Internet Engineering Task Force Bernie Hoeneisen Internet Draft Krisztian Kiss draft-kiss-sip-s100rel-00.txt Markus Isomaki Expires: January 2002 Nokia July 2001 Simple way of Reliability of Provisional Responses in SIP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. The extension can be seen as an alternative proposal of [6], where the method PRACK and the package 100rel are described. Hoeneisen/Isomaki/Kiss Internet Draft [Page 1] Internet-Draft Simple 100rel July 2001 This extension uses the option tag s100rel, and the difference compared to 100rel extension [6] is mainly that - unlike PRACK - the SPRACK request - similarly to the ACK request - does not need a response. This Internet-Draft assumes the reader has the knowledge of 100rel extension [6] and therefore it only concentrates on the differences compared to [6]. 1 Introduction This document provides an alternative of [6], where an extension is defined to SIP for ensuring that provisional responses to all SIP requests can be delivered reliably end to end, independent of the underlying transport mechanism. Similarly to [6] the extension works for provisional responses for any method (excepting ACK, of course, which have no responses, PRACK, defined in [6], and SPRACK, defined here). The extension defines one new method (SPRACK), and the two header fields required by the extension agree with the header fields defined in [6]. Unlike 100rel, the s100rel extension requires support in proxies. The s100rel extension is indicated with the option tag s100rel. The motivation for defining an alternative approach to [6] is that certain networks, e.g. cellular networks, have limited bandwidth for signalling purposes. Thus every extra message in the session initiation increases the duration of the session setup, which might cause that the session setup delay crosses the acceptable limit. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations. 3 Basic Overview The reliability mechanism for provisional responses equals as it is defined in [6]. Provisional responses are retransmitted with an exponential backoff. Those retransmissions cease when a SPRACK message is received. The SPRACK request plays the same role as ACK, but for provisional responses. Hoeneisen/Isomaki/Kiss Internet Draft [Page 2] Internet-Draft Simple 100rel July 2001 However, SPRACK, as ACK, is end-to-end, which is different from a normal SIP message, like BYE, where the reliability is ensured hop-by-hop through each stateful proxy. Similarly as ACK, SPRACK has no response. This requires that all proxies need to understand this extension. If this requirement cannot be fulfilled, the SPRACK request cannot traverse existing proxy servers. 4 Detailed Overview of Operation The reliability mechanism for provisional responses equals as it is defined in [6]. The UAC can determine that the response is to be transmitted reliably by the presence of the Require header containing the option tag s100rel. Responses which are not transmitted reliably do not contain this tag in a Require header. The rules for creating the header fields (RSeq, RAck, Call-ID, CSeq) of SPRACK request are the same as for PRACK request defined in [6]. Similarly to ACK request, the SPRACK request MUST be retransmitted when retransmissions of the corresponding provisional response are received. When the UAS receives the SPRACK request, it knows that the provisional response has been received. The UAS then ceases retransmission of that provisional response. However - unlike in case of PRACK request - the UAS does not generate a response to the SPRACK. Other rules for UAS behavior equal as it is defined in [6, chapter 4]. This extension MUST NOT be used together with the 100rel extension described in [6], as this would cause unpredictable behavior. Hoeneisen/Isomaki/Kiss Internet Draft [Page 3] Internet-Draft Simple 100rel July 2001 5 Extension Syntax The definition of RSeq and RAck header fields is equal to the definition described in [6, chapter 5]. The method specified here is called SPRACK. Sprack = "SPRACK" As with other methods, the SPRACK method name is case sensitive. The method name in the RAck header is also case sensitive. This document specifies the named extension s100rel. This feature name is placed in the Proxy-Require, Require, Supported or Proxy-Supported [7] header in requests, or the Require, Supported, Unsupported or Proxy-Supported [7] header in responses [4]. 6 Detailed Protocol Semantics In this section, we discuss the detailed behavior required from user agent clients, user agent servers, and proxies, in order to implement this extension. 6.1 UAC Behavior If the UAC wishes to insist that all provisional responses are delivered reliably, it MUST include a Require header along with a Proxy-Supported header [7] into the request containing the option tag s100rel. Otherwise, if a UAC supports this extension, it MUST include a Proxy-Supported header [7] into all requests (excepting ACK, PRACK and SPRACK), with the name s100rel listed as an option tag. The support of the extension SHOULD be also indicated in a Supported header present in the request. Hoeneisen/Isomaki/Kiss Internet Draft [Page 4] Internet-Draft Simple 100rel July 2001 The request whose provisional response is being reliably sent is referred to as the initial request. If a provisional response is received for the initial request, and that response contains a Require and a Proxy-Supported header containing the option tag s100rel, the response is to be sent reliably. If the response is a 100 (as opposed to 101 to 199), this option tag is ignored. The reliability mechanisms defined here MUST NOT be used on 100 responses. Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method SPRACK. The rules for creating Call-ID, CSeq, To, From, Via, Timestamp, Supported and Require headers, handling bodies and credentials equal as it is defined in [6, chapter 6.1]. It is assumed that reliable provisional responses contain Record-Route headers, thus the SPRACK request MUST contain Route headers according to the procedures specified in [1], as if the SPRACK were a BYE. The Route header that is constructed from some provisional response MUST NOT be placed in any other request except for the SPRACK for that specific provisional response. For reliable provisional responses to a request that contained Route headers, the SPRACK MUST contain the same Route headers as the request. Once the SPRACK request is created, it is sent by the UAC. It is sent as would an ACK request for a call. In particular, when sent over UDP, the SPRACK request MUST be retransmitted when the UAC receives a retransmission of the provisional response being acknowledged. A reliable provisional response for which a SPRACK request has been sent is called an acknowledged reliable provisional response. A SPRACK request MUST NOT be cancelled - that is, a UAC MUST NOT ever send a CANCEL for a SPRACK request. Handling of subsequent reliable provisional responses equals to [6, chapter 6.1]. Hoeneisen/Isomaki/Kiss Internet Draft [Page 5] Internet-Draft Simple 100rel July 2001 6.2 UAS Behavior The UAS MAY send any non-100 provisional response reliably, so long as the initial request contained a Supported and a Proxy-Supported header indicating that this feature is understood. The UAS MUST send any non-100 response reliably if the initial request contained a Proxy-Supported and a Require header indicating that the feature is mandatory for all provisional responses. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include a Unsupported header containing the option tag s100rel. A UAS MUST NOT attempt to send a 100 response reliably. Only responses numbered 101 to 199 may be sent reliably. A UAS MUST NOT send a reliable provisional response to a PRACK request, in order to avoid provisional/PRACK loops. If the request did not include a Proxy-Supported header indicating this feature is understood by every record-routing proxy, but it included a Supported or a Require header indicating this feature, the UAS either SHOULD send the provisional response using the reliability mechanism defined in [6] or it SHOULD send the provisional response unreliably. If the request did not include either a Supported or Require header indicating this feature, the UAS SHOULD send the provisional response unreliably. The rest of this discussion assumes that the initial request contained a Supported or Require header and also a Proxy-Supported header listing this feature, and that there is a provisional response to be sent reliably. Note that a UAS can send reliable provisional responses for any request, excepting a SPRACK request, PRACK and ACK. It is anticipated that reliable provisional responses will be most useful for INVITE requests. Hoeneisen/Isomaki/Kiss Internet Draft [Page 6] Internet-Draft Simple 100rel July 2001 The provisional response to be sent reliably MUST include a Require and a Proxy-Supported header containing the option tag s100rel. The rules for creating Call-ID, CSeq, To, From, Via, Timestamp, and Contact headers, handling bodies and credentials, rules for matching SPRACK request with its provisional response and rule for cancelling PRACK equal as it is defined in [6, chapter 6.2]. It is assumed that the initial request contained Record-Route headers, thus the provisional response MUST contain a copy of those headers, as if the response were a 200 OK to the initial request. If a SPRACK request is received that matches a provisional response for which no SPRACK has been received, the provisional response retransmission ceases. The UAS can be certain at this point that the provisional response has been received in order. Thus, there is no need to retransmit the reliable provisional response when a SPRACK is received. The UAS generates a no response to the SPRACK. If the SPRACK contained a body, the body is treated in the same way a body in an ACK is treated. The rule for sending additional reliable provisional responses equal as it is defined in [6, chapter 6.2]. 6.3 Proxy Behavior This extension does require support from proxies and therefore the proxies MUST recognize s100rel option tag present in the Proxy-Supported header of the initial request. Proxies need to maintain Proxy-Supported header and proxy-supported Record-Route parameter in the initial request according to [7]. SPRACK requests are treated similar than ACK requests for 2xx responses. The SPRACK messages are end-to-end, and thus not retransmitted by intermediate proxies. A proxy forwards the SPRACK request like an ACK request for a 2xx response; no transaction state is maintained, not even in stateful proxies. Hoeneisen/Isomaki/Kiss Internet Draft [Page 7] Internet-Draft Simple 100rel July 2001 In all cases, the SPRACK will have Route headers to indicate its proxy path. A requirement for proxies is that they MUST pass all provisional responses upstream. RFC 2543 does not mandate that provisional responses are forwarded, although most proxy implementations do. Rules for proxies, which generate their own provisional responses to be sent reliably, equal as it is defined in [6, chapter 6.3]. 7 Example Message Formatting In this example, a UAC sends an INVITE to a UAS via a proxy server. The UAS sends a 183 response reliably. The UAC determines with the help of the Proxy-Supported header whether the proxy server supports the s100rel extension. The initial request looks like: A->P: INVITE sip:watson@bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com Supported: s100rel Proxy-Supported: s100rel From: sip:alexander@bell-tel.com;tag=736ad7789 Contact: sip:alexander@host33.bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE Content-length: 0 The proxy server forwards the request to B: P->B: INVITE sip:watson@bell-tel.com SIP/2.0 Via: SIP/2.0/UDP proxy.bell-tel.com Via: SIP/2.0/UDP saturn.bell-tel.com Supported: s100rel Proxy-Supported: s100rel From: sip:alexander@bell-tel.com;tag=736ad7789 Contact: sip:alexander@host33.bell-tel.com To: sip:watson@bell-tel.com Record-Route: sip:proxy.bell-tel.com;proxy-supported=yes Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE Subject: Come here Watson Content-length: 0 Hoeneisen/Isomaki/Kiss Internet Draft [Page 8] Internet-Draft Simple 100rel July 2001 B sends a 183 reliably: B->P: SIP/2.0 183 Proceeding Require: s100rel Proxy-Supported: s100rel Via: SIP/2.0/UDP proxy.bell-tel.com Via: SIP/2.0/UDP saturn.bell-tel.com RSeq: 776655 From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Record-Route: sip:proxy.bell-tel.com;proxy-supported=yes Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE Content-Type: application/sdp Content-length: ... The proxy server forwards the 183 to A: P->A: SIP/2.0 183 Proceeding Require: s100rel Proxy-Supported: s100rel Via: SIP/2.0/UDP saturn.bell-tel.com RSeq: 776655 From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Record-Route: sip:proxy.bell-tel.com;proxy-supported=yes Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE Content-Type: application/sdp Content-length: ... This response is retransmitted with an exponential backoff. When A receives the response, it sends a SPRACK: A->P: SPRACK sip:proxy.bell-tel.com SIP/2.0 RAck: 776655 1 INVITE Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 2 SPRACK Route: sip:watson@mypc.bell-tel.com Content-Type: application/sdp Content-length: ... Hoeneisen/Isomaki/Kiss Internet Draft [Page 9] Internet-Draft Simple 100rel July 2001 The proxy server forwards the request to B: P->B: SPRACK sip:watson@mypc.bell-tel.com SIP/2.0 RAck: 776655 1 INVITE Via: SIP/2.0/UDP proxy.bell-tel.com Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 2 SPRACK Content-Type: application/sdp Content-length: ... Upon receiving this, the UAS stops retransmitting the 183, and the session initiation continues further normally. 8 Security Considerations This extension introduces no new security considerations beyond those discussed in [6]. 9 Author's Addresses Bernie Hoeneisen Nokia Networks Valimo 13B/3 P.O. Box 314 FIN-00045 NOKIA GROUP email: bernhard.honeisen@nokia.com Krisztian Kiss Nokia Research Center Visiokatu 1 P.O. Box 100 FIN-33721 TAMPERE email: krisztian.kiss@nokia.com Hoeneisen/Isomaki/Kiss Internet Draft [Page 10] Internet-Draft Simple 100rel July 2001 Markus Isomaki Nokia Research Center Ruoholahti 1/B6 P.O. Box 407 FIN-00045 NOKIA GROUP email: markus.isomaki@nokia.com 10 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A. Roach, "SIP 183 session progress message," Internet Draft, Internet Engineering Task Force, Oct. 1999. Work in progress. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [4] J. Rosenberg and H. Schulzrinne, "The SIP supported header," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [5] W. Marshall, K. Ramakrishnan, et al., "Integration of resource management and SIP," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [6] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses in SIP," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [7] B. Hoeneisen, M. Isomaki, K. Kiss, "The SIP Proxy-Supported header field", Internet Draft, Internet Engineering Task Force, July 2001. Work in progress Hoeneisen/Isomaki/Kiss Internet Draft [Page 11]