The Anatomy of an INVITE Request

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.

9 comments

  1. Thank you for detailed explanation.

    We also would appreciate to see how ABNF grammar rules applied to SIP in the same manner

    1. Faith, you need to be more specific. There are ABNF forms of SIP available on the web. Are you looking for something more?

  2. Thanks for the details Andrew! Very informative.

    1. Thanks, Neil. It was fun to write.

  3. Very Informative post.. Thank you…

  4. I wrote a SDP parser so that I can manipulate it into the browser: https://github.com/beradrian/sdpparser

  5. Very helpful post Thank you. If possible can you explain a video conferencing sip call flow. Thankyou

  6. RiverIntoSea · · Reply

    Thank you very well explained

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: