idnits 2.17.1 draft-ietf-sipcore-keep-03.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 (May 24, 2010) is 5084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 591, 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: Informational May 24, 2010 5 Expires: November 25, 2010 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-03.txt 10 Abstract 12 This specification defines a new Session Initiation Protocol (SIP) 13 Via header field parameter, "keep", which allows adjacent SIP 14 entities to explicitly negotiate usage of the Network Address 15 Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in 16 cases where SIP Outbound is not supported, cannot be applied, or 17 where usage of keep-alives are not implicitly negotiated as part of 18 the SIP Outbound negotiation. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 25, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Use-case: Session from non-registered UAs . . . . . . . . 3 56 1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3 57 1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 61 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Scope and duration of keep-alives . . . . . . . . . . . . 5 63 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.2. Keep-alives within registration . . . . . . . . . . . 5 65 4.2.3. Keep-alives within dialog . . . . . . . . . . . . . . 6 66 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6 67 4.4. Behavior of a SIP entity willing to receive keep-alives . 7 68 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 69 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8 70 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.2. Keep-alive negotiation: UA-proxy within registration . . . 9 73 7.3. Keep-alive negotiation: UA-proxy within dialog . . . . . . 10 74 7.4. Keep-alive negotiation: UA-UA within dialog . . . . . . . 12 75 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive 88 mechanisms. Eventhough the keep-alive mechanisms are separated from 89 the rest of the SIP Outbound mechanism, it is currently not possible 90 to explicitly negotiate usage of the keep-alive mechanisms, since 91 usage of keep-alives in most cases are implicitly negotiated as part 92 of the SIP Outbound negotiation. 94 However, there are SIP Outbound use-cases where the usage of keep- 95 alives are not implicitly negotiated as part of the SIP Outbound 96 negotiation. In addition, there are cases where SIP Outbound is not 97 supported, where it cannot be applied, but where there is still a 98 need to be able to negotiate usage of keep-alives. For those cases, 99 a mechanism to explicitly negotiate the usage of keep-alives is 100 needed. 102 This specification defines a new Session Initiation Protocol (SIP) 103 [RFC3261] Via header field parameter, "keep", which allows adjacent 104 SIP entities can use to explicitly negotiate the usage of the NAT 105 keep-alive mechanisms defined in SIP Outbound. The "keep" parameter 106 allows SIP entities to indicate willingness to send keep-alives, and 107 it allows SIP entities to indciate willingness to receive keep- 108 alives. 110 The following sections describe use-cases where a mechanism to 111 explicitly negotiate the usage of keep-alives is needed. 113 1.1. Use-case: Session from non-registered UAs 115 In some cases a User Agent Client (UAC) does not register itself 116 before it establishes a session, but where it still needs to be able 117 to establish a session and send keep-alives in order to maintain NAT 118 bindings open during the duration of the call. A typical example is 119 an emergency calls, where a registration is not always required. 121 1.2. Use-case: SIP Outbound not supported 123 In some cases all SIP entities that need to be able to negotiate the 124 usage of keep-alives do not support SIP Outbound. However, they 125 still support the keep-alive mechanisms defined in SIP Outbound, and 126 need to be able to negotiate the usage of them. 128 1.3. Use-case: SIP dialog initiated Outbound flows 130 SIP Outbound allows the establishment of flows using initial SIP 131 dialog requests. As specified in [RFC5626], the usage keep-alives 132 are not implicitly negotiated for such flows. Therefor there is a 133 need to be able to explicitly negotiate the usage of the keep-alives. 135 2. Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in BCP 14, RFC 2119 140 [RFC2119]. 142 3. Definitions 144 Edge proxy: As defined in [RFC5626], a SIP proxy that is located 145 topologically between the registering User Agent (UA) and the 146 Authoritative Proxy. 148 NOTE: In some deployments the edge proxy might physically be located 149 in the same entity as the Authoritative Proxy. 151 Keep-alives: Refers to keep-alive messages as defined in SIP Outbound 152 [RFC5626]. 154 "keep" parameter: A SIP Via header field parameter that a SIP entity 155 can insert in its Via header field of a request to explicitly 156 indicate willingness to send keep-alives. A SIP entity can add a 157 "yes" parameter value to a "keep" parameter in the top-most Via 158 header field of a recieved SIP request, to indicate willingness to 159 receive keep-alives from the adjacent downstream SIP entity 160 (associated with the top-most Via header field of the received 161 request) from which it received the request. 163 SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 165 4. User Agent and Proxy behavior 167 4.1. General 169 This section describes of SIP UAs and proxies negotiate the sending 170 or receiving of keep-alives within a registration and within a 171 dialog. It also describes which types of SIP requests and responses 172 can be used in order to negotiate the sending and receiving of keep- 173 alives, and the lifetime of the negotiated keep-alives. 175 SIP requests are used by SIP entities to indicate willingness to send 176 keep-alives towards the adjacent upstream SIP entity. The associated 177 responses are used by SIP entities to indicate willingness to receive 178 keep-alives. The procedures to indicate willingness to send and 179 received keep-alives are identical for UAs and proxies. 181 NOTE: Since there are SIP entities that already use CRLF keep-alives, 182 and SIP entities are expected to be able to receive those, this 183 specification does not forbid the sending of CRLF keep-alives towards 184 an SIP entity even if it has not indicated willingess to receive 185 keep-alives using the "keep" parameter. However, the "keep" 186 parameter is still important in order for a SIP entity to indicate 187 that it supports CRLF keep-alives, so that the adjacent SIP entity 188 does not use other mechanisms (e.g. short registration refresh 189 intervals) in order to make sure the NAT bindings are kept open. 191 4.2. Scope and duration of keep-alives 193 4.2.1. General 195 The sending and receving of keep-alives can be negotiated within a 196 registration, or within a dialog. The scope of the negotiated keep- 197 alives depends on what SIP request methods are used for the keep- 198 alive negotiation. 200 The sending and receiving of keep-alives can be negotiated when a 201 registration or dialog is initiated, or later during the registration 202 or dialog. However, once a SIP entity has negotiated the sending of 203 keep-alives within a registration or dialog, it can not re-negotiate 204 the sending of keep-alives within the same registration or dialog. 205 Likewise, once a SIP entity has indicated willingness to receive 206 keep-alives within a registration or dialog, it MUST NOT indicate 207 willingness to receive keep-alives in a response to a subsequent 208 request within that registration or dialog. 210 A SIP entity that has indicated willingess to receive keep-alives 211 within a dialog can still, in a subsequent request within the dialog, 212 indicate willingness to send keep-alives within the same dialog. 213 Likewise, a SIP entity that has negotiated the sending of keep-alives 214 within a dialog can in a response to a subsequent request indicate 215 willingness to receive keep-alives within the same dialog. 217 4.2.2. Keep-alives within registration 219 SIP entities use the REGISTER method in order to negotiate the 220 sending and reciving of keep-alives within a registration. The keep- 221 alives can be negotiated when the registration is established, or 222 later within the registration. Once negotiated, the keep-alives are 223 sent during the lifetime of the registration, until it is terminated. 225 In case a SIP entity establishes multiple registration flows 227 [RFC5626], the sending and receiving of keep-alives is done 228 separately for each individual registration flow. The SIP entity 229 MUST NOT send keep-alives on registration flows where it has not 230 received an indicator that the adjacent upstream SIP entity is 231 willing to receive keep-alives withing that registration flow. 233 4.2.3. Keep-alives within dialog 235 SIP entities use a initial request for a dialog, or a mid-dialog 236 target refresh request [RFC3261] in order to negotiate the sending 237 and reciving of keep-alives within a dialog. The keep-alives can be 238 negotiated when the dialog is established, or later within the 239 dialog. Once negotiated, the keep-alives are sent during the 240 lifetime of the dialog, until it is terminated. 242 Since an ACK request does not have an associated response, it can not 243 be used to negotiate the sending and reciving of keep-alives. 244 Therefor a SIP entity MUST NOT insert a "keep" parameter in its Via 245 header field of an ACK request. If a SIP entity receives a "keep" 246 parameter in an ACK request, it MUST ignore the parameter. 248 4.3. Behavior of a SIP entity willing to send keep-alives 250 As defined in [RFC5626], a SIP entity that supports the sending of 251 keep-alives must act as a Session Traversal Utilities for NAT (STUN) 252 client [RFC5389]. The SIP entity must support the amount of STUN 253 which is required to apply the STUN keep-alive mechanism defined in 254 [RFC5626], and it must support the CRLF keep-alive mechanism defined 255 in [RFC5626]. 257 When a SIP entity sends or forwards a request, if it wants to 258 negotiate the sending of keep-alives within the registration (in case 259 of a REGISTER request) or dialog (in case of an initial request for a 260 dialog, or a mid-dialog target refresh request), and if it has not 261 previously negotiated the sending of keep-alives within the same 262 registration or dialog, it MUST insert a "keep" parameter in its Via 263 header field of the request. 265 When the SIP entity receives the associated response, if the "keep" 266 parameter in its Via header field in the response contains a "yes" 267 parameter value, it MUST start to send keep-alives towards the same 268 destination where it would send a subsequent request (e.g. REGISTER 269 requests and initial requests for dialog) associated with the 270 registration (if the keep-alive negotiation is for a registration), 271 or where it would send subsequent mid-dialog reuqests (if the keep- 272 alive negotiation is for a dialog). Subsequent mid-dialog requests 273 are addressed based on the dialog route set. 275 If the response contains a Flow-Timer header field, the SIP entity 276 MUST remove the header field before it forwards the response towards 277 another SIP entity. 279 When a SIP entity is about to send a keep-alive, if the SIP entity at 280 the same time is also about to send or forward a SIP request within 281 the same registration or dialog, for which the keep-alive is to be 282 sent, the SIP entity MAY choose not to send the keep-alive, as the 283 SIP request will perform the same keep-alive action. 285 NOTE: When a SIP entity sends an initial request for a dialog, if the 286 adjacent upstream SIP entity does not insert itself in the dialog 287 route set using a Record-Route header field, the adjacent upstream 288 SIP entity will change once the dialog route set has been 289 established. If a SIP entity inserts a "keep" parameter in its Via 290 header field of an initial request for a dialog, and the "keep" 291 parameter in the associated response does not contain a "yes" 292 parameter value, the SIP entity can insert a "keep" parameter in its 293 Via header field of a subsequent request within the dialog, in case 294 the new adjacent SIP entity is willing to receive keep-alives (in 295 which case it will add a "yes" parameter value to the "keep" 296 parameter). 298 NOTE: If a SIP entity inserts a "keep" parameter in its Via header 299 field of an INVITE request, and it receives multiple responses 300 (provisional or final) associated with the request, as long as at 301 least one of the responses, for a specific dialog, contains a "keep" 302 parameter with a "yes" value it is seen as an indication that the 303 adjacent upstream SIP entity is willing to receive keep-alives within 304 the dialog. 306 4.4. Behavior of a SIP entity willing to receive keep-alives 308 As defined in [RFC5626], a SIP entity that supports receiving of 309 keep-alives must act as a STUN server [RFC5389]. The SIP entity must 310 support the amount of STUN which is required to apply the STUN keep- 311 alive mechanism defined in [RFC5626], and it must support the CRLF 312 keep-alive mechanism defined in [RFC5626]. 314 When a SIP entity receives request that can be used in order to 315 negotiate the sending and receiveing of keep-alives, the top-most Via 316 header field of the request contains a "keep" parameter, and the SIP 317 entity has not previously indicated willingess to receive keep-alives 318 from the adjacent downstream SIP entity within the registration (in 319 case of a REGISTER request) or dialog (in case of a initial request 320 for a dialog, or a mid-dialog target refresh request), if it is 321 willing to receive keep-alives from the adjacent downstream SIP 322 entity it MUST add a "yes" parameter value to the "keep" parameter of 323 the top-most Via header field of the request, before forwarding the 324 request or creating a response. In addition, the SIP entity MAY 325 insert a Flow-Timer header field [RFC5626] in the associated 326 response, which indicates the recommended keep-alive frequency for 327 the registration or dialog. 329 5. Keep-alive frequency 331 If a SIP entity receives a SIP response, where its Via header field 332 contains a "keep" parameter with a "yes" value, also contains a Flow- 333 Timer header field [RFC5626], according to [RFC5626] the SIP entity 334 MUST send keep-alives at least as often as this number of seconds, 335 and if the SIP entity uses the server-recommended keep-alive 336 frequency it should send its keep-alives so that the interval between 337 each keep-alive israndomly distributed between 80% and 100% of the 338 server-provided time. 340 If the SIP entity does not receive a Flow-Timer header field from the 341 edge proxy, it can send keep-alives at its discretion. [RFC5626] 342 provides additional guidance on selecting the keep-alive frequency in 343 case a Flow-Timer header field is not received. 345 OPEN ISSUE: It has been suggested that, instead of using the Flow- 346 Timer header field in order to provide the recommented keep-alive 347 frequency value, the value would be added as a parameter to the 348 "keep" parameter, instead of the "yes" value. 350 6. Overlap with connection reuse 352 The connect-reuse specification [I-D.ietf-sip-connect-reuse] 353 specifies how to use connection-oriented transports to send requests 354 in the reverse direction. SIP entity A opens a connection to entity 355 B in order to send a request. Under certain conditions entity B can 356 reuse that connection for sending requests in the backwards direction 357 to A as well. However, the connect-reuse specification does not 358 define a keep-alive mechanism for this connection. 360 The mechanism specified in this draft is thus orthogonal to the 361 purpose of connection reuse. An entity that wants to use connection- 362 reuse as well as indicate keep-alive mechanism on that connection 363 will insert both the "alias" parameter defined in [connect-reuse] as 364 well as the "keep" parameter defined in this memo. Inserting only 365 one of these parameters is not a substitute for the other. Thus, 366 while the presence of a "keep" parameter will indicate that the enity 367 supports keep-alives in order to keep the connection open, no 368 inference can be drawn on whether that connection can be used for 369 requests in the backwards direction. 371 7. Examples 373 7.1. General 375 This section shows example flows where the usage of keep-alives is 376 negotiated between different SIP entities, within a registration or 377 within a dialog. 379 7.2. Keep-alive negotiation: UA-proxy within registration 381 The figure shows an example where Alice sends an REGISTER request. 382 She indicates willingness of sending keep-alive by inserting a "keep" 383 parameter in her Via header field of the request. The edge proxy 384 (P1) supports the keep-alive mechanism, and is willing to receive 385 keep-alives from Alice during the registration, so it adds a "yes" 386 value to the "keep" parameter in the Via header field of the UAC, 387 before it forwards the request towards the registrar. 389 When P1 receives the associated response, it inserts a Flow-Timer 390 header field, with a recommended keep-alive frequency interval of 30 391 seconds, in the response, before it forwards the response towards 392 Alice. 394 When Alice receives the response, she determines from her Via header 395 field that P1 is willing to receive keep-alives within the 396 registration. For the duration of the registration, the UAC then 397 sends periodic keep-alives (in this example using the STUN keep-alive 398 technique) towards P1, using the recommended keep-alive frequency 399 indicated in the Flow-Timer header field of the response. 401 Alice P1 REGISTRAR 402 | | | 403 |--- REGISTER------------->| | 404 | Via: UAC;keep | | 405 | |--- REGISTER-------------->| 406 | | Via: P1 | 407 | | Via: UAC;keep=yes | 408 | | | 409 | |<-- 200 OK ----------------| 410 | | Via: P1 | 411 | | Via: UAC;keep=yes | 412 |<-- 200 OK ---------------| | 413 | Via: UAC;keep=yes | | 414 | Flow-Timer: 30 | | 415 | | | 416 | | | 417 | *** Timeout *** | 418 | | | 419 |=== STUN request ========>| | 420 |<== STUN response ========| | 421 | | | 422 | *** Timeout *** | 423 | | | 424 |=== STUN request ========>| | 425 |<== STUN response ========| | 426 | | | 428 Figure 1: Example call flow 430 7.3. Keep-alive negotiation: UA-proxy within dialog 432 The figure shows an example where Alice sends an initial INVITE 433 request for a dialog. She indicates willingness to send keep-alive 434 by inserting a "keep" parameter in her Via header field of the 435 request. The edge proxy (P1) adds itself to the dialog route set by 436 adding itself to a Record-Route header field. P1 also supports the 437 keep-alive mechanism, and is willing to receive keep-alives from 438 Alice during the dialog, so it adds a "yes" value to the "keep" 439 parameter in the Via header field of Alice, before it forwards the 440 request towards Bob. 442 When P1 receives the associated response, it inserts a Flow-Timer 443 header field, with a recommended keep-alive frequency interval of 30 444 seconds, in the response, before it forwards the response towards 445 Alice. 447 When Alice receives the response, she determines from its Via header 448 field that P1 is willing to receive keep-alives within the dialog. 449 For the duration of the dialog, she then sends periodic keep-alives 450 (in this example using the STUN keep-alive technique) towards P1, 451 using the recommended keep-alive frequency indicated in the Flow- 452 Timer header field of the response. 454 Alice P1 Bob 455 | | | 456 |--- INVITE -------------->| | 457 | Via: UAC;keep | | 458 | |--- INVITE --------------->| 459 | | Via: P1 | 460 | | Via: UAC;keep=yes | 461 | | Record-Route: P1 | 462 | | | 463 | |<-- 200 OK ----------------| 464 | | Via: P1 | 465 | | Via: UAC;keep=yes | 466 | | Record-Route: P1 | 467 |<-- 200 OK ---------------| | 468 | Via: UAC;keep=yes | | 469 | Flow-Timer: 30 | | 470 | Record-Route: P1 | | 471 | | | 472 |--- ACK ----------------->| | 473 | | | 474 | |--- ACK ------------------>| 475 | | | 476 | *** Timeout *** | 477 | | | 478 |=== STUN request ========>| | 479 |<== STUN response ========| | 480 | | | 481 | *** Timeout *** | 482 | | | 483 |=== STUN request ========>| | 484 |<== STUN response ========| | 485 | | | 486 | | | 487 |--- BYE ----------------->| | 488 | | | 489 | |--- BYE ------------------>| 490 | | | 491 | |<-- 200 OK ----------------| 492 | | | 494 Figure 2: Example call flow 496 7.4. Keep-alive negotiation: UA-UA within dialog 498 The figure shows an example where Alice sends an initial INVITE 499 request for a dialog. She indicates willingness to send keep-alive 500 by inserting a "keep" parameter in her Via header field of the 501 request. The edge proxy (P1) does not add itself to the dialog route 502 set by adding itself to a Record-Route header field, and it does not 503 indicate willingness to receive keep-alives from Alice. 505 When Alice receives the response, she determines from her Via header 506 field that P1 is not willing to receive keep-alives from her. When 507 the dialog route set has been established, Alice sends a mid-dialog 508 UPDATE request towards Bob (since P1 did not insert itself in the 509 dialog route set), and she once again indicates willingness to send 510 keep-alives by inserting a "keep" parameter in her Via header field 511 of the request. Bob supports the keep-alive mechanism, and is 512 willing to receive keep-alives from Alice during the dialog, so he 513 adds a "yes" value to the "keep" parameter in the Via header field of 514 Alice, before he creates and sends a response towards her. Bob also 515 inserts a Flow-Timer header field in the response, with a recommended 516 keep-alive frequency interval of 30 seconds. 518 When Alice receives the response, she determines from her Via header 519 field that Bob is willing to receive keep-alives from her within the 520 dialog. For the duration of the dialog, Alice then sends periodic 521 keep-alives (in this example using the STUN keep-alive technique) 522 towards Bob, using the recommended keep-alive frequency indicated in 523 the Flow-Timer header field of the response. 525 Alice P1 Bob 526 | | | 527 |--- INVITE -------------->| | 528 | Via: UAC;keep | | 529 | |--- INVITE --------------->| 530 | | Via: P1 | 531 | | Via: UAC:keep | 532 | | | 533 | |<-- 200 OK ----------------| 534 | | Via: P1 | 535 | | Via: UAC;keep | 536 |<-- 200 OK ---------------| | 537 | Via: UAC;keep | | 538 | | | 539 | | 540 |--- ACK --------------------------------------------->| 541 | | 542 |--- UPDATE ------------------------------------------>| 543 | Via: UAC;keep | 544 | | 545 |<-- 200 OK ------------------------------------------>| 546 | Via: UAC;keep=yes | 547 | Flow-Timer: 30 | 548 | | 549 | | 550 | *** Timeout *** | 551 | | 552 |=== STUN request ====================================>| 553 |<== STUN response ====================================| 554 | | 555 | *** Timeout *** | 556 | | 557 |=== STUN request ====================================>| 558 |<== STUN response ====================================| 559 | | 560 | | 561 |--- BYE --------------------------------------------->| 562 | | 563 |<-- 200 OK -------------------------------------------| 564 | | 566 Figure 3: Example call flow 568 8. Grammar 570 This specification defines a new Via header field parameter, "keep". 571 The grammar includes the definitions from [RFC5626]. 573 The ABNF [RFC5234] is: 575 via-params =/ keep 577 keep = "keep" [ EQUAL "yes" ] 579 9. IANA Considerations 581 9.1. keep 583 This specification defines a new Via header field parameter called 584 keep in the "Header Field Parameters and Parameter Values" sub- 585 registry as per the registry created by [RFC5626]. The syntax is 586 defined in Section 8. The required information is: 588 Predefined 589 Header Field Parameter Name Values Reference 590 ---------------------- --------------------- ---------- --------- 591 Via keep No [RFCXXXX] 593 10. Security Considerations 595 This specification does not introduce security consideritions in 596 additions to those specified in [RFC5626]. 598 11. Acknowledgements 600 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 601 and Milo Orsic for their comments on the initial draft. Thanks to 602 Juha Heinaenen, Jiri Kuthan, Dean Willis and John Elwell for their 603 comments on the list. Thanks to Vijay Gurbani for providing text 604 about the relationship with the connect-reuse specification. 606 12. References 608 12.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 614 A., Peterson, J., Sparks, R., Handley, M., and E. 615 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 616 June 2002. 618 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 619 Specifications: ABNF", STD 68, RFC 5234, January 2008. 621 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 622 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 623 October 2008. 625 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 626 Initiated Connections in the Session Initiation Protocol 627 (SIP)", RFC 5626, October 2009. 629 12.2. Informative References 631 [I-D.ietf-sip-connect-reuse] 632 Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 633 the Session Initiation Protocol (SIP)", 634 draft-ietf-sip-connect-reuse-14 (work in progress), 635 August 2009. 637 Author's Address 639 Christer Holmberg 640 Ericsson 641 Hirsalantie 11 642 Jorvas 02420 643 Finland 645 Email: christer.holmberg@ericsson.com