Understanding Session Description Protocol (SDP)

It’s impossible to truly understand SIP without understanding its cousin, Session Description Protocol (SDP).  While SIP deals with establishing, modifying, and tearing down sessions, SDP is solely concerned with the media within those sessions.  That SIP would relegate media to another protocol is not accidental.  The creators of SIP set out to make it media agnostic and this separation of church and state reinforces that.   SIP does what it does best and leaves media to SDP.

So, what is SDP?  Well, it’s exactly what its name says it is.  It’s a protocol that describes the media of a session.  It is important to realize that it doesn’t negotiate the media.  It isn’t used by SIP clients to go back and forth asking “can you do this?” before finally settling on a common media protocol like G.711.  Instead, one party tells the other party, “here are all the media types I can support — pick one and use it.”

SDP is comprised of a series of <character>=<value> lines, where <character> is a single case-sensitive alphabetic character and <value> is structured text.

SDP consists of three main sections – session, timing, and media descriptions.  Each message may contain multiple timing and media descriptions, but only one session description.

The definition of those sections and their possible contents are as follows.  It’s important to know that not every character/value may be present in an SDP message.

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)

For Example

The following is an example of an actual SDP message.


o=Andrew 2890844526 2890844526 IN IP4

s= SDP Blog

c=IN IP4

t=0 0

m=audio 49170 RTP/AVP 0 8 97

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:97 iLBC/8000

m=video 51372 RTP/AVP 31 32

a=rtpmap:31 H261/90000

Unless you’ve been working with SIP and SDP for a while, this probably looks pretty undecipherable.  However, it’s really not that bad if you know what to look for and what you can safely ignore.  This is what I pay attention to in an SDP message.

c=  This will tell me the IP address where the media will come from and where it should be sent to.

m= There will be a media line for each media type.  For example, if your client can support real-time audio there will be an m= audio line.  If your client can support real-time video there will be a separate m=video line.  Each media line indicates the number the codecs that will be defined in attribute lines.

a=  There will be an attribute line for each codec advertised in the media line.

Looking at the example above I immediately see this.

The client will use IP version 4 with an address of It can support three audio codecs and one video codec.   The audio codecs are G.711 uLaw (PCMU), G.711 aLaw (PCMA), and iLBC.  The audio codecs will use port 49170 and all have a sample rate of 8000 Hz.  The video codec is H.261 on port 51327.  99.9% of the time I can safely ignore any of the other SDP values that might be present.

After receiving  a SIP message with the above SDP in the message body, the recipient will respond with SDP of its own identifying its IP address, ports, and codec values.  The recipient will also pick from the list of the sender’s codecs which ones it will use and potentially start real-time media flows.  The unwritten rule of SDP is that if possible you use the first codec of a type listed, but you don’t have to.  If the sender says he can do something, he had better be prepared to handle media of that type no matter in what order it was listed.

I hope this helps makes sense of what might be seen as a difficult subject.  If possible, take some Wireshark traces of a few SIP calls and see if you can figure out how media is being described and used.

