RFC 3262 (rfc3262) - Page 2 of 14

Reliability of Provisional Responses in Session Initiation Protocol (SIP)

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