draft-ietf-sipcore-keep-04.txt   draft-ietf-sipcore-keep-05.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational May 31, 2010 Intended status: Standards Track August 5, 2010
Expires: December 2, 2010 Expires: February 6, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-04.txt draft-ietf-sipcore-keep-05.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 is 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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 2, 2010. This Internet-Draft will expire on February 6, 2011.
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 24 skipping to change at page 2, line 24
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. Lifetime 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 associated with registration . . . . . . . 5 4.2.2. Keep-alives associated with registration . . . . . . . 5
4.2.3. Keep-alives associated with 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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Keep-alive negotiation associated with registration:
7.2. Keep-alive negotiation associated with registration:
UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. Keep-alive negotiation associated with dialog: UA-proxy . 10 6.3. Keep-alive negotiation associated with dialog: UA-proxy . 10
7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 6.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
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. Even though the keep-alive mechanisms are separated from
the rest of the SIP Outbound mechanism, SIP Outbound does not define the rest of the SIP Outbound mechanism, SIP Outbound does not define
a mechanism to explicitly negotiate usage of the keep-alive a mechanism to explicitly negotiate usage of the keep-alive
mechanisms, since usage of keep-alives in most cases are implicitly mechanisms. In some cases usage of keep-alives can be implicitly
negotiated as part of the SIP Outbound negotiation. negotiated as part of the SIP Outbound negotiation.
However, there are SIP Outbound use-cases where usage of keep-alives However, there are SIP Outbound use-cases where usage of keep-alives
are not implicitly negotiated as part of the SIP Outbound is not implicitly negotiated as part of the SIP Outbound negotiation.
negotiation. In addition, there are cases where SIP Outbound is not In addition, there are cases where SIP Outbound is not supported, or
supported, where it cannot be applied, but where there is still a where it cannot be applied, but where there is still a need to be
need to be able to negotiate usage of keep-alives. able to negotiate usage of keep-alives.
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 to explicitly negotiate usage of the NAT keep-alive SIP entities to explicitly negotiate usage of the NAT keep-alive
mechanisms defined in SIP Outbound. The "keep" parameter allows SIP mechanisms defined in SIP Outbound. The "keep" parameter allows SIP
entities to indicate willingness to send keep-alives, to indicate entities to indicate willingness to send keep-alives, to indicate
willingness to receive keep-alives, and for SIP entities willing to willingness to receive keep-alives, and for SIP entities willing to
receive keep-alives to provide a recommended keep-alive frequency. 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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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 might not support SIP Outbound. However, they usage of keep-alives might not support SIP Outbound. However, they
might still support the keep-alive mechanisms defined in SIP might still support the keep-alive mechanisms defined in SIP
Outbound, and need to be able to negotiate 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 the initial SIP Outbound allows the establishment of flows using the initial
request for a dialog. As specified in [RFC5626], usage keep-alives request for a dialog. As specified in [RFC5626], usage of keep-
is not implicitly negotiated for such flows, why usage needs to be alives is not implicitly negotiated for such flows.
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 26 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 towards it adjacent upstream indicate willingness to send keep-alives towards its adjacent
SIP entity. If a SIP entity is willing to receive keep-alives from downstream SIP entity. A SIP entity can also insert the header field
its adjacent downstream SIP entity, and the Via header field in a response to explicitly indicate willingness to receive keep-
associated with the adjacent downstream SIP entity contains a "keep" alives from its adjacent upstream SIP entity.
parameter, the SIP entity willing to receive keep-alives can add an
integer parameter value to that "keep" parameter. The integer
parameter value can be used to indicate a recommended keep-alive
frequency. A zero value indicates that the SIP entity is willing to
receive keep-alives, but that a recommended keep-alive frequency is
not provided.
SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261].
Adjacent downstream SIP entity: The adjacent SIP entity in the
direction towards which a SIP request is sent.
Adjacent upstream SIP entity: The adjacent SIP entity in the
direction from which a SIP request is received.
4. User Agent and Proxy behavior 4. User Agent and Proxy behavior
4.1. General 4.1. General
This section describes how SIP UAs and proxies negotiate usage of This section describes how SIP UAs and proxies negotiate usage of
keep-alives associated with a registration, or a dialog, which types keep-alives associated with a registration, or a dialog, which types
of SIP requests types can be used in order to negotiate the usage, of SIP requests can be used in order to negotiate the usage, and the
and the lifetime of the negotiated keep-alives. lifetime of the negotiated keep-alives.
SIP entities indicate willingness to send keep-alives towards the SIP entities indicate willingness to send keep-alives towards the
adjacent upstream SIP entity using SIP requests. The associated adjacent downstream 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. SIP entities that indicate willingness to receive keep- keep-alives. SIP entities that indicate willingness to receive keep-
alives can provide a recommended keep-alive frequency. alives can provide a recommended keep-alive frequency.
The procedures to negotiate usage of keep-alives are identical for The procedures to negotiate usage of keep-alives are identical for
SIP UAs and proxies. SIP UAs and proxies.
NOTE: Usage of keep-alives is negotiated per direction. If a SIP NOTE: Usage of keep-alives is negotiated per direction. If a SIP
entity has indicated willingness to receive keep-alives from its entity has indicated willingness to receive keep-alives from an
adjacent downstream SIP entity, sending of keep-alives towards the adjacent SIP entity, sending of keep-alives towards the same SIP
same SIP entity needs to be separately negotiated. entity needs to be separately negotiated.
NOTE: Since there are SIP entities that already use a combination of NOTE: Since there are SIP entities that already use a combination of
Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP
entities are expected to be able to receive those, this specification entities are expected to be able to receive those, this specification
does not forbid the sending of CRLF keep-alive messages towards an does not forbid the sending of CRLF keep-alive messages towards an
adjacent upstream SIP entity even if usage of keep-alives have not adjacent SIP entity even if usage of keep-alives with that SIP entity
been negotiated. However, the "keep" parameter is still important in has not been negotiated. However, the "keep" parameter is still
order for a SIP entity to indicate that it supports sending of CRLF important in order for a SIP entity to indicate that it supports
keep-alive messages, so that the adjacent upstream SIP entity does sending of CRLF keep-alive messages, so that the adjacent downstream
not use other mechanisms (e.g. short registration refresh intervals) SIP entity does not use other mechanisms (e.g. short registration
in order to keep NAT bindings open. refresh intervals) in order to keep NAT bindings open.
4.2. Lifetime of keep-alives 4.2. Lifetime of keep-alives
4.2.1. General 4.2.1. General
The lifetime of negotiated keep-alives depends on whether the keep- The lifetime of negotiated keep-alives depends on whether the keep-
alives are associated with a registration or a dialog. The section alives are associated with a registration or a dialog. This section
describes the lifetime of negotiated keep-alives. describes the lifetime of negotiated keep-alives.
4.2.2. Keep-alives associated with registration 4.2.2. Keep-alives associated with registration
SIP entities use a registration request in order to negotiate usage SIP entities use a registration request in order to negotiate usage
of keep-alives associated with a registration. Usage of keep-alives of keep-alives associated with a registration. Usage of keep-alives
can be negotiated when the registration is established, or later can be negotiated when the registration is established, or later
during the lifetime of the registration. Once negotiated, keep- during the lifetime of the registration. Once negotiated, keep-
alives are sent until the registration is terminated, or until a 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. When a
skipping to change at page 6, line 22 skipping to change at page 6, line 22
during the lifetime of the dialog. Once negotiated, keep-alives MUST during the lifetime of the dialog. Once negotiated, keep-alives MUST
be sent for the lifetime of the dialog, until the dialog is be sent for the lifetime of the dialog, until the dialog is
terminated. Once usage of keep-alives associated with a dialog has terminated. Once usage of keep-alives associated with a dialog has
been negotiated, it is not possible to re-negotiate the usage been negotiated, it is not possible to re-negotiate the usage
associated with the dialog. 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 sending of keep- As defined in [RFC5626], a SIP entity that supports sending of 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 those aspects of STUN
which is required to apply the STUN keep-alive mechanism defined in that are required in order to apply the STUN keep-alive mechanism
[RFC5626], and it must support the CRLF keep-alive mechanism defined defined in [RFC5626], and it must support the CRLF keep-alive
in [RFC5626]. mechanism defined 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 for the lifetime of a negotiate the sending of keep-alives for the lifetime of a
registration (in case of a REGISTER request), or a dialog (in case of registration, or a dialog, it MUST insert a "keep" parameter in its
an initial request for a dialog, or a mid-dialog target refresh Via header field of the request to indicate willingness to send keep-
request), it MUST insert a "keep" parameter in its Via header field alives.
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 of the response contains a parameter in its Via header field of the response contains a "keep"
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 requests (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.
Once a SIP entity has negotiated sending of keep-alives associated Once a SIP entity has negotiated sending of keep-alives associated
with a dialog towards its adjacent upstream SIP entity, it MUST NOT with a dialog towards an adjacent SIP entity, it MUST NOT insert a
insert a "keep" parameter in any subsequent SIP requests associated "keep" parameter in any subsequent SIP requests, associated with the
with the dialog. Such "keep" parameter MUST be ignored, if received. dialog, towards that adjacent SIP entity. Such "keep" parameter MUST
be ignored, if received.
Since an ACK request does not have an associated response, it can not 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 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 MUST NOT insert a "keep" parameter in its Via header field of an ACK
request. Such "keep" parameter MUST be ignored, if received. 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 A SIP entity MUST NOT indicates willingness to send keep-alives
the same time is also about to send or forward a SIP request associated with a dialog, unless it has also inserted itself in the
associated with the same registration or dialog, for which the keep- dialog route set [RFC3261].
alive is to be sent, the SIP entity MAY choose not to send the keep-
alive, as the SIP request will perform the same keep-alive action.
NOTE: When a SIP entity sends an initial request for a dialog, if the 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 downstream SIP entity does not insert itself in the dialog
route set using a Record-Route header field [RFC3261], the adjacent route set using a Record-Route header field [RFC3261], the adjacent
upstream SIP entity will change once the dialog route set has been downstream 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 parameter parameter in the associated response does not contain a parameter
value, the SIP entity might choose to insert a "keep" parameter in value, the SIP entity might choose to insert a "keep" parameter in
its Via header field of a subsequent SIP request associated with the its Via header field of a subsequent SIP request associated with the
dialog, in case the new adjacent SIP entity (based on the dialog dialog, in case the new adjacent SIP downstream entity (based on the
route set) is willing to receive keep-alives (in which case it will dialog route set) is willing to receive keep-alives (in which case it
add a parameter value to the "keep" parameter). will add a parameter value to the "keep" parameter).
NOTE: If a SIP entity inserts a "keep" parameter in its Via header If an INVITE request is used to indicate willingness to send keep-
field of an INVITE request, and it receives multiple responses alives, as long as at least one response (provisional or final) to
(provisional or final) associated with the request, as long as at the INVITE request contains a "keep" parameter with a parameter
least one of the responses, per dialog, contains a "keep" parameter value, it is seen as an indication that the adjacent downstream SIP
with a parameter value it is seen as an indication that the adjacent entity is willing to receive keep-alives associated with the dialog
upstream SIP entity is willing to receive keep-alives associated with on which the response is received.
the dialog.
A SIP entity that has negotiated sending of keep-alives associated
with a registration MUST be prepared to receive, from the receiver of
the keep-alives, SIP messages (requests and responses) associated
with the registration on the same IP port:address from where the
keep-alives are sent. If the SIP entity sends the keep-alives over a
connection-oriented transport protocol, it MUST be prepared to
receive SIP messages associated with the registration over the same
connection. The same rules apply for SIP messages associated with a
dialog, if the SIP entity has negotiated sending of keep-alives
associated with a 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 those aspects of STUN that are required in order to apply the
alive mechanism defined in [RFC5626], and it must support the CRLF STUN keep-alive mechanism defined in [RFC5626], and it must support
keep-alive mechanism defined in [RFC5626]. the CRLF keep-alive mechanism defined in [RFC5626].
When a SIP entity creates or receives a response to a request that When a SIP entity sends or forwards a response, and the adjacent
can be used in order to indicate willingness to send keep-alives upstream SIP entity indicated willingness to send keep-alives, if the
associated with a registration or dialog, and the Via header field SIP entity is willing to receive keep-alives associated with the
associated with the adjacent downstream SIP entity (that is, the top- registration, or the dialog, from the adjacent upstream SIP entity it
most Via header field once a SIP entity that received the response MUST add a parameter value to the "keep" parameter, before sending or
has removed its own Via header field from the response) contains a forwarding the response. The parameter can contain a recommended
"keep" parameter, if the SIP entity is willing to receive keep-alives keep-alive frequency, or a zero value.
associated with the registration (in case of a REGISTER response), or
the dialog (in case of a response to an initial request for a dialog, When a SIP entity indicates willingness to receive keep-alives in a
or a response to a mid-dialog target refresh request), from the response to an INVITE request, it MUST insert a "keep" parameter in
adjacent downstream SIP entity it MUST add a parameter value to the at least one reliable response to the request. The SIP entity MAY
"keep" parameter, before sending or forwarding the response. The insert an identical "keep" parameter value in other responses to the
parameter can contain a recommended keep-alive frequency, or a zero same request. The SIP entity MUST NOT insert "keep" parameters with
value. differing values in responses to a single INVITE request. The SIP
entity SHOULD indicate the willingness to receive keep-alives as soon
as possible.
A SIP entity MUST NOT indicates willingness to receive keep-alives
associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261].
A SIP entity that has negotiated receiving of keep-alives associated
with a registration MUST send, towards the sender of the keep-alives,
SIP messages (requests and responses) associated with the
registration using the IP address:port from where the keep-alives are
received. If the SIP entity receives the keep-alives over a
connection-oriented transport protocol, it MUST send SIP messages
associated with the registration over the same connection, rather
than creating a new connection. The same rules apply for SIP
messages associated with a dialog, if the SIP entity has negotiated
receiving of keep-alives associated with a dialog.
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 non-zero value that indicates a contains a "keep" parameter with a non-zero value that indicates a
recommended keep-alive frequency, it MUST use the procedures defined recommended keep-alive frequency, it MUST use the procedures defined
for the Flow-Timer header field [RFC5626]. According to the for the Flow-Timer header field [RFC5626]. According to the
procedures, the SIP entity must send keep-alives at least as often as procedures, the SIP entity must send keep-alives at least as often as
the indicated recommended keep-alive frequency, and if the SIP entity the indicated recommended keep-alive frequency, and if the SIP entity
uses the recommended keep-alive frequency then it should send its uses the recommended keep-alive frequency then it should send its
keep-alives so that the interval between each keep-alive is randomly keep-alives so that the interval between each keep-alive is randomly
distributed between 80% and 100% of the recommended keep-alive distributed between 80% and 100% of the recommended keep-alive
frequency. frequency.
If the received "keep" parameter value is zero, the SIP entity can If the received "keep" parameter value is zero, the SIP entity can
send keep-alives at its discretion. [RFC5626] provides additional send keep-alives at its discretion. [RFC5626] provides additional
guidance on selecting the keep-alive frequency in case a recommended guidance on selecting the keep-alive frequency in case a recommended
keep-alive frequency is not provided. keep-alive frequency is not provided.
A SIP entity that uses the "keep" parameter to indicate willingness If a SIP entity that uses the "keep" parameter to indicate
to receive keep-alives MUST NOT use the Flow-Timer header field in willingness to receive keep-alives also inserts a Flow-Timer header
order to provide a recommended keep-alive frequency. field (that can happen if the SIP entity is using both the Outbound
mechanism and the keep-alive mechanism) in the same SIP message, the
header field value and the "keep" parameter value MUST be identical.
SIP Outbound uses the Flow-Timer header field to indicate the server- SIP Outbound uses the Flow-Timer header field to indicate the server-
recommended keep-alive frequency. However, it will only be sent recommended keep-alive frequency. However, it will only be sent
between a UA and an edge proxy. Using the "keep" parameter, however, between a UA and an edge proxy. Using the "keep" parameter, however,
the sending and receiving of keep-alives might be negotiated between the sending and receiving of keep-alives might be negotiated between
multiple entities on the signalling path. Since the server- multiple entities on the signalling path. In addition, since the
recommended keep-alive frequency might vary between different SIP server-recommended keep-alive frequency might vary between different
entities, those would have to re-write the Flow-Timer header field SIP entities, a single Flow-Timer header field can not be used to
value. In addition, if a SIP entity does not indicate willingness to indicate all the different frequency values, without forcing entities
receive keep-alives from its adjacent downstream SIP entity, and to re-write the value of the Flow-Timer header field.
receives a Flow-Timer header field in a response, it would have to
remove the Flow-Timer header field from the response. This issue
does not exist for the "keep" parameter, as each SIP entity has its
own individual Via header field.
6. Overlap with connection reuse
The connect-reuse specification [I-D.ietf-sip-connect-reuse]
specifies how to use connection-oriented transports to send requests
in the reverse direction. SIP entity A opens a connection to entity
B in order to send a request. Under certain conditions entity B can
reuse that connection for sending requests in the backwards direction
to A as well. However, the connect-reuse specification does not
define a keep-alive mechanism for this connection.
The mechanism specified in this draft is thus orthogonal to the
purpose of connection reuse. An entity that wants to use connection-
reuse as well as indicate keep-alive mechanism on that connection
will insert both the "alias" parameter defined in [connect-reuse] as
well as the "keep" parameter defined in this memo. Inserting only
one of these parameters is not a substitute for the other. Thus,
while the presence of a "keep" parameter will indicate that the
entity supports keep-alives in order to keep the connection open, no
inference can be drawn on whether that connection can be used for
requests in the backwards direction.
7. Examples 6. Examples
7.1. General 6.1. General
This section shows example flows where usage of keep-alives, This section shows example flows where usage of keep-alives,
associated with a registration and a dialog, is negotiated between associated with a registration and a dialog, is negotiated between
different SIP entities. different SIP entities.
7.2. Keep-alive negotiation associated with registration: UA-proxy 6.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) forwards the request towards the registrar. (P1) forwards the request towards the registrar.
P1 is willing to receive keep-alives from Alice for the duration of P1 is willing to receive keep-alives from Alice for the duration of
the registration, so When P1 receives the associated response it adds the registration, so When P1 receives the associated response it adds
a keep parameter value, which indicates a recommended keep-alive a keep parameter value, which indicates a recommended keep-alive
frequency of 30 seconds, to Alice's Via header field, before it frequency of 30 seconds, to Alice's Via header field, before it
skipping to change at page 10, line 33 skipping to change at page 10, line 33
|<== 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 associated with dialog: UA-proxy 6.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, before it forwards the adding itself to a Record-Route header field, before it forwards the
request towards Bob. request towards Bob.
P1 is willing to receive keep-alives from Alice for the duration of P1 is willing to receive keep-alives from Alice for the duration of
the dialog, so When P1 receives the associated response it adds a the dialog, so When P1 receives the associated response it adds a
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 associated with dialog: UA-UA 6.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, before it set, by adding itself to a Record-Route header field, before it
forwards the request towards Bob. . 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 associated with field that P1 is not willing to receive keep-alives associated with
skipping to change at page 13, line 47 skipping to change at page 13, line 47
|<== STUN response ====================================| |<== STUN response ====================================|
| | | |
| | | |
|--- BYE --------------------------------------------->| |--- BYE --------------------------------------------->|
| | | |
|<-- 200 OK -------------------------------------------| |<-- 200 OK -------------------------------------------|
| | | |
Figure 3: Example call flow Figure 3: Example call flow
8. Grammar 7. 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 1*(DIGIT) ] keep = "keep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations 8. IANA Considerations
9.1. keep 8.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 7. 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 9. Security Considerations
This specification does not introduce security considerations in This specification does not introduce security considerations in
addition to those specified in [RFC5626]. addition to those specified in [RFC5626].
11. Acknowledgements 10. 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, John Elwell and Paul
comments on the list. Thanks to Vijay Gurbani for providing text Kyzivat for their comments on the list. Thanks to Vijay Gurbani for
about the relationship with the connect-reuse specification. providing text (later removed) about the relationship with the
connect-reuse specification.
12. References
12.1. Normative References 11. 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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. 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.
12.2. Informative References
[I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 43 change blocks. 
154 lines changed or deleted 143 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/