draft-ietf-mmusic-sdp-new-01.txt   draft-ietf-mmusic-sdp-new-03.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
INTERNET-DRAFT Mark Handley/ACIRI INTERNET-DRAFT Mark Handley/ACIRI
draft-ietf-mmusic-sdp-new-01.txt Van Jacobson/Packet Design draft-ietf-mmusic-sdp-new-03.txt Van Jacobson/Packet Design
Colin Perkins/ISI Colin Perkins/ISI
Expires: September 2001 Expires: January 2002
SDP: Session Description Protocol SDP: Session Description Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.
This document is a product of the Multiparty Multimedia Session Control This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force. Comments (MMUSIC) working group of the Internet Engineering Task Force. Comments
are solicited and should be addressed to the working group's mailing are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors. list at confctrl@isi.edu and/or the authors.
1. Introduction Abstract
Note: This draft is essentially identical to RFC 2327. It is made This memo defines the Session Description Protocol (SDP). SDP
available to stimulate discussion of corrections and clarifications is intended for describing multimedia sessions for the
which need to be made in order to advance SDP to a draft standard RFC. purposes of session announcement, session invitation, and
other forms of multimedia session initiation.
1. Introduction
On the Internet multicast backbone (Mbone), a session directory tool is On the Internet multicast backbone (Mbone), a session directory tool is
used to advertise multimedia conferences and communicate the conference used to advertise multimedia conferences and communicate the conference
addresses and conference tool-specific information necessary for addresses and conference tool-specific information necessary for
participation. This document defines a session description protocol for participation. This document defines a session description protocol for
this purpose, and for general real-time multimedia session description this purpose, and for general real-time multimedia session description
purposes. This draft does not describe multicast address allocation or purposes. This draft does not describe multicast address allocation or
the distribution of SDP messages in detail. These are described in the distribution of SDP messages. These are described in accompanying
accompanying drafts. SDP is not intended for negotiation of media drafts. SDP is not intended for negotiation of media encodings.
encodings.
2. Background 2. Background
The Mbone is the part of the internet that supports IP multicast, and The Mbone is the part of the internet that supports IP multicast, and
thus permits efficient many-to-many communication. It is used thus permits efficient many-to-many communication. It is used
extensively for multimedia conferencing. Such conferences usually have extensively for multimedia conferencing. Such conferences usually have
the property that tight coordination of conference membership is not the property that tight coordination of conference membership is not
necessary; to receive a conference, a user at an Mbone site only has to necessary; to receive a conference, a user at an Mbone site only has to
know the conference's multicast group address and the UDP ports for the know the conference's multicast group address and the UDP ports for the
conference data streams. conference data streams.
skipping to change at page 3, line 33 skipping to change at page 3, line 24
A session announcement is a mechanism by which a session description A session announcement is a mechanism by which a session description
is conveyed to users in a pro-active fashion, i.e., the session is conveyed to users in a pro-active fashion, i.e., the session
description was not explicitly requested by the user. description was not explicitly requested by the user.
Session Description Session Description
A well defined format for conveying sufficient information to A well defined format for conveying sufficient information to
discover and participate in a multimedia session. discover and participate in a multimedia session.
3.1. Terminology 3.1. Terminology
This document uses the same words as RFC 1123 for defining the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
significance of each particular requirement. These words are: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [13].
must:
This word or the adjective ``required'' means that the item is an
absolute requirement of the specification.
should:
This word or the adjective ``recommended'' means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
may:
This word or the adjective ``optional'' means that this item is
truly optional. One implementation may choose to include the item
because a particular application requires it or because it enhances
the product, for example, another implementation may omit the same
item.
An implementation is not compliant if it fails to satisfy one or more of 4. Examples of SDP Usage
the must requirements for the protocols it implements. An
implementation that satisfies all the must and all the should
requirements for the protocols it implements is said to be
``unconditionally compliant''; one that satisfies all the must
requirements but not all of the should requirements for the protocols it
implements is said to be ``conditionally compliant''.
4. SDP Usage 4.1. Session Initiation
4.1. Multicast Announcements The Session Initiation Protocol, SIP [11] is an application-layer
control protocol for creating, modifying and terminating sessions such
as Internet multimedia conferences, Internet telephone calls and
multimedia distribution. The SIP messages used to create sessions carry
session descriptions which allow participants to agree on a set of
compatible media types. These session descriptions are commonly
formatted using SDP.
SDP is a session description protocol for multimedia sessions. A common 4.2. Streaming media
mode of usage is for a client to announce a conference session by
periodically multicasting an announcement packet to a well known
multicast address and port using the Session Announcement Protocol
(SAP).
SAP packets are UDP packets with the following format: The Real Time Streaming Protocol, RTSP [12], is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable controlled,
on-demand delivery of real-time data, such as audio and video. It is
necessary for RTSP to convey a description of the session to be
controlled: SDP is often used for this purpose.
0 31 4.3. Multicast Announcement
|--------------------|
| SAP header |
|--------------------|
| text payload |
|/\/\/\/\/\/\/\/\/\/\|
The header is the Session Announcement Protocol header. SAP is In order to assist the advertisement of multicast multimedia conferences
described in more detail in a companion draft [4] and other multicast sessions, and to communicate the relevant session
setup information to prospective participants, a distributed session
directory may be used. An instance of such a session directory
periodically sends packets containing a description of the session to a
well known multicast group. These advertisements are received by other
session directories such that potential remote participants can use the
session description to start the tools required to participate in the
session.
The text payload is an SDP session description, as described in this One protocol commonly used to implement such a distributed directory is
draft. The text payload should be no greater than 1 Kbyte in length. the Session Announcement Protocol, SAP [4]. SDP provides the recommended
If announced by SAP, only one session announcement is permitted in a session description format for such announcements.
single packet.
4.2. Email and WWW Announcements 4.4. Email and the World Wide Web
Alternative means of conveying session descriptions include electronic Alternative means of conveying session descriptions include electronic
mail and the World Wide Web. For both email and WWW distribution, the mail and the World Wide Web. For both email and WWW distribution, the
use of the MIME content type ``application/sdp'' should be used. This use of the MIME content type ``application/sdp'' MUST be used. This
enables the automatic launching of applications for participation in the enables the automatic launching of applications for participation in the
session from the WWW client or mail reader in a standard manner. session from the WWW client or mail reader in a standard manner.
Note that announcements of multicast sessions made only via email or the Note that announcements of multicast sessions made only via email or the
World Wide Web (WWW) do not have the property that the receiver of a World Wide Web (WWW) do not have the property that the receiver of a
session announcement can necessarily receive the session because the session announcement can necessarily receive the session because the
multicast sessions may be restricted in scope, and access to the WWW multicast sessions may be restricted in scope, and access to the WWW
server or reception of email is possible outside this scope. SAP server or reception of email is possible outside this scope. SAP
announcements do not suffer from this mismatch. announcements do not suffer from this mismatch.
skipping to change at page 7, line 13 skipping to change at page 6, line 37
o An arbitrary list of start and stop times bounding the session o An arbitrary list of start and stop times bounding the session
o For each bound, repeat times such as "every Wednesday at 10am for o For each bound, repeat times such as "every Wednesday at 10am for
one hour" one hour"
This timing information is globally consistent, irrespective of local This timing information is globally consistent, irrespective of local
time zone or daylight saving time. time zone or daylight saving time.
5.3. Private Sessions 5.3. Private Sessions
It is possible to create both public sessions and private sessions. It is possible to create both public sessions and private sessions. SDP
Private sessions will typically be conveyed by encrypting the session itself does not distinguish between these: private sessions are
description to distribute it. The details of how encryption is typically conveyed by encrypting the session description during
performed are dependent on the mechanism used to convey SDP - see [4] distribution. The details of how encryption is performed are dependent
for how this is done for session announcements. on the mechanism used to convey SDP - e.g. mechanisms are defined for
SDP transported using SAP [4] and SIP [11].
If a session announcement is private it is possible to use that private If a session announcement is private it is possible to use that private
announcement to convey encryption keys necessary to decode each of the announcement to convey encryption keys necessary to decode each of the
media in a conference, including enough information to know which media in a conference, including enough information to know which
encryption scheme is used for each media. encryption scheme is used for each media.
5.4. Obtaining Further Information about a Session 5.4. Obtaining Further Information about a Session
A session description should convey enough information to decide whether A session description should convey enough information to decide whether
or not to participate in a session. SDP may include additional pointers or not to participate in a session. SDP may include additional pointers
in the form of Universal Resources Identifiers (URIs) for more in the form of Universal Resources Identifiers (URIs) for more
information about the session. information about the session.
5.5. Categorisation 5.5. Categorisation
When many session descriptions are being distributed by SAP or any other When many session descriptions are being distributed by SAP, or any
advertisement mechanism, it may be desirable to filter announcements other advertisement mechanism, it may be desirable to filter
that are of interest from those that are not. SDP supports a announcements that are of interest from those that are not. SDP
categorisation mechanism for sessions that is capable of being supports a categorisation mechanism for sessions that is capable of
automated. being automated.
5.6. Internationalization 5.6. Internationalization
The SDP specification recommends the use of the ISO 10646 character sets The SDP specification recommends the use of the ISO 10646 character sets
in the UTF-8 encoding (RFC 2044) to allow many different languages to be in the UTF-8 encoding (RFC 2044) to allow many different languages to be
represented. However, to assist in compact representations, SDP also represented. However, to assist in compact representations, SDP also
allows other character sets such as ISO 8859-1 to be used when desired. allows other character sets such as ISO 8859-1 to be used when desired.
Internationalization only applies to free-text fields (session name and Internationalization only applies to free-text fields (session name and
background information), and not to SDP as a whole. background information), and not to SDP as a whole.
6. SDP Specification 6. SDP Specification
SDP session descriptions are entirely textual using the ISO 10646 SDP session descriptions are entirely textual using the ISO 10646
character set in UTF-8 encoding. SDP field names and attributes names character set in UTF-8 encoding. SDP field names and attributes names
use only the US-ASCII subset of UTF-8, but textual fields and attribute use only the US-ASCII subset of UTF-8, but textual fields and attribute
values may use the full ISO 10646 character set. The textual form, as values may use the full ISO 10646 character set. The textual form, as
opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance
portability, to enable a variety of transports to be used (e.g, session portability, to enable a variety of transports to be used (e.g, session
description in a MIME email message) and to allow flexible, text-based description in a MIME email message) and to allow flexible, text-based
toolkits (e.g., Tcl/Tk ) to be used to generate and to process session toolkits (e.g., Tcl/Tk ) to be used to generate and to process session
descriptions. However, since the total bandwidth allocated to all SAP descriptions. However, since SDP may be used in environments where the
announcements is strictly limited, the encoding is deliberately compact. maximum permissable size of a session description is limited (e.g. SAP
Also, since announcements may be transported via very unreliable means announcements; SIP transported in UDP), the encoding is deliberately
(e.g., email) or damaged by an intermediate caching server, the encoding compact. Also, since announcements may be transported via very
was designed with strict order and formatting rules so that most errors unreliable means (e.g., email) or damaged by an intermediate caching
would result in malformed announcements which could be detected easily server, the encoding was designed with strict order and formatting rules
and discarded. This also allows rapid discarding of encrypted so that most errors would result in malformed announcements which could
announcements for which a receiver does not have the correct key. be detected easily and discarded. This also allows rapid discarding of
encrypted announcements for which a receiver does not have the correct
key.
An SDP session description consists of a number of lines of text of the An SDP session description consists of a number of lines of text of the
form form
<type>=<value> <type>=<value>
<type> is always exactly one character and is case-significant. <value> <type> is always exactly one character and is case-significant. <value>
is a structured text string whose format depends on <type>. It also is a structured text string whose format depends on <type>. It also
will be case-significant unless a specific field defines otherwise. will be case-significant unless a specific field defines otherwise.
Whitespace is not permitted either side of the `=' sign. In general Whitespace MUST NOT be used either side of the `=' sign. In general
<value> is either a number of fields delimited by a single space <value> is either a number of fields delimited by a single space
character or a free format string. character or a free format string.
A session description consists of a session-level description (details A session description consists of a session-level description (details
that apply to the whole session and all media streams) and optionally that apply to the whole session and all media streams) and optionally
several media-level descriptions (details that apply onto to a single several media-level descriptions (details that apply onto to a single
media stream). media stream).
An announcement consists of a session-level section followed by zero or An announcement consists of a session-level section followed by zero or
more media-level sections. The session-level part starts with a `v=' more media-level sections. The session-level part starts with a `v='
line and continues to the first media-level section. The media line and continues to the first media-level section. The media
description starts with an `m=' line and continues to the next media description starts with an `m=' line and continues to the next media
description or end of the whole session description. In general, description or end of the whole session description. In general,
session-level values are the default for all media unless overridden by session-level values are the default for all media unless overridden by
an equivalent media-level value. an equivalent media-level value.
When SDP is conveyed by SAP, only one session description is allowed per Some lines in each description are REQUIRED and some are OPTIONAL but
packet. When SDP is conveyed by other means, many SDP session all MUST appear in exactly the order given here (the fixed order greatly
descriptions may be concatenated together (the `v=' line indicating the enhances error detection and allows for a simple parser). OPTIONAL
start of a session description terminates the previous description).
Some lines in each description are required and some are optional but
all must appear in exactly the order given here (the fixed order greatly
enhances error detection and allows for a simple parser). Optional
items are marked with a `*'. items are marked with a `*'.
Session description Session description
v= (protocol version) v= (protocol version)
o= (owner/creator and session identifier). o= (owner/creator and session identifier).
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
p=* (phone number) p=* (phone number)
skipping to change at page 9, line 37 skipping to change at page 9, line 34
Media description Media description
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information - optional if included at session-level) c=* (connection information - optional if included at session-level)
b=* (bandwidth information) b=* (bandwidth information)
k=* (encryption key) k=* (encryption key)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
The set of `type' letters is deliberately small and not intended to be The set of `type' letters is deliberately small and not intended to be
extensible -- SDP parsers must completely ignore any announcement that extensible -- an SDP parser MUST completely ignore any announcement that
contains a `type' letter that it does not understand. The `attribute' contains a `type' letter that it does not understand. The `attribute'
mechanism ("a=" described below) is the primary means for extending SDP mechanism ("a=" described below) is the primary means for extending SDP
and tailoring it to particular applications or media. Some attributes and tailoring it to particular applications or media. Some attributes
(the ones listed in this document) have a defined meaning but others may (the ones listed in this document) have a defined meaning but others may
be added on an application-, media- or session-specific basis. A be added on an application-, media- or session-specific basis. An SDP
session directory must ignore any attribute it doesn't understand. parser MUST ignore any attribute it doesn't understand.
The connection (`c=') and attribute (`a=') information in the session- The connection (`c=') and attribute (`a=') information in the session-
level section applies to all the media of that session unless overridden level section applies to all the media of that session unless overridden
by connection information or an attribute of the same name in the media by connection information or an attribute of the same name in the media
description. For instance, in the example below, each media behaves as description. For instance, in the example below, each media behaves as
if it were given a `recvonly' attribute. if it were given a `recvonly' attribute.
An example SDP description is: An example SDP description is:
v=0 v=0
skipping to change at page 10, line 43 skipping to change at page 10, line 43
Origin Origin
o=<username> <session id> <version> <network type> <address type> o=<username> <session id> <version> <network type> <address type>
<address> <address>
The ``o='' field gives the originator of the session (their username and The ``o='' field gives the originator of the session (their username and
the address of the user's host) plus a session id and session version the address of the user's host) plus a session id and session version
number. <username> is the user's login on the originating host, or it number. <username> is the user's login on the originating host, or it
is ``-'' if the originating host does not support the concept of user is ``-'' if the originating host does not support the concept of user
ids. <username> must not contain spaces. <session id> is a numeric ids. <username> MUST NOT contain spaces. <session id> is a numeric
string such that the tuple of <username>, <session id>, <network type>, string such that the tuple of <username>, <session id>, <network type>,
<address type> and <address> form a globally unique identifier for the <address type> and <address> form a globally unique identifier for the
session. The method of session id allocation is up to the creating session. The method of session id allocation is up to the creating
tool, but it has been suggested that a Network Time Protocol (NTP) tool, but it has been suggested that a Network Time Protocol (NTP)
timestamp be used to ensure uniqueness [1]. <version> is a version timestamp be used to ensure uniqueness [1]. <version> is a version
number for this announcement. It is needed for proxy announcements to number for this announcement. It is needed for proxy announcements to
detect which of several announcements for the same session is the most detect which of several announcements for the same session is the most
recent. Again its usage is up to the creating tool, so long as recent. Again its usage is up to the creating tool, so long as
<version> is increased when a modification is made to the session data. <version> is increased when a modification is made to the session data.
Again, it is recommended (but not mandatory) that an NTP timestamp is Again, it is RECOMMENDED (but not mandatory) that an NTP timestamp is
used. <network type> is a text string giving the type of network. used. <network type> is a text string giving the type of network.
Initially ``IN'' is defined to have the meaning ``Internet''. <address Initially ``IN'' is defined to have the meaning ``Internet''. <address
type> is a text string giving the type of the address that follows. type> is a text string giving the type of the address that follows.
Initially ``IP4'' and ``IP6'' are defined. <address> is the globally Initially ``IP4'' and ``IP6'' are defined. <address> is the globally
unique address of the machine from which the session was created. For unique address of the machine from which the session was created. For
an address type of IP4, this is either the fully-qualified domain name an address type of IP4, this is either the fully-qualified domain name
of the machine, or the dotted-decimal representation of the IP version 4 of the machine, or the dotted-decimal representation of the IP version 4
address of the machine. For an address type of IP6, this is either the address of the machine. For an address type of IP6, this is either the
fully-qualified domain name of the machine, or the compressed textual fully-qualified domain name of the machine, or the compressed textual
representation of the IP version 6 address of the machine. For both IP4 representation of the IP version 6 address of the machine. For both IP4
skipping to change at page 11, line 33 skipping to change at page 11, line 33
In general, the ``o='' field serves as a globally unique identifier for In general, the ``o='' field serves as a globally unique identifier for
this version of this session description, and the subfields excepting this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any the version taken together identify the session irrespective of any
modifications. modifications.
Session Name Session Name
s=<session name> s=<session name>
The ``s='' field is the session name. There must be one and only one The ``s='' field is the session name. There MUST be one and only one
``s='' field per session description, and it must contain ISO 10646 ``s='' field per session description, and it SHOULD contain ISO 10646
characters (but see also the `charset' attribute below). characters (but see also the `charset' attribute below).
Session and Media Information Session and Media Information
i=<session description> i=<session description>
The ``i='' field is information about the session. There may be at most The ``i='' field is information about the session. There may be at most
one session-level ``i='' field per session description, and at most one one session-level ``i='' field per session description, and at most one
``i='' field per media. Although it may be omitted, this is discouraged ``i='' field per media. Although it may be omitted, this is NOT
for session announcements, and user interfaces for composing sessions RECOMMENDED for session announcements, and user interfaces for composing
should require text to be entered. If it is present it must contain ISO sessions should require text to be entered. If it is present it must
10646 characters (but see also the `charset' attribute below). contain ISO 10646 characters (but see also the `charset' attribute
below).
A single ``i='' field can also be used for each media definition. In A single ``i='' field can also be used for each media definition. In
media definitions, ``i='' fields are primarily intended for labeling media definitions, ``i='' fields are primarily intended for labeling
media streams. As such, they are most likely to be useful when a single media streams. As such, they are most likely to be useful when a single
session has more than one distinct media stream of the same media type. session has more than one distinct media stream of the same media type.
An example would be two different whiteboards, one for slides and one
An example would be two different whiteboards, one for slides and one
for feedback and questions. for feedback and questions.
URI URI
u=<URI> u=<URI>
o A URI is a Universal Resource Identifier as used by WWW clients o A URI is a Universal Resource Identifier as used by WWW clients
o The URI should be a pointer to additional information about the o The URI should be a pointer to additional information about the
conference conference
o This field is optional, but if it is present it should be specified o This field is OPTIONAL, but if it is present it MUST be specified
before the first media field before the first media field
o No more than one URI field is allowed per session description o No more than one URI field is allowed per session description
Email Address and Phone Number Email Address and Phone Number
e=<email address> e=<email address>
p=<phone number> p=<phone number>
o These specify contact information for the person responsible for the o These specify contact information for the person responsible for the
conference. This is not necessarily the same person that created conference. This is not necessarily the same person that created
the conference announcement. the conference announcement.
o Either an email field or a phone field must be specified. o Inclusion of an email address or phone number is OPTIONAL. Note
Additional email and phone fields are allowed. that the previous version of SDP specified that either an email
field or a phone field MUST be specified, but this was widely
ignored. The change brings the specification into line with common
usage.
o If these are present, they should be specified before the first o If these are present, they should be specified before the first
media field. media field.
o More than one email or phone field can be given for a session o More than one email or phone field can be given for a session
description. description.
o Phone numbers should be given in the conventional international o Phone numbers should be given in the conventional international
format - preceded by a ``+'' and the international country code. format - preceded by a ``+'' and the international country code.
There must be a space or a hyphen (``-'') between the country code There must be a space or a hyphen (``-'') between the country code
skipping to change at page 13, line 24 skipping to change at page 13, line 29
The free text string should be in the ISO-10646 character set with The free text string should be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate charset session-level attribute is set. the appropriate charset session-level attribute is set.
Connection Data Connection Data
c=<network type> <address type> <connection address> c=<network type> <address type> <connection address>
The ``c='' field contains connection data. The ``c='' field contains connection data.
A session announcement must contain one ``c='' field in each media A session announcement MUST contain one ``c='' field in each media
description (see below) or a ``c='' field at the session-level. It may description (see below) or a ``c='' field at the session-level. It MAY
contain a session-level ``c='' field and one additional ``c='' field per contain a session-level ``c='' field and one additional ``c='' field per
media description, in which case the per-media values override the media description, in which case the per-media values override the
session-level settings for the relevant media. session-level settings for the relevant media.
The first sub-field is the network type, which is a text string giving The first sub-field is the network type, which is a text string giving
the type of network. Initially ``IN'' is defined to have the meaning the type of network. Initially ``IN'' is defined to have the meaning
``Internet''. ``Internet''.
The second sub-field is the address type. This allows SDP to be used The second sub-field is the address type. This allows SDP to be used
for sessions that are not IP based. Currently only IP4 is defined. for sessions that are not IP based. Currently only IP4 and IP6 are
defined.
The third sub-field is the connection address. Optional extra sub- The third sub-field is the connection address. Optional extra sub-
fields may be added after the connection address depending on the value fields may be added after the connection address depending on the value
of the <address type> field. of the <address type> field.
For IP4 addresses, the connection address is defined as follows: For IP4 and IP6 addresses, the connection address is defined as follows:
o Typically the connection address will be a class-D IP multicast o If the session is multicast, the connection address will be an IP
group address. If the conference is not multicast, then the multicast group address. If the conference is not multicast, then
connection address contains the unicast IP address of the expected the connection address contains the unicast IP address of the
data source or data relay or data sink as determined by additional expected data source or data relay or data sink as determined by
attribute fields. It is not expected that unicast addresses will be additional attribute fields. It is not expected that unicast
given in a session description that is communicated by a multicast addresses will be given in a session description that is
announcement, though this is not prohibited. communicated by a multicast announcement, though this is not
prohibited.
o Conferences using an IP multicast connection address must also have o Conferences using an IP multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with address. The TTL and the address together define the scope with
which multicast packets sent in this conference will be sent. TTL which multicast packets sent in this conference will be sent. TTL
values must be in the range 0-255. values MUST be in the range 0-255.
The TTL for the session is appended to the address using a slash as The TTL for the session is appended to the address using a slash as
a separator. An example is: a separator. An example is:
c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.1/127
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of encoding from a single media source is split into a number of
layers. The receiver can choose the desired quality (and hence layers. The receiver can choose the desired quality (and hence
bandwidth) by only subscribing to a subset of these layers. Such bandwidth) by only subscribing to a subset of these layers. Such
skipping to change at page 14, line 45 skipping to change at page 15, line 5
be used at a ttl of 127. This is semantically identical to be used at a ttl of 127. This is semantically identical to
including multiple ``c='' lines in a media description: including multiple ``c='' lines in a media description:
c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127 c=IN IP4 224.2.1.3/127
Multiple addresses or ``c='' lines can only be specified on a per- Multiple addresses or ``c='' lines can only be specified on a per-
media basis, and not for a session-level ``c='' field. media basis, and not for a session-level ``c='' field.
It is illegal for the slash notation described above to be used for The slash notation described above MUST NOT be used for IP unicast
IP unicast addresses. addresses.
Bandwidth Bandwidth
b=<modifier>:<bandwidth-value> b=<modifier>:<bandwidth-value>
o This specifies the proposed bandwidth to be used by the session or o This specifies the proposed bandwidth to be used by the session or
media, and is optional. media, and is OPTIONAL.
o <bandwidth-value> is in kilobits per second by default. Modifiers o <bandwidth-value> is in kilobits per second by default. Modifiers
may specify that alternative units are to be used (the modifiers may specify that alternative units are to be used (the modifiers
defined in this memo use the default units). defined in this memo use the default units).
o <modifier> is a single alphanumeric word giving the meaning of the o <modifier> is a single alphanumeric word giving the meaning of the
bandwidth figure. bandwidth figure.
o Two modifiers are initially defined: o Two modifiers are initially defined:
CT Conference Total: An implicit maximum bandwidth is associated with CT Conference Total: If the bandwidth of a session or media in a
each TTL on the Mbone or within a particular multicast session is different from the bandwidth implicit from the scope, a
administrative scope region (the Mbone bandwidth vs. TTL limits `b=CT:...' line should be supplied for the session giving the
are given in the MBone FAQ). If the bandwidth of a session or proposed upper limit to the bandwidth used. The primary purpose
media in a session is different from the bandwidth implicit from of this is to give an approximate idea as to whether two or more
the scope, a `b=CT:...' line should be supplied for the session sessions can co-exist simultaneously.
giving the proposed upper limit to the bandwidth used. The
primary purpose of this is to give an approximate idea as to
whether two or more conferences can co-exist simultaneously.
AS Application-Specific Maximum: The bandwidth is interpreted to be AS Application-Specific Maximum: The bandwidth is interpreted to be
application-specific, i.e., will be the application's concept of application-specific, i.e., will be the application's concept of
maximum bandwidth. Normally this will coincide with what is set maximum bandwidth. Normally this will coincide with what is set
on the application's ``maximum bandwidth'' control if applicable. on the application's ``maximum bandwidth'' control if applicable.
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at all
sites. AS gives a bandwidth figure for a single media at a single sites. AS gives a bandwidth figure for a single media at a single
site, although there may be many sites sending simultaneously. site, although there may be many sites sending simultaneously.
o Extension Mechanism: Tool writers can define experimental bandwidth o Extension Mechanism: Tool writers can define experimental bandwidth
modifiers by prefixing their modifier with ``X-''. For example: modifiers by prefixing their modifier with ``X-''. For example:
b=X-YZ:128 b=X-YZ:128
SDP parsers should ignore bandwidth fields with unknown modifiers. SDP parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers should be alpha-numeric and, although no length limit is Modifiers MUST be alpha-numeric and, although no length limit is
given, they are recommended to be short. given, they are recommended to be short.
Times, Repeat Times and Time Zones Times, Repeat Times and Time Zones
t=<start time> <stop time> t=<start time> <stop time>
o ``t='' fields specify the start and stop times for a conference o ``t='' fields specify the start and stop times for a session.
session. Multiple ``t='' fields may be used if a session is active Multiple ``t='' fields MAY be used if a session is active at
at multiple irregularly spaced times; each additional ``t='' field multiple irregularly spaced times; each additional ``t='' field
specifies an additional period of time for which the session will be specifies an additional period of time for which the session will be
active. If the session is active at regular times, an ``r='' field active. If the session is active at regular times, an ``r='' field
(see below) should be used in addition to and following a ``t='' (see below) should be used in addition to and following a ``t=''
field - in which case the ``t='' field specifies the start and stop field - in which case the ``t='' field specifies the start and stop
times of the repeat sequence. times of the repeat sequence.
o The first and second sub-fields give the start and stop times for o The first and second sub-fields give the start and stop times for
the conference respectively. These values are the decimal the session respectively. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds representation of Network Time Protocol (NTP) time values in seconds
[1]. To convert these values to UNIX time, subtract decimal [1]. To convert these values to UNIX time, subtract decimal
2208988800. 2208988800.
NTP timestamps are 64 bit values which wrap sometime in the year
2036. Since SDP uses an arbitrary length decimal representation,
this should not cause an issue (SDP timestamps will continue
counting seconds since 1900, NTP will use the value modulo the 64
bit limit).
o If the stop-time is set to zero, then the session is not bounded, o If the stop-time is set to zero, then the session is not bounded,
though it will not become active until after the start-time. If the though it will not become active until after the start-time. If the
start-time is also zero, the session is regarded as permanent. start-time is also zero, the session is regarded as permanent.
User interfaces should strongly discourage the creation of unbounded User interfaces SHOULD strongly discourage the creation of unbounded
and permanent sessions as they give no information about when the and permanent sessions as they give no information about when the
session is actually going to terminate, and so make scheduling session is actually going to terminate, and so make scheduling
difficult. difficult.
The general assumption may be made, when displaying unbounded The general assumption may be made, when displaying unbounded
sessions that have not timed out to the user, that an unbounded sessions that have not timed out to the user, that an unbounded
session will only be active until half an hour from the current time session will only be active until half an hour from the current time
or the session start time, whichever is the later. If behaviour or the session start time, whichever is the later. If behaviour
other than this is required, an end-time should be given and other than this is required, an end-time should be given and
modified as appropriate when new information becomes available about modified as appropriate when new information becomes available about
when the session should really end. when the session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times which state precisely when unless there are associated repeat times which state precisely when
the session will be active. In general, permanent sessions should the session will be active. In general, permanent sessions SHOULD
not be created for any session expected to have a duration of less NOT be created for any session expected to have a duration of less
than 2 months, and should be discouraged for sessions expected to than 2 months, and should be discouraged for sessions expected to
have a duration of less than 6 months. have a duration of less than 6 months.
r=<repeat interval> <active duration> <list of offsets from start-time> r=<repeat interval> <active duration> <list of offsets from start-time>
o ``r='' fields specify repeat times for a session. For example, if o ``r='' fields specify repeat times for a session. For example, if
a session is active at 10am on Monday and 11am on Tuesday for one a session is active at 10am on Monday and 11am on Tuesday for one
hour each week for three months, then the <start time> in the hour each week for three months, then the <start time> in the
corresponding ``t='' field would be the NTP representation of 10am corresponding ``t='' field would be the NTP representation of 10am
on the first Monday, the <repeat interval> would be 1 week, the on the first Monday, the <repeat interval> would be 1 week, the
<active duration> would be 1 hour, and the offsets would be zero and <active duration> would be 1 hour, and the offsets would be zero and
25 hours. The corresponding ``t='' field stop time would be the NTP 25 hours. The corresponding ``t='' field stop time would be the NTP
representation of the end of the last session three months later. By representation of the end of the last session three months later. By
default all fields are in seconds, so the ``r='' and ``t='' fields default all fields are in seconds, so the ``r='' and ``t='' fields
might be: might be:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
To make announcements more compact, times may also be given in units To make description more compact, times may also be given in units
of days, hours or minutes. The syntax for these is a number of days, hours or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. immediately followed by a single case-sensitive character.
Fractional units are not allowed - a smaller unit should be used Fractional units are not allowed - a smaller unit should be used
instead. The following unit specification characters are allowed: instead. The following unit specification characters are allowed:
d - days (86400 seconds) d - days (86400 seconds)
h - minutes (3600 seconds) h - minutes (3600 seconds)
m - minutes (60 seconds) m - minutes (60 seconds)
s - seconds (allowed for completeness but not recommended) s - seconds (allowed for completeness but not recommended)
skipping to change at page 18, line 22 skipping to change at page 18, line 29
o If a session is likely to last several years, it is expected that o If a session is likely to last several years, it is expected that
the session announcement will be modified periodically rather than the session announcement will be modified periodically rather than
transmit several years worth of adjustments in one announcement. transmit several years worth of adjustments in one announcement.
Encryption Keys Encryption Keys
k=<method> k=<method>
k=<method>:<encryption key> k=<method>:<encryption key>
o The session description protocol may be used to convey encryption o The session description protocol MAY be used to convey encryption
keys. A key field is permitted before the first media entry (in keys. A key field is permitted before the first media entry (in
which case it applies to all media in the session), or for each which case it applies to all media in the session), or for each
media entry as required. media entry as required.
o The format of keys and their usage is outside the scope of this o The format of keys and their usage is outside the scope of this
document, but see [3]. document, but see [3].
o The method indicates the mechanism to be used to obtain a usable key o The method indicates the mechanism to be used to obtain a usable key
by external means, or from the encoded encryption key given. The by external means, or from the encoded encryption key given. The
following methods are defined: following methods are defined:
skipping to change at page 19, line 50 skipping to change at page 20, line 10
o value attributes. A value attribute is of the form o value attributes. A value attribute is of the form
``a=<attribute>:<value>''. An example might be that a whiteboard ``a=<attribute>:<value>''. An example might be that a whiteboard
could have the value attribute ``a=orient:landscape'' could have the value attribute ``a=orient:landscape''
Attribute interpretation depends on the media tool being invoked. Thus Attribute interpretation depends on the media tool being invoked. Thus
receivers of session descriptions should be configurable in their receivers of session descriptions should be configurable in their
interpretation of announcements in general and of attributes in interpretation of announcements in general and of attributes in
particular. particular.
Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8. Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8.
Attribute values are byte strings, and MAY use any byte value except Attribute values are byte strings, and MAY use any byte value except
0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are
to be interpreted as in ISO-10646 character set with UTF-8 encoding. to be interpreted as in ISO-10646 character set with UTF-8 encoding.
Unlike other text fields, attribute values are NOT normally affected by Unlike other text fields, attribute values are NOT normally affected by
the `charset' attribute as this would make comparisons against known the `charset' attribute as this would make comparisons against known
values problematic. However, when an attribute is defined, it can be values problematic. However, when an attribute is defined, it can be
defined to be charset-dependent, in which case it's value should be defined to be charset-dependent, in which case it's value should be
interpreted in the session charset rather than in ISO-10646. interpreted in the session charset rather than in ISO-10646.
skipping to change at page 20, line 47 skipping to change at page 21, line 7
conference control channel for the session. conference control channel for the session.
o The second sub-field is the transport port to which the media stream o The second sub-field is the transport port to which the media stream
will be sent. The meaning of the transport port depends on the will be sent. The meaning of the transport port depends on the
network being used as specified in the relevant ``c'' field and on network being used as specified in the relevant ``c'' field and on
the transport protocol defined in the third sub-field. Other ports the transport protocol defined in the third sub-field. Other ports
used by the media application (such as the RTCP port, see [2]) used by the media application (such as the RTCP port, see [2])
should be derived algorithmically from the base media port. should be derived algorithmically from the base media port.
Note: For transports based on UDP, the value should be in the range Note: For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even 1024 to 65535 inclusive. For RTP compliance it SHOULD be an even
number. number.
For applications where hierarchically encoded streams are being sent For applications where hierarchically encoded streams are being sent
to a unicast address, it may be necessary to specify multiple to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that used transport ports. This is done using a similar notation to that used
for IP multicast addresses in the ``c='' field: for IP multicast addresses in the ``c='' field:
m=<media> <port>/<number of ports> <transport> <fmt list> m=<media> <port>/<number of ports> <transport> <fmt list>
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
skipping to change at page 22, line 22 skipping to change at page 22, line 29
In addition, relays and monitoring tools that are transport- In addition, relays and monitoring tools that are transport-
protocol-specific but format-independent are possible. protocol-specific but format-independent are possible.
For RTP media streams operating under the RTP Audio/Video Profile For RTP media streams operating under the RTP Audio/Video Profile
[3], the protocol field is ``RTP/AVP''. Should other RTP profiles [3], the protocol field is ``RTP/AVP''. Should other RTP profiles
be defined in the future, their profiles will be specified in the be defined in the future, their profiles will be specified in the
same way. For example, the protocol field ``RTP/XYZ'' would specify same way. For example, the protocol field ``RTP/XYZ'' would specify
RTP operating under a profile whose short name is ``XYZ''. RTP operating under a profile whose short name is ``XYZ''.
o The fourth and subsequent sub-fields are media formats. For audio o The fourth and subsequent sub-fields are media formats. For audio
and video, these will normally be a media payload type as defined in and video, these SHOULD reference a MIME sub-type describing the
the RTP Audio/Video Profile. format under the `audio' and `video' top-level MIME types.
When a list of payload formats is given, this implies that all of When a list of payload formats is given, this implies that all of
these formats may be used in the session, but the first of these these formats may be used in the session, but the first of these
formats is the default format for the session. formats is the default format for the session.
For media whose transport protocol is not RTP or UDP the format For media whose transport protocol is not RTP or UDP the format
field is protocol specific. Such formats should be defined in an field is protocol specific. Such formats should be defined in an
additional specification document. additional specification document.
For media whose transport protocol is RTP, SDP can be used to For media whose transport protocol is RTP, SDP can be used to
skipping to change at page 25, line 6 skipping to change at page 25, line 13
not dependent on charset. not dependent on charset.
a=ptime:<packet time> a=ptime:<packet time>
This gives the length of time in milliseconds represented by the This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio data. media in a packet. This is probably only meaningful for audio data.
It should not be necessary to know ptime to decode RTP or vat audio, It should not be necessary to know ptime to decode RTP or vat audio,
and it is intended as a recommendation for the and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media attribute, and is encoding/packetisation of audio. It is a media attribute, and is
not dependent on charset. not dependent on charset.
a=maxptime:<maximum packet time>
The maximum amount of media which can be encapsulated in each
packet, expressed as time in milliseconds. The time shall be
calculated as the sum of the time the media present in the packet
represents. The time SHOULD be a multiple of the frame size. This is
probably only meaningful for audio data. It is a media attribute,
and is not dependent on charset.
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only mode This specifies that the tools should be started in receive-only mode
where applicable. It can be either a session or media attribute, and where applicable. It can be either a session or media attribute, and
is not dependent on charset. is not dependent on charset.
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and receive This specifies that the tools should be started in send and receive
mode. This is necessary for interactive conferences with tools such mode. This is necessary for interactive conferences with tools such
as wb which defaults to receive only mode. It can be either a as wb which defaults to receive only mode. It can be either a
session or media attribute, and is not dependent on charset. session or media attribute, and is not dependent on charset.
skipping to change at page 29, line 8 skipping to change at page 30, line 8
controller is given. controller is given.
In this document, only the declarative style of conference control In this document, only the declarative style of conference control
declaration is specified. Other forms of conference control should declaration is specified. Other forms of conference control should
specify an appropriate type attribute, and should define the specify an appropriate type attribute, and should define the
implications this has for control media. implications this has for control media.
7. Security Considerations 7. Security Considerations
SDP is a session description format that describes multimedia sessions. SDP is a session description format that describes multimedia sessions.
A session description should not be trusted unless it has been obtained A session description SHOULD NOT be trusted unless it has been obtained
by an authenticated transport protocol from a trusted source. Many by an authenticated transport protocol from a trusted source. Many
different transport protocols may be used to distribute session different transport protocols may be used to distribute session
description, and the nature of the authentication will differ from description, and the nature of the authentication will differ from
transport to transport. transport to transport.
One transport that will frequently be used to distribute session One transport that will frequently be used to distribute session
descriptions is the Session Announcement Protocol (SAP). SAP provides descriptions is the Session Announcement Protocol (SAP). SAP provides
both encryption and authentication mechanisms but due to the nature of both encryption and authentication mechanisms but due to the nature of
session announcements it is likely that there are many occasions where session announcements it is likely that there are many occasions where
the originator of a session announcement cannot be authenticated because the originator of a session announcement cannot be authenticated because
skipping to change at page 29, line 34 skipping to change at page 30, line 34
should take a few precautions. Session description contain information should take a few precautions. Session description contain information
required to start software on the receivers system. Software that required to start software on the receivers system. Software that
parses a session description MUST not be able to start other software parses a session description MUST not be able to start other software
except that which is specifically configured as appropriate software to except that which is specifically configured as appropriate software to
participate in multimedia sessions. It is normally considered participate in multimedia sessions. It is normally considered
INAPPROPRIATE for software parsing a session description to start, on a INAPPROPRIATE for software parsing a session description to start, on a
user's system, software that is appropriate to participate in multimedia user's system, software that is appropriate to participate in multimedia
sessions, without the user first being informed that such software will sessions, without the user first being informed that such software will
be started and giving their consent. Thus a session description be started and giving their consent. Thus a session description
arriving by session announcement, email, sessioR multimedia,session page arriving by session announcement, email, sessioR multimedia,session page
SHOULD not deliver the user into an interactive SHOULD NOT deliver the user into an interactive
without the user being aware that this will happen. As it is not always without the user being aware that this will happen. As it is not always
simple to tell whether a session is interactive or not, applications simple to tell whether a session is interactive or not, applications
that are unsure should assume sessions are interactive. that are unsure should assume sessions are interactive.
In this specification, there are no attributes which would allow the In this specification, there are no attributes which would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If circumstances it might be appropriate to define such attributes. If
this is done an application parsing a session description containing this is done an application parsing a session description containing
such attributes SHOULD either ignore them, or inform the user that such attributes SHOULD either ignore them, or inform the user that
skipping to change at page 33, line 31 skipping to change at page 34, line 31
sess-id = 1*(DIGIT) sess-id = 1*(DIGIT)
;should be unique for this originating username/host ;should be unique for this originating username/host
sess-version = 1*(DIGIT) sess-version = 1*(DIGIT)
;0 is a new session ;0 is a new session
connection-address = multicast-address connection-address = multicast-address
| unicast-address | unicast-address
multicast-address = 3*(decimal_uchar ".") decimal_uchar "/" ttl multicast-address = IP4-multicast | IP6-multicast
IP4-multicast = m1 3*(decimal_uchar ".") decimal_uchar "/" ttl
[ "/" integer ] [ "/" integer ]
;multicast addresses may be in the range ;IPv4 multicast addresses may be in the range
;224.0.0.0 to 239.255.255.255 ;224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"|"5"|"6"|"7"|"8"|"9")) | ("23" DIGIT ))
IP6-multicast = hexpart [ ":" IP4-multicast ] "/" ttl [ "/" integer ]
; IPv6 address starting with FF00
ttl = decimal_uchar ttl = decimal_uchar
start-time = time | "0" start-time = time | "0"
stop-time = time | "0" stop-time = time | "0"
time = POS-DIGIT 9*(DIGIT) time = POS-DIGIT 9*(DIGIT)
;sufficient for 2 more centuries ;sufficient for 2 more centuries
repeat-interval = typed-time repeat-interval = typed-time
skipping to change at page 34, line 32 skipping to change at page 35, line 35
bandwidth = 1*(DIGIT) bandwidth = 1*(DIGIT)
username = safe username = safe
;pretty wide definition, but doesn't include space ;pretty wide definition, but doesn't include space
email-address = email | email "(" email-safe ")" | email-address = email | email "(" email-safe ")" |
email-safe "<" email ">" email-safe "<" email ">"
email = ;defined in RFC822 email = ;defined in RFC822
uri= ;defined in RFC1630 uri= ;defined in RFC1630 and RFC2732
phone-number = phone | phone "(" email-safe ")" | phone-number = phone | phone "(" email-safe ")" |
email-safe "<" phone ">" email-safe "<" phone ">"
phone = "+" POS-DIGIT 1*(space | "-" | DIGIT) phone = "+" POS-DIGIT 1*(space | "-" | DIGIT)
;there must be a space or hyphen between the ;there must be a space or hyphen between the
;international code and the rest of the number. ;international code and the rest of the number.
nettype = "IN" nettype = "IN"
;list to be extended ;list to be extended
addrtype = "IP4" | "IP6" addrtype = "IP4" | "IP6"
;list to be extended ;list to be extended
addr = FQDN | unicast-address addr = FQDN | unicast-address
FQDN = 4*(alpha-numeric|"-"|".")
;fully qualified domain name as specified in RFC1035
unicast-address = IP4-address | IP6-address
IP4-address = b1 "." decimal_uchar "." decimal_uchar "." b4
b1 = decimal_uchar
;less than "224"; not "0" or "127"
b4 = decimal_uchar
;not "0"
IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
text = byte-string
;default is to interpret this as IS0-10646 UTF8
;ISO 8859-1 requires a "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;any byte except NUL, CR or LF
decimal_uchar = DIGIT
| POS-DIGIT DIGIT
| ("1" 2*(DIGIT))
| ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
| ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))
integer = POS-DIGIT *(DIGIT)
alpha-numeric = ALPHA | DIGIT
DIGIT = "0" | POS-DIGIT
POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
"l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
"w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|
"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|
"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
email-safe = safe | space | tab
safe = alpha-numeric |
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
"~" | "\"
space = %d32
tab = %d9
CRLF = %d13.10
Appendix B: Guidelines for registering SDP names with IANA
There are seven field names that may be registered with IANA. Using the
terminology in the SDP specification BNF, they are "media", "proto",
"fmt", "att-field", "bwtype", "nettype" and "addrtype".
"media" (eg, audio, video, application, data).
The set of media is intended to be small and not to be extended
except under rare circumstances. The same rules should apply for
media names as for top-level MIME content types, and where possible
the same name should be registered for SDP as for MIME. For media
other than existing MIME top-level content types, a standards-track
RFC MUST be produced for a new top-level content type to be
registered, and the registration MUST provide good justification
why no existing media name is appropriate.
"proto"
In general this should be an IETF standards-track transport
protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890
profile).
However, people will want to invent their own proprietary transport
protocols. Some of these should be registered as a "fmt" using
"udp" as the protocol and some of which probably can't be.
Where the protocol and the application are intimately linked, such
as with the LBL whiteboard wb which used a proprietary and special
purpose protocol over UDP, the protocol name should be "udp" and
the format name that should be registered is "wb". The rules for
formats (see below) apply to such registrations.
Where the proprietary transport protocol really carries many
different data formats, it is possible to register a new protocol
name with IANA. In such a case, an RFC MUST be produced describing
the protocol and referenced in the registration. Such an RFC MAY
be informational, although it is preferable if it is standards-
track.
"fmt"
The format namespace is dependent on the context of the "proto"
field, so a format cannot be registered without specifying one or
more transport protocols that it applies to.
Formats cover all the possible encodings that might want to be
transported in a multimedia session.
For RTP formats that have been assigned static payload types, the
payload type number is used. For RTP formats using a dynamic
payload type number, the dynamic payload type number is given as
the format and an additional "rtpmap" attribute specifies the
format and parameters.
For non-RTP formats, any unregistered format name may be
registered. If there is a suitable mapping from a MIME subtype to
the format, then the MIME subtype name should be registered. If
there is no suitable mapping from a MIME subtype, a new name should
be registered. In either case, unless there are strong reasons not
to do so, a standards-track RFC SHOULD be produced describing the
format and this RFC SHOULD be referenced in the registration.
"att-field" (Attribute names)
Attribute field names MAY be registered with IANA, although this is
not compulsory, and unknown attributes are simply ignored.
When an attribute is registered, it must be accompanied by a brief
specification stating the following:
o contact name, email address and telephone number
o attribute-name (as it will appear in SDP)
o long-form attribute name in English
o type of attribute (session level, media level, or both)
o whether the attribute value is subject to the charset
attribute.
o a one paragraph explanation of the purpose of the attribute.
o a specification of appropriate attribute values for this
attribute.
IANA will not sanity check such attribute registrations except to
ensure that they do not clash with existing registrations.
Although the above is the minimum that IANA will accept, if the
attribute is expected to see widespread use and interoperability is
an issue, authors are encouraged to produce a standards-track RFC
that specifies the attribute more precisely.
Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific
pieces of software in a manner that might inhibit interoperability.
"bwtype" (bandwidth specifiers)
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers may be registered with IANA. The
submission MUST reference a standards-track RFC specifying the
semantics of the bandwidth specifier precisely, and indicating when
it should be used, and why the existing registered bandwidth
specifiers do not suffice.
"nettype" (Network Type)
New network types may be registered with IANA if SDP needs to be
used in the context of non-internet environments. Whilst these are
not normally the preserve of IANA, there may be circumstances when
an Internet application needs to interoperate with a non-internet
application, such as when gatewaying an internet telephony call
into the PSTN. The number of network types should be small and
should be rarely extended. A new network type cannot be registered
without registering at least one address type to be used with that
network type. A new network type registration MUST reference an
RFC which gives details of the network type and address type and
specifies how and when they would be used. Such an RFC MAY be
Informational.
"addrtype" (Address Type)
New address types may be registered with IANA. An address type is
only meaningful in the context of a network type, and any
registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A
new address type registration MUST reference an RFC giving details
of the syntax of the address type. Such an RFC MAY be
Informational. Address types are not expected to be registered
frequently.
Registration Procedure
To register a name the above guidelines should be followed regarding the
required level of documentation that is required. The registration
itself should be sent to IANA. Attribute registrations should include
the information given above. Other registrations should include the
following additional information:
o contact name, email address and telephone number
o name being registered (as it will appear in SDP)
o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o a one paragraph explanation of the purpose of the registered name.
o a reference to the specification (eg RFC number) of the registered
name.
IANA may refer any registration to the IESG or to any appropriate IETF
working group for review, and may request revisions to be made before a
registration will be made.
Appendix C: Authors' Addresses
Mark Handley
AT&T Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704, USA
Email: mjh@isi.edu
Van Jacobson
MS 46a-1121
Lawrence Berkeley Laboratory
Berkeley, CA 94720
United States
Email: van@ee.lbl.gov
Colin Perkins
USC Information Sciences Institute
3811 N. Fairfax Drive, Suite 200
Arlington, VA 22203
United States
Email: csp@isi.edu
Acknowledgments
Many people in the IETF MMUSIC working group have made comments and
suggestions contributing to this document. In particular, we would like
to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann and Steve Hanna.
References
[1] D. Mills, ``Network Time Protocol (version 3) specification and
implementation", RFC 1305, March 1992.
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A
Transport Protocol for Real-Time Applications'', RFC 1889, January
1996.
[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with
Minimal Control'', RFC 1890, January 1996.
[4] M. Handley, C. Perkins and E. Whelan, ``Session Announcement
Protocol'', RFC 2974, October 2000.
[5] V. Jacobson and S. McCanne, ``vat - X11-based audio teleconferencing
tool'' vat manual page, Lawrence Berkeley Laboratory, 1994.
[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Addison-Wesley, 1996.
[7] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS)
-- Part 1: Architecture and Basic Multilingual Plane. Five
amendments and a technical corrigendum have been published up
to now. UTF-8 is described in Annex R, published as Amendment 2.
[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641,
[9] F. Yergeau, ``UTF-8, a transformation format of Unicode and ISO
10646'', RFC 2044, October 1996
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
Receiving Internet-based H.323 Conferences", ITU, Geneva.
[11] M. Handley, H. Schulzrinne, E. Scholler and J. Rosenberg ``SIP:
Session Initiation Protocol'', RFC 2543, March 1999.
[12] H. Schulzrinne, A. Rao and R. Lanphier, ``Real Time Streaming
Protocol (RTSP)'' RFC 2326, April 1998.
[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement
Levels'', RFC 2119, March 1997.
 End of changes. 61 change blocks. 
152 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/