Description
A Provisional response is a Session Initiation Protocol (SIP) response message that indicates the server has received the request and is processing it, but has not yet completed the transaction. In SIP, responses are categorized by status codes: 1xx responses are provisional, while 2xx, 3xx, 4xx, 5xx, and 6xx responses are final. Provisional responses are used to provide feedback to the client during lengthy operations, preventing timeouts and allowing the client to maintain the transaction state. They are defined in IETF RFC 3261 and are integral to the 3GPP IP Multimedia Subsystem (IMS) architecture, where SIP is the core signaling protocol.
In a SIP transaction, the client sends a request (e.g., INVITE) to a server. The server may send one or more provisional responses (e.g., 100 Trying, 180 Ringing, 183 Session Progress) before sending a final response. The 100 Trying response is typically sent immediately to stop retransmissions of the INVITE. The 180 Ringing response indicates the user is being alerted. The 183 Session Progress response can carry early media, such as ringback tones or announcements. Provisional responses are not acknowledged by the client at the SIP layer, but they are part of the transaction and must be handled correctly. The server must send a final response to complete the transaction, unless the transaction is cancelled.
Provisional responses are crucial for interoperability and user experience. They allow the network to signal progress without committing to the session. In IMS, provisional responses are used in conjunction with the Session Description Protocol (SDP) to negotiate media parameters. For example, a 183 Session Progress may contain an SDP offer or answer, enabling early media. The PRACK (Provisional Response Acknowledgement) mechanism, defined in RFC 3262, provides reliable delivery of provisional responses, ensuring that important provisional responses are not lost. This is particularly important for services like call waiting and preconditions.
The 3GPP specifications (24.408, 24.508, 24.608, 29.998) reference provisional responses in the context of IMS and other SIP-based services. These specifications define how IMS entities such as the P-CSCF, S-CSCF, and AS handle provisional responses. For instance, the P-CSCF may generate provisional responses on behalf of the network, while the S-CSCF routes them based on service logic. The term is also used in other 3GPP-defined protocols, such as the SIP-based messaging in Mission Critical Push-to-Talk (MCPTT).
In summary, a provisional response is a fundamental SIP concept that enables robust session establishment. It provides progress information, supports early media, and is essential for reliable transaction management. Its definition in 3GPP specifications ensures consistent behavior across IMS implementations, contributing to seamless interoperability and enhanced user experience.
Purpose & Motivation
Provisional responses exist to address the need for progress indication in SIP transactions, which can take time to complete due to network delays, user alerting, or complex service logic. Without provisional responses, a client would have to wait for a final response without any feedback, leading to timeouts and poor user experience. The 1xx responses solve this by allowing the server to signal that the request is being processed, thereby keeping the transaction alive and informing the client of the current state.
Historically, SIP was designed to be a lightweight and extensible protocol for establishing, modifying, and terminating multimedia sessions. The concept of provisional responses was inherited from HTTP, where 1xx responses serve a similar purpose. In SIP, provisional responses are particularly important for INVITE transactions, where the called party may take several seconds to answer. The 180 Ringing response provides audible feedback to the caller, while 183 Session Progress enables early media, such as custom ringback tones. The PRACK mechanism was later introduced to ensure reliable delivery of provisional responses, addressing the limitation of unreliable UDP transport.
In 3GPP networks, provisional responses are essential for IMS services, including voice over LTE (VoLTE) and voice over NR (VoNR). They enable features like call forwarding, call waiting, and conferencing. The definition of provisional response in 3GPP specifications ensures that all IMS entities handle these responses consistently, which is critical for interoperability between different vendors and networks. As SIP continues to evolve, provisional responses remain a cornerstone of session management.
What changed in its specifications
The latest release-to-release comparison of specifications that define Provisional response. Each summary describes the whole specification, not only this term.
Rel-9 added XCAP reference and authorization rules for terminating identity presentation service elements.
Full comparison in TS 24.608 →Release Timeline
Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Defining Specifications
3GPP specifications that define or reference Provisional response, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.408 v700 | TIP/TIR Services Protocol Specification | Rel-7 read |
| TS 24.508 v820 | TIP and TIR Service Protocol Description | Rel-8 read |
| TS 24.608 vj00 | 3GPP TS 24608: TIP/TIR Services Protocol | Rel-19 read |
| TR 29.998 v320 | OSA API Mapping to CAP and MAP | R99 read |