SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Informational                              May 24, 31, 2010
Expires: November 25, December 2, 2010

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

Abstract

   This specification defines a new Session Initiation Protocol (SIP)
   Via header field parameter, "keep", which allows adjacent SIP
   entities to explicitly negotiate usage of the Network Address
   Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in
   cases where SIP Outbound is not supported, cannot be applied, or
   where usage of keep-alives are is not implicitly negotiated as part of
   the SIP Outbound negotiation.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 25, December 2, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Use-case: Session from non-registered UAs  . . . . . . . .  3
     1.2.  Use-case: SIP Outbound not supported . . . . . . . . . . .  3
     1.3.  Use-case: SIP dialog initiated Outbound flows  . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  User Agent and Proxy behavior  . . . . . . . . . . . . . . . .  4
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Scope and duration  Lifetime of keep-alives  . . . . . . . . . . . . . . . . .  5
       4.2.1.  General  . . . . . . . . . . . . . . . . . . . . . . .  5
       4.2.2.  Keep-alives within associated with registration . . . . . . . . . . .  5
       4.2.3.  Keep-alives within associated with dialog . . . . . . . . . . . . . .  6
     4.3.  Behavior of a SIP entity willing to send keep-alives . . .  6
     4.4.  Behavior of a SIP entity willing to receive keep-alives  .  7
   5.  Keep-alive frequency . . . . . . . . . . . . . . . . . . . . .  8
   6.  Overlap with connection reuse  . . . . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.2.  Keep-alive negotiation: negotiation associated with registration:
           UA-proxy within registration . . .  9
     7.3.  Keep-alive negotiation: UA-proxy within dialog . . . . . . 10
     7.4.  Keep-alive negotiation: UA-UA within dialog . . . . . . . . . . . . . . . .  9
     7.3.  Keep-alive negotiation associated with dialog: UA-proxy  . 10
     7.4.  Keep-alive negotiation associated with dialog: UA-UA . . . 12
   8.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     12.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15

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 SIP Outbound does not possible define
   a mechanism to explicitly negotiate usage of the keep-alive
   mechanisms, since usage of keep-alives in most cases are implicitly
   negotiated as part of the SIP Outbound negotiation.

   However, there are SIP Outbound use-cases where the usage of keep-
   alives keep-alives
   are not implicitly negotiated as part of the SIP Outbound
   negotiation.  In addition, there are cases where SIP Outbound is not
   supported, where it cannot be applied, but where there is still a
   need to be able to negotiate usage of keep-alives.  For those cases,
   a mechanism to explicitly negotiate the usage of keep-alives is
   needed.

   This specification defines a new Session Initiation Protocol (SIP)
   [RFC3261] Via header field parameter, "keep", which allows adjacent
   SIP entities can use to explicitly negotiate the usage of the NAT keep-alive
   mechanisms defined in SIP Outbound.  The "keep" parameter allows SIP
   entities to indicate willingness to send keep-alives, to indicate
   willingness to receive keep-alives, and
   it allows for SIP entities to indciate willingness willing to
   receive keep-
   alives. keep-alives to provide a recommended keep-alive frequency.

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

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

   In some cases a User Agent Client (UAC) does not register itself
   before it establishes a session, but where it still needs to be able
   to establish a session and send keep-alives in order to maintain NAT
   bindings open during the duration session it still needs to be able to
   negotiate sending of the call. keep-alives towards its adjacent upstream SIP
   entity.  A typical example is an emergency calls, call, where a registration
   is not always required. required in order to make the call.

1.2.  Use-case: SIP Outbound not supported

   In some cases all SIP entities that need to be able to negotiate the
   usage of keep-alives do might not support SIP Outbound.  However, they
   might still support the keep-alive mechanisms defined in SIP
   Outbound, and need to be able to negotiate the usage of them.

