draft-ietf-mmusic-sdp-new-12.txt   draft-ietf-mmusic-sdp-new-13.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
INTERNET-DRAFT Mark Handley/ACIRI INTERNET-DRAFT Mark Handley/ICSI
draft-ietf-mmusic-sdp-new-12.txt Van Jacobson/Packet Design draft-ietf-mmusic-sdp-new-13.txt Van Jacobson/Packet Design
Colin Perkins/ISI Colin Perkins/ISI
Expires: September 2003 Expires: November 2003
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 7, line 8 skipping to change at page 7, line 8
When many session descriptions are being distributed by SAP, or any When many session descriptions are being distributed by SAP, or any
other advertisement mechanism, it may be desirable to filter other advertisement mechanism, it may be desirable to filter
announcements that are of interest from those that are not. SDP announcements that are of interest from those that are not. SDP
supports a categorisation mechanism for sessions that is capable of supports a categorisation mechanism for sessions that is capable of
being automated. being automated.
4.6. Internationalization 4.6. Internationalization
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
sets in the UTF-8 encoding (RFC 2279) to allow many different sets in the UTF-8 encoding [RFC2279] to allow many different
languages to be represented. However, to assist in compact languages to be represented. However, to assist in compact
representations, SDP also allows other character sets such as ISO representations, SDP also allows other character sets such as ISO
8859-1 to be used when desired. Internationalization only applies to 8859-1 to be used when desired. Internationalization only applies to
free-text fields (session name and background information), and not free-text fields (session name and background information), and not
to SDP as a whole. to SDP as a whole.
5. SDP Specification 5. 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 attribute names character set in UTF-8 encoding. SDP field names and attribute names
skipping to change at page 8, line 20 skipping to change at page 8, line 20
OPTIONAL items are marked with a "*". OPTIONAL 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)
c=* (connection information - not required if included in all media) c=* (connection information - not required if included in
all media)
b=* (bandwidth information) b=* (bandwidth information)
One or more time descriptions (see below) One or more time descriptions (see below)
z=* (time zone adjustments) z=* (time zone adjustments)
k=* (encryption key) k=* (encryption key)
a=* (zero or more session attribute lines) a=* (zero or more session attribute lines)
Zero or more media descriptions (see below) Zero or more media descriptions (see below)
Time description Time description
t= (time the session is active) t= (time the session is active)
r=* (zero or more repeat times) r=* (zero or more repeat times)
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 -- an SDP parser MUST completely ignore any announcement extensible -- an SDP parser MUST completely ignore any announcement
that contains a type letter that it does not understand. The that contains a type letter that it does not understand. The
attribute mechanism ("a=" described below) is the primary means for attribute mechanism ("a=" described below) is the primary means for
extending SDP and tailoring it to particular applications or media. extending SDP and tailoring it to particular applications or media.
Some attributes (the ones listed in this document) have a defined Some attributes (the ones listed in this document) have a defined
skipping to change at page 13, line 14 skipping to change at page 13, line 17
IP6 are defined. IP6 are defined.
The third sub-field is the connection address. Optional extra The third sub-field is the connection address. Optional extra
sub-fields MAY be added after the connection address depending on sub-fields MAY be added after the connection address depending on
the value of the <address type> field. the value of the <address type> field.
For IP4 and IP6 addresses, the connection address is defined as For IP4 and IP6 addresses, the connection address is defined as
follows: follows:
o If the session is multicast, the connection address will be o If the session is multicast, the connection address will be
an IP multicast group address. If the conference is not an IP multicast group address. If the session is not
multicast, then the connection address contains the unicast multicast, then the connection address contains the unicast
IP address of the expected data source or data relay or data IP address of the expected data source or data relay or data
sink as determined by additional attribute fields. It is not sink as determined by additional attribute fields. It is not
expected that unicast addresses will be given in a session expected that unicast addresses will be given in a session
description that is communicated by a multicast announcement, description that is communicated by a multicast announcement,
though this is not prohibited. though this is not prohibited.
o Conferences using an IPv4 multicast connection address MUST o Conferences using an IPv4 multicast connection address MUST
also have a time to live (TTL) value present in addition to also have a time to live (TTL) value present in addition to
the multicast address. The TTL and the address together the multicast address. The TTL and the address together
skipping to change at page 18, line 49 skipping to change at page 19, line 4
k=uri:<URI to obtain key> k=uri:<URI to obtain key>
A Universal Resource Identifier is included in the key field. A Universal Resource Identifier is included in the key field.
The URI refers to the data containing the key, and may require The URI refers to the data containing the key, and may require
additional authentication before the key can be returned. When additional authentication before the key can be returned. When
a request is made to the given URI, the MIME content-type of a request is made to the given URI, the MIME content-type of
the reply specifies the encoding for the key in the reply. the reply specifies the encoding for the key in the reply.
k=prompt k=prompt
No key is included in this SDP description, but the session or No key is included in this SDP description, but the session or
media stream referred to by this key field is encrypted. The media stream referred to by this key field is encrypted. The
user should be prompted for the key when attempting to join the user should be prompted for the key when attempting to join the
session, and this user-supplied key should then be used to session, and this user-supplied key should then be used to
decrypt the media streams. The use of user-specified keys is decrypt the media streams. The use of user-specified keys is
NOT RECOMMENDED, since such keys tend to have weak security NOT RECOMMENDED, since such keys tend to have weak security
properties. properties.
The key field MUST NOT be used unless it can be guaranteed that The key field MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure and trusted channel. Examples of the SDP is conveyed over a secure and trusted channel. An example
such channels might include an SSL encrypted SIP or HTTP session of such a channel might be SDP embedded inside an S/MIME message.
where any intermediate proxies are trusted, or SDP embedded inside
an encrypted S/MIME message.
Attributes Attributes
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes Attributes are the primary means for extending SDP. Attributes
may be defined to be used as "session-level" attributes, "media- may be defined to be used as "session-level" attributes, "media-
level" attributes, or both. level" attributes, or both.
skipping to change at page 20, line 15 skipping to change at page 20, line 17
Attribute values are octet strings, and MAY use any octet value Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default,
attribute values are to be interpreted as in ISO-10646 character attribute values are to be interpreted as in ISO-10646 character
set with UTF-8 encoding. Unlike other text fields, attribute set with UTF-8 encoding. Unlike other text fields, attribute
values are NOT normally affected by the "charset" attribute as values are NOT normally affected by the "charset" attribute as
this would make comparisons against known values problematic. this would make comparisons against known values problematic.
However, when an attribute is defined, it can be defined to be However, when an attribute is defined, it can be defined to be
charset-dependent, in which case it's value should be interpreted charset-dependent, in which case it's value should be interpreted
in the session charset rather than in ISO-10646. in the session charset rather than in ISO-10646.
Attributes SHOULD be registered with IANA (see Appendix B). Names Attributes MUST be registered with IANA (see Appendix B). If an
of unregistered attributes SHOULD begin with "X-" to prevent attribute is received that is not understood, it MUST be ignored
inadvertent collision with registered attributes, however the use by the receiver.
of unregistered attributes is NOT RECOMMENDED. If an attribute is
received that is not understood, it MUST be ignored by the
receiver.
Media Announcements Media Announcements
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" field, and is Each media description starts with an "m=" field, and is
terminated by either the next "m=" field or by the end of the terminated by either the next "m=" field or by the end of the
session description. A media field has several four sub-fields. session description. A media field has several four sub-fields.
skipping to change at page 21, line 8 skipping to change at page 21, line 8
defined in [RTCPSDP]). defined in [RTCPSDP]).
For applications where hierarchically encoded streams are being For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field: used 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.
For RTP, only the even ports are used for data and the For RTP, the default is that only the even numbered ports are used
corresponding one-higher odd port is used for RTCP. For example: for data and the corresponding one-higher odd port is used for
RTCP. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a
separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP])
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
skipping to change at page 23, line 36 skipping to change at page 23, line 39
m=audio 49230 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to register define the set of valid encoding names and/or a means to register
encoding names if that profile is to be used with SDP. encoding names if that profile is to be used with SDP.
Experimental encoding formats can also be specified using rtpmap.
RTP formats that are not registered as standard format names MUST
be preceded by "X-". Use of the ``X-'' prefix is deprecated, and
all new formats SHOULD be registered with IANA. Thus a new
experimental redundant audio stream called GSMLPC using dynamic
payload type 99 could be specified as:
m=audio 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to
receive the media stream has relevant configured state in its
session directory to know which tools are appropriate.
Note that RTP audio formats typically do not include information Note that RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is required, defined in the RTP Audio/Video Profile) packetisation is required,
the"ptime" attribute is used as given below. the"ptime" attribute is used as given below.
For more details on RTP audio and video formats, see [RFC1890]. For more details on RTP audio and video formats, see [RFC1890].
Predefined applicarion formats for the UDP protocol with non-RTP Predefined application formats for the UDP protocol with non-RTP
media are as below: media are as below:
wb: LBL Whiteboard (transport: udp) wb: LBL Whiteboard (transport: udp)
nt: UCL Network Text Editor (transport: udp) nt: UCL Network Text Editor (transport: udp)
Suggested Attributes Suggested Attributes
The following attributes are suggested. Since application writers The following attributes are suggested. Since application writers
may add new attributes as they are required, this list is not may add new attributes as they are required, this list is not
exhaustive. exhaustive.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category of This attribute gives the dot-separated hierarchical category of
the session. This is to enable a receiver to filter unwanted the session. This is to enable a receiver to filter unwanted
sessions by category. It would probably have been a compulsory sessions by category. It is a session-level attribute, and is
separate field, except for its experimental nature at this not dependent on charset.
time. It is a session-level attribute, and is not dependent on
charset.
a=keywds:<keywords> a=keywds:<keywords>
Like the cat attribute, this is to assist identifying wanted Like the cat attribute, this is to assist identifying wanted
sessions at the receiver. This allows a receiver to select sessions at the receiver. This allows a receiver to select
interesting session based on keywords describing the purpose of interesting session based on keywords describing the purpose of
the session. It is a session-level attribute. It is a charset the session. It is a session-level attribute. It is a charset
dependent attribute, meaning that its value should be dependent attribute, meaning that its value should be
interpreted in the charset specified for the session interpreted in the charset specified for the session
description if one is specified, or by default in ISO description if one is specified, or by default in ISO
skipping to change at page 25, line 39 skipping to change at page 25, line 25
mode where applicable. It can be either a session or media mode where applicable. It can be either a session or media
attribute, and is not dependent on charset. Note that recvonly attribute, and is not dependent on charset. Note that recvonly
applies to the media only, not to any associated control applies to the media only, not to any associated control
protocol (e.g. an RTP based system in recvonly mode SHOULD protocol (e.g. an RTP based system in recvonly mode SHOULD
still send RTCP packets). still send RTCP packets).
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and This specifies that the tools should be started in send and
receive mode. This is necessary for interactive conferences receive mode. This is necessary for interactive conferences
with tools such as wb which defaults to receive only mode. It with tools that default to receive only mode. It can be either
can be either a session or media attribute, and is not a session or media attribute, and is not dependent on charset.
dependent on charset.
If none of the attributes "sendonly", "recvonly", "inactive", If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions which are not of the conference type default for sessions which are not of the conference type
"broadcast" or "H332" (see below). "broadcast" or "H332" (see below).
a=sendonly a=sendonly
This specifies that the tools should be started in send-only This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is mode. An example may be where a different unicast address is
skipping to change at page 27, line 15 skipping to change at page 26, line 49
session name and information data. By default, the ISO-10646 session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used representation is required, other character sets may be used
such as ISO-8859-1 for Northern European languages. In such as ISO-8859-1 for Northern European languages. In
particular, the ISO 8859-1 is specified with the following SDP particular, the ISO 8859-1 is specified with the following SDP
attribute: attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
This is a session-level attribute; if this attribute is This is a session-level attribute; if this attribute is
present, it must be before the first media field. The charset present, it MUST be before the first media field. The charset
specified MUST be one of those registered with IANA, such as specified MUST be one of those registered with IANA, such as
ISO-8859-1. The character set identifier is a US-ASCII string ISO-8859-1. The character set identifier is a US-ASCII string
and MUST be compared against the IANA identifiers using a case- and MUST be compared against the IANA identifiers using a case-
insensitive comparison. If the identifier is not recognised or insensitive comparison. If the identifier is not recognised or
not supported, all strings that are affected by it SHOULD be not supported, all strings that are affected by it SHOULD be
regarded as octet strings. regarded as octet strings.
Note that a character set specified MUST still prohibit the use Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting requiring the use of these characters MUST define a quoting
skipping to change at page 27, line 49 skipping to change at page 27, line 35
indicates the order of importance of the various languages in indicates the order of importance of the various languages in
the session or media from most important to least important. the session or media from most important to least important.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions languages is discouraged. Instead, multiple descriptions
SHOULD be sent describing the session, one in each language. SHOULD be sent describing the session, one in each language.
However this is not possible with all transport mechanisms, and However this is not possible with all transport mechanisms, and
so multiple sdplang attributes are allowed although NOT so multiple sdplang attributes are allowed although NOT
RECOMMENDED. RECOMMENDED.
The "sdplang" attribute value must be a single RFC 1766 The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII. It is not dependent on the charset language tag in US-ASCII [RFC3066]. It is not dependent on the
attribute. An "sdplang" attribute SHOULD be specified when a charset attribute. An "sdplang" attribute SHOULD be specified
session is of sufficient scope to cross geographic boundaries when a session is of sufficient scope to cross geographic
where the language of recipients cannot be assumed, or where boundaries where the language of recipients cannot be assumed,
the session is in a different language from the locally assumed or where the session is in a different language from the
norm. locally assumed norm.
a=lang:<language tag> a=lang:<language tag>
This can be a session level attribute or a media level This can be a session level attribute or a media level
attribute. As a session level attribute, it specifies the attribute. As a session level attribute, it specifies the
default language for the session being described. As a media default language for the session being described. As a media
level attribute, it specifies the language for that media, level attribute, it specifies the language for that media,
overriding any session-level language specified. Multiple lang overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if attributes can be provided either at session or media level if
multiple languages if the session description or media use multiple languages if the session description or media use
multiple languages, in which case the order of the attributes multiple languages, in which case the order of the attributes
indicates the order of importance of the various languages in indicates the order of importance of the various languages in
the session or media from most important to least important. the session or media from most important to least important.
The "lang" attribute value must be a single RFC 1766 language The "lang" attribute value must be a single RFC 3066 language
tag in US-ASCII. It is not dependent on the charset attribute. tag in US-ASCII [RFC3066]. It is not dependent on the charset
A "lang" attribute SHOULD be specified when a session is of attribute. A "lang" attribute SHOULD be specified when a
sufficient scope to cross geographic boundaries where the session is of sufficient scope to cross geographic boundaries
language of recipients cannot be assumed, or where the session where the language of recipients cannot be assumed, or where
is in a different language from the locally assumed norm. the session is in a different language from the locally assumed
norm.
a=framerate:<frame rate> a=framerate:<frame rate>
This gives the maximum video frame rate in frames/sec. It is This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data. intended as a recommendation for the encoding of video data.
Decimal representations of fractional values using the notation Decimal representations of fractional values using the notation
"<integer>.<fraction>" are allowed. It is a media attribute, "<integer>.<fraction>" are allowed. It is a media attribute,
is only defined for video media, and is not dependent on is only defined for video media, and is not dependent on
charset. charset.
skipping to change at page 32, line 8 skipping to change at page 32, line 8
provide separation of global multicast sessions from local ones. provide separation of global multicast sessions from local ones.
Use of the "k=" field poses a significant security risk, since it Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated. over which the SDP is delivered is both private and authenticated.
Appendix A: SDP Grammar Appendix A: SDP Grammar
This appendix provides an Augmented BNF grammar for SDP. ABNF is This appendix provides an Augmented BNF grammar for SDP. ABNF is
defined in RFC 2234. defined in [RFC2234].
; SDP Syntax ; SDP Syntax
announcement = proto-version announcement = proto-version
origin-field origin-field
session-name-field session-name-field
information-field information-field
uri-field uri-field
email-fields email-fields
phone-fields phone-fields
connection-field connection-field
skipping to change at page 34, line 17 skipping to change at page 34, line 17
sess-version = 1*DIGIT sess-version = 1*DIGIT
;0 is a new session ;0 is a new session
nettype = token nettype = token
;typically "IN" ;typically "IN"
addrtype = token addrtype = token
;typically "IP4" or "IP6" ;typically "IP4" or "IP6"
; sub-rules of 'u=' ; sub-rules of 'u='
uri = URI-reference; defined in RFC1630 and RFC2732 uri = URI-reference; see RFC1630 and RFC2732
; sub-rules of 'e=' ; sub-rules of 'e='
email-address = email *SP "(" 1*email-safe ")" / email-address = email *SP "(" 1*email-safe ")" /
1*email-safe "<" email ">" / 1*email-safe "<" email ">" /
email email
email = addr-spec ; defined in RFC2822 email = addr-spec ; defined in RFC2822
; modified to remove CFWS ; modified to remove CFWS
; sub-rules of 'p=' ; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" / phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" / 1*email-safe "<" phone ">" /
phone phone
phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT)
;there must be a space or hyphen between the ;there must be a space or hyphen between
;international code and the rest of the number. ;the international code and the rest of
;the number.
; sub-rules of 'c=' ; sub-rules of 'c='
connection-address = multicast-address / unicast-address connection-address = multicast-address / unicast-address
; sub-rules of 'b=' ; sub-rules of 'b='
bwtype = token bwtype = token
bandwidth = 1*DIGIT bandwidth = 1*DIGIT
; sub-rules of 't=' ; sub-rules of 't='
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
; 10-digit NTP time represents times between ; 10-digit NTP time represents times between
; 1931 and 5068 AD. 9* allows times after that ; 1931 and 5068 AD. 9* allows times after
; as well. ; that as well.
; sub-rules of 'r=' and 'z=' ; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = "d" / "h" / "m" / "s" fixed-len-time-unit = "d" / "h" / "m" / "s"
; sub-rules of 'k=' ; sub-rules of 'k='
key-type = "prompt" / key-type = "prompt" /
skipping to change at page 36, line 22 skipping to change at page 36, line 25
fmt = token fmt = token
;typically an RTP payload type for audio ;typically an RTP payload type for audio
;and video media ;and video media
proto = token "/" token proto = token "/" token
/ token / token
;typically "RTP/AVP" or "udp" for IP4 ;typically "RTP/AVP" or "udp" for IP4
port = 1*DIGIT port = 1*DIGIT
;should be either "0" or in the range "1024" to ;should be either "0" or in the range "1024"
;"65535" inclusive for UDP based media (a value ;to "65535" inclusive for UDP based media
;"0" is used to signal special conditions in some ;(a value of "0" is used to signal special
;uses of SDP) ;conditions in some uses of SDP)
; generic sub-rules: addressing ; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extension-addr unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast multicast-address = IP4-multicast / IP6-multicast
IP4-multicast = m1 3( "." decimal-uchar ) IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ] "/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the ; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255 ; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )) ("23" DIGIT ))
skipping to change at page 37, line 26 skipping to change at page 37, line 39
IP6-address = hexpart [ ":" IP4-address ] IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ] "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
; Generic for other address families ; Generic for other address families
extension-addr = non-ws-string extn-addr = non-ws-string
; generic sub-rules: datatypes ; generic sub-rules: datatypes
text = byte-string text = byte-string
;default is to interpret this as IS0-10646 UTF8 ;default is to interpret this as UTF8 text.
;ISO 8859-1 requires a "a=charset:ISO-8859-1" ;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR or LF ;any byte except NUL, CR or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters ;string of visible characters
token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
; definition from RFC 2045 - ; definition from RFC 2045 -
; "any (US-ASCII) CHAR except SPACE, CTLs, ; "any (US-ASCII) CHAR except SPACE, CTLs,
; or tspecials". ; or tspecials".
; the tspecials are ()<>@,;: ; the tspecials are ()<>@,;:
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
skipping to change at page 39, line 29 skipping to change at page 39, line 39
Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an
unspecified format over TCP; and "udp" indicates an unspecified unspecified format over TCP; and "udp" indicates an unspecified
format over UDP. format over UDP.
New transport protocols MAY be registered with IANA. Registrations New transport protocols MAY be registered with IANA. Registrations
MUST reference an RFC describing the protocol. Such an RFC MAY be MUST reference an RFC describing the protocol. Such an RFC MAY be
Experimental or Informational, although it is preferable if it is Experimental or Informational, although it is preferable if it is
Standards-Track. Registrations MUST also define the rules by which Standards-Track. Registrations MUST also define the rules by which
their "fmt" namespace is managed (see below). their "fmt" namespace is managed (see below).
Application-specific proprietary protocols that run over an
existing transport protocol SHOULD be registered as a "fmt". The
rules for formats (see below) apply to such registrations. An
example is the LBL whiteboard application, which uses the proto
"udp" with "wb" as the format.
"fmt" "fmt"
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats which associated "fmt" namespace that describes the media formats which
may conveyed by that protocol. Formats cover all the possible may conveyed by that protocol. Formats cover all the possible
encodings that might want to be transported in a multimedia encodings that might want to be transported in a multimedia
session. session.
RTP payload formats under the "RTP/AVP" protocol that have been RTP payload formats under the "RTP/AVP" protocol that have been
assigned static payload types MUST use the static payload type as assigned static payload types MUST use the static payload type as
their "fmt" value. For payload formats under "RTP/AVP" that have their "fmt" value. For payload formats under "RTP/AVP" that have
a dynamic payload type number, the dynamic payload type number is a dynamic payload type number, the dynamic payload type number is
given as the "fmt" and an additional "rtpmap" attribute specifies given as the "fmt" and an additional "rtpmap" attribute specifies
the format name and parameters. the format name and parameters as defined by the MIME type
registration for the payload format.
For "TCP" and "udp" protocols, new formats may be registered. If For "TCP" and "udp" protocols, new formats SHOULD be registered.
there is a suitable mapping from a MIME subtype to the format, it Use of an existing MIME subtype for the format is encouraged. If
is RECOMMENDED that the MIME subtype name be used as the "fmt" no MIME subtype exists, it is RECOMMENDED that a suitable one is
name. If there is no suitable mapping from a MIME subtype, a new registered through the IETF process (RFC 2048) by production of,
name should be registered. In either case, a standards-track RFC or reference to, a standards-track RFC. If a MIME subtype is for
MUST be produced describing the format and this RFC MUST be some reason inappropriate, an RFC publication describing the
referenced in the registration. format MUST be referenced in the registration, but it may be
Informational or Experimental if the protocol is not deemed to be
of widespread deployment.
For other protocols, formats MAY be registered according to the For other protocols, formats MAY be registered according to the
rules of the associated "proto" specification. rules of the associated "proto" specification.
Registrations of new formats MUST specify which transport Registrations of new formats MUST specify which transport
protocols they apply to. protocols they apply to.
"att-field" (Attribute names) "att-field" (Attribute names)
Attribute field names MUST be registered with IANA and documented, Attribute field names MUST be registered with IANA and documented,
because of noticeable issues due to conflicting attributes under because of noticeable issues due to conflicting attributes under
the same name. Unknown attributes in SDP are simply ignored, but the same name. Unknown attributes in SDP are simply ignored, but
conflicting ones that fragment the protocol are a serious problem. conflicting ones that fragment the protocol are a serious problem.
New attributes MAY be registered according to the "Specification New attribute registerations are accepted according to the
Required" policy of RFC 2434, provided that the specification "Specification Required" policy of RFC 2434, provided that the
includes the following information: specification includes the following information:
o contact name, email address and telephone number o contact name, email address and telephone number
o attribute-name (as it will appear in SDP) o attribute-name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o type of attribute (session level, media level, or both) o type of attribute (session level, media level, or both)
o whether the attribute value is subject to the charset o whether the attribute value is subject to the charset
skipping to change at page 45, line 42 skipping to change at page 45, line 44
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Normative References Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2234] D. Crocker and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October IANA Considerations Section in RFCs", RFC 2434, October
1998. 1998.
[RFC3066] H. Alvestrand, "Tags for the Identification of Languages",
RFC 3066, January 2001.
Informative References Informative References
[RFC1305] D. Mills, "Network Time Protocol (version 3) specification [RFC1305] D. Mills, "Network Time Protocol (version 3) specification
and implementation", RFC 1305, March 1992. and implementation", RFC 1305, March 1992.
[RFC1889] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, [RFC1889] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996. RFC 1889, January 1996.
[RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 1890, January Conferences with Minimal Control", RFC 1890, January
1996. 1996.
[RFC2974] M. Handley, C. Perkins and E. Whelan, "Session [RFC2974] M. Handley, C. Perkins and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[H.332] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
Receiving Internet-based H.323 Conferences", ITU, Geneva.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session
Initiatation Protocol", RFC 3261, May 2002. Initiatation Protocol", RFC 3261, May 2002.
[RFC2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time [RFC2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time
Streaming Protocol (RTSP)" RFC 2326, April 1998. Streaming Protocol (RTSP)" RFC 2326, April 1998.
[RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model [RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model
with SDP", RFC 3264, May 2002. with SDP", RFC 3264, May 2002.
[RTCPSDP] C. Huitema, "RTCP Attribute in SDP", Work in progress
[H.332] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
Receiving Internet-based H.323 Conferences", ITU, Geneva.
 End of changes. 40 change blocks. 
96 lines changed or deleted 83 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/