SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Informational                          December 1, 2009 Standards Track                          April 15, 2010
Expires: June 4, October 17, 2010

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

Abstract

   This specification defines a new SIP Via Session Initiation Protocol (SIP)
   header field parameter, "keep"
   which "keep", that SIP entities can use to indicate
   negotiate explicit support of the NAT keep-alive
   techniques mechanisms defined
   in the SIP Outbound, in Outbound specification.  The parameter is defined for
   cases where the SIP Outbound
   procedures are mechanism is not supported 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), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   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."

   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, October 17, 2010.

Copyright Notice

   Copyright (c) 2009 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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions
     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
   3.  Definitions
     1.4.  Use-case: Proxy-to-proxy heartbeat . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Requirements
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Client
   4.  User agent behavior  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Server
     4.2.  User agent client behavior . . . . . . . . . . . . . . . .  5
       4.2.1.  Keep-alive negotiation for registration  . . . . . . .  5
   7.  Proxy behavior
       4.2.2.  Keep-alive negotiation for dialog  . . . . . . . . . .  5
     4.3.  User agent server behavior . . . . . . . . . . . . . . . .  6
   8.  Overlap with connection reuse
       4.3.1.  Keep-alive negotiation for dialog  . . . . . . . . . .  6
     4.4.  Keep-alive frequency . . . . . .  6
   9.  Examples . . . . . . . . . . . . .  6
   5.  Proxy behavior . . . . . . . . . . . . . .  7
     9.1.  Example with keep-alive negotiation during registration .  7
     9.2.  Example with keep-alive negotiation during session
           establishment . . . . . . . . .  6
     5.1.  General  . . . . . . . . . . . . .  8
   10. Security Considerations . . . . . . . . . . . .  6
     5.2.  Edge proxy behavior  . . . . . . .  9
   11. IANA Considerations . . . . . . . . . . . .  7
       5.2.1.  Keep-alive negotiation for registration  . . . . . . .  7
       5.2.2.  Keep-alive negotiation for dialog  . .  9
     11.1. IANA Registration of the SIP Via keep parameter . . . . . 10
   12. Acknowledgements . . .  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  . . . 10
   13. References . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . 10
     13.1. Normative References . . . . . . . . . . . . . .  8
     7.1.  Example: Keep-alive negotiation for registration . . . . . 10
     13.2. Informative References  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  . . . . . . . . . 10
   Author's Address . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . 10 . . . . . . 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

1.  Introduction

   Chapter

   Section 3.5 of [I-D.ietf-sip-outbound] SIP Outbound [RFC5626] defines two keep-alive
   techniques.  Even though
   mechanisms.  Eventhough the keep-alive techniques mechanisms are separated from
   the rest of the SIP Outbound mechanism [I-D.ietf-sip-outbound], mechanism, it is currently not possible
   to indicate support explicitly negotiate the usage of keep-alives, since the keep-alive techniques without
   also indicating support for keep-
   alives are implicitly negotiated as part of the SIP Outbound mechanism.  In addition,
   negotation.

   However, there are also SIP Outbound use-cases where the keep-alives
   are not implicitly negotiated as
   described in [I-D.ietf-sip-outbound], for dialog initiated outbound
   flows a separate mechanism is used to indicate and negotiate support part of keep-alives.

   The the SIP Outbound
   negotiation, and therefor an explicit keep-alive negotiation
   mechanism is enabled during the UA registration phase.
   However, needed.  In addition, there are use-cases where the UA does SIP
   Outbound is not register itself, supported, or where it cannot be applied, but where
   there is still needs a need to be able to make 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 that the call.  A
   typical example is emergency calls.

1.2.  Use-case: SIP Outbound not supported

   There are also cases where entities do not support the Outbound mechanism, but still want SIP entities that need to be able to indicate support
   and use
   negotiate the keep-alive techniques defined in [I-D.ietf-sip-outbound].
   In addition, usage of keep-alives do not support the SIP Outbound
   mechanism also

