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
