SIPCORE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Informational May 31, 2010 Expires: December 2, 2010 Indication of support for keep-alive draft-ietf-sipcore-keep-04.txt Abstract This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Holmberg Expires December 2, 2010 [Page 1] Internet-Draft STUN-keep May 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use-case: Session from non-registered UAs . . . . . . . . 3 1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3 1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Lifetime of keep-alives . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. Keep-alives associated with registration . . . . . . . 5 4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6 4.4. Behavior of a SIP entity willing to receive keep-alives . 7 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Keep-alive negotiation associated with registration: UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 10 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Holmberg Expires December 2, 2010 [Page 2] Internet-Draft STUN-keep May 2010 1. Introduction Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive mechanisms. Eventhough the keep-alive mechanisms are separated from the rest of the SIP Outbound mechanism, SIP Outbound does not define a mechanism to explicitly negotiate usage of the keep-alive mechanisms, since usage of keep-alives in most cases are implicitly negotiated as part of the SIP Outbound negotiation. However, there are SIP Outbound use-cases where usage of keep-alives are not implicitly negotiated as part of the SIP Outbound negotiation. In addition, there are cases where SIP Outbound is not supported, where it cannot be applied, but where there is still a need to be able to negotiate usage of keep-alives. This specification defines a new Session Initiation Protocol (SIP) [RFC3261] Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the NAT keep-alive mechanisms defined in SIP Outbound. The "keep" parameter allows SIP entities to indicate willingness to send keep-alives, to indicate willingness to receive keep-alives, and for SIP entities willing to receive keep-alives to provide a recommended keep-alive frequency. The following sections describe use-cases where a mechanism to explicitly negotiate usage of keep-alives is needed. 1.1. Use-case: Session from non-registered UAs In some cases a User Agent Client (UAC) does not register itself before it establishes a session, but in order to maintain NAT bindings open during the session it still needs to be able to negotiate sending of keep-alives towards its adjacent upstream SIP entity. A typical example is an emergency call, where a registration is not always required in order to make the call. 1.2. Use-case: SIP Outbound not supported In some cases all SIP entities that need to be able to negotiate the usage of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them. 1.3. Use-case: SIP dialog initiated Outbound flows SIP Outbound allows the establishment of flows using the initial request for a dialog. As specified in [RFC5626], usage keep-alives is not implicitly negotiated for such flows, why usage needs to be explicitly negotiated. Holmberg Expires December 2, 2010 [Page 3] Internet-Draft STUN-keep May 2010 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 [RFC5626], a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy. NOTE: In some deployments the edge proxy might physically be located in the same entity as the Authoritative Proxy. Keep-alives: Refers to keep-alive messages as defined in SIP Outbound [RFC5626]. "keep" parameter: A SIP Via header field parameter that a SIP entity can insert in its Via header field of a request to explicitly indicate willingness to send keep-alives towards it adjacent upstream SIP entity. If a SIP entity is willing to receive keep-alives from its adjacent downstream SIP entity, and the Via header field associated with the adjacent downstream SIP entity contains a "keep" parameter, the SIP entity willing to receive keep-alives can add an integer parameter value to that "keep" parameter. The integer parameter value can be used to indicate a recommended keep-alive frequency. A zero value indicates that the SIP entity is willing to receive keep-alives, but that a recommended keep-alive frequency is not provided. SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 4. User Agent and Proxy behavior 4.1. General This section describes how SIP UAs and proxies negotiate usage of keep-alives associated with a registration, or a dialog, which types of SIP requests types can be used in order to negotiate the usage, and the lifetime of the negotiated keep-alives. SIP entities indicate willingness to send keep-alives towards the adjacent upstream SIP entity using SIP requests. The associated responses are used by SIP entities to indicate willingness to receive Holmberg Expires December 2, 2010 [Page 4] Internet-Draft STUN-keep May 2010 keep-alives. SIP entities that indicate willingness to receive keep- alives can provide a recommended keep-alive frequency. The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies. NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from its adjacent downstream SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated. NOTE: Since there are SIP entities that already use a combination of Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP entities are expected to be able to receive those, this specification does not forbid the sending of CRLF keep-alive messages towards an adjacent upstream SIP entity even if usage of keep-alives have not been negotiated. However, the "keep" parameter is still important in order for a SIP entity to indicate that it supports sending of CRLF keep-alive messages, so that the adjacent upstream SIP entity does not use other mechanisms (e.g. short registration refresh intervals) in order to keep NAT bindings open. 4.2. Lifetime of keep-alives 4.2.1. General The lifetime of negotiated keep-alives depends on whether the keep- alives are associated with a registration or a dialog. The section describes the lifetime of negotiated keep-alives. 4.2.2. Keep-alives associated with registration SIP entities use a registration request in order to negotiate usage of keep-alives associated with a registration. Usage of keep-alives can be negotiated when the registration is established, or later during the lifetime of the registration. Once negotiated, keep- alives are sent until the registration is terminated, or until a subsequent registration refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded, if a SIP entity is willing to continue sending keep-alives associated with the registration, usage of keep-alives MUST be re-negotiated. If usage is not successfully re-negotiated, the SIP entity MUST cease sending of keep-alives associated with the registration. In case a SIP entity establishes multiple registration flows [RFC5626], usage of keep-alives needs to be negotiated separately for each individual registration flow. A SIP entity MUST NOT send keep- alives associated with a registration flow for which usage of keep- Holmberg Expires December 2, 2010 [Page 5] Internet-Draft STUN-keep May 2010 alives has not been negotiated. 4.2.3. Keep-alives associated with dialog SIP entities use an initial request for a dialog, or a mid-dialog target refresh request [RFC3261], in order to negotiate sending and receiving of keep-alives associated with a dialog. Usage of keep- alives can be negotiated when the dialog is established, or later during the lifetime of the dialog. Once negotiated, keep-alives MUST be sent for the lifetime of the dialog, until the dialog is terminated. Once usage of keep-alives associated with a dialog has been negotiated, it is not possible to re-negotiate the usage associated with the dialog. 4.3. Behavior of a SIP entity willing to send keep-alives As defined in [RFC5626], a SIP entity that supports sending of keep- alives must act as a Session Traversal Utilities for NAT (STUN) client [RFC5389]. The SIP entity must support the amount of STUN which is required to apply the STUN keep-alive mechanism defined in [RFC5626], and it must support the CRLF keep-alive mechanism defined in [RFC5626]. When a SIP entity sends or forwards a request, if it wants to negotiate the sending of keep-alives for the lifetime of a registration (in case of a REGISTER request), or a dialog (in case of an initial request for a dialog, or a mid-dialog target refresh request), it MUST insert a "keep" parameter in its Via header field of the request. When the SIP entity receives the associated response, if the "keep" parameter in its Via header field of the response contains a parameter value, it MUST start to send keep-alives towards the same destination where it would send a subsequent request (e.g. REGISTER requests and initial requests for dialog) associated with the registration (if the keep-alive negotiation is for a registration), or where it would send subsequent mid-dialog requests (if the keep- alive negotiation is for a dialog). Subsequent mid-dialog requests are addressed based on the dialog route set. Once a SIP entity has negotiated sending of keep-alives associated with a dialog towards its adjacent upstream SIP entity, it MUST NOT insert a "keep" parameter in any subsequent SIP requests associated with the dialog. Such "keep" parameter MUST be ignored, if received. Since an ACK request does not have an associated response, it can not be used to negotiate usage of keep-alives. Therefore, a SIP entity MUST NOT insert a "keep" parameter in its Via header field of an ACK Holmberg Expires December 2, 2010 [Page 6] Internet-Draft STUN-keep May 2010 request. Such "keep" parameter MUST be ignored, if received. When a SIP entity is about to send a keep-alive, if the SIP entity at the same time is also about to send or forward a SIP request associated with the same registration or dialog, for which the keep- alive is to be sent, the SIP entity MAY choose not to send the keep- alive, as the SIP request will perform the same keep-alive action. NOTE: When a SIP entity sends an initial request for a dialog, if the adjacent upstream SIP entity does not insert itself in the dialog route set using a Record-Route header field [RFC3261], the adjacent upstream SIP entity will change once the dialog route set has been established. If a SIP entity inserts a "keep" parameter in its Via header field of an initial request for a dialog, and the "keep" parameter in the associated response does not contain a parameter value, the SIP entity might choose to insert a "keep" parameter in its Via header field of a subsequent SIP request associated with the dialog, in case the new adjacent SIP entity (based on the dialog route set) is willing to receive keep-alives (in which case it will add a parameter value to the "keep" parameter). NOTE: If a SIP entity inserts a "keep" parameter in its Via header field of an INVITE request, and it receives multiple responses (provisional or final) associated with the request, as long as at least one of the responses, per dialog, contains a "keep" parameter with a parameter value it is seen as an indication that the adjacent upstream SIP entity is willing to receive keep-alives associated with the dialog. 4.4. Behavior of a SIP entity willing to receive keep-alives As defined in [RFC5626], a SIP entity that supports receiving of keep-alives must act as a STUN server [RFC5389]. The SIP entity must support the amount of STUN which is required to apply the STUN keep- alive mechanism defined in [RFC5626], and it must support the CRLF keep-alive mechanism defined in [RFC5626]. When a SIP entity creates or receives a response to a request that can be used in order to indicate willingness to send keep-alives associated with a registration or dialog, and the Via header field associated with the adjacent downstream SIP entity (that is, the top- most Via header field once a SIP entity that received the response has removed its own Via header field from the response) contains a "keep" parameter, if the SIP entity is willing to receive keep-alives associated with the registration (in case of a REGISTER response), or the dialog (in case of a response to an initial request for a dialog, or a response to a mid-dialog target refresh request), from the adjacent downstream SIP entity it MUST add a parameter value to the Holmberg Expires December 2, 2010 [Page 7] Internet-Draft STUN-keep May 2010 "keep" parameter, before sending or forwarding the response. The parameter can contain a recommended keep-alive frequency, or a zero value. 5. Keep-alive frequency If a SIP entity receives a SIP response, where its Via header field contains a "keep" parameter with a non-zero value that indicates a recommended keep-alive frequency, it MUST use the procedures defined for the Flow-Timer header field [RFC5626]. According to the procedures, the SIP entity must send keep-alives at least as often as the indicated recommended keep-alive frequency, and if the SIP entity uses the recommended keep-alive frequency then it should send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the recommended keep-alive frequency. If the received "keep" parameter value is zero, the SIP entity can send keep-alives at its discretion. [RFC5626] provides additional guidance on selecting the keep-alive frequency in case a recommended keep-alive frequency is not provided. A SIP entity that uses the "keep" parameter to indicate willingness to receive keep-alives MUST NOT use the Flow-Timer header field in order to provide a recommended keep-alive frequency. SIP Outbound uses the Flow-Timer header field to indicate the server- recommended keep-alive frequency. However, it will only be sent between a UA and an edge proxy. Using the "keep" parameter, however, the sending and receiving of keep-alives might be negotiated between multiple entities on the signalling path. Since the server- recommended keep-alive frequency might vary between different SIP entities, those would have to re-write the Flow-Timer header field value. In addition, if a SIP entity does not indicate willingness to receive keep-alives from its adjacent downstream SIP entity, and receives a Flow-Timer header field in a response, it would have to remove the Flow-Timer header field from the response. This issue does not exist for the "keep" parameter, as each SIP entity has its own individual Via header field. 6. Overlap with connection reuse The connect-reuse specification [I-D.ietf-sip-connect-reuse] specifies how to use connection-oriented transports to send requests in the reverse direction. SIP entity A opens a connection to entity B in order to send a request. Under certain conditions entity B can Holmberg Expires December 2, 2010 [Page 8] Internet-Draft STUN-keep May 2010 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 mechanism 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 entity 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. 7. Examples 7.1. General This section shows example flows where usage of keep-alives, associated with a registration and a dialog, is negotiated between different SIP entities. 7.2. Keep-alive negotiation associated with registration: UA-proxy The figure shows an example where Alice sends an REGISTER request. She indicates willingness of sending keep-alive by inserting a "keep" parameter in her Via header field of the request. The edge proxy (P1) forwards the request towards the registrar. P1 is willing to receive keep-alives from Alice for the duration of the registration, so When P1 receives the associated response it adds a keep parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice. When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the registration. For the lifetime of the registration, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the keep parameter value. Holmberg Expires December 2, 2010 [Page 9] Internet-Draft STUN-keep May 2010 Alice P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: Alice;keep | | | |--- REGISTER-------------->| | | Via: P1 | | | Via: Alice;keep | | | | | |<-- 200 OK ----------------| | | Via: P1 | | | Via: Alice;keep | |<-- 200 OK ---------------| | | Via: Alice;keep=30 | | | | | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | Figure 1: Example call flow 7.3. Keep-alive negotiation associated with dialog: UA-proxy The figure shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alive by inserting a "keep" parameter in her Via header field of the request. The edge proxy (P1) adds itself to the dialog route set by adding itself to a Record-Route header field, before it forwards the request towards Bob. P1 is willing to receive keep-alives from Alice for the duration of the dialog, so When P1 receives the associated response it adds a keep parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice. When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic Holmberg Expires December 2, 2010 [Page 10] Internet-Draft STUN-keep May 2010 keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the keep parameter value. Alice P1 Bob | | | |--- INVITE -------------->| | | Via: Alice;keep | | | |--- INVITE --------------->| | | Via: P1 | | | Via: Alice;keep | | | Record-Route: P1 | | | | | |<-- 200 OK ----------------| | | Via: P1 | | | Via: Alice;keep | | | Record-Route: P1 | |<-- 200 OK ---------------| | | Alice: UAC;keep=30 | | | Record-Route: P1 | | | | | |--- ACK ----------------->| | | | | | |--- ACK ------------------>| | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | | | |--- BYE ----------------->| | | | | | |--- BYE ------------------>| | | | | |<-- 200 OK ----------------| | | | Figure 2: Example call flow Holmberg Expires December 2, 2010 [Page 11] Internet-Draft STUN-keep May 2010 7.4. Keep-alive negotiation associated with dialog: UA-UA The figure shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alive by inserting a "keep" parameter in her Via header field of the request. The edge proxy (P1) does not add itself to the dialog route set, by adding itself to a Record-Route header field, before it forwards the request towards Bob. . When Alice receives the response, she determines from her Via header field that P1 is not willing to receive keep-alives associated with the dialog from her. When the dialog route set has been established, Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not insert itself in the dialog route set), and she once again indicates willingness to send keep-alives by inserting a "keep" parameter in her Via header field of the request. Bob supports the keep-alive mechanism, and is willing to receive keep-alives associated with the dialog from Alice, so he creates a response and adds a keep parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before he forwards the response towards Alice. When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards Bob, using the recommended keep-alive frequency indicated by the keep parameter value. Holmberg Expires December 2, 2010 [Page 12] Internet-Draft STUN-keep May 2010 Alice P1 Bob | | | |--- INVITE -------------->| | | Via: Alice;keep | | | |--- INVITE --------------->| | | Via: P1 | | | Via: Alice:keep | | | | | |<-- 200 OK ----------------| | | Via: P1 | | | Via: Alice;keep | |<-- 200 OK ---------------| | | Via: Alice;keep | | | | | | | |--- ACK --------------------------------------------->| | | |--- UPDATE ------------------------------------------>| | Via: Alice;keep | | | |<-- 200 OK ------------------------------------------>| | Via: UAC;keep=30 | | | | | | *** Timeout *** | | | |=== STUN request ====================================>| |<== STUN response ====================================| | | | *** Timeout *** | | | |=== STUN request ====================================>| |<== STUN response ====================================| | | | | |--- BYE --------------------------------------------->| | | |<-- 200 OK -------------------------------------------| | | Figure 3: Example call flow 8. Grammar This specification defines a new Via header field parameter, "keep". The grammar includes the definitions from [RFC5626]. Holmberg Expires December 2, 2010 [Page 13] Internet-Draft STUN-keep May 2010 The ABNF [RFC5234] is: via-params =/ keep keep = "keep" [ EQUAL 1*(DIGIT) ] 9. IANA Considerations 9.1. keep This specification defines a new Via header field parameter called keep in the "Header Field Parameters and Parameter Values" sub- registry as per the registry created by [RFC5626]. The syntax is defined in Section 8. The required information is: Predefined Header Field Parameter Name Values Reference ---------------------- --------------------- ---------- --------- Via keep No [RFCXXXX] 10. Security Considerations This specification does not introduce security considerations in addition to those specified in [RFC5626]. 11. 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, Dean Willis and John Elwell for their comments on the list. Thanks to Vijay Gurbani for providing text about the relationship with the connect-reuse specification. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Holmberg Expires December 2, 2010 [Page 14] Internet-Draft STUN-keep May 2010 [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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. 12.2. Informative References [I-D.ietf-sip-connect-reuse] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-14 (work in progress), August 2009. Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires December 2, 2010 [Page 15]