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