draft-ietf-sipcore-keep-02.txt   draft-ietf-sipcore-keep-03.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track April 15, 2010 Intended status: Informational May 24, 2010
Expires: October 17, 2010 Expires: November 25, 2010
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-02.txt draft-ietf-sipcore-keep-03.txt
Abstract Abstract
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
header field parameter, "keep", that SIP entities can use to Via header field parameter, "keep", which allows adjacent SIP
negotiate explicit support of the NAT keep-alive mechanisms defined entities to explicitly negotiate usage of the Network Address
in the SIP Outbound specification. The parameter is defined for Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in
cases where the SIP Outbound mechanism is not supported, or in cases cases where SIP Outbound is not supported, cannot be applied, or
where it cannot be applied. where usage of keep-alives are not implicitly negotiated as part of
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 October 17, 2010. This Internet-Draft will expire on November 25, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use-case: Calls 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
1.4. Use-case: Proxy-to-proxy heartbeat . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User agent behavior . . . . . . . . . . . . . . . . . . . . . 4 4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. User agent client behavior . . . . . . . . . . . . . . . . 5 4.2. Scope and duration of keep-alives . . . . . . . . . . . . 5
4.2.1. Keep-alive negotiation for registration . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 5 4.2.2. Keep-alives within registration . . . . . . . . . . . 5
4.3. User agent server behavior . . . . . . . . . . . . . . . . 6 4.2.3. Keep-alives within dialog . . . . . . . . . . . . . . 6
4.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 6 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6
4.4. Keep-alive frequency . . . . . . . . . . . . . . . . . . . 6 4.4. Behavior of a SIP entity willing to receive keep-alives . 7
5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Edge proxy behavior . . . . . . . . . . . . . . . . . . . 7
5.2.1. Keep-alive negotiation for registration . . . . . . . 7
5.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 7
5.3. Proxy behavior for proxy-to-proxy heartbeats . . . . . . . 7
5.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 7
6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Example: Keep-alive negotiation for registration . . . . . 9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Example: Keep-alive negotiation for dialog from UA . . . . 10 7.2. Keep-alive negotiation: UA-proxy within registration . . . 9
7.3. Example: Keep-alive negotiation for dialog to UA . . . . . 11 7.3. Keep-alive negotiation: UA-proxy within dialog . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.4. Keep-alive negotiation: UA-UA within dialog . . . . . . . 12
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. IANA Registration of the SIP header field keep 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
parameter . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 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, it is currently not possible
to explicitly negotiate the usage of keep-alives, since the keep- to explicitly negotiate usage of the keep-alive mechanisms, since
alives are implicitly negotiated as part of the SIP Outbound usage of keep-alives in most cases are implicitly negotiated as part
negotation. of the SIP Outbound negotiation.
However, there are also SIP Outbound use-cases where the keep-alives However, there are SIP Outbound use-cases where the usage of keep-
are not implicitly negotiated as part of the SIP Outbound alives are not implicitly negotiated as part of the SIP Outbound
negotiation, and therefor an explicit keep-alive negotiation negotiation. In addition, there are cases where SIP Outbound is not
mechanism is needed. In addition, there are use-cases where SIP supported, where it cannot be applied, but where there is still a
Outbound is not supported, or where it cannot be applied, but where need to be able to negotiate usage of keep-alives. For those cases,
there is still a need to be able to negotiate the usage of keep- a mechanism to explicitly negotiate the usage of keep-alives is
alives. needed.
This specification defines a new SIP header field parameter, "keep", This specification defines a new Session Initiation Protocol (SIP)
that SIP entities can use to negotiate support of the NAT keep-alive [RFC3261] Via header field parameter, "keep", which allows adjacent
mechanisms defined in the SIP Outbound specification [RFC5626]. The SIP entities can use to explicitly negotiate the usage of the NAT
parameter is defined for cases where the SIP Outbound mechanism is keep-alive mechanisms defined in SIP Outbound. The "keep" parameter
not supported, or in cases where it cannot be applied. The usage of allows SIP entities to indicate willingness to send keep-alives, and
keep-alives can be negotiated as part of a registration, or as part it allows SIP entities to indciate willingness to receive keep-
of a dialog. alives.
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 the usage of keep-alives is needed.
1.1. Use-case: Calls from non-registered UAs 1.1. Use-case: Session from non-registered UAs
In some cases a UA does not register itself before making a call, but In some cases a User Agent Client (UAC) does not register itself
still needs to be able to make calls and send keep-alives in order to before it establishes a session, but where it still needs to be able
maintain NAT bindings open during the duration of the call. A to establish a session and send keep-alives in order to maintain NAT
typical example is emergency calls. bindings open during the duration of the call. A typical example is
an emergency calls, where a registration is not always required.
1.2. Use-case: SIP Outbound not supported 1.2. Use-case: SIP Outbound not supported
There are cases where the SIP entities that need to be able to In some cases all SIP entities that need to be able to negotiate the
negotiate the usage of keep-alives do not support the SIP Outbound usage of keep-alives do not support SIP Outbound. However, they
mechanism 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 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 initial SIP
dialog requests. As specified in [RFC5626], keep-alives are not dialog requests. As specified in [RFC5626], the usage keep-alives
implicitly negotiated for such flows, and therefor need to be are not implicitly negotiated for such flows. Therefor there is a
separately negotiated. need to be able to explicitly negotiate the usage of the keep-alives.
1.4. Use-case: Proxy-to-proxy heartbeat
There are cases where SIP proxies need to perform heartbeats between
themselves. Eventhough the heartbeats are normally not used for NAT
traversal purpose, the keep-alive mechanisms defined in [RFC5626] can
still be used to perform the heartbeats.
2. Conventions 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
Edge proxy: As defined in [RFC5626], a SIP proxy that is located Edge proxy: As defined in [RFC5626], a SIP proxy that is located
topologically between the registering User Agent (UA) and the topologically between the registering User Agent (UA) and the
Authoritative Proxy. Authoritative Proxy.
Keep-alives: Refers to keep-alive messages using the mechanisms NOTE: In some deployments the edge proxy might physically be located
define defined in the SIP Outbound specification [RFC5626]. in the same entity as the Authoritative Proxy.
"keep" parameter: A SIP header field parameter that a SIP entity can
insert to explicitly indicate that it supports the keep-alive
mechanisms defined in the SIP Outbound specification [RFC5626]. The
parameter is defined for the SIP Contact, Path and Record-Route
header fields.
4. User agent behavior
4.1. General
This section describes how a UA (User Agent) negotiates the usage of Keep-alives: Refers to keep-alive messages as defined in SIP Outbound
keep-alives between itself and its edge proxy, for a registration or [RFC5626].
a dialog.
A UA will only send keep-alives towards its edge proxy, and MUST NOT "keep" parameter: A SIP Via header field parameter that a SIP entity
expect to receive edge proxy initiated keep-alives. can insert in its Via header field of a request to explicitly
indicate willingness to send keep-alives. A SIP entity can add a
"yes" parameter value to a "keep" parameter in the top-most Via
header field of a recieved SIP request, to indicate willingness to
receive keep-alives from the adjacent downstream SIP entity
(associated with the top-most Via header field of the received
request) from which it received the request.
A UA that supports keep-alives MUST insert a "keep" parameter in its SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261].
Contact header field even if it also indicates support of SIP
Outbound [RFC5626], in order to be able to negotiate the usage of
keep-alives also in cases where the edge proxy only supports keep-
alives, but not the other parts of SIP Outbound.
As defined in [RFC5626], a UA that supports keep-alives MUST act as a 4. User Agent and Proxy behavior
Session Traversal Utilities for NAT (STUN) client [RFC5389]. The UA
MUST support the amount of STUN which is required to apply the STUN
keep-alive mechanism defined in [RFC5626], and the UA MUST support
the CRLF keep-alive mechanism defined in [RFC5626]. In addition, as
defined in [RFC5389], the UAC MUST be able to process the SIP Path
header [RFC3327], in order to detect whether the edge proxy supports
keep-alives.
NOTE: Keep-alives needs to be negotiated when a registration or 4.1. General
dialog is initiated. It is not possible to negotiate/re-negotiate
the usage keep-alives later during the registration or dialog, and
the usage of the "keep" parameter in re-registration requests and
dialog modification requsts is not specified.
NOTE: Since there are UAs that already use CRLF keep-alives, and This section describes of SIP UAs and proxies negotiate the sending
proxies are expected to be able to receive it, this specification or receiving of keep-alives within a registration and within a
does not forbid the sending of CRLF keep-alives even an edge proxy dialog. It also describes which types of SIP requests and responses
has not indicated support of keep-alives using the "keep" parameter. can be used in order to negotiate the sending and receiving of keep-
However, the "keep" parameter is still important in order for the UA alives, and the lifetime of the negotiated keep-alives.
to inform the edge proxy that the UA supports CRLF keep-alives, so
that the edge proxy does not use other mechanisms (e.g. short
registration refresh intervals) in order to make sure the NAT
bindings are kept open.
4.2. User agent client behavior SIP requests are used by SIP entities to indicate willingness to send
keep-alives towards the adjacent upstream SIP entity. The associated
responses are used by SIP entities to indicate willingness to receive
keep-alives. The procedures to indicate willingness to send and
received keep-alives are identical for UAs and proxies.
4.2.1. Keep-alive negotiation for registration NOTE: Since there are SIP entities that already use CRLF keep-alives,
and SIP entities are expected to be able to receive those, this
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.
When a UAC sends a REGISTER request for a new registration, if the 4.2. Scope and duration of keep-alives
UAC is willing to send keep-alives associated with the registration,
it MUST insert a "keep" parameter in its Contact header field of the
REGISTER request.
When the UAC receives the REGISTER response, if the top-most Path 4.2.1. General
header field (edge proxy) of the response contains a "keep"
parameter, the UAC MUST start to send keep-alives towards the edge
proxy, and it MUST send keep-alives for the remaining duration of the
registration. When the registration is terminated, the UAC MUST
cease the sending of keep-alives negotiated for the registration.
4.2.2. Keep-alive negotiation for dialog The sending and receving of keep-alives can be negotiated within a
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.
When a UAC sends an initial request (e.g. a SIP INVITE request) for a The sending and receiving of keep-alives can be negotiated when a
dialog, if the UAC is willing to send keep-alives associated with the registration or dialog is initiated, or later during the registration
dialog, it MUST insert a "keep" parameter in its Contact header field or dialog. However, once a SIP entity has negotiated the sending of
of the request. 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.
When the UAC receives the response(s) to the initial request for the A SIP entity that has indicated willingess to receive keep-alives
dialog, if the top-most Record-Route header field (edge proxy) of within a dialog can still, in a subsequent request within the dialog,
response(s) contains a "keep" parameter, the UAC MUST start to send indicate willingness to send keep-alives within the same dialog.
keep-alives towards the edge proxy for the remaining duration of the Likewise, a SIP entity that has negotiated the sending of keep-alives
dialog. When the dialog is terminated, the UAC MUST cease the within a dialog can in a response to a subsequent request indicate
sending of keep-alives negotiated for the dialog. willingness to receive keep-alives within the same dialog.
4.3. User agent server behavior 4.2.2. Keep-alives within registration
4.3.1. Keep-alive negotiation for dialog SIP entities use the REGISTER method in order to negotiate the
sending and reciving of keep-alives within a registration. The keep-
alives can be negotiated when the registration is established, or
later within the registration. Once negotiated, the keep-alives are
sent during the lifetime of the registration, until it is terminated.
When a UAS receives an initial request for a dialog, if the top-most In case a SIP entity establishes multiple registration flows
Record-Route header filed contains a "keep" parameter, and if the UAS
is willing to send keep-alives associated with the dialog, it MUST
insert a "keep" parameter in its Contact header field in the
response(s) to the request. After that the UAS MUST start to send
keep-alives towards the edge proxy, and it MUST send keep-alives for
the remaining duration of the registration.
4.4. Keep-alive frequency [RFC5626], the sending and receiving of keep-alives is done
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.
If the SIP message that contains the "keep" parameter of the edge 4.2.3. Keep-alives within dialog
proxy also contains a Flow-Timer header field [RFC5626], it is
strongly RECOMMENDED that the UA uses the server recommended keep-
alive frequency value, provided in the header field, and sends keep-
alives so that the interval between each keep-alive is randomly
distributed between 80% and 100% of the provided value.
If the UA does not receive a Flow-Timer header field from the edge SIP entities use a initial request for a dialog, or a mid-dialog
proxy, it can send keep-alives at its discretion. 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.
5. Proxy behavior Since an ACK request does not have an associated response, it can not
be used to 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 the parameter.
5.1. General 4.3. Behavior of a SIP entity willing to send keep-alives
A proxy that supports the mechanism specified in this specification As defined in [RFC5626], a SIP entity that supports the sending of
MUST act as a STUN server [RFC5389], and MUST support the amount of keep-alives must act as a Session Traversal Utilities for NAT (STUN)
STUN which is required to apply the STUN keep-alive technique client [RFC5389]. The SIP entity must support the amount of STUN
[RFC5626]. The edge proxy MUST also process double-CRLF keep-alives, which is required to apply the STUN keep-alive mechanism defined in
as defined in [RFC5626]. [RFC5626], and it must support the CRLF keep-alive mechanism defined
in [RFC5626].
If a proxy also generates keep-alives (see proxy-to-proxy case), it When a SIP entity sends or forwards a request, if it wants to
MUST also act as a STUN client [RFC5389]. negotiate the sending of keep-alives within the registration (in case
of a REGISTER request) or 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 dialog, it MUST insert a "keep" parameter in its Via
header field of the request.
5.2. Edge proxy behavior When the SIP entity receives the associated response, if the "keep"
parameter in its Via header field in 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 (if the keep-
alive negotiation is for a dialog). Subsequent mid-dialog requests
are addressed based on the dialog route set.
5.2.1. Keep-alive negotiation for registration If the response contains a Flow-Timer header field, the SIP entity
MUST remove the header field before it forwards the response towards
another SIP entity.
When an edge proxy receives an initial REGISTER request for a When a SIP entity is about to send a keep-alive, if the SIP entity at
registration from a UA behind the edge proxy, the Contact header the same time is also about to send or forward a SIP request within
field of the request contains a "keep" parameter, and if the edge the same registration or dialog, for which the keep-alive is to be
proxy is willing to receive keep-alives from the UA for the sent, the SIP entity MAY choose not to send the keep-alive, as the
associated registration, the edge proxy MUST insert a "keep" SIP request will perform the same keep-alive action.
parameter in its Path header field of the associated REGISTER
response. In addition, the edge proxy MAY insert a Flow-Timer header
field [RFC5626], which indicates the recommended keep-alive frequency
for the registration.
5.2.2. Keep-alive negotiation for dialog 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, 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 insert a "keep" parameter in its
Via header field of a subsequent request within the dialog, in case
the new adjacent SIP entity is willing to receive keep-alives (in
which case it will add a "yes" parameter value to the "keep"
parameter).
When an edge proxy receives a dialog initiation request from a UAC NOTE: If a SIP entity inserts a "keep" parameter in its Via header
behind the edge proxy, the Contact header field of the request field of an INVITE request, and it receives multiple responses
contains a "keep" parameter, and if the edge proxy is willing to (provisional or final) associated with the request, as long as at
receive keep-alives from the UA for the associated dialog, the edge least one of the responses, for a specific dialog, contains a "keep"
proxy MUST insert a "keep" parameter in its Record-Route header field parameter with a "yes" value it is seen as an indication that the
of the associated response(s). In addition, the edge proxy MAY adjacent upstream SIP entity is willing to receive keep-alives within
insert a Flow-Timer header field [RFC5626], which indicates the the dialog.
recommended keep-alive frequency for the dialog.
When an edge proxy receives an inbound dialog initiation request 4.4. Behavior of a SIP entity willing to receive keep-alives
towards a UAS behind the edge proxy, and if the edge proxy is willing
to receive keep-alives from the UA for the associated dialog, the
edge proxy MUST insert a "keep" parameter in its Record-Route header
field of the request. In addition, the edge proxy MAY insert a Flow-
Timer header field [RFC5626], which indicates the recommended keep-
alive frequency for the dialog. When the edge proxy receives
response(s) associated with the request from the UAS, associated with
the request, if the Contact header field of the response(s) contains
a "keep" parameter, the edge proxy can assume that the UAS will send
keep-alives associated with the dialog.
5.3. Proxy behavior for proxy-to-proxy heartbeats 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].
5.3.1. Keep-alive negotiation for dialog When a SIP entity receives request that can be used in order to
negotiate the sending and receiveing of keep-alives, the top-most Via
header field of the request contains a "keep" parameter, and the SIP
entity has not previously indicated willingess to receive keep-alives
from the adjacent downstream SIP entity within the registration (in
case of a REGISTER request) or dialog (in case of a initial request
for a dialog, or 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, before forwarding the
request or creating a response. In addition, the SIP entity MAY
insert a Flow-Timer header field [RFC5626] in the associated
response, which indicates the recommended keep-alive frequency for
the registration or dialog.
When a proxy receives a dialog initiation request from its previous- 5. Keep-alive frequency
hop proxy, and the top-most Record-Route header field of the request
contains a "keep" parameter, if the proxy is willing to send and
receive keep-alives from the previous-hop proxy for the associated
dialog, the proxy MUST insert a "keep" parameter in its Record-Route
header field of the associated response(s) sent towards the previous-
hop proxy. After that the proxy MUST send keep-alives, and accept
keep-alives sent from the previous-hop proxy, for the duration of the
dialog.
When a proxy forwards a dialog initiation request towards its next- If a SIP entity receives a SIP response, where its Via header field
hop proxy, and it wants to negotiate the usage of keep-alives with contains a "keep" parameter with a "yes" value, also contains a Flow-
that next-hop proxy, it MUST include a "keep" parameter in its Timer header field [RFC5626], according to [RFC5626] the SIP entity
Record-Record header field of the request. When the proxy receives MUST send keep-alives at least as often as this number of seconds,
the associated response(s), if the Record-Route header field that and if the SIP entity uses the server-recommended keep-alive
represents the next-hop proxy contains a "keep" parameter, the proxy frequency it should send its keep-alives so that the interval between
MUST start sending keep-alives towards the next-hop proxy for the each keep-alive israndomly distributed between 80% and 100% of the
duration of the dialog. server-provided time.
NOTE: The usage of the Flow-Timer header field for proxy-to-proxy If the SIP entity does not receive a Flow-Timer header field from the
heartbeats is unspecified. 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 is not received.
OPEN ISSUE: It still needs to be discuss whether it should be OPEN ISSUE: It has been suggested that, instead of using the Flow-
possible to negotiate that the sending of keep-alives between proxies Timer header field in order to provide the recommented keep-alive
continue after the dialog, for which the keep-alives were negotiated, frequency value, the value would be added as a parameter to the
has been terminated. "keep" parameter, instead of the "yes" value.
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 technique 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 will insert both the "alias" parameter defined in [connect-reuse] as
[I-D.ietf-sip-connect-reuse] as well as the "keep" header field well as the "keep" parameter defined in this memo. Inserting only
parameter defined in this specification. Inserting only one of these one of these parameters is not a substitute for the other. Thus,
parameters is not a substitute for the other. Thus, while the while the presence of a "keep" parameter will indicate that the enity
presence of a "keep" parameter will indicate that the enity supports supports keep-alives in order to keep the connection open, no
keep-alives in order to keep the connection open, no inference can be inference can be drawn on whether that connection can be used for
drawn on whether that connection can be used for requests in the requests in the backwards direction.
backwards direction.
7. Examples 7. Examples
7.1. Example: Keep-alive negotiation for registration
The figure shows an example where the UAC sends a REGISTER request. 7.1. General
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 This section shows example flows where the usage of keep-alives is
inserts a "keep" parameter in its Path header field of the REGISTER negotiated between different SIP entities, within a registration or
response that it forwards towards the UAC. In addition, the edge within a dialog.
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 7.2. Keep-alive negotiation: UA-proxy within registration
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 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 forwards the request towards the registrar.
When P1 receives the associated response, it inserts a Flow-Timer
header field, with a recommended keep-alive frequency interval of 30
seconds, in the response, 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 the
registration. For the duration of the registration, the UAC 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 the response.
Alice P1 REGISTRAR
| | | | | |
|--- REGISTER------------->| | |--- REGISTER------------->| |
| Contact: UAC;keep | | | Via: UAC;keep | |
| |--- REGISTER-------------->| | |--- REGISTER-------------->|
| | Path: P1 | | | Via: P1 |
| | Contact: UAC;keep | | | Via: UAC;keep=yes |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Path: P1 | | | Via: P1 |
| | Contact: UAC;keep | | | Via: UAC;keep=yes |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Path: P1;keep | | | Via: UAC;keep=yes | |
| Contact: UAC;keep | |
| Flow-Timer: 30 | | | Flow-Timer: 30 | |
| | | | | |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
skipping to change at page 10, line 4 skipping to change at page 10, line 31
| *** 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.2. Example: Keep-alive negotiation for dialog from UA 7.3. Keep-alive negotiation: UA-proxy within dialog
The figure shows an example where the UAC sends an INVITE request. The figure shows an example where Alice sends an initial INVITE
The UAC inserts a "keep" parameter in its Contact header field, to request for a dialog. She indicates willingness to send keep-alive
indicate that it is willing to send keep-alives during the lifetime by inserting a "keep" parameter in her Via header field of the
of the dialog. 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
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.
The edge proxy (P1) supports the receiving of keep-alives, so it When P1 receives the associated response, it inserts a Flow-Timer
inserts a "keep" parameter in its Record-Route header field of the header field, with a recommended keep-alive frequency interval of 30
INVITE response that it forwards towards the UAC. In addition, the seconds, in the response, before it forwards the response towards
edge proxy inserts a Flow-Timer header field in the response. The Alice.
header field value indicates the server recommended keep-alive
frequency.
When the UAC receives the INVITE response, and detects that the edge When Alice receives the response, she determines from its Via header
proxy supports the receiving of keep-alives, it starts to send field that P1 is willing to receive keep-alives within the dialog.
periodic keep-alives (in this example using the STUN keep-alive For the duration of the dialog, she then sends periodic keep-alives
technique) (in this example using the STUN keep-alive technique) towards P1,
UAC P1 (Edge Proxy) Remote SIP network using the recommended keep-alive frequency indicated in the Flow-
Timer header field of the response.
Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Contact: UAC;keep | | | Via: UAC;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: P1 |
| | Via: UAC;keep=yes |
| | Record-Route: P1 | | | Record-Route: P1 |
| | Contact: UAC;keep |
| | |
| | |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: UAC;keep=yes |
| | Record-Route: P1 | | | Record-Route: P1 |
| | Contact: UAS |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Record-Route: P1;keep | | | Via: UAC;keep=yes | |
| Contact: UAS | |
| Flow-Timer: 30 | | | Flow-Timer: 30 | |
| Record-Route: P1 | |
| | | | | |
|--- ACK ----------------->| | |--- ACK ----------------->| |
| | | | | |
| |--- ACK ------------------>| | |--- ACK ------------------>|
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
skipping to change at page 11, line 46 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.3. Example: Keep-alive negotiation for dialog to UA 7.4. Keep-alive negotiation: UA-UA within dialog
The figure shows an example where P1 (edge proxy) forwards an INVITE The figure shows an example where Alice sends an initial INVITE
request towards the UAS. P1 inserts a "keep" parameter in its request for a dialog. She indicates willingness to send keep-alive
Record-Route header field, to indicate that it is willing to receive by inserting a "keep" parameter in her Via header field of the
keep-alives during the lifetime of the dialog. In addition, the edge request. The edge proxy (P1) does not add itself to the dialog route
proxy inserts a Flow-Timer header field in the response. The header set by adding itself to a Record-Route header field, and it does not
field value indicates the server recommended keep-alive frequency. indicate willingness to receive keep-alives from Alice.
The UAS is willing to send keep-alives, so it inserts a "keep" When Alice receives the response, she determines from her Via header
parameter in its Contact header field of the INVITE 200 (OK) field that P1 is not willing to receive keep-alives from her. When
response. In addition, the edge proxy inserts a Flow-Timer header the dialog route set has been established, Alice sends a mid-dialog
field in the response. The header field value indicates the server UPDATE request towards Bob (since P1 did not insert itself in the
recommended keep-alive frequency. After that the UAS starts to send dialog route set), and she once again indicates willingness to send
periodic keep-alives (in this example using the STUN keep-alive keep-alives by inserting a "keep" parameter in her Via header field
technique) of the request. Bob supports the keep-alive mechanism, and is
Remote SIP network P1 (Edge Proxy) UAS willing to receive keep-alives from Alice during the dialog, so he
adds a "yes" value to the "keep" parameter in the Via header field of
Alice, before he creates and sends a response towards her. Bob also
inserts a Flow-Timer header field in the response, with a recommended
keep-alive frequency interval of 30 seconds.
When Alice receives the response, she determines from her Via header
field that Bob is willing to receive keep-alives from her within the
dialog. For the duration 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 the response.
Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Contact: UAC | | | Via: UAC;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Record-Route: P1;keep | | | Via: P1 |
| | Contact: UAC | | | Via: UAC:keep |
| | Flow-Timer: 30 |
| | |
| | |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Record-Route: P1;keep | | | Via: P1 |
| | Contact: UAS;keep | | | Via: UAC;keep |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Record-Route: P1;keep | | | Via: UAC;keep | |
| Contact: UAS;keep | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | | | | |
| |
|--- ACK --------------------------------------------->|
| |
|--- UPDATE ------------------------------------------>|
| Via: UAC;keep |
| |
|<-- 200 OK ------------------------------------------>|
| Via: UAC;keep=yes |
| Flow-Timer: 30 |
| |
| |
| *** Timeout *** | | *** Timeout *** |
| | | | |
| |<== STUN request ==========| |=== STUN request ====================================>|
| |=== STUN response ========>| |<== STUN response ====================================|
| | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | |
| |<== STUN request ==========| |=== STUN request ====================================>|
| |=== STUN response ========>| |<== STUN response ====================================|
| | | | |
|--- BYE ----------------->| | | |
| | | |--- BYE --------------------------------------------->|
| |--- BYE ------------------>| | |
| | | |<-- 200 OK -------------------------------------------|
| |<-- 200 OK ----------------| | |
| | |
Figure 3: Example call flow Figure 3: Example call flow
8. Security Considerations 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" ]
9. IANA Considerations 9. IANA Considerations
9.1. IANA Registration of the SIP header field keep parameter 9.1. keep
10. Acknowledgements 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:
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Predefined
Schneyer, Milo Orsic, John Elwell and Ya-Ching Tan for their comments Header Field Parameter Name Values Reference
on the initial draft. Thanks to Juha Heinaenen, Jiri Kuthan and Dean ---------------------- --------------------- ---------- ---------
Willis for their comments on the list. Thanks to Vijay Gurbani for Via keep No [RFCXXXX]
providing text about the relationship with the connect-reuse
specification.
11. References 10. Security Considerations
11.1. Normative References This specification does not introduce security consideritions in
additions 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
(SIP) Extension Header Field for Registering Non-Adjacent A., Peterson, J., Sparks, R., Handley, M., and E.
Contacts", RFC 3327, December 2002. 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, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
11.2. Informative References 12.2. Informative References
[I-D.ietf-sip-connect-reuse] [I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress), draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009. August 2009.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
 End of changes. 94 change blocks. 
334 lines changed or deleted 399 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/