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