Session Description Protocol

The Session Description Protocol was first published in 1998 in RFC2327, one year before SIP itself. The protocol was updated in 2006 with RFC4566. Like SIP, SDP is also a product of the MMUSIC working group. Aside from SIP, SDP was also used in Mbone.

Within SIP, the Session Description Protocol is used to exchange data the endpoints need to send and receive RTP streams with audio and possibly video. Thus, the most important parameters exchanged using SDP are the IP addresses, port numbers, and codecs. We can say that SDP plays the same role in SIP as H.245 does in H.323 (but SDP is much less "talkative").

An Example Message

In SIP, The SDP messages are transported in the body of SIP requests or responses. As an example, let us use once again the SIP INVITE request we have shown in the section on SIP messages:

INVITE sip:13@10.10.1.13 SIP/2.0

Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK343bf628;rport

From: "Test 15" <sip:15@10.10.1.99>;tag=as58f4201b

To: <sip:13@10.10.1.13>

Contact: <sip:15@10.10.1.99>

Call-ID: 326371826c80e17e6cf6c29861eb2933@10.10.1.99

CSeq: 102 INVITE

User-Agent: Asterisk PBX

Max-Forwards: 70

Date: Wed, 06 Dec 2009 14:12:45 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,

  SUBSCRIBE, NOTIFY

Supported: replaces

Content-Type: application/sdp

Content-Length: 258

v=0

o=root 1821 1821 IN IP4 10.10.1.99

s=session

c=IN IP4 10.10.1.99

t=0 0

m=audio 11424 RTP/AVP 0 8 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

a=sendrecv

As you can see in this example, the body of the message is separated from the headers with one empty line and the header Content-Type: tells us that the message transported in the body belongs to the SDP protocol.

We describe the meaning of individual SDP fields below.

SDP Fields

Generally, each field in the SDP message falls into one of the following categories:

• Session name
• Time the session is active
• Media in the session and information required to receive the media
• Information about bandwidth
• Contact info for the responsible person

Fields in SDP messages have the format <field code>=<value>. The field code is always a single letter.

Let us now list the mandatory fields:

Field	Meaning	Format
v=	protocol version	v=0
o=	session owner and identifier	o=<username> <session id> <version> <network type> <address type> <address> In our example message above, the field was: o=root 1821 1821 IN IP4 10.10.1.99 ("IN" stands for Internet, "IP4" means IP version 4 address)
s=	session name	s=<session name> In our example, this was just: s=session
t=	time the session is active	t=<start time> <stop time> Even though this is a mandatory field in SDP, it is not very meaningful for SIP — it is not easy to predict the duration of a call. Usually, both values are the same. In our example, we have just "t=0 0". The times are decimal Network Time Protocol values (in seconds since the year 1900). In applications other than SIP, the SDP message can contain several "t= " lines, specifying additional periods of time when the session will be active.
m=	media type, format, and transport address	m=<media> <port> <transport> <format list> In our example message, this is: m=audio 11424 RTP/AVP 0 8 101 The <media> is either "audio" or "video" (if the call contained both audio and video, there would be two "m=" lines). The <port> should always be even (the even port is used by RTP and the next odd port by RTCP). <transport> is usually "RTP/AVP", denoting the RTP protocol with the profile for "Audio and Video Conferences with Minimal Control" (see RFC3551). Under the AVP, the code 0 denotes G.711 uLaw, 8 stands for G.711 ALaw, 3 denotes the GSM codec, and for example the G.729 codec is denoted by 18. These codes appear in the <format list> part, and their order denotes the codec preferences of the given user agent. In our example, G.711 uLaw (code 0) is the most preferred codec and G.711 ALaw is the second most preferred. The codes not specified in the AVP can be introduced on a dynamic basis which is the case of the code 101 in our example message.

SDP has a number of optional fields. Let us have a look at those important for SIP:

Field	Meaning	Format
c=	connection information	c=<network type> <address type> <connection address> In our example message, the field is as follows: c=IN IP4 10.10.1.99 This field is "semi-optional". It must appear either at the session level (like in our example) where it is valid for the entire session, or it must be included as a part of the "m=" field (after the <format list> part).
i=	session information	i=<textual description> The session information may appear at the session level or within the "m=" field (like the "c=" field above).
k=	encryption key	k=<method>:<encryption key> or k=<method> This parameter may appear at the session level or within the "m=" field.
a=	session attributes	a=<attribute> or a=<attribute><value> The SDP message may contain zero or several session attributes. There's quite a number of possible attributes and we will look at them below. Like the other optional fields in this table, "a=" may appear either at the session level or within the "m=" field. The session-level option is the usual one as is the case in our example message.

Our table displays some of the session attributes that can appear in the "a=" fields:

Attribute	Format and Description
rtpmap	a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] This attribute is called "rtpmap" because it defines a mapping from RTP payload codes (which are used in the <format list> in the "m=" field) to a codec name, clock rate, and other encoding parameters. The "rtpmap" field must be used for dynamic payload types (i.e. types that are not predefined in the AVP profile) but it is quite common to use it even for the types that are already defined in the AVP profile. In our example message, one of the "rtpmap" attributes is "a=rtpmap:0 PCMU/8000"
sendrecv	a=sendrecv This attribute means that we are going to both send and receive media. This is the option you will see with SIP, the other options ("sendonly", "recvonly", "inactive", "broadcast") would be highly unusual for a phone call.
ptime	a=ptime:<packet time> This parameter describes the length of time (in milliseconds) carried in one RTP packed.
fmtp	a=fmtp:<format> <format specific parameters> This option allows to define parameters that are specific for a given format code. SDP does not need to understand the parameters, it only transports them.