1.3.  Use-case: SIP dialog initiated Outbound flows

   SIP Outbound allows the establishment of flows using initial dialog SIP
   dialog requests.  As specified in
   [I-D.ietf-sip-outbound], [RFC5626], keep-alives must be separately are not
   implicitly negotiated for such flows.

   Another use-case is when network entities (SIP proxies) flows, and therefor need to be
   separately negotiated.

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

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

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and the mechanism "OPTIONAL" in this
   document can are to be used by 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
   entities to indicate registering User Agent (UA) and negotiate support of the
   Authoritative Proxy.

   Keep-alives: Refers to keep-alive
   techniques.

   This specification defines a new messages using the mechanisms
   define defined in the SIP Outbound specification [RFC5626].

   "keep" parameter: A SIP Via header parameter, "keep",
   which can be used by field parameter that a UA SIP entity can
   insert to explicitly indicate support of that it supports the keep-alive
   techniques
   mechanisms defined in [I-D.ietf-sip-outbound].  The UA will insert the "keep" SIP Outbound specification [RFC5626].  The
   parameter in is defined for the Via SIP Contact, Path and Record-Route
   header of the REGISTER request, or
   the initial session request if not registered. fields.

4.  User agent behavior

4.1.  General

   This specification also defines section describes how a "yes" value for UA (User Agent) negotiates the "keep"
   parameter.  The usage of
   keep-alives between itself and its edge proxy will add proxy, for a "yes" value registration or
   a dialog.

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

   A UA that supports keep-alives MUST insert a "keep"
   parameter, if received parameter in the topmost Via header, to indicate its
   Contact header field even if it also indicates 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" SIP
   Outbound [RFC5626], in this
   document are order 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 able to negotiate the registering User
   Agent and usage of
   keep-alives also in cases where the Authoritative Proxy.  The "first" edge proxy refers to only supports keep-
   alives, but not the first edge proxy encountered when other parts of SIP Outbound.

   As defined in [RFC5626], a UA sends that supports keep-alives MUST act as a request.

   'keep' Parameter:
   Session Traversal Utilities for NAT (STUN) client [RFC5389].  The 'keep' parameter is a SIP Via header parameter
   which indicates that the entity inserting UA
   MUST support the parameter supports amount of STUN which is required to apply the STUN
   keep-alive techniques mechanism 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 [RFC5626], and session establishment, the UA MUST support of
   the CRLF keep-alive techniques mechanism defined in [I-D.ietf-sip-outbound] towards [RFC5626].  In addition, as
   defined in [RFC5389], the next hop, if only UAC MUST be able to process the keep-alive part of [I-D.ietf-sip-outbound]
   is used for 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 session

   REQ 2:
   dialog is initiated.  It MUST be is not possible for a SIP entity acting as a UAS to
   indicate, negotiate/re-negotiate
   the usage keep-alives later during the registration or dialog, and session establishment, support
   the usage of the keep-alive techniques defined "keep" parameter in [I-D.ietf-sip-outbound] towards
   the previous hop, if only 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 keep-alive part sending of
   [I-D.ietf-sip-outbound] CRLF keep-alives even an edge proxy
   has not indicated support of keep-alives using the "keep" parameter.
   However, the "keep" parameter is used 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 or session

5.  Client refresh intervals) in order to make sure the NAT
   bindings are kept open.

4.2.  User agent client behavior

   A SIP entity aciting as

4.2.1.  Keep-alive negotiation for registration

   When a UAC which supports sends a REGISTER request for a new registration, if the method defined in
   this specification
   UAC is willing to send keep-alives associated with the registration,
   it MUST act as insert a STUN client
   [I-D.ietf-behave-rfc3489bis], "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 support send keep-alives for the amount remaining duration of STUN
   which the
   registration.  When the registration is required to apply terminated, the STUN keep-alive technique
   [I-D.ietf-sip-outbound]. 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 entity acting as INVITE request) for a
   dialog, if the UAC (UA or proxy) which supports is willing to send keep-alives associated with the
   method defined
   dialog, it MUST insert a "keep" parameter in this specification sends its Contact header field
   of the request.

   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 SIP REGISTER request, dialog, if the top-most
   Record-Route header filed contains a "keep" parameter, and if the UAC wants UAS
   is willing to send keep-alives towards the next hop, associated with the
   entity dialog, it MUST
   insert a "keep" Via parameter in the SIP request.  If the
   Via its Contact header field in the SIP REGISTER response contains a "keep" parameter
   with a "yes" value,
   response(s) to the UA knows request.  After that the keep-alive techniques
   defined in [I-D.ietf-sip-outbound] can be used between UAS MUST start to send
   keep-alives towards the entity edge proxy, and it MUST send keep-alives for
   the next hop during the remaining duration of the registration.

