[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: Informational                          December 1, 2009
Expires: June 4, 2010


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

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.

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), 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 June 4, 2010.

Copyright Notice

   Copyright (c) 2009 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



Holmberg                  Expires June 4, 2010                  [Page 1]

Internet-Draft                  STUN-keep                  December 2009


   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
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Client behavior  . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Server behavior  . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  Overlap with connection reuse  . . . . . . . . . . . . . . . .  6
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     9.1.  Example with keep-alive negotiation during registration  .  7
     9.2.  Example with keep-alive negotiation during session
           establishment  . . . . . . . . . . . . . . . . . . . . . .  8
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     11.1. IANA Registration of the SIP Via keep parameter  . . . . . 10
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     13.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10






















Holmberg                  Expires June 4, 2010                  [Page 2]

Internet-Draft                  STUN-keep                  December 2009


1.  Introduction

   Chapter 3.5 of [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.  In addition, as
   described in [I-D.ietf-sip-outbound], for dialog initiated outbound
   flows a separate mechanism is used to indicate and negotiate support
   of keep-alives.

   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].
   In addition, the Outbound mechanism also allows the establishment of
   flows using initial dialog SIP requests.  As specified in
   [I-D.ietf-sip-outbound], keep-alives must be separately negotiated
   for such flows.

   Another use-case is when network entities (SIP proxies) need to
   perform heartbeats between themselves.  The keep-alive techniqurs
   defined in [I-D.ietf-sip-outbound] can be used for providing the
   heartbeats, and the mechanism in this document can be used by the
   entities to indicate and negotiate support of the keep-alive
   techniques.

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



Holmberg                  Expires June 4, 2010                  [Page 3]

Internet-Draft                  STUN-keep                  December 2009


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.


4.  Requirements

   REQ 1: It MUST be possible for a SIP entity acting as a UAC to
   indicate, during registration and session establishment, support of
   the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards
   the next hop, if only the keep-alive part of [I-D.ietf-sip-outbound]
   is used for the registration or session

   REQ 2: It MUST be possible for a SIP entity acting as a UAS to
   indicate, during registration and session establishment, support of
   the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards
   the previous hop, if only the keep-alive part of
   [I-D.ietf-sip-outbound] is used for the registration or session


5.  Client behavior

   A SIP entity aciting as a UAC 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 SIP entity acting as a UAC (UA or proxy) which supports the
   method defined in this specification sends a SIP REGISTER request,
   and the UAC wants to send keep-alives towards the next hop, the
   entity 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 entity and
   the next hop during the duration of the registration.  If the SIP
   REGISTER response contains a Flow-Timer header
   [I-D.ietf-sip-outbound], and the UAC uses the server recommended
   keepalive frequency provided in the header, the UAC SHOULD send its
   keepalives so that the interval between each keepalive is randomly



Holmberg                  Expires June 4, 2010                  [Page 4]

Internet-Draft                  STUN-keep                  December 2009


   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 UAC which supports the method defined in this specification
   sends an initial SIP request, the UAC has not registered itself via
   the edge proxy towards which the SIP request is sent, and the UAC
   wants to send keep-alives towards the next hop, the UAC 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 UAC and the next hop
   during the duration of the call.  If the initial SIP response
   contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC
   uses the recommended keepalive frequency provided in the header, the
   UAC 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
   initial SIP response, the UA can send keepalives at its discretion.
   If the UAC 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

   A SIP entity acting as a UAS (UA or 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 UAS MUST also process double-CRLF keep-
   alives, as defined in [I-D.ietf-sip-outbound].

   When a UAS that supports the method defined in this specification
   recieves a SIP REGISTER request which contains a "keep" parameter in



Holmberg                  Expires June 4, 2010                  [Page 5]

Internet-Draft                  STUN-keep                  December 2009


   the topmost Via header, and the UAS wants to allow the sender of the
   SIP REGISTER request to send keep-alives towards the UAS during the
   duration of the registration, the UAS proxy MUST add a "yes" value to
   the "keep" parameter.  In addition the UAS MAY include a Flow-Timer
   header field if the associated SIP REGISTER response.

   When a UAS that supports the method defined in this specification
   recieves an initial SIP request which contains a "keep" parameter in
   the topmost Via header, and the UAS wants to allow the sender of the
   initial SIP request to send keep-alives towards the UAS during the
   duration of the call, the UAS proxy MUST add a "yes" value to the
   "keep" parameter.  In addition the UAS MAY include a Flow-Timer
   header field if the associated initial SIP response.


7.  Proxy behavior

   A proxy acting as a UAC, that wants to use the mechanism in this
   document, shall follow the procedures defined in Section 5.

   A proxy acting as a UAS, that wants to use the mechanism in this
   document, shall follow the procedures defined in Section 6.


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







Holmberg                  Expires June 4, 2010                  [Page 6]

Internet-Draft                  STUN-keep                  December 2009


9.  Examples

9.1.  Example with keep-alive negotiation during registration

   The figure shows an example where a UAC sends an REGISTER request, in
   which it indicates support of keep-alive by inserting a "keep"
   parameter in the Via header of the REGISTER 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 registrar.  When the UAC receives the 200
   OK (REGISTER) response from the registrar 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 registration.  The edge proxy (P1) has inserted a
   Flow-Timer header in the 200 OK (REGISTER) response, indicating a
   recommented keep-alive interval of 30 seconds.

      UAC                        P1                        REGISTRAR
       |                          |                           |
       |--- REGISTER------------->|                           |
       |    Via: UAC;keep         |                           |
       |                          |--- REGISTER-------------->|
       |                          |    Via: UAC;keep=yes      |
       |                          |    Via: P1                |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: UAC;keep=yes      |
       |                          |    Via: P1                |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep=yes     |                           |
       |    Flow-Timer: 30        |                           |
       |                          |                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |



                        Figure 1: Example call flow




Holmberg                  Expires June 4, 2010                  [Page 7]

Internet-Draft                  STUN-keep                  December 2009


9.2.  Example with keep-alive negotiation during session establishment

   The figure shows an example where a non-registered UAC sends an
   INVITE request, 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 the 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) response,
   indicating a recommented keep-alive interval of 30 seconds.





































Holmberg                  Expires June 4, 2010                  [Page 8]

Internet-Draft                  STUN-keep                  December 2009


      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 2: Example call flow


10.  Security Considerations


11.  IANA Considerations







Holmberg                  Expires June 4, 2010                  [Page 9]

Internet-Draft                  STUN-keep                  December 2009


11.1.  IANA Registration of the SIP Via keep parameter


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., "Managing Client Initiated Connections in
              the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-20 (work in progress), June 2009.

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-18 (work in progress),
              July 2008.

   [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 June 4, 2010                 [Page 10]

Internet-Draft                  STUN-keep                  December 2009


Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com










































Holmberg                  Expires June 4, 2010                 [Page 11]


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