[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-holmberg-sipcore-keep) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6223

SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                          April 15, 2010
Expires: October 17, 2010


                  Indication of support for keep-alive
                     draft-ietf-sipcore-keep-02.txt

Abstract

   This specification defines a new Session Initiation Protocol (SIP)
   header field parameter, "keep", that SIP entities can use to
   negotiate explicit support of the NAT keep-alive mechanisms defined
   in the SIP Outbound specification.  The parameter is defined for
   cases where the SIP Outbound mechanism is not supported, or in cases
   where it cannot be applied.

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 October 17, 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
   the Trust Legal Provisions and are provided without warranty as



Holmberg                Expires October 17, 2010                [Page 1]

Internet-Draft                  STUN-keep                     April 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Use-case: Calls from non-registered UAs  . . . . . . . . .  3
     1.2.  Use-case: SIP Outbound not supported . . . . . . . . . . .  3
     1.3.  Use-case: SIP dialog initiated Outbound flows  . . . . . .  3
     1.4.  Use-case: Proxy-to-proxy heartbeat . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  User agent behavior  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  User agent client behavior . . . . . . . . . . . . . . . .  5
       4.2.1.  Keep-alive negotiation for registration  . . . . . . .  5
       4.2.2.  Keep-alive negotiation for dialog  . . . . . . . . . .  5
     4.3.  User agent server behavior . . . . . . . . . . . . . . . .  6
       4.3.1.  Keep-alive negotiation for dialog  . . . . . . . . . .  6
     4.4.  Keep-alive frequency . . . . . . . . . . . . . . . . . . .  6
   5.  Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Edge proxy behavior  . . . . . . . . . . . . . . . . . . .  7
       5.2.1.  Keep-alive negotiation for registration  . . . . . . .  7
       5.2.2.  Keep-alive negotiation for dialog  . . . . . . . . . .  7
     5.3.  Proxy behavior for proxy-to-proxy heartbeats . . . . . . .  7
       5.3.1.  Keep-alive negotiation for dialog  . . . . . . . . . .  7
   6.  Overlap with connection reuse  . . . . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Example: Keep-alive negotiation for registration . . . . .  9
     7.2.  Example: Keep-alive negotiation for dialog from UA . . . . 10
     7.3.  Example: Keep-alive negotiation for dialog to UA . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  IANA Registration of the SIP header field keep
           parameter  . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14










Holmberg                Expires October 17, 2010                [Page 2]

Internet-Draft                  STUN-keep                     April 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, it is currently not possible
   to explicitly negotiate the usage of keep-alives, since the keep-
   alives are implicitly negotiated as part of the SIP Outbound
   negotation.

   However, there are also SIP Outbound use-cases where the keep-alives
   are not implicitly negotiated as part of the SIP Outbound
   negotiation, and therefor an explicit keep-alive negotiation
   mechanism is needed.  In addition, there are use-cases where SIP
   Outbound is not supported, or where it cannot be applied, but where
   there is still a need to be able to negotiate the usage of keep-
   alives.

   This specification defines a new SIP header field parameter, "keep",
   that SIP entities can use to negotiate support of the NAT keep-alive
   mechanisms defined in the SIP Outbound specification [RFC5626].  The
   parameter is defined for cases where the SIP Outbound mechanism is
   not supported, or in cases where it cannot be applied.  The usage of
   keep-alives can be negotiated as part of a registration, or as part
   of a dialog.

   The following sections describe use-cases where a mechanism to
   explicitly negotiate the usage of keep-alives is needed.

1.1.  Use-case: Calls from non-registered UAs

   In some cases a UA does not register itself before making a call, but
   still needs to be able to make calls and send keep-alives in order to
   maintain NAT bindings open during the duration of the call.  A
   typical example is emergency calls.

1.2.  Use-case: SIP Outbound not supported

   There are cases where the SIP entities that need to be able to
   negotiate the usage of keep-alives do not support the SIP Outbound
   mechanism

1.3.  Use-case: SIP dialog initiated Outbound flows

   SIP Outbound allows the establishment of flows using initial SIP
   dialog requests.  As specified in [RFC5626], keep-alives are not
   implicitly negotiated for such flows, and therefor need to be
   separately negotiated.




Holmberg                Expires October 17, 2010                [Page 3]

Internet-Draft                  STUN-keep                     April 2010


1.4.  Use-case: Proxy-to-proxy heartbeat

   There are cases where SIP proxies need to perform heartbeats between
   themselves.  Eventhough the heartbeats are normally not used for NAT
   traversal purpose, the keep-alive mechanisms defined in [RFC5626] can
   still be used to perform the heartbeats.


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.

   Keep-alives: Refers to keep-alive messages using the mechanisms
   define defined in the SIP Outbound specification [RFC5626].

   "keep" parameter: A SIP header field parameter that a SIP entity can
   insert to explicitly indicate that it supports the keep-alive
   mechanisms defined in the SIP Outbound specification [RFC5626].  The
   parameter is defined for the SIP Contact, Path and Record-Route
   header fields.


4.  User agent behavior

4.1.  General

   This section describes how a UA (User Agent) negotiates the usage of
   keep-alives between itself and its edge proxy, for a registration or
   a dialog.

   A UA will only send keep-alives towards its edge proxy, and MUST NOT
   expect to receive edge proxy initiated keep-alives.

   A UA that supports keep-alives MUST insert a "keep" parameter in its
   Contact header field even if it also indicates support of SIP
   Outbound [RFC5626], in order to be able to negotiate the usage of
   keep-alives also in cases where the edge proxy only supports keep-
   alives, but not the other parts of SIP Outbound.



Holmberg                Expires October 17, 2010                [Page 4]

Internet-Draft                  STUN-keep                     April 2010


   As defined in [RFC5626], a UA that supports keep-alives MUST act as a
   Session Traversal Utilities for NAT (STUN) client [RFC5389].  The UA
   MUST support the amount of STUN which is required to apply the STUN
   keep-alive mechanism defined in [RFC5626], and the UA MUST support
   the CRLF keep-alive mechanism defined in [RFC5626].  In addition, as
   defined in [RFC5389], the UAC MUST be able to process the SIP Path
   header [RFC3327], in order to detect whether the edge proxy supports
   keep-alives.

   NOTE: Keep-alives needs to be negotiated when a registration or
   dialog is initiated.  It is not possible to negotiate/re-negotiate
   the usage keep-alives later during the registration or dialog, and
   the usage of the "keep" parameter in re-registration requests and
   dialog modification requsts is not specified.

   NOTE: Since there are UAs 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 an edge proxy
   has not indicated support of keep-alives using the "keep" parameter.
   However, the "keep" parameter is still important in order for the UA
   to inform the edge proxy that the UA 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.

4.2.  User agent client behavior

4.2.1.  Keep-alive negotiation for registration

   When a UAC sends a REGISTER request for a new registration, if the
   UAC is willing to send keep-alives associated with the registration,
   it MUST insert a "keep" parameter in its Contact header field of the
   REGISTER request.

   When the UAC receives the REGISTER response, if the top-most Path
   header field (edge proxy) of the response contains a "keep"
   parameter, the UAC MUST start to send keep-alives towards the edge
   proxy, and it MUST send keep-alives for the remaining duration of the
   registration.  When the registration is terminated, the UAC MUST
   cease the sending of keep-alives negotiated for the registration.

4.2.2.  Keep-alive negotiation for dialog

   When a UAC sends an initial request (e.g. a SIP INVITE request) for a
   dialog, if the UAC is willing to send keep-alives associated with the
   dialog, it MUST insert a "keep" parameter in its Contact header field
   of the request.




Holmberg                Expires October 17, 2010                [Page 5]

Internet-Draft                  STUN-keep                     April 2010


   When the UAC receives the response(s) to the initial request for the
   dialog, if the top-most Record-Route header field (edge proxy) of
   response(s) contains a "keep" parameter, the UAC MUST start to send
   keep-alives towards the edge proxy for the remaining duration of the
   dialog.  When the dialog is terminated, the UAC MUST cease the
   sending of keep-alives negotiated for the dialog.

4.3.  User agent server behavior

4.3.1.  Keep-alive negotiation for dialog

   When a UAS receives an initial request for a dialog, if the top-most
   Record-Route header filed contains a "keep" parameter, and if the UAS
   is willing to send keep-alives associated with the dialog, it MUST
   insert a "keep" parameter in its Contact header field in the
   response(s) to the request.  After that the UAS MUST start to send
   keep-alives towards the edge proxy, and it MUST send keep-alives for
   the remaining duration of the registration.

4.4.  Keep-alive frequency

   If the SIP message that contains the "keep" parameter of the edge
   proxy also contains a Flow-Timer header field [RFC5626], it is
   strongly RECOMMENDED that the UA uses the server recommended keep-
   alive frequency value, provided in the header field, and sends keep-
   alives so that the interval between each keep-alive is randomly
   distributed between 80% and 100% of the provided value.

   If the UA does not receive a Flow-Timer header field from the edge
   proxy, it can send keep-alives at its discretion.


5.  Proxy behavior

5.1.  General

   A proxy that supports the mechanism specified in this specification
   MUST act as a STUN server [RFC5389], and MUST support the amount of
   STUN which is required to apply the STUN keep-alive technique
   [RFC5626].  The edge proxy MUST also process double-CRLF keep-alives,
   as defined in [RFC5626].

   If a proxy also generates keep-alives (see proxy-to-proxy case), it
   MUST also act as a STUN client [RFC5389].







Holmberg                Expires October 17, 2010                [Page 6]

