idnits 2.17.1 draft-ietf-sipcore-reinvite-07.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2010) is 4907 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) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE G. Camarillo, Ed. 3 Internet-Draft C. Holmberg 4 Updates: 3261 (if approved) Ericsson 5 Intended status: Standards Track Y. Gao 6 Expires: May 23, 2011 ZTE 7 November 19, 2010 9 Re-INVITE and Target-refresh Request Handling in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-reinvite-07 13 Abstract 15 In this document, we clarify the handling of re-INVITEs in SIP. We 16 clarify in which situations a UAS (User Agent Server) should generate 17 a success response and in which situations a UAS should generate an 18 error response to a re-INVITE. Additionally, we clarify issues 19 related to target-refresh requests. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 23, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Changing the Session State During a Re-INVITE . . . . . . . . 4 58 3.1. Background on Re-INVITE Handling by UASs . . . . . . . . . 4 59 3.2. Problems with Error Responses and Already-executed 60 Changes . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.5. Glare Situations . . . . . . . . . . . . . . . . . . . . . 11 64 3.6. Example of UAS Behavior . . . . . . . . . . . . . . . . . 11 65 3.7. Example of UAC Behavior . . . . . . . . . . . . . . . . . 14 66 3.8. Clarifications on Cancelling Re-INVITEs . . . . . . . . . 16 67 4. Refreshing a Dialog's Targets . . . . . . . . . . . . . . . . 17 68 4.1. Background and Terminology on a Dialog's Targets . . . . . 17 69 4.2. Background on Target-refresh Requests . . . . . . . . . . 17 70 4.3. Clarification on the Atomicity of Target-Refresh 71 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 4.4. UA Updating the Dialog's Local Target in a Request . . . . 18 73 4.5. UA Updating the Dialog's Local Target in a Response . . . 19 74 4.6. A Request Updating the Dialog's Remote Target . . . . . . 19 75 4.7. A Response Updating the Dialog's Remote Target . . . . . . 20 76 4.8. Race Conditions and Target Refreshes . . . . . . . . . . . 20 77 4.9. Early Dialogs . . . . . . . . . . . . . . . . . . . . . . 20 78 5. A UA Losing its Contact . . . . . . . . . . . . . . . . . . . 21 79 5.1. Background on re-INVITE Transaction Routing . . . . . . . 21 80 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 21 81 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 22 82 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 23 83 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Introduction 94 As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request 95 sent within an existing dialog is known as a re-INVITE. A re-INVITE 96 is used to modify session parameters, dialog parameters, or both. 97 That is, a single re-INVITE can change both the parameters of its 98 associated session (e.g., changing the IP address where a media 99 stream is received) and the parameters of its associated dialog 100 (e.g., changing the remote target of the dialog). A re-INVITE can 101 change the remote target of a dialog because it is a target refresh 102 request, as defined in Section 6 of RFC 3261 [RFC3261]. 104 A re-INVITE transaction has an offer/answer [RFC3264] exchange 105 associated to it. The UAC (User Agent Client) generating a given re- 106 INVITE can act as the offerer or as the answerer. A UAC willing to 107 act as the offerer includes an offer in the re-INVITE. The UAS (User 108 Agent Server) then provides an answer in a response to the re-INVITE. 109 A UAC willing to act as answerer does not include an offer in the re- 110 INVITE. The UAS then provides an offer in a response to the re- 111 INVITE becoming, thus, the offerer. 113 Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] 114 transactions) can also have offer/answer exchanges associated to 115 them. A UA (User Agent) can act as the offerer or the answerer in 116 any of these transactions regardless of whether the UA was the 117 offerer or the answerer in the umbrella re-INVITE transaction. 119 There has been some confusion among implementors regarding how a UAS 120 should handle re-INVITEs. In particular, implementors requested 121 clarification on which type of response a UAS should generate in 122 different situations. In this document, we clarify these issues. 124 Additionally, there has also been some confusion among implementors 125 regarding target refresh requests, which include but are not limited 126 to re-INVITEs. In this document, we also clarify the process by 127 which remote targets are refreshed. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 UA: User Agent. 137 UAC: User Agent Client. 139 UAS: User Agent Server. 141 Note that the terms UAC and UAS are used with respect to an INVITE 142 or re-INVITE transaction and do not necessarily reflect the role 143 of the UA concerned with respect to any other transaction, such as 144 an UPDATE transaction occurring within the INVITE transaction. 146 3. Changing the Session State During a Re-INVITE 148 The following sections discuss how to change the state of the session 149 during a re-INVITE transaction. 151 3.1. Background on Re-INVITE Handling by UASs 153 A UAS receiving a re-INVITE will need to, eventually, generate a 154 response to it. Some re-INVITEs can be responded to immediately 155 because their handling does not require user interaction (e.g., 156 changing the IP address where a media stream is received). The 157 handling of other re-INVITEs requires user interaction (e.g., adding 158 a video stream to an audio-only session). Therefore, these re- 159 INVITEs cannot be responded to immediately. 161 An error response to a re-INVITE has the following semantics. As 162 specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is 163 rejected, no state changes are performed. These state changes 164 include state changes associated to the re-INVITE transaction and all 165 other transactions within the re-INVITE (this section deals with 166 changes to the session state; target refreshes are discussed in 167 Section 4.2). That is, the session state is the same as before the 168 re-INVITE was received. The example in Figure 1 illustrates this 169 point. 171 UAC UAS 173 | | 174 |-------------(1) INVITE SDP1--------------->| 175 | | 176 |<------------(2) 200 OK SDP2----------------| 177 | | 178 |------------------(3) ACK------------------>| 179 | | 180 | | 181 |-------------(4) INVITE SDP3--------------->| 182 | | 183 |<-----------------(5) 4xx-------------------| 184 | | 185 |------------------(6) ACK------------------>| 186 | | 188 Figure 1: Rejection of a re-INVITE 190 The UAs perform an offer/answer exchange to establish an audio-only 191 session: 193 SDP1: 194 m=audio 30000 RTP/AVP 0 196 SDP2: 197 m=audio 31000 RTP/AVP 0 199 At a later point, the UAC sends a re-INVITE (4) in order to add a 200 video stream to the session. 202 SDP3: 203 m=audio 30000 RTP/AVP 0 204 m=video 30002 RTP/AVP 31 206 The UAS is configured to automatically reject video streams. 207 Consequently, the UAS returns an error response (5). At that point, 208 the session parameters in use are still those resulting from the 209 initial offer/answer exchange, which are described by SDP1 and SDP2. 210 That is, the session state is the same as before the re-INVITE was 211 received. 213 In the previous example, the UAS rejected all the changes requested 214 in the re-INVITE by returning an error response. However, there are 215 situations where a UAS wants to accept some but not all the changes 216 requested in a re-INVITE. In these cases, the UAS generates a 200 217 (OK) response with an SDP indicating which changes were accepted and 218 which were not. The example in Figure 2 illustrates this point. 220 UAC UAS 222 | | 223 |-------------(1) INVITE SDP1--------------->| 224 | | 225 |<------------(2) 200 OK SDP2----------------| 226 | | 227 |------------------(3) ACK------------------>| 228 | | 229 | | 230 |-------------(4) INVITE SDP3--------------->| 231 | | 232 |<------------(5) 200 OK SDP4----------------| 233 | | 234 |------------------(6) ACK------------------>| 235 | | 237 Figure 2: Automatic rejection of a video stream 239 The UAs perform an offer/answer exchange to establish an audio only 240 session: 242 SDP1: 243 m=audio 30000 RTP/AVP 0 244 c=IN IP4 192.0.2.1 246 SDP2: 247 m=audio 31000 RTP/AVP 0 248 c=IN IP4 192.0.2.5 250 At a later point, the UAC moves to an access that provides a higher- 251 bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to 252 change the IP address where it receives the audio stream to its new 253 IP address and add a video stream to the session. 255 SDP3: 256 m=audio 30000 RTP/AVP 0 257 c=IN IP4 192.0.2.2 258 m=video 30002 RTP/AVP 31 259 c=IN IP4 192.0.2.2 261 The UAS is automatically configured to reject video streams. 262 However, the UAS needs to accept the change of the audio stream's 263 remote IP address. Consequently, the UAS returns a 200 (OK) response 264 and sets the port of the video stream to zero in its SDP. 266 SDP4: 267 m=audio 31000 RTP/AVP 0 268 c=IN IP4 192.0.2.5 269 m=video 0 RTP/AVP 31 271 In the previous example, the UAS was configured to automatically 272 reject the addition of video streams. The example in Figure 3 273 assumes that the UAS requires its user's input in order to accept or 274 reject the addition of a video stream and uses reliable provisional 275 responses [RFC3262] (PRACK transactions are not shown for clarity). 277 UAC UAS 279 | | 280 |-------------(1) INVITE SDP1--------------->| 281 | | 282 |<------------(2) 200 OK SDP2----------------| 283 | | 284 |------------------(3) ACK------------------>| 285 | | 286 | | 287 |-------------(4) INVITE SDP3--------------->| 288 | | 289 |<----(5) 183 Session Progress SDP4----------| 290 | | 291 | | 292 |<------------(6) UPDATE SDP5----------------| 293 | | 294 |-------------(7) 200 OK SDP6--------------->| 295 | | 296 |<---------------(8) 200 OK------------------| 297 | | 298 |------------------(9) ACK------------------>| 299 | | 301 Figure 3: Manual rejection of a video stream by the user 303 Everything up to (4) is identical to the previous example. In (5), 304 the UAS accepts the change of the audio stream's remote IP address 305 but does not accept the video stream yet (it provides a null IP 306 address instead of setting the stream to 'inactive' because inactive 307 streams still need to exchange RTCP traffic). 309 SDP4: 310 m=audio 31000 RTP/AVP 0 311 c=IN IP4 192.0.2.5 312 m=video 31002 RTP/AVP 31 313 c=IN IP4 0.0.0.0 315 At a later point, the UAS's user rejects the addition of the video 316 stream. Consequently, the UAS sends an UPDATE request (6) setting 317 the port of the video stream to zero in its offer. 319 SDP5: 320 m=audio 31000 RTP/AVP 0 321 c=IN IP4 192.0.2.5 322 m=video 0 RTP/AVP 31 323 c=IN IP4 0.0.0.0 325 The UAC returns a 200 (OK) response (7) to the UPDATE with the 326 following answer: 328 SDP6: 329 m=audio 30000 RTP/AVP 0 330 c=IN IP4 192.0.2.2 331 m=video 0 RTP/AVP 31 333 The UAS now returns a 200 (OK) response (8) to the re-INVITE. 335 In all the previous examples, the UAC of the re-INVITE transaction 336 was the offerer. Examples with UACs acting as the answerers would be 337 similar. 339 3.2. Problems with Error Responses and Already-executed Changes 341 Section 3.1 contains examples on how a UAS rejects all the changes 342 requested in a re-INVITE without executing any of them by returning 343 an error response (Figure 1), and how a UAS executes some of the 344 changes requested in a re-INVITE and rejects some of them by 345 returning a 2xx response (Figure 2 and Figure 3). A UAS can accept 346 and reject different sets of changes simultaneously (Figure 2) or at 347 different times (Figure 3). 349 The scenario that created confusion among implementors consists of a 350 UAS that receives a re-INVITE, executes some of the changes requested 351 in it, and then wants to reject all those already-executed changes 352 and revert to the pre-re-INVITE state. Such a UAS may consider 353 returning an error response to the re-INVITE (the message flow would 354 be similar to the one in Figure 1), or using an UPDATE request to 355 revert to the pre-re-INVITE state and then returning a 2xx response 356 to the re-INVITE (the message flow would be similar to the one in 357 Figure 3). This section explains the problems associated with 358 returning an error response in these circumstances. In order to 359 avoid these problems, the UAS should use the latter option (UPDATE 360 request plus a 2xx response). Section 3.3 and Section 3.4 contain 361 the normative statements needed to avoid these problems. 363 The reason for not using an error response to undo already executed 364 changes is that an error response to a re-INVITE for which changes 365 have already been executed (e.g., as a result of UPDATE transactions 366 or reliable provisional responses) is effectively requesting a change 367 in the session state. However, the UAC has no means to reject that 368 change if it is unable to execute them. That is, if the UAC is 369 unable to revert to the pre-re-INVITE state, it will not be able to 370 communicate this fact to the UAS. 372 3.3. UAS Behavior 374 UASs should only return an error response to a re-INVITE if no 375 changes to the session state have been executed since the re-INVITE 376 was received. Such an error response indicates that no changes have 377 been executed as a result of the re-INVITE or any other transaction 378 within it. 380 If any of the changes requested in a re-INVITE or in any transaction 381 within it have already been executed, the UAS SHOULD return a 2xx 382 response. 384 A change to the session state is considered to have been executed if 385 an offer/answer without preconditions [RFC4032] for the stream has 386 completed successfully or the UA has sent or received media using the 387 new parameters. Connection establishment messages (e.g., TCP SYN), 388 connectivity checks (e.g., when using ICE [RFC5245]), and any other 389 messages used in the process of meeting the preconditions for a 390 stream are not considered media. 392 Normally, a UA receiving media can easily detect when the new 393 parameters for the media stream are used (e.g,. media is received 394 on a new port). However, in some scenarios the UA will have to 395 process incoming media packets in order to detect whether they use 396 the old or the new parameters. 398 The successful completion of an offer/answer exchange without 399 preconditions indicates that the new parameters for the media stream 400 are already considered to be in use. The successful completion of an 401 offer/answer exchange with preconditions means something different. 402 The fact that all mandatory preconditions for the stream are met 403 indicates that the new parameters for the media stream are ready to 404 be used. However, they will not actually be used until the UAS 405 decides so. During a session establishment, the UAS can wait before 406 using the media parameters until the callee starts being alerted or 407 until the callee accepts the session. During a session modification, 408 the UAS can wait until its user accepts the changes to the session. 409 When dealing with streams where the UAS sends media more or less 410 continuously, the UAC notices that the new parameters are in use 411 because the UAC receives media that uses the new parameters. 412 However, this mechanism does not work with other types of streams. 413 Therefore, it is RECOMMENDED that when a UAS decides to start using 414 the new parameters for a stream for which all mandatory preconditions 415 have been met, the UAS either sends media using the new parameters or 416 sends a new offer where the precondition-related attributes for the 417 stream have been removed. As indicated above, the successful 418 completion of an offer/answer exchange without preconditions 419 indicates that the new parameters for the media stream are already 420 considered to be in use. 422 3.4. UAC Behavior 424 A UAC that receives an error response to a re-INVITE that undoes 425 already-executed changes within the re-INVITE may be facing a legacy 426 UAS that does not support this specification (i.e., a UAS that does 427 not follow the guidelines in Section 3.3). There are also certain 428 race condition situations that get both user agents out of 429 synchronization. In order to cope with these race condition 430 situations, a UAC that receives an error response to a re-INVITE for 431 which changes have been already executed SHOULD generate a new re- 432 INVITE or UPDATE request in order to make sure that both UAs have a 433 common view of the state of the session (the UAC uses the criteria in 434 Section 3.3 in order to decide whether or not changes have been 435 executed for a particular stream). The purpose of this new offer/ 436 answer exchange is to synchronize both UAs, not to request changes 437 that the UAS may choose to reject. Therefore, session parameters in 438 the offer/answer exchange SHOULD be as close to those in the pre-re- 439 INVITE state as possible. 441 3.5. Glare Situations 443 Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user 444 agent receiving an offer after having sent one but before having 445 received an answer to it. That section specifies rules to avoid 446 glare situations in most cases. When despite following those rules a 447 glare conditions occurs (as a result of a race condition), it is 448 handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. 449 The UAS returns a 491 (Request Pending) response and the UAC retries 450 the offer after a randomly-selected time, which depends on which user 451 agent is the owner of the Call-ID of the dialog. The rules in RFC 452 3261 [RFC3261] not only cover collisions between re-INVITEs that 453 contain offers; they cover collisions between two re-INVITEs in 454 general, even if they do not contain offers. Sections 5.2 and 5.3 of 455 RFC 3311 [RFC3311] extend those rules to also cover collisions 456 between an UPDATE request carrying an offer and another message 457 (UPDATE, PRACK or INVITE) also carrying an offer. 459 The rules in RFC 3261 [RFC3261] do not cover collisions between an 460 UPDATE request and a non-2xx final response to a re-INVITE. Since 461 both the UPDATE request and the reliable response could be requesting 462 changes to the session state, it would not be clear which changes 463 would need to be executed first. However, the procedures discussed 464 in Section 3.4 already cover this type of situation. Therefore, 465 there is no need to specify further rules here. 467 3.6. Example of UAS Behavior 469 This section contains an example of a UAS that implements this 470 specification using an UPDATE request and a 2xx response to a re- 471 INVITE in order to revert to the pre-re-INVITE state. The example, 472 which is shown in Figure 4, assumes that the UAS requires its user's 473 input in order to accept or reject the addition of a video stream and 474 uses reliable provisional responses [RFC3262] (PRACK transactions are 475 not shown for clarity). 477 UAC UAS 479 | | 480 |-------------(1) INVITE SDP1--------------->| 481 | | 482 |<------------(2) 200 OK SDP2----------------| 483 | | 484 |------------------(3) ACK------------------>| 485 | | 486 | | 487 |-------------(4) INVITE SDP3--------------->| 488 | | 489 |<----(5) 183 Session Progress SDP4----------| 490 | | 491 |-------------(6) UPDATE SDP5--------------->| 492 | | 493 |<------------(7) 200 OK SDP6----------------| 494 | | 495 | | 496 |<------------(8) UPDATE SDP7----------------| 497 | | 498 |-------------(9) 200 OK SDP8--------------->| 499 | | 500 |<--------------(10) 200 OK------------------| 501 | | 502 |-----------------(11) ACK------------------>| 503 | | 505 Figure 4: Rejection of a video stream by the user 507 The UAs perform an offer/answer exchange to establish an audio only 508 session: 510 SDP1: 511 m=audio 30000 RTP/AVP 0 512 c=IN IP4 192.0.2.1 514 SDP2: 515 m=audio 31000 RTP/AVP 0 516 c=IN IP4 192.0.2.5 518 At a later point, the UAC sends a re-INVITE (4) in order to add a new 519 codec to the audio stream and to add a video stream to the session. 521 SDP3: 522 m=audio 30000 RTP/AVP 0 3 523 c=IN IP4 192.0.2.1 524 m=video 30002 RTP/AVP 31 525 c=IN IP4 192.0.2.1 527 In (5), the UAS accepts the addition of the audio codec but does not 528 accept the video stream yet (it provides a null IP address instead of 529 setting the stream to 'inactive' because inactive streams still need 530 to exchange RTCP traffic). 532 SDP4: 533 m=audio 31000 RTP/AVP 0 3 534 c=IN IP4 192.0.2.5 535 m=video 31002 RTP/AVP 31 536 c=IN IP4 0.0.0.0 538 At a later point, the UAC sends an UPDATE request (6) to remove the 539 original audio codec from the audio stream (the UAC could have also 540 used the PRACK to (5) to request this change). 542 SDP5: 543 m=audio 30000 RTP/AVP 3 544 c=IN IP4 192.0.2.1 545 m=video 30002 RTP/AVP 31 546 c=IN IP4 192.0.2.1 548 SDP6: 549 m=audio 31000 RTP/AVP 3 550 c=IN IP4 192.0.2.5 551 m=video 31002 RTP/AVP 31 552 c=IN IP4 0.0.0.0 554 Yet at a later point, the UAS's user rejects the addition of the 555 video stream. Additionally, the UAS decides to revert to the 556 original audio codec. Consequently, the UAS sends an UPDATE request 557 (8) setting the port of the video stream to zero and offering the 558 original audio codec in its SDP. 560 SDP7: 561 m=audio 31000 RTP/AVP 0 562 c=IN IP4 192.0.2.5 563 m=video 0 RTP/AVP 31 564 c=IN IP4 0.0.0.0 566 The UAC accepts the change in the audio codec in its 200 (OK) 567 response (9) to the UPDATE request. 569 SDP8: 570 m=audio 30000 RTP/AVP 0 571 c=IN IP4 192.0.2.1 572 m=video 0 RTP/AVP 31 573 c=IN IP4 192.0.2.1 575 The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note 576 that the media state after this 200 (OK) response is the same as the 577 pre-re-INVITE media state. 579 3.7. Example of UAC Behavior 581 Figure 5 shows an example of a race condition situation in which the 582 UAs end up with different views of the state of the session. The UAs 583 in Figure 5 are involved in a session that, just before the message 584 flows in the figures starts, includes a sendrecv audio stream and an 585 inactive video stream. UA1 sends a re-INVITE (1) requesting to make 586 the video stream sendrecv. 588 SDP1: 589 m=audio 20000 RTP/AVP 0 590 a=sendrecv 591 m=video 20002 RTP/AVP 31 592 a=sendrecv 594 UA2 is configured to automatically accept incoming video streams but 595 to ask for user input before generating an outgoing video stream. 596 Therefore, UAS2 makes the video stream recvonly by returning a 183 597 (Session Progress) response (2). 599 SDP2: 600 m=audio 30000 RTP/AVP 0 601 a=sendrecv 602 m=video 30002 RTP/AVP 31 603 a=recvonly 605 When asked for input, UA2's user chooses not to have either incoming 606 or outgoing video. In order to make the video stream inactive, UA2 607 returns a 4xx error response (5) to the re-INVITE. The ACK request 608 (6) for this error response is generated by the proxy between both 609 user agents. Note that this error response undoes already-executed 610 changes. So, UA2 is a legacy UA that does not support this 611 specification. 613 The proxy relays the 4xx response (7) towards UA1. However, the 4xx 614 response (7) takes time to arrive to UA1 (e.g., the response may have 615 been sent over UDP and the first few retransmissions were lost). In 616 the meantime, UA2's user decides to put the audio stream on hold. 617 UA2 sends an UPDATE request (8) making the audio stream recvonly. 618 The video stream, which is inactive, is not modified and, thus, 619 continues being inactive. 621 SDP3: 622 m=audio 30000 RTP/AVP 0 623 a=recvonly 624 m=video 30002 RTP/AVP 31 625 a=inactive 627 The proxy relays the UPDATE request (9) to UA1. The UPDATE request 628 (9) arrives at UA1 before the 4xx response (7) that had been 629 previously sent. UA1 accepts the changes in the UPDATE request and 630 returns a 200 (OK) response (10) to it. 632 SDP4: 633 m=audio 20000 RTP/AVP 0 634 a=sendonly 635 m=video 30002 RTP/AVP 31 636 a=inactive 638 At a later point, the 4xx response (7) finally arrives at UA1. This 639 response makes the session return to its pre-re-INVITE state. 640 Therefore, for UA1, the audio stream is sendrecv and the video stream 641 is inactive. However, for UA2, the audio stream is recvonly (the 642 video stream is also inactive). 644 a:sendrecv a:sendrecv 645 v:inactive v:inactive 647 UA1 Proxy UA2 649 | | | 650 |----(1) INVITE SDP1-->| | 651 | |----(2) INVITE SDP1-->| 652 | | | 653 | |<----(3) 183 SDP2-----| a:sendrecv 654 a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly 655 v:sendonly | | | 656 | |<------(5) 4xx -------| 657 | |-------(6) ACK ------>| a:sendrecv 658 | +-(7) 4xx -| | v:inactive 659 | | |<---(8) UPDATE SDP3---| 660 |<---(9) UPDATE SDP3---| | 661 | | | | 662 a:sendonly |---(10) 200 OK SDP4-->| | 663 v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly 664 |<-(7) 4xx -+ | | v:inactive 665 a:sendrecv |------(12) ACK ------>| | 666 v:inactive | | | 668 a: status of the audio stream 669 v: status of the video stream 671 Figure 5: Message flow with race condition 673 After the message flow in Figure 5, following the recommendations in 674 this section, when UA1 received an error response (7) that undid 675 already-executed changes, UA1 would generate an UPDATE request with 676 an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and 677 inactive video). UA2 could then return a 200 (OK) response to the 678 UPDATE request making the audio stream recvonly, which is the state 679 UA2's user had requested. Such an UPDATE transaction would get the 680 UAs back into synchronization. 682 3.8. Clarifications on Cancelling Re-INVITEs 684 Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS 685 responding to a CANCEL request. Such a UAS responds to the INVITE 686 request with a 487 (Request Terminated) at the 'should' level. Per 687 the rules specified in Section 3.3, if the INVITE request was a re- 688 INVITE and some of its requested changes had already been executed, 689 the UAS would return a 2xx response instead. 691 4. Refreshing a Dialog's Targets 693 The following sections discuss how to refresh the targets of a 694 dialog. 696 4.1. Background and Terminology on a Dialog's Targets 698 As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a 699 dialog stores the dialog's remote target as part of the dialog's 700 state information the UA keeps. Consequently, each of the two UAs 701 involved in a dialog store a dialog's remote target. In this 702 document, we define a new term: a dialog's local target. A dialog's 703 local target is the dialog's remote target the remote UA stores. 704 Thus, the dialog's local target for a UA is the dialog's remote 705 target for the other UA. Similarly, the dialog's remote target for a 706 UA is the dialog's local target for the other UA. The use of this 707 new term is intended to add clarity to the following discussions. 709 4.2. Background on Target-refresh Requests 711 A target-refresh request is defined as follows in Section 6 of RFC 712 3261 [RFC3261]: 714 "A target-refresh request sent within a dialog is defined as a 715 request that can modify the remote target of the dialog." 717 Additionally, 2xx responses to target-refresh requests can also 718 update the remote target of the dialog. As discussed in Section 12.2 719 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. 721 RFC 3261 [RFC3261] specifies the behavior of UASs receiving target- 722 refresh requests and of UACs receiving a 2xx response for a target- 723 refresh request. 725 Section 12.2.2 of RFC 3261 [RFC3261] says: 727 "When a UAS receives a target-refresh request, it MUST replace the 728 dialog's remote target URI with the URI from the Contact header 729 field in that request, if present." 731 Section 12.2.1.2 of RFC 3261 [RFC3261] says: 733 "When a UAC receives a 2xx response to a target-refresh request, 734 it MUST replace the dialog's remote target URI with the URI from 735 the Contact header field in that response, if present." 737 The fact that re-INVITEs can be long-lived transactions and can have 738 other transactions within them makes it necessary to revise these 739 rules. Section 4.3 specifies new rules for the handing of target- 740 refresh requests. Note that the new rules apply to any target- 741 refresh request, not only to re-INVITEs. 743 4.3. Clarification on the Atomicity of Target-Refresh Requests 745 The local and remote targets of a dialog are special types of state 746 information because of their essential role in the exchange of SIP 747 messages between UAs in a dialog. A UA involved in a dialog receives 748 the remote target of the dialog from the remote UA. The UA uses the 749 received remote target to send SIP requests to the remote UA. 751 The dialog's local target is a piece of state information that is not 752 meant to be negotiated. When a UA changes its local target (i.e., 753 the UA changes its IP address), the UA simply communicates its new 754 local target to the remote UA (e.g., the UA communicates its new IP 755 address to the remote UA in order to remain reachable by the remote 756 UA). UAs need to follow the behavior specified in Section 4.4, 757 Section 4.5, Section 4.6, and Section 4.7 of this specification 758 instead of that specified in RFC 3261 [RFC3261], which was discussed 759 in Section 4.2. The new behavior regarding target-refresh requests 760 implies that a target-refresh request can, in some cases, update the 761 remote target even if the request is responded with a final error 762 response. This means that target-refresh requests are not atomic. 764 4.4. UA Updating the Dialog's Local Target in a Request 766 In order to update its local target, a UA can send a target-refresh 767 request. If the UA receives an error response to the target-refresh 768 request, the remote UA has not updated its remote target. 770 This allows UASs to authenticate target-refresh requests (see 771 Section 26.2 of RFC 3261 [RFC3261]). 773 If the UA receives a reliable provisional response or a 2xx response 774 to the target-refresh request, or the UA receives an in-dialog 775 request on the new local target, the remote UA has updated its remote 776 target. The UA can consider the target refresh operation completed. 778 Even if the target request was a re-INVITE and the final response 779 to the re-INVITE was an error response, the UAS would not revert 780 to the pre-re-INVITE remote target. 782 A UA SHOULD NOT use the same target refresh request to refresh the 783 target and to make session changes unless the session changes can be 784 trivially accepted by the remote UA (e.g., an IP address change). 785 Piggybacking a target refresh with more complicated session changes 786 would make it unnecessarily complicated for the remote UA to accept 787 the target refresh while rejecting the session changes. Only in case 788 the target refresh request is a re-INVITE and the UAS supports 789 reliable provisional response or UPDATE requests, the UAC MAY 790 piggyback session changes and a target refresh in the same re-INVITE. 792 4.5. UA Updating the Dialog's Local Target in a Response 794 A UA processing an incoming target refresh request can update its 795 local target by returning a reliable provisional response or a 2xx 796 response to the target-refresh request. The response needs to 797 contain the updated local target URI in its Contact header field. On 798 sending the response, the UA can consider the target refresh 799 operation completed. 801 4.6. A Request Updating the Dialog's Remote Target 803 Behavior of a UA after having received a target-refresh request 804 updating the remote target: 806 If the UA receives a target-refresh request that has been properly 807 authenticated (see Section 26.2 of RFC 3261 [RFC3261]), the UA SHOULD 808 generate a reliable provisional response or a 2xx response to the 809 target-refresh request. If generating such responses is not possible 810 (e.g., the UA does not support reliable provisional responses and 811 needs user input before generating a final response), the UA SHOULD 812 send an in-dialog request to the remote UA using the new remote 813 target (if the UA does not need to send a request for other reasons, 814 the UAS can send an UPDATE request). On sending a reliable 815 provisional response or a 2xx response to the target-refresh request, 816 or a request to the new remote target, the UA MUST replace the 817 dialog's remote target URI with the URI from the Contact header field 818 in the target-refresh request. 820 Reliable provisional responses in SIP are specified in RFC 3262 821 [RFC3262]. In this document, reliable provisional responses are 822 those that use the mechanism defined in RFC 3262 [RFC3262]. Other 823 specifications may define ways to send provisional responses 824 reliably using non-SIP mechanisms (e.g., using media-level 825 messages to acknowledge the reception of the SIP response). For 826 the purposes of this document, provisional responses using those 827 non-SIP mechanisms are considered unreliable responses. Note that 828 non-100 provisional responses are only applicable to INVITE 829 transactions [RFC4320]. 831 If instead of sending a reliable provisional response or a 2xx 832 response to the target-refresh request, or a request to the new 833 target, the UA generates an error response to the target-refresh 834 request, the UA MUST NOT update its dialog's remote target. 836 4.7. A Response Updating the Dialog's Remote Target 838 If a UA receives a reliable provisional response or a 2xx response to 839 a target-refresh request, the UA MUST replace the dialog's remote 840 target URI with the URI from the Contact header field in that 841 response, if present. 843 If a UA receives an unreliable provisional response to a target- 844 refresh request, the UA MUST NOT refresh the dialog's remote target. 846 4.8. Race Conditions and Target Refreshes 848 SIP provides request ordering by using the Cseq header field. That 849 is, a UA that receives two requests at roughly the same time can know 850 which one is newer. However, SIP does not provide ordering between 851 responses and requests. For example, if a UA receives a 200 (OK) 852 response to an UPDATE request and an UPDATE request at roughly the 853 same time, the UA cannot know which one was sent last. Since both 854 messages can refresh the remote target, the UA needs to know which 855 message was sent last in order to know which remote target needs to 856 be used. 858 This document specifies the following rule to avoid the situation 859 just described. If the protocol allows a UA to use a target-refresh 860 request at the point in time that UA wishes to refresh its local 861 target, the UA MUST use a target-refresh request instead of a 862 response to refresh its local target. This rule implies that a UA 863 only uses a response (i.e., a reliable provisional response or a 2xx 864 response to a target-refresh request) to refresh its local target if 865 the UA is unable to use a target-refresh request at that point in 866 time (e.g., the UAS of an ongoing re-INVITE without support for 867 UPDATE). 869 4.9. Early Dialogs 871 The rules given in this section about which messages can refresh the 872 target of a dialog also apply to early dialogs created by an initial 873 INVITE transaction. Additionally, as specified in Section 13.2.2.4 874 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial 875 INVITE, the UAC recomputes the whole route set of the dialog, which 876 transitions from the "early" state to the "confirmed" state. 878 Section 12.1 of RFC 3261 allows unreliable provisional responses to 879 create early dialogs. However, per the rules given in this section, 880 unreliable provisional responses cannot refresh the target of a 881 dialog. Therefore, the UAC of an initial INVITE transaction will not 882 perform any target refresh as a result of the reception of an 883 unreliable provisional response with an updated Contact value on an 884 (already-established) early dialog. Note also that a given UAS can 885 establish additional early dialogs, which can have different targets, 886 by returning additional unreliable provisional responses with 887 different To tags. 889 5. A UA Losing its Contact 891 The following sections discuss the case where a UA loses its 892 transport address during an ongoing re-INVITE transaction. Such a UA 893 will refresh the dialog's local target so that it reflects its new 894 transport address. Note that target refreshes that do not involve 895 changes in the UA's transport address are outside of the scope of 896 this section. Also, UAs losing their transport address during a non- 897 re-INVITE transaction (e.g., a UA losing its transport address right 898 after having sent an UPDATE request before having received a response 899 to it) are out of scope as well. 901 The rules given in this section are also applicable to initial INVITE 902 requests that have established early dialogs. 904 5.1. Background on re-INVITE Transaction Routing 906 Re-INVITEs are routed using the dialog's route set, which contains 907 all the proxy servers that need to be traversed by requests sent 908 within the dialog. Responses to the re-INVITE are routed using the 909 Via entries in the re-INVITE. 911 ACK requests for 2xx responses and for non-2xx final responses are 912 generated in different ways. As specified in Sections 14.1 and 913 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are 914 generated by the UAC core and are routed using the dialog's route 915 set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK 916 requests for non-2xx final responses are generated by the INVITE 917 client transaction (i.e., they are generated in a hop-by-hop fashion 918 by the proxy servers in the path) and are sent to the same transport 919 address as the re-INVITE. 921 5.2. Problems with UAs Losing their Contact 923 Refreshing the dialog's remote target during a re-INVITE transaction 924 (see Section 4.3) presents some issues because of the fact that re- 925 INVITE transactions can be long lived. As described in Section 5.1, 926 the way responses to the re-INVITE and ACKs for non-2xx final 927 responses are routed is fixed once the re-INVITE is sent. The 928 routing of this messages does not depend on the dialog's route set 929 and, thus, target refreshes within an ongoing re-INVITE do not affect 930 their routing. A UA that changes its location (i.e., performs a 931 target refresh) but is still reachable at its old location will be 932 able to receive those messages (which will be sent to the old 933 location). However, a UA that cannot be reachable at its old 934 location any longer will not be able to receive them. 936 The following sections describe the errors UAs face when they lose 937 their transport address during a re-INVITE. On detecting some of 938 these errors, UAs following the rules specified in RFC 3261 [RFC3261] 939 will terminate the dialog. When the dialog is terminated, the only 940 option for the UAs is to establish a new dialog. The following 941 sections change the requirements RFC 3261 [RFC3261] places on UAs 942 when certain errors occur so that the UAs can recover from those 943 errors. In short, the UAs generate a new re-INVITE transaction to 944 synchronize both UAs. Note that there are existing UA 945 implementations deployed that already implement this behavior. 947 5.3. UAS Losing its Contact: UAC Behavior 949 When a UAS that moves to a new contact and loses its old contact 950 generates a non-2xx final response to the re-INVITE, it will not be 951 able to receive the ACK request. The entity receiving the response 952 and, thus, generating the ACK request will either get a transport 953 error or a timeout error, which, as described in Section 8.1.3.1 of 954 RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) 955 response and as a 408 (Request Timeout) response, respectively. If 956 the sender of the ACK request is a proxy server, it will typically 957 ignore this error. If the sender of the ACK request is the UAC, 958 according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed 959 to (at the "should" level) terminate the dialog by sending a BYE 960 request. However, because of the special properties of ACK requests 961 for non-2xx final responses, most existing UACs do not terminate the 962 dialog when ACK request fails, which is fortunate. 964 A UAC that accepts a target refresh within a re-INVITE MUST ignore 965 transport and timeout errors when generating an ACK request for a 966 non-2xx final response. Additionally, UAC SHOULD generate a new re- 967 INVITE in order to make sure that both UAs have a common view of the 968 state of the session. 970 It is possible that the errors ignored by the UAC were not related 971 to the target refresh operation. If that was the case, the second 972 re-INVITE would fail and the UAC would terminate the dialog 973 because, per the rules above, UACs only ignore errors when they 974 accept a target refresh within the re-INVITE. 976 5.4. UAC Losing its Contact: UAS Behavior 978 When a UAC moves to a new contact and loses its old contact, it will 979 not be able to receive responses to the re-INVITE. Consequently, it 980 will never generate an ACK request. 982 As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server 983 that gets an error when forwarding a response does not take any 984 measures. Consequently, proxy servers relaying responses will 985 effectively ignore the error. 987 If there are no proxy servers in the dialog's route set, the UAS will 988 get an error when sending a non-2xx final response. The UAS core 989 will be notified of the transaction failure, as described in Section 990 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate 991 the dialog on encountering this failure, which is fortunate. 993 Regardless of the presence or absence of proxy servers in the 994 dialog's route set, a UAS generating a 2xx response to the re-INVITE 995 will never receive an ACK request for it. According to Section 14.2 996 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" 997 level) terminate the dialog by sending a BYE request. 999 A UAS that accepts a target refresh within a re-INVITE and never 1000 receives an ACK request after having sent a final response to the re- 1001 INVITE SHOULD NOT terminate the dialog if the UA has received a new 1002 re-INVITE with a higher CSeq sequence number than the original one. 1004 5.5. UAC Losing its Contact: UAC Behavior 1006 When a UAC moves to a new contact and loses its old contact, it will 1007 not be able to receive responses to the re-INVITE. Consequently, it 1008 will never generate an ACK request. 1010 Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE 1011 and cause the INVITE client transaction corresponding to the re- 1012 INVITE to enter the "Terminated" state. The UAC SHOULD also send a 1013 new re-INVITE in order to make sure that both UAs have a common view 1014 of the state of the session. 1016 Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new 1017 incoming re-INVITEs as soon as it has generated a final response 1018 to the previous INVITE request, which had a lower CSeq sequence 1019 number. 1021 6. Security Considerations 1023 This document does not introduce any new security issue. It just 1024 clarifies how certain transactions should be handled in SIP. 1025 Security issues related to re-INVITEs and UPDATE requests are 1026 discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. 1028 In particular, in order not to reduce the security level for a given 1029 session, re-INVITEs and UPDATE requests SHOULD be secured using a 1030 mechanism equivalent to or stronger than the initial INVITE request 1031 that created the session. For example, if the initial INVITE request 1032 was end-to-end integrity protected or encrypted, subsequent re- 1033 INVITEs and UPDATE requests should also be so. 1035 7. IANA Considerations 1037 There are no IANA actions associated with this document. 1039 8. Acknowledgements 1041 Paul Kyzivat provided useful ideas on the topics discussed in this 1042 document. 1044 9. References 1046 9.1. Normative References 1048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1049 Requirement Levels", BCP 14, RFC 2119, March 1997. 1051 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1052 A., Peterson, J., Sparks, R., Handley, M., and E. 1053 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1054 June 2002. 1056 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1057 Provisional Responses in Session Initiation Protocol 1058 (SIP)", RFC 3262, June 2002. 1060 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1061 with Session Description Protocol (SDP)", RFC 3264, 1062 June 2002. 1064 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1065 UPDATE Method", RFC 3311, October 2002. 1067 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1068 Initiation Protocol (SIP) Preconditions Framework", 1069 RFC 4032, March 2005. 1071 9.2. Informative References 1073 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1074 Session Initiation Protocol's (SIP) Non-INVITE 1075 Transaction", RFC 4320, January 2006. 1077 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1078 (ICE): A Protocol for Network Address Translator (NAT) 1079 Traversal for Offer/Answer Protocols", RFC 5245, 1080 April 2010. 1082 Authors' Addresses 1084 Gonzalo Camarillo (editor) 1085 Ericsson 1086 Hirsalantie 11 1087 Jorvas 02420 1088 Finland 1090 Email: Gonzalo.Camarillo@ericsson.com 1092 Christer Holmberg 1093 Ericsson 1094 Hirsalantie 11 1095 Jorvas 02420 1096 Finland 1098 Email: Christer.Holmberg@ericsson.com 1100 Yang Gao 1101 ZTE 1102 China 1104 Email: gao.yang2@zte.com.cn