4.4.  Keep-alive frequency

   If the SIP
   REGISTER response message that contains the "keep" parameter of the edge
   proxy also contains a Flow-Timer header
   [I-D.ietf-sip-outbound], and field [RFC5626], it is
   strongly RECOMMENDED that the UAC UA uses the server recommended
   keepalive keep-
   alive frequency value, provided in the header, the UAC SHOULD send its
   keepalives header field, and sends keep-
   alives so that the interval between each keepalive keep-alive is randomly
   distributed between 80% and 100% of the server provided time. value.

   If no the UA does not receive a Flow-Timer header field was present in the SIP REGISTER response, from the
   UA edge
   proxy, it can send keepalives keep-alives at its discretion.  The UA must insert a
   "keep" parameter even if

5.  Proxy behavior

5.1.  General

   A proxy that supports the UA also indicates mechanism specified in this specification
   MUST act as a STUN server [RFC5389], and MUST support the amount of Outbound
   [I-D.ietf-sip-outbound],
   STUN which is required to allow keep-alive usage in cases where apply the STUN keep-alive technique
   [RFC5626].  The edge proxy will only support "keep".

   When a UAC which supports the method MUST also process double-CRLF keep-alives,
   as defined in this specification
   sends [RFC5626].

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

5.2.  Edge proxy behavior

5.2.1.  Keep-alive negotiation for registration

   When an initial SIP request, the UAC has not registered itself via
   the edge proxy towards which the SIP receives an initial REGISTER request is sent, and for a
   registration from a UA behind the UAC
   wants to send keep-alives towards edge proxy, the next hop, Contact header
   field of the UAC MUST include request contains a "keep" Via parameter in parameter, and if the edge
   proxy is willing to receive keep-alives from the SIP request.  If UA for the Via header header
   in
   associated registration, the initial SIP responses contains edge proxy MUST insert 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 its Path header field of the call.  If associated REGISTER
   response.  In addition, the initial SIP response
   contains edge proxy MAY insert a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC
   uses
   field [RFC5626], which indicates the recommended keepalive keep-alive frequency provided in the header,
   for the registration.

5.2.2.  Keep-alive negotiation for dialog

   When an edge proxy receives a dialog initiation request from a UAC SHOULD send its keepalives so that
   behind the interval between each
   keepalive is randomly distributed between 80% and 100% of edge proxy, the server
   provided time.  If no Flow-Timer Contact header field was present in the
   initial SIP response, the UA can send keepalives at its discretion.
   If of the UAC wishes to apply keep-alive for future calls, it MUST
   insert request
   contains a "keep" Via parameter in the initial SIP request of those
   calls.

   NOTE: Since there are clients that already use CRLF keep-alives, parameter, and
   proxies are expected to be able if the edge proxy is willing 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 UA for the client to
   inform associated dialog, the edge
   proxy that MUST insert a "keep" parameter in its Record-Route header field
   of the client supports CRLF keep-alives, so
   that associated response(s).  In addition, the edge proxy does not use other mechanisms (e.g. short
   registration refresh intervals) in order to make sure MAY
   insert a Flow-Timer header field [RFC5626], which indicates the NAT
   bindings are kept open.

6.  Server behavior

   A SIP entity acting as
   recommended keep-alive frequency for the dialog.

   When an edge proxy receives an inbound dialog initiation request
   towards a UAS (UA or proxy) which supports behind the method
   defined in this specification MUST act as a STUN server
   [I-D.ietf-behave-rfc3489bis], edge proxy, and MUST support if the amount of STUN
   which edge proxy is required willing
   to apply receive keep-alives from the STUN keep-alive technique
   [I-D.ietf-sip-outbound].  The UAS UA for the associated dialog, the
   edge proxy MUST also process double-CRLF keep-
   alives, as defined in [I-D.ietf-sip-outbound].

   When insert a UAS that supports the method defined "keep" parameter in this specification
   recieves its Record-Route header
   field of the request.  In addition, the edge proxy MAY insert a SIP REGISTER request 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 in parameter, the topmost Via header, and edge proxy can assume that the UAS wants to allow 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 sender top-most Record-Route header field of the
   SIP REGISTER request
   contains a "keep" parameter, if the proxy is willing to send and
   receive keep-alives towards the UAS during from the
   duration of previous-hop proxy for the registration, associated
   dialog, the UAS proxy MUST add insert a "yes" value to
   the "keep" parameter.  In addition the UAS MAY include a Flow-Timer parameter in its Record-Route
   header field if of the associated SIP REGISTER response.

   When a UAS that supports response(s) sent towards the method defined in this specification
   recieves an initial SIP request which contains a "keep" parameter in previous-
   hop proxy.  After that the topmost Via header, proxy MUST send keep-alives, and accept
   keep-alives sent from the UAS wants to allow previous-hop proxy, for the sender duration of the
   initial SIP
   dialog.

   When a proxy forwards a dialog initiation request to send keep-alives towards its next-
   hop proxy, and it wants to negotiate the UAS during the
   duration usage of keep-alives with
   that next-hop proxy, it MUST include a "keep" parameter in its
   Record-Record header field of the call, request.  When the UAS proxy MUST add a "yes" value to receives
   the
   "keep" parameter.  In addition associated response(s), if the UAS MAY include a Flow-Timer Record-Route header field if that
   represents the associated initial SIP response.

