idnits 2.17.1 draft-ietf-sipcore-keep-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (May 4, 2009) is 5464 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 378, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-16 == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-13 Summary: 1 error (**), 0 flaws (~~), 4 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: Informational May 4, 2009 5 Expires: November 5, 2009 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 5, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This specification defines a new SIP Via header parameter, "keep" 47 which SIP entities can use to indicate support of the NAT keep-alive 48 techniques defined in SIP Outbound, in cases where the Outbound 49 procedures are not supported or cannot be applied. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Overlap with connection reuse . . . . . . . . . . . . . . . . 6 61 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Example with keep-alive negotiation during registration . 7 63 9.2. Example with keep-alive negotiation during session 64 establishment . . . . . . . . . . . . . . . . . . . . . . 8 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 11.1. IANA Registration of the SIP Via keep parameter . . . . . 10 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Chapter 3.5 of [I-D.ietf-sip-outbound] defines two keep-alive 77 techniques. Even though the keep-alive techniques are separated from 78 the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not 79 possible to indicate support of the keep-alive techniques without 80 also indicating support for the Outbound mechanism. In addition, as 81 described in [I-D.ietf-sip-outbound], for dialog initiated outbound 82 flows a separate mechanism is used to indicate and negotiate support 83 of keep-alives. 85 The Outbound mechanism is enabled during the UA registration phase. 86 However, there are use-cases where the UA does not register itself, 87 but still needs to be able to make calls and maintain NAT bindings 88 open during the duration of that call. A typical example is 89 emergency calls. There are also cases where entities do not support 90 the Outbound mechanism, but still want to be able to indicate support 91 and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. 92 In addition, the Outbound mechanism also allows the establishment of 93 flows using initial dialog SIP requests. As specified in 94 [I-D.ietf-sip-outbound], keep-alives must be separately negotiated 95 for such flows. 97 Another use-case is when network entities (SIP proxies) need to 98 perform heartbeats between themselves. The keep-alive techniqurs 99 defined in [I-D.ietf-sip-outbound] can be used for providing the 100 heartbeats, and the mechanism in this document can be used by the 101 entities to indicate and negotiate support of the keep-alive 102 techniques. 104 This specification defines a new SIP Via header parameter, "keep", 105 which can be used by a UA to indicate support of the keep-alive 106 techniques defined in [I-D.ietf-sip-outbound]. The UA will insert 107 the "keep" parameter in the Via header of the REGISTER request, or 108 the initial session request if not registered. 110 This specification also defines a "yes" value for the "keep" 111 parameter. The edge proxy will add a "yes" value to the "keep" 112 parameter, if received in the topmost Via header, to indicate support 113 of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. 115 2. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 3. Definitions 124 Edge proxy: As defined in [I-D.ietf-sip-outbound], an Edge Proxy is 125 any proxy that is located topologically between the registering User 126 Agent and the Authoritative Proxy. The "first" edge proxy refers to 127 the first edge proxy encountered when a UA sends a request. 129 'keep' Parameter: The 'keep' parameter is a SIP Via header parameter 130 which indicates that the entity inserting the parameter supports the 131 keep-alive techniques defined in [I-D.ietf-sip-outbound]. The 132 parameter may carry an associated parameter value. 134 4. Requirements 136 REQ 1: It MUST be possible for a SIP entity acting as a UAC to 137 indicate, during registration and session establishment, support of 138 the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards 139 the next hop, if only the keep-alive part of [I-D.ietf-sip-outbound] 140 is used for the registration or session 142 REQ 2: It MUST be possible for a SIP entity acting as a UAS to 143 indicate, during registration and session establishment, support of 144 the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards 145 the previous hop, if only the keep-alive part of 146 [I-D.ietf-sip-outbound] is used for the registration or session 148 5. Client behavior 150 A SIP entity aciting as a UAC which supports the method defined in 151 this specification MUST act as a STUN client 152 [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN 153 which is required to apply the STUN keep-alive technique 154 [I-D.ietf-sip-outbound]. 156 When a SIP entity acting as a UAC (UA or proxy) which supports the 157 method defined in this specification sends a SIP REGISTER request, 158 and the UAC wants to send keep-alives towards the next hop, the 159 entity MUST insert a "keep" Via parameter in the SIP request. If the 160 Via header in the SIP REGISTER response contains a "keep" parameter 161 with a "yes" value, the UA knows that the keep-alive techniques 162 defined in [I-D.ietf-sip-outbound] can be used between the entity and 163 the next hop during the duration of the registration. If the SIP 164 REGISTER response contains a Flow-Timer header 165 [I-D.ietf-sip-outbound], and the UAC uses the server recommended 166 keepalive frequency provided in the header, the UAC SHOULD send its 167 keepalives so that the interval between each keepalive is randomly 168 distributed between 80% and 100% of the server provided time. If no 169 Flow-Timer header field was present in the SIP REGISTER response, the 170 UA can send keepalives at its discretion. The UA must insert a 171 "keep" parameter even if the UA also indicates support of Outbound 172 [I-D.ietf-sip-outbound], to allow keep-alive usage in cases where the 173 edge proxy will only support "keep". 175 When a UAC which supports the method defined in this specification 176 sends an initial SIP request, the UAC has not registered itself via 177 the edge proxy towards which the SIP request is sent, and the UAC 178 wants to send keep-alives towards the next hop, the UAC MUST include 179 a "keep" Via parameter in the SIP request. If the Via header header 180 in the initial SIP responses contains a "keep" parameter with a "yes" 181 value, the UA knows that the keep-alive techniques defined in 182 [I-D.ietf-sip-outbound] can be used between the UAC and the next hop 183 during the duration of the call. If the initial SIP response 184 contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC 185 uses the recommended keepalive frequency provided in the header, the 186 UAC SHOULD send its keepalives so that the interval between each 187 keepalive is randomly distributed between 80% and 100% of the server 188 provided time. If no Flow-Timer header field was present in the 189 initial SIP response, the UA can send keepalives at its discretion. 190 If the UAC wishes to apply keep-alive for future calls, it MUST 191 insert a "keep" Via parameter in the initial SIP request of those 192 calls. 194 NOTE: Since there are clients that already use CRLF keep-alives, and 195 proxies are expected to be able to receive it, this specification 196 does not forbid the sending of CRLF keep-alives even when no 197 "keep=yes" indication has been received from the edge proxy. 198 However, the indicator is still important in order for the client to 199 inform the edge proxy that the client supports CRLF keep-alives, so 200 that the edge proxy does not use other mechanisms (e.g. short 201 registration refresh intervals) in order to make sure the NAT 202 bindings are kept open. 204 6. Server behavior 206 A SIP entity acting as a UAS (UA or proxy) which supports the method 207 defined in this specification MUST act as a STUN server 208 [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN 209 which is required to apply the STUN keep-alive technique 210 [I-D.ietf-sip-outbound]. The UAS MUST also process double-CRLF keep- 211 alives, as defined in [I-D.ietf-sip-outbound]. 213 When a UAS that supports the method defined in this specification 214 recieves a SIP REGISTER request which contains a "keep" parameter in 215 the topmost Via header, and the UAS wants to allow the sender of the 216 SIP REGISTER request to send keep-alives towards the UAS during the 217 duration of the registration, the UAS proxy MUST add a "yes" value to 218 the "keep" parameter. In addition the UAS MAY include a Flow-Timer 219 header field if the associated SIP REGISTER response. 221 When a UAS that supports the method defined in this specification 222 recieves an initial SIP request which contains a "keep" parameter in 223 the topmost Via header, and the UAS wants to allow the sender of the 224 initial SIP request to send keep-alives towards the UAS during the 225 duration of the call, the UAS proxy MUST add a "yes" value to the 226 "keep" parameter. In addition the UAS MAY include a Flow-Timer 227 header field if the associated initial SIP response. 229 7. Proxy behavior 231 A proxy acting as a UAC, that wants to use the mechanism in this 232 document, shall follow the procedures defined in Section 5. 234 A proxy acting as a UAS, that wants to use the mechanism in this 235 document, shall follow the procedures defined in Section 6. 237 8. Overlap with connection reuse 239 The connect-reuse specification [I-D.ietf-sip-connect-reuse] 240 specifies how to use connection-oriented transports to send requests 241 in the reverse direction. SIP entity A opens a connection to entity 242 B in order to send a request. Under certain conditions entity B can 243 reuse that connection for sending requests in the backwards direction 244 to A as well. However, the connect-reuse specification does not 245 define a keep-alive mechanism for this connection. 247 The technique specified in this draft is thus orthogonal to the 248 purpose of connection reuse. An entity that wants to use connection- 249 reuse as well as indicate keep-alive mechanism on that connection 250 will insert both the "alias" parameter defined in [connect-reuse] as 251 well as the "keep" parameter defined in this memo. Inserting only 252 one of these parameters is not a substitute for the other. Thus, 253 while the presence of a "keep" parameter will indicate that the enity 254 supports keep-alives in order to keep the connection open, no 255 inference can be drawn on whether that connection can be used for 256 requests in the backwards direction. 258 9. Examples 260 9.1. Example with keep-alive negotiation during registration 262 The figure shows an example where a UAC sends an REGISTER request, in 263 which it indicates support of keep-alive by inserting a "keep" 264 parameter in the Via header of the REGISTER request. The edge proxy 265 (P1) also supports the keep-alive mechanism, so it adds a "yes" value 266 to the "keep" parameter to the Via header of the UAC. The request is 267 then fowarded towards the registrar. When the UAC receives the 200 268 OK (REGISTER) response from the registrar it finds out that the edge 269 proxy supports keep-alive. After that the UAC sends periodic keep- 270 alives (in this example using the STUN keep-alive technique) during 271 the duration of the registration. The edge proxy (P1) has inserted a 272 Flow-Timer header in the 200 OK (REGISTER) response, indicating a 273 recommented keep-alive interval of 30 seconds. 275 UAC P1 REGISTRAR 276 | | | 277 |--- REGISTER------------->| | 278 | Via: UAC;keep | | 279 | |--- REGISTER-------------->| 280 | | Via: UAC;keep=yes | 281 | | Via: P1 | 282 | | | 283 | |<-- 200 OK ----------------| 284 | | Via: UAC;keep=yes | 285 | | Via: P1 | 286 |<-- 200 OK ---------------| | 287 | Via: UAC;keep=yes | | 288 | Flow-Timer: 30 | | 289 | | | 290 | | | 291 | *** Timeout *** | 292 | | | 293 |=== STUN request ========>| | 294 |<== STUN response ========| | 295 | | | 296 | *** Timeout *** | 297 | | | 298 |=== STUN request ========>| | 299 |<== STUN response ========| | 300 | | | 302 Figure 1: Example call flow 304 9.2. Example with keep-alive negotiation during session establishment 306 The figure shows an example where a non-registered UAC sends an 307 INVITE request, in which it indicates support of keep-alive by 308 inserting a "keep" parameter in the Via header of the INVITE request. 309 The edge proxy (P1) also supports the keep-alive mechanism, so it 310 adds a "yes" value to the "keep" parameter to the Via header of the 311 UAC. The request is then fowarded towards the UAS. When the UAC 312 receives the 200 OK (INVITE) response from the UAS it finds out that 313 the edge proxy supports keep-alive. After that the UAC sends 314 periodic keep-alives (in this example using the STUN keep-alive 315 technique) during the duration of the call. The edge proxy (P1) has 316 inserted a Flow-Timer header in the 200 OK (INVITE) response, 317 indicating a recommented keep-alive interval of 30 seconds. 319 UAC P1 UAS 320 | | | 321 |--- INVITE -------------->| | 322 | Via: UAC;keep | | 323 | |--- INVITE --------------->| 324 | | Via: UAC;keep=yes | 325 | | Via: P1 | 326 | | | 327 | |<-- 200 OK ----------------| 328 | | Via: UAC;keep=yes | 329 | | Via: P1 | 330 |<-- 200 OK ---------------| | 331 | Via: UAC;keep=yes | | 332 | Flow-Timer: 30 | | 333 | | | 334 |--- ACK ----------------->| | 335 | | | 336 | |--- ACK ------------------>| 337 | | | 338 | *** Timeout *** | 339 | | | 340 |=== STUN request ========>| | 341 |<== STUN response ========| | 342 | | | 343 | *** Timeout *** | 344 | | | 345 |=== STUN request ========>| | 346 |<== STUN response ========| | 347 | | | 348 | | | 349 |--- BYE ----------------->| | 350 | | | 351 | |--- BYE ------------------>| 352 | | | 353 | |<-- 200 OK ----------------| 354 | | | 356 Figure 2: Example call flow 358 10. Security Considerations 360 11. IANA Considerations 361 11.1. IANA Registration of the SIP Via keep parameter 363 12. Acknowledgements 365 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 366 and Milo Orsic for their comments on the initial draft. Thanks to 367 Juha Heinaenen, Jiri Kuthan and Dean Willis for their comments on the 368 list. Thanks to Vijay Gurbani for providing text about the 369 relationship with the connect-reuse specification. 371 13. References 373 13.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 379 A., Peterson, J., Sparks, R., Handley, M., and E. 380 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 381 June 2002. 383 13.2. Informative References 385 [I-D.ietf-sip-outbound] 386 Jennings, C. and R. Mahy, "Managing Client Initiated 387 Connections in the Session Initiation Protocol (SIP)", 388 draft-ietf-sip-outbound-16 (work in progress), 389 October 2008. 391 [I-D.ietf-behave-rfc3489bis] 392 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 393 "Session Traversal Utilities for (NAT) (STUN)", 394 draft-ietf-behave-rfc3489bis-18 (work in progress), 395 July 2008. 397 [I-D.ietf-sip-connect-reuse] 398 Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 399 the Session Initiation Protocol (SIP)", 400 draft-ietf-sip-connect-reuse-13 (work in progress), 401 March 2009. 403 Author's Address 405 Christer Holmberg 406 Ericsson 407 Hirsalantie 11 408 Jorvas 02420 409 Finland 411 Email: christer.holmberg@ericsson.com