SIP Working Group C. Holmberg Internet-Draft Ericsson Intended status: Informational June 10, 2008 Expires: December 12, 2008 Indication of support for keep-alive draft-holmberg-sip-keep-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet-Draft will expire on December 12, 2008. Abstract This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. Holmberg Expires December 12, 2008 [Page 1] Internet-Draft STUN-keep June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Overlap with connection reuse . . . . . . . . . . . . . . . . . 5 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 11.1. IANA Registration of the SIP Via keep parameter . . . . . 7 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 13.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Holmberg Expires December 12, 2008 [Page 2] Internet-Draft STUN-keep June 2008 1. Introduction Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] defines two keep-alive techniques. Even though the keep-alive techniques are separated from the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not possible to indicate support of the keep-alive techniques without also indicating support for the Outbound mechanism. The Outbound mechanism is enabled during the UA registration phase. However, there are use-cases where the UA does not register itself, but still needs to be able to make calls and maintain NAT bindings open during the duration of that call. A typical example is emergency calls. There are also cases where entities do not support the Outbound mechanism, but still want to be able to indicate support and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. This specification defines a new SIP Via header parameter, "keep", which can be used by a UA to indicate support of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. The UA will insert the "keep" parameter in the Via header of the REGISTER request, or the initial session request if not registered. This specification also defines a "yes" value for the "keep" parameter. The edge proxy will add a "yes" value to the "keep" parameter, if received in the topmost Via header, to indicate support of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions Edge proxy: As defined in [I-D.ietf-sip-outbound], an Edge Proxy is any proxy that is located topologically between the registering User Agent and the Authoritative Proxy. The "first" edge proxy refers to the first edge proxy encountered when a UA sends a request. 'keep' Parameter: The 'keep' parameter is a SIP Via header parameter which indicates that the entity inserting the parameter supports the keep-alive techniques defined in [I-D.ietf-sip-outbound]. The parameter may carry an associated parameter value. Holmberg Expires December 12, 2008 [Page 3] Internet-Draft STUN-keep June 2008 4. Requirements REQ 1: It MUST be possible for a UA to indicate support of the keep- alive techniques defined [I-D.ietf-sip-outbound] if the UA supports only the keep-alive part of [I-D.ietf-sip-outbound]. REQ 2: It MUST be possible for an edge proxy to indicate support of the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. 5. Client behavior A UA which supports the method defined in this specification MUST act as a STUN client [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN which is required to apply the STUN keep-alive technique [I-D.ietf-sip-outbound]. When a UA which supports the method defined in this specification sends a SIP REGISTER request the UA MUST insert a "keep" Via parameter in the SIP request. If the Via header in the SIP REGISTER response contains a "keep" parameter with a "yes" value, the UA knows that the keep-alive techniques defined in [I-D.ietf-sip-outbound] can be used between the UA and the edge proxy during the duration of the registration. If the SIP REGISTER response contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UA uses the server recommended keepalive frequency provided in the header, the UA SHOULD send its keepalives so that the interval between each keepalive is randomly distributed between 80% and 100% of the server provided time. If no Flow-Timer header field was present in the SIP REGISTER response, the UA can send keepalives at its discretion. The UA must insert a "keep" parameter even if the UA also indicates support of Outbound [I-D.ietf-sip-outbound], to allow keep-alive usage in cases where the edge proxy will only support "keep". When a UA which supports the method defined in this specification sends an initial SIP request, and the UA has not registered itself via the edge proxy towards which the SIP request is sent, the UA MUST include a "keep" Via parameter in the SIP request. If the Via header header in the initial SIP responses contains a "keep" parameter with a "yes" value, the UA knows that the keep-alive techniques defined in [I-D.ietf-sip-outbound] can be used between the UA and the edge proxy during the duration of the call. If the initial SIP response contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UA uses the server recommended keepalive frequency provided in the header, the UA SHOULD send its keepalives so that the interval between each keepalive is randomly distributed between 80% and 100% of the server provided time. If no Flow-Timer header field was present in the Holmberg Expires December 12, 2008 [Page 4] Internet-Draft STUN-keep June 2008 initial SIP response, the UA can send keepalives at its discretion. If the UA wishes to apply keep-alive for future calls, it MUST insert a "keep" Via parameter in the initial SIP request of those calls. NOTE: Since there are clients that already use CRLF keep-alives, and proxies are expected to be able to receive it, this specification does not forbid the sending of CRLF keep-alives even when no "keep=yes" indication has been received from the edge proxy. However, the indicator is still important in order for the client to inform the edge proxy that the client supports CRLF keep-alives, so that the edge proxy does not use other mechanisms (e.g. short registration refresh intervals) in order to make sure the NAT bindings are kept open. 6. Server behavior This specification does not define new server procedures. 7. Proxy behavior An edge proxy which supports the method defined in this specification MUST act as a STUN server [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN which is required to apply the STUN keep- alive technique [I-D.ietf-sip-outbound]. The edge proxy MUST also process double-CRLF keep-alives, as defined in [I-D.ietf-sip-outbound]. When an edge proxy that supports the method defined in this specification recieves a SIP REGISTER request which contains a "keep" parameter in the topmost Via header the edge proxy MUST add a "yes" value to the "keep" parameter. In addition the edge proxy MAY include a Flow-Timer header field if the associated SIP REGISTER response. When an edge proxy that supports the method defined in this specification recieves an initial SIP request which contains a "keep" parameter in the topmost Via header the edge proxy MUST add a "yes" value to the "keep" parameter. In addition the edge proxy MAY include a Flow-Timer header field if the associated initial SIP response. 8. Overlap with connection reuse The connect-reuse specification [connect-reuse] specifies how to use connection-oriented transports to send requests in the reverse Holmberg Expires December 12, 2008 [Page 5] Internet-Draft STUN-keep June 2008 direction. SIP entity A opens a connection to entity B in order to send a request. Under certain conditions entity B can reuse that connection for sending requests in the backwards direction to A as well. However, the connect-reuse specification does not define a keep-alive mechanism for this connection. The technique specified in this draft is thus orthogonal to the purpose of connection reuse. An entity that wants to use connection- reuse as well as indicate keep-alive mechanism on that connection will insert both the "alias" parameter defined in [connect-reuse] as well as the "keep" parameter defined in this memo. Inserting only one of these parameters is not a substitute for the other. Thus, while the presence of a "keep" parameter will indicate that the enity supports keep-alives in order to keep the connection open, no inference can be drawn on whether that connection can be used for requests in the backwards direction. 9. Example The figure shows an example where a non-registered UAC sends an INVITE reuqest, in which it indicates support of keep-alive by inserting a "keep" parameter in the Via header of the INVITE request. The edge proxy (P1) also supports the keep-alive mechanism, so it adds a "yes" value to the "keep" parameter to the Via header of the UAC. The request is then fowarded towards the UAS. When UAC receives the 200 OK (INVITE) response from the UAS it finds out that the edge proxy supports keep-alive. After that the UAC sends periodic keep-alives (in this example using the STUN keep-alive technique) during the duration of the call. The edge proxy (P1) has inserted a Flow-Timer header in the 200 OK (INVITE), indicating a recommented keep-alive interval of 30 seconds. Holmberg Expires December 12, 2008 [Page 6] Internet-Draft STUN-keep June 2008 UAC P1 UAS --- INVITE ---------------> Via: UAC;keep --- INVITE -----------------> Via: UAC;keep=yes Via: P1 <-- 200 OK ------------------ Via: UAC;keep=yes Via: P1 <-- 200 OK ---------------- Via: UAC;keep=yes Flow-Timer: 30 --- ACK ------------------> --- ACK --------------------> *** Timeout *** === STUN request =========> <== STUN response ========= *** Timeout *** === STUN request =========> <== STUN response ========= --- BYE ------------------> --- BYE ---------------------> <-- 200 OK ------------------- Figure 1: Example call flow 10. Security Considerations 11. IANA Considerations 11.1. IANA Registration of the SIP Via keep parameter Holmberg Expires December 12, 2008 [Page 7] Internet-Draft STUN-keep June 2008 12. Acknowledgements Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer and Milo Orsic for their comments on the initial draft. Thanks to Juha Heinaenen, Jiri Kuthan and Dean Willis for their comments on the list. Thanks to Vijay Gurbani for providing text about the relationship with the connect-reuse specification. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 13.2. Informative References [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-14 (work in progress), May 2008. [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-15 (work in progress), February 2008. Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires December 12, 2008 [Page 8] Internet-Draft STUN-keep June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Holmberg Expires December 12, 2008 [Page 9]