Internet-Draft                  STUN-keep                     April 2010


5.2.  Edge proxy behavior

5.2.1.  Keep-alive negotiation for registration

   When an edge proxy receives an initial REGISTER request for a
   registration from a UA behind the edge proxy, the Contact header
   field of the request contains a "keep" parameter, and if the edge
   proxy is willing to receive keep-alives from the UA for the
   associated registration, the edge proxy MUST insert a "keep"
   parameter in its Path header field of the associated REGISTER
   response.  In addition, the edge proxy MAY insert a Flow-Timer header
   field [RFC5626], which indicates the recommended keep-alive frequency
   for the registration.

5.2.2.  Keep-alive negotiation for dialog

   When an edge proxy receives a dialog initiation request from a UAC
   behind the edge proxy, the Contact header field of the request
   contains a "keep" parameter, and if the edge proxy is willing to
   receive keep-alives from the UA for the associated dialog, the edge
   proxy MUST insert a "keep" parameter in its Record-Route header field
   of the associated response(s).  In addition, the edge proxy MAY
   insert a Flow-Timer header field [RFC5626], which indicates the
   recommended keep-alive frequency for the dialog.

   When an edge proxy receives an inbound dialog initiation request
   towards a UAS behind the edge proxy, and if the edge proxy is willing
   to receive keep-alives from the UA for the associated dialog, the
   edge proxy MUST insert a "keep" parameter in its Record-Route header
   field of the request.  In addition, the edge proxy MAY insert a Flow-
   Timer header field [RFC5626], which indicates the recommended keep-
   alive frequency for the dialog.  When the edge proxy receives
   response(s) associated with the request from the UAS, associated with
   the request, if the Contact header field of the response(s) contains
   a "keep" parameter, the edge proxy can assume that the UAS will send
   keep-alives associated with the dialog.

5.3.  Proxy behavior for proxy-to-proxy heartbeats

5.3.1.  Keep-alive negotiation for dialog

   When a proxy receives a dialog initiation request from its previous-
   hop proxy, and the top-most Record-Route header field of the request
   contains a "keep" parameter, if the proxy is willing to send and
   receive keep-alives from the previous-hop proxy for the associated
   dialog, the proxy MUST insert a "keep" parameter in its Record-Route
   header field of the associated response(s) sent towards the previous-
   hop proxy.  After that the proxy MUST send keep-alives, and accept



Holmberg                Expires October 17, 2010                [Page 7]

Internet-Draft                  STUN-keep                     April 2010


   keep-alives sent from the previous-hop proxy, for the duration of the
   dialog.

   When a proxy forwards a dialog initiation request towards its next-
   hop proxy, and it wants to negotiate the usage of keep-alives with
   that next-hop proxy, it MUST include a "keep" parameter in its
   Record-Record header field of the request.  When the proxy receives
   the associated response(s), if the Record-Route header field that
   represents the next-hop proxy contains a "keep" parameter, the proxy
   MUST start sending keep-alives towards the next-hop proxy for the
   duration of the dialog.

   NOTE: The usage of the Flow-Timer header field for proxy-to-proxy
   heartbeats is unspecified.

   OPEN ISSUE: It still needs to be discuss whether it should be
   possible to negotiate that the sending of keep-alives between proxies
   continue after the dialog, for which the keep-alives were negotiated,
   has been terminated.


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
   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
   [I-D.ietf-sip-connect-reuse] as well as the "keep" header field
   parameter defined in this specification.  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.


7.  Examples






Holmberg                Expires October 17, 2010                [Page 8]

Internet-Draft                  STUN-keep                     April 2010


7.1.  Example: Keep-alive negotiation for registration

   The figure shows an example where the UAC sends a REGISTER request.
   The UAC inserts a "keep" parameter in its Contact header field, to
   indicate that it is willing to send keep-alives during the liftime of
   the registration.

   The edge proxy (P1) supports the receiving of keep-alives, so it
   inserts a "keep" parameter in its Path header field of the REGISTER
   response that it forwards towards the UAC.  In addition, the edge
   proxy inserts a Flow-Timer header field in the response.  The header
   field value indicates the server recommended keep-alive frequency.

   When the UAC receives the REGISTER response, and detects that the
   edge proxy supports the receiving of keep-alives, it starts to send
   periodic keep-alives (in this example using the STUN keep-alive
   technique)

      UAC                  P1 (Edge Proxy)                REGISTRAR
       |                          |                           |
       |--- REGISTER------------->|                           |
       |    Contact: UAC;keep     |                           |
       |                          |--- REGISTER-------------->|
       |                          |    Path: P1               |
       |                          |    Contact: UAC;keep      |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Path: P1               |
       |                          |    Contact: UAC;keep      |
       |<-- 200 OK ---------------|                           |
       |    Path: P1;keep         |                           |
           |    Contact: UAC;keep     |                           |
       |    Flow-Timer: 30        |                           |
       |                          |                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |






