Request for Comments: 4566 UCL
Obsoletes: 2327, 3266 V. Jacobson
Category: Standards Track Packet Design
C. Perkins
University of Glasgow
July 2006
SDP: Session Description Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation.
Table of Contents
1. Introduction ....................................................3
2. Glossary of Terms ...............................................3
3. Examples of SDP Usage ...........................................4
3.1. Session Initiation .........................................4
3.2. Streaming Media ............................................4
3.3. Email and the World Wide Web ...............................4
3.4. Multicast Session Announcement .............................4
4. Requirements and Recommendations ................................5
4.1. Media and Transport Information ............................6
4.2. Timing Information .........................................6
4.3. Private Sessions ...........................................7
4.4. Obtaining Further Information about a Session ..............7
4.5. Categorisation .............................................7
4.6. Internationalisation .......................................7
5. SDP Specification ...............................................7
5.1. Protocol Version ("v=") ...................................10
5.2. Origin ("o=") .............................................11
5.3. Session Name ("s=") .......................................12
5.4. Session Information ("i=") ................................12
5.5. URI ("u=") ................................................13
5.6. Email Address and Phone Number ("e=" and "p=") ............13
5.7. Connection Data ("c=") ....................................14
5.8. Bandwidth ("b=") ..........................................16
5.9. Timing ("t=") .............................................17
5.10. Repeat Times ("r=") ......................................18
5.11. Time Zones ("z=") ........................................19
5.12. Encryption Keys ("k=") ...................................19
5.13. Attributes ("a=") ........................................21
5.14. Media Descriptions ("m=") ................................22
6. SDP Attributes .................................................24
7. Security Considerations ........................................31
8. IANA Considerations ............................................33
8.1. The "application/sdp" Media Type ..........................33
8.2. Registration of Parameters ................................34
8.2.1. Media Types ("media") ..............................34
8.2.2. Transport Protocols ("proto") ......................34
8.2.3. Media Formats ("fmt") ..............................35
8.2.4. Attribute Names ("att-field") ......................36
8.2.5. Bandwidth Specifiers ("bwtype") ....................37
8.2.6. Network Types ("nettype") ..........................37
8.2.7. Address Types ("addrtype") .........................38
8.2.8. Registration Procedure .............................38
8.3. Encryption Key Access Methods .............................39
9. SDP Grammar ....................................................39
10. Summary of Changes from RFC 2327 ..............................44
11. Acknowledgements ..............................................45
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................46
1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description
metadata to the participants.
SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a
format for session description -- it does not incorporate a transport
protocol, and it is intended to use different transport protocols as
appropriate, including the Session Announcement Protocol [14],
Session Initiation Protocol [15], Real Time Streaming Protocol [16],
electronic mail using the MIME extensions, and the Hypertext
Transport Protocol.
SDP is intended to be general purpose so that it can be used in a
wide range of network environments and applications. However, it is
not intended to support negotiation of session content or media
encodings: this is viewed as outside the scope of session
description.
This memo obsoletes RFC 2327 [6] and RFC 3266 [10]. Section 10
outlines the changes introduced in this memo.
2. Glossary of Terms
The following terms are used in this document and have specific
meaning within the context of this document.
Conference: A multimedia conference is a set of two or more
communicating users along with the software they are using to
communicate.
Session: A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session.
Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Examples of SDP Usage
3.1. Session Initiation
The Session Initiation Protocol (SIP) [15] is an application-layer
control protocol for creating, modifying, and terminating sessions
such as Internet multimedia conferences, Internet telephone calls,
and multimedia distribution. The SIP messages used to create
sessions carry session descriptions that allow participants to agree
on a set of compatible media types. These session descriptions are
commonly formatted using SDP. When used with SIP, the offer/answer
model [17] provides a limited framework for negotiation using SDP.
3.2. Streaming Media
The Real Time Streaming Protocol (RTSP) [16], is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. An RTSP client and server negotiate an appropriate set of
parameters for media delivery, partially using SDP syntax to describe
those parameters.
3.3. Email and the World Wide Web
Alternative means of conveying session descriptions include
electronic mail and the World Wide Web (WWW). For both email and WWW
distribution, the media type "application/sdp" is used. This enables
the automatic launching of applications for participation in the
session from the WWW client or mail reader in a standard manner.
Note that announcements of multicast sessions made only via email or
the WWW do not have the property that the receiver of a session
announcement can necessarily receive the session because the
multicast sessions may be restricted in scope, and access to the WWW
server or reception of email is possible outside this scope.
3.4. Multicast Session Announcement
In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a
distributed session directory may be used. An instance of such a
session directory periodically sends packets containing a description
of the session to a well-known multicast group. These advertisements
are received by other session directories such that potential remote
participants can use the session description to start the tools
required to participate in the session.
One protocol used to implement such a distributed directory is the
Session Announcement Protocol (SAP) [14]. SDP provides the
recommended session description format for such session
announcements.
4. Requirements and Recommendations
The purpose of SDP is to convey information about media streams in
multimedia sessions to allow the recipients of a session description
to participate in the session. SDP is primarily intended for use in
an internetwork, although it is sufficiently general that it can
describe conferences in other network environments. Media streams
can be many-to-many. Sessions need not be continually active.
Thus far, multicast-based sessions on the Internet have differed from
many other forms of conferencing in that anyone receiving the traffic
can join the session (unless the session traffic is encrypted). In
such an environment, SDP serves two primary purposes. It is a means
to communicate the existence of a session, and it is a means to
convey sufficient information to enable joining and participating in
the session. In a unicast environment, only the latter purpose is
likely to be relevant.
An SDP session description includes the following:
o Session name and purpose
o Time(s) the session is active
o The media comprising the session
o Information needed to receive those media (addresses, ports,
formats, etc.)
As resources necessary to participate in a session may be limited,
some additional information may also be desirable:
o Information about the bandwidth to be used by the session
o Contact information for the person responsible for the session
In general, SDP must convey sufficient information to enable
applications to join a session (with the possible exception of
encryption keys) and to announce the resources to be used to any
non-participants that may need to know. (This latter feature is
primarily useful when SDP is used with a multicast session
announcement protocol.)
4.1. Media and Transport Information
An SDP session description includes the following media information:
o The type of media (video, audio, etc.)
o The transport protocol (RTP/UDP/IP, H.320, etc.)
o The format of the media (H.261 video, MPEG video, etc.)
In addition to media format and transport protocol, SDP conveys
address and port details. For an IP multicast session, these
comprise:
o The multicast group address for media
o The transport port for media
This address and port are the destination address and destination
port of the multicast stream, whether being sent, received, or both.
For unicast IP sessions, the following are conveyed:
o The remote address for media
o The remote transport port for media
The semantics of this address and port depend on the media and
transport protocol defined. By default, this SHOULD be the remote
address and remote port to which data is sent. Some media types may
redefine this behaviour, but this is NOT RECOMMENDED since it
complicates implementations (including middleboxes that must parse
the addresses to open Network Address Translation (NAT) or firewall
pinholes).
4.2. Timing Information
Sessions may be either bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. SDP can
convey:
o An arbitrary list of start and stop times bounding the session
o For each bound, repeat times such as "every Wednesday at 10am for
one hour"
This timing information is globally consistent, irrespective of local
time zone or daylight saving time (see Section 5.9).
4.3. Private Sessions
It is possible to create both public sessions and private sessions.
SDP itself does not distinguish between these; private sessions are
typically conveyed by encrypting the session description during
distribution. The details of how encryption is performed are
dependent on the mechanism used to convey SDP; mechanisms are
currently defined for SDP transported using SAP [14] and SIP [15],
and others may be defined in the future.
If a session announcement is private, it is possible to use that
private announcement to convey encryption keys necessary to decode
each of the media in a conference, including enough information to
know which encryption scheme is used for each media.
4.4. Obtaining Further Information about a Session
A session description should convey enough information to decide
whether or not to participate in a session. SDP may include
additional pointers in the form of Uniform Resource Identifiers
(URIs) for more information about the session.
4.5. Categorisation
When many session descriptions are being distributed by SAP, or any
other advertisement mechanism, it may be desirable to filter session
announcements that are of interest from those that are not. SDP
supports a categorisation mechanism for sessions that is capable of
being automated (the "a=cat:" attribute; see Section 6).
4.6. Internationalisation
The SDP specification recommends the use of the ISO 10646 character
sets in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole.
5. SDP Specification
An SDP session description is denoted by the media type
"application/sdp" (See Section 8).
An SDP session description is entirely textual using the ISO 10646
character set in UTF-8 encoding. SDP field names and attribute names
use only the US-ASCII subset of UTF-8, but textual fields and
attribute values MAY use the full ISO 10646 character set. Field and
attribute values that use the full UTF-8 character set are never
directly compared, hence there is no requirement for UTF-8
normalisation. The textual form, as opposed to a binary encoding
such as ASN.1 or XDR, was chosen to enhance portability, to enable a
variety of transports to be used, and to allow flexible, text-based
toolkits to be used to generate and process session descriptions.
However, since SDP may be used in environments where the maximum
permissible size of a session description is limited, the encoding is
deliberately compact. Also, since announcements may be transported
via very unreliable means or damaged by an intermediate caching
server, the encoding was designed with strict order and formatting
rules so that most errors would result in malformed session
announcements that could be detected easily and discarded. This also
allows rapid discarding of encrypted session announcements for which
a receiver does not have the correct key.
An SDP session description consists of a number of lines of text of
the form:
<type>=<value>
where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In
general, <value> is either a number of fields delimited by a single
space character or a free format string, and is case-significant
unless a specific field defines otherwise. Whitespace MUST NOT be
used on either side of the "=" sign.
An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level
section. Each media-level section starts with an "m=" line and
continues to the next media-level section or end of the whole session
description. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value.
Some lines in each description are REQUIRED and some are OPTIONAL,
but all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*".
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any session
description that contains a type letter that it does not understand.
The attribute mechanism ("a=" described below) is the primary means
for extending SDP and tailoring it to particular applications or
media. Some attributes (the ones listed in Section 6 of this memo)
have a defined meaning, but others may be added on an application-,
media-, or session-specific basis. An SDP parser MUST ignore any
attribute it doesn’t understand.
An SDP session description may contain URIs that reference external
content in the "u=", "k=", and "a=" lines. These URIs may be
dereferenced in some cases, making the session description non-self-
contained.
The connection ("c=") and attribute ("a=") information in the
session-level section applies to all the media of that session unless
overridden by connection information or an attribute of the same name
in the media description. For instance, in the example below, each
media behaves as if it were given a "recvonly" attribute.
An example SDP description is:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline
character. If the "a=charset" attribute is not present, these octet
strings MUST be interpreted as containing ISO-10646 characters in
UTF-8 encoding (the presence of the "a=charset" attribute may force
some fields to be interpreted differently).
A session description can contain domain names in the "o=", "u=",
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [1], [2]. Internationalised domain names (IDNs) MUST be
represented using the ASCII Compatible Encoding (ACE) form defined in
[11] and MUST NOT be directly represented in UTF-8 or any other
encoding (this requirement is for compatibility with RFC 2327 and
other SDP-related standards, which predate the development of
internationalised domain names).
5.1. Protocol Version ("v=")
v=0
The "v=" field gives the version of the Session Description Protocol.
This memo defines version 0. There is no minor version number.
5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
The "o=" field gives the originator of the session (her username and
the address of the user’s host) plus a session identifier and version
number:
<username> is the user’s login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [13].
<sess-version> is a version number for this session description. Its
usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used.
<nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8).
<addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in the future (see Section 8).
<unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either
the fully qualified domain name of the machine or the dotted-
decimal representation of the IP version 4 address of the machine.
For an address type of IP6, this is either the fully qualified
domain name of the machine or the compressed textual
representation of the IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
In general, the "o=" field serves as a globally unique identifier for
this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any
modifications.
For privacy reasons, it is sometimes desirable to obfuscate the
username and IP address of the session originator. If this is a
concern, an arbitrary <username> and private <unicast-address> MAY be
chosen to populate the "o=" field, provided that these are selected
in a manner that does not affect the global uniqueness of the field.