idnits 2.17.1 draft-ietf-sipping-dialogusage-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1214. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 22, 2006) is 6368 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 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-10 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Estacado Systems 4 Expires: April 25, 2007 October 22, 2006 6 Multiple Dialog Usages in the Session Initiation Protocol 7 draft-ietf-sipping-dialogusage-04 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 25, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Several methods in the Session Initiation Protocol can create an 41 association between endpoints known as a dialog. Some of these 42 methods can also create a different, but related, association within 43 an existing dialog. These multiple associations, or dialog usages, 44 require carefully coordinated processing as they have independent 45 life-cycles, but share common dialog state. Processing multiple 46 dialog usages correctly is not completely understood. What is 47 understood is difficult to implement. 49 This memo argues that multiple dialog usages should be avoided. It 50 discusses alternatives to their use and clarifies essential behavior 51 for elements that cannot currently avoid them. 53 This is an informative document and makes no normative statements of 54 any kind. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4 61 3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 7 63 4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 10 64 4.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 10 66 5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 10 67 5.1. A survey of the effect of failure responses on usages 68 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 16 70 5.3. Matching requests to usages . . . . . . . . . . . . . . . 16 71 5.4. Target refresh requests . . . . . . . . . . . . . . . . . 17 72 5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 18 73 5.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 18 74 5.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 18 75 6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 80 11. Informative References . . . . . . . . . . . . . . . . . . . . 25 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 82 A.1. draft-ietf-03->draft-ietf-04 . . . . . . . . . . . . . . . 26 83 A.2. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 26 84 A.3. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 26 85 A.4. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 26 86 A.5. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 27 87 A.6. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 27 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 Intellectual Property and Copyright Statements . . . . . . . . . . 29 91 1. Overview 93 This is an informative document. It makes no normative statements of 94 any kind. This document refines the concept of a dialog usage in the 95 Session Initiation Protocol (SIP [1]), and discusses what led to its 96 existence. It explores ambiguity associated with processing multiple 97 dialog usages that share a dialog. In particular, it surveys the 98 effect of SIP failure responses on transaction, dialog usage, and 99 dialog state. This document will help the implementer understand 100 what is required to process multiple dialog usages correctly, and 101 will inform future standards-track work clarifying RFC3261 and 102 related documents. Finally, the document explores single-usage 103 dialog alternatives (using SIP extensions) to multiple dialog usages. 105 2. Introduction 107 Several methods in SIP can establish a dialog. When they do so, they 108 also establish an association between the endpoints within that 109 dialog. This association has been known for some time as a "dialog 110 usage" in the developer community. A dialog initiated with an INVITE 111 request has an invite usage. A dialog initiated with a SUBSCRIBE 112 request has a subscribe usage. A dialog initiated with a REFER 113 request has a subscribe usage. 115 Dialogs with multiple usages arise when a usage-creating action 116 occurs inside an existing dialog. Such actions include accepting a 117 REFER or SUBSCRIBE issued inside a dialog established with an INVITE 118 request. Multiple REFERs within a dialog create multiple 119 subscriptions, each of which is a new dialog usage sharing common 120 dialog state. (Note that any REFER issued utilizing the 121 subscription-suppression mechanism specified in [8] creates no new 122 usage.) Similarly, an endpoint in a dialog established with an 123 INVITE might subscribe to its peer's KPML [11] and later issue a 124 REFER, resulting in three dialog usages sharing common dialog state. 126 The common state in the dialog shared by any usages is exactly: 127 o the Call-ID 128 o the local Tag 129 o the remote Tag 130 o the local CSeq 131 o the remote CSeq 132 o the Route-set 133 o the local contact 134 o the remote target 135 o the secure flag 137 Usages have state that is not shared in the dialog. For example, a 138 subscription has a duration, along with other usage-specific state. 139 Multiple subscriptions in the same dialog each have their own 140 duration. 142 A dialog comes into existence with the creation of the first usage, 143 and continues to exist until the last usage is terminated (reference 144 counting). Unfortunately, many of the usage management aspects of 145 SIP, such as authentication, were originally designed with the 146 implicit assumption that there was one usage per dialog. The 147 resulting mechanisms have mixed effects, some influencing the usage, 148 and some influencing the entire dialog. 150 The current specifications define two usages, invite and subscribe. 151 A dialog can share up to one invite usage and arbitrarily many 152 subscribe usages. 154 Because RFC3261 [1] states that user-agents should reuse Call-ID and 155 increment CSeq across a series of registration requests (and that to- 156 tags appear in register responses in some of the examples), some 157 implementations have treated REGISTER as if it were in a dialog. 158 However, RFC3261 explicitly calls out that REGISTER does not create a 159 dialog. A series of REGISTER requests does not create any usage or 160 dialog. Similarly, PUBLISH [10] does not create any usage or dialog. 162 3. Examples of Multiple Usages 164 3.1. Transfer 166 In Figure 1, Alice transfers a call she received from Bob to Carol. 167 A dialog (and an invite dialog usage) between Alice and Bob comes 168 into being with the 200 OK labeled F1. A second usage (a 169 subscription to event refer) comes into being with the NOTIFY labeled 170 F2. This second usage ends when the subscription is terminated by 171 the NOTIFY transaction labeled F3. The dialog still has one usage 172 (the invite usage), which lasts until the BYE transaction labeled F4. 173 At this point, the dialog has no remaining usages, so it ceases to 174 exist. Details of each of these messages are shown in Figure 2. 176 Alice Bob Carol 177 | INVITE | | 178 |<----------------| | 179 Dialog 1 Usage 1 | 200 OK (F1) | | 180 -start- -start- ----------->|---------------->| | 181 | | | ACK | | 182 | | |<----------------| | 183 | | | reINVITE/200/ACK| | 184 | | | (hold) | | 185 | | |---------------->| | 186 | | | REFER | | 187 | | Dialog 1 |---------------->| | 188 | | Usage 2 | NOTIFY (F2) | | 189 | | -start- -->|<----------------| INVITE | 190 | | | | 200 NOTIFY |----------->| 191 | | | |---------------->| 200 OK | 192 | | | | 200 REFER |<-----------| 193 | | | |<----------------| ACK | 194 | | | | NOTIFY (F3) |----------->| 195 | | | |<----------------| | 196 | | | | 200 | . | 197 | | -end- -->|---------------->| . | 198 | | | BYE (F4) | Dialog 2 | 199 | | |<----------------| proceeds | 200 | | | 200 | . | 201 -end- -end- ------------>|---------------->| . | 203 Figure 1 204 Message Details (abridged to show only dialog or usage details) 205 F1 206 SIP/2.0 200 OK 207 Call-ID: dialog1@bob.example.com 208 CSeq: 100 INVITE 209 To: ;tag=alicetag1 210 From: ;tag=bobtag1 211 Contact: 213 F2 214 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 215 Event: refer 216 Call-ID: dialog1@bob.example.com 217 CSeq: 101 NOTIFY 218 To: ;tag=alicetag1 219 From: ;tag=bobtag1 220 Contact: 222 F3 223 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 224 Event: refer 225 Subscription-State: terminated;reason=noresource 226 Call-ID: dialog1@bob.example.com 227 CSeq: 102 NOTIFY 228 To: ;tag=alicetag1 229 From: ;tag=bobtag1 230 Contact: 231 Content-Type: message/sipfrag 233 SIP/2.0 200 OK 235 F4 237 BYE sip:aliceinstance@alice.example.com SIP/2.0 238 Call-ID: dialog1@bob.example.com 239 CSeq: 103 BYE 240 To: ;tag=alicetag1 241 From: ;tag=bobtag1 242 Contact: 244 Figure 2 246 3.2. Reciprocal Subscription 248 In Figure 3, Alice subscribes to Bob's presence. For simplicity, 249 assume Bob and Alice are both serving their presence from their 250 endpoints instead of a presence server. To focus on the essential 251 points, the figure leaves out any rendezvous signaling through which 252 Alice discovers Bob's endpoint. 254 Bob is interested in Alice's presence too, so he subscribes to Alice 255 (in most deployed presence/IM systems, people watch each other). He 256 decides to skip the rendezvous step since he's already in a dialog 257 with Alice, and sends his SUBSCRIBE inside that dialog (a few early 258 SIMPLE clients behaved exactly this way). 260 The dialog and its first usage comes into being at F1, which 261 establishes Alice's subscription to Bob. Its second usage begins at 262 F2, which establishes Bob's subscription to Alice. These two 263 subscriptions are independent - they have distinct and different 264 expirations, but they share all the dialog state. 266 The first usage ends when Alice decides to unsubscribe at F3. Bob's 267 subscription to Alice, and thus the dialog, continues to exist. 268 Alice's UA must maintain this dialog state even though the 269 subscription that caused it to exist in the first place is now over. 270 The second usage ends when Alice decides to terminate Bob's 271 subscription at F4 (she's probably going to reject any attempt on 272 Bob's part to resubscribe until she's ready to subscribe to Bob 273 again). Since this was the last usage, the dialog also terminates. 274 Details of these messages are shown in Figure 4. 276 Alice Bob 277 | | 278 | SUBSCRIBE | 279 |------------------->| 280 Dialog Usage 1 | NOTIFY (F1) | 281 -start- -start- --------->|<-------------------| 282 | | | 200 SUBSCRIBE | 283 | | |<-------------------| 284 | | | 200 NOTIFY | 285 | | |------------------->| 286 | | | SUBSCRIBE | 287 | | |<-------------------| 288 | | Usage 2 | NOTIFY (F2) | 289 | | -start- -->|------------------->| 290 | | | | 200 SUBSCRIBE 291 | | | |------------------->| 292 | | | | 200 NOTIFY | 293 | | | |<-------------------| 294 | | | | : | 295 | | | | : | 296 | | | | (un)SUBSCRIBE (F3) | 297 | | | |------------------->| 298 | | | | 200 | 299 | | | |<-------------------| 300 | | | | NOTIFY | 301 | | | |<-------------------| 302 | | | | 200 | 303 | -end- ----------->|------------------->| 304 | | | : | 305 | | | : | 306 | | | NOTIFY (F4) | 307 | | | (Terminated) | 308 | | |------------------->| 309 | | | 200 | 310 -end- -end- -->|<-------------------| 311 | | 313 Figure 3 314 Message Details (abridged to show only dialog or usage details) 315 F1 316 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 317 Event: presence 318 Subscription-State: active;expires=600 319 Call-ID: alicecallid1@alice.example.com 320 From: ;tag=bobtag2 321 To: ;tag=alicetag2 322 CSeq: 100 NOTIFY 323 Contact: 325 F2 326 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 327 Event: presence 328 Subscription-State: active;expires=1200 329 Call-ID: alicecallid1@alice.example.com 330 To: ;tag=bobtag2 331 From: ;tag=alicetag2 332 CSeq: 500 NOTIFY 333 Contact: 335 F3 336 SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0 337 Event: presence 338 Expires: 0 339 Call-ID: alicecallid1@alice.example.com 340 To: ;tag=bobtag2 341 From: ;tag=alicetag2 342 CSeq: 501 SUBSCRIBE 343 Contact: 345 F4 346 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 347 Event: presence 348 Subscription-State: terminated;reason=deactivated 349 Call-ID: alicecallid1@alice.example.com 350 To: ;tag=bobtag2 351 From: ;tag=alicetag2 352 CSeq: 502 NOTIFY 353 Contact: 355 Figure 4 357 4. Usage Creation and Destruction 359 Dialogs come into existence along with their first usage. Dialogs 360 terminate when their last usage is destroyed. The messages that 361 create and destroy usages vary per usage. This section provides a 362 high-level categorization of those messages. The section does not 363 attempt to explore the REGISTER pseudo-dialog. 365 4.1. Invite usages 366 Created by: non-100 provisional responses to INVITE; 200 response to 367 INVITE 368 Destroyed by: 200 responses to BYE; certain failure responses to 369 INVITE, UPDATE, PRACK, or INFO; anything that destroys a dialog 370 and all its usages 372 4.2. Subscribe usages 373 Created by: 200 class responses to SUBSCRIBE; 200 class responses to 374 REFER; NOTIFY requests 375 Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or 376 refresh-SUBSCRIBE request timeout; certain failure responses to 377 NOTIFY or SUBSCRIBE; expiration without refresh if network issues 378 prevent the terminal NOTIFY from arriving; anything that destroys 379 a dialog and all its usages 381 5. Proper Handling of Multiple Usages 383 The examples in Section 3 show straightforward cases where it is 384 fairly obvious when the dialog begins and ends. Unfortunately, there 385 are many scenarios where such clarity is not present. For instance, 386 in Figure 1, what would it mean if the response to the NOTIFY (F2) 387 were a 481? Does that simply terminate the refer subscription, or 388 does it destroy the entire dialog? This section explores the problem 389 areas with multiple usages that have been identified to date. 391 5.1. A survey of the effect of failure responses on usages and dialogs 393 For this survey, consider a subscribe usage inside a dialog 394 established with an invite usage. Unless stated otherwise, we'll 395 discuss the effect on each usage and the dialog when a client issuing 396 a NOTIFY inside the subscribe usage receives a failure response (such 397 as a transferee issuing a NOTIFY to event refer). Further, unless 398 otherwise stated, the conclusions apply to arbitrary multiple-usages. 400 This survey is written from the perspective of a client receiving the 401 error response. The effect on dialogs and usages at the server 402 issuing the response is the same. 404 3xx responses: Redirection mid-dialog is not well understood in SIP, 405 but whatever effect it has impacts the entire dialog and all of 406 its usages equally. In our example scenario, both the 407 subscription and the invite usage would be redirected by this 408 single response. 410 For the failure responses with code 400 and greater, there are three 411 common ways the failure can affect the transaction, usage, and dialog 412 state. 413 Transaction Only The error affects only the transaction, not the 414 usage or dialog the transaction occurs in (beyond affecting the 415 local CSeq). Any other usage of the dialog is unaffected. The 416 error is a complaint about this transaction, not the usage or 417 dialog the transaction occurs in. 418 Destroys Usage The error destroys the usage, but not dialog. Any 419 other usages sharing this dialog are not affected. 420 The error destroys the dialog and all usages sharing it. 422 Table 1 displays how the various codes affect transaction, usage, or 423 dialog state. Response code specific comments (noted with *) or 424 exceptions (noted with **) follow the table. 426 +-----------------------+----------------+------------------+ 427 | Transaction Only | Destroys Usage | Destroys Dialog | 428 +-----------------------+----------------+------------------+ 429 | 400 (or unknown 4xx) | 405*, 480* | 404*, 410*, 416* | 430 | 401, 402*, 403, 406 | 481*, 489** | 482*, 483** | 431 | 407, 408*, 412-415 | 501* | 484*, 485* | 432 | 417, 420, 421, 422* | | 502*, 604* | 433 | 423, 428, 429* | | | 434 | 436-438, 486*, 487 | | | 435 | 488, 491, 493, 494 | | | 436 | 500 (or unknown 5xx)* | | | 437 | 503*, 504*, 505, 513 | | | 438 | 580 | | | 439 | 600 (or unknown 6xx)* | | | 440 | 603*, 606 | | | 441 +-----------------------+----------------+------------------+ 443 Table 1 445 402 Payment Required: This is a reserved response code. If 446 encountered, it should be treated as an unrecognized 4xx. 448 404 Not Found: This response destroys the dialog and all usages 449 sharing it. The Request-URI that is being 404ed is the remote 450 target set by the Contact provided by the peer. Getting this 451 response means something has gone fundamentally wrong with the 452 dialog state. 454 405 Method Not Allowed: In our example scenario, this response 455 destroys the subscription, but not the invite usage or the dialog. 456 It's an aberrant case for NOTIFYs to receive a 405 since they only 457 come as a result to something that creates subscription. In 458 general, a 405 within a given usage affects only that usage, but 459 does not affect other usages of the dialog. 461 408 Request Timeout: Receiving a 408 will have the same effect on 462 usages and dialogs as a real transaction timeout as described in 463 Section 5.2. 465 410 Gone: This response destroys the dialog and all usages sharing 466 it. The Request-URI that is being rejected is the remote target 467 set by the Contact provided by the peer. Similar to 404, getting 468 this response means something has gone fundamentally wrong with 469 the dialog state, its slightly less aberrant in that the other 470 endpoint recognizes that this was once a valid URI that it isn't 471 willing to respond to anymore. 473 416 Unsupported URI Scheme: Similar to 404 and 410, this response 474 came to a request whose Request-URI was provided by the peer in a 475 Contact header field. Something has gone fundamentally wrong, and 476 the dialog and all of its usages are destroyed. 478 422 Session Interval Too Small: This response will not be returned to 479 a NOTIFY in our example scenario. This response does not make 480 sense for any mid-usage request. If it is received, an element in 481 the path of the request is violating protocol, and the recipient 482 should treat this as it would an unknown 4xx response. If the 483 response came to a request that was attempting to establish a new 484 usage in an existing dialog, no new usage is created and existing 485 usages are unaffected. 487 429 Provide Referrer Identity: This response won't be returned to a 488 NOTIFY as in our example scenario, but when it is returned to a 489 REFER, it is objecting only to the REFER request itself. Any 490 usages sharing this dialog with that REFER request are unaffected. 491 The dialog is only affected by a change in its local CSeq. 493 480 Temporarily Unavailable: RFC 3261 is unclear on what this 494 response means for mid-usage requests. Future updates to that 495 specification are expected to clarify that this response affects 496 only the usage in which the request occurs. No other usages are 497 affected. If the response included a Retry-After header field, 498 further requests in that usage should not be sent until the 499 indicated time has past. Requests in other usages may still be 500 sent at any time. 502 481 Call/Transaction Does Not Exist: This response indicates that the 503 peer has lost its copy of the dialog usage state. The dialog 504 itself should not be destroyed unless this was the last usage. 505 The effects of a 481 on a dialog and its usages are the most 506 ambiguous of any final response. There are implementations that 507 have chosen the meaning recommended here, and others that destroy 508 the entire dialog without regard to the number of outstanding 509 usages. Going forward with this clarification will allow those 510 deployed implementations that assumed only the usage was destroyed 511 to work with a wider number of implementations. Those that made 512 the other choice will continue to function as they do now, 513 suffering at most the same extra messages needed for a peer to 514 discover that that other usages have gone away that they currently 515 do. However, the necessary clarification to RFC 3261 needs to 516 make it very clear that the ability to terminate usages 517 independently from the overall dialog using a 481 is not 518 justification for designing new applications that count on 519 multiple usages in a dialog. 521 482 Loop Detected: This response is aberrant mid-dialog. It will 522 only occur if the Record-Route header field was improperly 523 constructed by the proxies involved in setting up the dialog's 524 initial usage, or if a mid-dialog request forks and merges (which 525 should never happen). Future requests using this dialog state 526 will also fail. The dialog and any usages sharing it are 527 destroyed. 529 An edge condition exists during RFC3263 failover at the element 530 sending a request where the request effectively forks to 531 multiple destinations from the client. Some implementations 532 increase risk entering this edge condition by trying the next 533 potential location as determined by RFC3263 very rapidly if the 534 first does not immediately respond. In any situation where a 535 client sends the same request to more than one endpoint, it 536 must be prepared to receive a response from each branch (and 537 should choose a "best" response to act on following the same 538 guidelines as a forking proxy). In this particular race 539 condition, if multiple branches respond, all but one will most 540 likely return a 482 Merged Request. The client should select 541 the remaining non-482 response as the "best" response. 543 483 Too Many Hops: Similar to 482, receiving this mid-dialog is 544 aberrant. Unlike 482, recovery may be possible by increasing Max- 545 Forwards (assuming that the requester did something strange like 546 using a smaller value for Max-Forwards in mid-dialog requests than 547 it used for an initial request). If the request isn't tried with 548 an increased Max-Forwards, then the agent should attempt to 549 gracefully terminate this usage and all other usages that share 550 its dialog. 552 484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these 553 responses came to a request whose Request-URI was provided by the 554 peer in a Contact header field. Something has gone fundamentally 555 wrong, and the dialog and all of its usages are destroyed. 557 486 Busy Here: This response is nonsensical in our example scenario, 558 or in any scenario where this response comes inside an established 559 usage. If it occurs in that context, it should be treated as an 560 unknown 4xx response. The usage, and any other usages sharing its 561 dialog are unaffected. The dialog is only affected by the change 562 in its local CSeq. If this response is to a request that is 563 attempting to establish a new usage within an existing dialog 564 (such as an INVITE sent within a dialog established by a 565 subscription), the request fails, no new usage is created, and no 566 other usages are affected. 568 489 Bad Event: In our example scenario, [3] declares that the 569 subscription usage in which the NOTIFY is sent is terminated. The 570 invite usage is unaffected and the dialog continues to exist. 571 This response is only valid in the context of SUBSCRIBE and 572 NOTIFY. UAC behavior for receiving this response to other methods 573 is not specified, but treating it as an unknown 4xx is a 574 reasonable practice. 576 500 and 5xx unrecognized responses: These responses are complaints 577 against the request (transaction), not the usage. If the response 578 contains a Retry-After header field value, the server thinks the 579 condition is temporary and the request can be retried after the 580 indicated interval. This usage, and any other usages sharing the 581 dialog are unaffected. If the response does not contain a Retry- 582 After header field value, the UA may decide to retry after an 583 interval of its choosing or attempt to gracefully terminate the 584 usage. Whether or not to terminate other usages depends on the 585 application. If the UA receives a 500 (or unrecognized 5xx) in 586 response to an attempt to gracefully terminate this usage, it can 587 treat this usage as terminated. If this is the last usage sharing 588 the dialog, the dialog is also terminated. 590 501 Not Implemented: This would be a degenerate response in our 591 example scenario since the NOTIFY is being sent as part of an 592 established subscribe usage. In this case, the UA knows the 593 condition is unrecoverable and should stop attempting to send 594 NOTIFYs on this usage. (It may or may not destroy the usage. If 595 it remembers the bad behavior, it can reject any refresh 596 subscription). In general, this response may or may not affect 597 the usage (a 501 to an unknown method or an INFO will not end an 598 invite usage). It will never affect other usages sharing this 599 usage's dialog. 601 502 Bad Gateway: This response is aberrant mid-dialog. It will only 602 occur if the Record-Route header field was improperly constructed 603 by the proxies involved in setting up the dialog's initial usage. 604 Future requests using this dialog state will also fail. The 605 dialog and any usages sharing it are destroyed. 607 503 Service Unavailable: As per [2], the logic handling locating SIP 608 servers for transactions may handle 503 requests (effectively 609 sequentially forking at the endpoint based on DNS results). If 610 this process does not yield a better response, a 503 may be 611 returned to the transaction user. Like a 500 response, the error 612 is a complaint about this transaction, not the usage. Because 613 this response occurred in the context of an established usage 614 (hence an existing dialog), the route-set has already been formed 615 and any opportunity to try alternate servers (as recommended in 616 [1]) has been exhausted by the RFC3263 logic. The response should 617 be handled as described for 500 earlier in this memo. 619 504 Server Time-out: It is not obvious under what circumstances this 620 response would be returned to a request in an existing dialog. If 621 it occurs it should have the same affect on the dialog and its 622 usages as described for unknown 5xx responses. 624 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 625 response code says something about the recipient user, not the 626 request that was made. This end user is stating an unwillingness 627 to communicate. If the response contains a Retry-After header 628 field value, the user is indicating willingness to communicate 629 later and the request can be retried after the indicated interval. 630 This usage, and any other usages sharing the dialog are 631 unaffected. If the response does not contain a Retry-After header 632 field value, the UA may decide to retry after an interval of its 633 choosing or attempt to gracefully terminate the usage. Whether or 634 not to terminate other usages depends on the application. If the 635 UA receives a 600 (or unrecognized 6xx) in response to an attempt 636 to gracefully terminate this usage, it can treat this usage as 637 terminated. If this is the last usage sharing the dialog, the 638 dialog is also terminated. 640 603 Decline: This response declines the action indicated by the 641 associated request. It can be used, for example, to decline a 642 hold or transfer attempt. Receiving this response does NOT 643 terminate the usage it occurs in. Other usages sharing the dialog 644 are unaffected. 646 604 Does Not Exist Anywhere: Like 404, this response destroys the 647 dialog and all usages sharing it. The Request-URI in the request 648 is the remote target set by the Contact provided by the peer. 649 Getting this response means something has gone fundamentally wrong 650 with the dialog state. 652 5.2. Transaction timeouts 654 [1] states that a UAC should terminate a dialog (by sending a BYE) if 655 no response is received for a request sent within a dialog. This 656 recommendation should have been limited to the invite usage instead 657 of the whole dialog. [3] states that a timeout for a NOTIFY removes a 658 subscription, but a SUBSCRIBE that fails with anything other than a 659 481 does not. Given these statements, it is unclear whether a 660 refresh SUBSCRIBE issued in a dialog shared with an invite usage 661 destroys either usage or the dialog if it times out. 663 Generally, a transaction timeout should affect only the usage in 664 which the transaction occurred. Other uses sharing the dialog should 665 not be affected. In the worst case of timeout due to total transport 666 failure, it may require multiple failed messages to remove all usages 667 from a dialog (at least one per usage). 669 There are some mid-dialog messages that never belong to any usage. 670 If they timeout, they will have no effect on the dialog or its 671 usages. 673 5.3. Matching requests to usages 675 For many mid-dialog requests, identifying the usage they belong to is 676 obvious. A dialog can have at most one invite usage, so any INVITE, 677 UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The 678 usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER 679 requests belong to can be determined from the Event header field of 680 the request. REGISTER requests within a (pseudo)-dialog belong to 681 the registration usage. (As mentioned before, implementations aren't 682 mixing registration usages with other usages, so this document isn't 683 exploring the consequences of that bad behavior). 685 According to [1], "an OPTIONS request received within a dialog 686 generates a 200 OK response that is identical to one constructed 687 outside a dialog and does not have any impact on that dialog". Thus 688 OPTIONS does not belong to any usage. Only those failures discussed 689 in Section 5.1 and Section 5.2 that destroy entire dialogs will have 690 any effect on the usages sharing the dialog with a failed OPTIONS 691 request. 693 MESSAGE requests are discouraged inside a dialog. Implementations 694 are restricted from creating a usage for the purpose of carrying a 695 sequence of MESSAGE requests (though some implementations use it that 696 way, against the standard recommendation). A failed MESSAGE 697 occurring inside an existing dialog will have similar effects on the 698 dialog and its usages as a failed OPTIONS request. 700 Mid-dialog requests with unknown methods cannot be matched with a 701 usage. Servers will return a failure response (likely a 501). The 702 effect on the dialog and its usages at either the client or the 703 server should be similar to that of a failed OPTIONS request. 705 These guidelines for matching messages to usages (or determining 706 there is no usage) apply equally when acting as a UAS, a UAC, or any 707 third party tracking usage and dialog state by inspecting all 708 messages between two endpoints. 710 5.4. Target refresh requests 712 Target refresh requests update the remote target of a dialog when 713 they are successfully processed. The currently defined target 714 refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified 715 in a bug against RFC3565) and REFER (clarified in a bug against 716 RFC3515 [4]). 718 The remote target is part of the dialog state. When a target refresh 719 request affects it, it affects it for ALL usages sharing that dialog. 720 If a subscription and invite usage are sharing a dialog, sending a 721 refresh SUBSCRIBE with a different contact will cause reINVITEs from 722 the peer to go to that different contact. 724 A UAS will only update the remote target if it sends a 200 class 725 response to a target refresh request. A UAC will only update the 726 remote target if it receives a 200 class response to a target refresh 727 request. Again, any update to a dialog's remote target affects all 728 usages of that dialog. 730 There is known ambiguity around the effects of provisional responses 731 on remote targets that future specification will attempt to clarify. 732 Furthermore, because the remote target is part of the dialog state, 733 not any usage state, there is ambiguity in having target refresh 734 requests in progress simultaneously on multiple usages in the same 735 dialog. Implementation designers should consider these conditions 736 with care. 738 5.5. Refreshing and Terminating Usages 740 Subscription and registration usages expire over time and must be 741 refreshed (with a refresh SUBSCRIBE for example). This expiration is 742 usage state, not dialog state. If several subscriptions share a 743 dialog, refreshing one of them has no effect on the expiration of the 744 others. 746 Normal termination of a usage has no effect on other usages sharing 747 the same dialog. For instance terminating a subscription with a 748 NOTIFY/Subscription-State: terminated will not terminate an invite 749 usage sharing its dialog. Likewise, ending an invite usage with a 750 BYE does not terminate any active Event: refer subscriptions 751 established on that dialog. 753 5.6. Refusing new usages 755 As the survey of the effect of failure responses shows, care must be 756 taken when refusing a new usage inside an existing dialog. Choosing 757 the wrong response code will terminate the dialog and all of its 758 usages. Generally, returning a 603 Decline is the safest way to 759 refuse a new usage. 761 5.7. Replacing usages 763 [6] defines a mechanism through which one usage can replace another. 764 It can be used, for example, to associate the two dialogs a transfer 765 target is involved in during an attended transfer. It is written 766 using the term "dialog", but its intent was to only affect the invite 767 usage of the dialog it targets. Any other usages inside that dialog 768 are unaffected. For some applications, the other usages may no 769 longer make sense, and the application may terminate them as well. 771 However, the interactions between Replaces and multiple dialog usages 772 have not been well explored. More discussion of this topic is 773 needed. Implementers should avoid this scenario completely. 775 6. Avoiding Multiple Usages 777 Processing multiple usages correctly is not completely understood. 779 What is understood is difficult to implement and is very likely to 780 lead to interoperability problems. The best way to avoid the trouble 781 that comes with such complexity is to avoid it altogether. 783 When designing new applications or features that use SIP dialogs, do 784 not require endpoints to construct multiple usages to participate in 785 the application or use the feature. When designing endpoints, 786 address the existing multiple usage scenarios as best as possible. 787 Outside those scenarios, if a peer attempts to create a second usage 788 inside a dialog, refuse it. 790 Unfortunately, there are existing applications, like transfer, that 791 currently entail multiple usages, so the simple solution of "don't do 792 it" will require some transitional work. This section looks at the 793 pressures that led to these existing multiple usages and suggests 794 alternatives. 796 When executing a transfer, the transferor and transferee currently 797 share an invite usage and a subscription usage within the dialog 798 between them. This is a result of sending the REFER request within 799 the dialog established by the invite usage. Implementations were led 800 to this behavior by these primary pressures: 801 1. There was no way to ensure that a REFER on a new dialog would 802 reach the particular endpoint involved in a transfer. Many 803 factors, including details of implementations and changes in 804 proxy routing between an INVITE and a REFER could cause the REFER 805 to be sent to the wrong place. Sending the REFER down the 806 existing dialog ensured it got to the same endpoint with which 807 the dialog was established. 808 2. It was unclear how to associate an existing invite usage with a 809 REFER arriving on a new dialog, where it was completely obvious 810 what the association was when the REFER came on the invite 811 usage's dialog. 812 3. There were concerns with authorizing out-of-dialog REFERs. The 813 authorization policy for REFER in most implementations piggybacks 814 on the authorization policy for INVITE (which is, in most cases, 815 based simply on "I placed or answered this call"). 817 GRUUs [7] have been defined specifically to address problem 1 by 818 providing a URI that will reach one specific user-agent. The Target- 819 Dialog header field [9] was created to address problems 2 and 3. 820 This header field allows a request to indicate the dialog identifiers 821 of some other dialog, providing association with that other dialog 822 that can be used in an authorization decision. 824 The Join [5] and Replaces [6] mechanisms can also be used to address 825 problem 1. When using this technique, a new request is sent outside 826 any dialog with the expectation that it will fork to possibly many 827 endpoints, including the one we're interested in. This request 828 contains a header field listing the dialog identifiers of a dialog in 829 progress. Only the endpoint holding a dialog matching those 830 identifiers will accept the request. The other endpoints the request 831 may have forked to will respond with an error. This mechanism is 832 reasonably robust, failing only when the routing logic for out-of- 833 dialog requests changes such that the new request does not arrive at 834 the endpoint holding the dialog of interest. 836 The reachability aspects of using a GRUU to address problem 1 can be 837 combined with the association-with-other-dialogs aspects of the Join/ 838 Replaces and Target-Dialog mechanisms. A REFER request sent out-of- 839 dialog can be sent towards a GRUU, and identify an existing dialog as 840 part of the context the receiver should use. The Target-Dialog 841 header field can be included in the REFER listing the dialog this 842 REFER is associated with. Figure 5 sketches how this could be used 843 to achieve transfer without reusing a dialog. For simplicity, the 844 diagram and message details do not show the server at example.com 845 that will be involved in routing the GRUU. Refer to [7] for those 846 details. 848 Alice Bob Carol 849 | | | 850 | F1 INVITE (Bob's AOR) | | 851 | Call-ID: (call-id one) | | 852 | Contact: (Alice's-GRUU) | | 853 |------------------------------->| | 854 | F2 200 OK | | 855 | To: <>;tag=totag1 | | 856 | From: <>;tag=fromtag1 | | 857 | Call-ID: (call-id one) | | 858 | Contact: (Bob's-GRUU) | | 859 |<-------------------------------| | 860 | ACK | | 861 |------------------------------->| | 862 | : | | 863 | (Bob places Alice on hold) | | 864 | : | F3 INVITE (Carol's AOR) | 865 | | Call-ID: (call-id two) | 866 | | Contact: (Bob's-GRUU) | 867 | |----------------------------->| 868 | | F4 200 OK | 869 | | To: <>;tag=totag2 | 870 | | From: <>;tag=fromtag2 | 871 | | Call-ID: (call-id two) | 872 | | Contact: (Carol's-GRUU) | 873 | |<-----------------------------| 874 | | ACK | 875 | |----------------------------->| 876 | | : | 877 | | (Bob places Carol on hold) | 878 | F5 REFER (Alice's-GRUU) | : | 879 | Call-ID: (call-id three) | | 880 | Refer-To: (Carol's-GRUU) | | 881 | Target-Dialog: (call-id one,totag1,fromtag1) | 882 | Contact: (Bob's-GRUU) | | 883 |<-------------------------------| | 884 | 202 Accepted | | 885 |------------------------------->| | 886 | NOTIFY (Bob's-GRUU) | | 887 | Call-ID: (call-id three) | | 888 |------------------------------->| | 889 | 200 OK | | 890 |<-------------------------------| | 891 | | | 892 | F6 INVITE (Carol's-GRUU) | 893 | Call-ID: (call-id four) | 894 | Contact: (Alice's-GRUU) | 895 |-------------------------------------------------------------->| 896 | 200 OK | 897 | Contact: (Carol's-GRUU) | 898 |<--------------------------------------------------------------| 899 | ACK | 900 |-------------------------------------------------------------->| 901 | | | 902 | F7 NOTIFY (Bob's-GRUU) | | 903 | Call-ID: (call-id three) | | 904 |------------------------------->| | 905 | 200 OK | | 906 |<-------------------------------| | 907 | BYE (Alice's-GRUU) | | 908 | Call-ID: (call-id one) | | 909 |<-------------------------------| BYE (Carol's-GRUU) | 910 | | Call-ID: (call-id two) | 911 | 200 OK |----------------------------->| 912 |------------------------------->| 200 OK | 913 | |<-----------------------------| 914 | | | 916 Figure 5: Transfer without dialog reuse 918 In message F1, Alice invites Bob indicating support for GRUUs (and 919 offering a GRUU for herself): 921 Message F1 (abridged, detailing pertinent fields) 923 INVITE sip:bob@example.com SIP/2.0 924 Call-ID: 13jfdwer230jsdw@alice.example.com 925 Supported: gruu 926 Contact: 928 Message F2 lets Alice know that Bob understands GRUUs. If Bob did 929 not indicate this support, the original multi-usage approach to 930 transfer would have to be used. 932 Message F2 (abridged, detailing pertinent fields) 934 SIP/2.0 200 OK 935 Supported: gruu 936 To: ;tag=totag1 937 From: ;tag=fromtag1 938 Contact: 940 Bob decides to try to transfer Alice to Carol, so he puts Alice on 941 hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU 942 support similar to what happened in F1 and F2. 944 Message F3 (abridged, detailing pertinent fields) 946 INVITE sip:carol@example.com SIP/2.0 947 Supported: gruu 948 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 949 Contact: 951 Message F4 (abridged, detailing pertinent fields) 953 SIP/2.0 200 OK 954 Supported: gruu 955 To: ;tag=totag2 956 From: ;tag=fromtag2 957 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 958 Contact: 960 After consulting Carol, Bob places her on hold and refers Alice to 961 her using message F5. Notice that the Refer-To URI is Carol's GRUU, 962 and that this is on a different Call-ID than message F1. (The URI in 963 the Refer-To header is line-broken for readability in this draft, it 964 would not be valid to break the URI this way in a real message) 965 Message F5 (abridged, detailing pertinent fields) 967 REFER sip:aanewmr203raswdf@example.com SIP/2.0 968 Call-ID: 39fa99r0329493asdsf3n@bob.example.com 969 Refer-To: 972 Target-Dialog: 13jfdwer230jsdw@alice.example.com; 973 local-tag=fromtag1;remote-tag=totag1 974 Supported: gruu 975 Contact: 977 Alice uses the information in the Target-Dialog header field to 978 determine that this REFER is associated with the dialog she already 979 has in place with Bob. Alice is now in a position to use the same 980 admission policy she used for in-dialog REFERs: "Do I have a call 981 with this person?". She accepts the REFER. sends Bob the obligatory 982 immediate NOTIFY, and proceeds to INVITE Carol with message F6. 984 Message F6 (abridged, detailing pertinent fields) 986 sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits) 987 \ / 988 \ / 989 | | 990 v v 991 INVITE SIP/2.0 992 Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com 993 Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; 994 to-tag=totag2;from-tag=fromtag2 995 Supported: gruu 996 Contact: 998 Carol accepts Alice's invitation to replace her dialog (invite usage) 999 with Bob and notifies him that the REFERenced INVITE succeeded with 1000 F7: 1002 Message F7 (abridged, detailing pertinent fields) 1004 NOTIFY sip:boaiidfjjereis@example.com SIP/2.0 1005 Subscription-State: terminated;reason=noresource 1006 Call-ID: 39fa99r0329493asdsf3n@bob.example.com 1007 Contact: 1008 Content-Type: message/sipfrag 1010 SIP/2.0 200 OK 1012 Bob then ends his invite usages with both Alice and Carol using BYEs. 1014 7. Security Considerations 1016 Handling multiple usages within a single dialog is complex and 1017 introduces scenarios where the right thing to do is not clear. The 1018 ambiguities described here can result in unexpected disruption of 1019 communication if response codes are chosen carelessly. Furthermore, 1020 these ambiguities could be exploited, particularly by third-parties 1021 injecting unauthenticated requests or inappropriate responses. 1022 Implementations choosing to create or accept multiple usages within a 1023 dialog should give extra attention to the security considerations in 1024 [1], especially those concerning authenticity of requests and 1025 processing of responses. 1027 Service implementations should carefully consider the effects on 1028 their service of peers making different choices in these areas of 1029 ambiguity. A service that requires multiple usages needs to pay 1030 particular attention to the effect on service and network utilization 1031 when a client fails to destroy a dialog the service believes should 1032 be destroyed. A service that disallows multiple usages should 1033 consider the effect on clients that, for instance, destroy the entire 1034 dialog when only a usage should be torn down. In the worst case of a 1035 service deployed into a network with a large number of misbehaving 1036 clients trying to create multiple usages in an automated fashion, a 1037 retry storm similar to an avalanche restart could be induced. 1039 8. IANA Considerations 1041 This document has no actions for IANA. 1043 9. Conclusion 1045 Handling multiple usages within a single dialog is complex and 1046 introduces scenarios where the right thing to do is not clear. 1047 Implementations should avoid entering into multiple usages whenever 1048 possible. New applications should be designed to never introduce 1049 multiple usages. 1051 There are some accepted SIP practices, including transfer, that 1052 currently require multiple usages. Recent work, most notably GRUU, 1053 makes those practices unnecessary. The standardization of those 1054 practices and the implementations should be revised as soon as 1055 possible to use only single-usage dialogs. 1057 10. Acknowledgments 1059 The ideas in this draft have been refined over several IETF meetings 1060 with many participants. Significant contribution was provided by 1061 Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan 1062 Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate 1063 project also shared their difficulties and discoveries while 1064 implementing multiple-usage dialog handlers. 1066 11. Informative References 1068 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1069 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1070 Session Initiation Protocol", RFC 3261, June 2002. 1072 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1073 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1075 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1076 Notification", RFC 3265, June 2002. 1078 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1079 Method", RFC 3515, April 2003. 1081 [5] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1082 "Join" Header", RFC 3911, October 2004. 1084 [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1085 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1087 [7] Rosenberg, J., "Obtaining and Using Globally Routable User 1088 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1089 (SIP)", draft-ietf-sip-gruu-10 (work in progress), August 2006. 1091 [8] Levin, O., "Suppression of Session Initiation Protocol (SIP) 1092 REFER Method Implicit Subscription", RFC 4488, May 2006. 1094 [9] Rosenberg, J., "Request Authorization through Dialog 1095 Identification in the Session Initiation Protocol (SIP)", 1096 RFC 4538, June 2006. 1098 [10] Niemi, A., "Session Initiation Protocol (SIP) Extension for 1099 Event State Publication", RFC 3903, October 2004. 1101 [11] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP) 1102 Event Package for Key Press Stimulus (KPML)", 1103 draft-ietf-sipping-kpml-08 (work in progress), July 2006. 1105 Appendix A. Change Log 1107 RFC-EDITOR: Please remove this entire Change Log section while 1108 formatting this document for publication. 1110 A.1. draft-ietf-03->draft-ietf-04 1112 o Many minor editorial fixes addressing WGLC comments 1113 o Aligned with changes to GRUU 1114 o Added a short overview 1115 o Added a table summarizing the survey of responses and removed the 1116 description from those responses that were not exceptional. 1118 A.2. draft-ietf-02->draft-ietf-03 1120 o Removed discussion of the retargetting affect of provisional 1121 responses - that is a general problem that will now be addressed 1122 in SIP. 1123 o Added a Security Considerations section (blush) summarizing points 1124 from the document and the list discussion. 1125 o Added a no-op IANA Considerations section. 1127 A.3. draft-ietf-01->draft-ietf-02 1129 o Incorporated editorial-fix contributions from the list 1130 o Noted that REFERs using norefersub (RFC4488) don't create a new 1131 subscribe usage 1132 o Changed the affect of 403 to affect only the transaction, not the 1133 usage. This is motivated by text in 3261 (bottom of page 87 - 1134 pointed out by Brian Stucker) which states that a UA receiving a 1135 non-2xx final response to a re-INVITE must leave the session 1136 parameters unchanged as if the re-INVITE had not been issued. 1137 There are other recommendations in this document that violate that 1138 normative must (404,410, etc) but on review, I believe they are 1139 correct (except for 403) and that this text in 3261 needs to be 1140 updated to recognize the conditions under which they're sent. 1141 o Added text concerning the race condition wherein endpoints failing 1142 over rapidly to 3263 destinations may stimulate a merged-request 1143 response. 1144 o Corrected the 481 inconsistency Paul Kyzivat pointed out (by 1145 removing the inconsistent paragraph) 1147 A.4. draft-ietf-00->draft-ietf-01 1149 o Changed 481 to only affect the usage the response occurred in, 1150 closing the last open issue. Added some text justifying this 1151 recommendation. 1153 o Added 422 Session Interval Too Small 1154 o Added 417 Unknown Resource-Priority 1155 o Added 428 Use Identity Header 1156 o Added 436 Bad Identity-Info 1157 o Added 437 Unsupported Certificate 1158 o Added 438 Invalid Identity header 1159 o Added a section categorizing messages that create and destroy 1160 usages 1161 o Made sure all descriptions in Section 5 addressed the generic 1162 multi-usage case. 1163 o Clarified that the mechanics described in matching messages to 1164 usages applied equally to UACs and UASs. 1165 o More explicitly noted that REFER creates a subscribe-usage 1167 A.5. draft-sparks-01->draft-ietf-00 1168 o Draft rename 1170 A.6. draft-sparks-00->01 1171 o Changed 480 to affect only the usage the response occurred in. 1172 o Closed the open issue on 482. Usages and dialogs are destroyed 1173 even though there is an edge condition in which the response is 1174 only stimulated by certain methods (due to method specific routing 1175 rules). 1176 o Closed the open issue on 483. Usages are not terminated since the 1177 request might succeed if retried with a greater initial Max- 1178 Forwards 1179 o Closed the open issue on 502, accepting -00s suggestion that the 1180 same reasoning used for 482 applies. 1181 o Redid the transfer example to not require a GRUU per usage, but 1182 instead leverage the target-dialog concepts common to Join and 1183 Replaces. 1185 Author's Address 1187 Robert J. Sparks 1188 Estacado Systems 1190 Email: RjS@estacado.net 1192 Intellectual Property Statement 1194 The IETF takes no position regarding the validity or scope of any 1195 Intellectual Property Rights or other rights that might be claimed to 1196 pertain to the implementation or use of the technology described in 1197 this document or the extent to which any license under such rights 1198 might or might not be available; nor does it represent that it has 1199 made any independent effort to identify any such rights. Information 1200 on the procedures with respect to rights in RFC documents can be 1201 found in BCP 78 and BCP 79. 1203 Copies of IPR disclosures made to the IETF Secretariat and any 1204 assurances of licenses to be made available, or the result of an 1205 attempt made to obtain a general license or permission for the use of 1206 such proprietary rights by implementers or users of this 1207 specification can be obtained from the IETF on-line IPR repository at 1208 http://www.ietf.org/ipr. 1210 The IETF invites any interested party to bring to its attention any 1211 copyrights, patents or patent applications, or other proprietary 1212 rights that may cover technology that may be required to implement 1213 this standard. Please address the information to the IETF at 1214 ietf-ipr@ietf.org. 1216 Disclaimer of Validity 1218 This document and the information contained herein are provided on an 1219 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1220 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1221 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1222 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1223 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1224 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1226 Copyright Statement 1228 Copyright (C) The Internet Society (2006). This document is subject 1229 to the rights, licenses and restrictions contained in BCP 78, and 1230 except as set forth therein, the authors retain all their rights. 1232 Acknowledgment 1234 Funding for the RFC Editor function is currently provided by the 1235 Internet Society.