SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Informational December 1, 2009
Expires: June 4, 2010
Indication of support for keep-alive
draft-ietf-sipcore-keep-01.txt
Abstract
This specification defines a new SIP Via header parameter, "keep"
which SIP entities can use to indicate support of the NAT keep-alive
techniques defined in SIP Outbound, in cases where the Outbound
procedures are not supported or cannot be applied.
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Holmberg Expires June 4, 2010 [Page 1]
Internet-Draft STUN-keep December 2009
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4
6. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5
7. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Overlap with connection reuse . . . . . . . . . . . . . . . . 6
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Example with keep-alive negotiation during registration . 7
9.2. Example with keep-alive negotiation during session
establishment . . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11.1. IANA Registration of the SIP Via keep parameter . . . . . 10
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Holmberg Expires June 4, 2010 [Page 2]
Internet-Draft STUN-keep December 2009
1. Introduction
Chapter 3.5 of [I-D.ietf-sip-outbound] defines two keep-alive
techniques. Even though the keep-alive techniques are separated from
the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not
possible to indicate support of the keep-alive techniques without
also indicating support for the Outbound mechanism. In addition, as
described in [I-D.ietf-sip-outbound], for dialog initiated outbound
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 use-cases where the UA does not register itself,
but still needs to be able to make calls and maintain NAT bindings
open during the duration of that call. A typical example is
emergency calls. There are also cases where entities do not support
the Outbound mechanism, but still want to be able to indicate support
and use the keep-alive techniques defined in [I-D.ietf-sip-outbound].
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
perform heartbeats between themselves. The keep-alive techniqurs
defined in [I-D.ietf-sip-outbound] can be used for providing the
heartbeats, and the mechanism in this document can be used by the
entities to indicate and negotiate support of the keep-alive
techniques.
This specification defines a new SIP Via header parameter, "keep",
which can be used by a UA to indicate support of the keep-alive
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"
parameter. The edge proxy will add a "yes" value to the "keep"
parameter, if received in the topmost Via header, to indicate support
of the keep-alive techniques defined in [I-D.ietf-sip-outbound].
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Holmberg Expires June 4, 2010 [Page 3]
Internet-Draft STUN-keep December 2009
3. Definitions
Edge proxy: As defined in [I-D.ietf-sip-outbound], an Edge Proxy is
any proxy that is located topologically between the registering User
Agent and the Authoritative Proxy. The "first" edge proxy refers to
the first edge proxy encountered when a UA sends a request.
'keep' Parameter: The 'keep' parameter is a SIP Via header parameter
which indicates that the entity inserting the parameter supports the
keep-alive techniques defined in [I-D.ietf-sip-outbound]. The
parameter may carry an associated parameter value.
4. Requirements
REQ 1: It MUST be possible for a SIP entity acting as a UAC to
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
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
A SIP entity aciting as a UAC which supports the method defined in
this specification MUST act as a STUN client
[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
method defined in this specification sends a SIP REGISTER request,
and the UAC wants to send keep-alives towards the next hop, the
entity MUST insert a "keep" Via parameter in the SIP request. If the
Via header in the SIP REGISTER response contains a "keep" parameter
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
Holmberg Expires June 4, 2010 [Page 4]
Internet-Draft STUN-keep December 2009
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
sends an initial SIP request, the UAC has not registered itself via
the edge proxy towards which the SIP request is sent, and the UAC
wants to send keep-alives towards the next hop, the UAC MUST include
a "keep" Via parameter in the SIP request. If the Via header header
in the initial SIP responses contains a "keep" parameter with a "yes"
value, the UA knows that the keep-alive techniques defined in
[I-D.ietf-sip-outbound] can be used between the UAC and the next hop
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
proxies are expected to be able to receive it, this specification
does not forbid the sending of CRLF keep-alives even when no
"keep=yes" indication has been received from the edge proxy.
However, the indicator is still important in order for the client to
inform the edge proxy that the client supports CRLF keep-alives, so
that the edge proxy does not use other mechanisms (e.g. short
registration refresh intervals) in order to make sure the NAT
bindings are kept open.
6. Server behavior
A SIP entity acting as a UAS (UA or proxy) which supports the method
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
recieves a SIP REGISTER request which contains a "keep" parameter in
Holmberg Expires June 4, 2010 [Page 5]
Internet-Draft STUN-keep December 2009
the topmost Via header, and the UAS wants to allow the sender of the
SIP REGISTER request to send keep-alives towards the UAS during the
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
recieves an initial SIP request which contains a "keep" parameter in
the topmost Via header, and the UAS wants to allow the sender of the
initial SIP request to send keep-alives towards the UAS during the
duration of the call, 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 initial SIP response.
7. Proxy behavior
A proxy acting as a UAC, that wants to use the mechanism in this
document, shall follow the procedures defined in Section 5.
A proxy acting as a UAS, that wants to use the mechanism in this
document, shall follow the procedures defined in Section 6.
8. Overlap with connection reuse
The connect-reuse specification [I-D.ietf-sip-connect-reuse]
specifies how to use connection-oriented transports to send requests
in the reverse direction. SIP entity A opens a connection to entity
B in order to send a request. Under certain conditions entity B can
reuse that connection for sending requests in the backwards direction
to A as well. However, the connect-reuse specification does not
define a keep-alive mechanism for this connection.
The technique specified in this draft is thus orthogonal to the
purpose of connection reuse. An entity that wants to use connection-
reuse as well as indicate keep-alive mechanism on that connection
will insert both the "alias" parameter defined in [connect-reuse] as
well as the "keep" parameter defined in this memo. Inserting only
one of these parameters is not a substitute for the other. Thus,
while the presence of a "keep" parameter will indicate that the enity
supports keep-alives in order to keep the connection open, no
inference can be drawn on whether that connection can be used for
requests in the backwards direction.
Holmberg Expires June 4, 2010 [Page 6]
Internet-Draft STUN-keep December 2009
9. Examples
9.1. Example with keep-alive negotiation during registration
The figure shows an example where a UAC sends an REGISTER request, in
which it indicates support of keep-alive by inserting a "keep"
parameter in the Via header of the REGISTER request. The edge proxy
(P1) also supports the keep-alive mechanism, so it adds a "yes" value
to the "keep" parameter to the Via header of the UAC. The request is
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
| | |
|--- REGISTER------------->| |
| Via: UAC;keep | |
| |--- REGISTER-------------->|
| | Via: UAC;keep=yes |
| | Via: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: UAC;keep=yes |
| | Via: P1 |
|<-- 200 OK ---------------| |
| Via: UAC;keep=yes | |
| Flow-Timer: 30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Figure 1: Example call flow
Holmberg Expires June 4, 2010 [Page 7]
Internet-Draft STUN-keep December 2009
9.2. Example with keep-alive negotiation during session establishment
The figure shows an example where a non-registered UAC sends an
INVITE request, in which it indicates support of keep-alive by
inserting a "keep" parameter in the Via header of the INVITE request.
The edge proxy (P1) also supports the keep-alive mechanism, so it
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.
Holmberg Expires June 4, 2010 [Page 8]
Internet-Draft STUN-keep December 2009
UAC P1 UAS
| | |
|--- INVITE -------------->| |
| Via: UAC;keep | |
| |--- INVITE --------------->|
| | Via: UAC;keep=yes |
| | Via: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: UAC;keep=yes |
| | Via: P1 |
|<-- 200 OK ---------------| |
| Via: UAC;keep=yes | |
| Flow-Timer: 30 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Figure 2: Example call flow
10. Security Considerations
11. IANA Considerations
Holmberg Expires June 4, 2010 [Page 9]
Internet-Draft STUN-keep December 2009
11.1. IANA Registration of the SIP Via keep parameter
12. Acknowledgements
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer
and Milo Orsic for their comments on the initial draft. Thanks to
Juha Heinaenen, Jiri Kuthan 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
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
13.2. Informative References
[I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009.
[I-D.ietf-behave-rfc3489bis]
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]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
Holmberg Expires June 4, 2010 [Page 10]
Internet-Draft STUN-keep December 2009
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires June 4, 2010 [Page 11]
