idnits 2.17.1 draft-ietf-sipcore-keep-04.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 31, 2010) is 5079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 599, 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 31, 2010 5 Expires: December 2, 2010 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-04.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 is 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 December 2, 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. Lifetime of keep-alives . . . . . . . . . . . . . . . . . 5 63 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.2. Keep-alives associated with registration . . . . . . . 5 65 4.2.3. Keep-alives associated with 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 associated with registration: 73 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 10 75 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 76 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive 89 mechanisms. Eventhough the keep-alive mechanisms are separated from 90 the rest of the SIP Outbound mechanism, SIP Outbound does not define 91 a mechanism to explicitly negotiate usage of the keep-alive 92 mechanisms, since usage of keep-alives in most cases are implicitly 93 negotiated as part of the SIP Outbound negotiation. 95 However, there are SIP Outbound use-cases where usage of keep-alives 96 are not implicitly negotiated as part of the SIP Outbound 97 negotiation. In addition, there are cases where SIP Outbound is not 98 supported, where it cannot be applied, but where there is still a 99 need to be able to negotiate usage of keep-alives. 101 This specification defines a new Session Initiation Protocol (SIP) 102 [RFC3261] Via header field parameter, "keep", which allows adjacent 103 SIP entities to explicitly negotiate usage of the NAT keep-alive 104 mechanisms defined in SIP Outbound. The "keep" parameter allows SIP 105 entities to indicate willingness to send keep-alives, to indicate 106 willingness to receive keep-alives, and for SIP entities willing to 107 receive keep-alives to provide a recommended keep-alive frequency. 109 The following sections describe use-cases where a mechanism to 110 explicitly negotiate usage of keep-alives is needed. 112 1.1. Use-case: Session from non-registered UAs 114 In some cases a User Agent Client (UAC) does not register itself 115 before it establishes a session, but in order to maintain NAT 116 bindings open during the session it still needs to be able to 117 negotiate sending of keep-alives towards its adjacent upstream SIP 118 entity. A typical example is an emergency call, where a registration 119 is not always required in order to make the call. 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 might not support SIP Outbound. However, they 125 might still support the keep-alive mechanisms defined in SIP 126 Outbound, and need to be able to negotiate usage of them. 128 1.3. Use-case: SIP dialog initiated Outbound flows 130 SIP Outbound allows the establishment of flows using the initial 131 request for a dialog. As specified in [RFC5626], usage keep-alives 132 is not implicitly negotiated for such flows, why usage needs to be 133 explicitly negotiated. 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 towards it adjacent upstream 157 SIP entity. If a SIP entity is willing to receive keep-alives from 158 its adjacent downstream SIP entity, and the Via header field 159 associated with the adjacent downstream SIP entity contains a "keep" 160 parameter, the SIP entity willing to receive keep-alives can add an 161 integer parameter value to that "keep" parameter. The integer 162 parameter value can be used to indicate a recommended keep-alive 163 frequency. A zero value indicates that the SIP entity is willing to 164 receive keep-alives, but that a recommended keep-alive frequency is 165 not provided. 167 SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 169 4. User Agent and Proxy behavior 171 4.1. General 173 This section describes how SIP UAs and proxies negotiate usage of 174 keep-alives associated with a registration, or a dialog, which types 175 of SIP requests types can be used in order to negotiate the usage, 176 and the lifetime of the negotiated keep-alives. 178 SIP entities indicate willingness to send keep-alives towards the 179 adjacent upstream SIP entity using SIP requests. The associated 180 responses are used by SIP entities to indicate willingness to receive 181 keep-alives. SIP entities that indicate willingness to receive keep- 182 alives can provide a recommended keep-alive frequency. 184 The procedures to negotiate usage of keep-alives are identical for 185 SIP UAs and proxies. 187 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 188 entity has indicated willingness to receive keep-alives from its 189 adjacent downstream SIP entity, sending of keep-alives towards the 190 same SIP entity needs to be separately negotiated. 192 NOTE: Since there are SIP entities that already use a combination of 193 Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP 194 entities are expected to be able to receive those, this specification 195 does not forbid the sending of CRLF keep-alive messages towards an 196 adjacent upstream SIP entity even if usage of keep-alives have not 197 been negotiated. However, the "keep" parameter is still important in 198 order for a SIP entity to indicate that it supports sending of CRLF 199 keep-alive messages, so that the adjacent upstream SIP entity does 200 not use other mechanisms (e.g. short registration refresh intervals) 201 in order to keep NAT bindings open. 203 4.2. Lifetime of keep-alives 205 4.2.1. General 207 The lifetime of negotiated keep-alives depends on whether the keep- 208 alives are associated with a registration or a dialog. The section 209 describes the lifetime of negotiated keep-alives. 211 4.2.2. Keep-alives associated with registration 213 SIP entities use a registration request in order to negotiate usage 214 of keep-alives associated with a registration. Usage of keep-alives 215 can be negotiated when the registration is established, or later 216 during the lifetime of the registration. Once negotiated, keep- 217 alives are sent until the registration is terminated, or until a 218 subsequent registration refresh request is sent or forwarded. When a 219 subsequent registration refresh request is sent or forwarded, if a 220 SIP entity is willing to continue sending keep-alives associated with 221 the registration, usage of keep-alives MUST be re-negotiated. If 222 usage is not successfully re-negotiated, the SIP entity MUST cease 223 sending of keep-alives associated with the registration. 225 In case a SIP entity establishes multiple registration flows 226 [RFC5626], usage of keep-alives needs to be negotiated separately for 227 each individual registration flow. A SIP entity MUST NOT send keep- 228 alives associated with a registration flow for which usage of keep- 229 alives has not been negotiated. 231 4.2.3. Keep-alives associated with dialog 233 SIP entities use an initial request for a dialog, or a mid-dialog 234 target refresh request [RFC3261], in order to negotiate sending and 235 receiving of keep-alives associated with a dialog. Usage of keep- 236 alives can be negotiated when the dialog is established, or later 237 during the lifetime of the dialog. Once negotiated, keep-alives MUST 238 be sent for the lifetime of the dialog, until the dialog is 239 terminated. Once usage of keep-alives associated with a dialog has 240 been negotiated, it is not possible to re-negotiate the usage 241 associated with the dialog. 243 4.3. Behavior of a SIP entity willing to send keep-alives 245 As defined in [RFC5626], a SIP entity that supports sending of keep- 246 alives must act as a Session Traversal Utilities for NAT (STUN) 247 client [RFC5389]. The SIP entity must support the amount of STUN 248 which is required to apply the STUN keep-alive mechanism defined in 249 [RFC5626], and it must support the CRLF keep-alive mechanism defined 250 in [RFC5626]. 252 When a SIP entity sends or forwards a request, if it wants to 253 negotiate the sending of keep-alives for the lifetime of a 254 registration (in case of a REGISTER request), or a dialog (in case of 255 an initial request for a dialog, or a mid-dialog target refresh 256 request), it MUST insert a "keep" parameter in its Via header field 257 of the request. 259 When the SIP entity receives the associated response, if the "keep" 260 parameter in its Via header field of the response contains a 261 parameter value, it MUST start to send keep-alives towards the same 262 destination where it would send a subsequent request (e.g. REGISTER 263 requests and initial requests for dialog) associated with the 264 registration (if the keep-alive negotiation is for a registration), 265 or where it would send subsequent mid-dialog requests (if the keep- 266 alive negotiation is for a dialog). Subsequent mid-dialog requests 267 are addressed based on the dialog route set. 269 Once a SIP entity has negotiated sending of keep-alives associated 270 with a dialog towards its adjacent upstream SIP entity, it MUST NOT 271 insert a "keep" parameter in any subsequent SIP requests associated 272 with the dialog. Such "keep" parameter MUST be ignored, if received. 274 Since an ACK request does not have an associated response, it can not 275 be used to negotiate usage of keep-alives. Therefore, a SIP entity 276 MUST NOT insert a "keep" parameter in its Via header field of an ACK 277 request. Such "keep" parameter MUST be ignored, if received. 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 281 associated with the same registration or dialog, for which the keep- 282 alive is to be sent, the SIP entity MAY choose not to send the keep- 283 alive, as the 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 [RFC3261], the adjacent 288 upstream 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 parameter 292 value, the SIP entity might choose to insert a "keep" parameter in 293 its Via header field of a subsequent SIP request associated with the 294 dialog, in case the new adjacent SIP entity (based on the dialog 295 route set) is willing to receive keep-alives (in which case it will 296 add a parameter value to the "keep" 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, per dialog, contains a "keep" parameter 302 with a parameter value it is seen as an indication that the adjacent 303 upstream SIP entity is willing to receive keep-alives associated with 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 creates or receives a response to a request that 315 can be used in order to indicate willingness to send keep-alives 316 associated with a registration or dialog, and the Via header field 317 associated with the adjacent downstream SIP entity (that is, the top- 318 most Via header field once a SIP entity that received the response 319 has removed its own Via header field from the response) contains a 320 "keep" parameter, if the SIP entity is willing to receive keep-alives 321 associated with the registration (in case of a REGISTER response), or 322 the dialog (in case of a response to an initial request for a dialog, 323 or a response to a mid-dialog target refresh request), from the 324 adjacent downstream SIP entity it MUST add a parameter value to the 325 "keep" parameter, before sending or forwarding the response. The 326 parameter can contain a recommended keep-alive frequency, or a zero 327 value. 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 non-zero value that indicates a 333 recommended keep-alive frequency, it MUST use the procedures defined 334 for the Flow-Timer header field [RFC5626]. According to the 335 procedures, the SIP entity must send keep-alives at least as often as 336 the indicated recommended keep-alive frequency, and if the SIP entity 337 uses the recommended keep-alive frequency then it should send its 338 keep-alives so that the interval between each keep-alive is randomly 339 distributed between 80% and 100% of the recommended keep-alive 340 frequency. 342 If the received "keep" parameter value is zero, the SIP entity can 343 send keep-alives at its discretion. [RFC5626] provides additional 344 guidance on selecting the keep-alive frequency in case a recommended 345 keep-alive frequency is not provided. 347 A SIP entity that uses the "keep" parameter to indicate willingness 348 to receive keep-alives MUST NOT use the Flow-Timer header field in 349 order to provide a recommended keep-alive frequency. 351 SIP Outbound uses the Flow-Timer header field to indicate the server- 352 recommended keep-alive frequency. However, it will only be sent 353 between a UA and an edge proxy. Using the "keep" parameter, however, 354 the sending and receiving of keep-alives might be negotiated between 355 multiple entities on the signalling path. Since the server- 356 recommended keep-alive frequency might vary between different SIP 357 entities, those would have to re-write the Flow-Timer header field 358 value. In addition, if a SIP entity does not indicate willingness to 359 receive keep-alives from its adjacent downstream SIP entity, and 360 receives a Flow-Timer header field in a response, it would have to 361 remove the Flow-Timer header field from the response. This issue 362 does not exist for the "keep" parameter, as each SIP entity has its 363 own individual Via header field. 365 6. Overlap with connection reuse 367 The connect-reuse specification [I-D.ietf-sip-connect-reuse] 368 specifies how to use connection-oriented transports to send requests 369 in the reverse direction. SIP entity A opens a connection to entity 370 B in order to send a request. Under certain conditions entity B can 371 reuse that connection for sending requests in the backwards direction 372 to A as well. However, the connect-reuse specification does not 373 define a keep-alive mechanism for this connection. 375 The mechanism specified in this draft is thus orthogonal to the 376 purpose of connection reuse. An entity that wants to use connection- 377 reuse as well as indicate keep-alive mechanism on that connection 378 will insert both the "alias" parameter defined in [connect-reuse] as 379 well as the "keep" parameter defined in this memo. Inserting only 380 one of these parameters is not a substitute for the other. Thus, 381 while the presence of a "keep" parameter will indicate that the 382 entity supports keep-alives in order to keep the connection open, no 383 inference can be drawn on whether that connection can be used for 384 requests in the backwards direction. 386 7. Examples 388 7.1. General 390 This section shows example flows where usage of keep-alives, 391 associated with a registration and a dialog, is negotiated between 392 different SIP entities. 394 7.2. Keep-alive negotiation associated with registration: UA-proxy 396 The figure shows an example where Alice sends an REGISTER request. 397 She indicates willingness of sending keep-alive by inserting a "keep" 398 parameter in her Via header field of the request. The edge proxy 399 (P1) forwards the request towards the registrar. 401 P1 is willing to receive keep-alives from Alice for the duration of 402 the registration, so When P1 receives the associated response it adds 403 a keep parameter value, which indicates a recommended keep-alive 404 frequency of 30 seconds, to Alice's Via header field, before it 405 forwards the response towards Alice. 407 When Alice receives the response, she determines from her Via header 408 field that P1 is willing to receive keep-alives associated with the 409 registration. For the lifetime of the registration, Alice then sends 410 periodic keep-alives (in this example using the STUN keep-alive 411 technique) towards P1, using the recommended keep-alive frequency 412 indicated by the keep parameter value. 414 Alice P1 REGISTRAR 415 | | | 416 |--- REGISTER------------->| | 417 | Via: Alice;keep | | 418 | |--- REGISTER-------------->| 419 | | Via: P1 | 420 | | Via: Alice;keep | 421 | | | 422 | |<-- 200 OK ----------------| 423 | | Via: P1 | 424 | | Via: Alice;keep | 425 |<-- 200 OK ---------------| | 426 | Via: Alice;keep=30 | | 427 | | | 428 | | | 429 | *** Timeout *** | 430 | | | 431 |=== STUN request ========>| | 432 |<== STUN response ========| | 433 | | | 434 | *** Timeout *** | 435 | | | 436 |=== STUN request ========>| | 437 |<== STUN response ========| | 438 | | | 440 Figure 1: Example call flow 442 7.3. Keep-alive negotiation associated with dialog: UA-proxy 444 The figure shows an example where Alice sends an initial INVITE 445 request for a dialog. She indicates willingness to send keep-alive 446 by inserting a "keep" parameter in her Via header field of the 447 request. The edge proxy (P1) adds itself to the dialog route set by 448 adding itself to a Record-Route header field, before it forwards the 449 request towards Bob. 451 P1 is willing to receive keep-alives from Alice for the duration of 452 the dialog, so When P1 receives the associated response it adds a 453 keep parameter value, which indicates a recommended keep-alive 454 frequency of 30 seconds, to Alice's Via header field, before it 455 forwards the response towards Alice. 457 When Alice receives the response, she determines from her Via header 458 field that P1 is willing to receive keep-alives associated with the 459 dialog. For the lifetime of the dialog, Alice then sends periodic 460 keep-alives (in this example using the STUN keep-alive technique) 461 towards P1, using the recommended keep-alive frequency indicated by 462 the keep parameter value. 464 Alice P1 Bob 465 | | | 466 |--- INVITE -------------->| | 467 | Via: Alice;keep | | 468 | |--- INVITE --------------->| 469 | | Via: P1 | 470 | | Via: Alice;keep | 471 | | Record-Route: P1 | 472 | | | 473 | |<-- 200 OK ----------------| 474 | | Via: P1 | 475 | | Via: Alice;keep | 476 | | Record-Route: P1 | 477 |<-- 200 OK ---------------| | 478 | Alice: UAC;keep=30 | | 479 | Record-Route: P1 | | 480 | | | 481 |--- ACK ----------------->| | 482 | | | 483 | |--- ACK ------------------>| 484 | | | 485 | *** Timeout *** | 486 | | | 487 |=== STUN request ========>| | 488 |<== STUN response ========| | 489 | | | 490 | *** Timeout *** | 491 | | | 492 |=== STUN request ========>| | 493 |<== STUN response ========| | 494 | | | 495 | | | 496 |--- BYE ----------------->| | 497 | | | 498 | |--- BYE ------------------>| 499 | | | 500 | |<-- 200 OK ----------------| 501 | | | 503 Figure 2: Example call flow 505 7.4. Keep-alive negotiation associated with dialog: UA-UA 507 The figure shows an example where Alice sends an initial INVITE 508 request for a dialog. She indicates willingness to send keep-alive 509 by inserting a "keep" parameter in her Via header field of the 510 request. The edge proxy (P1) does not add itself to the dialog route 511 set, by adding itself to a Record-Route header field, before it 512 forwards the request towards Bob. . 514 When Alice receives the response, she determines from her Via header 515 field that P1 is not willing to receive keep-alives associated with 516 the dialog from her. When the dialog route set has been established, 517 Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not 518 insert itself in the dialog route set), and she once again indicates 519 willingness to send keep-alives by inserting a "keep" parameter in 520 her Via header field of the request. Bob supports the keep-alive 521 mechanism, and is willing to receive keep-alives associated with the 522 dialog from Alice, so he creates a response and adds a keep parameter 523 value, which indicates a recommended keep-alive frequency of 30 524 seconds, to Alice's Via header field, before he forwards the response 525 towards Alice. 527 When Alice receives the response, she determines from her Via header 528 field that P1 is willing to receive keep-alives associated with the 529 dialog. For the lifetime of the dialog, Alice then sends periodic 530 keep-alives (in this example using the STUN keep-alive technique) 531 towards Bob, using the recommended keep-alive frequency indicated by 532 the keep parameter value. 534 Alice P1 Bob 535 | | | 536 |--- INVITE -------------->| | 537 | Via: Alice;keep | | 538 | |--- INVITE --------------->| 539 | | Via: P1 | 540 | | Via: Alice:keep | 541 | | | 542 | |<-- 200 OK ----------------| 543 | | Via: P1 | 544 | | Via: Alice;keep | 545 |<-- 200 OK ---------------| | 546 | Via: Alice;keep | | 547 | | | 548 | | 549 |--- ACK --------------------------------------------->| 550 | | 551 |--- UPDATE ------------------------------------------>| 552 | Via: Alice;keep | 553 | | 554 |<-- 200 OK ------------------------------------------>| 555 | Via: UAC;keep=30 | 556 | | 557 | | 558 | *** Timeout *** | 559 | | 560 |=== STUN request ====================================>| 561 |<== STUN response ====================================| 562 | | 563 | *** Timeout *** | 564 | | 565 |=== STUN request ====================================>| 566 |<== STUN response ====================================| 567 | | 568 | | 569 |--- BYE --------------------------------------------->| 570 | | 571 |<-- 200 OK -------------------------------------------| 572 | | 574 Figure 3: Example call flow 576 8. Grammar 578 This specification defines a new Via header field parameter, "keep". 579 The grammar includes the definitions from [RFC5626]. 581 The ABNF [RFC5234] is: 583 via-params =/ keep 585 keep = "keep" [ EQUAL 1*(DIGIT) ] 587 9. IANA Considerations 589 9.1. keep 591 This specification defines a new Via header field parameter called 592 keep in the "Header Field Parameters and Parameter Values" sub- 593 registry as per the registry created by [RFC5626]. The syntax is 594 defined in Section 8. The required information is: 596 Predefined 597 Header Field Parameter Name Values Reference 598 ---------------------- --------------------- ---------- --------- 599 Via keep No [RFCXXXX] 601 10. Security Considerations 603 This specification does not introduce security considerations in 604 addition to those specified in [RFC5626]. 606 11. Acknowledgements 608 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 609 and Milo Orsic for their comments on the initial draft. Thanks to 610 Juha Heinaenen, Jiri Kuthan, Dean Willis and John Elwell for their 611 comments on the list. Thanks to Vijay Gurbani for providing text 612 about the relationship with the connect-reuse specification. 614 12. References 616 12.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 622 A., Peterson, J., Sparks, R., Handley, M., and E. 623 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 624 June 2002. 626 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 627 Specifications: ABNF", STD 68, RFC 5234, January 2008. 629 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 630 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 631 October 2008. 633 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 634 Initiated Connections in the Session Initiation Protocol 635 (SIP)", RFC 5626, October 2009. 637 12.2. Informative References 639 [I-D.ietf-sip-connect-reuse] 640 Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 641 the Session Initiation Protocol (SIP)", 642 draft-ietf-sip-connect-reuse-14 (work in progress), 643 August 2009. 645 Author's Address 647 Christer Holmberg 648 Ericsson 649 Hirsalantie 11 650 Jorvas 02420 651 Finland 653 Email: christer.holmberg@ericsson.com