Reliability of Provisional Responses in Session Initiation Protocol (SIP)
RFC 3262
Document | Type |
RFC - Proposed Standard
(July 2002; Errata)
Obsoletes RFC 2543
Was draft-ietf-sip-100rel (sip WG)
|
|
---|---|---|---|
Authors | Henning Schulzrinne , Jonathan Rosenberg | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3262 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note |
RFCs 3261-3265 Responsible: Finished |
||
Send notices to | sipcore@ietf.org, dispatch@ietf.org |
Network Working Group J. Rosenberg Request for Comments: 3262 dynamicsoft Category: Standards Track H. Schulzrinne Columbia U. June 2002 Reliability of Provisional Responses in the Session Initiation Protocol (SIP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. Table of Contents 1 Introduction ........................................ 2 2 Terminology ......................................... 3 3 UAS Behavior ........................................ 3 4 UAC Behavior ........................................ 6 5 The Offer/Answer Model and PRACK .................... 9 6 Definition of the PRACK Method ...................... 10 7 Header Field Definitions ............................ 10 7.1 RSeq ................................................ 10 7.2 RAck ................................................ 11 8 IANA Considerations ................................. 11 8.1 IANA Registration of the 100rel Option Tag .......... 11 8.2 IANA Registration of RSeq and RAck Headers .......... 12 9 Security Considerations ............................. 12 10 Collected BNF ....................................... 12 11 Acknowledgements .................................... 12 12 Normative References ................................ 13 13 Informative References .............................. 13 Rosenberg & Schulzrinne Standards Track [Page 1] 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 [Page 2] RFC 3262 Reliability of Provisional Responses in SIP June 2002Show full document text