RFC 3262 (rfc3262) - Page 2 of 14
Reliability of Provisional Responses in Session Initiation Protocol (SIP)
Alternative Format: Original Text Document
RFC 3262 Reliability of Provisional Responses in SIP June 2002
14 Authors' Addresses .................................. 13
15. Full Copyright Statement............................. 14
1 Introduction
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-
response protocol for initiating and managing communications
sessions. SIP defines two types of responses, provisional and final.
Final responses convey the result of the request processing, and are
sent reliably. Provisional responses provide information on the
progress of the request processing, but are not sent reliably in RFC
3261.
It was later observed that reliability was important in several
cases, including interoperability scenarios with the PSTN.
Therefore, an optional capability was needed to support reliable
transmission of provisional responses. That capability is provided
in this specification.
The reliability mechanism works by mirroring the current reliability
mechanisms for 2xx final responses to INVITE. Those requests are
transmitted periodically by the Transaction User (TU) until a
separate transaction, ACK, is received that indicates reception of
the 2xx by the UAC. The reliability for the 2xx responses to INVITE
and ACK messages are end-to-end. In order to achieve reliability for
provisional responses, we do nearly the same thing. Reliable
provisional responses are retransmitted by the TU with an exponential
backoff. Those retransmissions cease when a PRACK message is
received. The PRACK request plays the same role as ACK, but for
provisional responses. There is an important difference, however.
PRACK is a normal SIP message, like BYE. As such, its own
reliability is ensured hop-by-hop through each stateful proxy. Also
like BYE, but unlike ACK, PRACK has its own response. If this were
not the case, the PRACK message could not traverse proxy servers
compliant to RFC 2543 [4].
Each provisional response is given a sequence number, carried in the
RSeq header field in the response. The PRACK messages contain an
RAck header field, which indicates the sequence number of the
provisional response that is being acknowledged. The acknowledgments
are not cumulative, and the specifications recommend a single
outstanding provisional response at a time, for purposes of
congestion control.
Rosenberg & Schulzrinne Standards Track