Session Description Protocol

The Session Description Protocol (SDP) is a format for describing streaming media initialization parameters. The IETF published the original specification as an IETF Proposed Standard in April 1998,^[1] and subsequently published a revised specification as an IETF Proposed Standard as RFC 4566 in July 2006.^[2]

SDP is intended for describing multimedia communication sessions for the purposes of session announcement, session invitation, and parameter negotiation. SDP does not deliver media itself but is used for negotiation between end points of media type, format, and all associated properties. The set of properties and parameters are often called a session profile. SDP is designed to be extensible to support new media types and formats.

SDP started off as a component of the Session Announcement Protocol (SAP), but found other uses in conjunction with Real-time Transport Protocol (RTP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP) and even as a standalone format for describing multicast sessions.

Session description

A session is described by a series of fields, one per line.^{[note 1]} The form of each field is as follows.

<character>=<value>

Where <character> is a single case-significant character and value is structured text whose format depends upon attribute type. Values are typically a UTF-8 encoding.^{[note 2]} Whitespace is not allowed immediately to either side of the =.^[3]

Within an SDP message there are three main sections, detailing the session, timing, and media descriptions. Each message may contain multiple timing and media descriptions. Names are only unique within the associated syntactic construct, i.e. within the session, time, or media.^[4]

Optional values are specified with =* and each field must appear in the order shown below.

Session description
    v=  (protocol version number, currently only 0)
    o=  (originator and session identifier : username, id, version number, network address)
    s=  (session name : mandatory with at least one UTF-8-encoded character)
    i=* (session title or short information)
    u=* (URI of description)
    e=* (zero or more email address with optional name of contacts)
    p=* (zero or more phone number with optional name of contacts)
    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 (each one starting by an "m=" line; see below)

Time description (mandatory)
    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 or information field)
    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 — overriding the Session attribute lines)

Here is an example session description (from RFC 4566). This session description is being proposed to a receiving client (with username "jdoe") who was requesting a session from his host located at IPv4 address 10.47.16.5 in order to play a session named "SDP Seminar" (announced separately by the media server) that the SDP server describes as being titled more completely "A Seminar on the session description protocol" (with an available PDF documentation that the client could download separately if needed to get more information). It also contains the description of two non interactive (receive only) medias (audio and video) that are part of this proposed session. The media contents are both available (without any apparent secure access control in this example) on the same media server host (indicated in the Session-level parameters, whose contact name is "Jane Doe" and reachable by his indicated email address), emitting and transporting its two media streams with the RTP protocol over UDP in the basic RTP Audio Video Profile (RTP/AVP), from an IPv4 multicast address 224.2.17.12 (with an IP Multicast Time To Live of up to 127 hops), and using UDP port 49170 for the media data of the audio stream encoded with the RTP/AVP audio format 0 (whose mapping is registered on the IANA registry of standard RTP formats) with its associated UDP port 49171 for its control channel (implicitly added for RTP), and UDP port 51372 for the media data of the video stream (encoded with the server-defined RTP/AVP video format 99, which the SDP server defines and maps as being a "video/h263-1998" media codec) with its associated UDP port 51373 for its control channel (implicitly added for RTP) :

    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

Note that the SDP description just contains the description to user "jdoe" of the medias proposed by the described RTP/AVP media server(s) for his session. However it does not specify how the user (or his user user agent) reached the SDP server in order to get that description. it also does not indicate if (and how) "jdoe" was knowing the session name "SDP Seminar" and where it could locate the SDP server proposing this description (this requires a separate protocol for SDP announcement of available sessions). Also this SDP description does not say if (and how) these medias will be played by jdoe's user agent. At this point, the RTP/AVP media server has still not been reached by the client for these medias.

Also the SDP specifications do not indicate by which transport protocol this SDP description can be delivered to the client. Typically it would be sent by a SAP server in an announcement message, but it could as well be delivered by a web server, or sent as is in an email attachment. In fact, this SDP is not really a protocol but a message format by itself, with its own content type. As this content may be valid for a limited time, the SDP description contains a range of dates of validity during which it should be available, using here a single pair of start and stop times (see the next section about time formats).

Attributes

SDP uses attributes to extend the core protocol. Attributes can appear within the Session or Media sections and are scoped accordingly as session-level or media-level. New attributes are added to the standard occasionally through registration with IANA.^[5]

Attributes take two forms:

• A property form: a=flag conveys a simple boolean property of the media or session.
• A value form: a=attribute:value provides a named parameter.

Two of these attributes are specially defined:

• a=charset:encoding
• a=sdplang:code

