idnits 2.17.1 draft-ietf-sipcore-keep-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 (August 5, 2010) is 5012 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 597, 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 August 5, 2010 5 Expires: February 6, 2011 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-05.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 February 6, 2011. 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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.2. Keep-alive negotiation associated with registration: 72 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.3. Keep-alive negotiation associated with dialog: UA-proxy . 10 74 6.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 75 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 11. Normative References . . . . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive 86 mechanisms. Even though the keep-alive mechanisms are separated from 87 the rest of the SIP Outbound mechanism, SIP Outbound does not define 88 a mechanism to explicitly negotiate usage of the keep-alive 89 mechanisms. In some cases usage of keep-alives can be implicitly 90 negotiated as part of the SIP Outbound negotiation. 92 However, there are SIP Outbound use-cases where usage of keep-alives 93 is not implicitly negotiated as part of the SIP Outbound negotiation. 94 In addition, there are cases where SIP Outbound is not supported, or 95 where it cannot be applied, but where there is still a need to be 96 able to negotiate usage of keep-alives. 98 This specification defines a new Session Initiation Protocol (SIP) 99 [RFC3261] Via header field parameter, "keep", which allows adjacent 100 SIP entities to explicitly negotiate usage of the NAT keep-alive 101 mechanisms defined in SIP Outbound. The "keep" parameter allows SIP 102 entities to indicate willingness to send keep-alives, to indicate 103 willingness to receive keep-alives, and for SIP entities willing to 104 receive keep-alives to provide a recommended keep-alive frequency. 106 The following sections describe use-cases where a mechanism to 107 explicitly negotiate usage of keep-alives is needed. 109 1.1. Use-case: Session from non-registered UAs 111 In some cases a User Agent Client (UAC) does not register itself 112 before it establishes a session, but in order to maintain NAT 113 bindings open during the session it still needs to be able to 114 negotiate sending of keep-alives towards its adjacent upstream SIP 115 entity. A typical example is an emergency call, where a registration 116 is not always required in order to make the call. 118 1.2. Use-case: SIP Outbound not supported 120 In some cases all SIP entities that need to be able to negotiate the 121 usage of keep-alives might not support SIP Outbound. However, they 122 might still support the keep-alive mechanisms defined in SIP 123 Outbound, and need to be able to negotiate usage of them. 125 1.3. Use-case: SIP dialog initiated Outbound flows 127 SIP Outbound allows the establishment of flows using the initial 128 request for a dialog. As specified in [RFC5626], usage of keep- 129 alives is not implicitly negotiated for such flows. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in BCP 14, RFC 2119 136 [RFC2119]. 138 3. Definitions 140 Edge proxy: As defined in [RFC5626], a SIP proxy that is located 141 topologically between the registering User Agent (UA) and the 142 Authoritative Proxy. 144 NOTE: In some deployments the edge proxy might physically be located 145 in the same entity as the Authoritative Proxy. 147 Keep-alives: Refers to keep-alive messages as defined in SIP Outbound 148 [RFC5626]. 150 "keep" parameter: A SIP Via header field parameter that a SIP entity 151 can insert in its Via header field of a request to explicitly 152 indicate willingness to send keep-alives towards its adjacent 153 downstream SIP entity. A SIP entity can also insert the header field 154 in a response to explicitly indicate willingness to receive keep- 155 alives from its adjacent upstream SIP entity. 157 SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 159 Adjacent downstream SIP entity: The adjacent SIP entity in the 160 direction towards which a SIP request is sent. 162 Adjacent upstream SIP entity: The adjacent SIP entity in the 163 direction from which a SIP request is received. 165 4. User Agent and Proxy behavior 167 4.1. General 169 This section describes how SIP UAs and proxies negotiate usage of 170 keep-alives associated with a registration, or a dialog, which types 171 of SIP requests can be used in order to negotiate the usage, and the 172 lifetime of the negotiated keep-alives. 174 SIP entities indicate willingness to send keep-alives towards the 175 adjacent downstream SIP entity using SIP requests. The associated 176 responses are used by SIP entities to indicate willingness to receive 177 keep-alives. SIP entities that indicate willingness to receive keep- 178 alives can provide a recommended keep-alive frequency. 180 The procedures to negotiate usage of keep-alives are identical for 181 SIP UAs and proxies. 183 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 184 entity has indicated willingness to receive keep-alives from an 185 adjacent SIP entity, sending of keep-alives towards the same SIP 186 entity needs to be separately negotiated. 188 NOTE: Since there are SIP entities that already use a combination of 189 Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP 190 entities are expected to be able to receive those, this specification 191 does not forbid the sending of CRLF keep-alive messages towards an 192 adjacent SIP entity even if usage of keep-alives with that SIP entity 193 has not been negotiated. However, the "keep" parameter is still 194 important in order for a SIP entity to indicate that it supports 195 sending of CRLF keep-alive messages, so that the adjacent downstream 196 SIP entity does not use other mechanisms (e.g. short registration 197 refresh intervals) in order to keep NAT bindings open. 199 4.2. Lifetime of keep-alives 201 4.2.1. General 203 The lifetime of negotiated keep-alives depends on whether the keep- 204 alives are associated with a registration or a dialog. This section 205 describes the lifetime of negotiated keep-alives. 207 4.2.2. Keep-alives associated with registration 209 SIP entities use a registration request in order to negotiate usage 210 of keep-alives associated with a registration. Usage of keep-alives 211 can be negotiated when the registration is established, or later 212 during the lifetime of the registration. Once negotiated, keep- 213 alives are sent until the registration is terminated, or until a 214 subsequent registration refresh request is sent or forwarded. When a 215 subsequent registration refresh request is sent or forwarded, if a 216 SIP entity is willing to continue sending keep-alives associated with 217 the registration, usage of keep-alives MUST be re-negotiated. If 218 usage is not successfully re-negotiated, the SIP entity MUST cease 219 sending of keep-alives associated with the registration. 221 In case a SIP entity establishes multiple registration flows 222 [RFC5626], usage of keep-alives needs to be negotiated separately for 223 each individual registration flow. A SIP entity MUST NOT send keep- 224 alives associated with a registration flow for which usage of keep- 225 alives has not been negotiated. 227 4.2.3. Keep-alives associated with dialog 229 SIP entities use an initial request for a dialog, or a mid-dialog 230 target refresh request [RFC3261], in order to negotiate sending and 231 receiving of keep-alives associated with a dialog. Usage of keep- 232 alives can be negotiated when the dialog is established, or later 233 during the lifetime of the dialog. Once negotiated, keep-alives MUST 234 be sent for the lifetime of the dialog, until the dialog is 235 terminated. Once usage of keep-alives associated with a dialog has 236 been negotiated, it is not possible to re-negotiate the usage 237 associated with the dialog. 239 4.3. Behavior of a SIP entity willing to send keep-alives 241 As defined in [RFC5626], a SIP entity that supports sending of keep- 242 alives must act as a Session Traversal Utilities for NAT (STUN) 243 client [RFC5389]. The SIP entity must support those aspects of STUN 244 that are required in order to apply the STUN keep-alive mechanism 245 defined in [RFC5626], and it must support the CRLF keep-alive 246 mechanism defined in [RFC5626]. 248 When a SIP entity sends or forwards a request, if it wants to 249 negotiate the sending of keep-alives for the lifetime of a 250 registration, or a dialog, it MUST insert a "keep" parameter in its 251 Via header field of the request to indicate willingness to send keep- 252 alives. 254 When the SIP entity receives the associated response, if the "keep" 255 parameter in its Via header field of the response contains a "keep" 256 parameter value, it MUST start to send keep-alives towards the same 257 destination where it would send a subsequent request (e.g. REGISTER 258 requests and initial requests for dialog) associated with the 259 registration (if the keep-alive negotiation is for a registration), 260 or where it would send subsequent mid-dialog requests (if the keep- 261 alive negotiation is for a dialog). Subsequent mid-dialog requests 262 are addressed based on the dialog route set. 264 Once a SIP entity has negotiated sending of keep-alives associated 265 with a dialog towards an adjacent SIP entity, it MUST NOT insert a 266 "keep" parameter in any subsequent SIP requests, associated with the 267 dialog, towards that adjacent SIP entity. Such "keep" parameter MUST 268 be ignored, if received. 270 Since an ACK request does not have an associated response, it can not 271 be used to negotiate usage of keep-alives. Therefore, a SIP entity 272 MUST NOT insert a "keep" parameter in its Via header field of an ACK 273 request. Such "keep" parameter MUST be ignored, if received. 275 A SIP entity MUST NOT indicates willingness to send keep-alives 276 associated with a dialog, unless it has also inserted itself in the 277 dialog route set [RFC3261]. 279 NOTE: When a SIP entity sends an initial request for a dialog, if the 280 adjacent downstream SIP entity does not insert itself in the dialog 281 route set using a Record-Route header field [RFC3261], the adjacent 282 downstream SIP entity will change once the dialog route set has been 283 established. If a SIP entity inserts a "keep" parameter in its Via 284 header field of an initial request for a dialog, and the "keep" 285 parameter in the associated response does not contain a parameter 286 value, the SIP entity might choose to insert a "keep" parameter in 287 its Via header field of a subsequent SIP request associated with the 288 dialog, in case the new adjacent SIP downstream entity (based on the 289 dialog route set) is willing to receive keep-alives (in which case it 290 will add a parameter value to the "keep" parameter). 292 If an INVITE request is used to indicate willingness to send keep- 293 alives, as long as at least one response (provisional or final) to 294 the INVITE request contains a "keep" parameter with a parameter 295 value, it is seen as an indication that the adjacent downstream SIP 296 entity is willing to receive keep-alives associated with the dialog 297 on which the response is received. 299 A SIP entity that has negotiated sending of keep-alives associated 300 with a registration MUST be prepared to receive, from the receiver of 301 the keep-alives, SIP messages (requests and responses) associated 302 with the registration on the same IP port:address from where the 303 keep-alives are sent. If the SIP entity sends the keep-alives over a 304 connection-oriented transport protocol, it MUST be prepared to 305 receive SIP messages associated with the registration over the same 306 connection. The same rules apply for SIP messages associated with a 307 dialog, if the SIP entity has negotiated sending of keep-alives 308 associated with a dialog. 310 4.4. Behavior of a SIP entity willing to receive keep-alives 312 As defined in [RFC5626], a SIP entity that supports receiving of 313 keep-alives must act as a STUN server [RFC5389]. The SIP entity must 314 support those aspects of STUN that are required in order to apply the 315 STUN keep-alive mechanism defined in [RFC5626], and it must support 316 the CRLF keep-alive mechanism defined in [RFC5626]. 318 When a SIP entity sends or forwards a response, and the adjacent 319 upstream SIP entity indicated willingness to send keep-alives, if the 320 SIP entity is willing to receive keep-alives associated with the 321 registration, or the dialog, from the adjacent upstream SIP entity it 322 MUST add a parameter value to the "keep" parameter, before sending or 323 forwarding the response. The parameter can contain a recommended 324 keep-alive frequency, or a zero value. 326 When a SIP entity indicates willingness to receive keep-alives in a 327 response to an INVITE request, it MUST insert a "keep" parameter in 328 at least one reliable response to the request. The SIP entity MAY 329 insert an identical "keep" parameter value in other responses to the 330 same request. The SIP entity MUST NOT insert "keep" parameters with 331 differing values in responses to a single INVITE request. The SIP 332 entity SHOULD indicate the willingness to receive keep-alives as soon 333 as possible. 335 A SIP entity MUST NOT indicates willingness to receive keep-alives 336 associated with a dialog, unless it has also inserted itself in the 337 dialog route set [RFC3261]. 339 A SIP entity that has negotiated receiving of keep-alives associated 340 with a registration MUST send, towards the sender of the keep-alives, 341 SIP messages (requests and responses) associated with the 342 registration using the IP address:port from where the keep-alives are 343 received. If the SIP entity receives the keep-alives over a 344 connection-oriented transport protocol, it MUST send SIP messages 345 associated with the registration over the same connection, rather 346 than creating a new connection. The same rules apply for SIP 347 messages associated with a dialog, if the SIP entity has negotiated 348 receiving of keep-alives associated with a dialog. 350 5. Keep-alive frequency 352 If a SIP entity receives a SIP response, where its Via header field 353 contains a "keep" parameter with a non-zero value that indicates a 354 recommended keep-alive frequency, it MUST use the procedures defined 355 for the Flow-Timer header field [RFC5626]. According to the 356 procedures, the SIP entity must send keep-alives at least as often as 357 the indicated recommended keep-alive frequency, and if the SIP entity 358 uses the recommended keep-alive frequency then it should send its 359 keep-alives so that the interval between each keep-alive is randomly 360 distributed between 80% and 100% of the recommended keep-alive 361 frequency. 363 If the received "keep" parameter value is zero, the SIP entity can 364 send keep-alives at its discretion. [RFC5626] provides additional 365 guidance on selecting the keep-alive frequency in case a recommended 366 keep-alive frequency is not provided. 368 If a SIP entity that uses the "keep" parameter to indicate 369 willingness to receive keep-alives also inserts a Flow-Timer header 370 field (that can happen if the SIP entity is using both the Outbound 371 mechanism and the keep-alive mechanism) in the same SIP message, the 372 header field value and the "keep" parameter value MUST be identical. 374 SIP Outbound uses the Flow-Timer header field to indicate the server- 375 recommended keep-alive frequency. However, it will only be sent 376 between a UA and an edge proxy. Using the "keep" parameter, however, 377 the sending and receiving of keep-alives might be negotiated between 378 multiple entities on the signalling path. In addition, since the 379 server-recommended keep-alive frequency might vary between different 380 SIP entities, a single Flow-Timer header field can not be used to 381 indicate all the different frequency values, without forcing entities 382 to re-write the value of the Flow-Timer header field. 384 6. Examples 386 6.1. General 388 This section shows example flows where usage of keep-alives, 389 associated with a registration and a dialog, is negotiated between 390 different SIP entities. 392 6.2. Keep-alive negotiation associated with registration: UA-proxy 394 The figure shows an example where Alice sends an REGISTER request. 395 She indicates willingness of sending keep-alive by inserting a "keep" 396 parameter in her Via header field of the request. The edge proxy 397 (P1) forwards the request towards the registrar. 399 P1 is willing to receive keep-alives from Alice for the duration of 400 the registration, so When P1 receives the associated response it adds 401 a keep parameter value, which indicates a recommended keep-alive 402 frequency of 30 seconds, to Alice's Via header field, before it 403 forwards the response towards Alice. 405 When Alice receives the response, she determines from her Via header 406 field that P1 is willing to receive keep-alives associated with the 407 registration. For the lifetime of the registration, Alice then sends 408 periodic keep-alives (in this example using the STUN keep-alive 409 technique) towards P1, using the recommended keep-alive frequency 410 indicated by the keep parameter value. 412 Alice P1 REGISTRAR 413 | | | 414 |--- REGISTER------------->| | 415 | Via: Alice;keep | | 416 | |--- REGISTER-------------->| 417 | | Via: P1 | 418 | | Via: Alice;keep | 419 | | | 420 | |<-- 200 OK ----------------| 421 | | Via: P1 | 422 | | Via: Alice;keep | 423 |<-- 200 OK ---------------| | 424 | Via: Alice;keep=30 | | 425 | | | 426 | | | 427 | *** Timeout *** | 428 | | | 429 |=== STUN request ========>| | 430 |<== STUN response ========| | 431 | | | 432 | *** Timeout *** | 433 | | | 434 |=== STUN request ========>| | 435 |<== STUN response ========| | 436 | | | 438 Figure 1: Example call flow 440 6.3. Keep-alive negotiation associated with dialog: UA-proxy 442 The figure shows an example where Alice sends an initial INVITE 443 request for a dialog. She indicates willingness to send keep-alive 444 by inserting a "keep" parameter in her Via header field of the 445 request. The edge proxy (P1) adds itself to the dialog route set by 446 adding itself to a Record-Route header field, before it forwards the 447 request towards Bob. 449 P1 is willing to receive keep-alives from Alice for the duration of 450 the dialog, so When P1 receives the associated response it adds a 451 keep parameter value, which indicates a recommended keep-alive 452 frequency of 30 seconds, to Alice's Via header field, before it 453 forwards the response towards Alice. 455 When Alice receives the response, she determines from her Via header 456 field that P1 is willing to receive keep-alives associated with the 457 dialog. For the lifetime of the dialog, Alice then sends periodic 458 keep-alives (in this example using the STUN keep-alive technique) 459 towards P1, using the recommended keep-alive frequency indicated by 460 the keep parameter value. 462 Alice P1 Bob 463 | | | 464 |--- INVITE -------------->| | 465 | Via: Alice;keep | | 466 | |--- INVITE --------------->| 467 | | Via: P1 | 468 | | Via: Alice;keep | 469 | | Record-Route: P1 | 470 | | | 471 | |<-- 200 OK ----------------| 472 | | Via: P1 | 473 | | Via: Alice;keep | 474 | | Record-Route: P1 | 475 |<-- 200 OK ---------------| | 476 | Alice: UAC;keep=30 | | 477 | Record-Route: P1 | | 478 | | | 479 |--- ACK ----------------->| | 480 | | | 481 | |--- ACK ------------------>| 482 | | | 483 | *** Timeout *** | 484 | | | 485 |=== STUN request ========>| | 486 |<== STUN response ========| | 487 | | | 488 | *** Timeout *** | 489 | | | 490 |=== STUN request ========>| | 491 |<== STUN response ========| | 492 | | | 493 | | | 494 |--- BYE ----------------->| | 495 | | | 496 | |--- BYE ------------------>| 497 | | | 498 | |<-- 200 OK ----------------| 499 | | | 501 Figure 2: Example call flow 503 6.4. Keep-alive negotiation associated with dialog: UA-UA 505 The figure shows an example where Alice sends an initial INVITE 506 request for a dialog. She indicates willingness to send keep-alive 507 by inserting a "keep" parameter in her Via header field of the 508 request. The edge proxy (P1) does not add itself to the dialog route 509 set, by adding itself to a Record-Route header field, before it 510 forwards the request towards Bob. . 512 When Alice receives the response, she determines from her Via header 513 field that P1 is not willing to receive keep-alives associated with 514 the dialog from her. When the dialog route set has been established, 515 Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not 516 insert itself in the dialog route set), and she once again indicates 517 willingness to send keep-alives by inserting a "keep" parameter in 518 her Via header field of the request. Bob supports the keep-alive 519 mechanism, and is willing to receive keep-alives associated with the 520 dialog from Alice, so he creates a response and adds a keep parameter 521 value, which indicates a recommended keep-alive frequency of 30 522 seconds, to Alice's Via header field, before he forwards the response 523 towards Alice. 525 When Alice receives the response, she determines from her Via header 526 field that P1 is willing to receive keep-alives associated with the 527 dialog. For the lifetime of the dialog, Alice then sends periodic 528 keep-alives (in this example using the STUN keep-alive technique) 529 towards Bob, using the recommended keep-alive frequency indicated by 530 the keep parameter value. 532 Alice P1 Bob 533 | | | 534 |--- INVITE -------------->| | 535 | Via: Alice;keep | | 536 | |--- INVITE --------------->| 537 | | Via: P1 | 538 | | Via: Alice:keep | 539 | | | 540 | |<-- 200 OK ----------------| 541 | | Via: P1 | 542 | | Via: Alice;keep | 543 |<-- 200 OK ---------------| | 544 | Via: Alice;keep | | 545 | | | 546 | | 547 |--- ACK --------------------------------------------->| 548 | | 549 |--- UPDATE ------------------------------------------>| 550 | Via: Alice;keep | 551 | | 552 |<-- 200 OK ------------------------------------------>| 553 | Via: UAC;keep=30 | 554 | | 555 | | 556 | *** Timeout *** | 557 | | 558 |=== STUN request ====================================>| 559 |<== STUN response ====================================| 560 | | 561 | *** Timeout *** | 562 | | 563 |=== STUN request ====================================>| 564 |<== STUN response ====================================| 565 | | 566 | | 567 |--- BYE --------------------------------------------->| 568 | | 569 |<-- 200 OK -------------------------------------------| 570 | | 572 Figure 3: Example call flow 574 7. Grammar 576 This specification defines a new Via header field parameter, "keep". 577 The grammar includes the definitions from [RFC5626]. 579 The ABNF [RFC5234] is: 581 via-params =/ keep 583 keep = "keep" [ EQUAL 1*(DIGIT) ] 585 8. IANA Considerations 587 8.1. keep 589 This specification defines a new Via header field parameter called 590 keep in the "Header Field Parameters and Parameter Values" sub- 591 registry as per the registry created by [RFC5626]. The syntax is 592 defined in Section 7. The required information is: 594 Predefined 595 Header Field Parameter Name Values Reference 596 ---------------------- --------------------- ---------- --------- 597 Via keep No [RFCXXXX] 599 9. Security Considerations 601 This specification does not introduce security considerations in 602 addition to those specified in [RFC5626]. 604 10. Acknowledgements 606 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 607 and Milo Orsic for their comments on the initial draft. Thanks to 608 Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell and Paul 609 Kyzivat for their comments on the list. Thanks to Vijay Gurbani for 610 providing text (later removed) about the relationship with the 611 connect-reuse specification. 613 11. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 619 A., Peterson, J., Sparks, R., Handley, M., and E. 620 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 621 June 2002. 623 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 624 Specifications: ABNF", STD 68, RFC 5234, January 2008. 626 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 627 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 628 October 2008. 630 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 631 Initiated Connections in the Session Initiation Protocol 632 (SIP)", RFC 5626, October 2009. 634 Author's Address 636 Christer Holmberg 637 Ericsson 638 Hirsalantie 11 639 Jorvas 02420 640 Finland 642 Email: christer.holmberg@ericsson.com