idnits 2.17.1 draft-holmberg-sipcore-rkeep-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2014) is 3416 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 378, but not defined ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track O. Gallego 5 Expires: June 19, 2015 Vodafone 6 December 16, 2014 8 Indication of support for reverse keep-alive 9 draft-holmberg-sipcore-rkeep-05.txt 11 Abstract 13 This specification defines a new Session Initiation Protocol (SIP) 14 Via header field parameter, "rkeep". The "rkeep" parameter allows a 15 SIP entity to indicate willingness to receive keep-alives from its 16 adjacent downstream SIP entity, the adjacent downstream SIP entity to 17 indicate willingness to send keep-alives, and for SIP entities 18 willing to send keep-alives to inform the receiver about the keep- 19 alive interval. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 19, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Use-case: UA not able to send keep-alives due to sleep 57 mode . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 62 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.2. Lifetime of keep-alives . . . . . . . . . . . . . . . . . 4 64 5.3. Behavior of a SIP entity willing to receive keep-alives . 4 65 5.4. Behavior of a SIP entity willing to send keep-alives . . 5 66 6. Keep-alive interval . . . . . . . . . . . . . . . . . . . . . 7 67 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. 'rkeep' Via header field parameter . . . . . . . . . . . 9 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 13.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 RFC 6223 [RFC6223] defines a mechanism, which allows adjacent SIP 84 entities to explicitly negotiate usage of the NAT keep-alive 85 mechanisms defined in SIP Outbound [RFC5626]. The "keep" parameter 86 [RFC6223] allows SIP entities, when sending a request, to indicate 87 willingness to send keep-alives, and it allows SIP entities, when 88 sending a response, indicate willingness to receive keep-alives. 90 In some cases a SIP device, located behind a NAT, is not able to send 91 keep-alives. One reason can be that the scheduling policy of the 92 operating system used by the SIP device does not meet the requirement 93 for sending keep-alives using a proper interval, meaning that NAT 94 bindings might not be kept. In such cases, the device needs to 95 request another device to send keep-alives towards the itself. Then, 96 the keep-alive response message sent from the SIP device will ensure 97 that the NAT binding is kept open. 99 This specification defines a new Session Initiation Protocol (SIP) 100 Via header field parameter [RFC3261], "rkeep". The "rkeep" parameter 101 allows a SIP entity to indicate willingness to receive keep-alives 102 from its adjacent downstream SIP entity, the adjacent downstream SIP 103 entity to indicate willingness to send keep-alives, and for SIP 104 entities willing to send keep-alives to inform the receiver about the 105 keep-alive interval. 107 The following sections describe use-cases where a mechanism to 108 explicitly negotiate usage of keep-alives is needed. 110 1.1. Use-case: UA not able to send keep-alives due to sleep mode 112 2. Applicability 114 The mechanism defined in this specification MUST only be used by SIP 115 entities that are not able, e.g. because the scheduling policy of the 116 operating system used by the SIP device does not meet the requirement 117 for sending keep-alives using a proper interval. 119 3. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119]. 126 4. Definitions 128 Keep-alives: The keep-alive messages defined in RFC 5626. 130 "rkeep" parameter: A SIP Via header field parameter that a SIP entity 131 can insert in the topmost Via header field that it adds to the 132 request, to explicitly indicate willingness to receive keep-alives 133 from its adjacent downstream SIP entity. A SIP entity can add a 134 parameter value to the "rkeep" parameter, or remove an existing 135 parameter value, in a response to explicitly indicate willingness to 136 send keep-alives to its adjacent upstream SIP entity. 138 SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261. 140 Adjacent downstream SIP entity: The adjacent SIP entity in the 141 direction towards which a SIP request is sent. 143 Adjacent upstream SIP entity: The adjacent SIP entity in the 144 direction from which a SIP request is received. 146 5. User Agent and Proxy behavior 148 5.1. General 150 This section describes how SIP UAs and proxies negotiate usage of 151 keep-alives associated with a registration, or a dialog, which types 152 of SIP requests can be used in order to negotiate the usage, and the 153 lifetime of the negotiated keep-alives. 155 SIP entities indicate willingness to receive keep-alives from the 156 adjacent downstream SIP entity using SIP requests. The associated 157 responses are used by SIP entities to indicate willingness to send 158 keep-alives. Both SIP entities can indicate a recommended keep-alive 159 interval. 161 The procedures to negotiate usage of keep-alives are identical for 162 SIP UAs and proxies. 164 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 165 entity has indicated willingness to receive keep-alives from an 166 adjacent SIP entity, sending of keep-alives towards that adjacent SIP 167 entity needs to be separately negotiated. 169 5.2. Lifetime of keep-alives 171 The lifetime of negotiated keep-alives depends on whether the keep- 172 alives are associated with a registration or a dialog. The rules 173 defined in RFC 6223 [RFC6223] also apply when keep-alives are 174 negotiated using the 'rkeep' Via header field parameter. 176 5.3. Behavior of a SIP entity willing to receive keep-alives 178 As defined in RFC 5626, a SIP entity that supports receiving of keep- 179 alives must act as a STUN server [RFC5389]. The SIP entity must 180 support those aspects of STUN that are required in order to apply the 181 STUN keep-alive mechanism defined in RFC 5626, and it must support 182 the CRLF keep-alive mechanism defined in RFC 5626. 184 When a SIP entity sends or forwards a request, if it wants to 185 negotiate the receiving of keep-alives associated with a 186 registration, or a dialog, it MUST insert a "rkeep" parameter in the 187 topmost Via header field that it adds to the request, to indicate 188 willingness to receive keep-alives. The SIP entity MAY add a 189 parameter value to the "rkeep" parameter before sending or forwarding 190 the request. The parameter value, if present and with a value other 191 than zero, represents a recommended keep-alive interval, given in 192 seconds. 194 When the SIP entity receives the associated response, if the "rkeep" 195 parameter in the topmost Via header field of the response contains a 196 "rkeep" parameter value with a non-zero value, or a value which is 197 different from the value sent in the request (counting a "rkeep" 198 parameter without a value) it MUST be prepared to start receiving 199 keep-alives from the same destination from where it received the 200 response which was used to negotiate the receiving of keep-alives. 201 If the "rkeep" parameter does not contain a value, the SIP entity 202 MUST assume that keep-alives will be sent using the recommended keep- 203 alive interval, if any, that the SIP entity added to the associated 204 request. 206 If the associated response contains the same "rkeep" parameter value 207 as the request (counting a "rkeep" parameter without a value), the 208 SIP entity MUST assume that keep-alives will not be sent. 210 Once a SIP entity has negotiated receiving of keep-alives associated 211 with a dialog towards an adjacent SIP entity, it MUST NOT insert a 212 "rkeep" parameter in any subsequent SIP requests, associated with the 213 dialog, towards that adjacent SIP entity. Such "rkeep" parameter 214 MUST be ignored, if received. 216 Since an ACK request does not have an associated response, it can not 217 be used to negotiate usage of keep-alives. Therefore, a SIP entity 218 MUST NOT insert a "rkeep" parameter in the topmost Via header field 219 of an ACK request. Such "rkeep" parameter MUST be ignored, if 220 received. 222 A SIP entity MUST NOT indicates willingness to receive keep-alives 223 associated with a dialog, unless it has also inserted itself in the 224 dialog route set [RFC3261]. 226 If an INVITE request is used to indicate willingness to receive keep- 227 alives, as long as at least one response (provisional or final) to 228 the INVITE request contains a "rkeep" parameter with a parameter 229 value which is different from the value in the request (counting a 230 "rkeep" parameter without a value) it is seen as an indication that 231 the adjacent downstream SIP entity is willing to send keep-alives 232 associated with the dialog on which the response is received. 234 5.4. Behavior of a SIP entity willing to send keep-alives 236 As defined in RFC 5626, a SIP entity that supports sending of keep- 237 alives must act as a Session Traversal Utilities for NAT (STUN) 238 client [RFC5389]. The SIP entity must support those aspects of STUN 239 that are required in order to apply the STUN keep-alive mechanism 240 defined in RFC 5626, and it must support the CRLF keep-alive 241 mechanism defined in RFC 5626. RFC 5626 defines when to use STUN, 242 respectively double-CRLF, for keep-alives. 244 When a SIP entity sends or forwards a response, and the adjacent 245 upstream SIP entity indicated willingness to receive keep-alives 246 without a recommended keep-alive interval, if the SIP entity is 247 willing to send keep-alives associated with the registration, or the 248 dialog, to the adjacent upstream SIP entity it MUST add a parameter 249 value to the "rkeep" parameter, before sending or forwarding the 250 response. The parameter value, represents the keep-alive interval, 251 given in seconds, that the sender of the keep-alives will use. 253 If the adjacent upstream SIP entity provided a recommended keep-alive 254 interval, and if the SIP entity is willing to send keep-alives using 255 that interval, it MUST remove the "rkeep" parameter value which 256 indicates the recommended keep-alive interval, before sending or 257 forwarding the response. 259 NOTE: The reason for removing the "rkeep" parameter value is to 260 indicate that the SIP entity supports the mechanism, and simply does 261 not forward an unknown parameter. 263 If the adjacent upstream SIP entity provided a recommended keep-alive 264 interval, and if the SIP entity is willing to send keep-alives using 265 a different interval, it MUST modify the "rkeep" parameter value 266 which indicates the recommended keep-alive interval, before sending 267 or forwarding the response. 269 There might be multiple responses to an INVITE request. When a SIP 270 entity indicates willingness to send keep-alives in a response to an 271 INVITE request, it MUST add a parameter value to the "rkeep" 272 parameter in at least one reliable response to the request. The SIP 273 entity MAY add identical parameter values to the "rkeep" parameters 274 in other responses to the same request. The SIP entity MUST NOT add 275 different parameter value to the "rkeep" parameters in responses to 276 the same request. The SIP entity SHOULD indicate the willingness to 277 send keep-alives as soon as possible. 279 In case an INVITE request is forked [RFC3261], there might be 280 responses associated with multiple early dialogs [RFC5389]. When a 281 SIP entity indicates willingness to send keep-alives, it MUST add a 282 parameter in at least one reliable response per early dialog. Once 283 an early dialog is terminated (e.g. when a 200 OK final response 284 associated with anohter early dialog is received) the SIP entity MUST 285 cease sending keep-alives negotiated for the terminated early dialog. 287 A SIP entity MUST NOT indicates willingness to send keep-alives 288 associated with a dialog, unless it has also inserted itself in the 289 dialog route set [RFC3261]. 291 When the SIP entity has indicated willingness to send keep-alives, it 292 MUST start sending keep-alives towards the same destination where it 293 sent the response used to indicate willingness to send keep-alives. 295 6. Keep-alive interval 297 If a SIP entity sends a SIP response, where the topmost Via header 298 field contains a "rkeep" parameter with a non-zero value that 299 indicates the keep-alive interval, given in seconds, it MUST use the 300 procedures defined for the Flow-Timer header field [RFC5626]. 301 According to the procedures, the SIP entity must send keep-alives at 302 least as often as the indicated keep-alive interval, and if the SIP 303 entity uses the indicated keep-alive interval then it should send its 304 keep-alives so that the interval between each keep-alive is randomly 305 distributed between 80% and 100% of the indicated keep-alive 306 interval. 308 This specification does not define any semantic for a "rkeep" Via 309 header parameter value with a zero value. A SIP entity MUST NOT 310 insert a zero value to a "rkeep" parameter. A SIP entity that 311 receives a "rkeep" parameter with a zero value SHOULD NOT assume that 312 the sender of the response will send keep-alives towards the SIP 313 entity. 315 This specification does not specify actions to take if negotiated 316 keep-alives are not received. As defined in RFC 5626, the receiving 317 SIP entity may consider a connection to be dead in such situations. 319 NOTE: The Flow-Timer header field [RFC5626] has no impact on keep- 320 alives negotiated using the "rkeep" Via header field parameter. 322 7. Example 323 Alice P1 REGISTRAR 324 | | | 325 |--- REGISTER------------->| | 326 | Via: Alice;rkeep | | 327 | |--- REGISTER-------------->| 328 | | Via: P1 | 329 | | Via: Alice;rkeep | 330 | | | 331 | |<-- 200 OK ----------------| 332 | | Via: P1 | 333 | | Via: Alice;rkeep | 334 |<-- 200 OK ---------------| | 335 | Via: Alice;rkeep=30 | | 336 | | | 337 | | | 338 | *** Timeout *** | 339 | | | 340 |<=== STUN request ========| | 341 |=== STUN response =======>| | 342 | | | 343 | *** Timeout *** | 344 | | | 345 |<=== STUN request ========| | 346 |=== STUN response =======>| | 347 | | | 349 Figure 1: Example call flow 351 8. Grammar 353 8.1. General 355 This section describes the syntax extensions to the ABNF syntax 356 defined in RFC 3261, by defining a new Via header field parameter, 357 "rkeep". The ABNF defined in this specification is conformant to RFC 358 5234 [RFC5234]. 360 8.2. ABNF 362 via-params =/ rkeep 364 rkeep = "rkeep" [ EQUAL 1*(DIGIT) ] 366 9. IANA Considerations 368 9.1. 'rkeep' Via header field parameter 370 This specification defines a new Via header field parameter, called 371 "rkeep", in the "Header Field Parameters and Parameter Values" sub- 372 registry as per the registry created by [RFC3968]. The syntax is 373 defined in Section 8. The required information is: 375 Predefined 376 Header Field Parameter Name Values Reference 377 ---------------------- --------------------- ---------- --------- 378 Via rkeep No [RFCXXXX] 380 10. Security Considerations 382 The Security Considerations in RFC 6223 apply. 384 11. Acknowledgements 386 The following persons provided comments and feedback on the document: 387 Paul Kyzivat, Dan Wing, Gethin Liddell and Venkata Ramesh 388 Balabhadruni. 390 12. Change Log 392 [RFC EDITOR NOTE: Please remove this section when publishing] 394 Changes from draft-holmberg-sipcore-rkeep-04 396 o New version submitted due to expiration of previous version. 398 Changes from draft-holmberg-sipcore-rkeep-03 400 o New version submitted due to expiration of previous version. 402 Changes from draft-holmberg-sipcore-rkeep-02 404 o New version submitted due to expiration of previous version. 406 Changes from draft-holmberg-sipcore-rkeep-01 408 o New version submitted due to expiration of previous version. 410 Changes from draft-holmberg-sipcore-rkeep-00 412 o Forking text added. 414 o Editorial corrections. 416 o - s/6263/6223. 418 o - s/frequency/interval. 420 o Example added. 422 13. References 424 13.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 430 A., Peterson, J., Sparks, R., Handley, M., and E. 431 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 432 June 2002. 434 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 435 Specifications: ABNF", STD 68, RFC 5234, January 2008. 437 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 438 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 439 October 2008. 441 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 442 Initiated Connections in the Session Initiation Protocol 443 (SIP)", RFC 5626, October 2009. 445 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC 446 6223, April 2011. 448 13.2. Informative References 450 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 451 (IANA) Header Field Parameter Registry for the Session 452 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 453 2004. 455 Authors' Addresses 456 Christer Holmberg 457 Ericsson 458 Hirsalantie 11 459 Jorvas 02420 460 Finland 462 Email: christer.holmberg@ericsson.com 464 Oscar Gallego 465 Vodafone 466 One Kingdom Street, Paddington Central 467 London W2 6BY 468 UK 470 Email: oscar.gallego@vodafone.com