7.  Proxy behavior

   A next-hop proxy acting as contains a UAC, that wants to use "keep" parameter, the mechanism in this
   document, shall follow proxy
   MUST start sending keep-alives towards the procedures defined in Section 5.

   A next-hop proxy acting as a UAS, that wants 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 use be discuss whether it should be
   possible to negotiate that the mechanism in this
   document, shall follow sending of keep-alives between proxies
   continue after the procedures defined in Section dialog, for which the keep-alives were negotiated,
   has been terminated.

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

9.

7.  Examples

9.1.
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 ========|                           |
       |                          |                           |
                        Figure 1: Example with keep-alive call flow

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

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

   The edge proxy (P1) also supports the keep-alive mechanism, receiving of keep-alives, so it adds
   inserts a "yes" value
   to the "keep" parameter to the Via 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 request is
   then fowarded towards
   header field value indicates the registrar. server recommended keep-alive
   frequency.

   When the UAC receives the 200
   OK (REGISTER) response from the registrar it finds out INVITE response, and detects that the edge
   proxy supports keep-alive.  After that the UAC sends receiving of keep-alives, it starts to send
   periodic keep-
   alives 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 (Edge Proxy)            Remote SIP network
       |                          |                           |
       |--- REGISTER------------->| INVITE -------------->|                           |
       |    Via:    Contact: UAC;keep     |                           |
       |                          |--- REGISTER-------------->| INVITE --------------->|
       |                          |    Record-Route: P1       |
       |                          |    Contact: UAC;keep      |
           |                          |    Via: UAC;keep=yes                           |
       |                          |    Via: P1                           |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: UAC;keep=yes    Record-Route: P1       |
       |                          |    Via: P1    Contact: UAS           |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep=yes    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 1: 2: Example call flow

9.2.  Example with keep-alive

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

   The figure shows an example where a non-registered UAC sends P1 (edge proxy) forwards an INVITE request, in which it indicates support of keep-alive by
   inserting
   request towards the UAS.  P1 inserts a "keep" parameter in the Via its
   Record-Route header field, to indicate that it is willing to receive
   keep-alives during the lifetime of the INVITE request.
   The dialog.  In addition, the edge
   proxy (P1) also supports inserts a Flow-Timer header field in the response.  The header
   field value indicates the server recommended keep-alive mechanism, frequency.

   The UAS is willing to send keep-alives, so it
   adds inserts a "yes" value to the "keep"
   parameter to the Via in its Contact header field of the
   UAC.  The request is then fowarded towards the UAS.  When the UAC
   receives the INVITE 200 OK (INVITE) response from the UAS it finds out that (OK)
   response.  In addition, the edge proxy supports keep-alive. inserts a Flow-Timer header
   field in the response.  The header field value indicates the server
   recommended keep-alive frequency.  After that the UAC sends UAS starts to send
   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.

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

                        Figure 2: 3: Example call flow

10.

8.  Security Considerations

11.
9.  IANA Considerations
11.1.

9.1.  IANA Registration of the SIP Via header field keep parameter

12.

10.  Acknowledgements

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

13.

11.  References

13.1.

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

   [RFC3327]  Willis, D. and E.
              Schooler, "SIP: Session B. Hoeneisen, "Session Initiation Protocol", Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3261,
              June 3327, December 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]

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) NAT (STUN)",
              draft-ietf-behave-rfc3489bis-18 (work in progress),
              July 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.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com