SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track O. Gallego
Expires: December 23, 2012 Vodafone
June 21, 2012
Indication of support for reverse keep-alive
draft-holmberg-sipcore-rkeep-00.txt
Abstract
This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "rkeep". The "rkeep" parameter allows a
SIP entity to indicate willingness to receive keep-alives from its
adjacent downstream SIP entity, the adjacent downstream SIP entity to
indicate willingness to send keep-alives, and for SIP entities
willing to send keep-alives to inform the receiver about the keep-
alive frequency.
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 December 23, 2012.
Copyright Notice
Copyright (c) 2012 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
Holmberg & Gallego Expires December 23, 2012 [Page 1]
Internet-Draft reverse keep-alive June 2012
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use-case: UA not able to send keep-alives due to sleep
mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. User Agent and Proxy behavior . . . . . . . . . . . . . . . . . 4
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Lifetime of keep-alives . . . . . . . . . . . . . . . . . . 4
5.3. Behavior of a SIP entity willing to receive keep-alives . . 5
5.4. Behavior of a SIP entity willing to send keep-alives . . . 6
6. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 7
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9.1. rkeep . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Holmberg & Gallego Expires December 23, 2012 [Page 2]
Internet-Draft reverse keep-alive June 2012
1. Introduction
RFC 6263 [RFC6263] defines a mechanism, which allows adjacent SIP
entities to explicitly negotiate usage of the NAT keep-alive
mechanisms defined in SIP Outbound [RFC5626]. The "keep" parameter
[RFC6263] allows SIP entities, when sending a request, to indicate
willingness to send keep-alives, and it allows SIP entities, when
sending a response, indicate willingness to receive keep-alives.
In some cases a SIP device, located behind a NAT, is not able to send
keep-alives. One reason can be that the scheduling policy of the
operating system used by the SIP device does not meet the requirement
for sending keep-alives using a proper frequency, meaning that NAT
bindings might not be kept. In such cases, the device needs to
request another device to send keep-alives towards the itself. Then,
the keep-alive response message sent from the SIP device will ensure
that the NAT binding is kept open.
This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter [RFC3261], "rkeep". The "rkeep" parameter
allows a SIP entity to indicate willingness to receive keep-alives
from its adjacent downstream SIP entity, the adjacent downstream SIP
entity to indicate willingness to send keep-alives, and for SIP
entities willing to send keep-alives to inform the receiver about the
keep-alive frequency.
The following sections describe use-cases where a mechanism to
explicitly negotiate usage of keep-alives is needed.
1.1. Use-case: UA not able to send keep-alives due to sleep mode
2. Applicability
The mechanism defined in this specification MUST only be used by SIP
entities that are not able, e.g. because the scheduling policy of the
operating system used by the SIP device does not meet the requirement
for sending keep-alives using a proper frequency.
3. 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 & Gallego Expires December 23, 2012 [Page 3]
Internet-Draft reverse keep-alive June 2012
4. Definitions
Keep-alives: The keep-alive messages defined in RFC 5626.
"rkeep" parameter: A SIP Via header field parameter that a SIP entity
can insert in the topmost Via header field that it adds to the
request, to explicitly indicate willingness to receive keep-alives
from its adjacent downstream SIP entity. A SIP entity can add a
parameter value to the "rkeep" parameter, or remove an existing
parameter value, in a response to explicitly indicate willingness to
send keep-alives to its adjacent upstream SIP entity.
SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
Adjacent downstream SIP entity: The adjacent SIP entity in the
direction towards which a SIP request is sent.
Adjacent upstream SIP entity: The adjacent SIP entity in the
direction from which a SIP request is received.
5. User Agent and Proxy behavior
5.1. General
This section describes how SIP UAs and proxies negotiate usage of
keep-alives associated with a registration, or a dialog, which types
of SIP requests can be used in order to negotiate the usage, and the
lifetime of the negotiated keep-alives.
SIP entities indicate willingness to receive keep-alives from the
adjacent downstream SIP entity using SIP requests. The associated
responses are used by SIP entities to indicate willingness to send
keep-alives. Both SIP entities can indicate a recommended keep-alive
frequency.
The procedures to negotiate usage of keep-alives are identical for
SIP UAs and proxies.
NOTE: Usage of keep-alives is negotiated per direction. If a SIP
entity has indicated willingness to receive keep-alives from an
adjacent SIP entity, sending of keep-alives towards that adjacent SIP
entity needs to be separately negotiated.
5.2. Lifetime of keep-alives
The lifetime of negotiated keep-alives depends on whether the keep-
alives are associated with a registration or a dialog. The rules
Holmberg & Gallego Expires December 23, 2012 [Page 4]
Internet-Draft reverse keep-alive June 2012
defined in RFC 6223 [RFC6223] also apply when keep-alives are
negotiated using the 'rkeep' Via header field parameter.
5.3. Behavior of a SIP entity willing to receive keep-alives
As defined in RFC 5626, a SIP entity that supports receiving of keep-
alives must act as a STUN server [RFC5389]. The SIP entity must
support those aspects of STUN that are required in order to apply the
STUN keep-alive mechanism defined in RFC 5626, and it must support
the CRLF keep-alive mechanism defined in RFC 5626.
When a SIP entity sends or forwards a request, if it wants to
negotiate the receiving of keep-alives associated with a
registration, or a dialog, it MUST insert a "rkeep" parameter in the
topmost Via header field that it adds to the request, to indicate
willingness to receive keep-alives. The SIP entity MAY add a
parameter value to the "rkeep" parameter before sending or forwarding
the request. The parameter value, if present and with a value other
than zero, represents a recommended keep-alive frequency, given in
seconds.
When the SIP entity receives the associated response, if the "rkeep"
parameter in the topmost Via header field of the response contains a
"rkeep" parameter value with a non-zero value, or a value which is
different from the value sent in the request (counting a "rkeep"
parameter without a value) it MUST be prepared to start receiving
keep-alives from the same destination from where it received the
response which was used to negotiate the receiving of keep-alives.
If the "rkeep" parameter does not contain a value, the SIP entity
MUST assume that keep-alives will be sent using the recommended keep-
alive frequency, if any, that the SIP entity added to the associated
request.
If the associated response contains the same "rkeep" parameter value
as the request (counting a "rkeep" parameter without a value), the
SIP entity MUST assume that keep-alives will not be sent.
Once a SIP entity has negotiated receiving of keep-alives associated
with a dialog towards an adjacent SIP entity, it MUST NOT insert a
"rkeep" parameter in any subsequent SIP requests, associated with the
dialog, towards that adjacent SIP entity. Such "rkeep" parameter
MUST be ignored, if received.
Since an ACK request does not have an associated response, it can not
be used to negotiate usage of keep-alives. Therefore, a SIP entity
MUST NOT insert a "rkeep" parameter in the topmost Via header field
of an ACK request. Such "rkeep" parameter MUST be ignored, if
received.
Holmberg & Gallego Expires December 23, 2012 [Page 5]
Internet-Draft reverse keep-alive June 2012
A SIP entity MUST NOT indicates willingness to receive keep-alives
associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261].
If an INVITE request is used to indicate willingness to receive keep-
alives, as long as at least one response (provisional or final) to
the INVITE request contains a "rkeep" parameter with a parameter
value which is different from the value in the request (counting a
"rkeep" parameter without a value) it is seen as an indication that
the adjacent downstream SIP entity is willing to send keep-alives
associated with the dialog on which the response is received.
5.4. Behavior of a SIP entity willing to send keep-alives
As defined in RFC 5626, a SIP entity that supports sending of keep-
alives must act as a Session Traversal Utilities for NAT (STUN)
client [RFC5389]. The SIP entity must support those aspects of STUN
that are required in order to apply the STUN keep-alive mechanism
defined in RFC 5626, and it must support the CRLF keep-alive
mechanism defined in RFC 5626. RFC 5626 defines when to use STUN,
respectively double-CRLF, for keep-alives.
When a SIP entity sends or forwards a response, and the adjacent
upstream SIP entity indicated willingness to receive keep-alives
without a recommended keep-alive frequency, if the SIP entity is
willing to send keep-alives associated with the registration, or the
dialog, to the adjacent upstream SIP entity it MUST add a parameter
value to the "rkeep" parameter, before sending or forwarding the
response. The parameter value, represents the keep-alive frequency,
given in seconds, that the sender of the keep-alives will use.
If the adjacent upstream SIP entity provided a recommended keep-alive
frequency, and if the SIP entity is willing to send keep-alives using
that frequency, it MUST remove the "rkeep" parameter value which
indicates the recommended keep-alive frequency, before sending or
forwarding the response.
NOTE: The reason for removing the "rkeep" parameter value is to
indicate that the SIP entity supports the mechanism, and simply does
not forward an unknown parameter.
If the adjacent upstream SIP entity provided a recommended keep-alive
frequency, and if the SIP entity is willing to send keep-alives using
a different frequency, it MUST modify the "rkeep" parameter value
which indicates the recommended keep-alive frequency, before sending
or forwarding the response.
There might be multiple responses to an INVITE request. When a SIP
Holmberg & Gallego Expires December 23, 2012 [Page 6]
Internet-Draft reverse keep-alive June 2012
entity indicates willingness to send keep-alives in a response to an
INVITE request, it MUST add a parameter value to the "rkeep"
parameter in at least one reliable response to the request. The SIP
entity MAY add identical parameter values to the "rkeep" parameters
in other responses to the same request. The SIP entity MUST NOT add
different parameter value to the "rkeep" parameters in responses to
the same request. The SIP entity SHOULD indicate the willingness to
send keep-alives as soon as possible.
A SIP entity MUST NOT indicates willingness to send keep-alives
associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261].
When the SIP entity has indicated willingness to send keep-alives, it
MUST start sending keep-alives towards the same destination where it
sent the response used to indicate willingness to send keep-alives.
6. Keep-alive frequency
If a SIP entity sends a SIP response, where the topmost Via header
field contains a "rkeep" parameter with a non-zero value that
indicates the keep-alive frequency, given in seconds, it MUST use the
procedures defined for the Flow-Timer header field [RFC5626].
According to the procedures, the SIP entity must send keep-alives at
least as often as the indicated keep-alive frequency, and if the SIP
entity uses the indicated keep-alive frequency then it should send
its keep-alives so that the interval between each keep-alive is
randomly distributed between 80% and 100% of the indicated keep-alive
frequency.
This specification does not define any semantic for a "rkeep" Via
header parameter value with a zero value. A SIP entity MUST NOT
insert a zero value to a "rkeep" parameter. A SIP entity that
receives a "rkeep" parameter with a zero value SHOULD NOT assume that
the sender of the response will send keep-alives towards the SIP
entity.
This specification does not specify actions to take if negotiated
keep-alives are not received. As defined in RFC 5626, the receiving
SIP entity may consider a connection to be dead in such situations.
NOTE: The Flow-Timer header field [RFC5626] has no impact on keep-
alives negotiated using the "rkeep" Via header field parameter.
Holmberg & Gallego Expires December 23, 2012 [Page 7]
Internet-Draft reverse keep-alive June 2012
7. Examples
8. Grammar
8.1. General
This section describes the syntax extensions to the ABNF syntax
defined in RFC 3261, by defining a new Via header field parameter,
"rkeep". The ABNF defined in this specification is conformant to RFC
5234 [RFC5234].
8.2. ABNF
via-params =/ rkeep
rkeep = "rkeep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations
9.1. rkeep
This specification defines a new Via header field parameter called
keep in the "Header Field Parameters and Parameter Values" sub-
registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8. The required information is:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via rkeep No [RFCXXXX]
10. Security Considerations
The Security Considerations in RFC 6223 apply.
11. Acknowledgements
Holmberg & Gallego Expires December 23, 2012 [Page 8]
Internet-Draft reverse keep-alive June 2012
12. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-rkeep-xx
o TBA
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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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.
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive",
RFC 6223, April 2011.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011.
13.2. Informative References
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
Holmberg & Gallego Expires December 23, 2012 [Page 9]
Internet-Draft reverse keep-alive June 2012
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Oscar Gallego
Vodafone
One Kingdom Street, Paddington Central
London W2 6BY
UK
Email: oscar.gallego@vodafone.com
Holmberg & Gallego Expires December 23, 2012 [Page 10]