A traceSM look at SIP PRACK Messages

As many of my blog 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.”

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.

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.

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

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.

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.

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.  There is a good chance that other user agent servers also require them, but I am going to have to start up a few more traceSM sessions to learn which ones do and which ones don’t.

That’s about all I really need to say about PRACK (again). 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 is always a good thing.

Tags: Prack, SIP, Unified Communications