idnits 2.17.1 draft-ietf-sipcore-reinvite-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (May 8, 2010) is 5103 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: November 9, 2010 ZTE 7 May 8, 2010 9 Re-INVITE and Target-refresh Request Handling in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-reinvite-04.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 November 9, 2010. 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. Re-INVITE Handling . . . . . . . . . . . . . . . . . . . . . . 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. Target-refresh Handling . . . . . . . . . . . . . . . . . . . 17 68 4.1. Background on Target-refresh Requests . . . . . . . . . . 17 69 4.2. Clarification on the Atomicity of Target-Refresh 70 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 4.3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 72 4.4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 73 4.5. Race Conditions and Target Refreshes . . . . . . . . . . . 19 74 5. Re-INVITE Transaction Routing . . . . . . . . . . . . . . . . 20 75 5.1. Background on re-INVITE Transaction Routing . . . . . . . 20 76 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 20 77 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 20 78 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 21 79 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 22 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request 91 sent within an existing dialog is known as a re-INVITE. A re-INVITE 92 is used to modify session parameters, dialog parameters, or both. 93 That is, a single re-INVITE can change both the parameters of its 94 associated session (e.g., changing the IP address where a media 95 stream is received) and the parameters of its associated dialog 96 (e.g., changing the remote target of the dialog). A re-INVITE can 97 change the remote target of a dialog because it is a target refresh 98 request, as defined in Section 6 of RFC 3261 [RFC3261]. 100 A re-INVITE transaction has an offer/answer [RFC3264] exchange 101 associated to it. The UAC (User Agent Client) generating a given re- 102 INVITE can act as the offerer or as the answerer. A UAC willing to 103 act as the offerer includes an offer in the re-INVITE. The UAS then 104 provides an answer in a response to the re-INVITE. A UAC willing to 105 act as answerer does not include an offer in the re-INVITE. The UAS 106 then provides an offer in a response to the re-INVITE becoming, thus, 107 the offerer. 109 Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] 110 transactions) can also have offer/answer exchanges associated to 111 them. A UA (User Agent) can act as the offerer or the answerer in 112 any of these transactions regardless of whether the UA was the 113 offerer or the answerer in the umbrella re-INVITE transaction. 115 There has been some confusion among implementors regarding how a UAS 116 (User Agent Server) should handle re-INVITEs. In particular, 117 implementors requested clarification on which type of response a UAS 118 should generate in different situations. In this document, we 119 clarify these issues. 121 Additionally, there has also been some confusion among implementors 122 regarding target refresh requests, which include but are not limited 123 to re-INVITEs. In this document, we also clarify the process by 124 which remote targets are refreshed. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 UA: User Agent. 134 UAC: User Agent Client. 136 UAS: User Agent Server. 138 Note that the terms UAC and UAS are used with respect to an INVITE 139 or re-INVITE transaction and do not necessarily reflect the role 140 of the UA concerned with respect to any other transaction, such as 141 an UPDATE transaction occurring within the INVITE transaction. 143 3. Re-INVITE Handling 145 The following sections discuss re-INVITE handling. 147 3.1. Background on Re-INVITE Handling by UASs 149 A UAS receiving a re-INVITE will need to, eventually, generate a 150 response to it. Some re-INVITEs can be responded to immediately 151 because their handling does not require user interaction (e.g., 152 changing the IP address where a media stream is received). The 153 handling of other re-INVITEs requires user interaction (e.g., adding 154 a video stream to an audio-only session). Therefore, these re- 155 INVITEs cannot be responded to immediately. 157 An error response to a re-INVITE has the following semantics. As 158 specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is 159 rejected, no state changes are performed. These state changes 160 include state changes associated to the re-INVITE transaction and all 161 other transactions within the re-INVITE (target refreshes, which are 162 discussed in Section 4.1, are an exception to this rule because in 163 certain cases they are performed even if the re-INVITE is rejected). 164 That is, the session and dialog states are the same as before the re- 165 INVITE was received. The example in Figure 1 illustrates this point. 167 UAC UAS 169 | | 170 |-------------(1) INVITE SDP1--------------->| 171 | | 172 |<------------(2) 200 OK SDP2----------------| 173 | | 174 |------------------(3) ACK------------------>| 175 | | 176 | | 177 |-------------(4) INVITE SDP3--------------->| 178 | | 179 |<-----------------(5) 4xx-------------------| 180 | | 181 |------------------(6) ACK------------------>| 182 | | 184 Figure 1: Rejection of a re-INVITE 186 The UAs perform an offer/answer exchange to establish an audio-only 187 session: 189 SDP1: 190 m=audio 30000 RTP/AVP 0 192 SDP2: 193 m=audio 31000 RTP/AVP 0 195 At a later point, the UAC sends a re-INVITE (4) in order to add a 196 video stream to the session. 198 SDP3: 199 m=audio 30000 RTP/AVP 0 200 m=video 30002 RTP/AVP 31 202 The UAS is automatically configured to reject video streams. 203 Consequently, the UAS returns an error response (5). At that point, 204 the session parameters in use are still those resulting from the 205 initial offer/answer exchange, which are described by SDP1 and SDP2. 206 That is, the session and dialog states are the same as before the re- 207 INVITE was received. 209 In the previous example, the UAS rejected all the changes requested 210 in the re-INVITE by returning an error response. However, there are 211 situations where a UAS wants to accept some but not all the changes 212 requested in a re-INVITE. In these cases, the UAS generates a 200 213 (OK) response with an SDP indicating which changes were accepted and 214 which were not. The example in Figure 2 illustrates this point. 216 UAC UAS 218 | | 219 |-------------(1) INVITE SDP1--------------->| 220 | | 221 |<------------(2) 200 OK SDP2----------------| 222 | | 223 |------------------(3) ACK------------------>| 224 | | 225 | | 226 |-------------(4) INVITE SDP3--------------->| 227 | | 228 |<------------(5) 200 OK SDP4----------------| 229 | | 230 |------------------(6) ACK------------------>| 231 | | 233 Figure 2: Automatic rejection of a video stream 235 The UAs perform an offer/answer exchange to establish an audio only 236 session: 238 SDP1: 239 m=audio 30000 RTP/AVP 0 240 c=IN IP4 192.0.2.1 242 SDP2: 243 m=audio 31000 RTP/AVP 0 244 c=IN IP4 192.0.2.5 246 At a later point, the UAC moves to an access that provides a higher- 247 bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to 248 change the IP address where it receives the audio stream to its new 249 IP address and add a video stream to the session. 251 SDP3: 252 m=audio 30000 RTP/AVP 0 253 c=IN IP4 192.0.2.2 254 m=video 30002 RTP/AVP 31 255 c=IN IP4 192.0.2.2 257 The UAS is automatically configured to reject video streams. 258 However, the UAS needs to accept the change of the audio stream's 259 remote IP address. Consequently, the UAS returns a 200 (OK) response 260 and sets the port of the video stream to zero in its SDP. 262 SDP4: 263 m=audio 31000 RTP/AVP 0 264 c=IN IP4 192.0.2.5 265 m=video 0 RTP/AVP 31 267 In the previous example, the UAS was configured to automatically 268 reject the addition of video streams. The example in Figure 3 269 assumes that the UAS requires its user's input in order to accept or 270 reject the addition of a video stream and uses reliable provisional 271 responses [RFC3262] (PRACK transactions are not shown for clarity). 273 UAC UAS 275 | | 276 |-------------(1) INVITE SDP1--------------->| 277 | | 278 |<------------(2) 200 OK SDP2----------------| 279 | | 280 |------------------(3) ACK------------------>| 281 | | 282 | | 283 |-------------(4) INVITE SDP3--------------->| 284 | | 285 |<----(5) 183 Session Progress SDP4----------| 286 | | 287 | | 288 |<------------(6) UPDATE SDP5----------------| 289 | | 290 |-------------(7) 200 OK SDP6--------------->| 291 | | 292 |<---------------(8) 200 OK------------------| 293 | | 294 |------------------(9) ACK------------------>| 295 | | 297 Figure 3: Rejection of a video stream by the user 299 Everything up to (4) is identical to the previous example. In (5), 300 the UAS accepts the change of the audio stream's remote IP address 301 but does not accept the video stream yet (it provides a null IP 302 address instead of setting the stream to 'inactive' because inactive 303 streams still need to exchange RTCP traffic). 305 SDP4: 306 m=audio 31000 RTP/AVP 0 307 c=IN IP4 192.0.2.5 308 m=video 31002 RTP/AVP 31 309 c=IN IP4 0.0.0.0 311 At a later point, the UAS's user rejects the addition of the video 312 stream. Consequently, the UAS sends an UPDATE request (6) setting 313 the port of the video stream to zero in its offer. 315 SDP5: 316 m=audio 31000 RTP/AVP 0 317 c=IN IP4 192.0.2.5 318 m=video 0 RTP/AVP 31 319 c=IN IP4 0.0.0.0 321 The UAC returns a 200 (OK) response (7) to the UPDATE with the 322 following answer: 324 SDP6: 325 m=audio 30000 RTP/AVP 0 326 c=IN IP4 192.0.2.2 327 m=video 0 RTP/AVP 31 329 The UAS now returns a 200 (OK) response (8) to the re-INVITE. 331 In all the previous examples, the UAC of the re-INVITE transaction 332 was the offerer. Examples with UACs acting as the answerers would be 333 similar. 335 3.2. Problems with Error Responses and Already-executed Changes 337 Section 3.1 contains examples on how a UAS rejects all the changes 338 requested in a re-INVITE without executing any of them by returning 339 an error response (Figure 1), and how a UAS executes some of the 340 changes requested in a re-INVITE and rejects some of them by 341 returning a 2xx response (Figure 2 and Figure 3). A UAS can accept 342 and reject different sets of changes simultaneously (Figure 2) or at 343 different times (Figure 3). 345 The scenario that created confusion among implementors consists of a 346 UAS that receives a re-INVITE, executes some of the changes requested 347 in it, and then wants to reject all those already-executed changes 348 and revert to the pre-re-INVITE state. Such a UAS may consider 349 returning an error response to the re-INVITE (the message flow would 350 be similar to the one in Figure 1), or using an UPDATE request to 351 revert to the pre-re-INVITE state and then returning a 2xx response 352 to the re-INVITE (the message flow would be similar to the one in 353 Figure 3). This section explains the problems associated with 354 returning an error response in these circumstances. In order to 355 avoid these problems, the UAS should use the latter option (UPDATE 356 request plus a 2xx response). Section 3.3 and Section 3.4 contain 357 the normative statements needed to avoid these problems. 359 The reason for not using an error response to undo already executed 360 changes is that an error response to a re-INVITE for which changes 361 have already been executed is effectively requesting a change in the 362 session or the dialog state. However, the UAC has no means to reject 363 those changes if it is unable to execute them. That is, if the UAC 364 is unable to revert to the pre-re-INVITE state, it will not be able 365 to communicate this fact to the UAS. 367 3.3. UAS Behavior 369 UASs should only return an error response to a re-INVITE if no 370 changes to the session or to the dialog state have been executed 371 since the re-INVITE was received. Such an error response indicates 372 that no changes have been executed as a result of the re-INVITE or 373 any other transaction within it. 375 If any of the changes requested in a re-INVITE or in any transaction 376 within it have already been executed (with the exception of target 377 refreshes), the UAS SHOULD return a 2xx response. 379 A change to the session state is considered to have been executed if 380 an offer/answer without preconditions [RFC4032] for the stream has 381 completed successfully or the UAs have exchanged media using the new 382 parameters. Connection establishment messages (e.g., TCP SYN), 383 connectivity checks (e.g., when using ICE [RFC5245]), and any other 384 messages used in the process of meeting the preconditions for a 385 stream are not considered media. 387 Normally, a UA receiving media can easily detect when the new 388 parameters for the media stream are used (e.g,. media is received 389 on a new port). However, in some scenarios the UA will have to 390 process incoming media packets in order to detect whether they use 391 the old or the new parameters. 393 The successful completion of an offer/answer exchange without 394 preconditions indicates that the new parameters for the media stream 395 are already considered to be in use. The successful completion of an 396 offer/answer exchange with preconditions means something different. 397 The fact that all mandatory preconditions for the stream are met 398 indicates that the new parameters for the media stream are ready to 399 be used. However, they will not actually be used until the UAS 400 decides so. During a session establishment, the UAS can wait before 401 using the media parameters until the callee starts being alerted or 402 until the callee accepts the session. During a session modification, 403 the UAS can wait until its user accepts the changes to the session. 404 When dealing with streams where the UAS sends media more or less 405 continuously, the UAC notices that the new parameters are in use 406 because the UAC receives media that uses the new parameters. 407 However, this mechanism does not work with other types of streams. 408 Therefore, it is RECOMMENDED that when a UAS decides to start using 409 the new parameters for a stream for which all mandatory preconditions 410 have been met, the UAS either sends media using the new parameters or 411 sends a new offer where the precondition-related attributes for the 412 stream have been removed. As indicated above, the successful 413 completion of an offer/answer exchange without preconditions 414 indicates that the new parameters for the media stream are already 415 considered to be in use. 417 The point a change to the dialog state is considered to have been 418 executed depends on the particular dialog parameter being modified. 419 The specifications of different dialog parameters describe when the 420 new value of the parameter needs to be taken into use. 422 3.4. UAC Behavior 424 A UAC that receives an error response to a re-INVITE that undoes 425 already-executed changes within the re-INVITE may be facing a legacy 426 UAS that does not support this specification (i.e., a UAS that does 427 not follow the guidelines in Section 3.3). There are also certain 428 race condition situations that get both user agents out of 429 synchronization. In order to cope with these race condition 430 situations, a UAC that receives an error response to a re-INVITE for 431 which changes have been already executed SHOULD generate a new re- 432 INVITE or UPDATE request in order to make sure that both UAs have a 433 common view of the state of the dialog and the session (the UAC uses 434 the criteria in Section 3.3 in order to decide whether or not changes 435 have been executed for the stream). The purpose of this new offer/ 436 answer exchange is to synchronize both UAs, not to request changes 437 that the UAS may choose to reject. Therefore, the dialog parameters 438 and the session parameters in the offer/answer exchange SHOULD be as 439 close as those in the pre-re-INVITE state as possible. 441 3.5. Glare Situations 443 Section 4 of RFC 3264 [RFC3264] specifies rules to avoid and detect 444 glare situations (i.e., to avoid offer/answer collisions in race 445 conditions). Section 14.1 of RFC 3261 [RFC3261] specifies general 446 rules to handle glare situations in SIP. Section 5.1 of RFC 3311 447 [RFC3311] specifies when UPDATE requests can be sent. The specified 448 rules include, among other things, procedures to cope with situations 449 where both UAs generate an offer at the same time. However, there 450 are no rules to avoid a collision between an offer in an UPDATE 451 request and an error response to a re-INVITE. Since both the UPDATE 452 request and the error response could be requesting changes, it would 453 not be clear which changes would need to be executed first. The 454 following rules avoid types of glare conditions that were not covered 455 by previous specifications. 457 When checking for glare situations, UAs MUST treat the exchange of a 458 non-2xx final response to a re-INVITE and its corresponding ACK 459 request as an offer/answer exchange. Consequently, the rules 460 regarding glare situations applicable to offer/answer exchanges are 461 also applicable to those exchanges. These rules imply that if the 462 UAS of a re-INVITE transaction receives and UPDATE request with an 463 offer after having sent a non-2xx final response to the re-INVITE but 464 before having received the corresponding ACK request, the UA SHOULD 465 return a 491 (Request Pending) response to the UPDATE request. If 466 the UAC of a re-INVITE transaction sends an UPDATE request with an 467 offer, receives a non-2xx response to the re-INVITE, and then a 2xx 468 response to the UPDATE request, the UA SHOULD generate a new re- 469 INVITE or UPDATE request in order to make sure that both UAs have a 470 common view of the state of the session, as described in Section 3.4. 472 An UPDATE request without an offer can change dialog parameters. So 473 can a non-2xx final response to a re-INVITE request or a 2xx response 474 to an INVITE request (re-INVITE or initial INVITE). However, there 475 are no rules to avoid a collision between an offerless UPDATE request 476 and a final response to an INVITE request. The rules in Section 4.5, 477 which are given in the context of target refreshes, cover these types 478 of collisions as well. Therefore, there is no need to specify 479 further rules here. 481 3.6. Example of UAS Behavior 483 This section contains an example of a UAS that implements this 484 specification using an UPDATE request and a 2xx response to a re- 485 INVITE in order to revert to the pre-re-INVITE state. The example, 486 which is shown in Figure 4, assumes that the UAS requires its user's 487 input in order to accept or reject the addition of a video stream and 488 uses reliable provisional responses [RFC3262] (PRACK transactions are 489 not shown for clarity). 491 UAC UAS 493 | | 494 |-------------(1) INVITE SDP1--------------->| 495 | | 496 |<------------(2) 200 OK SDP2----------------| 497 | | 498 |------------------(3) ACK------------------>| 499 | | 500 | | 501 |-------------(4) INVITE SDP3--------------->| 502 | | 503 |<----(5) 183 Session Progress SDP4----------| 504 | | 505 |-------------(6) UPDATE SDP5--------------->| 506 | | 507 |<------------(7) 200 OK SDP6----------------| 508 | | 509 | | 510 |<------------(8) UPDATE SDP7----------------| 511 | | 512 |-------------(9) 200 OK SDP8--------------->| 513 | | 514 |<--------------(10) 200 OK------------------| 515 | | 516 |-----------------(11) ACK------------------>| 517 | | 519 Figure 4: Rejection of a video stream by the user 521 The UAs perform an offer/answer exchange to establish an audio only 522 session: 524 SDP1: 525 m=audio 30000 RTP/AVP 0 526 c=IN IP4 192.0.2.1 528 SDP2: 529 m=audio 31000 RTP/AVP 0 530 c=IN IP4 192.0.2.5 532 At a later point, the UAC sends a re-INVITE (4) in order to add a new 533 codec to the audio stream and to add a video stream to the session. 535 SDP3: 536 m=audio 30000 RTP/AVP 0 3 537 c=IN IP4 192.0.2.1 538 m=video 30002 RTP/AVP 31 539 c=IN IP4 192.0.2.1 541 In (5), the UAS accepts the addition of the audio codec but does not 542 accept the video stream yet (it provides a null IP address instead of 543 setting the stream to 'inactive' because inactive streams still need 544 to exchange RTCP traffic). 546 SDP4: 547 m=audio 31000 RTP/AVP 0 3 548 c=IN IP4 192.0.2.5 549 m=video 31002 RTP/AVP 31 550 c=IN IP4 0.0.0.0 552 At a later point, the UAC sends an UPDATE request (6) to remove the 553 original audio codec from the audio stream (the UAC could have also 554 used the PRACK to (5) to request this change). 556 SDP5: 557 m=audio 30000 RTP/AVP 3 558 c=IN IP4 192.0.2.1 559 m=video 30002 RTP/AVP 31 560 c=IN IP4 192.0.2.1 562 SDP6: 563 m=audio 31000 RTP/AVP 3 564 c=IN IP4 192.0.2.5 565 m=video 31002 RTP/AVP 31 566 c=IN IP4 0.0.0.0 568 Yet at a later point, the UAS's user rejects the addition of the 569 video stream. Additionally, the UAS decides to revert to the 570 original audio codec. Consequently, the UAS sends an UPDATE request 571 (8) setting the port of the video stream to zero and offering the 572 original audio codec in its SDP. 574 SDP7: 575 m=audio 31000 RTP/AVP 0 576 c=IN IP4 192.0.2.5 577 m=video 0 RTP/AVP 31 578 c=IN IP4 0.0.0.0 580 The UAC accepts the change in the audio codec in its 200 (OK) 581 response (9) to the UPDATE request. 583 SDP8: 584 m=audio 30000 RTP/AVP 0 585 c=IN IP4 192.0.2.1 586 m=video 0 RTP/AVP 31 587 c=IN IP4 192.0.2.1 589 The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note 590 that the media state after this 200 (OK) response is the same as the 591 pre-re-INVITE media state. 593 3.7. Example of UAC Behavior 595 Figure 5 shows an example of a race condition situation in which the 596 UAs end up with different views of the state of the session. The UAs 597 in Figure 5 are involved in a session that, just before the message 598 flows in the figures starts, includes a sendrecv audio stream and an 599 inactive video stream. UA1 sends a re-INVITE (1) requesting to make 600 the video stream sendrecv. 602 SDP1: 603 m=audio 20000 RTP/AVP 0 604 a=sendrecv 605 m=video 20002 RTP/AVP 31 606 a=sendrecv 608 UA2 is configured to automatically accept incoming video streams but 609 to ask for user input before generating an outgoing video stream. 610 Therefore, UAS2 makes the video stream recvonly by returning a 183 611 (Session Progress) response (2). 613 SDP2: 614 m=audio 30000 RTP/AVP 0 615 a=sendrecv 616 m=video 30002 RTP/AVP 31 617 a=recvonly 619 When asked for input, UA2's user chooses not to have either incoming 620 or outgoing video. In order to make the video stream inactive, UA2 621 returns a 4xx error response (5) to the re-INVITE. The ACK request 622 (6) for this error response is generated by the proxy between both 623 user agents. Note that this error response undoes already-executed 624 changes. So, UA2 is a legacy UA that does not support this 625 specification. 627 The proxy relays the 4xx response (7) towards UA1. However, the 4xx 628 response (7) takes time to arrive to UA1 (e.g., the response may have 629 been sent over UDP and the first few retransmissions were lost). In 630 the meantime, UA2's user decides to put the audio stream on hold. 631 UA2 sends an UPDATE request (8) making the audio stream recvonly. 632 The video stream, which is inactive, is not modified and, thus, 633 continues being inactive. 635 SDP3: 636 m=audio 30000 RTP/AVP 0 637 a=recvonly 638 m=video 30002 RTP/AVP 31 639 a=inactive 641 The proxy relays the UPDATE request (9) to UA1. The UPDATE request 642 (9) arrives at UA1 before the 4xx response (7) that had been 643 previously sent. UA1 accepts the changes in the UPDATE request and 644 returns a 200 (OK) response (10) to it. 646 SDP4: 647 m=audio 20000 RTP/AVP 0 648 a=sendonly 649 m=video 30002 RTP/AVP 31 650 a=inactive 652 At a later point, the 4xx response (7) finally arrives at UA1. This 653 response makes the session return to its pre-re-INVITE state. 654 Therefore, for UA1, the audio stream is sendrecv and the video stream 655 is inactive. However, for UA2, the audio stream is recvonly (the 656 video stream is also inactive). 658 a:sendrecv a:sendrecv 659 v:inactive v:inactive 661 UA1 Proxy UA2 663 | | | 664 |----(1) INVITE SDP1-->| | 665 | |----(2) INVITE SDP1-->| 666 | | | 667 | |<----(3) 183 SDP2-----| a:sendrecv 668 a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly 669 v:sendonly | | | 670 | |<------(5) 4xx -------| 671 | |-------(6) ACK ------>| a:sendrecv 672 | +-(7) 4xx -| | v:inactive 673 | | |<---(8) UPDATE SDP3---| 674 |<---(9) UPDATE SDP3---| | 675 | | | | 676 a:sendonly |---(10) 200 OK SDP4-->| | 677 v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly 678 |<-(7) 4xx -+ | | v:inactive 679 a:sendrecv |------(12) ACK ------>| | 680 v:inactive | | | 682 a: status of the audio stream 683 v: status of the video stream 685 Figure 5: Message flow with race condition 687 After the message flow in Figure 5, following the recommendations in 688 this section, when UA1 received an error response (7) that undid 689 already-executed changes, UA1 would generate an UPDATE request with 690 an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and 691 inactive video). UA2 could then return a 200 (OK) response to the 692 UPDATE request making the audio stream recvonly, which is the state 693 UA2's user had requested. Such an UPDATE transaction would get the 694 UAs back into synchronization. 696 3.8. Clarifications on Cancelling Re-INVITEs 698 Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS 699 responding to a CANCEL request. Such a UAS responds to the INVITE 700 request with a 487 (Request Terminated) at the 'should' level. Per 701 the rules specified in Section 3.3, if the INVITE request was a re- 702 INVITE and some of its requested changes had already been executed, 703 the UAS would return a 2xx response instead. 705 4. Target-refresh Handling 707 The following sections discuss target-refresh request handling. 709 4.1. Background on Target-refresh Requests 711 A target-refresh request is defined as follows in Section 6 of RFC 712 3261 [RFC3261]: 714 "A target-refresh request sent within a dialog is defined as a 715 request that can modify the remote target of the dialog." 717 Additionally, 2xx responses to target-refresh requests can also 718 update the remote target of the dialog. As discussed in Section 12.2 719 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. 721 RFC 3261 [RFC3261] specifies the behavior of UASs receiving target- 722 refresh requests and of UACs receiving a 2xx response for a target- 723 refresh request. 725 Section 12.2.2 of RFC 3261 [RFC3261] says: 727 "When a UAS receives a target-refresh request, it MUST replace the 728 dialog's remote target URI with the URI from the Contact header 729 field in that request, if present." 731 Section 12.2.1.2 of RFC 3261 [RFC3261] says: 733 "When a UAC receives a 2xx response to a target-refresh request, 734 it MUST replace the dialog's remote target URI with the URI from 735 the Contact header field in that response, if present." 737 The fact that re-INVITEs can be long-lived transactions and can have 738 other transactions within them makes it necessary to revise these 739 rules. Section 4.2 specifies new rules for the handing of target- 740 refresh requests. Note that the new rules apply to any target- 741 refresh request, not only to re-INVITEs. 743 4.2. Clarification on the Atomicity of Target-Refresh Requests 745 The remote target of a dialog is a special type of state information 746 because of its essential role in the exchange of SIP messages between 747 UAs in a dialog. A UA involved in a dialog receives the remote 748 target of the dialog from the remote UA. The UA uses the remote 749 target to send SIP requests to the remote UA. 751 The remote target is a piece of state information that is not meant 752 to be negotiated. When a UAC changes its address, the UAC simply 753 communicates its new address to the UAS in order to remain reachable 754 by the UAS. UAs need to follow the behavior specified in Section 4.3 755 and Section 4.4 of this specification instead of that specified in 756 RFC 3261 [RFC3261], which was discussed in Section 4.1. The new 757 behavior regarding target-refresh requests implies that a target- 758 refresh request can, in some cases, update the remote target even if 759 the request is responded with a final error response. This means 760 that target-refresh requests are not atomic. 762 4.3. UAC Behavior 764 Behavior of a UAC after having sent a target-refresh request updating 765 the remote target: 767 If the UAC receives an error response to the target-refresh request, 768 the UAS has not updated its remote target. 770 This allows UASs to authenticate target-refresh requests. 772 If the UAC receives a reliable provisional response or a 2xx response 773 to the target-refresh request, or the UAC receives a request on the 774 new target, the UAS has updated its remote target. The UAC can 775 consider the target refresh operation completed. 777 Even if the target request was a re-INVITE and the final response 778 to the re-INVITE was an error response, the UAS would not revert 779 to the pre-re-INVITE remote target. 781 If the UAC receives a reliable provisional response or a 2xx response 782 to the target-refresh request, the UAC MUST replace the dialog's 783 remote target URI with the URI from the Contact header field in that 784 response, if present. 786 When interacting with a UAS that does not support reliable 787 provisional responses or UPDATE requests, a UAC SHOULD NOT use the 788 same target refresh request to refresh the target and to make session 789 changes unless the session changes can be trivially accepted by the 790 UAS (e.g., an IP address change). Piggybacking a target refresh with 791 more complicated session changes in this situation would make it 792 unnecessarily complicated for the UAS to accept the target refresh 793 while rejecting the session changes. 795 4.4. UAS Behavior 797 Behavior of a UAS after having received a target-refresh request 798 updating the remote target: 800 If the UAS receives a target-refresh request that has been properly 801 authenticated, the UAS SHOULD generate a reliable provisional 802 response or a 2xx response to the target-refresh request. If 803 generating such responses is not possible (e.g., the UAS does not 804 support reliable provisional responses and needs user input before 805 generating a final response), the UAS SHOULD send a request to the 806 UAC using the new remote target (if the UAS does not need to send a 807 request for other reasons, the UAS can send an UPDATE request). On 808 sending a reliable provisional response or a 2xx response to the 809 target-refresh request, or a request to the new remote target, the 810 UAS MUST replace the dialog's remote target URI with the URI from the 811 Contact header field in the target-refresh request. 813 Reliable provisional responses in SIP are specified in RFC 3262 814 [RFC3262]. In this document, reliable provisional responses are 815 those that use the mechanism defined in RFC 3262 [RFC3262] or any 816 other SIP-based mechanism that may be specified in the future. 817 Other specifications may define ways to send provisional responses 818 reliably using non-SIP mechanisms (e.g., using media-level 819 messages to acknowledge the reception of the SIP response). For 820 the purposes of this document, provisional responses using those 821 non-SIP mechanisms are considered unreliable responses. 823 If instead of sending a reliable provisional response or a 2xx 824 response to the target-refresh request, or a request to the new 825 target, the UAS generates an error response to the target-refresh 826 request, the UAS MUST NOT update its dialog's remote target. 828 4.5. Race Conditions and Target Refreshes 830 SIP provides request ordering by using the Cseq header field. That 831 is, a UAS that receives two requests at roughly the same time can 832 know which one is newer. However, SIP does not provide ordering 833 between responses and requests. For example, if a UA receives a 200 834 (OK) response to an UPDATE request and an UPDATE request at roughly 835 the same time, the UA cannot know which one was sent last. Since 836 both messages can refresh the remote target, the UA needs to know 837 which message was sent last in order to know which remote target 838 needs to be used. 840 Some of the procedures discussed in Section 3.5 could avoid these 841 types of situations. However, they are currently defined only for 842 SIP messages involved in offer/answer exchanges (e.g., the procedures 843 do not apply to an UPDATE request that does not carry an offer). The 844 following rules make those procedures applicable to the race 845 conditions described above so that UASs can cope with them. 847 When checking for glare situations, UAs MUST treat every UPDATE 848 request as if it contained an offer. Additionally, UAs MUST treat 849 the exchange of a 2xx response to an INVITE request and its 850 corresponding ACK request as an offer/answer exchange. Consequently, 851 the rules regarding glare situations applicable to offer/answer 852 exchanges are also applicable to those exchanges. 854 5. Re-INVITE Transaction Routing 856 The following sections discuss re-INVITE transaction routing. 858 5.1. Background on re-INVITE Transaction Routing 860 Re-INVITEs are routed using the dialog's route set, which contains 861 all the proxy servers that need to be traversed by requests send 862 within the dialog. Responses to the re-INVITE are routed using the 863 Via entries in the re-INVITE. 865 ACK requests for 2xx responses and for non-2xx final responses are 866 generated in different ways. As specified in Sections 14.1 and 867 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are 868 generated by the UAC core and are routed using the dialog's route 869 set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK 870 requests for non-2xx final responses are generated by the INVITE 871 client transaction (i.e., they are generated in a hop-by-hop fashion 872 by the proxy servers in the path) and are sent to the same transport 873 address as the re-INVITE. 875 5.2. Problems with UAs Losing their Contact 877 Refreshing the dialog's remote target during a re-INVITE transaction 878 (see Section 4.2) presents some issues because of the fact that Re- 879 INVITE transactions can be long lived. As described in Section 5.1, 880 the way responses to the re-INVITE and ACKs for non-2xx final 881 responses are routed is fixed once the re-INVITE is sent. The 882 routing of this messages does not depend on the dialog's route set 883 and, thus, target refreshes within an ongoing re-INVITE do not affect 884 their routing. A UA that changes its location (i.e., performs a 885 target refresh) but is still reachable at its old location will be 886 able to receive those messages (which will be sent to the old 887 location). However, a UA that cannot be reachable at its old 888 location any longer will not be able to receive them. 890 5.3. UAS Losing its Contact: UAC Behavior 892 When a UAS that moves to a new contact and loses its old contact 893 generates a non-2xx final response to the re-INVITE, it will not be 894 able to receive the ACK request. The entity receiving the response 895 and, thus, generating the ACK request will either get a transport 896 error or a timeout error, which, as described in Section 8.1.3.1 of 897 RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) 898 response and as a 408 (Request Timeout) response, respectively. If 899 the sender of the ACK request is a proxy server, it will typically 900 ignore this error. If the sender of the ACK request is the UAC, 901 according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed 902 to (at the "should" level) terminate the dialog by sending a BYE 903 request. However, because of the special properties of ACK requests 904 for non-2xx final responses, most existing UACs do not terminate the 905 dialog when ACK request fails, which is fortunate. 907 A UAC that accepts a target refresh within a re-INVITE MUST ignore 908 transport and timeout errors when generating an ACK request for a 909 non-2xx final response if the UAC is communicating directly with the 910 UAS (i.e., there are no proxy servers in the dialog's route set). 912 5.4. UAC Losing its Contact: UAS Behavior 914 When a UAC moves to a new contact and loses its old contact, it will 915 not be able to receive responses to the re-INVITE. Consequently, it 916 will never generate an ACK request. 918 As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server 919 that gets an error when forwarding a response does not take any 920 measurements. Consequently, proxy servers relaying responses will 921 effectively ignore the error. 923 If there are no proxy servers in the dialog's route set, the UAS will 924 get an error when sending a non-2xx final response. The UAS core 925 will be notified of the transaction failure, as described in Section 926 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate 927 the dialog on encountering this failure, which is fortunate. 929 A UAS that accepts a target refresh within a re-INVITE MUST ignore 930 transport and timeout errors when generating a non-2xx final response 931 to the re-INVITE if the UAS is communicating directly with the UAC 932 (i.e., there are no proxy servers in the dialog's route set). 934 Regardless of the presence or absence of proxy servers in the 935 dialog's route set, a UAS generating a 2xx response to the re-INVITE 936 will never receive an ACK request for it. According to Section 14.2 937 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" 938 level) terminate the dialog by sending a BYE request. 940 A UAS that accepts a target refresh within a re-INVITE and never 941 receives an ACK request after having sent a 2xx response to the re- 942 INVITE SHOULD NOT terminate the dialog. If the UA has received a new 943 re-INVITE with a higher CSeq sequence number than the original one, 944 the UA SHOULD just ignore the error. If the UA has not received such 945 a re-INVITE, UA SHOULD generate a new re-INVITE in order to make sure 946 that both UAs have a common view of the state of the session. 948 Note that the UA generates a re-INVITE and not an UPDATE request 949 because UPDATE requests can be sent within a re-INVITE. By 950 accepting the incoming re-INVITE, the remote UA indicates that the 951 old re-INVITE transaction has already been terminated. 953 A 500 (Server Internal Error) response to the new re-INVITE would 954 mean that the remote UA was still processing the original re-INVITE. 955 This may be because the remote UA is a legacy UA that does not 956 support this specification. In this situation, the UA SHOULD follow 957 the original recommendation in RFC 3261 [RFC3261] and terminate the 958 dialog. 960 5.5. UAC Losing its Contact: UAC Behavior 962 When a UAC moves to a new contact and loses its old contact, it will 963 not be able to receive responses to the re-INVITE. Consequently, it 964 will never generate an ACK request. 966 Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE 967 and cause the INVITE client transaction corresponding to the re- 968 INVITE to enter the "Terminated" state. The UAC SHOULD also send a 969 new re-INVITE in order to make sure that both UAs have a common view 970 of the state of the session. 972 Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new 973 incoming re-INVITEs as soon as it has generated a final response 974 to the previous INVITE request, which had a lower CSeq sequence 975 number. 977 6. Security Considerations 979 This document does not introduce any new security issue. It just 980 clarifies how certain transactions should be handled in SIP. 981 Security issues related to re-INVITEs and UPDATE requests are 982 discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. 984 7. IANA Considerations 986 There are no IANA actions associated with this document. 988 8. Acknowledgements 990 Paul Kyzivat provided useful ideas on the topics discussed in this 991 document. 993 9. References 995 9.1. Normative References 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", BCP 14, RFC 2119, March 1997. 1000 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1001 A., Peterson, J., Sparks, R., Handley, M., and E. 1002 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1003 June 2002. 1005 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1006 Provisional Responses in Session Initiation Protocol 1007 (SIP)", RFC 3262, June 2002. 1009 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1010 with Session Description Protocol (SDP)", RFC 3264, 1011 June 2002. 1013 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1014 UPDATE Method", RFC 3311, October 2002. 1016 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1017 Initiation Protocol (SIP) Preconditions Framework", 1018 RFC 4032, March 2005. 1020 9.2. Informative References 1022 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1023 (ICE): A Protocol for Network Address Translator (NAT) 1024 Traversal for Offer/Answer Protocols", RFC 5245, 1025 April 2010. 1027 Authors' Addresses 1029 Gonzalo Camarillo (editor) 1030 Ericsson 1031 Hirsalantie 11 1032 Jorvas 02420 1033 Finland 1035 Email: Gonzalo.Camarillo@ericsson.com 1037 Christer Holmberg 1038 Ericsson 1039 Hirsalantie 11 1040 Jorvas 02420 1041 Finland 1043 Email: Christer.Holmberg@ericsson.com 1045 Yang Gao 1046 ZTE 1047 China 1049 Email: gao.yang2@zte.com.cn