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