SIP Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Informational October 24, 2008
Expires: April 27, 2009
Indication of support for keep-alive
draft-holmberg-sip-keep-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 27, 2009.
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.
Holmberg Expires April 27, 2009 [Page 1]
Internet-Draft STUN-keep October 2008
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. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11.1. IANA Registration of the SIP Via keep parameter . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Holmberg Expires April 27, 2009 [Page 2]
Internet-Draft STUN-keep October 2008
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 April 27, 2009 [Page 3]
Internet-Draft STUN-keep October 2008
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 support of the keep-alive techniques defined
[I-D.ietf-sip-outbound] towards the next hop, if the UA supports only
the keep-alive part of [I-D.ietf-sip-outbound].
REQ 2: It MUST be possible for a SIP entity acting as a UAS to
indicate support of the keep-alive techniques defined
[I-D.ietf-sip-outbound] towards the previous hop, if the edge poxy
supports only the keep-alive part of [I-D.ietf-sip-outbound].
REQ 3: It MUST be possible for SIP entities which supportthe
proceduers in [I-D.ietf-sip-outbound] to indicate, and negotiate
support of, keep-alives for Outbound dialog flows
[I-D.ietf-sip-outbound].
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
Holmberg Expires April 27, 2009 [Page 4]
Internet-Draft STUN-keep October 2008
[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
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.
OPEN ISSUE: Is there a need to, using initial SIP requests, negotiate
keep-alives for a duration longer than the actual call?
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
Holmberg Expires April 27, 2009 [Page 5]
Internet-Draft STUN-keep October 2008
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
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
Holmberg Expires April 27, 2009 [Page 6]
Internet-Draft STUN-keep October 2008
inference can be drawn on whether that connection can be used for
requests in the backwards direction.
9. Example
The figure shows an example where a non-registered UAC sends an
INVITE reuqest, 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 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), indicating a
recommented keep-alive interval of 30 seconds.
Holmberg Expires April 27, 2009 [Page 7]
Internet-Draft STUN-keep October 2008
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 1: Example call flow
10. Security Considerations
11. IANA Considerations
11.1. IANA Registration of the SIP Via keep parameter
Holmberg Expires April 27, 2009 [Page 8]
Internet-Draft STUN-keep October 2008
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. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008.
[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-12 (work in progress),
October 2008.
Holmberg Expires April 27, 2009 [Page 9]
Internet-Draft STUN-keep October 2008
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires April 27, 2009 [Page 10]
Internet-Draft STUN-keep October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Holmberg Expires April 27, 2009 [Page 11]