Description
The Provisional Response ACKnowledgement (PRACK) is a Session Initiation Protocol (SIP) method, standardized in IETF RFC 3262, which is adopted and utilized within the 3GPP IP Multimedia Subsystem (IMS) architecture. SIP, as a text-based application-layer signaling protocol, is the core of IMS for establishing, modifying, and terminating multimedia sessions. SIP responses are categorized as provisional (1xx) or final (2xx-6xx). Provisional responses provide informational status updates, such as 100 Trying, 180 Ringing, and 183 Session Progress, but their delivery over unreliable transport protocols like UDP was originally not guaranteed.
The PRACK method solves this reliability issue. When a User Agent Client (UAC), such as an IMS terminal, receives a provisional response that requires acknowledgement (indicated by the presence of a Require header with the value '100rel' in the response), it must send a PRACK request back to the User Agent Server (UAS), such as an IMS Application Server or another terminal. This PRACK request is a separate SIP transaction that reliably confirms the receipt of that specific provisional response. The provisional response itself contains a RSeq header (Response Sequence number), and the corresponding PRACK request contains a RACK header that echoes this RSeq number and a CSeq sequence number from the original INVITE transaction, ensuring precise matching.
Within the IMS network, PRACK messages traverse the same signaling path as the original INVITE, passing through Proxy Call Session Control Functions (P-CSCF), Serving CSCFs (S-CSCF), and any Application Servers (AS). These nodes act as stateful proxies for the INVITE transaction and must also handle the PRACK transaction correctly to maintain session state. The reliable delivery of provisional responses enabled by PRACK is crucial for several advanced telephony services. For example, it allows for reliable 'ringback tone' delivery (180 Ringing) and, more importantly, enables early media sessions. Early media permits media streams (like announcements or music-on-hold) to be established before the final answer (200 OK) to the INVITE, which is essential for pre-call services and seamless user experience.
The implementation and support of PRACK are mandated for IMS terminals and network elements that support the precondition and early media features. It forms a key part of the IMS service reliability framework alongside other SIP extensions like UPDATE. The handling of PRACK is specified in 3GPP TS 24.229 (IP multimedia call control protocol) and is integral to the IMS Multimedia Telephony service specifications.
Purpose & Motivation
PRACK was created to address a significant limitation in the base SIP protocol (RFC 3261) regarding the unreliable delivery of provisional responses. In the original SIP specification, provisional responses (1xx) were not acknowledged, making them unreliable when transported over UDP. This unreliability could lead to scenarios where a calling party never hears a ringback tone because the 180 Ringing message was lost, or where early media negotiations failed, degrading the user experience for services like video ringing or pre-call announcements.
The motivation stemmed from the telephony industry's requirement for reliable and predictable signaling, akin to that provided by traditional SS7/ISUP networks. For IMS to be a viable replacement for, and enhancement of, circuit-switched telephony services, it needed to guarantee the delivery of critical intermediate signaling messages. The IETF defined the extension in RFC 3262, which 3GPP subsequently adopted as a mandatory component for IMS implementations supporting certain features.
PRACK, along with the precondition framework, enables advanced service capabilities that were difficult or impossible with unreliable provisional responses. It solves the problem of race conditions during session establishment, particularly when resource reservation (via QoS mechanisms) and early media are involved. By providing a reliable handshake for provisional messages, it ensures that both ends of a session have a consistent and confirmed view of the call progress state, which is foundational for complex IMS services like Multimedia Telephony (MMTel), Voice over LTE (VoLTE), and Rich Communication Services (RCS).
Key Features
- Defined as a SIP method (like INVITE or BYE) for acknowledging provisional (1xx) responses.
- Uses the RSeq and RACK headers to uniquely correlate an acknowledgement with a specific provisional response.
- Enabled by the '100rel' option tag in the Supported or Require header fields of a SIP dialog.
- Creates a separate SIP transaction, ensuring reliable delivery over unreliable transports like UDP.
- Essential for the reliable operation of the SIP precondition framework (RFC 3312).
- Fundamental for enabling reliable early media sessions, where media flows before the final session answer.
Evolution Across Releases
PRACK was formally introduced into the 3GPP IMS specifications with the first full IMS profile defined in Release 8. It became a mandatory supported capability for IMS terminals and network elements (P-CSCF, S-CSCF) to enable reliable provisional responses, particularly for the Multimedia Telephony service for IMS (MTSI) and early media support.
Further integration and profiling of PRACK usage within enhanced IMS services, including its role in the Session Continuity and Voice Call Continuity (VCC) specifications. Clarifications and optimizations for its use in conjunction with the UPDATE method and preconditions.
PRACK remained a stable and critical part of the IMS core for 5G Voice over New Radio (VoNR). Its principles were unchanged but applied within the 5G Core (5GC) and the interaction between the UE and the IMS over the N1 interface, ensuring service continuity from previous generations.
Defining Specifications
| Specification | Title |
|---|---|
| TS 23.231 | 3GPP TS 23.231 |
| TS 26.982 | 3GPP TS 26.982 |
| TS 26.998 | 3GPP TS 26.998 |