As a high school student, I loved biology. I loved learning about the natural world and how our bodies function. The spleen was my friend — not to mention the pancreas, liver, and lungs.
Unlike many of my classmates, I didn’t mind dissecting frogs and the obligatory fetal pig. Okay, I wasn’t overly fond of the smell of formaldehyde, but it was mesmerizing cutting into the skin and exploring what lurked below.
I look upon SIP in a very similar fashion except instead of using a knife, my dissection tool of choice is Wireshark. Followers of this blog should already know that from reading my article, How to Debug SIP. Wireshark is powerful software that not only captures SIP packets, but displays them in a very readable manner. On top of that, you can also capture and replay audio streams. If you want to call yourself a SIP professional, you need to get very chummy with Wireshark.
I recently taught my Introduction to SIP class and saved a few call traces from the student’s PCs. To keep things simple, I load up a basic Avaya SIP soft-phone that allows the students to perform a number of telephony functions along with rudimentary presence operations. As part of our labs, they turn on Wireshark and capture everything from make call to conference and transfer.
Today, I am going to pull an INVITE message from one those traces and walk through it section by section.
In case you forgot, a SIP message consists of four sections:
- The request line
- The headers
- A blank line
- An option message body
Since this is an INVITE with SDP, you will see all four parts.
INVITE sip:twhite@10.101.5.120 SIP/2.0
From: “Andrew Prokop” <sip:aprokop@10.101.6.120>;tag=35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
To: sip:twhite@10.101.5.120
Call-ID: f_169eac17a017b0a4e0adfa8_I@10.101.6.120
CSeq: 15 INVITE
Via: SIP/2.0/UDP 10.101.6.120;branch=z9hG4bKf_169eac12baa17054e0adfb3_I
Content-Length: 306
Max-Forwards: 70
Contact: sip:aprokop@10.101.6.120;transport=udp
Content-Type: application/sdp
User-Agent: Avaya SIP Softphone
Supported: replaces
v=0
o=sip:aprokop@10.101.6.120 1 16 IN IP4 10.101.6.120
s=sip:aprokop@10.101.6.120
c=IN IP4 10.101.6.120
t=0 0
m=audio 5000 RTP/AVP 0 8 18 4 120
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000/1
a=rtpmap:120 telephone-event/8000/1
I will admit that I have seen more complicated INVITE messages, but this one is a fair representation of what one should look like. All the required headers are present and properly formed. The SDP includes several widely used codecs. In other words, it’s real and it works.
One thing to take note of is that my labs are done with point-to-point SIP clients. This means that we don’t have the benefit of a SIP address of record (AOR) registered with a proxy. That’s why you see an IP address used in the Request Line, To header, and From header. Sending a REGISTER to a SIP proxy would allow us to use the format, user@domain, but I don’t have the necessary setup to allow for that.
For a deeper understanding of the SIP AOR, please see my article Understanding SIP Addresses.
Okay, let’s get started on dissecting this message
Request Line
INVITE sip:twhite@10.101.5.120 SIP/2.0
The request line tells me that this is an INVITE sent to sip:twhite@10.101.5.120. It also tells me that the INVITE uses SIP version 2.0 (the current version).
At the end of the call, you would see a SIP message with a BYE in the Request Line.
From
From: “Andrew Prokop” <sip:aprokop@10.101.6.120>;tag=35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
From is the first header of this INVITE. It’s important to know that From could have appeared anywhere in the header section. With the exception of the Via, SIP headers are not order dependent.
This From tells me that the message is from sip:aprokop@10.101.6.120 and the display name is “Andrew Prokop.” Display name is for human consumption only and plays no part in routing the message.
The tag parameter is used to identify the call leg or dialog. For more information on tags, please read my article, Let’s Play (SIP) Tag.
To
sip:twhite@10.101.5.120
This To header indicates that the called party is twhite@10.101.5.120. Notice that there is no tag. A tag will be applied by the recipient.
Call-ID
Call-ID: f_169eac17a017b0a4e0adfa8_I@10.101.6.120
Call-ID is used to create a unique identity for this session. The requirement for Call-ID is that it needs to be globally unique. A common way to guarantee uniqueness is to generate a random number that is unique to the sender (in this case, f_169eac17a017b0a4e0adfa8_I) and then append the sender’s IP address. This number plus IP address makes it globally unique since no two endpoints will have the same IP address.
CSeq
CSeq: 15 INVITE
Command sequence is used to identify the number of requests of a specific type. Here, the header tells us that this is the 15th INVITE sent by this soft client. The client will increment the number by one for the next INVITE.
Note: I have seen some soft clients take liberties with this number and not start counting at 1. However, they will still increment by one for each new message sent.
Via
Via: SIP/2.0/UDP 10.101.6.120;branch=z9hG4bKf_169eac12baa17054e0adfb3_I
Via is used to record the route of a SIP message.
I wrote extensively about the Via header in my article, Understanding the SIP Via Header.
Content-Length
Content-Length: 306
Content-Length is the number of byes in the message body. A Content-Length of 0 (zero) indicates that there is no message body. This message body is 306 bytes long. We need to find Content-Type to know what those bytes represent.
For a detailed look into message bodies, please read, Understanding SIP Message Bodies.
Max-Forwards
Max-Forwards: 70
Max-Forwards is used to detect and stop a SIP message from endlessly looping around the network. Most clients, like this one, use the default value of 70.
You can learn more about Max-Forwards in SIP Loop Detection – Will it go Round in Circles.
Content-Type
Content-Type: application/sdp
If there is a message body, Content-Type will tell you how that message body has been formatted. In this case, it contains SDP.
User-Agent
User-Agent: Avaya SIP Softphone
User-Agent is used to inform the calling party about the caller’s SIP endpoint. A good analogy is an Internet browser. The browser will tell the web server what its make and model are. This allows the web server to treat Internet Explorer one way and Chrome another.
In this INVITE, the caller is telling the called party this it is an Avaya SIP Softphone.
If I wrote the client, I would have been more specific and also included a version number.
Supported
Supported: replaces
The Supported header allows the caller to tell the called party what SIP extensions it supports. Replaces is one of those extensions.
I go deep into the weeds about Replaces in Understanding the SIP Replaces Header.
That’s it for the SIP message. Next comes the message body.
We know that there is a message body because Content-Length was greater than 0 (zero). We know the format of the message body from Content-Type. So, for this INVITE, we have 306 bytes of SDP.
Version
v=0
The current version of SDP is 0 (zero).
Originator
o=sip:aprokop@10.101.6.120 1 16 IN IP4 10.101.6.120
This section identifies the sender, the protocol the sender is using, and the sender’s IP address. In this case, sip:aprokop@10.101.6.120 is the sender, he will be using IPV4, and lives at 10.101.16.120.
Session
s=sip:aprokop@10.101.6.120
This is the session title. Honestly, I’ve never seen it used for much of anything, but it has to appear in every SDP message.
Connection Information
c=IN IP4 10.101.6.120
This field defines the connection type and address. Here, were are using IPV4 and the sender’s media address is 10.101.6.120. It’s possible that this IP address could differ from the one specified in Originator, but that would not be common.
Timing
t=0 0
Timing is used to indicate the start and stop times for a session. Start and stop times of 0 (zero) indicates that the session is permanent and not bounded time-wise. I have never seen SDP in an INVITE that did not use zeroes for both values.
Media Descriptor
m=audio 5000 RTP/AVP 0 8 18 4 120
A media line will be present for each media type advertised within an SDP message. The format is:
m=<media> <port> <proto> <fmt>
In this example, the media line informs the called party that the caller supports RTP audio on port 5000. The 0, 8, 18, 4, and 120 are the various codecs that will be described by attribute lines.
Attribute Lines
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000/1
a=rtpmap:120 telephone-event/8000/1
Each attribute line refers back to the Media Descriptor and the <fmt> values. Since we had five formats (0, 8, 18, 4, 120) we will have at least five attribute lines. Our example has six because codec 18 uses two lines to describe itself.
The format of these attributes is:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]
In our example, the SDP advertises that the client supports G.711 (PCMU and PCMA — pulse code modulation u-law and a-law) at 8000 Hz, G.729 at 8000 Hz, and G.723 at 8000 Hz. The last entry indicates that DTMF tones will be send using RFC 4733/2833. For more information about DTMF, please see my article DTMF and RFC 2833 / 4733.
That wasn’t too messy, was it? We just dissected an entire INVITE message along with a piece of SDP and our hands are still clean. As I previously wrote, I have seen more complicated INVITE requests, but they simply had a few more headers and perhaps a more involved SDP (audio plus video). This one is actually quite representative of a lot of what you will see in the real word.
Tao, Zen, and Tomorrow 
Thank you for detailed explanation.
We also would appreciate to see how ABNF grammar rules applied to SIP in the same manner
Faith, you need to be more specific. There are ABNF forms of SIP available on the web. Are you looking for something more?
Thanks for the details Andrew! Very informative.
Thanks, Neil. It was fun to write.
Very Informative post.. Thank you…
Reblogged this on telecom • networking • design.
I wrote a SDP parser so that I can manipulate it into the browser: https://github.com/beradrian/sdpparser
Very helpful post Thank you. If possible can you explain a video conferencing sip call flow. Thankyou
Thank you very well explained
Hello Andrew,
we are having a issue in DTMF where our collecting carrier is transcoding and DTMF is misbehaving. And they are telling us that we are not adding in the 200 OK media attribute “a=rtpmap:8 PCMA/8000”
is this field mandatory?
m=audio 55764 RTP/AVP 8 18 0 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sqn:0
a=cdsc: 1 image udptl t38
It appears they need you to support G.711. Do you?
very good post Andrew thanks for your help
Andrew, you have talent for converting a very cold RFC into a enjoyable story.
I learned a lot reading it.
I thought that would be useful to add the reference of RTP MAPs
after fetching several times “sip rtp map 8 101”
finally I got:
https://en.wikipedia.org/wiki/RTP_audio_video_profile
I Just Love this website. I have learned a lot.
I worked suppurting a voicemail system and I have clear out so many doubts.
Thanks! Your comment made my day.
Always enjoy reading your site Thanks for the great info!
Thanks, Dorcas!
Hey, thank you for simplifying everything so fluently. I still have one more question about the codecs, if you’re still replying to this thread. I was wondering how you can find a caller’s preferred codec choice.
The preferred Codec is the first one listed in the RTP.
Hi Andrew
Your blog is very informative and i learn a lot but i have one question
Is it possible to show a public IP on your sip “from Header”…..? Example my private IP is 10.24.0.16 which is NATTED to a public IP 212.60.100.133 at the firewall.
The ‘from Header’ should like this ‘+22299865544′<sip:+22299865544@10.24.0.16 or like this
'+22299865544'<sip:+22299865544@212.60.100.133
Which IP will show on the from header…..?
I expect that only the public IP address will show. Your SBC will be responsible for translating back and forth.
Very nicely written article. You made things easy to understand. Thanks a lot
Just found this article today and It is very informative! Very well written and truly contains amazing chunks of learning.