draft-ietf-sipcore-keep-01.txt   draft-ietf-sipcore-keep-02.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational December 1, 2009 Intended status: Standards Track April 15, 2010
Expires: June 4, 2010 Expires: October 17, 2010
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-01.txt draft-ietf-sipcore-keep-02.txt
Abstract Abstract
This specification defines a new SIP Via header parameter, "keep" This specification defines a new Session Initiation Protocol (SIP)
which SIP entities can use to indicate support of the NAT keep-alive header field parameter, "keep", that SIP entities can use to
techniques defined in SIP Outbound, in cases where the Outbound negotiate explicit support of the NAT keep-alive mechanisms defined
procedures are not supported or cannot be applied. in the SIP Outbound specification. The parameter is defined for
cases where the SIP Outbound mechanism is not supported, or in cases
where it cannot be applied.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 17, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use-case: Calls from non-registered UAs . . . . . . . . . 3
1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3
1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3
1.4. Use-case: Proxy-to-proxy heartbeat . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. User agent behavior . . . . . . . . . . . . . . . . . . . . . 4
5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. User agent client behavior . . . . . . . . . . . . . . . . 5
7. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Keep-alive negotiation for registration . . . . . . . 5
8. Overlap with connection reuse . . . . . . . . . . . . . . . . 6 4.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 5
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. User agent server behavior . . . . . . . . . . . . . . . . 6
9.1. Example with keep-alive negotiation during registration . 7 4.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 6
9.2. Example with keep-alive negotiation during session 4.4. Keep-alive frequency . . . . . . . . . . . . . . . . . . . 6
establishment . . . . . . . . . . . . . . . . . . . . . . 8 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.2. Edge proxy behavior . . . . . . . . . . . . . . . . . . . 7
11.1. IANA Registration of the SIP Via keep parameter . . . . . 10 5.2.1. Keep-alive negotiation for registration . . . . . . . 7
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Proxy behavior for proxy-to-proxy heartbeats . . . . . . . 7
13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 5.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 7
13.2. Informative References . . . . . . . . . . . . . . . . . . 10 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Example: Keep-alive negotiation for registration . . . . . 9
7.2. Example: Keep-alive negotiation for dialog from UA . . . . 10
7.3. Example: Keep-alive negotiation for dialog to UA . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. IANA Registration of the SIP header field keep
parameter . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Chapter 3.5 of [I-D.ietf-sip-outbound] defines two keep-alive Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive
techniques. Even though the keep-alive techniques are separated from mechanisms. Eventhough the keep-alive mechanisms are separated from
the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not the rest of the SIP Outbound mechanism, it is currently not possible
possible to indicate support of the keep-alive techniques without to explicitly negotiate the usage of keep-alives, since the keep-
also indicating support for the Outbound mechanism. In addition, as alives are implicitly negotiated as part of the SIP Outbound
described in [I-D.ietf-sip-outbound], for dialog initiated outbound negotation.
flows a separate mechanism is used to indicate and negotiate support
of keep-alives.
The Outbound mechanism is enabled during the UA registration phase. However, there are also SIP Outbound use-cases where the keep-alives
However, there are use-cases where the UA does not register itself, are not implicitly negotiated as part of the SIP Outbound
but still needs to be able to make calls and maintain NAT bindings negotiation, and therefor an explicit keep-alive negotiation
open during the duration of that call. A typical example is mechanism is needed. In addition, there are use-cases where SIP
emergency calls. There are also cases where entities do not support Outbound is not supported, or where it cannot be applied, but where
the Outbound mechanism, but still want to be able to indicate support there is still a need to be able to negotiate the usage of keep-
and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. alives.
In addition, the Outbound mechanism also allows the establishment of
flows using initial dialog SIP requests. As specified in
[I-D.ietf-sip-outbound], keep-alives must be separately negotiated
for such flows.
Another use-case is when network entities (SIP proxies) need to This specification defines a new SIP header field parameter, "keep",
perform heartbeats between themselves. The keep-alive techniqurs that SIP entities can use to negotiate support of the NAT keep-alive
defined in [I-D.ietf-sip-outbound] can be used for providing the mechanisms defined in the SIP Outbound specification [RFC5626]. The
heartbeats, and the mechanism in this document can be used by the parameter is defined for cases where the SIP Outbound mechanism is
entities to indicate and negotiate support of the keep-alive not supported, or in cases where it cannot be applied. The usage of
techniques. keep-alives can be negotiated as part of a registration, or as part
of a dialog.
This specification defines a new SIP Via header parameter, "keep", The following sections describe use-cases where a mechanism to
which can be used by a UA to indicate support of the keep-alive explicitly negotiate the usage of keep-alives is needed.
techniques defined in [I-D.ietf-sip-outbound]. The UA will insert
the "keep" parameter in the Via header of the REGISTER request, or
the initial session request if not registered.
This specification also defines a "yes" value for the "keep" 1.1. Use-case: Calls from non-registered UAs
parameter. The edge proxy will add a "yes" value to the "keep"
parameter, if received in the topmost Via header, to indicate support In some cases a UA does not register itself before making a call, but
of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. still needs to be able to make calls and send keep-alives in order to
maintain NAT bindings open during the duration of the call. A
typical example is emergency calls.
1.2. Use-case: SIP Outbound not supported
There are cases where the SIP entities that need to be able to
negotiate the usage of keep-alives do not support the SIP Outbound
mechanism
1.3. Use-case: SIP dialog initiated Outbound flows
SIP Outbound allows the establishment of flows using initial SIP
dialog requests. As specified in [RFC5626], keep-alives are not
implicitly negotiated for such flows, and therefor need to be
separately negotiated.
1.4. Use-case: Proxy-to-proxy heartbeat
There are cases where SIP proxies need to perform heartbeats between
themselves. Eventhough the heartbeats are normally not used for NAT
traversal purpose, the keep-alive mechanisms defined in [RFC5626] can
still be used to perform the heartbeats.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Edge proxy: As defined in [I-D.ietf-sip-outbound], an Edge Proxy is Edge proxy: As defined in [RFC5626], a SIP proxy that is located
any proxy that is located topologically between the registering User topologically between the registering User Agent (UA) and the
Agent and the Authoritative Proxy. The "first" edge proxy refers to Authoritative Proxy.
the first edge proxy encountered when a UA sends a request.
'keep' Parameter: The 'keep' parameter is a SIP Via header parameter Keep-alives: Refers to keep-alive messages using the mechanisms
which indicates that the entity inserting the parameter supports the define defined in the SIP Outbound specification [RFC5626].
keep-alive techniques defined in [I-D.ietf-sip-outbound]. The
parameter may carry an associated parameter value.
4. Requirements "keep" parameter: A SIP header field parameter that a SIP entity can
insert to explicitly indicate that it supports the keep-alive
mechanisms defined in the SIP Outbound specification [RFC5626]. The
parameter is defined for the SIP Contact, Path and Record-Route
header fields.
REQ 1: It MUST be possible for a SIP entity acting as a UAC to 4. User agent behavior
indicate, during registration and session establishment, support of
the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards
the next hop, if only the keep-alive part of [I-D.ietf-sip-outbound]
is used for the registration or session
REQ 2: It MUST be possible for a SIP entity acting as a UAS to 4.1. General
indicate, during registration and session establishment, support of
the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards
the previous hop, if only the keep-alive part of
[I-D.ietf-sip-outbound] is used for the registration or session
5. Client behavior This section describes how a UA (User Agent) negotiates the usage of
keep-alives between itself and its edge proxy, for a registration or
a dialog.
A SIP entity aciting as a UAC which supports the method defined in A UA will only send keep-alives towards its edge proxy, and MUST NOT
this specification MUST act as a STUN client expect to receive edge proxy initiated keep-alives.
[I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN
which is required to apply the STUN keep-alive technique
[I-D.ietf-sip-outbound].
When a SIP entity acting as a UAC (UA or proxy) which supports the A UA that supports keep-alives MUST insert a "keep" parameter in its
method defined in this specification sends a SIP REGISTER request, Contact header field even if it also indicates support of SIP
and the UAC wants to send keep-alives towards the next hop, the Outbound [RFC5626], in order to be able to negotiate the usage of
entity MUST insert a "keep" Via parameter in the SIP request. If the keep-alives also in cases where the edge proxy only supports keep-
Via header in the SIP REGISTER response contains a "keep" parameter alives, but not the other parts of SIP Outbound.
with a "yes" value, the UA knows that the keep-alive techniques
defined in [I-D.ietf-sip-outbound] can be used between the entity and
the next hop during the duration of the registration. If the SIP
REGISTER response contains a Flow-Timer header
[I-D.ietf-sip-outbound], and the UAC uses the server recommended
keepalive frequency provided in the header, the UAC SHOULD send its
keepalives so that the interval between each keepalive is randomly
distributed between 80% and 100% of the server provided time. If no
Flow-Timer header field was present in the SIP REGISTER response, the
UA can send keepalives at its discretion. The UA must insert a
"keep" parameter even if the UA also indicates support of Outbound
[I-D.ietf-sip-outbound], to allow keep-alive usage in cases where the
edge proxy will only support "keep".
When a UAC which supports the method defined in this specification As defined in [RFC5626], a UA that supports keep-alives MUST act as a
sends an initial SIP request, the UAC has not registered itself via Session Traversal Utilities for NAT (STUN) client [RFC5389]. The UA
the edge proxy towards which the SIP request is sent, and the UAC MUST support the amount of STUN which is required to apply the STUN
wants to send keep-alives towards the next hop, the UAC MUST include keep-alive mechanism defined in [RFC5626], and the UA MUST support
a "keep" Via parameter in the SIP request. If the Via header header the CRLF keep-alive mechanism defined in [RFC5626]. In addition, as
in the initial SIP responses contains a "keep" parameter with a "yes" defined in [RFC5389], the UAC MUST be able to process the SIP Path
value, the UA knows that the keep-alive techniques defined in header [RFC3327], in order to detect whether the edge proxy supports
[I-D.ietf-sip-outbound] can be used between the UAC and the next hop keep-alives.
during the duration of the call. If the initial SIP response
contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC
uses the recommended keepalive frequency provided in the header, the
UAC SHOULD send its keepalives so that the interval between each
keepalive is randomly distributed between 80% and 100% of the server
provided time. If no Flow-Timer header field was present in the
initial SIP response, the UA can send keepalives at its discretion.
If the UAC wishes to apply keep-alive for future calls, it MUST
insert a "keep" Via parameter in the initial SIP request of those
calls.
NOTE: Since there are clients that already use CRLF keep-alives, and NOTE: Keep-alives needs to be negotiated when a registration or
dialog is initiated. It is not possible to negotiate/re-negotiate
the usage keep-alives later during the registration or dialog, and
the usage of the "keep" parameter in re-registration requests and
dialog modification requsts is not specified.
NOTE: Since there are UAs that already use CRLF keep-alives, and
proxies are expected to be able to receive it, this specification proxies are expected to be able to receive it, this specification
does not forbid the sending of CRLF keep-alives even when no does not forbid the sending of CRLF keep-alives even an edge proxy
"keep=yes" indication has been received from the edge proxy. has not indicated support of keep-alives using the "keep" parameter.
However, the indicator is still important in order for the client to However, the "keep" parameter is still important in order for the UA
inform the edge proxy that the client supports CRLF keep-alives, so to inform the edge proxy that the UA supports CRLF keep-alives, so
that the edge proxy does not use other mechanisms (e.g. short that the edge proxy does not use other mechanisms (e.g. short
registration refresh intervals) in order to make sure the NAT registration refresh intervals) in order to make sure the NAT
bindings are kept open. bindings are kept open.
6. Server behavior 4.2. User agent client behavior
A SIP entity acting as a UAS (UA or proxy) which supports the method 4.2.1. Keep-alive negotiation for registration
defined in this specification MUST act as a STUN server
[I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN
which is required to apply the STUN keep-alive technique
[I-D.ietf-sip-outbound]. The UAS MUST also process double-CRLF keep-
alives, as defined in [I-D.ietf-sip-outbound].
When a UAS that supports the method defined in this specification When a UAC sends a REGISTER request for a new registration, if the
recieves a SIP REGISTER request which contains a "keep" parameter in UAC is willing to send keep-alives associated with the registration,
the topmost Via header, and the UAS wants to allow the sender of the it MUST insert a "keep" parameter in its Contact header field of the
SIP REGISTER request to send keep-alives towards the UAS during the REGISTER request.
duration of the registration, the UAS proxy MUST add a "yes" value to
the "keep" parameter. In addition the UAS MAY include a Flow-Timer
header field if the associated SIP REGISTER response.
When a UAS that supports the method defined in this specification When the UAC receives the REGISTER response, if the top-most Path
recieves an initial SIP request which contains a "keep" parameter in header field (edge proxy) of the response contains a "keep"
the topmost Via header, and the UAS wants to allow the sender of the parameter, the UAC MUST start to send keep-alives towards the edge
initial SIP request to send keep-alives towards the UAS during the proxy, and it MUST send keep-alives for the remaining duration of the
duration of the call, the UAS proxy MUST add a "yes" value to the registration. When the registration is terminated, the UAC MUST
"keep" parameter. In addition the UAS MAY include a Flow-Timer cease the sending of keep-alives negotiated for the registration.
header field if the associated initial SIP response.
7. Proxy behavior 4.2.2. Keep-alive negotiation for dialog
A proxy acting as a UAC, that wants to use the mechanism in this When a UAC sends an initial request (e.g. a SIP INVITE request) for a
document, shall follow the procedures defined in Section 5. dialog, if the UAC is willing to send keep-alives associated with the
dialog, it MUST insert a "keep" parameter in its Contact header field
of the request.
A proxy acting as a UAS, that wants to use the mechanism in this When the UAC receives the response(s) to the initial request for the
document, shall follow the procedures defined in Section 6. dialog, if the top-most Record-Route header field (edge proxy) of
response(s) contains a "keep" parameter, the UAC MUST start to send
keep-alives towards the edge proxy for the remaining duration of the
dialog. When the dialog is terminated, the UAC MUST cease the
sending of keep-alives negotiated for the dialog.
8. Overlap with connection reuse 4.3. User agent server behavior
4.3.1. Keep-alive negotiation for dialog
When a UAS receives an initial request for a dialog, if the top-most
Record-Route header filed contains a "keep" parameter, and if the UAS
is willing to send keep-alives associated with the dialog, it MUST
insert a "keep" parameter in its Contact header field in the
response(s) to the request. After that the UAS MUST start to send
keep-alives towards the edge proxy, and it MUST send keep-alives for
the remaining duration of the registration.
4.4. Keep-alive frequency
If the SIP message that contains the "keep" parameter of the edge
proxy also contains a Flow-Timer header field [RFC5626], it is
strongly RECOMMENDED that the UA uses the server recommended keep-
alive frequency value, provided in the header field, and sends keep-
alives so that the interval between each keep-alive is randomly
distributed between 80% and 100% of the provided value.
If the UA does not receive a Flow-Timer header field from the edge
proxy, it can send keep-alives at its discretion.
5. Proxy behavior
5.1. General
A proxy that supports the mechanism specified in this specification
MUST act as a STUN server [RFC5389], and MUST support the amount of
STUN which is required to apply the STUN keep-alive technique
[RFC5626]. The edge proxy MUST also process double-CRLF keep-alives,
as defined in [RFC5626].
If a proxy also generates keep-alives (see proxy-to-proxy case), it
MUST also act as a STUN client [RFC5389].
5.2. Edge proxy behavior
5.2.1. Keep-alive negotiation for registration
When an edge proxy receives an initial REGISTER request for a
registration from a UA behind the edge proxy, the Contact header
field of the request contains a "keep" parameter, and if the edge
proxy is willing to receive keep-alives from the UA for the
associated registration, the edge proxy MUST insert a "keep"
parameter in its Path header field of the associated REGISTER
response. In addition, the edge proxy MAY insert a Flow-Timer header
field [RFC5626], which indicates the recommended keep-alive frequency
for the registration.
5.2.2. Keep-alive negotiation for dialog
When an edge proxy receives a dialog initiation request from a UAC
behind the edge proxy, the Contact header field of the request
contains a "keep" parameter, and if the edge proxy is willing to
receive keep-alives from the UA for the associated dialog, the edge
proxy MUST insert a "keep" parameter in its Record-Route header field
of the associated response(s). In addition, the edge proxy MAY
insert a Flow-Timer header field [RFC5626], which indicates the
recommended keep-alive frequency for the dialog.
When an edge proxy receives an inbound dialog initiation request
towards a UAS behind the edge proxy, and if the edge proxy is willing
to receive keep-alives from the UA for the associated dialog, the
edge proxy MUST insert a "keep" parameter in its Record-Route header
field of the request. In addition, the edge proxy MAY insert a Flow-
Timer header field [RFC5626], which indicates the recommended keep-
alive frequency for the dialog. When the edge proxy receives
response(s) associated with the request from the UAS, associated with
the request, if the Contact header field of the response(s) contains
a "keep" parameter, the edge proxy can assume that the UAS will send
keep-alives associated with the dialog.
5.3. Proxy behavior for proxy-to-proxy heartbeats
5.3.1. Keep-alive negotiation for dialog
When a proxy receives a dialog initiation request from its previous-
hop proxy, and the top-most Record-Route header field of the request
contains a "keep" parameter, if the proxy is willing to send and
receive keep-alives from the previous-hop proxy for the associated
dialog, the proxy MUST insert a "keep" parameter in its Record-Route
header field of the associated response(s) sent towards the previous-
hop proxy. After that the proxy MUST send keep-alives, and accept
keep-alives sent from the previous-hop proxy, for the duration of the
dialog.
When a proxy forwards a dialog initiation request towards its next-
hop proxy, and it wants to negotiate the usage of keep-alives with
that next-hop proxy, it MUST include a "keep" parameter in its
Record-Record header field of the request. When the proxy receives
the associated response(s), if the Record-Route header field that
represents the next-hop proxy contains a "keep" parameter, the proxy
MUST start sending keep-alives towards the next-hop proxy for the
duration of the dialog.
NOTE: The usage of the Flow-Timer header field for proxy-to-proxy
heartbeats is unspecified.
OPEN ISSUE: It still needs to be discuss whether it should be
possible to negotiate that the sending of keep-alives between proxies
continue after the dialog, for which the keep-alives were negotiated,
has been terminated.
6. Overlap with connection reuse
The connect-reuse specification [I-D.ietf-sip-connect-reuse] The connect-reuse specification [I-D.ietf-sip-connect-reuse]
specifies how to use connection-oriented transports to send requests specifies how to use connection-oriented transports to send requests
in the reverse direction. SIP entity A opens a connection to entity in the reverse direction. SIP entity A opens a connection to entity
B in order to send a request. Under certain conditions entity B can B in order to send a request. Under certain conditions entity B can
reuse that connection for sending requests in the backwards direction reuse that connection for sending requests in the backwards direction
to A as well. However, the connect-reuse specification does not to A as well. However, the connect-reuse specification does not
define a keep-alive mechanism for this connection. define a keep-alive mechanism for this connection.
The technique specified in this draft is thus orthogonal to the The technique specified in this draft is thus orthogonal to the
purpose of connection reuse. An entity that wants to use connection- purpose of connection reuse. An entity that wants to use connection-
reuse as well as indicate keep-alive mechanism on that connection reuse as well as indicate keep-alive mechanism on that connection
will insert both the "alias" parameter defined in [connect-reuse] as will insert both the "alias" parameter defined in
well as the "keep" parameter defined in this memo. Inserting only [I-D.ietf-sip-connect-reuse] as well as the "keep" header field
one of these parameters is not a substitute for the other. Thus, parameter defined in this specification. Inserting only one of these
while the presence of a "keep" parameter will indicate that the enity parameters is not a substitute for the other. Thus, while the
supports keep-alives in order to keep the connection open, no presence of a "keep" parameter will indicate that the enity supports
inference can be drawn on whether that connection can be used for keep-alives in order to keep the connection open, no inference can be
requests in the backwards direction. drawn on whether that connection can be used for requests in the
backwards direction.
9. Examples 7. Examples
7.1. Example: Keep-alive negotiation for registration
9.1. Example with keep-alive negotiation during registration The figure shows an example where the UAC sends a REGISTER request.
The UAC inserts a "keep" parameter in its Contact header field, to
indicate that it is willing to send keep-alives during the liftime of
the registration.
The figure shows an example where a UAC sends an REGISTER request, in The edge proxy (P1) supports the receiving of keep-alives, so it
which it indicates support of keep-alive by inserting a "keep" inserts a "keep" parameter in its Path header field of the REGISTER
parameter in the Via header of the REGISTER request. The edge proxy response that it forwards towards the UAC. In addition, the edge
(P1) also supports the keep-alive mechanism, so it adds a "yes" value proxy inserts a Flow-Timer header field in the response. The header
to the "keep" parameter to the Via header of the UAC. The request is field value indicates the server recommended keep-alive frequency.
then fowarded towards the registrar. When the UAC receives the 200
OK (REGISTER) response from the registrar it finds out that the edge
proxy supports keep-alive. After that the UAC sends periodic keep-
alives (in this example using the STUN keep-alive technique) during
the duration of the registration. The edge proxy (P1) has inserted a
Flow-Timer header in the 200 OK (REGISTER) response, indicating a
recommented keep-alive interval of 30 seconds.
UAC P1 REGISTRAR When the UAC receives the REGISTER response, and detects that the
edge proxy supports the receiving of keep-alives, it starts to send
periodic keep-alives (in this example using the STUN keep-alive
technique)
UAC P1 (Edge Proxy) REGISTRAR
| | | | | |
|--- REGISTER------------->| | |--- REGISTER------------->| |
| Via: UAC;keep | | | Contact: UAC;keep | |
| |--- REGISTER-------------->| | |--- REGISTER-------------->|
| | Via: UAC;keep=yes | | | Path: P1 |
| | Via: P1 | | | Contact: UAC;keep |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: UAC;keep=yes | | | Path: P1 |
| | Via: P1 | | | Contact: UAC;keep |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: UAC;keep=yes | | | Path: P1;keep | |
| Contact: UAC;keep | |
| Flow-Timer: 30 | | | Flow-Timer: 30 | |
| | | | | |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
skipping to change at page 7, line 48 skipping to change at page 10, line 4
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
Figure 1: Example call flow Figure 1: Example call flow
9.2. Example with keep-alive negotiation during session establishment 7.2. Example: Keep-alive negotiation for dialog from UA
The figure shows an example where a non-registered UAC sends an The figure shows an example where the UAC sends an INVITE request.
INVITE request, in which it indicates support of keep-alive by The UAC inserts a "keep" parameter in its Contact header field, to
inserting a "keep" parameter in the Via header of the INVITE request. indicate that it is willing to send keep-alives during the lifetime
The edge proxy (P1) also supports the keep-alive mechanism, so it of the dialog.
adds a "yes" value to the "keep" parameter to the Via header of the
UAC. The request is then fowarded towards the UAS. When the UAC
receives the 200 OK (INVITE) response from the UAS it finds out that
the edge proxy supports keep-alive. After that the UAC sends
periodic keep-alives (in this example using the STUN keep-alive
technique) during the duration of the call. The edge proxy (P1) has
inserted a Flow-Timer header in the 200 OK (INVITE) response,
indicating a recommented keep-alive interval of 30 seconds.
UAC P1 UAS The edge proxy (P1) supports the receiving of keep-alives, so it
inserts a "keep" parameter in its Record-Route header field of the
INVITE response that it forwards towards the UAC. In addition, the
edge proxy inserts a Flow-Timer header field in the response. The
header field value indicates the server recommended keep-alive
frequency.
When the UAC receives the INVITE response, and detects that the edge
proxy supports the receiving of keep-alives, it starts to send
periodic keep-alives (in this example using the STUN keep-alive
technique)
UAC P1 (Edge Proxy) Remote SIP network
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Via: UAC;keep | | | Contact: UAC;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: UAC;keep=yes | | | Record-Route: P1 |
| | Via: P1 | | | Contact: UAC;keep |
| | |
| | |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: UAC;keep=yes | | | Record-Route: P1 |
| | Via: P1 | | | Contact: UAS |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Via: UAC;keep=yes | | | Record-Route: P1;keep | |
| Contact: UAS | |
| Flow-Timer: 30 | | | Flow-Timer: 30 | |
| | | | | |
|--- ACK ----------------->| | |--- ACK ----------------->| |
| | | | | |
| |--- ACK ------------------>| | |--- ACK ------------------>|
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
skipping to change at page 9, line 44 skipping to change at page 11, line 46
| | | | | |
|--- BYE ----------------->| | |--- BYE ----------------->| |
| | | | | |
| |--- BYE ------------------>| | |--- BYE ------------------>|
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | | | | |
Figure 2: Example call flow Figure 2: Example call flow
10. Security Considerations 7.3. Example: Keep-alive negotiation for dialog to UA
11. IANA Considerations The figure shows an example where P1 (edge proxy) forwards an INVITE
11.1. IANA Registration of the SIP Via keep parameter request towards the UAS. P1 inserts a "keep" parameter in its
Record-Route header field, to indicate that it is willing to receive
keep-alives during the lifetime of the dialog. In addition, the edge
proxy inserts a Flow-Timer header field in the response. The header
field value indicates the server recommended keep-alive frequency.
12. Acknowledgements The UAS is willing to send keep-alives, so it inserts a "keep"
parameter in its Contact header field of the INVITE 200 (OK)
response. In addition, the edge proxy inserts a Flow-Timer header
field in the response. The header field value indicates the server
recommended keep-alive frequency. After that the UAS starts to send
periodic keep-alives (in this example using the STUN keep-alive
technique)
Remote SIP network P1 (Edge Proxy) UAS
| | |
|--- INVITE -------------->| |
| Contact: UAC | |
| |--- INVITE --------------->|
| | Record-Route: P1;keep |
| | Contact: UAC |
| | Flow-Timer: 30 |
| | |
| | |
| | |
| |<-- 200 OK ----------------|
| | Record-Route: P1;keep |
| | Contact: UAS;keep |
|<-- 200 OK ---------------| |
| Record-Route: P1;keep | |
| Contact: UAS;keep | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
| |<== STUN request ==========|
| |=== STUN response ========>|
| | |
| *** Timeout *** |
| | |
| |<== STUN request ==========|
| |=== STUN response ========>|
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer Figure 3: Example call flow
and Milo Orsic for their comments on the initial draft. Thanks to
Juha Heinaenen, Jiri Kuthan and Dean Willis for their comments on the
list. Thanks to Vijay Gurbani for providing text about the
relationship with the connect-reuse specification.
13. References 8. Security Considerations
9. IANA Considerations
13.1. Normative References 9.1. IANA Registration of the SIP header field keep parameter
10. Acknowledgements
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean
Schneyer, Milo Orsic, John Elwell and Ya-Ching Tan for their comments
on the initial draft. Thanks to Juha Heinaenen, Jiri Kuthan and Dean
Willis for their comments on the list. Thanks to Vijay Gurbani for
providing text about the relationship with the connect-reuse
specification.
11. References
11.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, [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
A., Peterson, J., Sparks, R., Handley, M., and E. (SIP) Extension Header Field for Registering Non-Adjacent
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Contacts", RFC 3327, December 2002.
June 2002.
13.2. Informative References [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[I-D.ietf-sip-outbound] [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Jennings, C., "Managing Client Initiated Connections in Initiated Connections in the Session Initiation Protocol
the Session Initiation Protocol (SIP)", (SIP)", RFC 5626, October 2009.
draft-ietf-sip-outbound-20 (work in progress), June 2009.
[I-D.ietf-behave-rfc3489bis] 11.2. Informative References
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 2008.
[I-D.ietf-sip-connect-reuse] [I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress), draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009. August 2009.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
 End of changes. 60 change blocks. 
238 lines changed or deleted 404 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/