Session Description Protocol
| Company type | Internet protocol |
|---|---|
| Industry | Telecommunications, Streaming media |
| Founded | 1998 |
| Headquarters | Internet Engineering Task Force (IETF) |
| Products | Multimedia session description format |
The Session Description Protocol (SDP) serves as a standardized format for detailing multimedia communication sessions, enabling efficient announcement and invitation processes. Its main application lies in supporting streaming media technologies such as voice over IP (VoIP) and video conferencing. Although SDP does not carry media streams itself, it facilitates negotiation between endpoints regarding network parameters, media formats, and associated characteristics, collectively referred to as a session profile.
Designed with extensibility in mind, SDP can incorporate emerging media types and standards. Originally developed as part of the Session Announcement Protocol (SAP), it is extensively utilized alongside protocols like the Real-time Transport Protocol (RTP), Real-time Streaming Protocol (RTSP), and Session Initiation Protocol (SIP), as well as independently for defining multicast sessions.
The initial SDP specification was released by the IETF as a Proposed Standard in 1998 (RFC 2327), followed by updates in 2006 (RFC 4566) and most recently in 2021 (RFC 8866).
Session description
SDP employs a text-based structure to represent session details, formatted with one field per line:
<character>=<value><CR><LF>
Here, <character> is a single case-sensitive letter, and <value> consists of structured text, generally encoded in UTF-8. No spaces are permitted immediately adjacent to the equal sign.
A session description is divided into three main parts: session information, timing details, and media descriptions. Multiple timing and media sections may be included. The sequence of fields is fixed; optional fields are indicated by an asterisk:
- Session description
v= (protocol version number; currently set to 0)
o= (originator and session identifier: username, session id, version number, network address)
s= (session name; required UTF-8 string)
i=* (session title or brief information)
u=* (URI pointing to the description)
e=* (email contacts)
p=* (phone contact details)
c=* (connection information—optional if present in all media sections)
b=* (bandwidth specification lines)
One or more time descriptions ("t=" and "r=" lines)
z=* (time zone adjustments)
k=* (encryption key data)
a=* (session-level attribute lines)
Zero or more media descriptions beginning with "m=" lines
- Time description (required)
t= (active duration of the session)
r=* (repeat intervals)
- Media description (optional)
m= (media type and transport address)
i=* (media title or additional info)
c=* (connection details—optional if defined at session level)
b=* (bandwidth information)
k=* (encryption key information)
a=* (media-specific attribute lines that override session attributes)
An example from RFC 4566 demonstrates SDP's practical application in business contexts: it outlines an audio/video seminar organized by user "jdoe" with an IPv4 address of 10.47.16.5. The description includes contact details, a two-hour schedule, multicast connection parameters, and two media streams—audio on port 49170 using RTP/AVP payload type 0, and video on port 51372 employing dynamic payload type 99 mapped to the h263-1998 codec.
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
SDP acts exclusively as a format for describing sessions and is distributed through multiple transport mechanisms including SAP, SIP, and RTSP. Additionally, it can be conveyed via email or embedded within HTTP payloads.
Attributes
SDP enhances its fundamental protocol by incorporating attributes, which are found within either Session or Media sections as session-level or media-level elements. Occasionally, new attributes are introduced through IANA registration.
Attributes fall into two categories: properties or values:
- Property: a=flag represents a Boolean characteristic related to the media or session.
- Value: a=attribute:value conveys a named parameter.
Among the essential attributes are:
- a=charset:encoding defines the character encoding (registered with IANA) used for user-visible text when it differs from the default UTF-8.
- a=sdplang:code specifies the language of the textual content, enabling support for multiple languages selectable by user agents.
For display purposes, text fields apply the most recent occurrence of charset and sdplang found within the current media or session section.
The parameters v, s, and o are mandatory, must contain non-empty values, and are required to be UTF-8 encoded. These serve as identifiers rather than for direct presentation to users.
Additional attributes include session-level flags such as a=recvonly and media-level value attributes like a=rtpmap:99 h263-1998/90000, which describe specific media characteristics.
Time formats and repetitions
Absolute time values utilize the Network Time Protocol (NTP) format, representing seconds elapsed since 1900. A stop time set to 0 indicates an unbounded session; if both start and stop times are zero, the session is considered permanent. While these configurations are permitted, their use is generally discouraged.
Time intervals may be expressed either as NTP timestamps or using typed units—days (d), hours (h), minutes (m), and seconds (s). For instance, a one-hour meeting beginning at 10 am UTC on August 1, 2010, recurring weekly, can be denoted as:
t=
r=7d 1h 0
Repeat intervals automatically adjust for daylight saving time changes to preserve consistent local timing. Instead of specifying explicit time zones, SDP employs the z field to represent daylight saving adjustments through pairs of NTP absolute times and offsets relative to the session start.
As an example, a weekly one-hour session running from August 1 to November 28, 2010, with a daylight saving rollback of one hour on October 31, 2010 at 3 am UTC is described by:
t=
r=7d 1h 0
z= -1h
For an entire year that includes both daylight saving changes—such as adding one hour on March 27, 2011—the configuration would be:
t=
r=7d 1h 0
z= -1h 0
SDP announcements are advised not to span durations longer than several years; consequently, the number of daylight saving entries in the z= parameter remains minimal.
To accommodate irregular weekly schedules, multiple tuples can be included in the r= parameter. For example, scheduling events simultaneously on Sunday and Saturday involves:
t=
r=7d 1h 0 6d
z= -1h 0
Due to inconsistent intervals, monthly and yearly repetitions cannot be represented with simple repeat times; instead, separate sets of t and r tuples must be defined for each occurrence period.