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