Ducks Go Quack. SIP Goes Prack.

The first release of nearly everything typically leaves something to be desired.  Not only are there the inevitable bugs, but it’s nearly impossible to think through every use case that might be applied.  This was clearly true with SIP.  When I first began working with SIP in the late 1990’s there were quite a few holes and areas that weren’t quite thought through all that well.  For instance, the first incarnation of SIP didn’t have the Refer message and transfer was implemented with a header in the Bye message.   That header, which I recall as being called “bye-also,” directed the transferred party to hang up and place  new call.  It was clumsy at best and disappeared once Refer came along.

Another hole was how provisional responses were handled.  As you may know, a provisional response is sent after a session has been initiated, but before it has been established.  Provisional responses fall into the 1xx class of responses.  The 1xx class of responses consists of 100 Trying, 180 Ringing, 182 Queued, and 183 Session in Progress.  There is no limit to the number of provisional responses you might receive before a session is established with a final response (2xx through 6xx).

Not too long after SIP was developed a problem arose with provisional responses.  There was no way of knowing if a provisional response was ever received.  This was especially true with an unreliable, datagram protocol like UDP.  A user agent server (UAS) might send a 183 Session in Progress in order to play an announcement to a user agent client (UAC), but the data network could drop the message and the UAS would never know that it wasn’t received.  Thus, the Provisional  Response Acknowledgement, or Prack message, was created.

The idea behind Prack is that the recipient of a 1xx response message informs the sender that the message was received and is being acted upon.  That way the sender can know that the 180 Ringing message that it sent has caused some form of alerting to occur (i.e. a ringing phone).

The mechanics behind a Prack aren’t that difficult to understand once you learn about a few constructs that have been added to SIP.  First, Prack messages aren’t automatically sent.  The UAC needs to advertise that it supports Prack messages by adding a “Supported” header to an Invite message.  Specially, it adds a Supported header with the value of 100Rel.  For example,

Supported: 100Rel

Next, the UAS adds Require and Response Sequence (RSeq) headers to every provisional response it wants acknowledged.  Every RSeq header will contain a numeric value that identifies a specific response message.  For example, the sender might add the following to headers to 180 Ringing provisional response.

Require: 100Rel

Rseq: 6

Upon receipt of that response message, the SIP UAC will reply with a Prack message containing a Response Acknowledge (RAck) header with the same RSeq value.  For instance, if a 180 Ringing is received with an RSeq of 145, the Prack will contain an RAck header with the value of 145.  The UAS responds back with a 200 OK to complete the acknowledgement.

The following message flow is an example of a Prack transaction.

UAC  sends:  INVITE (Supported: 100Rel)

UAS sends:  180 Ringing (Required: 100Rel, RSeq: 145)

UAC sends:  PRACK (CSeq: 1 PRACK, RAck: 145)

UAS sends: 200 Ok (CSeq: 1 PRACK)

That’s really all there is to Prack.  Will it be the last “fix” to SIP?  Absolutely not.   As SIP acceptance grows and it is applied in ways that the original developers never envisioned, there will be new headers, request types, and reference call flows.



  1. Ravi Prakash · · Reply

    Thanks for this informative post.
    However, this call flow is not complete. UAS will send 200 OK twice. So, i suggest you to complete the call flow for novice learners at least!!.

    1. By twice do you mean the 200 OK for the INVITE? Yes, that will happen, but that is not part of the PRACK call flow. There will be on 200 OK for every PRACK. That is the point of this article. The 200 OK for the INVITE is separate.

  2. Ravi Prakash · · Reply

    All right.
    Thanks for your explanation.
    Looking forward to more such nice articles from you.:)

  3. Abhishek · · Reply

    Thanks a lot for such a nice explanation….please try to cover every SIP topic
    and looking forward to some more nice articles

  4. Abhishek · · Reply

    Can you please write an articles on SIP Media negotiation.

  5. Just a moment to say thank you!

    I enjoy too much learning with your articles as the intro is pleasant and even funny!

    it helps to quench the technical flames engineers like me are involved.

    I also noted that remember SIP topics is not so easy (for me) to remember, but I associate that to your intro and I realize I do remember that explanations.

    Great work

  6. Is a PRACK sent in response to a 100 Trying?

  7. Just wanted to drop a note of appreciation–I’ve read several of your articles along my journey into VoIP and I’ve never acknowledged the assistance you’ve provided me.

    1. Thanks! I love knowing my articles are helpful.

  8. is it safe to assume, 100 trying is the only message for which a PRACK is not sent(among the other 1xx)

  9. Joseph DeMarco · · Reply

    Being new to SIP, your articles are very helpful. One question.. In paragraph above message flow example you state “the UAC responds back with a 200 OK to complete the acknowledgement”. Message flow shows “UAS sends: 200 Ok (CSeq: 1 PRACK)”. Which is correct?

    1. Fixed. Thanks for finding that.

  10. Dear Andrew,

    Your articles on SIP protocol are really good.
    Can you explain briefly on “Why ACK is separate transaction. As I did’t get clarity when read RFC 3261 or 2543.


  11. Hi Andrew, is it acceptable for a PRACK to have ‘call-info’ header ??
    I have an issue where far end is rejecting call because of this, as they say it is invalid, but I cant find anyhting thats says what headers are / are not allowed in a PRACK.

  12. Are PRACKs sent only when a 183 is sent? Recently got hired as a (PAID!!!) intern doing VoIP and am trying to understand it as much as possible during training. (My field is more networking, CCNA, than telephony)

    1. Nope. They are sent for every provisional response other than 100 Trying.

  13. HOW Rseq is increments??& what is and why is needed??

    1. From RFC 3262: The value of the RSeq in each subsequent reliable provisional response for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 – 1, but the maximum is 2**32 – 1, there can be up to 2**31 reliable provisional responses per request, which is more than sufficient.

  14. How should a provisional responses with RSeq-headers be handled when there are no option tags?

  15. patrik clarin · · Reply

Leave a Reply

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

You are commenting using your 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: