How do You Do an SIP INVITE Request?

Invite

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.

Related article: Avaya IP Shuffling: What Exactly Happens?

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=

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 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:/ [/]

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 world.

This article originally appeared on SIP Adventures and is reprinted with permission.

Related Articles:

Understanding SIP PRACK for Avaya Aura

As many of my readers know, every few months I teach a two and a half day class on “all things SIP.” My students are exposed to everything from “why SIP” to the nitty-gritty of SIP requests, responses and call flows. I even speak about some of the more esoteric topics such as To and From tags, the Replaces header, nonce values and TR-87.

Included in the esoteric list is the PRACK (Provisional Response Acknowledgement) method. PRACK wasn’t in the original SIP specification and was introduced later in RFC 3262. It came about after it was realized that some user agent servers need to know that a provisional response was received by a user agent client. Before PRACK, 1xx responses sent using UDP might get lost, and the sender would never know. PRACK adds a layer of reliability to an otherwise unreliable call flow.

I previously addressed PRACK in my article “Ducks Go Quack. SIP Goes PRACK.” Although I addressed most of the pertinent material, I was short on examples and real-life call flows. As I walked my most recent students through live calls on my company’s Avaya system, I happened to notice a few PRACKs and decided it was time to update my old article.

The following screenshots were gathered using the Avaya traceSM utility. I simply started traceSM on a live Aura system, let it run for a few minutes, and then stopped it after I noticed a few PRACK messages fly by. This was simply because I was unsure as to when Avaya uses PRACKs and when it does not.  In other words, “When in doubt, trace it out.”

prack1

Let’s start at the beginning. PRACK messages aren’t just sent out-of-the blue. The sender of an INVITE message must indicate that it is capable of sending PRACKS. It does that by including the header in the INVITE message:

Supported: 100Rel

This tells the recipient that, if requested, it will send PRACK messages for 1xx Responses.

The following shows an INVITE with such a header.

prack2

Now that the user agent server knows that PRACK messages are possible, it will include headers similar to the following in all 1xx Responses it wants to be PRACKed:

Require: 100Rel

Rseq: 1

The Requires header with a value of 100Rel tells the user agent client (the sender of the INVITE) that a PRACK is expected for this response. It’s important to know that the user agent server (the sender of the Response messages) has to request the PRACK. It’s not an automatic process and must be initiated with an Rseq header.

The value in Rseq is used by the user agent client when it creates a PRACK message. The user agent server is responsible for setting and incrementing this number.

The following 180 Ringing indicates that it expects a PRACK.

prack3

Upon receipt of this 180 Ringing, the user agent client must respond with a PRACK message. Of interest to this article is the Rack header. This header must contain the Rseq value sent in the previous 180 Ringing. Additionally, it will indicate the original INVITE session’s CSeq number. Look back at the INVITE in this call flow, and you will see a CSeq value of 1 (one). Therefore, the Rack will look as follows:

Rack: 1 1 INVITE

prack4

Next, the user agent server will send a 200 Ok for the PRACK. This tells the user agent client that the PRACK was received and processed.

prack5

For grins, I will now show you the 200 Ok for the original INVITE. Note that it does not have a Rseq header and 100Rel is not in the Requires header. Why not? That’s because this is not a provisional response. PRACKs are only sent for 1xx responses.

prack6

Mischief Managed

Before I close things out, I want to address the question I hinted at near the top of this article.  When does Avaya use PRACK?

While I honestly don’t know all the permutations, it appears that an INVITE from an Avaya endpoint will always indicate that it supports PRACK (Supported: 100Rel).  However, as you just learned, it’s the recipient of the INVITE that indicates if PRACK messages are required.

In the example above, the Avaya Modular Message voice mail server requests PRACK messages.  Additionally, PRACK is used when direct media is enabled.

There is a good chance that PRACK is used in other situations, but I am going to have to start up a few more traceSM sessions to learn where they show up.

That’s about all I really need to say about PRACK. I invite you to take a look at the RFC if you want to learn about any PRACK subtleties I might have missed, but for all practical purposes, I’ve said all that needs to be said. I hope you had as much fun today as I did. As is often the case, I learned something in the process of writing this article, and that’s always a good thing.