draft-ietf-sipcore-keep-07.txt   draft-ietf-sipcore-keep-08.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track October 13, 2010 Intended status: Standards Track October 19, 2010
Expires: April 16, 2011 Expires: April 22, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-07.txt draft-ietf-sipcore-keep-08.txt
Abstract Abstract
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "keep", which allows adjacent SIP Via header field parameter, "keep", which allows adjacent SIP
entities to explicitly negotiate usage of the Network Address entities to explicitly negotiate usage of the Network Address
Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in
cases where SIP Outbound is not supported, cannot be applied, or cases where SIP Outbound is not supported, cannot be applied, or
where usage of keep-alives is not implicitly negotiated as part of where usage of keep-alives is not implicitly negotiated as part of
the SIP Outbound negotiation. the SIP Outbound negotiation.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 16, 2011. This Internet-Draft will expire on April 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.2.2. Keep-alives associated with registration . . . . . . . 5 4.2.2. Keep-alives associated with registration . . . . . . . 5
4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6 4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6
4.3. Behavior of a SIP entity willing to send keep-alives . . . 6 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6
4.4. Behavior of a SIP entity willing to receive keep-alives . 7 4.4. Behavior of a SIP entity willing to receive keep-alives . 7
5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8
6. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9 6. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Keep-alive negotiation associated with registration: 7.2. Keep-alive negotiation associated with registration:
UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 10
7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 17
skipping to change at page 6, line 13 skipping to change at page 6, line 13
can be negotiated when the registration is established, or later can be negotiated when the registration is established, or later
during the registration. Once negotiated, keep-alives are sent until during the registration. Once negotiated, keep-alives are sent until
the registration is terminated, or until a subsequent registration the registration is terminated, or until a subsequent registration
refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded. When a subsequent registration
refresh request is sent or forwarded, if a SIP entity is willing to refresh request is sent or forwarded, if a SIP entity is willing to
continue sending keep-alives associated with the registration, usage continue sending keep-alives associated with the registration, usage
of keep-alives MUST be re-negotiated. If usage is not successfully of keep-alives MUST be re-negotiated. If usage is not successfully
re-negotiated, the SIP entity MUST cease sending of keep-alives re-negotiated, the SIP entity MUST cease sending of keep-alives
associated with the registration. associated with the registration.
In case a SIP entity establishes multiple registration flows
[RFC5626], usage of keep-alives needs to be negotiated separately for
each individual registration flow. A SIP entity MUST NOT send keep-
alives associated with a registration flow for which usage of keep-
alives has not been negotiated.
4.2.3. Keep-alives associated with dialog 4.2.3. Keep-alives associated with dialog
SIP entities use an initial request for a dialog, or a mid-dialog SIP entities use an initial request for a dialog, or a mid-dialog
target refresh request [RFC3261], in order to negotiate sending and target refresh request [RFC3261], in order to negotiate sending and
receiving of keep-alives associated with a dialog. Usage of keep- receiving of keep-alives associated with a dialog. Usage of keep-
alives can be negotiated when the dialog is established, or later alives can be negotiated when the dialog is established, or later
during the lifetime of the dialog. Once negotiated, keep-alives MUST during the lifetime of the dialog. Once negotiated, keep-alives MUST
be sent for the lifetime of the dialog, until the dialog is be sent for the lifetime of the dialog, until the dialog is
terminated. Once usage of keep-alives associated with a dialog has terminated. Once usage of keep-alives associated with a dialog has
been negotiated, it is not possible to re-negotiate the usage been negotiated, it is not possible to re-negotiate the usage
skipping to change at page 14, line 50 skipping to change at page 14, line 50
|--- BYE --------------------------------------------->| |--- BYE --------------------------------------------->|
| | | |
|<-- 200 OK -------------------------------------------| |<-- 200 OK -------------------------------------------|
| | | |
Figure 3: Example call flow Figure 3: Example call flow
8. Grammar 8. Grammar
This specification defines a new Via header field parameter, "keep". This specification defines a new Via header field parameter, "keep".
The grammar includes the definitions from [RFC5626].
The ABNF [RFC5234] is: The ABNF [RFC5234] is:
via-params =/ keep via-params =/ keep
keep = "keep" [ EQUAL 1*(DIGIT) ] keep = "keep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations 9. IANA Considerations
9.1. keep 9.1. keep
This specification defines a new Via header field parameter called This specification defines a new Via header field parameter called
keep in the "Header Field Parameters and Parameter Values" sub- keep in the "Header Field Parameters and Parameter Values" sub-
registry as per the registry created by [RFC5626]. The syntax is registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8. The required information is: defined in Section 8. The required information is:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- --------- ---------------------- --------------------- ---------- ---------
Via keep No [RFCXXXX] Via keep No [RFCXXXX]
10. Security Considerations 10. Security Considerations
SIP entities that send or receive keep-alives are often required to SIP entities that send or receive keep-alives are often required to
skipping to change at page 16, line 25 skipping to change at page 16, line 22
and Milo Orsic for their comments on the initial draft. Thanks to and Milo Orsic for their comments on the initial draft. Thanks to
Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat,
Peter Musgrave, Dale Worley and Adam Roach for their comments on the Peter Musgrave, Dale Worley and Adam Roach for their comments on the
list. Thanks to Vijay Gurbani for providing text about the list. Thanks to Vijay Gurbani for providing text about the
relationship with the connect reuse specification. relationship with the connect reuse specification.
12. Change Log 12. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-keep-07
o Last paragraph of section 4.2.2 removed
o Reference correction
Changes from draft-ietf-sipcore-keep-06 Changes from draft-ietf-sipcore-keep-06
o New text added to the security considerations o New text added to the security considerations
Changes from draft-ietf-sipcore-keep-05 Changes from draft-ietf-sipcore-keep-05
o New section about connection reuse added o New section about connection reuse added
o Clarify that the specification does not define a mechanism for o Clarify that the specification does not define a mechanism for
connection reuse connection reuse
o New text added to the security considerations o New text added to the security considerations
o CRLF changed to double-CRLF in some places o CRLF changed to double-CRLF in some places
skipping to change at page 17, line 15 skipping to change at page 17, line 15
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
13.2. Informative References 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.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", RFC 5923, the Session Initiation Protocol (SIP)", RFC 5923,
June 2010. June 2010.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 9 change blocks. 
13 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/