By the way, this is the 50th article I’ve written for this blog.  Congratulations to me.



  1. shaila · · Reply

    This article is helpful when you are starting with SDP.Was really helpful in understanding SDP in a simple manner with good information.

    1. Thank you. I am happy you got something out of it.

  2. I was very unconformable with SDP. after reading your tutorial it is better now. Thanks for nice and Simple Explanation.

  3. Reblogged this on Codeera and commented:
    Nice Post about SDP protocal

  4. nice article

  5. thank you for making it easy to understand SDP…. great article !!!

  6. ganganapalli · · Reply

    This article is very nice and very simple to understand…
    After reading your article I have some doubts regarding timing description(Each message may contain multiple timing…..THIS IS FROM YOUR ARTICLE).
    1.Here suppose t= 0 0 means session with media exchange between two user agents will be for unlimited time. If we declare stop time with some value like t=0 12345 ,does it means after expiring the time 1234 there will be no media exchange but session will be existed???

    2. Can you explain about bounded time and permanent time for start time and stop time.

    3. How can we have the multiple timings in the sdp ? could please explain this with some related examples

    1. Ganganapalli, thanks for reading. Here is the explanation for multiple timing sections taken from RFC 4566. I hope it helps.

      Honestly, I have never created a session with more than one t-line and it has always been 0 0. You will find that what is allowed in a specification may not be what you do in real life. 🙂

      The “t=” lines specify the start and stop times for a session.
      Multiple “t=” lines MAY be used if a session is active at multiple
      irregularly spaced times; each additional “t=” line specifies an
      additional period of time for which the session will be active. If
      the session is active at regular times, an “r=” line (see below)
      should be used in addition to, and following, a “t=” line — in which
      case the “t=” line specifies the start and stop times of the repeat

  7. you are simply a great writer and educator in IMS field. I have learned so much from you, an IMS hero!!!!!

    1. Thank you. That was the nicest thing anyone has said to me today. 🙂

  8. This document is really help me a lot. Thanks dear. Please keep writing on complicated things.

  9. Ravi Prakash · · Reply

    Very nice article.

  10. Hi Andrew,

    Can you explain about record-route header filed ?

    For a new request within a dialog, does proxy must add record-route ? If proxy doesn’t add record-route to a new request that is already in the dialog, will it be removed in that path (route set) or it remains same ?

    Suppose let us take intermiate request in a dialog is UPDATE ? Does proxy must add record-rout to this to remain in this path ? or without adding record-route also it will be raminaing in this path ?

    In RFC the below 2 statements are confusing.

    4. Record-Route


    If this request is already part of a dialog, the proxy SHOULD
    insert a Record-Route header field value if it wishes to remain
    on the path of future requests in the dialog. In normal
    endpoint operation as described in Section 12, these Record-
    Route header field values will not have any effect on the route
    sets used by the endpoints.

    The proxy will remain on the path if it chooses to not insert a
    Record-Route header field value into requests that are already
    part of a dialog. However, it would be removed from the path
    when an endpoint that has failed reconstitutes the dialog.


    Could you please provide your comments on this ?

  11. Hello,

    There are multiple “c” params in following message. Whereas there is only 1 “m” param. Does it make sense ? Is it having any significance? Can it cause any issue in the network elements ?Is there any standard which does not allow multiple “c” without “m” param.
    Please let me know.

    o=- 1027440880 131201676 IN IP4
    s=QC VOIP
    c=IN IP4 ////////————————-here
    t=0 0
    m=audio 1754 RTP/AVP 104 105
    c=IN IP4 ////////————————-here
    a=rtpmap:104 AMR-WB/16000
    a=rtpmap:105 telephone-event/16000
    a=fmtp:104 max-red=0; mode-change-capability=2; mode-set=0,1,2
    a=fmtp:105 0-15

  12. Very simple and nice explanation

    1. Thanks for reading and commenting!

  13. Hi ,

    I am having one doubt on stateless proxy.

    Stateless proxy means it will not maintain any transactions. Why stateless proxy also should add it’s via header filed ? (why its mandatory ?)

    Thanks for your support.


    1. I am not positive on this, but I don’t believe that a Via is mandatory for all proxies. The RFC reads that a UAC must insert one. It also says that a stateful proxy needs to do the same. However, it makes no claim for a stateless proxy.

  14. Hi Andrew,

    Thanks for clearing my doubts.

    I am having one more doubt, in some softphones there are 2 options ‘proxy’ and ‘outbound proxy’. What is the difference between sip Proxy and outbound proxy. How the client behaviour change if we set proxy and outbound proxy ?

    Thanks for your continuous support.


    1. I don’t know what softphone you are using so I really can’t say. I would try setting both values to your SIP proxy and see what happens. It might work exactly the same, but I really don’t know.

  15. Thanks for the information. We are using PJSIP, they are having botth options proxy and outbound proxy. In general proxy and outbound proxy are same ? or any difference ?

  16. Rasheed Khouli · · Reply

    Thank you very much, I have a question. When I run tpacketcapture app on my mobile phone, I can’t make any voice call with another mobile. The SIP signaling was done ok, and the other party was ringing, but when he answered we couldn’t hear anything, from the trace I noted that the connection header in the SDP part is not my real IP but instead is the IP address of the tpacketcapture app (, so I think the media will not reach me on this IP.. Is there anything to do in this situation ??, because without the tpacketcapture I will not be able to trace the packets.

    Appreciate your help. thank you.


    1. I don’t use tpacketcapture, but from what I read it uses the Android vpnService which would have it become the media sink (at least that’s the way I see it). You will need to research tpacketcapture to figure out how to get it to NAT properly.

      I’m sorry I can’t help any further. There may be online forums for tpacketcapture where someone has already figured this out. Good luck.

      If you do find the answer, please share it here so others might know. Thanks.

  17. Chandio · · Reply

    Good Article with basics, Thanks!!

  18. Guillermo Gesualdi · · Reply

    Great Article Andrew thank you as always !!
    I wanted to ask you, I am working in an Avaya SBC against a Broadsoft SBC, is there a way at Avaya side to remove SDP values during the INVITE session, like : Bandwith, Time Description and Session attributes ?
    This is being required by the provider AT&T.
    I have been told that this happened at AT&T USA, but I can´t find any information about that.
    thank you !!

    1. Without a customer premise SBC, I don’t know how to do that.

  19. Deepak Narwal · · Reply

    After two days i am going to face one interview where knowledge of SIP is must..I was nervous but after reading your tutorial i am feeling excited and really u are a person with a great writing skills..salute sir……It is 00:04 Hrs in india and i am ready to spend my whole night in going through ur tutorials..Thanks a lot sir..thanks a lot..D way u describe things..really u are person with beautiful writing skills..Thanks once again boss

    1. Good luck. I hope it goes well for you.

  20. […] зависит, кто кому первый пошлет описание сессии в формате SDP (Session Description Protocol, там где говорится о количестве, […]

  21. Hello Andrew,

    thanks for such a nice post. I have few queries.

    I am baseband/modem engineer and working on integrating VoLTE.

    1) When does IMS stack will send codec /rtp media parameters to Modem/Voice engine ?

    Is it after getting 183 session progress or 180 ringing.

    As I have seen in one 3gpp document,Network usually performs Voice bearer allocation after 183 session progress. So I believe that after that network can start sending voice data.

    Also there is some description related to SDP I saw in this link

    It seems that if 183 or 180 has SDP , then voice path should be established.

    2) If i mostly seen 183 followed by 180 , can we also get
    2a) 180 directly
    2b) 180 and then 183.

  22. This is a very helpful article! Thank you so much!

    1. Thank you! I am happy to be of assistance.

  23. What will happen if source send SDP in the INVITE and there is no SDP response from destination side??

    A B
    INVITE with SDP==>
    180 ringing(Without SDP) <==
    200 OK (WIth out SDP) <==

    1. Then there is no media. I would also look for a different SIP endpoint. There are better ways to handle a situation where the called party doesn’t want to start a media connection.

      1. Thanks Andrew..:)

  24. Thanks Andrew, your blogs use SDP (simple description protocol) as well 🙂

  25. HI Andrew,

    I have one doubt What is the Ptime in SDP…

    Sample Logs:

    m=audio 49230 RTP/AVP 96 97
    a=rtpmap:96 L8/8000
    a=ptime: 20
    a=rtpmap:97 L16/8000

  26. Hi Andrew Thanks for such a wonderful information. I am regular reader of your blog. I’ve just started the professional life. I was studying and something came into my mind. Suppose i am watching a video in HD, In the middle i change the video quality to Medium. How it will process ?? I mean it will be a Late Offer or Early offer or something else. Please respond. I will be much glad for your correspondence 🙂

  27. Hi .. I cannot find anything on media attribute a=X-AD-REALM:-1. I don’t know what this attribute means. I received a complaint saying that if the above media attribute exist in SDP, the INVITE message will not getting any response.

    1. I believe that that’s a proprietary header strictly used by Microsoft Lync. AD stands for Active Directory. Other than that, I don’t know what it’s used for. Sorry.

  28. Hi Andrew Thanks for such a wonderful information. I am regular reader of your blog. I’ve just started the professional life. I was studying and something came into my mind.
    phone A send Register message to register server and server send 200 ok….but clinet is still not yet registered…..may i know how and y its be like this

    1. If the client receives a 200 OK it should be registered. It sounds like a bug if it’s not.

  29. Hi Andrew, I have some different issue while handling the Metaswitch, while in between call dialog, some one place call on hold, it will send re-invite with SDP information.

    m=audio 47178 RTP/AVP 18 101
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    But while negotiating this re-invite, switch is changing the codec order and after that switch send the BYE.

    t=0 0
    m=audio 54606 RTP/AVP 18 101 0
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000

    Is this change in sequence of order is valid? What can lead switch to do it.? Is this known issue in SIP?

    1. It is legal to change the order if there is a good reason to do so. This may be how a switch implements call admission control and bandwidth management. However, in your case I don’t see a change in order. In both cases I see G.729 followed by RFC 2833.

      1. Hi Andrew, appreciate your response, thanks. but still have some doubt, If change in order sequence is valid, then how PCMU is following after RFC 2833 over 200 OK? Does it is valid to add extra SDP information which is not given in re-invite. Does 200 OK should not contain the only SDP information which is contained in re-invite?

  30. Danielle · · Reply

    Hi Andrew,

    Great job on this blog.. there isn’t a lot of good SIP explanations out there 🙂

    For SDP offers is an SDP answer always required from the far end? IE. UPDATE message with an SDP offer (same as previous in INVITE) must the 200OK response contact SDP answer?


    1. Thanks for the compliment!

      I am not sure if I understand your question, but an answer SDP is required.

  31. Andres Gonzalez · · Reply

    Quick question: are comments allowed in an SDP file? using perhaps a ‘#’ at the beginning of a line?

    1. Not that I am aware of. I’ve certainly never seen comments within a protocol message.

      1. Andres Gonzalez · ·

        Thanks for your response. I did not see anything in RFC 4566 about allowing comments but I though I would ask you about it.

  32. Subhankar Dey · · Reply

    can you please talk more on fmtp & rtpmap from SDP? interested to know the use of these #2 attributes in SDP.

  33. Narendra · · Reply

    Andrew, Thanks for your series of articles, it is really making understanding SIP and SDP much easier and interesting.


  34. good article thnks

  35. I generally don’t see b=bandwidth info in SDP it just shows the RTP values….does the b=bandwidth value is hidden…we use call manager 9.1

    1. Bandwidth (B=) is optional and is often not inserted.

  36. i havent seen response for ptime in SDP what it is and can i have more than one ptime in an SDP message ?

    1. From the RFC…Any payload format, but most likely audio formats, may also include the optional parameters “ptime” to specify the recommended length of time in milliseconds represented by the media in a packet, and/or “maxptime” to specify the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds.

    2. Thank you Andrew for that quick response, but the m= line attribute can have more than one rtpmap(codec’s), if there is a use case that codec G.722′ needs ptime 10 codec ‘PCMU’ needs ptime 20 then the SDP message would look like this

      a=rtpmap:9 G.722/8000
      a=rtpmap:0 PCMU/8000

      reffering cisco link :http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/8_5_1/sip_t_n/4-sdp_api.html

      If both codec used same ptime then how would the SDP look like ?

      Option A:
      a=rtpmap:9 G.722/8000
      a=rtpmap:0 PCMU/8000

      Option B:
      a=rtpmap:9 G.722/8000
      a=rtpmap:0 PCMU/8000

      Is there any spec that could point to how this would look like ?

      1. Did you get a chance to look at it ?

  37. Super great article!!

  38. Kavita · · Reply

    Great article. It was easy to follow and understand. Thanks

  39. Lucas · · Reply

    simple and easy to understand. Thanks for your blogs!
    I got one question about the SIP proxy server. Can you please provide your thoughts?
    If the UAC sends an invalid INVITE(say, an SDP offerer does not include “require” header tag with “precondtion” value when the offer contains one or more “mandatory” strength-tags, in spec rfc3312#section-11, it must include this.)
    Should the SIP proxy server reject this INVITE? or just proxy it? I feel confused about that.


    1. I don’t know if there is a hard and fast rule about it. At some point, a malformed message should be rejected, but I don’t believe that the specifications say exactly where that should happen.

  40. hello ,, without media IP , is any session would be established ??
    Is media IP mandatory for session establishment ??

    1. Media is not mandatory.

      1. what do you mean not mandatory ?

      2. It means it’s not required.

  41. taofeek · · Reply

    thank you Andrew

  42. This article helped me out a lot, SDP was in cyrilic for me before.

  43. Thomas Anderson · · Reply

    Andrew – Great to see people like you who are truly passionate about this subject. Thank you very much for you hard work and time. Sharing the knowledge is where it is at. Im a true follower of your log now!! You should write a book!

  44. HI Andrew ,

    I have a small doubt here , in sdp we have “o” and “c” parameter both contains an ip , may i know which ip “o” parameter will contain ?

    According to my understanding “c” will contain media ip address from where media will flow but have confusion with “o” parameter .

    Could you please clear this doubt ?

    Thanks 🙂

  45. Bhavna Bathla · · Reply

    Hi Andrew , I have one question here .. Is it correct to say that the media formats or codecs advertised in SDP state what a device is willing to receive ?

  46. SBoobathy · · Reply

    HI Andrew, there are two audio m line in a SDP
    what does it mean…

    m= audio 45673 RTP/SAVP 9 104 0 18 101
    m= application 0 RTP/SAVP 0
    m= audio 0 RTP/SAVP 0

  47. Rob Annable · · Reply

    Hi Andrew, I am very new to SIP and in the last few months I have been reading many pages of your blog.
    I cannot thank you enough for your writing. If you decided to publish anything on the subject, I would definitely be ordering a copy!
    Thanks again,

  48. Shahid Hussain · · Reply

    Hi ,
    Can someone please tell me the reason why we use payload number in m= line , is it only to do mapping between payload type and its properties? Can it be vary like can i specify 1 for PCMU or it is fixed i.e PCMU is 0?
    Anyone can reply,

    1. Hi Shahid,
      RTP Payload type can have the values 0 to 127. The binding of RTP payload format to Payload type can be static or dynamic. [RFC3551] establishes the policy that no additional static payload types will be assigned beyond the ones defined. As described in RFC5761, dynamic RTP payload types SHOULD be chosen first from the range 96-127. Values below 64 MAY be used if that is insufficient.
      As a summary , all payload types below 96 have fixed values , and you can define yours from the range of 96 to 127 , like i can invent a Codec and names it shahidcodec and give it a value between 96 to 127 , but

  49. Hi Andrew,

    Can you please explain what you mean by
    c=* (connection information—not required if included in all media)

    Specifically “not required if included in all media”. What other attributes/SDP fields would be needed if the connection line was empty?


    1. It can be in an “o” tag.

  50. Debjyoti · · Reply

    Very simple and very Helpful —– Please keep writing more blogs on SIP fro beginners like me.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: