draft-ietf-sipcore-keep-03.txt   draft-ietf-sipcore-keep-04.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational May 24, 2010 Intended status: Informational May 31, 2010
Expires: November 25, 2010 Expires: December 2, 2010
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-03.txt draft-ietf-sipcore-keep-04.txt
Abstract Abstract
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "keep", which allows adjacent SIP Via header field parameter, "keep", which allows adjacent SIP
entities to explicitly negotiate usage of the Network Address entities to explicitly negotiate usage of the Network Address
Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in
cases where SIP Outbound is not supported, cannot be applied, or cases where SIP Outbound is not supported, cannot be applied, or
where usage of keep-alives are not implicitly negotiated as part of where usage of keep-alives is not implicitly negotiated as part of
the SIP Outbound negotiation. the SIP Outbound negotiation.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2010. This Internet-Draft will expire on December 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use-case: Session from non-registered UAs . . . . . . . . 3 1.1. Use-case: Session from non-registered UAs . . . . . . . . 3
1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3 1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3
1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3 1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Scope and duration of keep-alives . . . . . . . . . . . . 5 4.2. Lifetime of keep-alives . . . . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Keep-alives within registration . . . . . . . . . . . 5 4.2.2. Keep-alives associated with registration . . . . . . . 5
4.2.3. Keep-alives within dialog . . . . . . . . . . . . . . 6 4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6
4.3. Behavior of a SIP entity willing to send keep-alives . . . 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 4.4. Behavior of a SIP entity willing to receive keep-alives . 7
5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8
6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Keep-alive negotiation: UA-proxy within registration . . . 9 7.2. Keep-alive negotiation associated with registration:
7.3. Keep-alive negotiation: UA-proxy within dialog . . . . . . 10 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. Keep-alive negotiation: UA-UA within dialog . . . . . . . 12 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 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive
mechanisms. Eventhough the keep-alive mechanisms are separated from mechanisms. Eventhough the keep-alive mechanisms are separated from
the rest of the SIP Outbound mechanism, it is currently not possible the rest of the SIP Outbound mechanism, SIP Outbound does not define
to explicitly negotiate usage of the keep-alive mechanisms, since a mechanism to explicitly negotiate usage of the keep-alive
usage of keep-alives in most cases are implicitly negotiated as part mechanisms, since usage of keep-alives in most cases are implicitly
of the SIP Outbound negotiation. negotiated as part of the SIP Outbound negotiation.
However, there are SIP Outbound use-cases where the usage of keep- However, there are SIP Outbound use-cases where usage of keep-alives
alives are not implicitly negotiated as part of the SIP Outbound are not implicitly negotiated as part of the SIP Outbound
negotiation. In addition, there are cases where SIP Outbound is not negotiation. In addition, there are cases where SIP Outbound is not
supported, where it cannot be applied, but where there is still a 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, need to be able to negotiate usage of keep-alives.
a mechanism to explicitly negotiate the usage of keep-alives is
needed.
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
[RFC3261] Via header field parameter, "keep", which allows adjacent [RFC3261] Via header field parameter, "keep", which allows adjacent
SIP entities can use to explicitly negotiate the usage of the NAT SIP entities to explicitly negotiate usage of the NAT keep-alive
keep-alive mechanisms defined in SIP Outbound. The "keep" parameter mechanisms defined in SIP Outbound. The "keep" parameter allows SIP
allows SIP entities to indicate willingness to send keep-alives, and entities to indicate willingness to send keep-alives, to indicate
it allows SIP entities to indciate willingness to receive keep- willingness to receive keep-alives, and for SIP entities willing to
alives. receive keep-alives to provide a recommended keep-alive frequency.
The following sections describe use-cases where a mechanism to The following sections describe use-cases where a mechanism to
explicitly negotiate the usage of keep-alives is needed. explicitly negotiate usage of keep-alives is needed.
1.1. Use-case: Session from non-registered UAs 1.1. Use-case: Session from non-registered UAs
In some cases a User Agent Client (UAC) does not register itself 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 before it establishes a session, but in order to maintain NAT
to establish a session and send keep-alives in order to maintain NAT bindings open during the session it still needs to be able to
bindings open during the duration of the call. A typical example is negotiate sending of keep-alives towards its adjacent upstream SIP
an emergency calls, where a registration is not always required. entity. A typical example is an emergency call, where a registration
is not always required in order to make the call.
1.2. Use-case: SIP Outbound not supported 1.2. Use-case: SIP Outbound not supported
In some cases all SIP entities that need to be able to negotiate the In some cases all SIP entities that need to be able to negotiate the
usage of keep-alives do not support SIP Outbound. However, they usage of keep-alives might not support SIP Outbound. However, they
still support the keep-alive mechanisms defined in SIP Outbound, and might still support the keep-alive mechanisms defined in SIP
need to be able to negotiate the usage of them. Outbound, and need to be able to negotiate usage of them.
1.3. Use-case: SIP dialog initiated Outbound flows 1.3. Use-case: SIP dialog initiated Outbound flows
SIP Outbound allows the establishment of flows using initial SIP SIP Outbound allows the establishment of flows using the initial
dialog requests. As specified in [RFC5626], the usage keep-alives request for a dialog. As specified in [RFC5626], usage keep-alives
are not implicitly negotiated for such flows. Therefor there is a is not implicitly negotiated for such flows, why usage needs to be
need to be able to explicitly negotiate the usage of the keep-alives. explicitly negotiated.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
skipping to change at page 4, line 27 skipping to change at page 4, line 26
Authoritative Proxy. Authoritative Proxy.
NOTE: In some deployments the edge proxy might physically be located NOTE: In some deployments the edge proxy might physically be located
in the same entity as the Authoritative Proxy. in the same entity as the Authoritative Proxy.
Keep-alives: Refers to keep-alive messages as defined in SIP Outbound Keep-alives: Refers to keep-alive messages as defined in SIP Outbound
[RFC5626]. [RFC5626].
"keep" parameter: A SIP Via header field parameter that a SIP entity "keep" parameter: A SIP Via header field parameter that a SIP entity
can insert in its Via header field of a request to explicitly can insert in its Via header field of a request to explicitly
indicate willingness to send keep-alives. A SIP entity can add a indicate willingness to send keep-alives towards it adjacent upstream
"yes" parameter value to a "keep" parameter in the top-most Via SIP entity. If a SIP entity is willing to receive keep-alives from
header field of a recieved SIP request, to indicate willingness to its adjacent downstream SIP entity, and the Via header field
receive keep-alives from the adjacent downstream SIP entity associated with the adjacent downstream SIP entity contains a "keep"
(associated with the top-most Via header field of the received parameter, the SIP entity willing to receive keep-alives can add an
request) from which it received the request. 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]. SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261].
4. User Agent and Proxy behavior 4. User Agent and Proxy behavior
4.1. General 4.1. General
This section describes of SIP UAs and proxies negotiate the sending This section describes how SIP UAs and proxies negotiate usage of
or receiving of keep-alives within a registration and within a keep-alives associated with a registration, or a dialog, which types
dialog. It also describes which types of SIP requests and responses of SIP requests types can be used in order to negotiate the usage,
can be used in order to negotiate the sending and receiving of keep- and the lifetime of the negotiated keep-alives.
alives, and the lifetime of the negotiated keep-alives.
SIP requests are used by SIP entities to indicate willingness to send SIP entities indicate willingness to send keep-alives towards the
keep-alives towards the adjacent upstream SIP entity. The associated adjacent upstream SIP entity using SIP requests. The associated
responses are used by SIP entities to indicate willingness to receive responses are used by SIP entities to indicate willingness to receive
keep-alives. The procedures to indicate willingness to send and keep-alives. SIP entities that indicate willingness to receive keep-
received keep-alives are identical for UAs and proxies. alives can provide a recommended keep-alive frequency.
NOTE: Since there are SIP entities that already use CRLF keep-alives, The procedures to negotiate usage of keep-alives are identical for
and SIP entities are expected to be able to receive those, this SIP UAs and proxies.
specification does not forbid the sending of CRLF keep-alives towards
an SIP entity even if it has not indicated willingess to receive
keep-alives using the "keep" parameter. However, the "keep"
parameter is still important in order for a SIP entity to indicate
that it supports CRLF keep-alives, so that the adjacent SIP entity
does not use other mechanisms (e.g. short registration refresh
intervals) in order to make sure the NAT bindings are kept open.
4.2. Scope and duration of keep-alives 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.
4.2.1. General NOTE: Since there are SIP entities that already use a combination of
Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP
entities are expected to be able to receive those, this specification
does not forbid the sending of CRLF keep-alive messages towards an
adjacent upstream SIP entity even if usage of keep-alives have not
been negotiated. However, the "keep" parameter is still important in
order for a SIP entity to indicate that it supports sending of CRLF
keep-alive messages, so that the adjacent upstream SIP entity does
not use other mechanisms (e.g. short registration refresh intervals)
in order to keep NAT bindings open.
The sending and receving of keep-alives can be negotiated within a 4.2. Lifetime of keep-alives
registration, or within a dialog. The scope of the negotiated keep-
alives depends on what SIP request methods are used for the keep-
alive negotiation.
The sending and receiving of keep-alives can be negotiated when a 4.2.1. General
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 a subsequent
request within that registration or dialog.
A SIP entity that has indicated willingess to receive keep-alives The lifetime of negotiated keep-alives depends on whether the keep-
within a dialog can still, in a subsequent request within the dialog, alives are associated with a registration or a dialog. The section
indicate willingness to send keep-alives within the same dialog. describes the lifetime of negotiated keep-alives.
Likewise, a SIP entity that has negotiated the sending of keep-alives
within a dialog can in a response to a subsequent request indicate
willingness to receive keep-alives within the same dialog.
4.2.2. Keep-alives within registration 4.2.2. Keep-alives associated with registration
SIP entities use the REGISTER method in order to negotiate the SIP entities use a registration request in order to negotiate usage
sending and reciving of keep-alives within a registration. The keep- of keep-alives associated with a registration. Usage of keep-alives
alives can be negotiated when the registration is established, or can be negotiated when the registration is established, or later
later within the registration. Once negotiated, the keep-alives are during the lifetime of the registration. Once negotiated, keep-
sent during the lifetime of the registration, until it is terminated. alives are sent until the registration is terminated, or until a
subsequent registration refresh request is sent or forwarded. When a
subsequent registration refresh request is sent or forwarded, if a
SIP entity is willing to continue sending keep-alives associated with
the registration, usage of keep-alives MUST be re-negotiated. If
usage is not successfully re-negotiated, the SIP entity MUST cease
sending of keep-alives associated with the registration.
In case a SIP entity establishes multiple registration flows In case a SIP entity establishes multiple registration flows
[RFC5626], usage of keep-alives needs to be negotiated separately for
each individual registration flow. A SIP entity MUST NOT send keep-
alives associated with a registration flow for which usage of keep-
alives has not been negotiated.
[RFC5626], the sending and receiving of keep-alives is done 4.2.3. Keep-alives associated with dialog
separately for each individual registration flow. The SIP entity
MUST NOT send keep-alives on registration flows where it has not
received an indicator that the adjacent upstream SIP entity is
willing to receive keep-alives withing that registration flow.
4.2.3. Keep-alives within dialog
SIP entities use a initial request for a dialog, or a mid-dialog
target refresh request [RFC3261] in order to negotiate the sending
and reciving of keep-alives within a dialog. The keep-alives can be
negotiated when the dialog is established, or later within the
dialog. Once negotiated, the keep-alives are sent during the
lifetime of the dialog, until it is terminated.
Since an ACK request does not have an associated response, it can not SIP entities use an initial request for a dialog, or a mid-dialog
be used to negotiate the sending and reciving of keep-alives. target refresh request [RFC3261], in order to negotiate sending and
Therefor a SIP entity MUST NOT insert a "keep" parameter in its Via receiving of keep-alives associated with a dialog. Usage of keep-
header field of an ACK request. If a SIP entity receives a "keep" alives can be negotiated when the dialog is established, or later
parameter in an ACK request, it MUST ignore the parameter. during the lifetime of the dialog. Once negotiated, keep-alives MUST
be sent for the lifetime of the dialog, until the dialog is
terminated. Once usage of keep-alives associated with a dialog has
been negotiated, it is not possible to re-negotiate the usage
associated with the dialog.
4.3. Behavior of a SIP entity willing to send keep-alives 4.3. Behavior of a SIP entity willing to send keep-alives
As defined in [RFC5626], a SIP entity that supports the sending of As defined in [RFC5626], a SIP entity that supports sending of keep-
keep-alives must act as a Session Traversal Utilities for NAT (STUN) alives must act as a Session Traversal Utilities for NAT (STUN)
client [RFC5389]. The SIP entity must support the amount of STUN client [RFC5389]. The SIP entity must support the amount of STUN
which is required to apply the STUN keep-alive mechanism defined in which is required to apply the STUN keep-alive mechanism defined in
[RFC5626], and it must support the CRLF keep-alive mechanism defined [RFC5626], and it must support the CRLF keep-alive mechanism defined
in [RFC5626]. in [RFC5626].
When a SIP entity sends or forwards a request, if it wants to When a SIP entity sends or forwards a request, if it wants to
negotiate the sending of keep-alives within the registration (in case negotiate the sending of keep-alives for the lifetime of a
of a REGISTER request) or dialog (in case of an initial request for a registration (in case of a REGISTER request), or a dialog (in case of
dialog, or a mid-dialog target refresh request), and if it has not an initial request for a dialog, or a mid-dialog target refresh
previously negotiated the sending of keep-alives within the same request), it MUST insert a "keep" parameter in its Via header field
registration or dialog, it MUST insert a "keep" parameter in its Via of the request.
header field of the request.
When the SIP entity receives the associated response, if the "keep" When the SIP entity receives the associated response, if the "keep"
parameter in its Via header field in the response contains a "yes" parameter in its Via header field of the response contains a
parameter value, it MUST start to send keep-alives towards the same parameter value, it MUST start to send keep-alives towards the same
destination where it would send a subsequent request (e.g. REGISTER destination where it would send a subsequent request (e.g. REGISTER
requests and initial requests for dialog) associated with the requests and initial requests for dialog) associated with the
registration (if the keep-alive negotiation is for a registration), registration (if the keep-alive negotiation is for a registration),
or where it would send subsequent mid-dialog reuqests (if the keep- or where it would send subsequent mid-dialog requests (if the keep-
alive negotiation is for a dialog). Subsequent mid-dialog requests alive negotiation is for a dialog). Subsequent mid-dialog requests
are addressed based on the dialog route set. are addressed based on the dialog route set.
If the response contains a Flow-Timer header field, the SIP entity Once a SIP entity has negotiated sending of keep-alives associated
MUST remove the header field before it forwards the response towards with a dialog towards its adjacent upstream SIP entity, it MUST NOT
another SIP entity. insert a "keep" parameter in any subsequent SIP requests associated
with the dialog. Such "keep" parameter MUST be ignored, if received.
Since an ACK request does not have an associated response, it can not
be used to negotiate usage of keep-alives. Therefore, a SIP entity
MUST NOT insert a "keep" parameter in its Via header field of an ACK
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 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 the same time is also about to send or forward a SIP request
the same registration or dialog, for which the keep-alive is to be associated with the same registration or dialog, for which the keep-
sent, the SIP entity MAY choose not to send the keep-alive, as the alive is to be sent, the SIP entity MAY choose not to send the keep-
SIP request will perform the same keep-alive action. 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 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 adjacent upstream SIP entity does not insert itself in the dialog
route set using a Record-Route header field, the adjacent upstream route set using a Record-Route header field [RFC3261], the adjacent
SIP entity will change once the dialog route set has been upstream SIP entity will change once the dialog route set has been
established. If a SIP entity inserts a "keep" parameter in its Via established. If a SIP entity inserts a "keep" parameter in its Via
header field of an initial request for a dialog, and the "keep" header field of an initial request for a dialog, and the "keep"
parameter in the associated response does not contain a "yes" parameter in the associated response does not contain a parameter
parameter value, the SIP entity can insert a "keep" parameter in its value, the SIP entity might choose to insert a "keep" parameter in
Via header field of a subsequent request within the dialog, in case its Via header field of a subsequent SIP request associated with the
the new adjacent SIP entity is willing to receive keep-alives (in dialog, in case the new adjacent SIP entity (based on the dialog
which case it will add a "yes" parameter value to the "keep" route set) is willing to receive keep-alives (in which case it will
parameter). add a parameter value to the "keep" parameter).
NOTE: If a SIP entity inserts a "keep" parameter in its Via header NOTE: If a SIP entity inserts a "keep" parameter in its Via header
field of an INVITE request, and it receives multiple responses field of an INVITE request, and it receives multiple responses
(provisional or final) associated with the request, as long as at (provisional or final) associated with the request, as long as at
least one of the responses, for a specific dialog, contains a "keep" least one of the responses, per dialog, contains a "keep" parameter
parameter with a "yes" value it is seen as an indication that the with a parameter value it is seen as an indication that the adjacent
adjacent upstream SIP entity is willing to receive keep-alives within upstream SIP entity is willing to receive keep-alives associated with
the dialog. the dialog.
4.4. Behavior of a SIP entity willing to receive keep-alives 4.4. Behavior of a SIP entity willing to receive keep-alives
As defined in [RFC5626], a SIP entity that supports receiving of As defined in [RFC5626], a SIP entity that supports receiving of
keep-alives must act as a STUN server [RFC5389]. The SIP entity must 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- support the amount of STUN which is required to apply the STUN keep-
alive mechanism defined in [RFC5626], and it must support the CRLF alive mechanism defined in [RFC5626], and it must support the CRLF
keep-alive mechanism defined in [RFC5626]. keep-alive mechanism defined in [RFC5626].
When a SIP entity receives request that can be used in order to When a SIP entity creates or receives a response to a request that
negotiate the sending and receiveing of keep-alives, the top-most Via can be used in order to indicate willingness to send keep-alives
header field of the request contains a "keep" parameter, and the SIP associated with a registration or dialog, and the Via header field
entity has not previously indicated willingess to receive keep-alives associated with the adjacent downstream SIP entity (that is, the top-
from the adjacent downstream SIP entity within the registration (in most Via header field once a SIP entity that received the response
case of a REGISTER request) or dialog (in case of a initial request has removed its own Via header field from the response) contains a
for a dialog, or a mid-dialog target refresh request), if it is "keep" parameter, if the SIP entity is willing to receive keep-alives
willing to receive keep-alives from the adjacent downstream SIP associated with the registration (in case of a REGISTER response), or
entity it MUST add a "yes" parameter value to the "keep" parameter of the dialog (in case of a response to an initial request for a dialog,
the top-most Via header field of the request, before forwarding the or a response to a mid-dialog target refresh request), from the
request or creating a response. In addition, the SIP entity MAY adjacent downstream SIP entity it MUST add a parameter value to the
insert a Flow-Timer header field [RFC5626] in the associated "keep" parameter, before sending or forwarding the response. The
response, which indicates the recommended keep-alive frequency for parameter can contain a recommended keep-alive frequency, or a zero
the registration or dialog. value.
5. Keep-alive frequency 5. Keep-alive frequency
If a SIP entity receives a SIP response, where its Via header field If a SIP entity receives a SIP response, where its Via header field
contains a "keep" parameter with a "yes" value, also contains a Flow- contains a "keep" parameter with a non-zero value that indicates a
Timer header field [RFC5626], according to [RFC5626] the SIP entity recommended keep-alive frequency, it MUST use the procedures defined
MUST send keep-alives at least as often as this number of seconds, for the Flow-Timer header field [RFC5626]. According to the
and if the SIP entity uses the server-recommended keep-alive procedures, the SIP entity must send keep-alives at least as often as
frequency it should send its keep-alives so that the interval between the indicated recommended keep-alive frequency, and if the SIP entity
each keep-alive israndomly distributed between 80% and 100% of the uses the recommended keep-alive frequency then it should send its
server-provided time. keep-alives so that the interval between each keep-alive is randomly
distributed between 80% and 100% of the recommended keep-alive
frequency.
If the SIP entity does not receive a Flow-Timer header field from the If the received "keep" parameter value is zero, the SIP entity can
edge proxy, it can send keep-alives at its discretion. [RFC5626] send keep-alives at its discretion. [RFC5626] provides additional
provides additional guidance on selecting the keep-alive frequency in guidance on selecting the keep-alive frequency in case a recommended
case a Flow-Timer header field is not received. keep-alive frequency is not provided.
OPEN ISSUE: It has been suggested that, instead of using the Flow- A SIP entity that uses the "keep" parameter to indicate willingness
Timer header field in order to provide the recommented keep-alive to receive keep-alives MUST NOT use the Flow-Timer header field in
frequency value, the value would be added as a parameter to the order to provide a recommended keep-alive frequency.
"keep" parameter, instead of the "yes" value.
SIP Outbound uses the Flow-Timer header field to indicate the server-
recommended keep-alive frequency. However, it will only be sent
between a UA and an edge proxy. Using the "keep" parameter, however,
the sending and receiving of keep-alives might be negotiated between
multiple entities on the signalling path. Since the server-
recommended keep-alive frequency might vary between different SIP
entities, those would have to re-write the Flow-Timer header field
value. In addition, if a SIP entity does not indicate willingness to
receive keep-alives from its adjacent downstream SIP entity, and
receives a Flow-Timer header field in a response, it would have to
remove the Flow-Timer header field from the response. This issue
does not exist for the "keep" parameter, as each SIP entity has its
own individual Via header field.
6. Overlap with connection reuse 6. Overlap with connection reuse
The connect-reuse specification [I-D.ietf-sip-connect-reuse] The connect-reuse specification [I-D.ietf-sip-connect-reuse]
specifies how to use connection-oriented transports to send requests specifies how to use connection-oriented transports to send requests
in the reverse direction. SIP entity A opens a connection to entity 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 B in order to send a request. Under certain conditions entity B can
reuse that connection for sending requests in the backwards direction reuse that connection for sending requests in the backwards direction
to A as well. However, the connect-reuse specification does not to A as well. However, the connect-reuse specification does not
define a keep-alive mechanism for this connection. define a keep-alive mechanism for this connection.
The mechanism specified in this draft is thus orthogonal to the The mechanism specified in this draft is thus orthogonal to the
purpose of connection reuse. An entity that wants to use connection- purpose of connection reuse. An entity that wants to use connection-
reuse as well as indicate keep-alive mechanism on that connection reuse as well as indicate keep-alive mechanism on that connection
will insert both the "alias" parameter defined in [connect-reuse] as will insert both the "alias" parameter defined in [connect-reuse] as
well as the "keep" parameter defined in this memo. Inserting only well as the "keep" parameter defined in this memo. Inserting only
one of these parameters is not a substitute for the other. Thus, one of these parameters is not a substitute for the other. Thus,
while the presence of a "keep" parameter will indicate that the enity while the presence of a "keep" parameter will indicate that the
supports keep-alives in order to keep the connection open, no entity supports keep-alives in order to keep the connection open, no
inference can be drawn on whether that connection can be used for inference can be drawn on whether that connection can be used for
requests in the backwards direction. requests in the backwards direction.
7. Examples 7. Examples
7.1. General 7.1. General
This section shows example flows where the usage of keep-alives is This section shows example flows where usage of keep-alives,
negotiated between different SIP entities, within a registration or associated with a registration and a dialog, is negotiated between
within a dialog. different SIP entities.
7.2. Keep-alive negotiation: UA-proxy within registration 7.2. Keep-alive negotiation associated with registration: UA-proxy
The figure shows an example where Alice sends an REGISTER request. The figure shows an example where Alice sends an REGISTER request.
She indicates willingness of sending keep-alive by inserting a "keep" She indicates willingness of sending keep-alive by inserting a "keep"
parameter in her Via header field of the request. The edge proxy parameter in her Via header field of the request. The edge proxy
(P1) supports the keep-alive mechanism, and is willing to receive (P1) forwards the request towards the registrar.
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 forwards the request towards the registrar.
When P1 receives the associated response, it inserts a Flow-Timer P1 is willing to receive keep-alives from Alice for the duration of
header field, with a recommended keep-alive frequency interval of 30 the registration, so When P1 receives the associated response it adds
seconds, in the response, before it forwards the response towards a keep parameter value, which indicates a recommended keep-alive
Alice. frequency of 30 seconds, to Alice's Via header field, before it
forwards the response towards Alice.
When Alice receives the response, she determines from her Via header When Alice receives the response, she determines from her Via header
field that P1 is willing to receive keep-alives within the field that P1 is willing to receive keep-alives associated with the
registration. For the duration of the registration, the UAC then registration. For the lifetime of the registration, Alice then sends
sends periodic keep-alives (in this example using the STUN keep-alive periodic keep-alives (in this example using the STUN keep-alive
technique) towards P1, using the recommended keep-alive frequency technique) towards P1, using the recommended keep-alive frequency
indicated in the Flow-Timer header field of the response. indicated by the keep parameter value.
Alice P1 REGISTRAR Alice P1 REGISTRAR
| | | | | |
|--- REGISTER------------->| | |--- REGISTER------------->| |
| Via: UAC;keep | | | Via: Alice;keep | |
| |--- REGISTER-------------->| | |--- REGISTER-------------->|
| | Via: P1 | | | Via: P1 |
| | Via: UAC;keep=yes | | | Via: Alice;keep |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 | | | Via: P1 |
| | Via: UAC;keep=yes | | | Via: Alice;keep |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: UAC;keep=yes | | | Via: Alice;keep=30 | |
| Flow-Timer: 30 | |
| | | | | |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
Figure 1: Example call flow Figure 1: Example call flow
7.3. Keep-alive negotiation: UA-proxy within dialog 7.3. Keep-alive negotiation associated with dialog: UA-proxy
The figure shows an example where Alice sends an initial INVITE The figure shows an example where Alice sends an initial INVITE
request for a dialog. She indicates willingness to send keep-alive request for a dialog. She indicates willingness to send keep-alive
by inserting a "keep" parameter in her Via header field of the 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 request. The edge proxy (P1) adds itself to the dialog route set by
adding itself to a Record-Route header field. P1 also supports the adding itself to a Record-Route header field, before it forwards the
keep-alive mechanism, and is willing to receive keep-alives from
Alice during the dialog, so it adds a "yes" value to the "keep"
parameter in the Via header field of Alice, before it forwards the
request towards Bob. request towards Bob.
When P1 receives the associated response, it inserts a Flow-Timer P1 is willing to receive keep-alives from Alice for the duration of
header field, with a recommended keep-alive frequency interval of 30 the dialog, so When P1 receives the associated response it adds a
seconds, in the response, before it forwards the response towards keep parameter value, which indicates a recommended keep-alive
Alice. frequency of 30 seconds, to Alice's Via header field, before it
forwards the response towards Alice.
When Alice receives the response, she determines from its Via header When Alice receives the response, she determines from her Via header
field that P1 is willing to receive keep-alives within the dialog. field that P1 is willing to receive keep-alives associated with the
For the duration of the dialog, she then sends periodic keep-alives dialog. For the lifetime of the dialog, Alice then sends periodic
(in this example using the STUN keep-alive technique) towards P1, keep-alives (in this example using the STUN keep-alive technique)
using the recommended keep-alive frequency indicated in the Flow- towards P1, using the recommended keep-alive frequency indicated by
Timer header field of the response. the keep parameter value.
Alice P1 Bob Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Via: UAC;keep | | | Via: Alice;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: UAC;keep=yes | | | Via: Alice;keep |
| | Record-Route: P1 | | | Record-Route: P1 |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 | | | Via: P1 |
| | Via: UAC;keep=yes | | | Via: Alice;keep |
| | Record-Route: P1 | | | Record-Route: P1 |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: UAC;keep=yes | | | Alice: UAC;keep=30 | |
| Flow-Timer: 30 | |
| Record-Route: P1 | | | Record-Route: P1 | |
| | | | | |
|--- ACK ----------------->| | |--- ACK ----------------->| |
| | | | | |
| |--- ACK ------------------>| | |--- ACK ------------------>|
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
skipping to change at page 12, line 5 skipping to change at page 12, line 5
| | | | | |
|--- BYE ----------------->| | |--- BYE ----------------->| |
| | | | | |
| |--- BYE ------------------>| | |--- BYE ------------------>|
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | | | | |
Figure 2: Example call flow Figure 2: Example call flow
7.4. Keep-alive negotiation: UA-UA within dialog 7.4. Keep-alive negotiation associated with dialog: UA-UA
The figure shows an example where Alice sends an initial INVITE The figure shows an example where Alice sends an initial INVITE
request for a dialog. She indicates willingness to send keep-alive request for a dialog. She indicates willingness to send keep-alive
by inserting a "keep" parameter in her Via header field of the 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 request. The edge proxy (P1) does not add itself to the dialog route
set by adding itself to a Record-Route header field, and it does not set, by adding itself to a Record-Route header field, before it
indicate willingness to receive keep-alives from Alice. forwards the request towards Bob. .
When Alice receives the response, she determines from her Via header When Alice receives the response, she determines from her Via header
field that P1 is not willing to receive keep-alives from her. When field that P1 is not willing to receive keep-alives associated with
the dialog route set has been established, Alice sends a mid-dialog the dialog from her. When the dialog route set has been established,
UPDATE request towards Bob (since P1 did not insert itself in the Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not
dialog route set), and she once again indicates willingness to send insert itself in the dialog route set), and she once again indicates
keep-alives by inserting a "keep" parameter in her Via header field willingness to send keep-alives by inserting a "keep" parameter in
of the request. Bob supports the keep-alive mechanism, and is her Via header field of the request. Bob supports the keep-alive
willing to receive keep-alives from Alice during the dialog, so he mechanism, and is willing to receive keep-alives associated with the
adds a "yes" value to the "keep" parameter in the Via header field of dialog from Alice, so he creates a response and adds a keep parameter
Alice, before he creates and sends a response towards her. Bob also value, which indicates a recommended keep-alive frequency of 30
inserts a Flow-Timer header field in the response, with a recommended seconds, to Alice's Via header field, before he forwards the response
keep-alive frequency interval of 30 seconds. towards Alice.
When Alice receives the response, she determines from her Via header When Alice receives the response, she determines from her Via header
field that Bob is willing to receive keep-alives from her within the field that P1 is willing to receive keep-alives associated with the
dialog. For the duration of the dialog, Alice then sends periodic dialog. For the lifetime of the dialog, Alice then sends periodic
keep-alives (in this example using the STUN keep-alive technique) keep-alives (in this example using the STUN keep-alive technique)
towards Bob, using the recommended keep-alive frequency indicated in towards Bob, using the recommended keep-alive frequency indicated by
the Flow-Timer header field of the response. the keep parameter value.
Alice P1 Bob Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Via: UAC;keep | | | Via: Alice;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: UAC:keep | | | Via: Alice:keep |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 | | | Via: P1 |
| | Via: UAC;keep | | | Via: Alice;keep |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: UAC;keep | | | Via: Alice;keep | |
| | | | | |
| | | |
|--- ACK --------------------------------------------->| |--- ACK --------------------------------------------->|
| | | |
|--- UPDATE ------------------------------------------>| |--- UPDATE ------------------------------------------>|
| Via: UAC;keep | | Via: Alice;keep |
| | | |
|<-- 200 OK ------------------------------------------>| |<-- 200 OK ------------------------------------------>|
| Via: UAC;keep=yes | | Via: UAC;keep=30 |
| Flow-Timer: 30 |
| | | |
| | | |
| *** Timeout *** | | *** Timeout *** |
| | | |
|=== STUN request ====================================>| |=== STUN request ====================================>|
|<== STUN response ====================================| |<== STUN response ====================================|
| | | |
| *** Timeout *** | | *** Timeout *** |
| | | |
|=== STUN request ====================================>| |=== STUN request ====================================>|
skipping to change at page 14, line 9 skipping to change at page 14, line 9
8. Grammar 8. Grammar
This specification defines a new Via header field parameter, "keep". This specification defines a new Via header field parameter, "keep".
The grammar includes the definitions from [RFC5626]. The grammar includes the definitions from [RFC5626].
The ABNF [RFC5234] is: The ABNF [RFC5234] is:
via-params =/ keep via-params =/ keep
keep = "keep" [ EQUAL "yes" ] keep = "keep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations 9. IANA Considerations
9.1. keep 9.1. keep
This specification defines a new Via header field parameter called This specification defines a new Via header field parameter called
keep in the "Header Field Parameters and Parameter Values" sub- keep in the "Header Field Parameters and Parameter Values" sub-
registry as per the registry created by [RFC5626]. The syntax is registry as per the registry created by [RFC5626]. The syntax is
defined in Section 8. The required information is: defined in Section 8. The required information is:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- --------- ---------------------- --------------------- ---------- ---------
Via keep No [RFCXXXX] Via keep No [RFCXXXX]
10. Security Considerations 10. Security Considerations
This specification does not introduce security consideritions in This specification does not introduce security considerations in
additions to those specified in [RFC5626]. addition to those specified in [RFC5626].
11. Acknowledgements 11. Acknowledgements
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer
and Milo Orsic for their comments on the initial draft. Thanks to and Milo Orsic for their comments on the initial draft. Thanks to
Juha Heinaenen, Jiri Kuthan, Dean Willis and John Elwell for their Juha Heinaenen, Jiri Kuthan, Dean Willis and John Elwell for their
comments on the list. Thanks to Vijay Gurbani for providing text comments on the list. Thanks to Vijay Gurbani for providing text
about the relationship with the connect-reuse specification. about the relationship with the connect-reuse specification.
12. References 12. References
 End of changes. 75 change blocks. 
235 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/