Session Description Protocol

Internet protocol suite
Application layer
BGP DHCP DHCPv6 DNS FTP HTTP IMAP IRC LDAP MGCP NNTP NTP POP RIP RPC RTP RTSP SIP SMTP SNMP SOCKS SSH Telnet TLS/SSL XMPP (more)
Transport layer
TCP UDP DCCP SCTP RSVP ECN (more)
Internet layer
IP IPv4 IPv6 ICMP ICMPv6 IGMP IPsec (more)
Link layer
ARP/InARP NDP OSPF Tunnels L2TP PPP Media access control Ethernet DSL ISDN FDDI (more)

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, and subsequently published a revised specification as an IETF Proposed Standard as RFC 4566 in July 2006.

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. 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. Whitespace is not allowed immediately to either side of the =.

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.

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

     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)

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. Attributes take two forms:

• A property form: a=<flag> conveys a property of the session.
• A value form: a=<attribute>:<value> provides a named parameter.

Time Formats

Absolute times are represented in Network Time Protocol 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 on 1 August 2010, with a single repeat time a week later at the same time can be represented as:

        t=3487140000 3487143600
        r=604800 3600 0

Or using typed time:

        t=3487140000 3487143600
        r=7d 3600 0

External links

• Rosenberg, J.; Schulzrinne, H. (2002-06). "An Offer/Answer Model with the Session Description Protocol(RFC 3264)". IETF. http://tools.ietf.org/html/rfc3264. Retrieved 2010-07-25.