SIP PRACK and 100rel (RFC 3262): Reliable Provisional Responses in PSTN Interworking

Overview

This guide explains the SIP PRACK (Provisional Response Acknowledgement) mechanism and the 100rel extension defined in RFC 3262. Readers will learn why standard SIP provisional responses are unreliable over UDP, how PRACK guarantees delivery for early media and SDP negotiation, and how PRACK enables seamless interworking with SS7/ISDN PSTN networks.

Key takeaways

• Standard SIP provisional responses (1xx except 100 Trying) are unacknowledged and unreliable when transmitted over UDP.
• RFC 3262 introduces the '100rel' option tag, 'RSeq' sequence header, and 'PRACK' method to enforce reliable delivery of 1xx responses.
• PRACK is essential for PSTN interworking to ensure SS7/ISUP mapping (such as ACM and CPG messages) and early media negotiation are reliably processed before final answer.
• The offer/answer model can complete entirely within early dialogs using 18x provisional responses and PRACK requests.
• Negotiation occurs via 'Supported: 100rel' or 'Require: 100rel' headers in the initial INVITE.

Prerequisites

• Understanding of core SIP architecture and dialog creation (RFC 3261).
• Basic knowledge of SDP offer/answer model.
• Familiarity with PSTN interworking concepts and ISDN/SS7 signaling (ISUP ACM, CPG, ANM).

Guide

1. section #1

   The Limitations of Standard SIP Provisional Responses In baseline SIP (RFC 3261), 1xx provisional responses—such as 180 Ringing or 183 Session Progress—are sent unreliably over UDP. While 2xx final responses are explicitly acknowledged by an ACK request, provisional responses are not acknowledged by the User Agent Client (UAC). In pure IP voice networks, losing a 180 Ringing packet might only cause a minor delay in ringback tone display. However, when interworking with traditional PSTN networks (SS7/ISUP), provisional responses carry critical call control state changes and early media SDP descriptions that must not be lost.

2. section #2

   Understanding the RFC 3262 Mechanism (100rel & PRACK) RFC 3262 solves provisional response unreliability by introducing the PRACK method and the 100rel option tag. When a UAC advertises 'Supported: 100rel' (or mandates it via 'Require: 100rel'), the User Agent Server (UAS) can send provisional responses reliably. To do this, the UAS assigns a unique sequence number in an 'RSeq' header and includes 'Require: 100rel'. Upon receiving this provisional response, the UAC must immediately return a PRACK request containing a 'RAck' header that references the RSeq and CSeq numbers. The UAS then acknowledges the PRACK with a standard 200 OK.

3. section #3

   Detailed PRACK Call Flow and Header Syntax The reliability mechanism introduces a sub-transaction within the early dialog. The UAS retransmits the 18x provisional response until it receives the PRACK request from the UAC. The RAck header format in the PRACK request consists of two numbers: the sequence number from the RSeq header of the response being acknowledged, and the CSeq number of the original INVITE request.

   UAC                           UAS
    |                             |
    |--- INVITE (Supported:100rel)->|
    |                             |
    |<-- 183 Session Progress ----|
    |    (Require: 100rel,        |
    |     RSeq: 1001)             |
    |
    |--- PRACK (RAck: 1001 1 INVITE)->|
    |<-- 200 OK (for PRACK) ------|
    |
    |<-- 200 OK (for INVITE) -----|
    |--- ACK -------------------->|
   
   Example 183 Session Progress:
   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK776asdhds
   From: <sip:alice@example.com>;tag=1928301774
   To: <sip:bob@example.com>;tag=a6c85cf
   Call-ID: a84b4c76e66710@192.168.1.10
   CSeq: 1 INVITE
   Require: 100rel
   RSeq: 1001
   Content-Type: application/sdp
   
   Example PRACK Request:
   PRACK sip:bob@192.168.1.20:5060 SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK887bcde
   From: <sip:alice@example.com>;tag=1928301774
   To: <sip:bob@example.com>;tag=a6c85cf
   Call-ID: a84b4c76e66710@192.168.1.10
   CSeq: 2 PRACK
   RAck: 1001 1 INVITE

4. section #4

   PSTN Interworking: ISUP Mapping and Early Media SDP When a SIP-to-PSTN gateway converts SIP signals to SS7 ISDN User Part (ISUP) messages, state synchronization is essential. An ISUP Address Complete Message (ACM) or Call Progress (CPG) message maps to a 180 or 183 response. In PSTN networks, early media (in-band ringback, carrier announcements, or custom tone playout) requires a fully negotiated RTP stream before the call is answered (ISUP Answer Message - ANM). PRACK allows the initial SDP offer in the INVITE to receive an SDP answer inside the 183 response, guaranteed by PRACK acknowledgment, establishing early media pathways reliably before billing starts.

5. section #5

   SDP Offer/Answer Model Rules with PRACK RFC 3262 enforces strict offer/answer rules across provisional responses. If an INVITE does not contain an SDP offer (late offer), the UAS MUST place its SDP offer inside the 18x reliable provisional response. In this case, the UAC MUST place its SDP answer inside the PRACK request. Once an SDP offer/answer exchange completes within a provisional response sub-transaction, neither party can initiate another offer/answer exchange until the current PRACK transaction receives a 200 OK.

6. section #6

   Configuration Examples in Asterisk and FreeSWITCH Enabling 100rel on IP PBXs and SBCs ensures smooth interworking with telecom carriers that mandate reliable provisional responses. Below are standard configuration directives for PJSIP in Asterisk and Sofia SIP in FreeSWITCH.

   ; Asterisk pjsip.conf configuration
   [carrier-endpoint]
   type = endpoint
   context = incoming-carrier
   100rel = yes ; Options: no, yes, required
   
   <!-- FreeSWITCH Sofia SIP Profile (sip_profiles/external.xml) -->
   <param name="enable-100rel" value="true"/>
   <!-- To enforce PRACK on outbound calls via dialplan: -->
   <action application="set" data="sip_require_100rel=true"/>

7. section #7

   Troubleshooting and Best Practices Common issues with PRACK include '421 Extension Required' errors (sent when the UAS requires 100rel but the UAC did not include 'Supported: 100rel') and race conditions where 200 OK INVITE arrives before PRACK completes. Always ensure Session Border Controllers (SBCs) are configured to handle PRACK translation if downstream endpoints do not support RFC 3262. Furthermore, avoid forcing 'Require: 100rel' on endpoints like WebRTC clients or legacy ATA devices unless verified to support RFC 3262.

Further reading

• RFC 3262 - Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
• RFC 3261 - SIP: Session Initiation Protocol
• RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
• RFC 6337 - SIP Usage of the Offer/Answer Model