draft-ietf-mmusic-sdp-new-20.txt   draft-ietf-mmusic-sdp-new-21.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 2327, 3266 (if V. Jacobson Obsoletes: 2327, 3266 (if V. Jacobson
approved) Packet Design approved) Packet Design
Expires: March 20, 2005 C. Perkins Expires: April 25, 2005 C. Perkins
University of Glasgow University of Glasgow
September 19, 2004 October 25, 2004
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-20.txt draft-ietf-mmusic-sdp-new-21.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material 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.
This Internet-Draft will expire on March 20, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
8.1 The "application/sdp" media type . . . . . . . . . . . . . 31 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32
8.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33
8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42
9.2 Informative References . . . . . . . . . . . . . . . . . . . 42 9.2 Informative References . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . 46
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
skipping to change at page 6, line 26 skipping to change at page 6, line 26
o The transport port for media o The transport port for media
This address and port are the destination address and destination This address and port are the destination address and destination
port of the multicast stream, whether being sent, received, or both. port of the multicast stream, whether being sent, received, or both.
For unicast IP sessions, the following are conveyed: For unicast IP sessions, the following are conveyed:
o The remote address for media o The remote address for media
o The transport port for media o The remote transport port for media
The semantics of this address and port depend on the media and The semantics of this address and port depend on the media and
transport protocol defined. By default, this SHOULD be the remote transport protocol defined. By default, this SHOULD be the remote
address and remote port to which data is sent. Some media types MAY address and remote port to which data is sent. Some media types MAY
redefine this behaviour, but this is NOT RECOMMENDED. redefine this behaviour, but this is NOT RECOMMENDED.
4.2 Timing Information 4.2 Timing Information
Sessions may either be bounded or unbounded in time. Whether or not Sessions may either be bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. SDP can they are bounded, they may be only active at specific times. SDP can
skipping to change at page 9, line 7 skipping to change at page 9, line 7
description. In general, session-level values are the default for description. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value. all media unless overridden by an equivalent media-level value.
Some lines in each description are REQUIRED and some are OPTIONAL but Some lines in each description are REQUIRED and some are OPTIONAL but
all MUST appear in exactly the order given here (the fixed order all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser). greatly enhances error detection and allows for a simple parser).
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 c=* (connection information - not required if included in
all media) all media)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines, see below) One or more time descriptions ("t=" and "r=" lines, 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 Zero or more media descriptions
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, if present
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 c=* (connection information - optional if included at
session-level) session-level)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
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 session extensible -- an SDP parser MUST completely ignore any session
skipping to change at page 10, line 19 skipping to change at page 10, line 19
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31 m=video 51372 RTP/AVP 99
m=application 32416 udp wb a=rtpmap:99 h263-1998/90000
a=orient:portrait
Text fields such as the session name and information are octet Text fields such as the session name and information are octet
strings which may contain any octet with the exceptions of 0x00 strings which may contain any octet with the exceptions of 0x00
(Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The
sequence CRLF (0x0d0a) is used to end a record, although parsers sequence CRLF (0x0d0a) is used to end a record, although parsers
SHOULD be tolerant and also accept records terminated with a single SHOULD be tolerant and also accept records terminated with a single
newline character. If the "a=charset" attribute is not present, newline character. If the "a=charset" attribute is not present,
these octet strings MUST be interpreted as containing ISO-10646 these octet strings MUST be interpreted as containing ISO-10646
characters in UTF-8 encoding (the presence of the "a=charset" characters in UTF-8 encoding (the presence of the "a=charset"
attribute MAY force some fields to be interpreted differently). attribute MAY force some fields to be interpreted differently).
skipping to change at page 12, line 14 skipping to change at page 12, line 10
be empty and SHOULD contain ISO 10646 characters (but see also the be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the "a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e. a single space as the session value "s= " SHOULD be used (i.e. a single space as the session
name). name).
5.4 Session Information ("i=") 5.4 Session Information ("i=")
i=<session description> i=<session description>
The "i=" field provides textual information about the session. There The "i=" field provides textual information about the session. There
may be at most one session-level "i=" field per session description, MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field. is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST If the "a=charset" attribute is not present, the "i=" field MUST
contain ISO 10646 characters in UTF-8 encoding. contain ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In A single "i=" field MAY 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 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 single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
skipping to change at page 12, line 37 skipping to change at page 12, line 33
The "i=" field is intended to provide a free-form human readable The "i=" field is intended to provide a free-form human readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5 URI ("u=") 5.5 URI ("u=")
u=<uri> u=<uri>
A URI is a Universal Resource Identifier as used by WWW clients [4], A URI is a Universal Resource Identifier as used by WWW clients [4],
[6]. The URI should be a pointer to additional information about the [6]. The URI should be a pointer to additional information about the
conference. This field is OPTIONAL, but if it is present it MUST be session. This field is OPTIONAL, but if it is present it MUST be
specified before the first media field. No more than one URI field specified before the first media field. No more than one URI field
is allowed per session description. is allowed per session description.
5.6 Email Address and Phone Number ("e=" and "p=") 5.6 Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" and "p=" lines specify contact information for the person The "e=" and "p=" lines specify contact information for the person
responsible for the conference. This is not necessarily the same responsible for the conference. This is not necessarily the same
skipping to change at page 14, line 4 skipping to change at page 13, line 47
It MAY contain a single session-level "c=" field and additional "c=" It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values field(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially "IN" is defined to text string giving the type of network. Initially "IN" is defined to
have the meaning "Internet", but other values MAY be registered in have the meaning "Internet", but other values MAY be registered in
the future (see Section 8). the future (see Section 8).
The second sub-field ("<addrtype>") is the address type. This allows The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. Currently only SDP to be used for sessions that are not IP based. This memo only
IP4 and IP6 are defined, but other values MAY be registered in the defines IP4 and IP6, but other values MAY be registered in the future
future (see Section 8). (see Section 8).
The third sub-field ("<connection-address>") is the connection The third sub-field ("<connection-address>") is the connection
address. OPTIONAL sub-fields MAY be added after the connection address. OPTIONAL sub-fields MAY be added after the connection
address depending on the value of the <addrtype> field. address depending on the value of the <addrtype> field.
When the <addrtype> is IP4 and IP6, the connection address is defined When the <addrtype> is IP4 and IP6, the connection address is defined
as follows: as follows:
o If the session is multicast, the connection address will be an IP o If the session is multicast, the connection address will be an IP
multicast group address. If the session is not multicast, then multicast group address. If the session is not multicast, then
the connection address contains the unicast IP address of the the connection address contains the unicast IP address of the
expected data source or data relay or data sink as determined by expected data source or data relay or data sink as determined by
additional attribute fields. It is not expected that unicast additional attribute fields. It is not expected that unicast
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited. prohibited.
o Conferences using an IPv4 multicast connection address MUST also o Sessions using an IPv4 multicast connection address MUST also have
have a time to live (TTL) value present in addition to the a time to live (TTL) value present in addition to the multicast
multicast address. The TTL and the address together define the address. The TTL and the address together define the scope with
scope with which multicast packets sent in this conference will be which multicast packets sent in this conference will be sent. TTL
sent. TTL values MUST be in the range 0-255. values MUST be in the range 0-255. While the TTL MUST be
specified, its use to scope multicast traffic is deprecated;
applications SHOULD use an adminstratively scoped address instead.
The TTL for the session is appended to the address using a slash as a The TTL for the session is appended to the address using a slash as a
separator. An example is: separator. An example is:
c=IN IP4 224.2.36.42/127 c=IN IP4 224.2.36.42/127
IPv6 multicast does not use TTL scoping, and hence the TTL value MUST IPv6 multicast does not use TTL scoping, and hence the TTL value MUST
NOT be present for IPv6 multicast. It is expected that IPv6 scoped NOT be present for IPv6 multicast. It is expected that IPv6 scoped
addresses will be used to limit the scope of conferences. addresses will be used to limit the scope of conferences.
skipping to change at page 15, line 51 skipping to change at page 15, line 48
This OPTIONAL field denotes the proposed bandwidth to be used by the This OPTIONAL field denotes the proposed bandwidth to be used by the
session or media. The <bwtype> is an alphanumeric modifier giving session or media. The <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure. Two values are defined in the meaning of the <bandwidth> figure. Two values are defined in
this specification, but other values MAY be registered in future (see this specification, but other values MAY be registered in future (see
Section 8 and [22], [16]): Section 8 and [22], [16]):
CT If the bandwidth of a session or media in a session is different CT If the bandwidth of a session or media in a session is different
from the bandwidth implicit from the scope, a "b=CT:..." line from the bandwidth implicit from the scope, a "b=CT:..." line
SHOULD be supplied for the session giving the proposed upper limit SHOULD be supplied for the session giving the proposed upper limit
to the bandwidth used. The primary purpose of this is to give an to the bandwidth used (the "conference total" bandwidth). The
approximate idea as to whether two or more sessions can co-exist primary purpose of this is to give an approximate idea as to
simultaneously. When using the CT modifier with RTP, if several whether two or more sessions can co-exist simultaneously. When
RTP sessions are part of the conference, the conference total using the CT modifier with RTP, if several RTP sessions are part
refers to total bandwidth of all RTP sessions. of the conference, the conference total refers to total bandwidth
of all RTP sessions.
AS The bandwidth is interpreted to be application-specific (it will AS The bandwidth is interpreted to be application-specific (it will
be the application's concept of maximum bandwidth). Normally this be the application's concept of maximum bandwidth). Normally this
will coincide with what is set on the application's "maximum will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP based applications, AS bandwidth" control if applicable. For RTP based applications, AS
gives the RTP "session bandwidth" as defined in section 6.2 of gives the RTP "session bandwidth" as defined in section 6.2 of
[14]. [14].
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
skipping to change at page 16, line 30 skipping to change at page 16, line 28
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
SHOULD be registered with IANA in the standard namespace. SDP SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown modifiers. parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers MUST 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.
The <bandwidth> is in kilobits per second by default. Modifiers MAY The <bandwidth> is interpreted as kilobits per second by default.
specify that alternative units are to be used (the modifiers defined The definition of a new <bwtype> modifier MAY specify that the
in this memo use the default units). bandwidth is to be interpreted in some alternative unit (the "CT" and
"AS" modifiers defined in this memo use the default units).
5.9 Timing ("t=") 5.9 Timing ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" lines specifies an irregularly spaced times; each additional "t=" lines specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular times, an "r=" line (see below) the session is active at regular times, an "r=" line (see below)
skipping to change at page 17, line 24 skipping to change at page 17, line 22
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 modified other than this is required, an end-time SHOULD be given and modified
as appropriate when new information becomes available about when the as appropriate when new information becomes available about when the
session should really end. 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.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
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 The key field MUST NOT be used unless it can be guaranteed that the
SDP is conveyed over a secure and trusted channel. An example of SDP is conveyed over a secure and trusted channel. An example of
such a channel might be SDP embedded inside an S/MIME message or a such a channel might be SDP embedded inside an S/MIME message or a
TLS protected HTTP or SIP session. It is important to ensure that TLS-protected HTTP session. It is important to ensure that the
the secure channel is with the party that is authorized to join the secure channel is with the party that is authorized to join the
session, not an intermediary: if a caching proxy server is used, it session, not an intermediary: if a caching proxy server is used, it
is important to ensure that the proxy is either trusted or unable to is important to ensure that the proxy is either trusted or unable to
access the SDP. Definition of appropriate security measures is access the SDP. Definition of appropriate security measures is
beyond the scope of this specification, and should be defined by the beyond the scope of this specification, and should be defined by the
users of SDP. users of SDP.
5.13 Attributes ("a=") 5.13 Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. attributes, or both.
A media description may have any number of attributes ("a=" fields) A media description may have any number of attributes ("a=" fields)
which are media specific. These are referred to as "media-level" which are media specific. These are referred to as "media-level"
attributes and add information about the media stream. Attribute attributes and add information about the media stream. Attribute
fields can also be added before the first media field; these fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies "session-level" attributes convey additional information that applies
to the conference as a whole rather than to individual media; an to the conference as a whole rather than to individual media.
example might be the conference's floor control policy.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o A property attribute is simply of the form "a=<flag>". These are o A property attribute is simply of the form "a=<flag>". These are
binary attributes, and the presence of the attribute conveys that binary attributes, and the presence of the attribute conveys that
the attribute is a property of the session. An example might be the attribute is a property of the session. An example might be
"a=recvonly". "a=recvonly".
o A value attribute is of the form "a=<attribute>:<value>". For o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute example, a whiteboard could have the value attribute
skipping to change at page 21, line 28 skipping to change at page 21, line 28
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
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, attribute except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
values are to be interpreted as in ISO-10646 character set with UTF-8 values are to be interpreted as in ISO-10646 character set with UTF-8
encoding. Unlike other text fields, attribute values are NOT encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset-dependent, in attribute is defined, it can be defined to be charset-dependent, in
which case it's value should be interpreted in the session charset which case its value should be interpreted in the session charset
rather than in ISO-10646. rather than in ISO-10646.
Attributes MUST be registered with IANA (see Section 8). If an Attributes MUST be registered with IANA (see Section 8). If an
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
5.14 Media Descriptions ("m=") 5.14 Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
skipping to change at page 22, line 39 skipping to change at page 22, line 39
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.
The combination of ports specified in "m=" lines and IP addresses
specified in "c=" lines MUST comply with the following rules for
RTP-based media streams (other protocols SHOULD define similar
rules):
1. If two media sessions have the same transport address (i.e.
identical IP address and port numbers), the associated payload
types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be
in conflict, i.e. the same payload type MUST NOT be mapped to
different media types.
2. If two media sessions have the same transport address, they
MUST use compatible media (e.g. both audio or both video).
3. If two media sessions have the same transport address, they
SHOULD operate under the same RTP profile. The sessions MAY
use two different RTP profiles only if those profiles are
specifically designed to be compatible.
4. If two media sessions have the same RTP transport address,
they MUST also use the same RTCP address and vice versa.
Two media sessions with the same transport address indicate
alternatives for the same media stream, i.e. all profiles, media
types, and payload types provided in any of the "m=" lines are
valid.
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant protocol is dependent on the address type field in the relevant
"c=" field. Thus a "c=" field of IP4 indicates that the transport "c=" field. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols defined, but may be extended through registration of new protocols
with IANA (see Section 8): with IANA (see Section 8):
* udp: denotes an unspecified protocol running over UDP. * udp: denotes an unspecified protocol running over UDP.
* RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio
and Video Conferences with Minimal Control [15] running over and Video Conferences with Minimal Control [15] running over
UDP. UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18]
running over UDP. running over UDP.
The main reason to specify the transport-protocol in addition to The main reason to specify the transport-protocol in addition to
the media format is that the same standard media formats may be the media format is that the same standard media formats may be
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same - a historical example is vat PCM audio and protocol is the same - a historical example is vat PCM audio and
RTP PCM audio. In addition, relays and monitoring tools that are RTP PCM audio, another might be TCP/RTP PCM audio. In addition,
transport-protocol-specific but format-independent are possible. relays and monitoring tools that are transport-protocol-specific
but format-independent are possible.
<fmt> is a media format description. The fourth and any subsequent <fmt> is a media format description. The fourth and any subsequent
sub-fields describe the format of the media. The interpretation sub-fields describe the format of the media. The interpretation
of the media format depends on the value of the <proto> sub-field. of the media format depends on the value of the <proto> sub-field.
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
sub-fields contain RTP payload type numbers. When a list of sub-fields contain RTP payload type numbers. When a list of
payload type numbers is given, this implies that all of these payload type numbers is given, this implies that all of these
payload formats MAY be used in the session, but the first of these payload formats MAY be used in the session, but the first of these
formats SHOULD be used as the default format for the session. For formats SHOULD be used as the default format for the session. For
dynamic payload type assignments the "a=rtpmap:" attribute (see dynamic payload type assignments the "a=rtpmap:" attribute (see
Section 6) SHOULD be used to map from an RTP payload type number Section 6) SHOULD be used to map from an RTP payload type number
to a media encoding name that identifies the payload format. The to a media encoding name that identifies the payload format. The
"a=fmtp:" attribute MAY be used to specify format parameters (see "a=fmtp:" attribute MAY be used to specify format parameters (see
Section 6). Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio", reference a media type describing the format under the "audio",
"text" and "video" top-level MIME types. The media type "video", "text" and "application" top-level MIME types. The media
registration SHOULD define the packetization format for use with type registration SHOULD define the packetization format for use
UDP transport. with UDP transport.
For media using other transport protocols, the <fmt> field is For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> protocol specific. Rules for interpretation of the <fmt>
sub-field MUST be defined when registering new protocols (see sub-field MUST be defined when registering new protocols (see
section 8.2.2). section 8.2.2).
6. Suggested Attributes 6. SDP Attributes
The following attributes are defined. Since application writers may The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive. add new attributes as they are required, this list is not exhaustive.
Registration procedures for new attributes are defined in Section Registration procedures for new attributes are defined in Section
8.2.4. 8.2.4.
a=cat:<category> a=cat:<category>
This attribute gives the dot-separated hierarchical category This attribute gives the dot-separated hierarchical category
of the session. This is to enable a receiver to filter of the session. This is to enable a receiver to filter
skipping to change at page 24, line 39 skipping to change at page 25, line 21
sense. It should not be necessary to know ptime to decode RTP sense. It should not be necessary to know ptime to decode RTP
or vat audio, and it is intended as a recommendation for the or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media attribute, and encoding/packetisation of audio. It is a media attribute, and
is not dependent on charset. is not dependent on charset.
a=maxptime:<maximum packet time> a=maxptime:<maximum packet time>
The maximum amount of media which can be encapsulated in each The maximum amount of media which can be encapsulated in each
packet, expressed as time in milliseconds. The time SHALL be packet, expressed as time in milliseconds. The time SHALL be
calculated as the sum of the time the media present in the calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the frame packet represents. For frame based codecs, the time SHOULD
size. This attribute is probably only meaningful for audio be an integer multiple of the frame size. This attribute is
data, but may be used with other media types if it makes probably only meaningful for audio data, but may be used with
sense. It is a media attribute, and is not dependent on other media types if it makes sense. It is a media attribute,
charset. Note that this attribute was introduced after RFC and is not dependent on charset. Note that this attribute was
2327, and non updated implementations will ignore this introduced after RFC 2327, and non updated implementations will
attribute. ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate> a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>] [/<encoding parameters>]
This attribute maps from an RTP payload type number (as used in This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and to be used. It also provides information on the clock rate and
encoding parameters. It is a media level attribute that is not encoding parameters. It is a media level attribute that is not
dependent on charset. dependent on charset.
skipping to change at page 26, line 43 skipping to change at page 27, line 23
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
to be used for a traffic destination than for a traffic to be used for a traffic destination than for a traffic
source. In such a case, two media descriptions may be use, source. In such a case, two media descriptions may be used,
one sendonly and one recvonly. It can be either a session or one sendonly and one recvonly. It can be either a session or
media attribute, but would normally only be used as a media media attribute, but would normally only be used as a media
attribute, and is not dependent on charset. Note that sendonly attribute. It is not dependent on charset. Note that sendonly
applies only to the media, and any associated control protocol applies only to the media, and any associated control protocol
(e.g. RTCP) SHOULD still be received and processed as normal. (e.g. RTCP) SHOULD still be received and processed as normal.
a=inactive a=inactive
This specifies that the tools should be started in inactive This specifies that the tools should be started in inactive
mode. This is necessary for interactive conferences where mode. This is necessary for interactive conferences where
users can put other users on hold. No media is sent over an users can put other users on hold. No media is sent over an
inactive media stream. Note that an RTP based system SHOULD inactive media stream. Note that an RTP based system SHOULD
still send RTCP, even if started inactive. It can be either a still send RTCP, even if started inactive. 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.
a=orient:<whiteboard orientation> a=orient:<orientation>
Normally this is only used in a whiteboard media specification. Normally this is only used for a whiteboard or presentation
It specifies the orientation of a the whiteboard on the screen. tool. It specifies the orientation of a the workspace on
It is a media attribute. Permitted values are "portrait", the screen. It is a media attribute. Permitted values are
"landscape" and "seascape" (upside down landscape). It is not "portrait", "landscape" and "seascape" (upside down landscape).
dependent on charset. It is not dependent on charset.
a=type:<conference type> a=type:<conference type>
This specifies the type of the conference. Suggested values This specifies the type of the conference. Suggested values
are "broadcast", "meeting", "moderated", "test" and "H332". are "broadcast", "meeting", "moderated", "test" and "H332".
"recvonly" should be the default for "type:broadcast" "recvonly" should be the default for "type:broadcast"
sessions, "type:meeting" should imply "sendrecv" and sessions, "type:meeting" should imply "sendrecv" and
"type:moderated" should indicate the use of a floor control "type:moderated" should indicate the use of a floor control
tool and that the media tools are started so as to mute new tool and that the media tools are started so as to mute new
sites joining the conference. sites joining the conference.
skipping to change at page 30, line 11 skipping to change at page 30, line 41
formats specified for the media. Format-specific parameters formats specified for the media. Format-specific parameters
may be any set of parameters required to be conveyed by SDP may be any set of parameters required to be conveyed by SDP
and given unchanged to the media tool that will use this and given unchanged to the media tool that will use this
format. At most one instance of this attribute is allowed format. At most one instance of this attribute is allowed
for each format. for each format.
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
7. Security Considerations 7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [10]
using the offer/answer model [12] to agree parameters for unicast
sessions. When used in this manner, the security considerations of
those protocols apply.
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. A session description SHOULD NOT be trusted unless it has sessions. A session description SHOULD NOT be trusted unless it has
been obtained by an authenticated transport protocol from a trusted been obtained by an authenticated transport protocol from a trusted
source. Many different transport protocols may be used to distribute source. Many different transport protocols may be used to distribute
session description, and the nature of the authentication will differ session description, and the nature of the authentication will differ
from transport to transport. from 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 descriptions is the Session Announcement Protocol (SAP). SAP
provides both encryption and authentication mechanisms but due to the provides both encryption and authentication mechanisms but due to the
skipping to change at page 31, line 10 skipping to change at page 31, line 44
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
joining this session will result in the automatic transmission of joining this session will result in the automatic transmission of
multimedia data. The default behaviour for an unknown attribute is multimedia data. The default behaviour for an unknown attribute is
to ignore it. to ignore it.
Session descriptions may be parsed at intermediate systems such as Session descriptions may be parsed at intermediate systems such as
firewalls for the purposes of opening a hole in the firewall to allow firewalls for the purposes of opening a hole in the firewall to allow
the participation in multimedia sessions. It is considered participation in multimedia sessions. This SHOULD NOT be done unless
inappropriate for a firewall to open such holes for unicast data the SDP is conveyed in a manner that allows proper authentication and
streams unless the session description comes in a request from inside authorization checks to ensure that firewall holes are only opened in
the firewall. For multicast sessions, it is likely that local accordance with applicable security policy. SDP by itself does not
administrators will apply their own policies, but the exclusive use include sufficient information to enable these checks: they depend on
of "local" or "site-local" administrative scope within the firewall the encapsulating protocol (e.g. SIP or RTSP).
and the refusal of the firewall to open a hole for such scopes will
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.
8. IANA Considerations 8. IANA Considerations
8.1 The "application/sdp" media type 8.1 The "application/sdp" media type
skipping to change at page 38, line 37 skipping to change at page 39, line 10
; sub-rules of 'o=' ; sub-rules of 'o='
username = non-ws-string username = non-ws-string
;pretty wide definition, but doesn't ;pretty wide definition, but doesn't
;include space ;include space
sess-id = 1*DIGIT sess-id = 1*DIGIT
;should be unique for this username/host ;should be unique for this username/host
sess-version = 1*DIGIT sess-version = 1*DIGIT
;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 uri = URI-reference
; see RFC2396 and RFC2732 ; see RFC2396 and RFC2732
skipping to change at page 40, line 27 skipping to change at page 40, line 47
;"application" ;"application"
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)
;typically "RTP/AVP" or "udp" ;typically "RTP/AVP" or "udp"
port = 1*DIGIT port = 1*DIGIT
;should be either "0" or in the range "1024"
;to "65535" inclusive for UDP based media
;(a value of "0" is used to signal special
;conditions in some uses of SDP)
; generic sub-rules: addressing ; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / extn-addr multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
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 )
IP6-multicast = hexpart [ "/" integer ] IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF ; IPv6 address starting with FF
ttl = (POS-DIGIT *2DIGIT) / "0" ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".") FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified ; fully qualified domain name as specified
; in RFC1035 ; in RFC1035 (and updates)
IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar b1 = decimal-uchar
; less than "224"; not "0" or "127" ; less than "224"
; The following is from RFC2373 Appendix B. It is a direct copy. ; The following is from RFC2373 Appendix B. It is a direct copy.
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
 End of changes. 39 change blocks. 
79 lines changed or deleted 108 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/