draft-ietf-sipcore-keep-12.txt   rfc6223.txt 
SIPCORE Working Group C. Holmberg Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft Ericsson Request for Comments: 6223 Ericsson
Intended status: Standards Track January 20, 2011 Category: Standards Track April 2011
Expires: July 24, 2011 ISSN: 2070-1721
Indication of support for keep-alive Indication of Support for Keep-Alive
draft-ietf-sipcore-keep-12.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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 24, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6223.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 ....................................................2
1.1. Use-case: Dialog from non-registered UAs . . . . . . . . . 3 1.1. Use-Case: Dialog 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 .....................................................3
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. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9 6. Connection Reuse ................................................9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples ........................................................9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. General ....................................................9
7.2. Keep-alive negotiation associated with registration: 7.2. Keep-Alive Negotiation Associated with
UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 10 Registration: UA-Proxy .....................................9
7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11 7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy ...11
7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 13 7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA ......13
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Grammar ........................................................15
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. General ...................................................15
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. ABNF ......................................................15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations ............................................15
9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. "keep" Via Header Field Parameter .........................15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations .......................................15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements ..............................................16
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References ....................................................17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References .....................................17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References ...................................17
13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
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. Even though 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. In some cases usage of keep-alives can be 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
is not implicitly negotiated as part of the SIP Outbound negotiation. is not implicitly negotiated as part of the SIP Outbound negotiation.
In addition, there are cases where SIP Outbound is not supported, or In addition, there are cases where SIP Outbound is not supported, or
where it cannot be applied, but where there is still a need to be where it cannot be applied, but where there is still a need to be
able to negotiate usage of keep-alives. Last, SIP Outbound only able to negotiate usage of keep-alives. Last, SIP Outbound only
allows keep-alives to be negotiated between a UA and an edge proxy, allows keep-alives to be negotiated between a User Agent (UA) and an
and not between other SIP entities. edge proxy, and not between other SIP entities.
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
receive keep-alives to provide a recommended keep-alive frequency. to 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 usage of keep-alives is needed. explicitly negotiate usage of keep-alives is needed.
1.1. Use-case: Dialog from non-registered UAs 1.1. Use-Case: Dialog 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 dialog, but in order to maintain NAT bindings before it establishes a dialog, but in order to maintain NAT bindings
open during the lifetime of the dialog it still needs to be able to open during the lifetime of the dialog, it still needs to be able to
negotiate sending of keep-alives towards its adjacent downstream SIP negotiate the sending of keep-alives towards its adjacent downstream
entity. A typical example is an emergency call, where a registration SIP entity. A typical example is an emergency call, where a
is not always required in order to make the call. 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 some SIP entities that need to be able to negotiate the In some cases, some SIP entities that need to be able to negotiate
use of keep-alives might not support SIP Outbound. However, they the use 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
Outbound, and need to be able to negotiate usage of them. 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 RFC 5626 [RFC5626], usage of request for a dialog. As specified in RFC 5626 [RFC5626], usage of
keep-alives is not implicitly negotiated for such flows. keep-alives is not implicitly negotiated for such flows.
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 RFC 5626, a SIP proxy that is located Edge proxy: As defined in RFC 5626, 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.
NOTE: In some deployments the edge proxy might physically be located NOTE: In some deployments, the edge proxy might be physically
in the same SIP entity as the Authoritative Proxy. located in the same SIP entity as the Authoritative Proxy.
Keep-alives: The keep-alive messages defined in RFC 5626. Keep-alives: The keep-alive messages defined in RFC 5626.
"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 the topmost Via header field that it adds to the can insert in the topmost Via header field that it adds to the
request, to explicitly indicate willingness to send keep-alives request, to explicitly indicate willingness to send keep-alives
towards its adjacent downstream SIP entity. A SIP entity can add a towards its adjacent downstream SIP entity. A SIP entity can add a
parameter value to the "keep" parameter in a response to explicitly parameter value to the "keep" parameter in a response to explicitly
indicate willingness to receive keep-alives from its adjacent indicate willingness to receive keep-alives from its adjacent
upstream SIP entity. upstream SIP entity.
SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261. SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
Adjacent downstream SIP entity: The adjacent SIP entity in the Adjacent downstream SIP entity: The adjacent SIP entity in the
direction towards which a SIP request is sent. direction towards which a SIP request is sent.
Adjacent upstream SIP entity: The adjacent SIP entity in the Adjacent upstream SIP entity: The adjacent SIP entity in the
direction from which a SIP request is received. 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 can be used in order to negotiate the usage, and the of SIP requests can be used in order to negotiate the usage, 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 downstream 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
skipping to change at page 5, line 23 skipping to change at page 5, line 10
In general, it can be useful for SIP entities to indicate willingness In general, it can be useful for SIP entities to indicate willingness
to send keep-alives, even if they are not aware of any necessity for to send keep-alives, even if they are not aware of any necessity for
them to send keep-alives, since the adjacent downstream SIP entity them to send keep-alives, since the adjacent downstream SIP entity
might have knowledge about the necessity. Similarly, if the adjacent might have knowledge about the necessity. Similarly, if the adjacent
upstream SIP entity has indicated willingness to send keep-alives, it upstream SIP entity has indicated willingness to send keep-alives, it
can be useful for SIP entities to indicate willingness to receive can be useful for SIP entities to indicate willingness to receive
keep-alives, even if they are not aware of any necessity for the keep-alives, even if they are not aware of any necessity for the
adjacent upstream SIP entity to send them. adjacent upstream SIP entity to send them.
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 an entity has indicated willingness to receive keep-alives from an
adjacent SIP entity, sending of keep-alives towards that adjacent SIP adjacent SIP entity, the sending of keep-alives towards that
entity needs to be separately negotiated. adjacent SIP 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
Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP of Carriage Return and Line Feed (CRLF) as keep-alive messages,
entities are expected to be able to receive those, this specification and SIP entities are expected to be able to receive those, this
does not forbid the sending of double-CRLF keep-alive messages specification does not forbid the sending of double-CRLF keep-
towards an adjacent SIP entity even if usage of keep-alives with that alive messages towards an adjacent SIP entity even if usage of
SIP entity has not been negotiated. However, the "keep" parameter is keep-alives with that SIP entity has not been negotiated.
still important in order for a SIP entity to indicate that it However, the "keep" parameter is still important in order for a
supports sending of double-CRLF keep-alive messages, so that the SIP entity to indicate that it supports the sending of double-CRLF
adjacent downstream SIP entity does not use other mechanisms (e.g. keep-alive messages, so that the adjacent downstream SIP entity
short registration refresh intervals) in order to keep NAT bindings does not use other mechanisms (e.g., short registration refresh
open. 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. This 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 registration. Once negotiated, keep-alives are sent until during the registration. Once negotiated, keep-alives are sent until
the registration is terminated, or until a subsequent registration 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 subsequent registration
refresh request is sent or forwarded, if a SIP entity is willing to refresh request is sent or forwarded, if a SIP entity is willing to
continue sending keep-alives associated with the registration, usage continue sending keep-alives associated with the registration, usage
of keep-alives MUST be re-negotiated. If usage is not successfully of keep-alives MUST be re-negotiated. If usage is not successfully
re-negotiated, the SIP entity MUST cease sending of keep-alives re-negotiated, the SIP entity MUST cease the sending of keep-alives
associated with the registration. associated with the registration.
NOTE: Sending of keep-alives associated with a registration can only NOTE: The sending of keep-alives associated with a registration
be negotiated in the direction from the registering SIP entity can only be negotiated in the direction from the registering SIP
towards the registrar. entity towards the registrar.
4.2.3. Keep-alives associated with dialog 4.2.3. Keep-Alives Associated with Dialog
SIP entities use an initial request for a dialog, or a mid-dialog SIP entities use an initial request for a dialog, or a mid-dialog
target refresh request [RFC3261], in order to negotiate sending and target refresh request [RFC3261], in order to negotiate the sending
receiving of keep-alives associated with a dialog. Usage of keep- and receiving of keep-alives associated with a dialog. Usage of
alives can be negotiated when the dialog is established, or later keep-alives can be negotiated when the dialog is established, or
during the lifetime of the dialog. Once negotiated, keep-alives MUST later during the lifetime of the dialog. Once negotiated, keep-
be sent for the lifetime of the dialog, until the dialog is alives MUST be sent for the lifetime of the dialog, until the dialog
terminated. Once usage of keep-alives associated with a dialog has is terminated. Once the usage of keep-alives associated with a
been negotiated, it is not possible to re-negotiate the usage dialog has been negotiated, it is not possible to re-negotiate the
associated with the dialog. 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 RFC 5626, a SIP entity that supports sending of keep- As defined in RFC 5626, a SIP entity that supports the sending of
alives must act as a Session Traversal Utilities for NAT (STUN) keep-alives must act as a Session Traversal Utilities for NAT (STUN)
client [RFC5389]. The SIP entity must support those aspects of STUN client [RFC5389]. The SIP entity must support those aspects of STUN
that are required in order to apply the STUN keep-alive mechanism that are required in order to apply the STUN keep-alive mechanism
defined in RFC 5626, and it must support the CRLF keep-alive defined in RFC 5626, and it must support the CRLF keep-alive
mechanism defined in RFC 5626. RFC 5626 defines when to use STUN, mechanism defined in RFC 5626. RFC 5626 defines when to use STUN and
respectively double-CRLF, for keep-alives. when to use double-CRLF for keep-alives.
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 associated with a registration, negotiate the sending of keep-alives associated with a registration
or a dialog, it MUST insert a "keep" parameter in the topmost Via or a dialog, it MUST insert a "keep" parameter in the topmost Via
header field that it adds to the request, to indicate willingness to header field that it adds to the request, to indicate willingness to
send keep-alives. send keep-alives.
When the SIP entity receives the associated response, if the "keep" When the SIP entity receives the associated response, if the "keep"
parameter in the topmost Via header field of the response contains a parameter in the topmost Via header field of the response contains a
"keep" parameter value, it MUST start sending keep-alives towards the "keep" parameter value, it MUST start sending keep-alives towards the
same destination where it would send a subsequent request (e.g. same destination where it would send a subsequent request (e.g.,
REGISTER requests and initial requests for dialog) associated with REGISTER requests and initial requests for dialog) associated with
the registration (if the keep-alive negotiation is for a the registration (if the keep-alive negotiation is for a
registration), or where it would send subsequent mid-dialog requests registration), or where it would send subsequent mid-dialog requests
(if the keep-alive negotiation is for a dialog). Subsequent mid- (if the keep-alive negotiation is for a dialog). Subsequent
dialog requests are addressed based on the dialog route set. mid-dialog requests 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 the sending of keep-alives
with a dialog towards an adjacent SIP entity, it MUST NOT insert a associated with a dialog towards an adjacent SIP entity, it MUST NOT
"keep" parameter in any subsequent SIP requests, associated with the insert a "keep" parameter in any subsequent SIP requests associated
dialog, towards that adjacent SIP entity. Such "keep" parameter MUST with that dialog towards that adjacent SIP entity. Such "keep"
be ignored, if received. parameters 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 cannot
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 the topmost Via header field of MUST NOT insert a "keep" parameter in the topmost Via header field of
an ACK request. Such "keep" parameter MUST be ignored, if received. an ACK request. Such "keep" parameters MUST be ignored, if received.
A SIP entity MUST NOT indicates willingness to send keep-alives A SIP entity MUST NOT indicate willingness to send keep-alives
associated with a dialog, unless it has also inserted itself in the associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261]. dialog route set [RFC3261].
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
adjacent downstream SIP entity does not insert itself in the dialog the adjacent downstream SIP entity does not insert itself in the
route set using a Record-Route header field [RFC3261], the adjacent dialog route set using a Record-Route header field [RFC3261], the
downstream SIP entity will change once the dialog route set has been adjacent downstream SIP entity will change once the dialog route
established. If a SIP entity inserts a "keep" parameter in the set has been established. If a SIP entity inserts a "keep"
topmost Via header field of an initial request for a dialog, and the parameter in the topmost Via header field of an initial request
"keep" parameter in the associated response does not contain a for a dialog, and the "keep" parameter in the associated response
parameter value, the SIP entity might choose to insert a "keep" does not contain a parameter value, the SIP entity might choose to
parameter in the topmost Via header field of a subsequent SIP request insert a "keep" parameter in the topmost Via header field of a
associated with the dialog, in case the new adjacent downstream SIP subsequent SIP request associated with the dialog, in case the new
entity (based on the dialog route set) is willing to receive keep- adjacent downstream SIP entity (based on the dialog route set) is
alives (in which case it will add a parameter value to the "keep" willing to receive keep-alives (in which case it will add a
parameter). parameter value to the "keep" parameter).
If an INVITE request is used to indicate willingness to send keep- If an INVITE request is used to indicate willingness to send keep-
alives, as long as at least one response (provisional or final) to alives, as long as at least one response (provisional or final) to
the INVITE request contains a "keep" parameter with a parameter the INVITE request contains a "keep" parameter with a parameter
value, it is seen as an indication that the adjacent downstream SIP value, it is seen as an indication that the adjacent downstream SIP
entity is willing to receive keep-alives associated with the dialog entity is willing to receive keep-alives associated with the dialog
on which the response is received. on which the response is received.
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 RFC 5626, a SIP entity that supports receiving of keep- As defined in RFC 5626, a SIP entity that supports the receiving of
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 those aspects of STUN that are required in order to apply the support those aspects of STUN that are required in order to apply the
STUN keep-alive mechanism defined in RFC 5626, and it must support STUN keep-alive mechanism defined in RFC 5626, and it must support
the CRLF keep-alive mechanism defined in RFC 5626. the CRLF keep-alive mechanism defined in RFC 5626.
When a SIP entity sends or forwards a response, and the adjacent When a SIP entity sends or forwards a response, and the adjacent
upstream SIP entity indicated willingness to send keep-alives, if the upstream SIP entity has indicated willingness to send keep-alives, if
SIP entity is willing to receive keep-alives associated with the the SIP entity is willing to receive keep-alives associated with the
registration, or the dialog, from the adjacent upstream SIP entity it registration or with the dialog from that adjacent upstream SIP
MUST add a parameter value to the "keep" parameter, before sending or entity, then it MUST add a parameter value to the "keep" parameter
forwarding the response. The parameter value, if present and with a before sending or forwarding the response. The parameter value, if
value other than zero, represents a recommended keep-alive frequency, present and with a value other than zero, represents a recommended
given in seconds. keep-alive frequency, given in seconds.
There might be multiple responses to an INVITE request. When a SIP There might be multiple responses to an INVITE request. When a SIP
entity indicates willingness to receive keep-alives in a response to entity indicates willingness to receive keep-alives in a response to
an INVITE request, it MUST add a parameter value to the "keep" an INVITE request, it MUST add a parameter value to the "keep"
parameter in at least one reliable response to the request. The SIP parameter in at least one reliable response to the request. The SIP
entity MAY add identical parameter values to the "keep" parameters in entity MAY add identical parameter values to the "keep" parameters in
other responses to the same request. The SIP entity MUST NOT add other responses to the same request. The SIP entity MUST NOT add
different parameter value to the "keep" parameters in responses to different parameter values to the "keep" parameters in responses to
the same request. The SIP entity SHOULD indicate the willingness to the same request. The SIP entity SHOULD indicate the willingness to
receive keep-alives as soon as possible. receive keep-alives as soon as possible.
A SIP entity MUST NOT indicates willingness to receive keep-alives A SIP entity MUST NOT indicate willingness to receive keep-alives
associated with a dialog, unless it has also inserted itself in the associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261]. dialog route set [RFC3261].
5. Keep-alive frequency 5. Keep-Alive Frequency
If a SIP entity receives a SIP response, where the topmost Via header If a SIP entity receives a SIP response, where the topmost Via header
field contains a "keep" parameter with a non-zero value that field contains a "keep" parameter with a non-zero value that
indicates a recommended keep-alive frequency, given in seconds, it indicates a recommended keep-alive frequency, given in seconds, it
MUST use the procedures defined for the Flow-Timer header field MUST use the procedures defined for the Flow-Timer header field
[RFC5626]. According to the procedures, the SIP entity must send [RFC5626]. According to the procedures, the SIP entity must send
keep-alives at least as often as the indicated recommended keep-alive keep-alives at least as often as the indicated recommended keep-alive
frequency, and if the SIP entity uses the recommended keep-alive frequency, and if the SIP entity uses the recommended keep-alive
frequency then it should send its keep-alives so that the interval frequency, then it should send its keep-alives so that the interval
between each keep-alive is randomly distributed between 80% and 100% between each keep-alive is randomly distributed between 80% and 100%
of the recommended keep-alive frequency. of the recommended keep-alive 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. RFC 5626 provides additional send keep-alives at its discretion. RFC 5626 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.
This specification does not specify actions to take if negotiated This specification does not specify actions to take if negotiated
keep-alives are not received. As defined in RFC 5626, the receiving keep-alives are not received. As defined in RFC 5626, the receiving
SIP entity may consider a connection to be dead in such situations. SIP entity may consider a connection to be dead in such situations.
If a SIP entity that adds a parameter value to the "keep" parameter, If a SIP entity that adds a parameter value to the "keep" parameter
in order to indicate willingness to receive keep-alives, also inserts in order to indicate willingness to receive keep-alives also inserts
a Flow-Timer header field (that can happen if the SIP entity is using a Flow-Timer header field (that can happen if the SIP entity is using
both the Outbound mechanism and the keep-alive mechanism) in the same both the Outbound mechanism and the keep-alive mechanism) in the same
SIP message, the header field value and the "keep" parameter value SIP message, the header field value and the "keep" parameter value
MUST be identical. 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. On the other hand, by using the
the sending and receiving of keep-alives might be negotiated between "keep" parameter, the sending and receiving of keep-alives can be
multiple entities on the signalling path. In addition, since the negotiated between multiple entities on the signalling path. In
server-recommended keep-alive frequency might vary between different addition, since the server-recommended keep-alive frequency might
SIP entities, a single Flow-Timer header field can not be used to vary between different SIP entities, a single Flow-Timer header field
indicate all the different frequency values. cannot be used to indicate all the different frequency values.
6. Connection reuse 6. Connection Reuse
Keep-alives are often sent in order to keep NAT bindings open, so Keep-alives are often sent in order to keep NAT bindings open, so
that the NAT may be passed by SIP requests sent in the reverse that SIP requests sent in the reverse direction will pass by the NAT
direction, reusing the same connection, or for non-connection- and reuse the same connection. In the case of non-connection-
oriented transport protocols, reusing the same path. This oriented transport protocols, keep-alives would permit the same path
specification does not define such connection reuse mechanism. The to be reused. This specification does not define such a connection
keep-alive mechanism defined in this specification is only used to reuse mechanism. The keep-alive mechanism defined in this
negotiate the sending and receiving of keep-alives. Entities that specification is only used to negotiate the sending and receiving of
want to reuse connections need to use another mechanism to ensure keep-alives. Entities that want to reuse connections need to use
that security aspects associated with connection reuse are taken into another mechanism to ensure that security aspects associated with
consideration. connection reuse are taken into consideration.
RFC 5923 [RFC5923] specifies a mechanism for using connection- RFC 5923 [RFC5923] specifies a mechanism for using connection-
oriented transports to send requests in the reverse direction, and an oriented transports to send requests in the reverse direction, and an
entity that wants to use connection-reuse as well as indicate support entity that wants to use connection reuse as well as indicate support
of keep-alives on that connection will insert both the "alias" of keep-alives on that connection will insert both the "alias"
parameter defined in RFC 5923 as well as the "keep" parameter defined parameter defined in RFC 5923 and the "keep" parameter defined in
in this specification. this specification.
SIP Outbound specifies how registration flows are used to send SIP Outbound specifies how registration flows are used to send
requests in the reverse direction. requests in the reverse direction.
7. Examples 7. Examples
7.1. General 7.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.
NOTE: The examples do not show the actual syntactical encoding of the NOTE: The examples do not show the actual syntactical encoding of
request lines, response lines and the Via header fields, but rather a the request lines, response lines, and the Via header fields, but
pseudo code in order to identity the message type and to which SIP rather a pseudocode in order to identify the message type and also
entity a Via header field is associated. identify to which SIP entity a Via header field is associated.
7.2. Keep-alive negotiation associated with registration: UA-proxy 7.2. Keep-Alive Negotiation Associated with Registration: UA-Proxy
Figure 1 shows an example where Alice sends an REGISTER request. She Figure 1 shows an example where Alice sends a REGISTER request. She
indicates willingness of sending keep-alive by inserting a "keep" indicates willingness to send keep-alives by inserting a "keep"
parameter in her Via header field of the request. The edge proxy parameter in the Via header field of her 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
forwards the response towards Alice. 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 associated with the field that P1 is willing to receive keep-alives associated with the
registration. Until the registration expires, or Alice sends a registration. Until either the registration expires or Alice sends a
registration refresh request, Alice then sends periodic keep-alives registration refresh request, Alice then sends periodic keep-alives
(in this example using the STUN keep-alive technique) towards P1, (in this example using the STUN keep-alive technique) towards P1,
using the recommended keep-alive frequency indicated by the "keep" using the recommended keep-alive frequency indicated by the "keep"
parameter value. parameter value.
Alice P1 REGISTRAR Alice P1 REGISTRAR
| | | | | |
|--- REGISTER------------->| | |--- REGISTER------------->| |
| Via: Alice;keep | | | Via: Alice;keep | |
| |--- REGISTER-------------->| | |--- REGISTER-------------->|
skipping to change at page 11, line 31 skipping to change at page 10, line 39
| | | | | |
|=== 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 associated with dialog: UA-proxy 7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy
Figure 2 shows an example where Alice sends an initial INVITE request Figure 2 shows an example where Alice sends an initial INVITE request
for a dialog. She indicates willingness to send keep-alive by for a dialog. She indicates willingness to send keep-alives by
inserting a "keep" parameter in her Via header field of the request. inserting a "keep" parameter in the Via header field of her request.
The edge proxy (P1) adds itself to the dialog route set by adding The edge proxy (P1) adds itself to the dialog route set by adding
itself to a Record-Route header field, before it forwards the request itself to a Record-Route header field, before it forwards the request
towards Bob. 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
"keep" parameter value, which indicates a recommended keep-alive "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
forwards the response towards Alice. 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 associated with the field that P1 is willing to receive keep-alives associated with the
dialog. For the lifetime 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 P1, using the recommended keep-alive frequency indicated by towards P1, using the recommended keep-alive frequency indicated by
the "keep" parameter value. the "keep" parameter value.
skipping to change at page 12, line 47 skipping to change at page 12, line 44
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| | | | | |
|--- 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 7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA
Figure 3 shows an example where Alice sends an initial INVITE request Figure 3 shows an example where Alice sends an initial INVITE request
for a dialog. She indicates willingness to send keep-alive by for a dialog. She indicates willingness to send keep-alives by
inserting a "keep" parameter in her Via header field of the request. inserting a "keep" parameter in the Via header field of her request.
The edge proxy (P1) does not add itself to the dialog route set, by In this scenario, the edge proxy (P1) does not add itself to a
adding itself to a Record-Route header field, before it forwards the Record-Route header field (and so will not be added to the dialog
request towards Bob. route set) before forwarding the request towards Bob.
When Alice receives the response, she determines from her Via header When Alice receives the response, she determines from the 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
the dialog from her. When the dialog route set has been established, the dialog from her. When the dialog route set has been established,
Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not
insert itself in the dialog route set), and she once again indicates insert itself in the dialog route set), and she once again indicates
willingness to send keep-alives by inserting a "keep" parameter in willingness to send keep-alives by inserting a "keep" parameter in
her Via header field of the request. Bob supports the keep-alive the Via header field of her request. Bob supports the keep-alive
mechanism, and is willing to receive keep-alives associated with the mechanism, and is willing to receive keep-alives associated with the
dialog from Alice, so he creates a response and adds a "keep" dialog from Alice, so he creates a response and adds a "keep"
parameter value, which indicates a recommended keep-alive frequency parameter value, which indicates a recommended keep-alive frequency
of 30 seconds, to Alice's Via header field, before he forwards the of 30 seconds, to Alice's Via header field, before he forwards the
response towards Alice. 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 Bob is willing to receive keep-alives associated with the field that Bob is willing to receive keep-alives associated with the
dialog. For the lifetime 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 by towards Bob, using the recommended keep-alive frequency indicated by
the "keep" parameter value. the "keep" parameter value.
Alice P1 Bob Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Via: Alice;keep | | | Via: Alice;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: Alice:keep | | | Via: Alice;keep |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 | | | Via: P1 |
| | Via: Alice;keep | | | Via: Alice;keep |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: Alice;keep | | | Via: Alice;keep | |
| | | | | |
| | | |
|--- ACK --------------------------------------------->| |--- ACK --------------------------------------------->|
| | | |
|--- UPDATE ------------------------------------------>| |--- UPDATE ------------------------------------------>|
| Via: Alice;keep | | Via: Alice;keep |
| | | |
|<-- 200 OK ------------------------------------------>| |<-- 200 OK -------------------------------------------|
| Via: UAC;keep=30 | | Via: Alice;keep=30 |
| | | |
| | | |
| *** Timeout *** | | *** Timeout *** |
| | | |
|=== STUN request ====================================>| |=== STUN request ====================================>|
|<== STUN response ====================================| |<== STUN response ====================================|
| | | |
| *** Timeout *** | | *** Timeout *** |
| | | |
|=== STUN request ====================================>| |=== STUN request ====================================>|
|<== STUN response ====================================| |<== STUN response ====================================|
| | | |
| | | |
|--- BYE --------------------------------------------->| |--- BYE --------------------------------------------->|
| | | |
|<-- 200 OK -------------------------------------------| |<-- 200 OK -------------------------------------------|
| | | |
Figure 3: Example call flow Figure 3: Example Call Flow
8. Grammar 8. Grammar
8.1. General 8.1. General
This section describes the syntax extensions to the ABNF syntax This section extends the ABNF definition of via-params from [RFC3261]
defined in RFC 3261, by defining a new Via header field parameter, by adding a new Via header field parameter, "keep". The ABNF defined
"keep". The ABNF defined in this specification is conformant to RFC in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL"
5234 [RFC5234]. is defined in RFC 3261. "DIGIT" is defined in RFC 5234.
8.2. ABNF 8.2. ABNF
via-params =/ keep via-params =/ keep
keep = "keep" [ EQUAL 1*(DIGIT) ] keep = "keep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations 9. IANA Considerations
9.1. keep 9.1. "keep" Via Header Field Parameter
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"
registry as per the registry created by [RFC3968]. The syntax is sub-registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8. The required information is: defined in Section 8 of this document. IANA has registered the
following:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- --------- ---------------------- --------------------- ---------- ---------
Via keep No [RFCXXXX] Via keep No [RFC6223]
10. Security Considerations 10. Security Considerations
SIP entities that send or receive keep-alives are often required to SIP entities that send or receive keep-alives are often required to
use a connection reuse mechanism, in order to ensure that requests use a connection reuse mechanism, in order to ensure that requests
sent in the reverse direction, towards the sender of the keep-alives, sent in the reverse direction, towards the sender of the keep-alives,
traverse NATs etc. This specification does not specify a connection traverse NATs, etc. This specification does not define a connection
reuse mechanism, and it does not address security issues related to reuse mechanism, and it does not address security issues related to
connection reuse. SIP entities that wish to reuse connections need connection reuse. SIP entities that wish to reuse connections need
to use a dedicated connection reuse mechanism, in conjunction with to use a dedicated connection reuse mechanism, in conjunction with
the keep-alive negotiation mechanism. the keep-alive negotiation mechanism.
Unless SIP messages are integrity protected hop-by-hop, e.g. using Unless SIP messages are integrity protected hop-by-hop, e.g., using
Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer
Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header
fields used by two entities to negotiate sending of keep-alives, e.g. fields used by two entities to negotiate the sending of keep-alives,
e.g., by removing the designations used to indicate willingness to
by removing the indications used to indicate willingness to send and send and receive keep-alives, or by decreasing the timer value to a
receive keep-alives, or by decreasing the timer value to a very low very low value, which might trigger additional resource consumption
value, which might trigger additional resource consumption due to the due to the frequently sent keep-alives.
frequently sent keep-alives.
The behavior defined in Sections 4.3 and 4.4 require a SIP entity The behaviors defined in Sections 4.3 and 4.4 require a SIP entity
using the mechanism defined in this specification to place a value in using the mechanism defined in this specification to place a value in
the "keep" parameter in the topmost Via header field value of a the "keep" parameter in the topmost Via header field value of a
response the SIP entity sends. They do not instruct the entity to response the SIP entity sends. They do not instruct the entity to
place a value in a "keep" parameter of any request it forwards. In place a value in a "keep" parameter of any request it forwards. In
particular, SIP proxies MUST NOT place a value into the keep particular, a SIP proxy MUST NOT place a value into the "keep"
parameter of the topmost Via header field value of a request it parameter of the topmost Via header field value of a request it
receives before forwarding it. A SIP proxy implementing this receives before forwarding it. A SIP proxy implementing this
specification SHOULD remove any keep parameter values in any Via specification SHOULD remove any "keep" parameter values in any Via
header field values below the topmost one in responses it receives header field values below the topmost one in responses it receives
before forwarding them. before forwarding them.
When requests are forwarded across multiple hops, it is possible for When requests are forwarded across multiple hops, it is possible for
a malicious downstream SIP entity to tamper with the accrued values a malicious downstream SIP entity to tamper with the accrued values
in the Via header field. The malicious SIP entity could place a in the Via header field. The malicious SIP entity could place a
value, or change an existing value in a "keep" parameter in any of value, or change an existing value in a "keep" parameter in any of
the Via header field values, not just the topmost value. A proxy the Via header field values -- not just the topmost value. A proxy
implementation that simply forwards responses by stripping the implementation that simply forwards responses by stripping the
topmost Via header field value and not inspecting the resulting new topmost Via header field value and not inspecting the resulting new
topmost Via header field value risks being adversely affected by such topmost Via header field value risks being adversely affected by such
a malicious downstream SIP entity. In particular, such a proxy may a malicious downstream SIP entity. In particular, such a proxy may
start receiving STUN requests if it blindly forwards a response with start receiving STUN requests if it blindly forwards a response with
a keep parameter with a value it did not create in the topmost Via a "keep" parameter with a value it did not create in the topmost Via
header field. header field.
To lower the chances of the malicious SIP entity's actions having To lower the chances of the malicious SIP entity's actions having
adverse affects on such proxies, when a SIP entity sends STUN keep- adverse effects on such proxies, when a SIP entity sends STUN keep-
alives to an adjacent downstream SIP entity and does not receive a alives to an adjacent downstream SIP entity and does not receive a
response to those STUN messages, it MUST, based on the procedure in response to those STUN messages (as described in Section 7.2.1 of
section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error RFC 5389 [RFC5389], it MUST stop sending keep-alives for the
response is received for the STUN request, stop sending keep-alives remaining duration of the dialog (if the sending of keep-alives were
for the remaining duration of the dialog (if the sending of keep- negotiated for a dialog) or until the sending of keep-alives is
alives were negotiated for a dialog) or until the sending of keep- re-negotiated for the registration (if the sending keep-alives were
alives is re-negotiated for the registration (if the sending keep- negotiated for a registration).
alives were negotiated for a registration).
Apart from the issues described above, this specification does not Apart from the issues described above, this specification does not
introduce security considerations in addition to those specified for introduce security considerations in addition to those specified for
keep-alives in [RFC5626]. keep-alives 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
and Milo Orsic for their comments on the initial draft. Thanks to Schneyer, and Milo Orsic for their comments on the initial draft
Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, version of this document. Thanks to Juha Heinanen, Jiri Kuthan, Dean
Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their Willis, John Elwell, Paul Kyzivat, Peter Musgrave, Dale Worley, Adam
comments on the list. Thanks to Vijay Gurbani for providing text Roach, and Robert Sparks for their comments on the sipcore mailing
about the relationship with the connect reuse specification. list. Thanks to Vijay Gurbani for providing text about the
relationship with the connect reuse specification.
12. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-keep-11
o Editorial fixes based on last call comments by Peter Saint-Andre
(Jan 11th)
o - TLS and DTLS references added
o - Clarification that the sending of keep-alives stops after 7
retranmissions
o Editorial fixes based on last call comments by Alexey Melnikov
(Jan 12th)
o - Additional text added to Grammar section
o Editorial fixes based on last call comments by Adrian Farrel (Jan
16th)
o Editorial fixes based on last call comments by Sean Turner (Jan
20th)
o Reference clean-ups
Changes from draft-ietf-sipcore-keep-10
o Editorial fixes based on last call comments by Juergen
Schoenwaelder (Dec 21st)
o Editorial fixes based on last call comments by Roni Even (Dec
28th)
Changes from draft-ietf-sipcore-keep-09
o Changes based on AD review comments by Robert Sparks
o Redundant paragraph removed from security considerations
Changes from draft-ietf-sipcore-keep-08
o Changes based on AD review comments by Robert Sparks
o Additional security considerations text provided by Robert Sparks
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html
(Nov 23rd)
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html
(Nov 23rd)
Changes from draft-ietf-sipcore-keep-07
o Last paragraph of section 4.2.2 removed
o Reference correction
Changes from draft-ietf-sipcore-keep-06
o New text added to the security considerations
Changes from draft-ietf-sipcore-keep-05
o New section about connection reuse added
o Clarify that the specification does not define a mechanism for
connection reuse
o New text added to the security considerations
o CRLF changed to double-CRLF in some places
13. References 12. References
13.1. Normative 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.
[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., Ed., and P. Overell, "Augmented BNF for
Specifications: ABNF", STD 68, RFC 5234, January 2008. 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., Ed., Mahy, R., Ed., and F. Audet, Ed.,
Initiated Connections in the Session Initiation Protocol "Managing Client-Initiated Connections in the Session
(SIP)", RFC 5626, October 2009. Initiation Protocol (SIP)", RFC 5626, October 2009.
13.2. Informative References 12.2. Informative References
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004. December 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in [RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse
the Session Initiation Protocol (SIP)", RFC 5923, in the Session Initiation Protocol (SIP)", RFC 5923,
June 2010. June 2010.
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. 90 change blocks. 
295 lines changed or deleted 240 lines changed or added

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