idnits 2.17.1 draft-ietf-sipcore-reinvite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (December 10, 2009) is 5251 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 13, 2010 ZTE 7 December 10, 2009 9 Re-INVITE and Target-refresh Request Handling in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-reinvite-00.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 to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on June 13, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Background on Re-INVITE Handling by UASs . . . . . . . . . . . 4 64 4. Problems with Error Responses and Already-executed Changes . . 8 65 5. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Example of UAS Behavior . . . . . . . . . . . . . . . . . . . 10 68 8. Example of UAC Behavior . . . . . . . . . . . . . . . . . . . 13 69 9. Clarifications on Cancelling Re-INVITEs . . . . . . . . . . . 15 70 10. Background on Target-Refresh Requests . . . . . . . . . . . . 16 71 11. Clarification on the Atomicity of Target-Refresh Requests . . 16 72 12. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 13. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 14. Race Conditions and Target Refreshes . . . . . . . . . . . . . 18 75 15. Background on re-INVITE Transaction Routing . . . . . . . . . 18 76 16. Problems with UAs Losing their Contact . . . . . . . . . . . . 19 77 17. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . . . 19 78 18. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . . . 20 79 19. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . . . 21 80 20. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 83 23. Normative References . . . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request 89 sent within an existing dialog is known as a re-INVITE. A re-INVITE 90 is used to modify session parameters, dialog parameters, or both. 91 That is, a single re-INVITE can change both the parameters of its 92 associated session (e.g., changing the IP address where a media 93 stream is received) and the parameters of its associated dialog 94 (e.g., changing the remote target of the dialog). A re-INVITE can 95 change the remote target of a dialog because it is a target refresh 96 request, as defined in Section 6 of RFC 3261 [RFC3261]. 98 A re-INVITE transaction has an offer/answer [RFC3264] exchange 99 associated to it. The UAC (User Agent Client) generating a given re- 100 INVITE can act as the offerer or as the answerer. A UAC willing to 101 act the offerer includes an offer in the re-INVITE. The UAS then 102 provides an answer in a response to the re-INVITE. A UAC willing to 103 act as answerer does not include an offer in the re-INVITE. The UAS 104 then provides an offer in a response to the re-INVITE becoming, thus, 105 the offerer. 107 Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] 108 transactions) can also have offer/answer exchanges associated to 109 them. A UA (User Agent) can act as the offerer or the answerer in 110 any of these transactions regardless of whether the UA was the 111 offerer or the answerer in the umbrella re-INVITE transaction. 113 There has been some confusion among implentors regarding how a UAS 114 (User Agent Server) should handle re-INVITEs. In particular, 115 implementors requested clarifications on which type of response a UAS 116 should generate in different situations. In this document, we 117 clarify these issues. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 UA: User Agent. 127 UAC: User Agent Client. 129 UAS: User Agent Server. 131 3. Background on Re-INVITE Handling by UASs 133 A UAS receiving a re-INVITE will need to, eventually, generate a 134 response to it. Some re-INVITEs can be responded to immediately 135 because their handling does not require user interaction (e.g., 136 changing the IP address where a media stream is received). The 137 handling of other re-INVITEs requires user interaction (e.g., adding 138 a video stream to an audio-only session). Therefore, these re- 139 INVITEs cannot be responded to immediately. 141 An error response to a re-INVITE has the following semantics. As 142 specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is 143 rejected, no state changes are performed. These state changes 144 include state changes associated to the re-INVITE transaction and all 145 other transactions within the re-INVITE (target refreshes, which are 146 discussed in Section 10, are an exception to this rule because in 147 certain cases they are performed even if the re-INVITE is rejected). 148 That is, the session and dialog states are the same as before the re- 149 INVITE was received. The example in Figure 1 illustrates this point. 151 UAC UAS 153 | | 154 |-------------(1) INVITE SDP1--------------->| 155 | | 156 |<------------(2) 200 OK SDP2----------------| 157 | | 158 |------------------(3) ACK------------------>| 159 | | 160 | | 161 |-------------(4) INVITE SDP3--------------->| 162 | | 163 |<-----------------(5) 4xx-------------------| 164 | | 165 |------------------(6) ACK------------------>| 166 | | 168 Figure 1: Rejection of a re-INVITE 170 The UAs perform an offer/answer exchange to establish an audio-only 171 session: 173 SDP1: 174 m=audio 30000 RTP/AVP 0 176 SDP2: 177 m=audio 31000 RTP/AVP 0 179 At a later point, the UAC sends a re-INVITE (4) in order to add a 180 video stream to the session. 182 SDP3: 183 m=audio 30000 RTP/AVP 0 184 m=video 30002 RTP/AVP 31 186 The UAS is automatically configured to reject video streams. 187 Consequently, the UAS returns an error response (5). At that point, 188 the session parameters in use are still those resulting from the 189 initial offer/answer exchange, which are described by SDP1 and SDP2. 190 That is, the session and dialog states are the same as before the re- 191 INVITE was received. 193 In the previous example, the UAS rejected all the changes requested 194 in the re-INVITE by returning an error response. However, there are 195 situations where a UAS wants to accept some but not all the changes 196 requested in a re-INVITE. In these cases, the UAS generates a 200 197 (OK) response with an SDP indicating which changes were accepted and 198 which were not. The example in Figure 2 illustrates this point. 200 UAC UAS 202 | | 203 |-------------(1) INVITE SDP1--------------->| 204 | | 205 |<------------(2) 200 OK SDP2----------------| 206 | | 207 |------------------(3) ACK------------------>| 208 | | 209 | | 210 |-------------(4) INVITE SDP3--------------->| 211 | | 212 |<------------(5) 200 OK SDP4----------------| 213 | | 214 |------------------(6) ACK------------------>| 215 | | 217 Figure 2: Automatic rejection of a video stream 219 The UAs perform an offer/answer exchange to establish an audio only 220 session: 222 SDP1: 223 m=audio 30000 RTP/AVP 0 224 c=IN IP4 192.0.2.1 226 SDP2: 227 m=audio 31000 RTP/AVP 0 228 c=IN IP4 192.0.2.5 230 At a later point, the UAC moves to an access that provides a higher- 231 bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to 232 change the IP address where it receives the audio stream to its new 233 IP address, and add a video stream to the session. 235 SDP3: 236 m=audio 30000 RTP/AVP 0 237 c=IN IP4 192.0.2.2 238 m=video 30002 RTP/AVP 31 239 c=IN IP4 192.0.2.2 241 The UAS is automatically configured to reject video streams. 242 However, the UAS needs to accept the change of the audio stream's 243 remote IP address. Consequently, the UAS returns a 200 (OK) response 244 and sets the port of the video stream to zero in its SDP. 246 SDP4: 247 m=audio 31000 RTP/AVP 0 248 c=IN IP4 192.0.2.5 249 m=video 0 RTP/AVP 31 250 c=IN IP4 192.0.2.2 252 In the previous example, the UAS was configured to automatically 253 reject the addition of video streams. The example in Figure 3 254 assumes that the UAS requires its user's input in order to accept or 255 reject the addition of a video stream and uses reliable provisional 256 responses [RFC3262] (PRACK transactions are not shown for clarity). 258 UAC UAS 260 | | 261 |-------------(1) INVITE SDP1--------------->| 262 | | 263 |<------------(2) 200 OK SDP2----------------| 264 | | 265 |------------------(3) ACK------------------>| 266 | | 267 | | 268 |-------------(4) INVITE SDP3--------------->| 269 | | 270 |<----(5) 183 Session Progress SDP4----------| 271 | | 272 | | 273 |<------------(6) UPDATE SDP5----------------| 274 | | 275 |-------------(7) 200 OK SDP6--------------->| 276 | | 277 |<---------------(8) 200 OK------------------| 278 | | 279 |------------------(9) ACK------------------>| 280 | | 282 Figure 3: Rejection of a video stream by the user 284 Everything up to (4) is identical to the previous example. In (5), 285 the UAS accepts the change of the audio stream's remote IP address 286 but does not accept the video stream yet (it provides a null IP 287 address instead of setting the stream to 'inactive' because inactive 288 streams still need to exchange RTCP traffic). 290 SDP4: 291 m=audio 31000 RTP/AVP 0 292 c=IN IP4 192.0.2.5 293 m=video 31002 RTP/AVP 31 294 c=IN IP4 0.0.0.0 296 At a later point, the UAS's user rejects the addition of the video 297 stream. Consequently, the UAS sends an UPDATE request setting the 298 port of the video stream to zero in its SDP. 300 SDP5: 301 m=audio 31000 RTP/AVP 0 302 c=IN IP4 192.0.2.5 303 m=video 0 RTP/AVP 31 304 c=IN IP4 0.0.0.0 306 The UAS now returns a 200 (OK) response to the re-INVITE. 308 In all the previous examples, the UAC was the offerer in the re- 309 INVITE transaction. Examples with UACs acting as the answerers would 310 be similar. 312 4. Problems with Error Responses and Already-executed Changes 314 Section 3 contains examples on how a UAS rejects all the changes 315 requested in a re-INVITE without executing any of them by returning 316 an error response (Figure 1), and how a UAS executes some of the 317 changes requested in a re-INVITE and rejects some of them by 318 returning a 2xx response (Figure 2 and Figure 3). A UAS can accept 319 and reject different sets of changes simultaneously (Figure 2) or at 320 different times (Figure 3). 322 The scenario that created confusion among implementors consists of a 323 UAS that receives a re-INVITE, executes some of the changes requested 324 in it, and then wants to reject all those already-executed changes 325 and revert to the pre-re-INVITE state. Such a UAS may consider 326 returning an error response to the re-INVITE (the message flow would 327 be similar to the one in Figure 1), or using an UPDATE request to 328 revert to the pre-re-INVITE state and then returning a 2xx response 329 to the re-INVITE (the message flow would be similar to the one in 330 Figure 3). This section explains the problems associated with 331 returning an error response in these circumstances. In order to 332 avoid these problems, the UAS should use the latter option (UPDATE 333 request plus a 2xx response). Section 5 and Section 6 contain the 334 normative statements needed to avoid these problems. 336 The reason for not using an error response to undo already executed 337 changes is that an error response to a re-INVITE for which changes 338 have already been executed is effectively requesting a change in the 339 session or the dialog state. However, the UAC has no means to reject 340 those changes if it is unable to execute them. That is, if the UAC 341 is unable to revert to the pre-re-INVITE state, it will not be able 342 to communicate this fact to the UAS. 344 Using an error response to undo already executed changes presents an 345 additional problem. Section 4 of [RFC3264] specifies rules to avoid 346 glare situations (i.e., to avoid offer/answer collisions in race 347 conditions). Even when both UAs generate an offer at the same time, 348 there are rules to determine which one should be processed first. 349 However, there are no rules to avoid a collision between an offer in 350 an UPDATE request and an error response for a re-INVITE. Since both 351 the UPDATE request and the error response would request changes, it 352 would not be clear which changes would need to be executed first. 353 This is yet another reason why UASs should not use error responses to 354 undo already-executed changes. 356 5. UAS Behavior 358 UASs should only return an error response to a re-INVITE if no 359 changes to the session or to the dialog state have been executed 360 since the re-INVITE was received. Such an error response indicates 361 that no changes have been executed as a result of the re-INVITE or 362 any other transaction within it. 364 If any of the changes requested in a re-INVITE or in any transaction 365 within it have already been executed (with the exception of target 366 refreshes), the UAS MUST always return a 2xx response. 368 A change to the session state is considered to have been executed 369 when the new media parameters are being used. Therefore, a change to 370 a stream subject to preconditions [RFC4032] is considered to have 371 been executed when the new media parameters start being used; not 372 when the preconditions for the stream are met. Connection 373 establishment messages (e.g., TCP SYN) and connectivity checks (e.g., 374 when using ICE [I-D.ietf-mmusic-ice]) are not considered media 375 either. A UA considers the new parameters to be in use when it sends 376 media using them, or when media that uses the new parameters is 377 received, which should be interpreted as follows. From Section 8.3.1 378 of RFC 3264 [RFC3264]: 380 "Received, in this case, means that the media is passed to a media 381 sink. This means that if there is a playout buffer, the agent 382 would continue to listen on the old port until the media on the 383 new port reached the top of the playout buffer. At that time, it 384 MAY cease listening for media on the old port." 386 TODO: RFC3264 assumes media streams that carry media continuously. 387 So, it considers that an UA should continue listening to the old port 388 (i.e., using the old parameters) until it sends media or receives 389 media on the new port. However, if two UASs perform an offer/answer 390 exchange on a stream that only carries media every now and then, the 391 UAs will need to be ready to receive media on both the old and the 392 new port for a long time. Shall we define some type of timeout for 393 this? 394 A UAS MUST NOT generate an error response to a re-INVITE if it has 395 generated a prior offer for which it has not yet received an answer 396 or a rejection. 398 6. UAC Behavior 400 A UAC that receives an error response to a re-INVITE that undoes 401 already-executed changes within the re-INVITE may be facing a legacy 402 UAS that does not support this specification (i.e., a UAS that does 403 not follow the guidelines in Section 5). There are certain race 404 condition situations that get both user agents out of 405 synchronization. In order to cope with these race condition 406 situations, a UAC that receives an error response to a re-INVITE for 407 which changes have been already executed SHOULD generate a new re- 408 INVITE or UPDATE request in order to make sure that both UAs have a 409 common view of the state of the session. The purpose of this new 410 offer/answer exchange is to synchronize both UAs, not to request 411 changes that the UAS may choose to reject. Therefore, the session 412 parameters in the offer/answer exchange SHOULD be as close as those 413 in the pre-re-INVITE state as possible. 415 7. Example of UAS Behavior 417 This section contains an example of a UAS that supports this 418 specification using an UPDATE request and a 2xx response to a re- 419 INVITE in order to revert to the pre-re-INVITE state. The example, 420 which is shown in Figure 4, assumes that the UAS requires its user's 421 input in order to accept or reject the addition of a video stream and 422 uses reliable provisional responses [RFC3262] (PRACK transactions are 423 not shown for clarity). 425 UAC UAS 427 | | 428 |-------------(1) INVITE SDP1--------------->| 429 | | 430 |<------------(2) 200 OK SDP2----------------| 431 | | 432 |------------------(3) ACK------------------>| 433 | | 434 | | 435 |-------------(4) INVITE SDP3--------------->| 436 | | 437 |<----(5) 183 Session Progress SDP4----------| 438 | | 439 |-------------(6) UPDATE SDP5--------------->| 440 | | 441 |<------------(7) 200 OK SDP6----------------| 442 | | 443 | | 444 |<------------(8) UPDATE SDP7----------------| 445 | | 446 |-------------(9) 200 OK SDP8--------------->| 447 | | 448 |<--------------(10) 200 OK------------------| 449 | | 450 |-----------------(11) ACK------------------>| 451 | | 453 Figure 4: Rejection of a video stream by the user 455 The UAs perform an offer/answer exchange to establish an audio only 456 session: 458 SDP1: 459 m=audio 30000 RTP/AVP 0 460 c=IN IP4 192.0.2.1 462 SDP2: 463 m=audio 31000 RTP/AVP 0 464 c=IN IP4 192.0.2.5 466 At a later point, the UAC sends a re-INVITE (4) in order to add a new 467 codec to the audio stream and to add a video stream to the session. 469 SDP3: 470 m=audio 30000 RTP/AVP 0 3 471 c=IN IP4 192.0.2.1 472 m=video 30002 RTP/AVP 31 473 c=IN IP4 192.0.2.1 475 In (5), the UAS accepts the addition of the audio codec but does not 476 accept the video stream yet (it provides a null IP address instead of 477 setting the stream to 'inactive' because inactive streams still need 478 to exchange RTCP traffic). 480 SDP4: 481 m=audio 31000 RTP/AVP 0 3 482 c=IN IP4 192.0.2.5 483 m=video 31002 RTP/AVP 31 484 c=IN IP4 0.0.0.0 486 At a later point, the UAC sends an UPDATE request (6) to remove the 487 original audio codec from the audio stream (the UAC could have also 488 used the PRACK to (5) to request this change). 490 SDP5: 491 m=audio 30000 RTP/AVP 3 492 c=IN IP4 192.0.2.1 493 m=video 30002 RTP/AVP 31 494 c=IN IP4 192.0.2.1 496 SDP6: 497 m=audio 31000 RTP/AVP 3 498 c=IN IP4 192.0.2.5 499 m=video 31002 RTP/AVP 31 500 c=IN IP4 0.0.0.0 502 Yet at a later point, the UAS's user rejects the addition of the 503 video stream. Additionally, the UAS decides to revert to the 504 original audio codec. Consequently, the UAS sends an UPDATE request 505 (8) setting the port of the video stream to zero and offering the 506 original audio codec in its SDP. 508 SDP7: 509 m=audio 31000 RTP/AVP 0 510 c=IN IP4 192.0.2.5 511 m=video 0 RTP/AVP 31 512 c=IN IP4 0.0.0.0 514 The UAC accepts the change in the audio codec in its 200 (OK) 515 response (9) to the UPDATE request. 517 SDP8: 518 m=audio 30000 RTP/AVP 0 519 c=IN IP4 192.0.2.1 520 m=video 0 RTP/AVP 31 521 c=IN IP4 192.0.2.1 523 The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note 524 that the media state after this 200 (OK) response is the same as the 525 pre-re-INVITE media state. 527 8. Example of UAC Behavior 529 Figure 5 shows an example of a race condition situation in which the 530 UAs end up with different views of the state of the session. The UAs 531 in Figure 5 are involved in a session that, just before the message 532 flows in the figures starts, includes a sendrecv audio stream and an 533 inactive video stream. UA1 sends a re-INVITE (1) requesting to make 534 the video stream sendrecv. 536 SDP1: 537 m=audio 20000 RTP/AVP 0 538 a=sendrecv 539 m=video 20002 RTP/AVP 31 540 a=sendrecv 542 UA2 is configured to automatically accept incoming video streams but 543 to ask for user input before generating an outgoing video stream. 544 Therefore, UAS2 makes the video stream sendonly by returning a 183 545 (Session Progress) response (2). 547 SDP2: 548 m=audio 30000 RTP/AVP 0 549 a=sendrecv 550 m=video 30002 RTP/AVP 31 551 a=sendonly 553 When asked for input, UA2's user chooses not to have either incoming 554 or outgoing video. In order to make the video stream inactive, UA2 555 returns a 4xx error response (5) to the re-INVITE. The ACK request 556 (6) for this error response is generated by the proxy between both 557 user agents. Note that this error response undoes already-executed 558 changes. So, UA2 is a legacy UA that does not support this 559 specification. 561 The proxy relays the 4xx response (7) towards UA1. However, the 4xx 562 response (7) takes time to arrive to UA1 (e.g., the response may have 563 been sent over UDP and the first few retransmissions were lost). In 564 the meantime, UA2's user decides to put the audio stream on hold. 565 UA2 sends an UPDATE request (8) making the audio stream recvonly. 566 The video stream, which is inactive, is not modified and, thus, 567 continues being inactive. 569 SDP3: 570 m=audio 30000 RTP/AVP 0 571 a=recvonly 572 m=video 30002 RTP/AVP 31 573 a=inactive 575 The proxy relays the UPDATE request (9) to UA1. The UPDATE request 576 (9) arrives at UA1 before the 4xx response (7) that had been 577 previously sent. UA2 accepts the changes in the UPDATE request and 578 returns a 200 (OK) response (10) to it . 580 SDP4: m=audio 20000 RTP/AVP 0 a=sendonly m=video 30002 RTP/AVP 31 581 a=inactive 583 At a later point, the 4xx response (7) finally arrives at UA1. This 584 response makes the session return to its pre-re-INVITE state. 585 Therefore, for UA1, the audio stream is sendrecv and the video stream 586 is inactive. However, for UA2, the audio stream is recvonly (the 587 video stream is also inactive). 589 a:sendrecv a:sendrecv 590 v:inactive v:inactive 592 UA1 Proxy UA2 594 | | | 595 |----(1) INVITE SDP1-->| | 596 | |----(2) INVITE SDP1-->| 597 | | | 598 | |<----(3) 183 SDP2-----| a:sendrecv 599 a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly 600 v:sendonly | | | 601 | |<------(5) 4xx -------| 602 | |-------(6) ACK ------>| a:sendrecv 603 | +-(7) 4xx -| | v:inactive 604 | | |<---(8) UPDATE SDP3---| 605 |<---(9) UPDATE SDP3---| | 606 | | | | 607 a:sendonly |---(10) 200 OK SDP4-->| | 608 v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly 609 |<-(7) 4xx -+ | | v:inactive 610 a:sendrecv |------(12) ACK ------>| | 611 v:inactive | | | 613 a: status of the audio stream 614 v: status of the video stream 616 Figure 5: Message flow with race condition 618 After the message flow in Figure 5, following the recommendations in 619 this section, when UA1 received an error response (7) that undid 620 already-executed changes, UA1 would generate an UPDATE request with 621 an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and 622 inactive video). UA2 could then return a 200 (OK) response to the 623 UPDATE request making the audio stream recvonly, which is the state 624 UA2's user had requested. Such an UPDATE transaction would get the 625 UAs back into synchronization. 627 9. Clarifications on Cancelling Re-INVITEs 629 Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS 630 responding to a CANCEL request. Such a UAS responds to the INVITE 631 request with a 487 (Request Terminated) at the 'should' level. Per 632 the rules specified in Section 5, if the INVITE request was a re- 633 INVITE and some of its requested changes had already been executed, 634 the UAS would return a 2xx response instead. 636 10. Background on Target-Refresh Requests 638 A target-refresh request is defined as follows in Section 6 of RFC 639 3261 [RFC3261]: 641 "A target-refresh request sent within a dialog is defined as a 642 request that can modify the remote target of the dialog." 644 Additionally, 2xx responses to target-refresh requests can also 645 update the remote target of the dialog.. As discussed in Section 646 12.2 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. 648 RFC 3261 [RFC3261] specifies the behavior of UASs receiving target- 649 refresh requests and of UACs receiving a 2xx response for a target- 650 refresh request. 652 Section 12.2.2 of RFC 3261 [RFC3261] says: 654 "When a UAS receives a target-refresh request, it MUST replace the 655 dialog's remote target URI with the URI from the Contact header 656 field in that request, if present." 658 Section 12.2.1.2 of RFC 3261 [RFC3261] says: 660 "When a UAC receives a 2xx response to a target-refresh request, 661 it MUST replace the dialog's remote target URI with the URI from 662 the Contact header field in that response, if present." 664 The fact that re-INVITEs can be long-lived transactions and can have 665 other transactions within them makes it necessary to revise these 666 rules. Section 11 specifies new rules for the handing of target- 667 refresh requests. Note that the new rules apply to any target- 668 refresh request, not only to re-INVITEs. 670 11. Clarification on the Atomicity of Target-Refresh Requests 672 The remote target of a dialog is a special type of state information 673 because of its essential role in the exchange of SIP messages between 674 UAs in a dialog. A UA involved in a dialog receives the remote 675 target of the dialog from the remote UA. The UA uses the remote 676 target to send SIP requests to the remote UA. 678 The remote target is a piece of state information that is not meant 679 to be negotiated. When a UAC changes its address, the UAC simply 680 communicates its new address to the UAS in order to remain reachable 681 by the UAS. UAs need to follow the behavior specified in Section 12 682 and Section 12 instead of that specified in RFC 3261 [RFC3261] and 683 discussed in Section 10. The new behavior regarding target-refresh 684 requests implies that a target-refresh request can, in some cases, 685 update the remote target even if the request is responded with a 686 final error response. This means that target-refresh requests are 687 not atomic. 689 12. UAC Behavior 691 Behavior of a UAC after having sent a target-refresh request updating 692 the remote target: 694 If the UAC receives an error response to the target-refresh request, 695 the UAS has not updated its remote target. 697 This allows UASs to authenticate target-refresh requests. 699 If the UAC receives a reliable provisional response or a 2xx response 700 to the target-refresh request, or the UAC receives a request on the 701 new target, the UAS has updated its remote target. The UAC can 702 consider the target refresh operation completed. 704 Even if the target request was a re-INVITE and the final response 705 to the re-INVITE was an error response, the UAS would not revert 706 to the pre-re-INVITE remote target. 708 If the UAC receives a reliable provisional response or a 2xx response 709 to the target-refresh request, the UAC MUST replace the dialog's 710 remote target URI with the URI from the Contact header field in that 711 response, if present. 713 When interacting with a UACs that does not support reliable 714 provisional responses or UPDATE requests, a UAC SHOULD NOT use the 715 same target refresh request to refresh the target and to make session 716 changes unless the session changes can be trivially accepted by the 717 UAS (e.g., a change IP address change). Piggybacking a target 718 refresh with more complicated session changes in this situation would 719 make it unnecessarily complicated for the UAS to accept the target 720 refresh while rejecting the session changes. 722 13. UAS Behavior 724 Behavior of a UAS after having received a target-refresh request 725 updating the remote target: 727 If the UAS receives a target-refresh request that has been properly 728 authenticated, the UAS SHOULD generate a reliable provisional 729 response or a 2xx response to the target-refresh request. If 730 generating such responses is not possible (e.g., the UAS does not 731 support reliable provisional responses and needs user input before 732 generating a final response), the UAS SHOULD send a request to the 733 UAC using the new remote target (if the UAS does not need to send a 734 request for other reasons, the UAS can send an UPDATE request). On 735 sending a reliable provisional response or a 2xx response to the 736 target-refresh request, or a request to the new remote target, the 737 UAS MUST replace the dialog's remote target URI with the URI from the 738 Contact header field in the target-refresh request. 740 Reliable provisional responses in SIP are specified in RFC 3262 741 [RFC3262]. In this document, reliable provisional responses are 742 those that use the mechanism defined in RFC 3262 [RFC3262] on any 743 other SIP-based mechanism that may be specified in the future. 744 Other specifications may define ways to send provisional responses 745 reliably using non-SIP mechanisms (e.g., using media-level 746 messages to acknowledge the reception of the SIP response). For 747 the purposes of this document, provisional responses using those 748 non-SIP mechanisms are considered unreliable responses. 750 If before sending a reliable provisional response or a 2xx response 751 to the target-refresh request, or a request to the new target, the 752 UAS generates an error response to the target-refresh request, the 753 UAS MUST NOT update its dialog's remote target. 755 14. Race Conditions and Target Refreshes 757 TODO: this is a corner case but we should describe it anyway. A UA 758 that changes its own contact twice in a row may create a race 759 condition if, for example, the first time it refreshes it using a 2xx 760 response (to an UPDATE or a re-INVITE) and the second with an UPDATE. 761 If the offer/answer glare-avoidance rules do not apply (and they 762 don't if there is no offer/answer exchange), the remote UA could 763 receive first the UPDATE and then the 2xx response for the previous 764 request. 766 15. Background on re-INVITE Transaction Routing 768 Re-INVITEs are routed using the dialog's route set, which contains 769 all the proxy servers that need to be traversed by requests send 770 within the dialog. Responses to the re-INVITE are routed using the 771 Via entries in the re-INVITE. 773 ACK requests for 2xx responses and for non-2xx final responses are 774 generated in different ways. As specified in Sections 14.1 and 775 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are 776 generated by the UAC core and are routed using the dialog's route 777 set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK 778 requests for non-2xx final responses are generated by the INVITE 779 client transaction (i.e., they are generated in a hop-by-hop fashion 780 by the proxy servers in the path) and are sent to the same transport 781 address as the re-INVITE. 783 16. Problems with UAs Losing their Contact 785 Refreshing the dialog's remote target during a re-INVITE transaction 786 (see Section 11) presents some issues because of the fact that Re- 787 INVITE transactions can be long lived. As described in Section 15, 788 the way responses to the re-INVITE and ACKs for non-2xx final 789 responses are routed is fixed once the re-INVITE is sent. The 790 routing of this messages does not depend on the dialog's route set 791 and, thus, target refreshes within an ongoing re-INVITE do not affect 792 their routing. A UA that changes its location (i.e., performs a 793 target refresh) but is still reachable at its old location will be 794 able to receive those messages (which will be sent to the old 795 location). However, a UA that cannot be reachable at its old 796 location any longer will not be able to receive them. 798 17. UAS Losing its Contact: UAC Behavior 800 When a UAS that moves to a new contact and loses its old contact 801 generates a non-2xx final response to the re-INVITE, it will not be 802 able to receive the ACK request. The entity receiving the response 803 and, thus, generating the ACK request will either get a transport 804 error or a timeout error, which, as described in Section 8.1.3.1 of 805 RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) 806 response and as a 408 (Request Timeout) response, respectively. If 807 the sender of the ACK request is a proxy server, it will typically 808 ignore this error. If the sender of the ACK request is the UAC, 809 according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed 810 to (at the "should" level) terminate the dialog by sending a BYE 811 request. However, because of the special properties of ACK requests 812 for non-2xx final responses, most existing UACs do not terminate the 813 dialog when ACK request fails, which is fortunate. 815 A UAC that accepts a target refresh within a re-INVITE MUST ignore 816 transport and timeout errors when generating an ACK request for a 817 non-2xx final response if the UAC is communicating directly with the 818 UAS (i.e., there are no proxy servers in the dialog's route set). 820 18. UAC Losing its Contact: UAS Behavior 822 When a UAC moves to a new contact and loses its old contact, it will 823 not be able to receive responses to the re-INVITE. Consequently, it 824 will never generate an ACK request. 826 As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server 827 that gets an error when forwarding a response does not take any 828 measurements. Consequently, proxy servers relaying responses will 829 effectively ignore the error. 831 If there are no proxy servers in the dialog's route set, the UAS will 832 get an error when sending a non-2xx final response. The UAS core 833 will be notified of the transaction failure, as described in Section 834 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate 835 the dialog on encountering this failure, which is fortunate. 837 A UAS that accepts a target refresh within a re-INVITE MUST ignore 838 transport and timeout errors when generating a non-2xx final response 839 to the re-INVITE if the UAS is communicating directly with the UAC 840 (i.e., there are no proxy servers in the dialog's route set). 842 Regardless of the presence or absence of proxy servers in the 843 dialog's route set, a UAS generating a 2xx response to the re-INVITE 844 will never receive an ACK request for it. According to Section 14.2 845 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" 846 level) terminate the dialog by sending a BYE request. 848 A UAS that accepts a target refresh within a re-INVITE and never 849 receives an ACK request after having sent a 2xx response to the re- 850 INVITE SHOULD NOT terminate the dialog. If the UA has received a new 851 re-INVITE with a higher CSeq sequence number than the original one, 852 the UA SHOULD just ignore the error. If the UA has not received such 853 a re-INVITE, UA SHOULD generate a new re-INVITE in order to make sure 854 that both UAs have a common view of the state of the session. 856 Note that the UA generates a re-INVITE and not an UPDATE request 857 because UPDATE requests can be sent within a re-INVITE. By 858 accepting the incoming re-INVITE, the remote UA indicates that the 859 old re-INVITE transaction has already been terminated. 861 A 500 (Server Internal Error) response to the new re-INVITE would 862 mean that the remote UA was still processing the original re-INVITE. 863 This may be because the remote UA is a legacy UA that does not 864 support this specification. In this situation, the UA SHOULD follow 865 the original recommendation in RFC 3261 [RFC3261] and terminate the 866 dialog. 868 19. UAC Losing its Contact: UAC Behavior 870 When a UAC moves to a new contact and loses its old contact, it will 871 not be able to receive responses to the re-INVITE. Consequently, it 872 will never generate an ACK request. 874 Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE 875 and cause the INVITE client transaction corresponding to the re- 876 INVITE to enter the "Terminated" state. The UAC SHOULD also send a 877 new re-INVITE in order to make sure that both UAs have a common view 878 of the state of the session. 880 Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new 881 incoming re-INVITEs as soon as it has generated a final response 882 to the previous INVITE request, which had a lower CSeq sequence 883 number. 885 20. Security Considerations 887 This document does not introduce any new security issue. It just 888 clarifies how certain transactions should be handled in SIP. 889 Security issues related to re-INVITEs and UPDATE requests are 890 discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. 892 21. IANA Considerations 894 There are no IANA actions associated with this document. 896 22. Acknowledgements 898 Paul Kyzivat provided useful ideas on the topics discussed in this 899 document. 901 23. Normative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 907 A., Peterson, J., Sparks, R., Handley, M., and E. 908 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 909 June 2002. 911 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 912 Provisional Responses in Session Initiation Protocol 913 (SIP)", RFC 3262, June 2002. 915 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 916 with Session Description Protocol (SDP)", RFC 3264, 917 June 2002. 919 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 920 UPDATE Method", RFC 3311, October 2002. 922 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 923 Initiation Protocol (SIP) Preconditions Framework", 924 RFC 4032, March 2005. 926 [I-D.ietf-mmusic-ice] 927 Rosenberg, J., "Interactive Connectivity Establishment 928 (ICE): A Protocol for Network Address Translator (NAT) 929 Traversal for Offer/Answer Protocols", 930 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 932 Authors' Addresses 934 Gonzalo Camarillo (editor) 935 Ericsson 936 Hirsalantie 11 937 Jorvas 02420 938 Finland 940 Email: Gonzalo.Camarillo@ericsson.com 942 Christer Holmberg 943 Ericsson 944 Hirsalantie 11 945 Jorvas 02420 946 Finland 948 Email: Christer.Holmberg@ericsson.com 950 Yang Gao 951 ZTE 952 China 954 Email: gao.yang2@zte.com.cn