idnits 2.17.1 draft-ietf-sipcore-reinvite-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 : ---------------------------------------------------------------------------- -- 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 (July 26, 2010) is 5021 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: January 27, 2011 ZTE 7 July 26, 2010 9 Re-INVITE and Target-refresh Request Handling in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-reinvite-05.txt 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 January 27, 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 . . . . . . . . . . . 22 83 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 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 then 108 provides an answer in a response to the re-INVITE. A UAC willing to 109 act as answerer does not include an offer in the re-INVITE. The UAS 110 then provides an offer in a response to the re-INVITE becoming, thus, 111 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 (User Agent Server) should handle re-INVITEs. In particular, 121 implementors requested clarification on which type of response a UAS 122 should generate in different situations. In this document, we 123 clarify these issues. 125 Additionally, there has also been some confusion among implementors 126 regarding target refresh requests, which include but are not limited 127 to re-INVITEs. In this document, we also clarify the process by 128 which remote targets are refreshed. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 UA: User Agent. 138 UAC: User Agent Client. 140 UAS: User Agent Server. 142 Note that the terms UAC and UAS are used with respect to an INVITE 143 or re-INVITE transaction and do not necessarily reflect the role 144 of the UA concerned with respect to any other transaction, such as 145 an UPDATE transaction occurring within the INVITE transaction. 147 3. Changing the Session State During a Re-INVITE 149 The following sections discuss how to change the state of the session 150 during a re-INVITE transaction. 152 3.1. Background on Re-INVITE Handling by UASs 154 A UAS receiving a re-INVITE will need to, eventually, generate a 155 response to it. Some re-INVITEs can be responded to immediately 156 because their handling does not require user interaction (e.g., 157 changing the IP address where a media stream is received). The 158 handling of other re-INVITEs requires user interaction (e.g., adding 159 a video stream to an audio-only session). Therefore, these re- 160 INVITEs cannot be responded to immediately. 162 An error response to a re-INVITE has the following semantics. As 163 specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is 164 rejected, no state changes are performed. These state changes 165 include state changes associated to the re-INVITE transaction and all 166 other transactions within the re-INVITE (this section deals with 167 changes to the session state; target refreshes are discussed in 168 Section 4.2). That is, the session state is the same as before the 169 re-INVITE was received. The example in Figure 1 illustrates this 170 point. 172 UAC UAS 174 | | 175 |-------------(1) INVITE SDP1--------------->| 176 | | 177 |<------------(2) 200 OK SDP2----------------| 178 | | 179 |------------------(3) ACK------------------>| 180 | | 181 | | 182 |-------------(4) INVITE SDP3--------------->| 183 | | 184 |<-----------------(5) 4xx-------------------| 185 | | 186 |------------------(6) ACK------------------>| 187 | | 189 Figure 1: Rejection of a re-INVITE 191 The UAs perform an offer/answer exchange to establish an audio-only 192 session: 194 SDP1: 195 m=audio 30000 RTP/AVP 0 197 SDP2: 198 m=audio 31000 RTP/AVP 0 200 At a later point, the UAC sends a re-INVITE (4) in order to add a 201 video stream to the session. 203 SDP3: 204 m=audio 30000 RTP/AVP 0 205 m=video 30002 RTP/AVP 31 207 The UAS is configured to automatically reject video streams. 208 Consequently, the UAS returns an error response (5). At that point, 209 the session parameters in use are still those resulting from the 210 initial offer/answer exchange, which are described by SDP1 and SDP2. 211 That is, the session state is the same as before the re-INVITE was 212 received. 214 In the previous example, the UAS rejected all the changes requested 215 in the re-INVITE by returning an error response. However, there are 216 situations where a UAS wants to accept some but not all the changes 217 requested in a re-INVITE. In these cases, the UAS generates a 200 218 (OK) response with an SDP indicating which changes were accepted and 219 which were not. The example in Figure 2 illustrates this point. 221 UAC UAS 223 | | 224 |-------------(1) INVITE SDP1--------------->| 225 | | 226 |<------------(2) 200 OK SDP2----------------| 227 | | 228 |------------------(3) ACK------------------>| 229 | | 230 | | 231 |-------------(4) INVITE SDP3--------------->| 232 | | 233 |<------------(5) 200 OK SDP4----------------| 234 | | 235 |------------------(6) ACK------------------>| 236 | | 238 Figure 2: Automatic rejection of a video stream 240 The UAs perform an offer/answer exchange to establish an audio only 241 session: 243 SDP1: 244 m=audio 30000 RTP/AVP 0 245 c=IN IP4 192.0.2.1 247 SDP2: 248 m=audio 31000 RTP/AVP 0 249 c=IN IP4 192.0.2.5 251 At a later point, the UAC moves to an access that provides a higher- 252 bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to 253 change the IP address where it receives the audio stream to its new 254 IP address and add a video stream to the session. 256 SDP3: 257 m=audio 30000 RTP/AVP 0 258 c=IN IP4 192.0.2.2 259 m=video 30002 RTP/AVP 31 260 c=IN IP4 192.0.2.2 262 The UAS is automatically configured to reject video streams. 263 However, the UAS needs to accept the change of the audio stream's 264 remote IP address. Consequently, the UAS returns a 200 (OK) response 265 and sets the port of the video stream to zero in its SDP. 267 SDP4: 268 m=audio 31000 RTP/AVP 0 269 c=IN IP4 192.0.2.5 270 m=video 0 RTP/AVP 31 272 In the previous example, the UAS was configured to automatically 273 reject the addition of video streams. The example in Figure 3 274 assumes that the UAS requires its user's input in order to accept or 275 reject the addition of a video stream and uses reliable provisional 276 responses [RFC3262] (PRACK transactions are not shown for clarity). 278 UAC UAS 280 | | 281 |-------------(1) INVITE SDP1--------------->| 282 | | 283 |<------------(2) 200 OK SDP2----------------| 284 | | 285 |------------------(3) ACK------------------>| 286 | | 287 | | 288 |-------------(4) INVITE SDP3--------------->| 289 | | 290 |<----(5) 183 Session Progress SDP4----------| 291 | | 292 | | 293 |<------------(6) UPDATE SDP5----------------| 294 | | 295 |-------------(7) 200 OK SDP6--------------->| 296 | | 297 |<---------------(8) 200 OK------------------| 298 | | 299 |------------------(9) ACK------------------>| 300 | | 302 Figure 3: Rejection of a video stream by the user 304 Everything up to (4) is identical to the previous example. In (5), 305 the UAS accepts the change of the audio stream's remote IP address 306 but does not accept the video stream yet (it provides a null IP 307 address instead of setting the stream to 'inactive' because inactive 308 streams still need to exchange RTCP traffic). 310 SDP4: 311 m=audio 31000 RTP/AVP 0 312 c=IN IP4 192.0.2.5 313 m=video 31002 RTP/AVP 31 314 c=IN IP4 0.0.0.0 316 At a later point, the UAS's user rejects the addition of the video 317 stream. Consequently, the UAS sends an UPDATE request (6) setting 318 the port of the video stream to zero in its offer. 320 SDP5: 321 m=audio 31000 RTP/AVP 0 322 c=IN IP4 192.0.2.5 323 m=video 0 RTP/AVP 31 324 c=IN IP4 0.0.0.0 326 The UAC returns a 200 (OK) response (7) to the UPDATE with the 327 following answer: 329 SDP6: 330 m=audio 30000 RTP/AVP 0 331 c=IN IP4 192.0.2.2 332 m=video 0 RTP/AVP 31 334 The UAS now returns a 200 (OK) response (8) to the re-INVITE. 336 In all the previous examples, the UAC of the re-INVITE transaction 337 was the offerer. Examples with UACs acting as the answerers would be 338 similar. 340 3.2. Problems with Error Responses and Already-executed Changes 342 Section 3.1 contains examples on how a UAS rejects all the changes 343 requested in a re-INVITE without executing any of them by returning 344 an error response (Figure 1), and how a UAS executes some of the 345 changes requested in a re-INVITE and rejects some of them by 346 returning a 2xx response (Figure 2 and Figure 3). A UAS can accept 347 and reject different sets of changes simultaneously (Figure 2) or at 348 different times (Figure 3). 350 The scenario that created confusion among implementors consists of a 351 UAS that receives a re-INVITE, executes some of the changes requested 352 in it, and then wants to reject all those already-executed changes 353 and revert to the pre-re-INVITE state. Such a UAS may consider 354 returning an error response to the re-INVITE (the message flow would 355 be similar to the one in Figure 1), or using an UPDATE request to 356 revert to the pre-re-INVITE state and then returning a 2xx response 357 to the re-INVITE (the message flow would be similar to the one in 358 Figure 3). This section explains the problems associated with 359 returning an error response in these circumstances. In order to 360 avoid these problems, the UAS should use the latter option (UPDATE 361 request plus a 2xx response). Section 3.3 and Section 3.4 contain 362 the normative statements needed to avoid these problems. 364 The reason for not using an error response to undo already executed 365 changes is that an error response to a re-INVITE for which changes 366 have already been executed (e.g., as a result of UPDATE transactions 367 or reliable provisional responses) is effectively requesting a change 368 in the session state. However, the UAC has no means to reject that 369 change if it is unable to execute them. That is, if the UAC is 370 unable to revert to the pre-re-INVITE state, it will not be able to 371 communicate this fact to the UAS. 373 3.3. UAS Behavior 375 UASs should only return an error response to a re-INVITE if no 376 changes to the session state have been executed since the re-INVITE 377 was received. Such an error response indicates that no changes have 378 been executed as a result of the re-INVITE or any other transaction 379 within it. 381 If any of the changes requested in a re-INVITE or in any transaction 382 within it have already been executed, the UAS SHOULD return a 2xx 383 response. 385 A change to the session state is considered to have been executed if 386 an offer/answer without preconditions [RFC4032] for the stream has 387 completed successfully or the UA has sent or received media using the 388 new parameters. Connection establishment messages (e.g., TCP SYN), 389 connectivity checks (e.g., when using ICE [RFC5245]), and any other 390 messages used in the process of meeting the preconditions for a 391 stream are not considered media. 393 Normally, a UA receiving media can easily detect when the new 394 parameters for the media stream are used (e.g,. media is received 395 on a new port). However, in some scenarios the UA will have to 396 process incoming media packets in order to detect whether they use 397 the old or the new parameters. 399 The successful completion of an offer/answer exchange without 400 preconditions indicates that the new parameters for the media stream 401 are already considered to be in use. The successful completion of an 402 offer/answer exchange with preconditions means something different. 403 The fact that all mandatory preconditions for the stream are met 404 indicates that the new parameters for the media stream are ready to 405 be used. However, they will not actually be used until the UAS 406 decides so. During a session establishment, the UAS can wait before 407 using the media parameters until the callee starts being alerted or 408 until the callee accepts the session. During a session modification, 409 the UAS can wait until its user accepts the changes to the session. 410 When dealing with streams where the UAS sends media more or less 411 continuously, the UAC notices that the new parameters are in use 412 because the UAC receives media that uses the new parameters. 413 However, this mechanism does not work with other types of streams. 414 Therefore, it is RECOMMENDED that when a UAS decides to start using 415 the new parameters for a stream for which all mandatory preconditions 416 have been met, the UAS either sends media using the new parameters or 417 sends a new offer where the precondition-related attributes for the 418 stream have been removed. As indicated above, the successful 419 completion of an offer/answer exchange without preconditions 420 indicates that the new parameters for the media stream are already 421 considered to be in use. 423 3.4. UAC Behavior 425 A UAC that receives an error response to a re-INVITE that undoes 426 already-executed changes within the re-INVITE may be facing a legacy 427 UAS that does not support this specification (i.e., a UAS that does 428 not follow the guidelines in Section 3.3). There are also certain 429 race condition situations that get both user agents out of 430 synchronization. In order to cope with these race condition 431 situations, a UAC that receives an error response to a re-INVITE for 432 which changes have been already executed SHOULD generate a new re- 433 INVITE or UPDATE request in order to make sure that both UAs have a 434 common view of the state of the session (the UAC uses the criteria in 435 Section 3.3 in order to decide whether or not changes have been 436 executed for a particular stream). The purpose of this new offer/ 437 answer exchange is to synchronize both UAs, not to request changes 438 that the UAS may choose to reject. Therefore, session parameters in 439 the offer/answer exchange SHOULD be as close to those in the pre-re- 440 INVITE state as possible. 442 3.5. Glare Situations 444 Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user 445 agent receiving an offer after having sent one but before having 446 received an answer to it. That section specifies rules to avoid 447 glare situations in most cases. When despite following those rules a 448 glare conditions occurs (as a result of a race condition), it is 449 handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. 450 The UAS returns a 491 (Request Pending) response and the UAC retries 451 the offer after a randomly-selected time, which depends on which user 452 agent is the owner of the Call-ID of the dialog. The rules in RFC 453 3261 [RFC3261] not only cover collisions between re-INVITEs that 454 contain offers; they cover collisions between two re-INVITEs in 455 general, even if they do not contain offers. Sections 5.2 and 5.3 of 456 RFC 3311 [RFC3311] extend those rules to also cover collisions 457 between an UPDATE request carrying an offer and another message 458 (UPDATE, PRACK or INVITE) also carrying an offer. 460 The rules in RFC 3261 [RFC3261] do not cover collisions between an 461 UPDATE request and a non-2xx final response to a re-INVITE. Since 462 both the UPDATE request and the reliable response could be requesting 463 changes to the session state, it would not be clear which changes 464 would need to be executed first. However, the procedures discussed 465 in Section 3.4 already cover this type of situation. Therefore, 466 there is no need to specify further rules here. 468 3.6. Example of UAS Behavior 470 This section contains an example of a UAS that implements this 471 specification using an UPDATE request and a 2xx response to a re- 472 INVITE in order to revert to the pre-re-INVITE state. The example, 473 which is shown in Figure 4, assumes that the UAS requires its user's 474 input in order to accept or reject the addition of a video stream and 475 uses reliable provisional responses [RFC3262] (PRACK transactions are 476 not shown for clarity). 478 UAC UAS 480 | | 481 |-------------(1) INVITE SDP1--------------->| 482 | | 483 |<------------(2) 200 OK SDP2----------------| 484 | | 485 |------------------(3) ACK------------------>| 486 | | 487 | | 488 |-------------(4) INVITE SDP3--------------->| 489 | | 490 |<----(5) 183 Session Progress SDP4----------| 491 | | 492 |-------------(6) UPDATE SDP5--------------->| 493 | | 494 |<------------(7) 200 OK SDP6----------------| 495 | | 496 | | 497 |<------------(8) UPDATE SDP7----------------| 498 | | 499 |-------------(9) 200 OK SDP8--------------->| 500 | | 501 |<--------------(10) 200 OK------------------| 502 | | 503 |-----------------(11) ACK------------------>| 504 | | 506 Figure 4: Rejection of a video stream by the user 508 The UAs perform an offer/answer exchange to establish an audio only 509 session: 511 SDP1: 512 m=audio 30000 RTP/AVP 0 513 c=IN IP4 192.0.2.1 515 SDP2: 516 m=audio 31000 RTP/AVP 0 517 c=IN IP4 192.0.2.5 519 At a later point, the UAC sends a re-INVITE (4) in order to add a new 520 codec to the audio stream and to add a video stream to the session. 522 SDP3: 523 m=audio 30000 RTP/AVP 0 3 524 c=IN IP4 192.0.2.1 525 m=video 30002 RTP/AVP 31 526 c=IN IP4 192.0.2.1 528 In (5), the UAS accepts the addition of the audio codec but does not 529 accept the video stream yet (it provides a null IP address instead of 530 setting the stream to 'inactive' because inactive streams still need 531 to exchange RTCP traffic). 533 SDP4: 534 m=audio 31000 RTP/AVP 0 3 535 c=IN IP4 192.0.2.5 536 m=video 31002 RTP/AVP 31 537 c=IN IP4 0.0.0.0 539 At a later point, the UAC sends an UPDATE request (6) to remove the 540 original audio codec from the audio stream (the UAC could have also 541 used the PRACK to (5) to request this change). 543 SDP5: 544 m=audio 30000 RTP/AVP 3 545 c=IN IP4 192.0.2.1 546 m=video 30002 RTP/AVP 31 547 c=IN IP4 192.0.2.1 549 SDP6: 550 m=audio 31000 RTP/AVP 3 551 c=IN IP4 192.0.2.5 552 m=video 31002 RTP/AVP 31 553 c=IN IP4 0.0.0.0 555 Yet at a later point, the UAS's user rejects the addition of the 556 video stream. Additionally, the UAS decides to revert to the 557 original audio codec. Consequently, the UAS sends an UPDATE request 558 (8) setting the port of the video stream to zero and offering the 559 original audio codec in its SDP. 561 SDP7: 562 m=audio 31000 RTP/AVP 0 563 c=IN IP4 192.0.2.5 564 m=video 0 RTP/AVP 31 565 c=IN IP4 0.0.0.0 567 The UAC accepts the change in the audio codec in its 200 (OK) 568 response (9) to the UPDATE request. 570 SDP8: 571 m=audio 30000 RTP/AVP 0 572 c=IN IP4 192.0.2.1 573 m=video 0 RTP/AVP 31 574 c=IN IP4 192.0.2.1 576 The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note 577 that the media state after this 200 (OK) response is the same as the 578 pre-re-INVITE media state. 580 3.7. Example of UAC Behavior 582 Figure 5 shows an example of a race condition situation in which the 583 UAs end up with different views of the state of the session. The UAs 584 in Figure 5 are involved in a session that, just before the message 585 flows in the figures starts, includes a sendrecv audio stream and an 586 inactive video stream. UA1 sends a re-INVITE (1) requesting to make 587 the video stream sendrecv. 589 SDP1: 590 m=audio 20000 RTP/AVP 0 591 a=sendrecv 592 m=video 20002 RTP/AVP 31 593 a=sendrecv 595 UA2 is configured to automatically accept incoming video streams but 596 to ask for user input before generating an outgoing video stream. 597 Therefore, UAS2 makes the video stream recvonly by returning a 183 598 (Session Progress) response (2). 600 SDP2: 601 m=audio 30000 RTP/AVP 0 602 a=sendrecv 603 m=video 30002 RTP/AVP 31 604 a=recvonly 606 When asked for input, UA2's user chooses not to have either incoming 607 or outgoing video. In order to make the video stream inactive, UA2 608 returns a 4xx error response (5) to the re-INVITE. The ACK request 609 (6) for this error response is generated by the proxy between both 610 user agents. Note that this error response undoes already-executed 611 changes. So, UA2 is a legacy UA that does not support this 612 specification. 614 The proxy relays the 4xx response (7) towards UA1. However, the 4xx 615 response (7) takes time to arrive to UA1 (e.g., the response may have 616 been sent over UDP and the first few retransmissions were lost). In 617 the meantime, UA2's user decides to put the audio stream on hold. 618 UA2 sends an UPDATE request (8) making the audio stream recvonly. 619 The video stream, which is inactive, is not modified and, thus, 620 continues being inactive. 622 SDP3: 623 m=audio 30000 RTP/AVP 0 624 a=recvonly 625 m=video 30002 RTP/AVP 31 626 a=inactive 628 The proxy relays the UPDATE request (9) to UA1. The UPDATE request 629 (9) arrives at UA1 before the 4xx response (7) that had been 630 previously sent. UA1 accepts the changes in the UPDATE request and 631 returns a 200 (OK) response (10) to it. 633 SDP4: 634 m=audio 20000 RTP/AVP 0 635 a=sendonly 636 m=video 30002 RTP/AVP 31 637 a=inactive 639 At a later point, the 4xx response (7) finally arrives at UA1. This 640 response makes the session return to its pre-re-INVITE state. 641 Therefore, for UA1, the audio stream is sendrecv and the video stream 642 is inactive. However, for UA2, the audio stream is recvonly (the 643 video stream is also inactive). 645 a:sendrecv a:sendrecv 646 v:inactive v:inactive 648 UA1 Proxy UA2 650 | | | 651 |----(1) INVITE SDP1-->| | 652 | |----(2) INVITE SDP1-->| 653 | | | 654 | |<----(3) 183 SDP2-----| a:sendrecv 655 a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly 656 v:sendonly | | | 657 | |<------(5) 4xx -------| 658 | |-------(6) ACK ------>| a:sendrecv 659 | +-(7) 4xx -| | v:inactive 660 | | |<---(8) UPDATE SDP3---| 661 |<---(9) UPDATE SDP3---| | 662 | | | | 663 a:sendonly |---(10) 200 OK SDP4-->| | 664 v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly 665 |<-(7) 4xx -+ | | v:inactive 666 a:sendrecv |------(12) ACK ------>| | 667 v:inactive | | | 669 a: status of the audio stream 670 v: status of the video stream 672 Figure 5: Message flow with race condition 674 After the message flow in Figure 5, following the recommendations in 675 this section, when UA1 received an error response (7) that undid 676 already-executed changes, UA1 would generate an UPDATE request with 677 an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and 678 inactive video). UA2 could then return a 200 (OK) response to the 679 UPDATE request making the audio stream recvonly, which is the state 680 UA2's user had requested. Such an UPDATE transaction would get the 681 UAs back into synchronization. 683 3.8. Clarifications on Cancelling Re-INVITEs 685 Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS 686 responding to a CANCEL request. Such a UAS responds to the INVITE 687 request with a 487 (Request Terminated) at the 'should' level. Per 688 the rules specified in Section 3.3, if the INVITE request was a re- 689 INVITE and some of its requested changes had already been executed, 690 the UAS would return a 2xx response instead. 692 4. Refreshing a Dialog's Targets 694 The following sections discuss how to refresh the targets of a 695 dialog. 697 4.1. Background and Terminology on a Dialog's Targets 699 As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a 700 dialog stores the dialog's remote target as part of the dialog's 701 state information the UA keeps. Consequently, each of the two UAs 702 involved in a dialog store a dialog's remote target. In this 703 document, we define a new term: a dialog's local target. A dialog's 704 local target is the dialog's remote target the remote UA stores. 705 Thus, the dialog's local target for a UA is the dialog's remote 706 target for the other UA. Similarly, the dialog's remote target for a 707 UA is the dialog's local target for the other UA. The use of this 708 new term is intended to add clarity to the following discussions. 710 4.2. Background on Target-refresh Requests 712 A target-refresh request is defined as follows in Section 6 of RFC 713 3261 [RFC3261]: 715 "A target-refresh request sent within a dialog is defined as a 716 request that can modify the remote target of the dialog." 718 Additionally, 2xx responses to target-refresh requests can also 719 update the remote target of the dialog. As discussed in Section 12.2 720 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. 722 RFC 3261 [RFC3261] specifies the behavior of UASs receiving target- 723 refresh requests and of UACs receiving a 2xx response for a target- 724 refresh request. 726 Section 12.2.2 of RFC 3261 [RFC3261] says: 728 "When a UAS receives a target-refresh request, it MUST replace the 729 dialog's remote target URI with the URI from the Contact header 730 field in that request, if present." 732 Section 12.2.1.2 of RFC 3261 [RFC3261] says: 734 "When a UAC receives a 2xx response to a target-refresh request, 735 it MUST replace the dialog's remote target URI with the URI from 736 the Contact header field in that response, if present." 738 The fact that re-INVITEs can be long-lived transactions and can have 739 other transactions within them makes it necessary to revise these 740 rules. Section 4.3 specifies new rules for the handing of target- 741 refresh requests. Note that the new rules apply to any target- 742 refresh request, not only to re-INVITEs. 744 4.3. Clarification on the Atomicity of Target-Refresh Requests 746 The local and remote targets of a dialog are special types of state 747 information because of their essential role in the exchange of SIP 748 messages between UAs in a dialog. A UA involved in a dialog receives 749 the remote target of the dialog from the remote UA. The UA uses the 750 received remote target to send SIP requests to the remote UA. 752 The dialog's local target is a piece of state information that is not 753 meant to be negotiated. When a UA changes its local target (i.e., 754 the UA changes its IP address), the UA simply communicates its new 755 local target to the remote UA (e.g., the UA communicates its new IP 756 address to the remote UA in order to remain reachable by the remote 757 UA). UAs need to follow the behavior specified in Section 4.4, 758 Section 4.5, Section 4.6, and Section 4.7 of this specification 759 instead of that specified in RFC 3261 [RFC3261], which was discussed 760 in Section 4.2. The new behavior regarding target-refresh requests 761 implies that a target-refresh request can, in some cases, update the 762 remote target even if the request is responded with a final error 763 response. This means that target-refresh requests are not atomic. 765 4.4. UA Updating the Dialog's Local Target in a Request 767 In order to update its local target, a UA can send a target-refresh 768 request. If the UA receives an error response to the target-refresh 769 request, the remote UA has not updated its remote target. 771 This allows UASs to authenticate target-refresh requests. 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, the UA SHOULD generate a reliable provisional response 808 or a 2xx response to the target-refresh request. If generating such 809 responses is not possible (e.g., the UA does not support reliable 810 provisional responses and needs user input before generating a final 811 response), the UA SHOULD send an in-dialog request to the remote UA 812 using the new remote target (if the UA does not need to send a 813 request for other reasons, the UAS can send an UPDATE request). On 814 sending a reliable provisional response or a 2xx response to the 815 target-refresh request, or a request to the new remote target, the UA 816 MUST replace the dialog's remote target URI with the URI from the 817 Contact header field in the target-refresh request. 819 Reliable provisional responses in SIP are specified in RFC 3262 820 [RFC3262]. In this document, reliable provisional responses are 821 those that use the mechanism defined in RFC 3262 [RFC3262]. Other 822 specifications may define ways to send provisional responses 823 reliably using non-SIP mechanisms (e.g., using media-level 824 messages to acknowledge the reception of the SIP response). For 825 the purposes of this document, provisional responses using those 826 non-SIP mechanisms are considered unreliable responses. Note that 827 non-100 provisional responses are only applicable to INVITE 828 transactions [RFC4320]. 830 If instead of sending a reliable provisional response or a 2xx 831 response to the target-refresh request, or a request to the new 832 target, the UA generates an error response to the target-refresh 833 request, the UA MUST NOT update its dialog's remote target. 835 4.7. A Response Updating the Dialog's Remote Target 837 If a UA receives a reliable provisional response or a 2xx response to 838 a target-refresh request, the UA MUST replace the dialog's remote 839 target URI with the URI from the Contact header field in that 840 response, if present. 842 If a UA receives an unreliable provisional response to a target- 843 refresh request, the UA MUST NOT refresh the dialog's remote target. 845 4.8. Race Conditions and Target Refreshes 847 SIP provides request ordering by using the Cseq header field. That 848 is, a UA that receives two requests at roughly the same time can know 849 which one is newer. However, SIP does not provide ordering between 850 responses and requests. For example, if a UA receives a 200 (OK) 851 response to an UPDATE request and an UPDATE request at roughly the 852 same time, the UA cannot know which one was sent last. Since both 853 messages can refresh the remote target, the UA needs to know which 854 message was sent last in order to know which remote target needs to 855 be used. 857 This document specifies the following rule to avoid the situation 858 just described. A UA that wishes to refresh its local target and can 859 perform such a refresh by sending a target-refresh request at that 860 point in time SHOULD use a target-refresh request to refresh its 861 local target. This rules implies that a UA only uses a response 862 (i.e., a reliable provisional response or a 2xx response to a target- 863 refresh request) to refresh its local target if the UA is unable to 864 use a target-refresh request at that point in time (e.g., the UAS of 865 an ongoing re-INVITE without support for UPDATE). 867 4.9. Early Dialogs 869 The rules given in this section about which messages can refresh the 870 target of a dialog also apply to early dialogs created by an initial 871 INVITE transaction. Additionally, as specified in Section 13.2.2.4 872 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial 873 INVITE, the UAC recomputes the whole route set of the dialog, which 874 transitions from the "early" state to the "confirmed" state. 876 Section 12.1 of RFC 3261 allows unreliable provisional responses to 877 create early dialogs. However, per the rules given in this section, 878 unreliable provisional responses cannot refresh the target of a 879 dialog. Therefore, the UAC of an initial INVITE transaction will not 880 perform any target refresh as a result of the reception of an 881 unreliable provisional response with an updated Contact value on an 882 (already-established) early dialog. Note also that a given UAS can 883 establish additional early dialogs, which can have different targets, 884 by returning additional unreliable provisional responses with 885 different To tags. 887 5. A UA Losing its Contact 889 The following sections discuss the case where a UA loses its 890 transport address during an ongoing re-INVITE transaction. Such a UA 891 will refresh the dialog's local target so that it reflects its new 892 transport address. Note that target refreshes that do not involve 893 changes in the UA's transport address are outside of the scope of 894 this section. Also, UAs losing their transport address during a non- 895 re-INVITE transaction (e.g., a UA losing its transport address right 896 after having sent an UPDATE request before having received a response 897 to it) are out of scope as well. 899 The rules given in this section are also applicable to initial INVITE 900 requests that have established early dialogs. 902 5.1. Background on re-INVITE Transaction Routing 904 Re-INVITEs are routed using the dialog's route set, which contains 905 all the proxy servers that need to be traversed by requests sent 906 within the dialog. Responses to the re-INVITE are routed using the 907 Via entries in the re-INVITE. 909 ACK requests for 2xx responses and for non-2xx final responses are 910 generated in different ways. As specified in Sections 14.1 and 911 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are 912 generated by the UAC core and are routed using the dialog's route 913 set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK 914 requests for non-2xx final responses are generated by the INVITE 915 client transaction (i.e., they are generated in a hop-by-hop fashion 916 by the proxy servers in the path) and are sent to the same transport 917 address as the re-INVITE. 919 5.2. Problems with UAs Losing their Contact 921 Refreshing the dialog's remote target during a re-INVITE transaction 922 (see Section 4.3) presents some issues because of the fact that re- 923 INVITE transactions can be long lived. As described in Section 5.1, 924 the way responses to the re-INVITE and ACKs for non-2xx final 925 responses are routed is fixed once the re-INVITE is sent. The 926 routing of this messages does not depend on the dialog's route set 927 and, thus, target refreshes within an ongoing re-INVITE do not affect 928 their routing. A UA that changes its location (i.e., performs a 929 target refresh) but is still reachable at its old location will be 930 able to receive those messages (which will be sent to the old 931 location). However, a UA that cannot be reachable at its old 932 location any longer will not be able to receive them. 934 The following sections describe the errors UAs face when they lose 935 their transport address during a re-INVITE. On detecting some of 936 these errors, UAs following the rules specified in RFC 3261 [RFC3261] 937 will terminate the dialog. When the dialog is terminated, the only 938 option for the UAs is to establish a new dialog. However, in some 939 cases, exiting UAs will not terminate the dialog when detecting those 940 errors (despite of the rules in RFC 3261 [RFC3261]). The following 941 sections describe how to recover from those errors when the dialog 942 has not been terminated. In short, the UAs generate a new re-INVITE 943 transaction to synchronize both UAs. 945 5.3. UAS Losing its Contact: UAC Behavior 947 When a UAS that moves to a new contact and loses its old contact 948 generates a non-2xx final response to the re-INVITE, it will not be 949 able to receive the ACK request. The entity receiving the response 950 and, thus, generating the ACK request will either get a transport 951 error or a timeout error, which, as described in Section 8.1.3.1 of 952 RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) 953 response and as a 408 (Request Timeout) response, respectively. If 954 the sender of the ACK request is a proxy server, it will typically 955 ignore this error. If the sender of the ACK request is the UAC, 956 according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed 957 to (at the "should" level) terminate the dialog by sending a BYE 958 request. However, because of the special properties of ACK requests 959 for non-2xx final responses, most existing UACs do not terminate the 960 dialog when ACK request fails, which is fortunate. 962 A UAC that accepts a target refresh within a re-INVITE MUST ignore 963 transport and timeout errors when generating an ACK request for a 964 non-2xx final response. Additionally, UAC SHOULD generate a new re- 965 INVITE in order to make sure that both UAs have a common view of the 966 state of the session. 968 It is possible that the errors ignored by the UAC were not related 969 to the target refresh operation. If that was the case, the second 970 re-INVITE would fail and the UAC would terminate the dialog 971 because, per the rules above, UACs only ignore errors when they 972 accept a target refresh within the re-INVITE. 974 5.4. UAC Losing its Contact: UAS Behavior 976 When a UAC moves to a new contact and loses its old contact, it will 977 not be able to receive responses to the re-INVITE. Consequently, it 978 will never generate an ACK request. 980 As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server 981 that gets an error when forwarding a response does not take any 982 measures. Consequently, proxy servers relaying responses will 983 effectively ignore the error. 985 If there are no proxy servers in the dialog's route set, the UAS will 986 get an error when sending a non-2xx final response. The UAS core 987 will be notified of the transaction failure, as described in Section 988 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate 989 the dialog on encountering this failure, which is fortunate. 991 Regardless of the presence or absence of proxy servers in the 992 dialog's route set, a UAS generating a 2xx response to the re-INVITE 993 will never receive an ACK request for it. According to Section 14.2 994 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" 995 level) terminate the dialog by sending a BYE request. 997 A UAS that accepts a target refresh within a re-INVITE and never 998 receives an ACK request after having sent a final response to the re- 999 INVITE SHOULD NOT terminate the dialog if the UA has received a new 1000 re-INVITE with a higher CSeq sequence number than the original one. 1002 5.5. UAC Losing its Contact: UAC Behavior 1004 When a UAC moves to a new contact and loses its old contact, it will 1005 not be able to receive responses to the re-INVITE. Consequently, it 1006 will never generate an ACK request. 1008 Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE 1009 and cause the INVITE client transaction corresponding to the re- 1010 INVITE to enter the "Terminated" state. The UAC SHOULD also send a 1011 new re-INVITE in order to make sure that both UAs have a common view 1012 of the state of the session. 1014 Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new 1015 incoming re-INVITEs as soon as it has generated a final response 1016 to the previous INVITE request, which had a lower CSeq sequence 1017 number. 1019 6. Security Considerations 1021 This document does not introduce any new security issue. It just 1022 clarifies how certain transactions should be handled in SIP. 1023 Security issues related to re-INVITEs and UPDATE requests are 1024 discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. 1026 7. IANA Considerations 1028 There are no IANA actions associated with this document. 1030 8. Acknowledgements 1032 Paul Kyzivat provided useful ideas on the topics discussed in this 1033 document. 1035 9. References 1037 9.1. Normative References 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, March 1997. 1042 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1043 A., Peterson, J., Sparks, R., Handley, M., and E. 1044 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1045 June 2002. 1047 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1048 Provisional Responses in Session Initiation Protocol 1049 (SIP)", RFC 3262, June 2002. 1051 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1052 with Session Description Protocol (SDP)", RFC 3264, 1053 June 2002. 1055 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1056 UPDATE Method", RFC 3311, October 2002. 1058 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1059 Initiation Protocol (SIP) Preconditions Framework", 1060 RFC 4032, March 2005. 1062 9.2. Informative References 1064 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1065 Session Initiation Protocol's (SIP) Non-INVITE 1066 Transaction", RFC 4320, January 2006. 1068 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1069 (ICE): A Protocol for Network Address Translator (NAT) 1070 Traversal for Offer/Answer Protocols", RFC 5245, 1071 April 2010. 1073 Authors' Addresses 1075 Gonzalo Camarillo (editor) 1076 Ericsson 1077 Hirsalantie 11 1078 Jorvas 02420 1079 Finland 1081 Email: Gonzalo.Camarillo@ericsson.com 1083 Christer Holmberg 1084 Ericsson 1085 Hirsalantie 11 1086 Jorvas 02420 1087 Finland 1089 Email: Christer.Holmberg@ericsson.com 1091 Yang Gao 1092 ZTE 1093 China 1095 Email: gao.yang2@zte.com.cn