The first one is used in the Session or Media sections to specify another character encoding (as registered in the IANA registry^[6]) than the default one highly recommended (UTF-8) where it is used in standard protocol keys whose values are containing a text intended to be displayed to a user. The second one is used to specify in which language it is written (alternate texts in multiple languages may be carried in the protocol, and selected automatically by the user agent according to user preferences. In both cases, each textual field in the protocol which are not interpreted symbolically by the protocol itself, will be interpreted as opaque strings, but rendered to the user or application with the values indicated in the last occurrence of the charset and sdplang in the current Media section, or otherwise their last value in the Session section).

Note that the first 3 mandatory parameters (v=, s= and o=), even though they seem to contain displayable text, are not intended to be displayed to users and translated. The fields present in their values are considered in the protocol as opaque strings, they are used as identifiers, just like paths in an URL or filenames in a file system: the SDP standard indicates that they must all non empty and should be UTF-8 encoded.

A few other attributes (described as part the standard SDP specifications in the same RFC) are also shown in the example above, either as a session-level attribute (such as the attribute in property form a=recvonly) which also applies to the described medias unless they override their value, or as a media-level attribute (such as the attribute in value form a=rtpmap:99 h263-1998/90000 for the video media in the example).

Time formats and repetitions

Absolute times are represented in Network Time Protocol (NTP) format (the number of seconds since 1900). If the stop time is 0 then the session is "unbounded." If the start time is also zero then the session is considered "permanent." Unbounded and permanent sessions are discouraged but not prohibited. Intervals can be represented with Network Time Protocol times or in typed time: a value and time units (days ('d'), hours ('h'), minutes ('m') and seconds ('s')) sequence.

Thus an hour meeting from 10am UTC on 1 August 2010, with a single repeat time a week later at the same time can be represented as:

        t=1280656800 1281265200
        r=604800 3600 0

Or using typed time:

        t=1280656800 1281265200
        r=7d 1h 0

When repeat times are specified, the start time of each repetition may need to be adjusted so that it will occur at the same local time in a specific timezone throughout the period between the start time and the stop time (which are still specified in NTP format in an absolute UTC timezone.

Instead of specifying this timezone and having to support a database of timezones for knowing when and where daylight adjustments will be needed, the repeat times are assumed to be all defined within the same timezone, and SDP supports the indication of NTP absolute times when a daylight offset (expressed in seconds or using a type time) will need to be applied to the repeated start time or end time falling at or after each daylight adjustment. All these offsets are relative to the start time, they are not cumulative. NTP supports this with the z= field which indicates a series of pairs, whose first item is the NTP absolute time when a daylight adjustment will occur, and the second item indicates the offset to apply relative to the absolute times computed with the r= field.

For example, if a daylight adjustment will substract 1 hour on 31 October 2010 at 03am UTC (i.e. 60 days minus 7 hours after the start time on Sunday 1 August 2010 at 10am UTC), and this will be the only daylight adjustment to apply in the scheduled period which would occur between 1 August 2010 up to the 28 November 2010 at 10am UTC (the stop time of the repeated 1h session which is repeated each week at the same local time, which occurs 88 days later), this can be specified as:

        t=1280656800 1290938400
        r=7d 1h 0
        z=1288494000 -1h

If the weekly 1-hour session was repeated every Sunday for full one year, i.e. from Sunday 1 August 2010 03am UTC to Sunday 26 June 2011 04am UTC (stop time of the last repeat, i.e. 360 days plus 1 hour later, or 31107600 seconds later), so that it would include the transition back to Summer time on Sunday 27 March 2011 at 02am (1 hour is added again to local time, so that the second daylight transition would occur 209 days after the first start time):

        t=1280656800 1290938400
        r=7d 1h 0
        z=1288494000 -1h 1269655200 0

As SDP announcements for repeated sessions should not be made to cover very long periods exceeding a few years, the number of daylight adjustments to include in the z= parameter should remain small.

Note also that sessions may be repeated irregularly over a week but scheduled the same way for all weeks in the period, by adding more tuples in the r parameter. For example to schedule the same event also on Saturday (at the same time of the day) you would use :

        t=1280656800 1290938400
        r=7d 1h 0 6d
        z=1288494000 -1h 1269655200 0

The SDP protocol does not support repeating sessions monthly and yearly schedules with such simple repeat times, because they are irregularly spaced in time; instead, additional t/r tuples may be supplied for each month or year.

Notes

References

External links

• Rosenberg, J.; Schulzrinne, H. (June 2002). "An Offer/Answer Model with the Session Description Protocol(RFC 3264)". IETF. Retrieved 2010-07-25.  Cite uses deprecated parameters (help)