idnits 2.17.1 draft-sparks-sipping-dialogusage-00.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1012. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1028), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (July 2, 2004) is 7232 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) == Unused Reference: '4' is defined on line 960, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-01 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Sparks 2 Internet-Draft dynamicsoft 3 Expires: December 31, 2004 July 2, 2004 5 Multiple Dialog Usages in the Session Initiation Protocol 6 draft-sparks-sipping-dialogusage-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 31, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 Several methods in the Session Initiation Protocol can create an 40 association between endpoints known as a dialog. Some of these 41 methods can also create a new association within an existing dialog. 42 These multiple associations, or dialog usages, require carefully 43 coordinated processing as they have independent life-cycles, but 44 share common dialog state. 46 This memo argues that multiple dialog usages should be avoided. It 47 discusses alternatives to their use and clarifies essential behavior 48 for elements that cannot currently avoid them. 50 This is an informative document and makes no normative statements of 51 any kind. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 3 57 2.1 Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2 Reciprocal Subscription . . . . . . . . . . . . . . . . . 5 59 3. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 7 60 3.1 A survey of the effect of failure responses on usages 61 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2 Transaction timeouts . . . . . . . . . . . . . . . . . . . 14 63 3.3 Matching requests to usages . . . . . . . . . . . . . . . 14 64 3.4 Target refresh requests . . . . . . . . . . . . . . . . . 15 65 3.5 Refreshing and Terminating Usages . . . . . . . . . . . . 15 66 3.6 Refusing new usages . . . . . . . . . . . . . . . . . . . 16 67 3.7 Replacing usages . . . . . . . . . . . . . . . . . . . . . 16 68 4. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 16 69 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 71 6. Informative References . . . . . . . . . . . . . . . . . . . . 21 72 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 73 Intellectual Property and Copyright Statements . . . . . . . . 23 75 1. Introduction 77 Several methods in SIP can establish a dialog. When they do so, they 78 also establish an association between the endpoints within that 79 dialog. This assocation has been known for some time as a "dialog 80 usage" in the developer community. A dialog initiated with an INVITE 81 request has an invite usage. A dialog initiated with a SUBSCRIBE 82 request has a subscribe usage. 84 Dialogs with multiple usages arise from actions like a REFER or 85 SUBSCRIBE issued inside a dialog established with an INVITE request. 86 Multiple REFERs within a dialog create multiple subscriptions, each 87 of which is a new dialog usage sharing common dialog state. This 88 state includes: 89 o the Call-ID 90 o the local Tag 91 o the remote Tag 92 o the local CSeq 93 o the remote CSeq 94 o the Route-set 95 o the local contact 96 o the remote target 98 A dialog comes into existence with the creation of the first usage, 99 and continues to exist until the last usage is terminated (reference 100 counting). Unfortunately, many of the usage management aspects of 101 SIP, such as authentication, were originally designed with the 102 implicit assumption that there was one usage per dialog. The 103 resulting mechanisms have mixed effects, some influencing the usage, 104 and some influencing the entire dialog. 106 The current specifications define two usages, invite and subscribe. 107 A dialog can share up to one invite usage and arbitrarily many 108 subscribe usages. The pseudo-dialog behavior of REGISTER could be 109 considered a third usage. Fortunately, no existing implementations 110 have attempted to mix a registration usage with any other usage. 112 2. Examples of Multiple Usages 114 2.1 Transfer 116 In Figure 1, Alice transfers a call she received from Bob to Carol. 117 A dialog (and an invite dialog usage) between Alice and Bob came into 118 being with the 200 OK labeled F1. A second usage (a subscription to 119 event refer) springs into being with the NOTIFY labeled F2. This 120 second usage ends when the subscription is terminated by the NOTIFY 121 transaction labeled F3. The dialog still has one usage (the invite 122 usage), which lasts until the BYE transaction labeled F4. At this 123 point, the dialog has no remaining usages, so it ceases to exist. 125 Alice Bob Carol 126 | INVITE | | 127 |<----------------| | 128 Dialog 1 Usage 1 | 200 OK (F1) | | 129 -start- -start- ----------->|---------------->| | 130 | | | ACK | | 131 | | |<----------------| | 132 | | | reINVITE/200/ACK| | 133 | | | (hold) | | 134 | | |---------------->| | 135 | | | REFER | | 136 | | Dialog 1 |---------------->| | 137 | | Usage 2 | NOTIFY (F2) | | 138 | | -start- -->|<----------------| INVITE | 139 | | | | 200 NOTIFY |----------->| 140 | | | |---------------->| 200 OK | 141 | | | | 200 REFER |<-----------| 142 | | | |<----------------| ACK | 143 | | | | NOTIFY (F3) |----------->| 144 | | | |<----------------| | 145 | | | | 200 | . | 146 | | -end- -->|---------------->| . | 147 | | | BYE (F4) | Dialog 2 | 148 | | |<----------------| proceeds | 149 | | | 200 | . | 150 -end- -end- ------------>|---------------->| . | 152 Message Details (abridged to show only dialog or usage details) 153 F1 154 SIP/2.0 200 OK 155 Call-ID: dialog1@bob.example.com 156 CSeq: 100 INVITE 157 To: ;tag=alicetag1 158 From: ;tag=bobtag1 159 Contact: 161 F2 162 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 163 Event: refer 164 Call-ID: dialog1@bob.example.com 165 CSeq: 101 NOTIFY 166 To: ;tag=alicetag1 167 From: ;tag=bobtag1 168 Contact: 170 F3 171 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 172 Event: refer 173 Subscription-State: terminated;reason=noresource 174 Call-ID: dialog1@bob.example.com 175 CSeq: 102 NOTIFY 176 To: ;tag=alicetag1 177 From: ;tag=bobtag1 178 Contact: 179 Content-Type: message/sipfrag 181 SIP/2.0 200 OK 183 F4 185 BYE sip:aliceinstance@alice.example.com SIP/2.0 186 Call-ID: dialog1@bob.example.com 187 CSeq: 103 BYE 188 To: ;tag=alicetag1 189 From: ;tag=bobtag1 190 Contact: 192 Figure 1 194 2.2 Reciprocal Subscription 196 In Figure 2, Alice subscribes to Bob's presence. For simplicity, 197 assume Bob and Alice are both serving their presence from their 198 endpoints instead of a presence server. For space, the figure leaves 199 out any rendezvous signaling through which Alice discovers Bob's 200 endpoint. 202 Bob is interested in Alice's presence too, so he subscribes to Alice 203 (in most deployed presence/IM systems, people watch each other). He 204 decides skip the rendezvous step since he's already in a dialog with 205 Alice, and sends his SUBSCRIBE inside that dialog (a few early SIMPLE 206 clients behaved exactly this way). 208 The dialog and its first usage comes into being at F1, which 209 establishes Alice's subscription to Bob. Its second usage begins at 210 F2, which establishes Bob's subscription to Alice. These two 211 subscriptions are independent - they have distinct and different 212 expirations, but they share all the dialog state. 214 The first usage ends when Alice decides to unsubscribe at F3. Bob's 215 subscription to Alice, and thus the dialog, continues to exist. 216 Alice's UA must maintain this dialog state even though the 217 subscription that caused it to exist in the first place is now over. 218 The second usage ends when Alice decides to terminate Bob's 219 subscription at F4 (she's probably going to reject any attempt on 220 Bob's part to resubscribe until she's ready to subscribe to Bob 221 again). Since this was the last usage, the dialog also terminates. 223 Alice Bob 224 | | 225 | SUBSCRIBE | 226 |------------------->| 227 Dialog Usage 1 | NOTIFY (F1) | 228 -start- -start- --------->|<-------------------| 229 | | | 200 SUBSCRIBE | 230 | | |<-------------------| 231 | | | 200 NOTIFY | 232 | | |------------------->| 233 | | | SUBSCRIBE | 234 | | |<-------------------| 235 | | Usage 2 | NOTIFY (F2) | 236 | | -start- -->|------------------->| 237 | | | | 200 SUBSCRIBE 238 | | | |------------------->| 239 | | | | 200 NOTIFY | 240 | | | |<-------------------| 241 | | | | : | 242 | | | | : | 243 | | | | (un)SUBSCRIBE (F3) | 244 | | | |------------------->| 245 | | | | 200 | 246 | -end- ---------->|<-------------------| 247 | | | NOTIFY | 248 | | |<-------------------| 249 | | | 200 | 250 | | |------------------->| 251 | | | : | 252 | | | : | 253 | | | NOTIFY (F4) | 254 | | | (Terminated) | 255 | | |------------------->| 256 | | | 200 | 257 -end- -end- -->|<-------------------| 258 | | 260 Message Details (abridged to show only dialog or usage details) 261 F1 262 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 263 Event: presence 264 Subscription-State: active;expires=600 265 Call-ID: alicecallid1@alice.example.com 266 From: ;tag=bobtag2 267 To: ;tag=alicetag2 268 CSeq: 100 NOTIFY 269 Contact: 271 F2 272 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 273 Event: presence 274 Subscription-State: active;expires=1200 275 Call-ID: alicecallid1@alice.example.com 276 To: ;tag=bobtag2 277 From: ;tag=alicetag2 278 CSeq: 500 NOTIFY 279 Contact: 281 F3 282 SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0 283 Event: presence 284 Expires: 0 285 Call-ID: alicecallid1@alice.example.com 286 To: ;tag=bobtag2 287 From: ;tag=alicetag2 288 CSeq: 501 SUBSCRIBE 289 Contact: 291 F4 292 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 293 Event: presence 294 Subscription-State: terminated;reason=deactivated 295 Call-ID: alicecallid1@alice.example.com 296 To: ;tag=bobtag2 297 From: ;tag=alicetag2 298 CSeq: 502 NOTIFY 299 Contact: 301 Figure 2 303 3. Proper Handling of Multiple Usages 305 The examples in Section 2 show straightforward cases where it is 306 fairly obvious when the dialog begins and ends. Unfortunately, there 307 are many scenarios where such clarity is not present. For instance, 308 in Figure 1, what would it mean if the response to the NOTIFY (F2) 309 were a 481? Does that simply terminate the refer subscription, or 310 does it destroy the entire dialog? This section explores the problem 311 spots with multiple usages that have been identified to date. 313 3.1 A survey of the effect of failure responses on usages and dialogs 315 For this survey, consider a subscribe usage inside a dialog 316 established with an invite usage. Unless stated otherwise, we'll 317 discuss the effect on each usage and the dialog when a client issuing 318 a NOTIFY inside the subscribe usage receives a failure response (such 319 as a transferee issuing a NOTIFY to event refer). 321 This survey is written from the perspective of a client receiving the 322 error response. The effect on dialogs and usages at the server 323 issuing the response is the same. 325 3xx responses: Redirection mid-dialog is not well understood in SIP, 326 but whatever effect it has impacts the entire dialog and all of 327 its usages equally. In our example scenario, both the 328 subscription and the invite usage would be redirected by this 329 single response. 331 400 and unrecognized 4xx responses: These responses affect only the 332 NOTIFY transaction, not the subscription, the dialog it resides in 333 (beyond affecting the local CSeq), or any other usage of that 334 dialog. In general, the response is a complaint about this 335 transaction, not the usage or dialog the transaction occurs in. 337 401 Unauthorized ,407 Proxy Authentication Required: This request, 338 not the subscription or dialog, is being challenged. The usages 339 and dialog are not terminated. 341 402 Payment Required: This is a reserved response code. If 342 encountered, it should be treated as an unrecognized 4xx. 344 403 Forbidden: This response terminates the subscription, but has no 345 effect on any other usages of the dialog. In our example 346 scenario, the invite usage continues to exist. Similarly, if the 347 403 came in response to a reINVITE, the invite usage would be 348 terminated, but not the subscription. 350 404 Not Found: This response destroys the dialog and all usages 351 sharing it. The Request-URI that is being 404ed is the remote 352 target set by the Contact provided by the peer. Getting this 353 response means something has gone fundamentally wrong with the 354 dialog state. 356 405 Method Not Allowed: In our example scenario, this response 357 destroys the subscription, but not the invite usage or the dialog. 358 It's an aberrant case for NOTIFYs to receive a 405 since they only 359 come as a result to something that creates subscription. In 360 general, a 405 within a given usage affects only that usage, but 361 does not affect other usages of the dialog. 363 406 Not Acceptable: These responses concern details of the message in 364 the transaction. Subsequent requests in this same usage may 365 succeed. Neither the usage nor dialog is terminated, other usages 366 sharing this dialog are unaffected. 368 408 Request Timeout: OPEN ISSUE. 3261 explicitly says this 369 terminates dialogs. Does it really mean it terminates the invite 370 usage? Should it truly tear down all usages on a dialog where it 371 occurs? More on this in Section 3.2. 373 410 Gone: This response destroys the dialog and all usages sharing 374 it. The Request-URI that is being rejected is the remote target 375 set by the Contact provided by the peer. Similar to 404, getting 376 this response means something has gone fundamentally wrong with 377 the dialog state, its slightly less aberrant in that the other 378 endpoint recognizes that this was once a valid URI that it isn't 379 willing to respond to anymore. 381 412 Conditional Request Failed: 382 413 Request Entity Too Large: 383 414 Request-URI Too Long: 384 415 Unsupported Media Type: These responses concern details of the 385 message in the transaction. Subsequent requests in this same 386 usage may succeed. Neither the usage nor dialog is terminated, 387 other usages sharing this dialog are unaffected. 389 416 Unsupported URI Scheme: Similar to 404 and 410, this response 390 came to a request whose Request-URI was provided by the peer in a 391 Contact header field. Something has gone fundamentally wrong, and 392 the dialog and all of its usages are destroyed. 394 420 Bad Extension, 421 Extension Required: These responses are 395 objecting to the request, not the usage. The usage is not 396 affected. The dialog is only affected by a change in its local 397 CSeq. No other usages of the dialog are affected. 399 423 Interval Too Brief: This response won't happen in our example 400 scenario, but if it came in response to a reSUBSCRIBE, the 401 subscribe usage is not destroyed (or otherwise affected). No 402 other usages of the dialog are affected. 404 429 Provide Referrer Identity: This response won't be returned to a 405 NOTIFY as in our example scenario, but when it is returned to a 406 REFER, it is objecting to the REFER request itself, not any usage 407 the REFER occurs within. The usage is unaffected. Any other 408 usages sharing this dialog are unaffected. The dialog is only 409 affected by a change in its local CSeq. 411 480 Temporarily Unavailable: OPEN ISSUE: Similar to 404,410 this 412 response is to a R-URI that was provided by the peer in a Contact. 413 Is it reasonable for a request to such a URI to return a 480? For 414 instance, if someone places a call on hold and activates 415 Do-not-disturb, would 480 be a reasonable response to decline 416 reINVITEs? We need more clarity around what a mid-usage 480 means. 417 I propose we declare it an error and that this section has an 418 answer like 404s. 420 481 Call/Transaction Does Not Exist: This response indicates that the 421 peer has lost its copy of the dialog state. The dialog and any 422 usages sharing it are destroyed. 424 482 Loop Detected: This response is aberrant mid-dialog. It will 425 only occur if the Record-Route header field was improperly 426 constructed by the proxies involved in setting up the dialog's 427 initial usage, or if a mid-dialog request forks and merges (which 428 should never happen). Future requests using this dialog state 429 will also fail. The dialog and any usages sharing it are 430 destroyed. OPEN ISSUE: This response may have been triggered by 431 method (and perhaps usage) specific handling. Is destroying the 432 entire dialog too severe? 434 483 Too Many Hops: Similar to 482, receiving this mid-dialog is 435 aberrant. Unlike 482, recovery may be possible by increasing 436 Max-Forwards (assuming that the requester did something strange 437 like using a smaller value for Max-Forwards in mid-dialog requests 438 than it used for an initial request). If the request isn't tried 439 with an increased Max-Forwards, then the agent should attempt to 440 gracefully terminate this usage and all other usages that share 441 its dialog. OPEN ISSUE: Is this the right behavior, or should we 442 just declare the dialog terminated? 444 484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these 445 responses came to a request whose Request-URI was provided by the 446 peer in a Contact header field. Something has gone fundamentally 447 wrong, and the dialog and all of its usages are destroyed. 449 486 Busy Here: This response is non-sensical in our example scenario, 450 or in any scenario where this response comes inside an established 451 usage. If it occurs in that context, it should be treated as an 452 unknown 4xx response. The usage, and any other usages sharing its 453 dialog are unaffected. The dialog is only affected by the change 454 in its local CSeq. If this response is to a request that is 455 attempting to establish a new usage within an existing dialog 456 (such as an INVITE sent within a dialog established by a 457 subscription), the request fails, no new usage is created, and no 458 other usages are affected. 460 487 Request Terminated: This response speaks to the disposition of a 461 particular request (transaction). The usage in which that request 462 occurs is not affected by this response (it may be affected by 463 another associated request within that usage). No other usages 464 sharing this dialog are affected. 466 488 Not Acceptable Here: This response is objecting to the request, 467 not the usage. The usage is not affected. The dialog is only 468 affected by a change in its local CSeq. No other usages of the 469 dialog are affected. 471 489 Bad Event: In our example scenario, [3] declares that the 472 subscription usage in which the NOTIFY is sent is terminated. The 473 invite usage is unaffected and the dialog continues to exist. 474 This response is only valid in the context of SUBSCRIBE and 475 NOTIFY. UAC behavior for receiving this response to other methods 476 is not specified, but treating it as an unknown 4xx is a 477 reasonable practice. 479 491 Request Pending: This response addresses in-dialog request glare. 480 Its affect is scoped to the request. The usage in which the 481 request occurs is not affected. The dialog is only affected by 482 the change in its local CSeq. No other usages sharing this dialog 483 are affected. 485 493 Undecipherable: This response objects to the request, not the 486 usage. The usage is not affected. The dialog is only affected by 487 a change in its local CSeq. No other usages of the dialog are 488 affected. 490 494 Security Agreement Required: This response is objecting to the 491 request, not the usage. The usage is not affected. The dialog is 492 only affected by a change in its local CSeq. No other usages of 493 the dialog are affected. 495 500 and 5xx unrecognized responses: These responses are complaints 496 against the request (transaction), not the usage. If the response 497 contains a Retry-After header field value, the server thinks the 498 condition is temporary and the request can be retried after the 499 indicated interval. This usage, and any other usages sharing the 500 dialog are unaffected. If the response does not contain a 501 Retry-After header field value, the UA may decide to retry after 502 an interval of its choosing or attempt to gracefully terminate the 503 usage. Whether or not to terminate other usages depends on the 504 application. If the UA receives a 500 (or unrecognized 5xx) in 505 response to an attempt to gracefully terminate this usage, it can 506 treat this usage as terminated. If this is the last usage sharing 507 the dialog, the dialog is also terminated. 509 501 Not Implemented: This would be a degenerate response in our 510 example scenario since the NOTIFY is being sent as part of an 511 established subscribe usage. In this case, the UA knows the 512 condition is unrecoverable and should stop attempting to send 513 NOTIFYs on this usage. (It may or may not destroy the usage. If 514 it remembers the bad behavior, it can reject any refresh 515 subscription). In general, this response may or may not affect 516 the usage (a 501 to an unknown method or an INFO will not end an 517 invite usage). It will never affect other usages sharing this 518 usage's dialog. 520 502 Bad Gateway: OPEN ISSUE: I think this is similar to "Loop 521 Detected". 523 503 Service Unavailable: As per [2], the logic handling locating SIP 524 servers for transactions may handle 503 requests (effectively 525 sequentially forking at the endpoint based on DNS results). If 526 this process does not yield a better response, a 503 may be 527 returned to the transaction user. Like a 500 response, the error 528 is a complaint about this transaction, not the usage. Because 529 this response occurred in the context of an established usage 530 (hence an existing dialog), the route-set has already been formed 531 and any opportunity to try alternate servers (as recommended in 532 [1] has been exhausted by the RFC3263 logic. The response should 533 be handled as described for 500 earlier in this memo. 535 504 Server Time-out: It is not obvious under what circumstances this 536 response would be returned to a request in an existing dialog. If 537 it occurs it should have the same affect on the dialog and its 538 usages as described for unknown 5xx responses. 540 505 Version Not Supported, 513 Message Too Large: These responses are 541 objecting to the request, not the usage. The usage is not 542 affected. The dialog is only affected by a change in its local 543 CSeq. No other usages of the dialog are affected. 545 580 Precondition Failure: This response is objecting to the request, 546 not the usage. The usage is not affected. The dialog is only 547 affected by a change in its local CSeq. No other usages of the 548 dialog are affected. 550 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 551 response code says something about the recipient user, not the 552 request that was made. This end user is stating an unwillingness 553 to communicate. OPEN ISSUE: It is not clear what this means in 554 response to a mid-dialog request. I propose this behavior if you 555 receive a 600 or unknown 6xx: If the response contains a 556 Retry-After header field value, the user is indicating willingness 557 to communicate later and the request can be retried after the 558 indicated interval. This usage, and any other usages sharing the 559 dialog are unaffected. If the response does not contain a 560 Retry-After header field value, the UA may decide to retry after 561 an interval of its choosing or attempt to gracefully terminate the 562 usage. Whether or not to terminate other usages depends on the 563 application. If the UA receives a 600 (or unrecognized 6xx) in 564 response to an attempt to gracefully terminate this usage, it can 565 treat this usage as terminated. If this is the last usage sharing 566 the dialog, the dialog is also terminated. 568 603 Decline: This response declines the action indicated by the 569 associated request. It can be used, for example, to decline a 570 hold or transfer attempt. Receiving this response does NOT 571 terminate the usage it occurs in. Other usages sharing the dialog 572 are unaffected. 574 604 Does Not Exist Anywhere: Like 404, this response destroys the 575 dialog and all usages sharing it. The Request-URI that is being 576 604ed is the remote target set by the Contact provided by the 577 peer. Getting this response means something has gone 578 fundamentally wrong with the dialog state. 580 606 Not Acceptable: This response is objecting to aspects of the 581 associated request, not the usage the request appears in. The 582 usage is unaffected. Any other usages sharing the dialog are 583 unaffected. The only affect on the dialog is the change in the 584 local CSeq. 586 3.2 Transaction timeouts 588 [1] states that a UAC should terminate a dialog (by sending a BYE) if 589 no response is received for a request sent within a dialog. This 590 recommendation should have been limited to the invite usage instead 591 of the whole dialog. [3] states that a timeout for a NOTIFY removes 592 a subscription, but a SUBSCRIBE that fails with anything other than a 593 481 does not. Given these statements, it is unclear whether a 594 refresh SUBSCRIBE issued in a dialog shared with an invite usage 595 destroys either usage or the dialog if it times out. 597 Generally, a transaction timeout should affect only the usage in 598 which the transaction occurred. Other uses sharing the dialog should 599 not be affected. In the worst case of timeout due to total transport 600 failure, it may require multiple failed messages to remove all usages 601 from a dialog (at least one per usage). 603 There are some mid-dialog messages that never belong to any usage. 604 If they timeout, they will have no effect on the dialog or its 605 usages. 607 3.3 Matching requests to usages 609 For many mid-dialog requests, identifying the usage they belong to is 610 obvious. A dialog can have at most one invite usage, so any INVITE, 611 UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The 612 usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and 613 REFER requests belong to can be determined from the Event header 614 field of the request. REGISTER requests within a (pseudo)-dialog 615 belong to the registration usage. (As mentioned before, 616 implementations aren't mixing registration usages with other usages, 617 so this document isn't exploring the consequences of that bad 618 behavior). 620 According to [1], "an OPTIONS request received within a dialog 621 generates a 200 OK response that is identical to one constructed 622 outside a dialog and does not have any impact on that dialog". Thus 623 OPTIONS does not belong to any usage. Only those failures discussed 624 in Section 3.1 and Section 3.2 that destroy entire dialogs will have 625 any effect on the usages sharing the dialog with a failed OPTIONS 626 request. 628 MESSAGE requests are not currently allowed inside a dialog (though 629 some implementations use it that way, against the standard 630 recommendation). As it is not meant to be part of any given dialog, 631 it cannot be part of any given usage. A failed MESSAGE request 632 should have similar effects on a dialog and its usages as a failed 633 OPTIONS request. 635 Mid-dialog requests with unknown methods cannot be matched with a 636 usage. Servers will return a failure response (likely a 501). The 637 effect on the dialog and its usages at either the client or the 638 server should be similar to that of a failed OPTIONS request. 640 3.4 Target refresh requests 642 Target refresh requests update the remote target of a dialog when 643 they are successfully processed. The currently defined target 644 refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified 645 in a bug against RFC3565). REFER could also be a target refresh 646 request since it can establish a new usage (and even a new dialog). 647 (OPEN ISSUE: Is REFER a target refresh request?) 649 The remote target is part of the dialog state. When a target refresh 650 request affects it, it affects it for ALL usages sharing that dialog. 651 If a subscription and invite usage are sharing a dialog, sending a 652 refresh SUBSCRIBE with a different contact will cause reINVITEs from 653 the peer to go to that different contact. 655 A UAS will only update the remote target if it sends a 200 class 656 response to a target refresh request. A UAC will only update the 657 remote target if it receives a 200 class response to a target refresh 658 request. Again, any update to a dialog's remote target affects all 659 usages of that dialog. 661 3.5 Refreshing and Terminating Usages 663 Subscription and registration usages expire over time and must be 664 refreshed (with a refresh SUBSCRIBE for example). This expiration is 665 usage state, not dialog state. If several subscriptions share a 666 dialog, refreshing one of them has no effect on the expiration of the 667 others. 669 Normal termination of a usage has no effect on other usages sharing 670 the same dialog. For instance terminating a subscription with a 671 NOTIFY/Subscription-State: terminated will not terminate an invite 672 usage sharing its dialog. Likewise, ending an invite usage with a 673 BYE does not terminate any active Event: refer subscriptions 674 established on that dialog. 676 Abnormal termination can effect all usages on a dialog. Rejecting a 677 NOTIFY with a 481 (incorrectly recommended in the past as an 678 inexpensive way to terminate a REFER subscription) destroys the 679 dialog and all of its usages. 681 3.6 Refusing new usages 683 As the survey of the effect of failure responses shows, care must be 684 taken when refusing a new usage inside an existing dialog. Choosing 685 the wrong response code will terminate the dialog and all of its 686 usages. Generally, returning a 603 Decline is the safest way to 687 refuse a new usage. 689 3.7 Replacing usages 691 [5] defines a mechanism through which one usage can replace another. 692 It can be used, for example, to associate the two dialogs a transfer 693 target is involved in during an attended transfer. It is written 694 using the term "dialog", but its intent was to only affect the invite 695 usage of the dialog it targets. Any other usages inside that dialog 696 are unaffected. For some applications, the other usages may no 697 longer make sense, and the application may terminate them as well. 699 However, the interactions between Replaces and multiple dialog usages 700 have not been well explored. More discussion of this topic is 701 needed. Implementers should avoid this scenario completely. 703 4. Avoiding Multiple Usages 705 Processing multiple usages correctly is not completely understood. 706 What is understood is difficult to implement and is very likely to 707 lead to interoperability problems. The best way to avoid the trouble 708 that comes with such complexity is to avoid it altogether. 710 When designing new applications that use SIP dialogs, do not 711 construct multiple usages. If a peer attempts to create a second 712 usage inside a dialog, refuse it. 714 Unfortunately, there are existing applications, like transfer, that 715 currently entail multiple usages, so the simple solution of "don't do 716 it" will require some transitional work. This section will look at 717 the pressures that led to these existing multiple usages and suggest 718 alternatives. 720 When executing a transfer, the transferor and transferee currently 721 share an invite usage and a subscription usage within the dialog 722 between them. This is a result of sending the REFER request within 723 the dialog established by the invite usage. Implementations were led 724 to this behavior by two primary pressures: 725 1. There was no way to ensure that a REFER on a new dialog would 726 reach the particular endpoint involved in a transfer. Many 727 factors, including details of implementations and changes in 728 proxy routing between an INVITE and a REFER could cause the REFER 729 to be sent to the wrong place. Sending the REFER down the 730 existing dialog ensured it got to the endpoint we were already 731 talking to. 732 2. It was unclear how to associate an existing invite usage with a 733 REFER arriving on a new dialog, where it was completely obvious 734 what the association was when the REFER came on the invite 735 usage's dialog. 736 3. There were concerns with authorizing out-of-dialog REFERs. The 737 authorization policy for REFER in most implementations piggybacks 738 on the authorization policy for INVITE (which is, in most cases, 739 based simply on "I placed or answered this call"). 741 GRUUs ([6]) have been defined specifically to address problem 1. 742 Problem 2 can be addressed using a GRUU's grid parameter. In the 743 immediate term, this solution to problem 2 allows the existing REFER 744 authorization policy to be reused. Figure 3 shows a transfer where 745 any given dialog has exactly one usage. 747 Each message in this flow passes through a server at 748 example.com, which forwards messages to the endpoints 749 based on the AOR or GRUU in the Request-URI. This hop 750 through the server has been removed from the diagram 751 to make it easier to read. An "S" appears in the middle 752 of each arrow as a reminder of the visit to this intermediary. 754 Alice Bob Carol 755 | | | 756 | F1 INVITE (Bob's AOR) | | 757 | Call-ID: (call-id one) | | 758 | Contact: (Alice-GRUU-grid1) | | 759 |-------------S----------------->| | 760 | F2 200 OK | | 761 | Contact: (Bob-GRUU-grid1) | | 762 |<------------S------------------| | 763 | ACK | | 764 |-------------S----------------->| | 765 | : | | 766 | (Bob places Alice on hold) | | 767 | : | F3 INVITE (Carol's AOR) | 768 | | Call-ID: (call-id two) | 769 | | Contact: (Bob-GRUU-grid2) | 770 | |-------------S--------------->| 771 | | F4 200 OK | 772 | | Contact: (Carol-GRUU-grid1) 773 | |<------------S----------------| 774 | | ACK | 775 | |-------------S--------------->| 776 | | : | 777 | | (Bob places Carol on hold) | 778 | F5 REFER (Alice-GRUU-grid1) | : | 779 | Call-ID: (call-id three) | | 780 | Refer-To: (Carol-GRUU-grid1)| | 781 | Contact: (Bob-GRUU-grid1) | | 782 |<-----------S-------------------| | 783 | 202 Accepted | | 784 |------------S------------------>| | 785 | NOTIFY (Bob-GRUU-grid1) | | 786 |------------S------------------>| | 787 | 200 OK | | 788 |<-----------S-------------------| | 789 | | | 790 | | | 791 | | | 792 | | | 793 | | | 794 | F6 INVITE (Carol-GRUU-grid1) | 795 | Call-ID: (call-id four) | 796 | Contact: (Alice-GRUU-grid2) | 797 |-----------------------------S-------------------------------->| 798 | F7 200 OK | 799 | Contact: (Carol-GRUU-grid2) | 800 |<----------------------------S---------------------------------| 801 | ACK | 802 |-----------------------------S-------------------------------->| 803 | | | 804 | F8 NOTIFY (Bob-GRUU-grid1) | | 805 |-------------S----------------->| | 806 | 200 OK | | 807 |<------------S------------------| | 808 | BYE (Alice-GRUU-grid1) | | 809 |<------------S------------------| BYE (Carol-GRUU-grid1) | 810 | 200 OK |-------------S--------------->| 811 |-------------S----------------->| 200 OK | 812 | |<------------S----------------| 813 | | | 815 Figure 3: Transfer without dialog reuse 817 In message F1, Alice invites Bob indicating support for GRUUs (and 818 offering a GRUU for herself): 820 Message F1 (abridged, detailing pertinent fields) 822 INVITE sip:bob@example.com SIP/2.0 823 Call-ID: 13jfdwer230jsdw@alice.example.com 824 Supported: gruu 825 Contact: 827 Message F2 lets Alice know that Bob understands GRUUs. If Bob did 828 not indicate this support, the original multi-usage approach to 829 transfer would have to be used. 831 Message F2 (abridged, detailing pertinent fields) 833 SIP/2.0 200 OK 834 Supported: gruu 835 Contact: 837 Bob decides to try to transfer Alice to Carol, so he puts Alice on 838 hold and sends message F3 to Carol. Notice that Bob has provided a 839 different grid to Carol than he provided to Alice. This is a 840 significant part of the solution to problem 2 - if Alice or Carol 841 were to beat Bob to a REFER, this will let Bob know which invite 842 usage (the one with Alice or the one with Carol) to affect. 844 Message F3 (abridged, detailing pertinent fields) 846 INVITE sip:carol@example.com SIP/2.0 847 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 848 Supported: gruu 849 Contact: 851 Carol indicates her own support of GRUU and provides her GRUU for 852 this dialog in message F4: 854 Message F4 (abridged, detailing pertinent fields) 856 SIP/2.0 200 OK 857 Supported: gruu 858 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 859 To: ;tag=foiew3n 860 From: ;tag=baeih23n 861 Contact: 863 After consulting Carol, Bob places her on hold and refers Alice to 864 her using message F5. Notice that the Refer-To URI is Carol's GRUU, 865 and that this is on a different Call-ID than message F1. (The URI in 866 the Refer-To header is line-broken for readability in this draft, it 867 would not be valid to break the URI this way in a real message) 869 Message F5 (abridged, detailing pertinent fields) 871 REFER sip:aanewmr203raswdf@example.com;grid=au9a3e SIP/2.0 872 Call-ID: 39fa99r0329493asdsf3n@bob.example.com 873 Refer-To: 876 Supported: gruu 877 Contact: 879 Alice accepts this REFER, sends Bob the obligatory immediate NOTIFY, 880 and proceeds to INVITE Carol with message F6. Notice that Alice 881 gives Carol a GRUU with a different grid than she gave Bob. If Bob 882 decided not to terminate his dialog with Alice (possibly sending her 883 another REFER) and/or Carol decided to transfer Alice again, this 884 becomes an important part of associating Bob or Carol's REFER with 885 the correct invite usage. 887 Message F6 (abridged, detailing pertinent fields) 889 INVITE sip:c239fniuweorw9sdfn@example.com;grid=cbfnei2 SIP/2.0 890 Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com 891 Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; 892 to-tag=foiew3n;from-tag=baeih23n 893 Supported: gruu 894 Contact: 896 Carol accepts Alice's invitation to replace her dialog (invite usage) 897 with Bob with F7. For the same reasons listed above, Carol hands 898 Alice a different grid than the one she handed Bob (which was the one 899 Alice used to reach her in F6). 901 Message F7 (abridged, detailing pertinent fields) 903 SIP/2.0 200 OK 904 Supported: gruu 905 Contact: 907 Alice notifies Bob that the REFERenced INVITE succeeded with F8: 909 Message F8 (abridged, detailing pertinent fields) 911 NOTIFY sip:boaiidfjjereis@example.com;grid=baierac SIP/2.0 912 Subscription-State: terminated;reason=noresource 913 Contact: 914 Content-Type: message/sipfrag 916 SIP/2.0 200 OK 918 Bob then ends his invite usages with both Alice and Carol using BYEs. 920 Generalizing what was said several times during that flow: Using a 921 different grid for each usage between two endpoints lets endpoints 922 involved in more than one dialog figure out which dialog is related 923 to a new out-of-dialog request. Having that association can affect 924 whether this new out-of-dialog request is accepted. 926 One potential application for REFER that has been discussed at 927 several working group meetings is using an out-of-dialog REFER to ask 928 an endpoint to join a conference. An endpoint receiving such a REFER 929 would have to authorize it (by prompting its user for permission 930 perhaps). If this REFER arrived while the user was in another call, 931 the lack of a grid parameter matching the call that is ongoing lets 932 the UA know that this REFER is not a transfer of the existing call. 934 5. Conclusion 936 Handling multiple usages within a single dialog is complex and 937 introduces scenarios where the right thing to do is not clear. 938 Implementations should avoid entering into multiple usages whenever 939 possible. New applications should be designed to never introduce 940 multiple usages. 942 There are some accepted SIP practices, including transfer, that 943 currently require multiple usages. Recent work, most notably GRUU, 944 makes those practices unnecessary. The standardization of those 945 practices and the implementations should be revised as soon as 946 possible to use only single-usage dialogs. 948 6 Informative References 950 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 951 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 952 Session Initiation Protocol", RFC 3261, June 2002. 954 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 955 (SIP): Locating SIP Servers", RFC 3263, June 2002. 957 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 958 Notification", RFC 3265, June 2002. 960 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 961 Method", RFC 3515, April 2003. 963 [5] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation 964 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-04 965 (work in progress), August 2003. 967 [6] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 968 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 969 draft-ietf-sip-gruu-01 (work in progress), February 2004. 971 Author's Address 973 Robert J. Sparks 974 dynamicsoft 975 5100 Tennyson Parkway 976 Suite 1200 977 Plano, TX 75024 979 EMail: rsparks@dynamicsoft.com 981 Appendix A. Acknowledgments 983 The ideas in this draft have been refined over several IETF meetings 984 with many participants. Significant contribution was provided by 985 Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan 986 Rosenberg and Rohan Mahy. Members of the reSIProcate project (http:/ 987 /www.sipfoundry.org/reSIProcate) also shared their difficulties and 988 discoveries while implementing multiple-usage dialog handlers. 990 Intellectual Property Statement 992 The IETF takes no position regarding the validity or scope of any 993 Intellectual Property Rights or other rights that might be claimed to 994 pertain to the implementation or use of the technology described in 995 this document or the extent to which any license under such rights 996 might or might not be available; nor does it represent that it has 997 made any independent effort to identify any such rights. Information 998 on the procedures with respect to rights in RFC documents can be 999 found in BCP 78 and BCP 79. 1001 Copies of IPR disclosures made to the IETF Secretariat and any 1002 assurances of licenses to be made available, or the result of an 1003 attempt made to obtain a general license or permission for the use of 1004 such proprietary rights by implementers or users of this 1005 specification can be obtained from the IETF on-line IPR repository at 1006 http://www.ietf.org/ipr. 1008 The IETF invites any interested party to bring to its attention any 1009 copyrights, patents or patent applications, or other proprietary 1010 rights that may cover technology that may be required to implement 1011 this standard. Please address the information to the IETF at 1012 ietf-ipr@ietf.org. 1014 Disclaimer of Validity 1016 This document and the information contained herein are provided on an 1017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1019 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1020 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1021 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Copyright Statement 1026 Copyright (C) The Internet Society (2004). This document is subject 1027 to the rights, licenses and restrictions contained in BCP 78, and 1028 except as set forth therein, the authors retain all their rights. 1030 Acknowledgment 1032 Funding for the RFC Editor function is currently provided by the 1033 Internet Society.