SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track April 15, 2010
Expires: October 17, 2010
Indication of support for keep-alive
draft-ietf-sipcore-keep-02.txt
Abstract
This specification defines a new Session Initiation Protocol (SIP)
header field parameter, "keep", that SIP entities can use to
negotiate explicit support of the NAT keep-alive mechanisms defined
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
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). 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
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."
This Internet-Draft will expire on October 17, 2010.
Copyright Notice
Copyright (c) 2010 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
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
Holmberg Expires October 17, 2010 [Page 1]
Internet-Draft STUN-keep April 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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
4. User agent behavior . . . . . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. User agent client behavior . . . . . . . . . . . . . . . . 5
4.2.1. Keep-alive negotiation for registration . . . . . . . 5
4.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 5
4.3. User agent server behavior . . . . . . . . . . . . . . . . 6
4.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 6
4.4. Keep-alive frequency . . . . . . . . . . . . . . . . . . . 6
5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Edge proxy behavior . . . . . . . . . . . . . . . . . . . 7
5.2.1. Keep-alive negotiation for registration . . . . . . . 7
5.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 7
5.3. Proxy behavior for proxy-to-proxy heartbeats . . . . . . . 7
5.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 7
6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8
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
Holmberg Expires October 17, 2010 [Page 2]
Internet-Draft STUN-keep April 2010
1. Introduction
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive
mechanisms. Eventhough the keep-alive mechanisms are separated from
the rest of the SIP Outbound mechanism, it is currently not possible
to explicitly negotiate the usage of keep-alives, since the keep-
alives are implicitly negotiated as part of the SIP Outbound
negotation.
However, there are also SIP Outbound use-cases where the keep-alives
are not implicitly negotiated as part of the SIP Outbound
negotiation, and therefor an explicit keep-alive negotiation
mechanism is needed. In addition, there are use-cases where SIP
Outbound is not supported, or where it cannot be applied, but where
there is still a need to be able to negotiate the usage of keep-
alives.
This specification defines a new SIP header field parameter, "keep",
that SIP entities can use to negotiate support of the NAT keep-alive
mechanisms defined in the SIP Outbound specification [RFC5626]. The
parameter is defined for cases where the SIP Outbound mechanism is
not supported, or in cases where it cannot be applied. The usage of
keep-alives can be negotiated as part of a registration, or as part
of a dialog.
The following sections describe use-cases where a mechanism to
explicitly negotiate the usage of keep-alives is needed.
1.1. Use-case: Calls from non-registered UAs
In some cases a UA does not register itself before making a call, but
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.
Holmberg Expires October 17, 2010 [Page 3]
Internet-Draft STUN-keep April 2010
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
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].
3. Definitions
Edge proxy: As defined in [RFC5626], a SIP proxy that is located
topologically between the registering User Agent (UA) and the
Authoritative Proxy.
Keep-alives: Refers to keep-alive messages using the mechanisms
define defined in the SIP Outbound specification [RFC5626].
"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.
4. User agent behavior
4.1. General
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 UA will only send keep-alives towards its edge proxy, and MUST NOT
expect to receive edge proxy initiated keep-alives.
A UA that supports keep-alives MUST insert a "keep" parameter in its
Contact header field even if it also indicates support of SIP
Outbound [RFC5626], in order to be able to negotiate the usage of
keep-alives also in cases where the edge proxy only supports keep-
alives, but not the other parts of SIP Outbound.
Holmberg Expires October 17, 2010 [Page 4]
Internet-Draft STUN-keep April 2010
As defined in [RFC5626], a UA that supports keep-alives MUST act as a
Session Traversal Utilities for NAT (STUN) client [RFC5389]. The UA
MUST support the amount of STUN which is required to apply the STUN
keep-alive mechanism defined in [RFC5626], and the UA MUST support
the CRLF keep-alive mechanism defined in [RFC5626]. In addition, as
defined in [RFC5389], the UAC MUST be able to process the SIP Path
header [RFC3327], in order to detect whether the edge proxy supports
keep-alives.
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
does not forbid the sending of CRLF keep-alives even an edge proxy
has not indicated support of keep-alives using the "keep" parameter.
However, the "keep" parameter is still important in order for the UA
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
registration refresh intervals) in order to make sure the NAT
bindings are kept open.
4.2. User agent client behavior
4.2.1. Keep-alive negotiation for registration
When a UAC sends a REGISTER request for a new registration, if the
UAC is willing to send keep-alives associated with the registration,
it MUST insert a "keep" parameter in its Contact header field of the
REGISTER request.
When the UAC receives the REGISTER response, if the top-most Path
header field (edge proxy) of the response contains a "keep"
parameter, the UAC MUST start to send keep-alives towards the edge
proxy, and it MUST send keep-alives for the remaining duration of the
registration. When the registration is terminated, the UAC MUST
cease the sending of keep-alives negotiated for the registration.
4.2.2. Keep-alive negotiation for dialog
When a UAC sends an initial request (e.g. a SIP INVITE request) for a
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.
Holmberg Expires October 17, 2010 [Page 5]
Internet-Draft STUN-keep April 2010
When the UAC receives the response(s) to the initial request for the
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.
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].
Holmberg Expires October 17, 2010 [Page 6]
Internet-Draft STUN-keep April 2010
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
Holmberg Expires October 17, 2010 [Page 7]
Internet-Draft STUN-keep April 2010
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]
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
[I-D.ietf-sip-connect-reuse] as well as the "keep" header field
parameter defined in this specification. 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.
7. Examples
Holmberg Expires October 17, 2010 [Page 8]
Internet-Draft STUN-keep April 2010
7.1. Example: Keep-alive negotiation for 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 edge proxy (P1) supports the receiving of keep-alives, so it
inserts a "keep" parameter in its Path header field of the REGISTER
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 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------------->| |
| Contact: UAC;keep | |
| |--- REGISTER-------------->|
| | Path: P1 |
| | Contact: UAC;keep |
| | |
| |<-- 200 OK ----------------|
| | Path: P1 |
| | Contact: UAC;keep |
|<-- 200 OK ---------------| |
| Path: P1;keep | |
| Contact: UAC;keep | |
| Flow-Timer: 30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Holmberg Expires October 17, 2010 [Page 9]
Internet-Draft STUN-keep April 2010
Figure 1: Example call flow
7.2. Example: Keep-alive negotiation for dialog from UA
The figure shows an example where the UAC sends an INVITE request.
The UAC inserts a "keep" parameter in its Contact header field, to
indicate that it is willing to send keep-alives during the lifetime
of the dialog.
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)
Holmberg Expires October 17, 2010 [Page 10]
Internet-Draft STUN-keep April 2010
UAC P1 (Edge Proxy) Remote SIP network
| | |
|--- INVITE -------------->| |
| Contact: UAC;keep | |
| |--- INVITE --------------->|
| | Record-Route: P1 |
| | Contact: UAC;keep |
| | |
| | |
| | |
| |<-- 200 OK ----------------|
| | Record-Route: P1 |
| | Contact: UAS |
|<-- 200 OK ---------------| |
| Record-Route: P1;keep | |
| Contact: UAS | |
| Flow-Timer: 30 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Figure 2: Example call flow
7.3. Example: Keep-alive negotiation for dialog to UA
The figure shows an example where P1 (edge proxy) forwards an INVITE
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
Holmberg Expires October 17, 2010 [Page 11]
Internet-Draft STUN-keep April 2010
proxy inserts a Flow-Timer header field in the response. The header
field value indicates the server recommended keep-alive frequency.
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)
Holmberg Expires October 17, 2010 [Page 12]
Internet-Draft STUN-keep April 2010
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 ----------------|
| | |
Figure 3: Example call flow
8. Security Considerations
Holmberg Expires October 17, 2010 [Page 13]
Internet-Draft STUN-keep April 2010
9. IANA Considerations
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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
11.2. Informative References
[I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
Holmberg Expires October 17, 2010 [Page 14]
Internet-Draft STUN-keep April 2010
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires October 17, 2010 [Page 15]