1.3.  Use-case: SIP dialog initiated Outbound flows

   SIP Outbound allows the establishment of flows using the initial SIP
   dialog requests.
   request for a dialog.  As specified in [RFC5626], the usage keep-alives
   are
   is not implicitly negotiated for such flows.  Therefor there is a
   need flows, why usage needs to be able to
   explicitly negotiate the usage of the keep-alives. negotiated.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Definitions

   Edge proxy: As defined in [RFC5626], a SIP proxy that is located
   topologically between the registering User Agent (UA) and the
   Authoritative Proxy.

   NOTE: In some deployments the edge proxy might physically be located
   in the same entity as the Authoritative Proxy.

   Keep-alives: Refers to keep-alive messages as defined in SIP Outbound
   [RFC5626].

   "keep" parameter: A SIP Via header field parameter that a SIP entity
   can insert in its Via header field of a request to explicitly
   indicate willingness to send keep-alives.  A keep-alives towards it adjacent upstream
   SIP entity can add a
   "yes" parameter value to a "keep" parameter in the top-most Via
   header field of entity.  If a recieved SIP request, to indicate willingness entity is willing to receive keep-alives from the
   its adjacent downstream SIP entity
   (associated with entity, and the top-most Via header field of the received
   request) from which it received
   associated with the request. adjacent downstream SIP entity: entity contains a "keep"
   parameter, the SIP User Agent (UA), or proxy, as defined in [RFC3261].

4.  User Agent and Proxy behavior

4.1.  General

   This section describes of entity willing to receive keep-alives can add an
   integer parameter value to that "keep" parameter.  The integer
   parameter value can be used to indicate a recommended keep-alive
   frequency.  A zero value indicates that the SIP entity is willing to
   receive keep-alives, but that a recommended keep-alive frequency is
   not provided.

   SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261].

4.  User Agent and Proxy behavior

4.1.  General

   This section describes how SIP UAs and proxies negotiate the sending
   or receiving usage of
   keep-alives within associated with a registration and within registration, or a
   dialog.  It also describes dialog, which types
   of SIP requests and responses types can be used in order to negotiate the sending and receiving of keep-
   alives, usage,
   and the lifetime of the negotiated keep-alives.

   SIP requests are used by SIP entities to indicate willingness to send keep-alives towards the
   adjacent upstream SIP entity. entity using SIP requests.  The associated
   responses are used by SIP entities to indicate willingness to receive
   keep-alives.  The procedures to  SIP entities that indicate willingness to send and
   received receive keep-
   alives can provide a recommended keep-alive frequency.

   The procedures to negotiate usage of keep-alives are identical for
   SIP UAs and proxies.

   NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
   entity has indicated willingness to receive keep-alives from its
   adjacent downstream SIP entity, sending of keep-alives towards the
   same SIP entity needs to be separately negotiated.

   NOTE: Since there are SIP entities that already use CRLF keep-alives, a combination of
   Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP
   entities are expected to be able to receive those, this specification
   does not forbid the sending of CRLF keep-alives keep-alive messages towards an
   adjacent upstream SIP entity even if it has not indicated willingess to receive usage of keep-alives using the "keep" parameter. have not
   been negotiated.  However, the "keep" parameter is still important in
   order for a SIP entity to indicate that it supports sending of CRLF keep-alives,
   keep-alive messages, so that the adjacent upstream SIP entity does
   not use other mechanisms (e.g. short registration refresh intervals)
   in order to make sure the keep NAT bindings are kept open.

4.2.  Scope and duration  Lifetime of keep-alives

4.2.1.  General

   The sending and receving of keep-alives can be negotiated within a
   registration, or within a dialog.  The scope lifetime of the negotiated keep-
   alives keep-alives depends on what SIP request methods are used for whether the keep-
   alive negotiation.

   The sending and receiving of keep-alives can be negotiated when a
   registration or dialog is initiated, or later during the registration
   or dialog.  However, once a SIP entity has negotiated the sending of
   keep-alives within a registration or dialog, it can not re-negotiate
   the sending of keep-alives within the same registration or dialog.
   Likewise, once a SIP entity has indicated willingness to receive
   keep-alives within a registration or dialog, it MUST NOT indicate
   willingness to receive keep-alives in a response to
   alives are associated with a subsequent
   request within that registration or dialog.

   A SIP entity that has indicated willingess to receive keep-alives
   within a dialog can still, in a subsequent request within the dialog,
   indicate willingness to send keep-alives within the same dialog.
   Likewise, a SIP entity that has negotiated  The section
   describes the sending lifetime of keep-alives
   within a dialog can in a response to a subsequent request indicate
   willingness to receive keep-alives within the same dialog. negotiated keep-alives.

