Let us have a look at the last protocol component that SIP needs in order to successfully establish a call. This last component is the Session Description Protocol, or SDP for short.
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:firstname.lastname@example.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK343bf628;rport
From: "Test 15" <sip:email@example.com>;tag=as58f4201b
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Wed, 06 Dec 2009 14:12:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
o=root 1821 1821 IN IP4 10.10.1.99
c=IN IP4 10.10.1.99
m=audio 11424 RTP/AVP 0 8 101
a=silenceSupp:off - - - -
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.
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:
|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:
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).
The session information may appear at the session level or within the "m=" field (like the "c=" field above).
k=<method>:<encryption key> or k=<method>
This parameter may appear at the session level or within the "m=" field.
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|
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"
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.
This parameter describes the length of time (in milliseconds) carried in one RTP packed.
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.
This is the last section of the Voice over IP Overview in its current length. I hope you have found it useful.
To help me improve the text, please take this
quick survey. Thank you!
Comments on this piece, or the VoIP Overview as a whole, are welcome on Vladimir's blog.
|Bookmark this on Delicious|