Holmberg                Expires October 17, 2010                [Page 9]

Internet-Draft                  STUN-keep                     April 2010


                        Figure 1: Example call flow

7.2.  Example: Keep-alive negotiation for dialog from UA

   The figure shows an example where the UAC sends an INVITE request.
   The UAC inserts a "keep" parameter in its Contact header field, to
   indicate that it is willing to send keep-alives during the lifetime
   of the dialog.

   The edge proxy (P1) supports the receiving of keep-alives, so it
   inserts a "keep" parameter in its Record-Route header field of the
   INVITE response that it forwards towards the UAC.  In addition, the
   edge proxy inserts a Flow-Timer header field in the response.  The
   header field value indicates the server recommended keep-alive
   frequency.

   When the UAC receives the INVITE response, and detects that the edge
   proxy supports the receiving of keep-alives, it starts to send
   periodic keep-alives (in this example using the STUN keep-alive
   technique)































Holmberg                Expires October 17, 2010               [Page 10]

Internet-Draft                  STUN-keep                     April 2010


      UAC                  P1 (Edge Proxy)            Remote SIP network
       |                          |                           |
       |--- INVITE -------------->|                           |
       |    Contact: UAC;keep     |                           |
       |                          |--- INVITE --------------->|
       |                          |    Record-Route: P1       |
       |                          |    Contact: UAC;keep      |
           |                          |                           |
       |                          |                           |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Record-Route: P1       |
       |                          |    Contact: UAS           |
       |<-- 200 OK ---------------|                           |
       |    Record-Route: P1;keep |                           |
       |    Contact: UAS          |                           |
       |    Flow-Timer: 30        |                           |
       |                          |                           |
       |--- ACK ----------------->|                           |
       |                          |                           |
       |                          |--- ACK ------------------>|
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                          |                           |
       |--- BYE ----------------->|                           |
       |                          |                           |
       |                          |--- BYE ------------------>|
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |                           |

                        Figure 2: Example call flow

7.3.  Example: Keep-alive negotiation for dialog to UA

   The figure shows an example where P1 (edge proxy) forwards an INVITE
   request towards the UAS.  P1 inserts a "keep" parameter in its
   Record-Route header field, to indicate that it is willing to receive
   keep-alives during the lifetime of the dialog.  In addition, the edge



Holmberg                Expires October 17, 2010               [Page 11]

Internet-Draft                  STUN-keep                     April 2010


   proxy inserts a Flow-Timer header field in the response.  The header
   field value indicates the server recommended keep-alive frequency.

   The UAS is willing to send keep-alives, so it inserts a "keep"
   parameter in its Contact header field of the INVITE 200 (OK)
   response.  In addition, the edge proxy inserts a Flow-Timer header
   field in the response.  The header field value indicates the server
   recommended keep-alive frequency.  After that the UAS starts to send
   periodic keep-alives (in this example using the STUN keep-alive
   technique)









































Holmberg                Expires October 17, 2010               [Page 12]

Internet-Draft                  STUN-keep                     April 2010


    Remote SIP network      P1 (Edge Proxy)                  UAS
       |                          |                           |
       |--- INVITE -------------->|                           |
       |    Contact: UAC          |                           |
       |                          |--- INVITE --------------->|
       |                          |    Record-Route: P1;keep  |
       |                          |    Contact: UAC           |
           |                          |    Flow-Timer: 30         |
           |                          |                           |
       |                          |                           |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Record-Route: P1;keep  |
       |                          |    Contact: UAS;keep      |
       |<-- 200 OK ---------------|                           |
       |    Record-Route: P1;keep |                           |
       |    Contact: UAS;keep     |                           |
       |                          |                           |
       |--- ACK ----------------->|                           |
       |                          |                           |
       |                          |--- ACK ------------------>|
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |                          |<== STUN request ==========|
       |                          |=== STUN response ========>|
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |                          |<== STUN request ==========|
       |                          |=== STUN response ========>|
       |                          |                           |
       |--- BYE ----------------->|                           |
       |                          |                           |
       |                          |--- BYE ------------------>|
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |                           |

                        Figure 3: Example call flow


8.  Security Considerations








Holmberg                Expires October 17, 2010               [Page 13]

Internet-Draft                  STUN-keep                     April 2010


9.  IANA Considerations

9.1.  IANA Registration of the SIP header field keep parameter


10.  Acknowledgements

   Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean
   Schneyer, Milo Orsic, John Elwell and Ya-Ching Tan 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.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, December 2002.

   [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.

11.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.










Holmberg                Expires October 17, 2010               [Page 14]

Internet-Draft                  STUN-keep                     April 2010


Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com










































Holmberg                Expires October 17, 2010               [Page 15]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/