4.2.2.  Keep-alives within associated with registration

   SIP entities use the REGISTER method use a registration request in order to negotiate the
   sending and reciving usage
   of keep-alives within associated with a registration.  The keep-
   alives  Usage of keep-alives
   can be negotiated when the registration is established, or later within
   during the lifetime of the registration.  Once negotiated, the keep-alives keep-
   alives are sent during until the lifetime of registration is terminated, or until a
   subsequent registration refresh request is sent or forwarded.  When a
   subsequent registration refresh request is sent or forwarded, if a
   SIP entity is willing to continue sending keep-alives associated with
   the registration, until it usage of keep-alives MUST be re-negotiated.  If
   usage is terminated. not successfully re-negotiated, the SIP entity MUST cease
   sending of keep-alives associated with the registration.

   In case a SIP entity establishes multiple registration flows
   [RFC5626], the sending and receiving usage of keep-alives is done needs to be negotiated separately for
   each individual registration flow.  The  A SIP entity MUST NOT send keep-alives on keep-
   alives associated with a registration flows where it flow for which usage of keep-
   alives has not
   received an indicator that the adjacent upstream SIP entity is
   willing to receive keep-alives withing that registration flow. been negotiated.

4.2.3.  Keep-alives within associated with dialog

   SIP entities use a an initial request for a dialog, or a mid-dialog
   target refresh request [RFC3261] [RFC3261], in order to negotiate the sending and reciving
   receiving of keep-alives within associated with a dialog.  The keep-alives  Usage of keep-
   alives can be negotiated when the dialog is established, or later within
   during the lifetime of the dialog.  Once negotiated, the keep-alives are MUST
   be sent during for the lifetime of the dialog, until it the dialog is
   terminated.

   Since an ACK request does not have an  Once usage of keep-alives associated response, with a dialog has
   been negotiated, it can is not
   be used possible to negotiate re-negotiate the sending and reciving of keep-alives.
   Therefor a SIP entity MUST NOT insert a "keep" parameter in its Via
   header field of an ACK request.  If a SIP entity receives a "keep"
   parameter in an ACK request, it MUST ignore usage
   associated with the parameter. dialog.

4.3.  Behavior of a SIP entity willing to send keep-alives

   As defined in [RFC5626], a SIP entity that supports the sending of
   keep-alives keep-
   alives must act as a Session Traversal Utilities for NAT (STUN)
   client [RFC5389].  The SIP entity must support the amount of STUN
   which is required to apply the STUN keep-alive mechanism defined in
   [RFC5626], and it must support the CRLF keep-alive mechanism defined
   in [RFC5626].

   When a SIP entity sends or forwards a request, if it wants to
   negotiate the sending of keep-alives within for the lifetime of a
   registration (in case of a REGISTER request) request), or a dialog (in case of
   an initial request for a
   dialog, or a mid-dialog target refresh request), and if it has not
   previously negotiated the sending of keep-alives within the same
   registration or initial request for a dialog, or a mid-dialog target refresh
   request), it MUST insert a "keep" parameter in its Via header field
   of the request.

   When the SIP entity receives the associated response, if the "keep"
   parameter in its Via header field in of the response contains a "yes"
   parameter value, it MUST start to send keep-alives towards the same
   destination where it would send a subsequent request (e.g.  REGISTER
   requests and initial requests for dialog) associated with the
   registration (if the keep-alive negotiation is for a registration),
   or where it would send subsequent mid-dialog reuqests requests (if the keep-
   alive negotiation is for a dialog).  Subsequent mid-dialog requests
   are addressed based on the dialog route set.

   If the response contains

   Once a Flow-Timer header field, the SIP entity has negotiated sending of keep-alives associated
   with a dialog towards its adjacent upstream SIP entity, it MUST remove NOT
   insert a "keep" parameter in any subsequent SIP requests associated
   with the header field before dialog.  Such "keep" parameter MUST be ignored, if received.

   Since an ACK request does not have an associated response, it forwards the response towards
   another can not
   be used to negotiate usage of keep-alives.  Therefore, a SIP entity. entity
   MUST NOT insert a "keep" parameter in its Via header field of an ACK
   request.  Such "keep" parameter MUST be ignored, if received.

   When a SIP entity is about to send a keep-alive, if the SIP entity at
   the same time is also about to send or forward a SIP request within
   associated with the same registration or dialog, for which the keep-alive keep-
   alive is to be sent, the SIP entity MAY choose not to send the keep-alive, keep-
   alive, as the SIP request will perform the same keep-alive action.

   NOTE: When a SIP entity sends an initial request for a dialog, if the
   adjacent upstream SIP entity does not insert itself in the dialog
   route set using a Record-Route header field, field [RFC3261], the adjacent
   upstream SIP entity will change once the dialog route set has been
   established.  If a SIP entity inserts a "keep" parameter in its Via
   header field of an initial request for a dialog, and the "keep"
   parameter in the associated response does not contain a "yes" parameter
   value, the SIP entity can might choose to insert a "keep" parameter in
   its Via header field of a subsequent SIP request within associated with the
   dialog, in case the new adjacent SIP entity (based on the dialog
   route set) is willing to receive keep-alives (in which case it will
   add a "yes" parameter value to the "keep" parameter).

   NOTE: If a SIP entity inserts a "keep" parameter in its Via header
   field of an INVITE request, and it receives multiple responses
   (provisional or final) associated with the request, as long as at
   least one of the responses, for a specific per dialog, contains a "keep" parameter
   with a "yes" parameter value it is seen as an indication that the adjacent
   upstream SIP entity is willing to receive keep-alives within associated with
   the dialog.

4.4.  Behavior of a SIP entity willing to receive keep-alives

   As defined in [RFC5626], a SIP entity that supports receiving of
   keep-alives must act as a STUN server [RFC5389].  The SIP entity must
   support the amount of STUN which is required to apply the STUN keep-
   alive mechanism defined in [RFC5626], and it must support the CRLF
   keep-alive mechanism defined in [RFC5626].

   When a SIP entity creates or receives a response to a request that
   can be used in order to
   negotiate the sending indicate willingness to send keep-alives
   associated with a registration or dialog, and receiveing of keep-alives, the top-most Via header field of
   associated with the request adjacent downstream SIP entity (that is, the top-
   most Via header field once a SIP entity that received the response
   has removed its own Via header field from the response) contains a
   "keep" parameter, and if the SIP entity has not previously indicated willingess is willing to receive keep-alives
   from the adjacent downstream SIP entity within
   associated with the registration (in case of a REGISTER request) response), or
   the dialog (in case of a response to an initial request for a dialog,
   or a response to a mid-dialog target refresh request), if it is
   willing to receive keep-alives from the
   adjacent downstream SIP entity it MUST add a "yes" parameter value to the
   "keep" parameter of
   the top-most Via header field of the request, parameter, before sending or forwarding the
   request or creating a response.  In addition, the SIP entity MAY
   insert  The
   parameter can contain a Flow-Timer header field [RFC5626] in the associated
   response, which indicates the recommended keep-alive frequency for
   the registration frequency, or dialog. a zero
   value.

5.  Keep-alive frequency

   If a SIP entity receives a SIP response, where its Via header field
   contains a "keep" parameter with a "yes" value, also contains non-zero value that indicates a Flow-
   Timer
   recommended keep-alive frequency, it MUST use the procedures defined
   for the Flow-Timer header field [RFC5626], according [RFC5626].  According to [RFC5626] the
   procedures, the SIP entity
   MUST must send keep-alives at least as often as this number of seconds,
   the indicated recommended keep-alive frequency, and if the SIP entity
   uses the server-recommended recommended keep-alive frequency then it should send its
   keep-alives so that the interval between each keep-alive israndomly is randomly
   distributed between 80% and 100% of the
   server-provided time. recommended keep-alive
   frequency.

   If the received "keep" parameter value is zero, the SIP entity does not receive a Flow-Timer header field from the
   edge proxy, it can
   send keep-alives at its discretion.  [RFC5626] provides additional
   guidance on selecting the keep-alive frequency in case a Flow-Timer header field recommended
   keep-alive frequency is not received.

   OPEN ISSUE: It has been suggested that, instead of using provided.

   A SIP entity that uses the "keep" parameter to indicate willingness
   to receive keep-alives MUST NOT use the Flow-
   Timer Flow-Timer header field in
   order to provide the recommented a recommended keep-alive
   frequency value, frequency.

   SIP Outbound uses the value would Flow-Timer header field to indicate the server-
   recommended keep-alive frequency.  However, it will only be added as sent
   between a parameter to UA and an edge proxy.  Using the "keep" parameter, instead however,
   the sending and receiving of keep-alives might be negotiated between
   multiple entities on the signalling path.  Since the "yes" server-
   recommended keep-alive frequency might vary between different SIP
   entities, those would have to re-write the Flow-Timer header field
   value.  In addition, if a SIP entity does not indicate willingness to
   receive keep-alives from its adjacent downstream SIP entity, and
   receives a Flow-Timer header field in a response, it would have to
   remove the Flow-Timer header field from the response.  This issue
   does not exist for the "keep" parameter, as each SIP entity has its
   own individual Via header field.

6.  Overlap with connection reuse

   The connect-reuse specification [I-D.ietf-sip-connect-reuse]
   specifies how to use connection-oriented transports to send requests
   in the reverse direction.  SIP entity A opens a connection to entity
   B in order to send a request.  Under certain conditions entity B can
   reuse that connection for sending requests in the backwards direction
   to A as well.  However, the connect-reuse specification does not
   define a keep-alive mechanism for this connection.

   The mechanism specified in this draft is thus orthogonal to the
   purpose of connection reuse.  An entity that wants to use connection-
   reuse as well as indicate keep-alive mechanism on that connection
   will insert both the "alias" parameter defined in [connect-reuse] as
   well as the "keep" parameter defined in this memo.  Inserting only
   one of these parameters is not a substitute for the other.  Thus,
   while the presence of a "keep" parameter will indicate that the enity
   entity supports keep-alives in order to keep the connection open, no
   inference can be drawn on whether that connection can be used for
   requests in the backwards direction.

7.  Examples

7.1.  General

   This section shows example flows where the usage of keep-alives keep-alives,
   associated with a registration and a dialog, is negotiated between
   different SIP entities, within a registration or
   within a dialog. entities.

7.2.  Keep-alive negotiation: negotiation associated with registration: UA-proxy within registration

   The figure shows an example where Alice sends an REGISTER request.
   She indicates willingness of sending keep-alive by inserting a "keep"
   parameter in her Via header field of the request.  The edge proxy
   (P1) supports the keep-alive mechanism, and is willing to receive
   keep-alives from Alice during the registration, so it adds a "yes"
   value to the "keep" parameter in the Via header field of the UAC,
   before it proxy
   (P1) forwards the request towards the registrar.

   P1 is willing to receive keep-alives from Alice for the duration of
   the registration, so When P1 receives the associated response, response it inserts adds
   a Flow-Timer
   header field, with keep parameter value, which indicates a recommended keep-alive
   frequency interval of 30 seconds, in the response, to Alice's Via header field, before it
   forwards the response towards Alice.

   When Alice receives the response, she determines from her Via header
   field that P1 is willing to receive keep-alives within associated with the
   registration.  For the duration lifetime of the registration, the UAC Alice then sends
   periodic keep-alives (in this example using the STUN keep-alive
   technique) towards P1, using the recommended keep-alive frequency
   indicated in the Flow-Timer header field of by the response. keep parameter value.

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

                        Figure 1: Example call flow

7.3.  Keep-alive negotiation: negotiation associated with dialog: UA-proxy within dialog

   The figure shows an example where Alice sends an initial INVITE
   request for a dialog.  She indicates willingness to send keep-alive
   by inserting a "keep" parameter in her Via header field of the
   request.  The edge proxy (P1) adds itself to the dialog route set by
   adding itself to a Record-Route header field.  P1 also supports field, before it forwards the
   keep-alive mechanism, and
   request towards Bob.

   P1 is willing to receive keep-alives from Alice during the dialog, so it adds a "yes" value to the "keep"
   parameter in for the Via header field duration of Alice, before it forwards
   the
   request towards Bob. dialog, so When P1 receives the associated response, response it inserts adds a Flow-Timer
   header field, with
   keep parameter value, which indicates a recommended keep-alive
   frequency interval of 30 seconds, in the response, to Alice's Via header field, before it
   forwards the response towards Alice.

   When Alice receives the response, she determines from its her Via header
   field that P1 is willing to receive keep-alives within associated with the
   dialog.  For the duration lifetime of the dialog, she Alice then sends periodic
   keep-alives (in this example using the STUN keep-alive technique)
   towards P1, using the recommended keep-alive frequency indicated in the Flow-
   Timer header field of by
   the response. keep parameter value.

     Alice                        P1                         Bob
       |                          |                           |
       |--- INVITE -------------->|                           |
       |    Via: UAC;keep Alice;keep       |                           |
       |                          |--- INVITE --------------->|
       |                          |    Via: P1                |
       |                          |    Via: UAC;keep=yes Alice;keep        |
       |                          |    Record-Route: P1       |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: P1                |
       |                          |    Via: UAC;keep=yes Alice;keep        |
       |                          |    Record-Route: P1       |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep=yes     |                           |
       |    Flow-Timer: 30    Alice: UAC;keep=30    |                           |
       |    Record-Route: P1      |                           |
       |                          |                           |
       |--- ACK ----------------->|                           |
       |                          |                           |
       |                          |--- ACK ------------------>|
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |=== STUN request ========>|                           |
       |<== STUN response ========|                           |
       |                          |                           |
       |                          |                           |
       |--- BYE ----------------->|                           |
       |                          |                           |
       |                          |--- BYE ------------------>|
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |                           |

                        Figure 2: Example call flow

