Understanding PRACK: The SIP Method for Reliable Provisional Responses

PRACK, or Provisional Response Acknowledgement, is an optional  SIP (Session Initiation Protocol) method, defined in the RFC 3262,  that is used to provide reliability for provisional responses in a SIP communication.

Provisional responses, also known as “1xx” responses, are used to indicate that a request has been received and understood by the server, but that additional information or action is needed before the request can be completed. Examples of provisional responses include “183 Session Progress” and “180 Ringing.”

The problem with provisional responses is that they are unreliable, meaning that they can be lost or delayed in transit. This can lead to confusion and delays in the communication process. PRACK addresses this issue by providing a mechanism for the client to acknowledge receipt of a provisional response and request retransmission if necessary.

When a client receives a provisional response, it can send a PRACK request to the server. The server will then respond with a “200 OK” response, indicating that the provisional response has been received and understood. If the client does not receive a “200 OK” response within a certain period of time, it can retransmit the PRACK request.

PRACK is useful in situations where the client and server are communicating over a network with high packet loss, such as a wireless network. It can also be used to provide reliability for provisional responses in situations where the client and server are communicating over a network with high delay, such as a satellite link.

According to the RFC3262:

The UAS MUST send any non-100 provisional response reliably if the
initial request contained a Require header field with the option tag
100rel.  If the UAS is unwilling to do so, it MUST reject the initial
request with a 420 (Bad Extension) and include an Unsupported header
field containing the option tag 100rel.

Lab – FreeSwitch, Obihai Phone

I’m going to demonstrate how to enable PRACK using FreeSwitch and a MicroSIP phone. On FreeSwitch you have to add the line <param name=”enable-100rel” value=”true”/> in the SIP profile for the phones. Then make a call to a phone who supports 100-rel such as the Obihai and the magic will appear. The SIP ladder of the exchange is shown below.

When I tried this lab with MicroSIP it didn’t work. MicroSIP includes in the 180 ringing response the header Supported: 100rel. For Obihai when you configure the phone for 100 rel support it adds the 100rel as Required. Once one of the sides have it as required, it starts.

2023/01/28 10:15:15.632273 ->
SIP/2.0 180 Ringing
Call-ID: 68582ad9-19c1-123c-1794-080027b770b9
CSeq: 62905665 INVITE
Content-Length: 0
From: “Extension 1000” <sip:1000@>;tag=BSat99UpmZH5H
To: <sip:1001@>;tag=SP16daaf9e7e37fbe64
Via: SIP/2.0/UDP;branch=z9hG4bK3yccZUX0X27jm;received=;rport=5060
Server: OBIHAI/OBi1062-
Contact: <sip:1001@>
Require: 100rel
RSeq: 39965
Allow-Events: hold,talk,dialog

You should use PRACK with care. These method is not often used, so it is easier to find bugs and incomplete implementations. The example is merely illustrative,I’m not suggesting you enable PRACK.

In conclusion, PRACK is a SIP method that provides reliability for provisional responses. It allows clients to acknowledge receipt of provisional responses and request retransmission if necessary.

1 thought on “Understanding PRACK: The SIP Method for Reliable Provisional Responses

Leave a Reply

Your email address will not be published. Required fields are marked *