7.4.  Keep-alive negotiation: negotiation associated with dialog: UA-UA within dialog

   The figure shows an example where Alice sends an initial INVITE
   request for a dialog.  She indicates willingness to send keep-alive
   by inserting a "keep" parameter in her Via header field of the
   request.  The edge proxy (P1) does not add itself to the dialog route
   set
   set, by adding itself to a Record-Route header field, and before it does not
   indicate willingness to receive keep-alives from Alice.
   forwards the request towards Bob. .

   When Alice receives the response, she determines from her Via header
   field that P1 is not willing to receive keep-alives associated with
   the dialog from her.  When the dialog route set has been established,
   Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not
   insert itself in the dialog route set), and she once again indicates
   willingness to send keep-alives by inserting a "keep" parameter in
   her Via header field of the request.  Bob supports the keep-alive
   mechanism, and is willing to receive keep-alives from Alice during the dialog, so he
   adds a "yes" value to the "keep" parameter in associated with the Via header field of
   dialog from Alice, before so he creates and sends a response towards her.  Bob also
   inserts and adds a Flow-Timer header field in the response, with keep parameter
   value, which indicates a recommended keep-alive frequency interval of 30 seconds.
   seconds, to Alice's Via header field, before he forwards the response
   towards Alice.

   When Alice receives the response, she determines from her Via header
   field that Bob P1 is willing to receive keep-alives from her within associated with the
   dialog.  For the duration lifetime of the dialog, Alice then sends periodic
   keep-alives (in this example using the STUN keep-alive technique)
   towards Bob, using the recommended keep-alive frequency indicated in
   the Flow-Timer header field of by
   the response. keep parameter value.

     Alice                        P1                         Bob
       |                          |                           |
       |--- INVITE -------------->|                           |
       |    Via: UAC;keep Alice;keep       |                           |
       |                          |--- INVITE --------------->|
       |                          |    Via: P1                |
       |                          |    Via: UAC:keep Alice:keep        |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: P1                |
       |                          |    Via: UAC;keep Alice;keep        |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep Alice;keep       |                           |
       |                          |                           |
       |                                                      |
       |--- ACK --------------------------------------------->|
       |                                                      |
       |--- UPDATE ------------------------------------------>|
       |    Via: UAC;keep Alice;keep                                   |
       |                                                      |
       |<-- 200 OK ------------------------------------------>|
       |    Via: UAC;keep=yes                                 |
       |    Flow-Timer: 30 UAC;keep=30                                  |
       |                                                      |
       |                                                      |
       |                   *** Timeout ***                    |
       |                                                      |
       |=== STUN request ====================================>|
       |<== STUN response ====================================|
       |                                                      |
       |                   *** Timeout ***                    |
       |                                                      |
       |=== STUN request ====================================>|
       |<== STUN response ====================================|
       |                                                      |
       |                                                      |
       |--- BYE --------------------------------------------->|
       |                                                      |
       |<-- 200 OK -------------------------------------------|
       |                                                      |

                        Figure 3: Example call flow

8.  Grammar

   This specification defines a new Via header field parameter, "keep".
   The grammar includes the definitions from [RFC5626].

   The ABNF [RFC5234] is:

   via-params =/ keep

   keep       = "keep" [ EQUAL "yes" 1*(DIGIT) ]

9.  IANA Considerations

9.1.  keep

   This specification defines a new Via header field parameter called
   keep in the "Header Field Parameters and Parameter Values" sub-
   registry as per the registry created by [RFC5626].  The syntax is
   defined in Section 8.  The required information is:

                                                  Predefined
   Header Field            Parameter Name         Values      Reference
   ----------------------  ---------------------  ----------  ---------
   Via                     keep                   No          [RFCXXXX]

10.  Security Considerations

   This specification does not introduce security consideritions considerations in
   additions
   addition to those specified in [RFC5626].

11.  Acknowledgements

   Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer
   and Milo Orsic for their comments on the initial draft.  Thanks to
   Juha Heinaenen, Jiri Kuthan, Dean Willis and John Elwell for their
   comments on the list.  Thanks to Vijay Gurbani for providing text
   about the relationship with the connect-reuse specification.

12.  References

12.1.  Normative References

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

12.2.  Informative References

   [I-D.ietf-sip-connect-reuse]
              Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
              the Session Initiation Protocol (SIP)",
              draft-ietf-sip-connect-reuse-14 (work in progress),
              August 2009.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com