diff options
Diffstat (limited to 'doc/rfc/rfc5057.txt')
| -rw-r--r-- | doc/rfc/rfc5057.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5057.txt b/doc/rfc/rfc5057.txt new file mode 100644 index 0000000..ed4da81 --- /dev/null +++ b/doc/rfc/rfc5057.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group R. Sparks +Request for Comments: 5057 Estacado Systems +Category: Informational November 2007 + + + Multiple Dialog Usages in the Session Initiation Protocol + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + Several methods in the Session Initiation Protocol (SIP) can create + an association between endpoints known as a dialog. Some of these + methods can also create a different, but related, association within + an existing dialog. These multiple associations, or dialog usages, + require carefully coordinated processing as they have independent + life-cycles, but share common dialog state. Processing multiple + dialog usages correctly is not completely understood. What is + understood is difficult to implement. + + This memo argues that multiple dialog usages should be avoided. It + discusses alternatives to their use and clarifies essential behavior + for elements that cannot currently avoid them. + + This is an informative document and makes no normative statements of + any kind. + + + + + + + + + + + + + + + + + + + + + +Sparks Informational [Page 1] + +RFC 5057 Multiple Dialog Usages November 2007 + + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4 + 3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 6 + 4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 9 + 4.1. Invite Usages . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 9 + 5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 9 + 5.1. A Survey of the Effect of Failure Responses on Usages + and Dialogs . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Transaction Timeouts . . . . . . . . . . . . . . . . . . . 15 + 5.3. Matching Requests to Usages . . . . . . . . . . . . . . . 16 + 5.4. Target Refresh Requests . . . . . . . . . . . . . . . . . 17 + 5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17 + 5.6. Refusing New Usages . . . . . . . . . . . . . . . . . . . 18 + 5.7. Replacing Usages . . . . . . . . . . . . . . . . . . . . . 18 + 6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 10. Informative References . . . . . . . . . . . . . . . . . . . . 24 + +1. Overview + + This is an informative document. It makes no normative statements of + any kind. This document refines the concept of a dialog usage in the + Session Initiation Protocol (SIP [1]), and discusses what led to its + existence. It explores ambiguity associated with processing multiple + dialog usages that share a dialog. In particular, it surveys the + effect of SIP failure responses on transaction, dialog usage, and + dialog state. This document will help the implementer understand + what is required to process multiple dialog usages correctly, and + will provide information for future standards-track work that will + clarify RFC 3261 and other related documents. Finally, the document + explores single-usage dialog alternatives (using SIP extensions) to + multiple dialog usages. + +2. Introduction + + Several methods in SIP can establish a dialog. When they do so, they + also establish an association between the endpoints within that + dialog. This association has been known for some time as a "dialog + usage" in the developer community. A dialog initiated with an INVITE + request has an invite usage. A dialog initiated with a SUBSCRIBE + + + + +Sparks Informational [Page 2] + +RFC 5057 Multiple Dialog Usages November 2007 + + + request has a subscribe usage. A dialog initiated with a REFER + request has a subscribe usage. + + Dialogs with multiple usages arise when a usage-creating action + occurs inside an existing dialog. Such actions include accepting a + REFER or SUBSCRIBE issued inside a dialog established with an INVITE + request. Multiple REFERs within a dialog create multiple + subscriptions, each of which is a new dialog usage sharing common + dialog state. (Note that any REFER issued utilizing the + subscription-suppression mechanism specified in [2] creates no new + usage.) Similarly, an endpoint in a dialog established with an + INVITE might subscribe to its peer's Key Press Markup Language (KPML) + [3] and later issue a REFER, resulting in three dialog usages sharing + common dialog state. + + The common state in the dialog shared by any usages is exactly: + + o the Call-ID + + o the local Tag + + o the remote Tag + + o the local CSeq + + o the remote CSeq + + o the Route-set + + o the local contact + + o the remote target + + o the secure flag + + Usages have state that is not shared in the dialog. For example, a + subscription has a duration, along with other usage-specific state. + Multiple subscriptions in the same dialog each have their own + duration. + + A dialog comes into existence with the creation of the first usage, + and continues to exist until the last usage is terminated (reference + counting). Unfortunately, many of the usage management aspects of + SIP, such as authentication, were originally designed with the + implicit assumption that there was one usage per dialog. The + resulting mechanisms have mixed effects, some influencing the usage, + and some influencing the entire dialog. + + + + +Sparks Informational [Page 3] + +RFC 5057 Multiple Dialog Usages November 2007 + + + The current specifications define two usages, invite and subscribe. + A dialog can share up to one invite usage and arbitrarily many + subscribe usages. + + Because RFC 3261 [1] states that user-agents should reuse Call-ID and + increment CSeq across a series of registration requests (and that to- + tags appear in register responses in some of the examples), some + implementations have treated REGISTER as if it were in a dialog. + However, RFC 3261 explicitly calls out that REGISTER does not create + a dialog. A series of REGISTER requests does not create any usage or + dialog. Similarly, PUBLISH [4] does not create any usage or dialog. + +3. Examples of Multiple Usages + +3.1. Transfer + + In Figure 1, Alice transfers a call she received from Bob to Carol. + A dialog (and an invite dialog usage) between Alice and Bob comes + into being with the 200 OK labeled F1. A second usage (a + subscription to event refer) comes into being with the NOTIFY labeled + F2. This second usage ends when the subscription is terminated by + the NOTIFY transaction labeled F3. The dialog still has one usage + (the invite usage), which lasts until the BYE transaction labeled F4. + At this point, the dialog has no remaining usages, so it ceases to + exist. Details of each of these messages are shown in Figure 2. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sparks Informational [Page 4] + +RFC 5057 Multiple Dialog Usages November 2007 + + + Alice Bob Carol + | INVITE | | + |<----------------| | + Dialog 1 Usage 1 | 200 OK (F1) | | + -start- -start- ----------->|---------------->| | + | | | ACK | | + | | |<----------------| | + | | | reINVITE/200/ACK| | + | | | (hold) | | + | | |---------------->| | + | | | REFER | | + | | Dialog 1 |---------------->| | + | | Usage 2 | NOTIFY (F2) | | + | | -start- -->|<----------------| INVITE | + | | | | 200 NOTIFY |----------->| + | | | |---------------->| 200 OK | + | | | | 200 REFER |<-----------| + | | | |<----------------| ACK | + | | | | NOTIFY (F3) |----------->| + | | | |<----------------| | + | | | | 200 | . | + | | -end- -->|---------------->| . | + | | | BYE (F4) | Dialog 2 | + | | |<----------------| proceeds | + | | | 200 | . | + -end- -end- ------------>|---------------->| . | + + Figure 1 + + Message Details (abridged to show only dialog or usage details) + F1 + SIP/2.0 200 OK + Call-ID: dialog1@bob.example.com + CSeq: 100 INVITE + To: <sip:Alice@alice.example.com>;tag=alicetag1 + From: <sip:Bob@bob.example.com>;tag=bobtag1 + Contact: <sip:aliceinstance@alice.example.com> + + F2 + NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 + Event: refer + Call-ID: dialog1@bob.example.com + CSeq: 101 NOTIFY + To: <sip:Alice@alice.example.com>;tag=alicetag1 + From: <sip:Bob@bob.example.com>;tag=bobtag1 + Contact: <sip:bobinstance@bob.example.com> + + + + + +Sparks Informational [Page 5] + +RFC 5057 Multiple Dialog Usages November 2007 + + + F3 + NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 + Event: refer + Subscription-State: terminated;reason=noresource + Call-ID: dialog1@bob.example.com + CSeq: 102 NOTIFY + To: <sip:Alice@alice.example.com>;tag=alicetag1 + From: <sip:Bob@bob.example.com>;tag=bobtag1 + Contact: <sip:bobinstance@bob.example.com> + Content-Type: message/sipfrag + + SIP/2.0 200 OK + + F4 + BYE sip:aliceinstance@alice.example.com SIP/2.0 + Call-ID: dialog1@bob.example.com + CSeq: 103 BYE + To: <sip:Alice@alice.example.com>;tag=alicetag1 + From: <sip:Bob@bob.example.com>;tag=bobtag1 + Contact: <sip:bobinstance@bob.example.com> + + Figure 2 + +3.2. Reciprocal Subscription + + In Figure 3, Alice subscribes to Bob's presence. For simplicity, + assume Bob and Alice are both serving their presence from their + endpoints instead of a presence server. To focus on the essential + points, the figure leaves out any rendezvous signaling through which + Alice discovers Bob's endpoint. + + Bob is interested in Alice's presence too, so he subscribes to Alice + (in most deployed presence/IM systems, people watch each other). He + decides to skip the rendezvous step since he's already in a dialog + with Alice, and sends his SUBSCRIBE inside that dialog (a few early + SIMPLE clients behaved exactly this way). + + The dialog and its first usage comes into being at F1, which + establishes Alice's subscription to Bob. Its second usage begins at + F2, which establishes Bob's subscription to Alice. These two + subscriptions are independent - they have distinct and different + expirations, but they share all the dialog state. + + The first usage ends when Alice decides to unsubscribe at F3. Bob's + subscription to Alice, and thus the dialog, continues to exist. + Alice's UA must maintain this dialog state even though the + subscription that caused it to exist in the first place is now over. + The second usage ends when Alice decides to terminate Bob's + + + +Sparks Informational [Page 6] + +RFC 5057 Multiple Dialog Usages November 2007 + + + subscription at F4 (she's probably going to reject any attempt on + Bob's part to resubscribe until she's ready to subscribe to Bob + again). Since this was the last usage, the dialog also terminates. + Details of these messages are shown in Figure 4. + + Alice Bob + | | + | SUBSCRIBE | + |------------------->| + Dialog Usage 1 | NOTIFY (F1) | + -start- -start- --------->|<-------------------| + | | | 200 SUBSCRIBE | + | | |<-------------------| + | | | 200 NOTIFY | + | | |------------------->| + | | | SUBSCRIBE | + | | |<-------------------| + | | Usage 2 | NOTIFY (F2) | + | | -start- -->|------------------->| + | | | | 200 SUBSCRIBE + | | | |------------------->| + | | | | 200 NOTIFY | + | | | |<-------------------| + | | | | : | + | | | | : | + | | | | (un)SUBSCRIBE (F3) | + | | | |------------------->| + | | | | 200 | + | | | |<-------------------| + | | | | NOTIFY | + | | | |<-------------------| + | | | | 200 | + | -end- ----------->|------------------->| + | | | : | + | | | : | + | | | NOTIFY (F4) | + | | | (Terminated) | + | | |------------------->| + | | | 200 | + -end- -end- -->|<-------------------| + | | + + Figure 3 + + + + + + + + +Sparks Informational [Page 7] + +RFC 5057 Multiple Dialog Usages November 2007 + + + Message Details (abridged to show only dialog or usage details) + F1 + NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 + Event: presence + Subscription-State: active;expires=600 + Call-ID: alicecallid1@alice.example.com + From: <sip:Bob@bob.example.com>;tag=bobtag2 + To: <sip:Alice@alice.example.com>;tag=alicetag2 + CSeq: 100 NOTIFY + Contact: <sip:bobinstance@bob.example.com> + + F2 + NOTIFY sip:bobinstance@bob.example.com SIP/2.0 + Event: presence + Subscription-State: active;expires=1200 + Call-ID: alicecallid1@alice.example.com + To: <sip:Bob@bob.example.com>;tag=bobtag2 + From: <sip:Alice@alice.example.com>;tag=alicetag2 + CSeq: 500 NOTIFY + Contact: <sip:aliceinstance@alice.example.com> + + F3 + SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0 + Event: presence + Expires: 0 + Call-ID: alicecallid1@alice.example.com + To: <sip:Bob@bob.example.com>;tag=bobtag2 + From: <sip:Alice@alice.example.com>;tag=alicetag2 + CSeq: 501 SUBSCRIBE + Contact: <sip:aliceinstance@alice.example.com> + + F4 + NOTIFY sip:bobinstance@bob.example.com SIP/2.0 + Event: presence + Subscription-State: terminated;reason=deactivated + Call-ID: alicecallid1@alice.example.com + To: <sip:Bob@bob.example.com>;tag=bobtag2 + From: <sip:Alice@alice.example.com>;tag=alicetag2 + CSeq: 502 NOTIFY + Contact: <sip:aliceinstance@alice.example.com> + + Figure 4 + + + + + + + + + +Sparks Informational [Page 8] + +RFC 5057 Multiple Dialog Usages November 2007 + + +4. Usage Creation and Destruction + + Dialogs come into existence along with their first usage. Dialogs + terminate when their last usage is destroyed. The messages that + create and destroy usages vary per usage. This section provides a + high-level categorization of those messages. The section does not + attempt to explore the REGISTER pseudo-dialog. + +4.1. Invite Usages + + Created by: non-100 provisional responses to INVITE; 200 response to + INVITE + + Destroyed by: 200 responses to BYE; certain failure responses to + INVITE, UPDATE, PRACK, INFO, or BYE; anything that destroys a + dialog and all its usages + +4.2. Subscribe usages + + Created by: 200 class responses to SUBSCRIBE; 200 class responses to + REFER; NOTIFY requests + + Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or + refresh-SUBSCRIBE request timeout; certain failure responses to + NOTIFY or SUBSCRIBE; expiration without refresh if network issues + prevent the terminal NOTIFY from arriving; anything that destroys + a dialog and all its usages + +5. Proper Handling of Multiple Usages + + The examples in Section 3 show straightforward cases where it is + fairly obvious when the dialog begins and ends. Unfortunately, there + are many scenarios where such clarity is not present. For instance, + in Figure 1, what would it mean if the response to the NOTIFY (F2) + were a 481? Does that simply terminate the refer subscription, or + does it destroy the entire dialog? This section explores the problem + areas with multiple usages that have been identified to date. + +5.1. A Survey of the Effect of Failure Responses on Usages and Dialogs + + For this survey, consider a subscribe usage inside a dialog + established with an invite usage. Unless stated otherwise, we'll + discuss the effect on each usage and the dialog when a client issuing + a NOTIFY inside the subscribe usage receives a failure response (such + as a transferee issuing a NOTIFY to event refer). Further, unless + otherwise stated, the conclusions apply to arbitrary multiple usages. + This survey is written from the perspective of a client receiving the + + + + +Sparks Informational [Page 9] + +RFC 5057 Multiple Dialog Usages November 2007 + + + error response. The effect on dialogs and usages at the server + issuing the response is the same. + + 3xx responses: Redirection mid-dialog is not well understood in SIP, + but whatever effect it has impacts the entire dialog and all of + its usages equally. In our example scenario, both the + subscription and the invite usage would be redirected by this + single response. + + For the failure responses with code 400 and greater, there are three + common ways the failure can affect the transaction, usage, and dialog + state. + + Transaction Only The error affects only the transaction, not the + usage or dialog the transaction occurs in (beyond affecting the + local CSeq). Any other usage of the dialog is unaffected. The + error is a complaint about this transaction, not the usage or + dialog that the transaction occurs in. + + Destroys Usage The error destroys the usage, but not the dialog. + Any other usages sharing this dialog are not affected. + + Destroys Dialog The error destroys the dialog and all usages sharing + it. + + Table 1 and Table 2 display how the various codes affect transaction, + usage, or dialog state. Response code specific comments or + exceptions follow the table. + + +----------------------+----------------+-----------------+ + | Transaction Only | Destroys Usage | Destroys Dialog | + +----------------------+----------------+-----------------+ + | 400 (or unknown 4xx) | 405, 480 | 404, 410, 416 | + | 401, 402, 403, 406 | 481, 489 | 482, 483 | + | 407, 408, 412-415 | 501 | 484, 485 | + | 417, 420, 421, 422 | | 502, 604 | + | 423, 428, 429 | | | + | 436-438, 486, 487 | | | + | 488, 491, 493, 494 | | | + | 500 (or unknown 5xx) | | | + | 503, 504, 505 | | | + | 513, 580 | | | + | 600 (or unknown 6xx) | | | + | 603, 606 | | | + +----------------------+----------------+-----------------+ + + Table 1 + + + + +Sparks Informational [Page 10] + +RFC 5057 Multiple Dialog Usages November 2007 + + + +---------+---------------------------------+-------------+-------+ + | Code | Reason | Impact | Notes | + +---------+---------------------------------+-------------+-------+ + | 400/4xx | Bad Request | Transaction | | + | 401 | Unauthorized | Transaction | | + | 402 | Payment Required | Transaction | (1) | + | 403 | Forbidden | Transaction | | + | 404 | Not Found | Dialog | (2) | + | 405 | Method Not Allowed | Usage | (3) | + | 406 | Not Acceptable | Transaction | | + | 407 | Proxy Authentication Required | Transaction | | + | 408 | Request Timeout | Transaction | (4) | + | 410 | Gone | Dialog | (2) | + | 412 | Conditional Request Failed | Transaction | | + | 413 | Request Entity Too Large | Transaction | | + | 414 | Request-URI Too Long | Transaction | | + | 415 | Unsupported Media Type | Transaction | | + | 416 | Unsupported URI Scheme | Dialog | (2) | + | 417 | Unknown Resource-Priority | Transaction | | + | 420 | Bad Extension | Transaction | | + | 421 | Extension Required | Transaction | | + | 422 | Session Interval Too Small | Transaction | (5) | + | 423 | Interval Too Brief | Transaction | | + | 428 | Use Identity Header | Transaction | | + | 429 | Provide Referrer Identity | Transaction | (6) | + | 436 | Bad Identity-Info | Transaction | | + | 437 | Unsupported Certificate | Transaction | | + | 438 | Invalid Identity Header | Transaction | | + | 480 | Temporarily Unavailable | Usage | (7) | + | 481 | Call/Transaction Does Not Exist | Usage | (8) | + | 482 | Loop Detected | Dialog | (9) | + | 483 | Too Many Hops | Dialog | (10) | + | 484 | Address Incomplete | Dialog | (2) | + | 485 | Ambiguous | Dialog | (2) | + | 486 | Busy Here | Transaction | (11) | + | 487 | Request Terminated | Transaction | | + | 488 | Not Acceptable Here | Transaction | | + | 489 | Bad Event | Usage | (12) | + | 491 | Request Pending | Transaction | | + | 493 | Undecipherable | Transaction | | + | 494 | Security Agreement Required | Transaction | | + | 500/5xx | Server Internal Error | Transaction | (13) | + | 501 | Not Implemented | Usage | (3) | + | 502 | Bad Gateway | Dialog | (14) | + | 503 | Service Unavailable | Transaction | (15) | + | 504 | Server Time-Out | Transaction | (16) | + | 505 | Version Not Supported | Transaction | | + | 513 | Message Too Large | Transaction | | + + + +Sparks Informational [Page 11] + +RFC 5057 Multiple Dialog Usages November 2007 + + + | 580 | Precondition Failure | Transaction | | + | 600/6xx | Busy Everywhere | Transaction | (17) | + | 603 | Decline | Transaction | | + | 604 | Does Not Exist Anywhere | Dialog | (2) | + | 606 | Not Acceptable | Transaction | | + +---------+---------------------------------+-------------+-------+ + + Table 2 + + (1) 402 Payment Required: This is a reserved response code. If + encountered, it should be treated as an unrecognized 4xx. + + (2) 404 Not Found: + + 410 Gone: + + 416 Unsupported URI Scheme: + + 484 Address Incomplete: + + 485 Ambiguous: + + 604 Does Not Exist Anywhere: + + The Request-URI that is being rejected is the remote target set by + the Contact provided by the peer. Getting this response means + that something has gone fundamentally wrong with the dialog state. + + (3) 405 Method Not Allowed: + + 501 Not Implemented: + + Either of these responses would be aberrant in our example + scenario since support for the NOTIFY method is required by the + usage. In this case, the UA knows the condition is unrecoverable + and should stop sending NOTIFYs on the usage. Any refresh + subscriptions should be rejected. In general, these errors will + affect at most the usage. If the request was not integral to the + usage (it used an unknown method, or was an INFO inside an INVITE + usage, for example), only the transaction will be affected. + + (4) 408 Request Timeout: Receiving a 408 will have the same effect + on usages and dialogs as a real transaction timeout as described + in Section 5.2. + + + + + + + +Sparks Informational [Page 12] + +RFC 5057 Multiple Dialog Usages November 2007 + + + (5) 422 Session Interval Too Small: This response does not make + sense for any mid-usage request. If it is received, an element in + the path of the request is violating protocol, and the recipient + should treat this as it would an unknown 4xx response. + + (6) 429 Provide Referrer Identity: This response won't be returned + to a NOTIFY as in our example scenario, but when it is returned to + a REFER, it is objecting only to the REFER request itself. + + (7) 480 Temporarily Unavailable: RFC 3261 is unclear on what this + response means for mid-usage requests. Future updates to that + specification are expected to clarify that this response affects + only the usage in which the request occurs. No other usages are + affected. If the response included a Retry-After header field, + further requests in that usage should not be sent until the + indicated time has past. Requests in other usages may still be + sent at any time. + + (8) 481 Call/Transaction Does Not Exist: This response indicates + that the peer has lost its copy of the dialog usage state. The + dialog itself should not be destroyed unless this was the last + usage. + + The effects of a 481 on a dialog and its usages are the most + ambiguous of any final response. There are implementations that + have chosen the meaning recommended here, and others that destroy + the entire dialog without regard to the number of outstanding + usages. Going forward with this clarification will allow those + deployed implementations that assumed only the usage was destroyed + to work with a wider number of implementations. Existing + implementations that destroy all other usages in the dialog will + continue to function as they do now, except that peers following + the recommendation will attempt to do things with the other usages + and this element will return 481s for each of them until they are + all gone. However, the necessary clarification to RFC 3261 needs + to make it very clear that the ability to terminate usages + independently from the overall dialog using a 481 is not + justification for designing new applications that count on + multiple usages in a dialog. + + The 481 response to a CANCEL request has to be treated + differently. For CANCEL, a 481 means the UAS can't find a + matching transaction. A 481 response to a CANCEL affects only the + CANCEL transaction. The usage associated with the INVITE is not + affected. + + + + + + +Sparks Informational [Page 13] + +RFC 5057 Multiple Dialog Usages November 2007 + + + (9) 482 Loop Detected: This response is aberrant mid-dialog. It + will only occur if the Record-Route header field were improperly + constructed by the proxies involved in setting up the dialog's + initial usage, or if a mid-dialog request forks and merges (which + should never happen). Future requests using this dialog state + will also fail. + + An edge condition exists during RFC 3263 failover at the + element sending a request, where the request effectively forks + to multiple destinations from the client. Some implementations + increase risk entering this edge condition by trying the next + potential location as determined by RFC 3263 very rapidly if + the first does not immediately respond. In any situation where + a client sends the same request to more than one endpoint, it + must be prepared to receive a response from each branch (and + should choose a "best" response to act on following the same + guidelines as a forking proxy). In this particular race + condition, if multiple branches respond, all but one will most + likely return a 482 Merged Request. The client should select + the remaining non-482 response as the "best" response. + + (10) 483 Too Many Hops: Similar to 482, receiving this mid-dialog is + aberrant. Unlike 482, recovery may be possible by increasing Max- + Forwards (assuming that the requester did something strange like + using a smaller value for Max-Forwards in mid-dialog requests than + it used for an initial request). If the request isn't tried with + an increased Max-Forwards, then the agent should follow the + Destroy Dialog actions. + + (11) 486 Busy Here: This response is nonsensical in our example + scenario, or in any scenario where this response comes inside an + established usage. If it occurs in that context, it should be + treated as an unknown 4xx response. + + (12) 489 Bad Event: In our example scenario, [5] declares that the + subscription usage in which the NOTIFY is sent is terminated. + This response is only valid in the context of SUBSCRIBE and + NOTIFY. UAC behavior for receiving this response to other methods + is not specified, but treating it as an unknown 4xx is a + reasonable practice. + + (13) 500 and 5xx unrecognized responses: If the response contains a + Retry-After header field value, the server thinks the condition is + temporary, and the request can be retried after the indicated + interval. If the response does not contain a Retry-After header + field value, the UA may decide to retry after an interval of its + choosing or attempt to gracefully terminate the usage. Whether or + not to terminate other usages depends on the application. If the + + + +Sparks Informational [Page 14] + +RFC 5057 Multiple Dialog Usages November 2007 + + + UA receives a 500 (or unrecognized 5xx) in response to an attempt + to gracefully terminate this usage, it can treat this usage as + terminated. If this is the last usage sharing the dialog, the + dialog is also terminated. + + (14) 502 Bad Gateway: This response is aberrant mid-dialog. It will + only occur if the Record-Route header field were improperly + constructed by the proxies involved in setting up the dialog's + initial usage. Future requests using this dialog state will also + fail. + + (15) 503 Service Unavailable: As per [6], the logic handling + locating SIP servers for transactions may handle 503 requests + (effectively, sequentially forking at the endpoint based on DNS + results). If this process does not yield a better response, a 503 + may be returned to the transaction user. Like a 500 response, the + error is a complaint about this transaction, not the usage. + Because this response occurred in the context of an established + usage (hence an existing dialog), the route-set has already been + formed and any opportunity to try alternate servers (as + recommended in [1]) has been exhausted by the RFC3263 logic. + + (16) 504 Server Time-out: It is not obvious under what circumstances + this response would be returned to a request in an existing + dialog. + + (17) 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a + 600 response code says something about the recipient user, not the + request that was made. This end user is stating an unwillingness + to communicate. If the response contains a Retry-After header + field value, the user is indicating willingness to communicate + later and the request can be retried after the indicated interval. + This usage, and any other usages sharing the dialog are + unaffected. If the response does not contain a Retry-After header + field value, the UA may decide to retry after an interval of its + choosing or attempt to gracefully terminate the usage. Whether or + not to terminate other usages depends on the application. If the + UA receives a 600 (or unrecognized 6xx) in response to an attempt + to gracefully terminate this usage, it can treat this usage as + terminated. If this is the last usage sharing the dialog, the + dialog is also terminated. + +5.2. Transaction Timeouts + + [1] states that a UAC should terminate a dialog (by sending a BYE) if + no response is received for a request sent within a dialog. This + recommendation should have been limited to the invite usage instead + of the whole dialog. [5] states that a timeout for a NOTIFY removes a + + + +Sparks Informational [Page 15] + +RFC 5057 Multiple Dialog Usages November 2007 + + + subscription, but a SUBSCRIBE that fails with anything other than a + 481 does not. Given these statements, it is unclear whether a + refresh SUBSCRIBE issued in a dialog shared with an invite usage + destroys either usage or the dialog if it times out. + + Generally, a transaction timeout should affect only the usage in + which the transaction occurred. Other uses sharing the dialog should + not be affected. In the worst case of timeout due to total transport + failure, it may require multiple failed messages to remove all usages + from a dialog (at least one per usage). + + There are some mid-dialog messages that never belong to any usage. + If they timeout, they will have no effect on the dialog or its + usages. + +5.3. Matching Requests to Usages + + For many mid-dialog requests, identifying the usage they belong to is + obvious. A dialog can have at most one invite usage, so any INVITE, + UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The + usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER + requests belong to can be determined from the Event header field of + the request. REGISTER requests within a (pseudo)-dialog belong to + the registration usage. (As mentioned before, implementations aren't + mixing registration usages with other usages, so this document isn't + exploring the consequences of that bad behavior). + + According to [1], "an OPTIONS request received within a dialog + generates a 200 OK response that is identical to one constructed + outside a dialog and does not have any impact on that dialog". Thus, + OPTIONS does not belong to any usage. Only those failures discussed + in Section 5.1 and Section 5.2 that destroy entire dialogs will have + any effect on the usages sharing the dialog with a failed OPTIONS + request. + + MESSAGE requests are discouraged inside a dialog. Implementations + are restricted from creating a usage for the purpose of carrying a + sequence of MESSAGE requests (though some implementations use it that + way, against the standard recommendation). A failed MESSAGE + occurring inside an existing dialog will have similar effects on the + dialog and its usages as a failed OPTIONS request. + + Mid-dialog requests with unknown methods cannot be matched with a + usage. Servers will return a failure response (likely a 501). The + effect on the dialog and its usages at either the client or the + server should be similar to that of a failed OPTIONS request. + + + + + +Sparks Informational [Page 16] + +RFC 5057 Multiple Dialog Usages November 2007 + + + These guidelines for matching messages to usages (or determining + there is no usage) apply equally when acting as a UAS, a UAC, or any + third party tracking usage and dialog state by inspecting all + messages between two endpoints. + +5.4. Target Refresh Requests + + Target refresh requests update the remote target of a dialog when + they are successfully processed. The currently defined target + refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER + [7]). + + The remote target is part of the dialog state. When a target refresh + request affects it, it affects it for ALL usages sharing that dialog. + If a subscription and invite usage are sharing a dialog, sending a + refresh SUBSCRIBE with a different contact will cause reINVITEs from + the peer to go to that different contact. + + A UAS will only update the remote target if it sends a 200 class + response to a target refresh request. A UAC will only update the + remote target if it receives a 200 class response to a target refresh + request. Again, any update to a dialog's remote target affects all + usages of that dialog. + + There is known ambiguity around the effects of provisional responses + on remote targets that a future specification will attempt to + clarify. Furthermore, because the remote target is part of the + dialog state, not any usage state, there is ambiguity in having + target refresh requests in progress simultaneously on multiple usages + in the same dialog. Implementation designers should consider these + conditions with care. + +5.5. Refreshing and Terminating Usages + + Subscription and registration usages expire over time and must be + refreshed (with a refresh SUBSCRIBE, for example). This expiration + is usage state, not dialog state. If several subscriptions share a + dialog, refreshing one of them has no effect on the expiration of the + others. + + Normal termination of a usage has no effect on other usages sharing + the same dialog. For instance, terminating a subscription with a + NOTIFY/Subscription-State: terminated will not terminate an invite + usage sharing its dialog. Likewise, ending an invite usage with a + BYE does not terminate any active Event: refer subscriptions + established on that dialog. + + + + + +Sparks Informational [Page 17] + +RFC 5057 Multiple Dialog Usages November 2007 + + +5.6. Refusing New Usages + + As the survey of the effect of failure responses shows, care must be + taken when refusing a new usage inside an existing dialog. Choosing + the wrong response code will terminate the dialog and all of its + usages. Generally, returning a 603 Decline is the safest way to + refuse a new usage. + +5.7. Replacing Usages + + [8] defines a mechanism through which one usage can replace another. + It can be used, for example, to associate the two dialogs in which a + transfer target is involved during an attended transfer. It is + written using the term "dialog", but its intent was only to affect + the invite usage of the dialog it targets. Any other usages inside + that dialog are unaffected. For some applications, the other usages + may no longer make sense, and the application may terminate them as + well. + + However, the interactions between Replaces and multiple dialog usages + have not been well explored. More discussion of this topic is + needed. Implementers should avoid this scenario completely. + +6. Avoiding Multiple Usages + + Processing multiple usages correctly is not completely understood. + What is understood is difficult to implement and is very likely to + lead to interoperability problems. The best way to avoid the trouble + that comes with such complexity is to avoid it altogether. + + When designing new applications or features that use SIP dialogs, do + not require endpoints to construct multiple usages to participate in + the application or use the feature. When designing endpoints, + address the existing multiple usage scenarios as best as possible. + Outside those scenarios, if a peer attempts to create a second usage + inside a dialog, refuse it. + + Unfortunately, there are existing applications, like transfer, that + currently entail multiple usages, so the simple solution of "don't do + it" will require some transitional work. This section looks at the + pressures that led to these existing multiple usages and suggests + alternatives. + + When executing a transfer, the transferor and transferee currently + share an invite usage and a subscription usage within the dialog + between them. This is a result of sending the REFER request within + the dialog established by the invite usage. Implementations were led + to this behavior by these primary problems: + + + +Sparks Informational [Page 18] + +RFC 5057 Multiple Dialog Usages November 2007 + + + 1. There was no way to ensure that a REFER on a new dialog would + reach the particular endpoint involved in a transfer. Many + factors, including details of implementations and changes in + proxy routing between an INVITE and a REFER could cause the REFER + to be sent to the wrong place. Sending the REFER down the + existing dialog ensured it got to the same endpoint with which + the dialog was established. + + 2. It was unclear how to associate an existing invite usage with a + REFER arriving on a new dialog, where it was completely obvious + what the association was when the REFER came on the invite + usage's dialog. + + 3. There were concerns with authorizing out-of-dialog REFERs. The + authorization policy for REFER in most implementations piggybacks + on the authorization policy for INVITE (which is, in most cases, + based simply on "I placed or answered this call"). + + Globally Routable User Agent (UA) URIs (GRUUs) [9] have been defined + specifically to address problem 1 by providing a URI that will reach + one specific user-agent. The Target-Dialog header field [10] was + created to address problems 2 and 3. This header field allows a + request to indicate the dialog identifiers of some other dialog, + providing association with the other dialog that can be used in an + authorization decision. + + The Join [11] and Replaces [8] mechanisms can also be used to address + problem 1. When using this technique, a new request is sent outside + any dialog with the expectation that it will fork to possibly many + endpoints, including the one we're interested in. This request + contains a header field listing the dialog identifiers of a dialog in + progress. Only the endpoint holding a dialog matching those + identifiers will accept the request. The other endpoints the request + may have forked to will respond with an error. This mechanism is + reasonably robust, failing only when the routing logic for out-of- + dialog requests changes such that the new request does not arrive at + the endpoint holding the dialog of interest. + + The reachability aspects of using a GRUU to address problem 1 can be + combined with the association-with-other-dialogs aspects of the Join/ + Replaces and Target-Dialog mechanisms. A REFER request sent out-of- + dialog can be sent towards a GRUU, and identify an existing dialog as + part of the context the receiver should use. The Target-Dialog + header field can be included in the REFER listing the dialog this + REFER is associated with. Figure 5 sketches how this could be used + to achieve transfer without reusing a dialog. For simplicity, the + diagram and message details do not show the server at example.com + + + + +Sparks Informational [Page 19] + +RFC 5057 Multiple Dialog Usages November 2007 + + + that will be involved in routing the GRUU. Refer to [9] for those + details. + + Alice Bob Carol + | | | + | F1 INVITE (Bob's AOR) | | + | Call-ID: (call-id one) | | + | Contact: (Alice's-GRUU) | | + |------------------------------->| | + | F2 200 OK | | + | To: <>;tag=totag1 | | + | From: <>;tag=fromtag1 | | + | Call-ID: (call-id one) | | + | Contact: (Bob's-GRUU) | | + |<-------------------------------| | + | ACK | | + |------------------------------->| | + | : | | + | (Bob places Alice on hold) | | + | : | F3 INVITE (Carol's AOR) | + | | Call-ID: (call-id two) | + | | Contact: (Bob's-GRUU) | + | |----------------------------->| + | | F4 200 OK | + | | To: <>;tag=totag2 | + | | From: <>;tag=fromtag2 | + | | Call-ID: (call-id two) | + | | Contact: (Carol's-GRUU) | + | |<-----------------------------| + | | ACK | + | |----------------------------->| + | | : | + | | (Bob places Carol on hold) | + | F5 REFER (Alice's-GRUU) | : | + | Call-ID: (call-id three) | | + | Refer-To: (Carol's-GRUU) | | + | Target-Dialog: (call-id one,totag1,fromtag1) | + | Contact: (Bob's-GRUU) | | + |<-------------------------------| | + | 202 Accepted | | + |------------------------------->| | + + + + + + + + + + +Sparks Informational [Page 20] + +RFC 5057 Multiple Dialog Usages November 2007 + + + | NOTIFY (Bob's-GRUU) | | + | Call-ID: (call-id three) | | + |------------------------------->| | + | 200 OK | | + |<-------------------------------| | + | | | + | F6 INVITE (Carol's-GRUU) | + | Call-ID: (call-id four) | + | Contact: (Alice's-GRUU) | + |-------------------------------------------------------------->| + | 200 OK | + | Contact: (Carol's-GRUU) | + |<--------------------------------------------------------------| + | ACK | + |-------------------------------------------------------------->| + | | | + | F7 NOTIFY (Bob's-GRUU) | | + | Call-ID: (call-id three) | | + |------------------------------->| | + | 200 OK | | + |<-------------------------------| | + | BYE (Alice's-GRUU) | | + | Call-ID: (call-id one) | | + |<-------------------------------| BYE (Carol's-GRUU) | + | | Call-ID: (call-id two) | + | 200 OK |----------------------------->| + |------------------------------->| 200 OK | + | |<-----------------------------| + | | | + + + Figure 5: Transfer without dialog reuse + + In message F1, Alice invites Bob indicating support for GRUUs (and + offering a GRUU for herself): + + Message F1 (abridged, detailing pertinent fields) + + INVITE sip:bob@example.com SIP/2.0 + Call-ID: 13jfdwer230jsdw@alice.example.com + Supported: gruu + Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)> + + + + + + + + + +Sparks Informational [Page 21] + +RFC 5057 Multiple Dialog Usages November 2007 + + + Message F2 carries Bob's GRUU to Alice. + + Message F2 (abridged, detailing pertinent fields) + + SIP/2.0 200 OK + Supported: gruu + To: <sip:bob@example.com>;tag=totag1 + From: <sip:alice@example.com>;tag=fromtag1 + Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)> + + Bob decides to try to transfer Alice to Carol, so he puts Alice on + hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU + support similar to what happened in F1 and F2. + + Message F3 (abridged, detailing pertinent fields) + + INVITE sip:carol@example.com SIP/2.0 + Supported: gruu + Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com + Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)> + + Message F4 (abridged, detailing pertinent fields) + + SIP/2.0 200 OK + Supported: gruu + To: <sip:carol@example.com>;tag=totag2 + From: <sip:bob@example.com>;tag=fromtag2 + Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com + Contact: <sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)> + + After consulting Carol, Bob places her on hold and refers Alice to + her using message F5. Notice that the Refer-To URI is Carol's GRUU, + and that this is on a different Call-ID than message F1. (The URI in + the Refer-To header is line-broken for readability in this document; + it would not be valid to break the URI this way in a real message.) + + Message F5 (abridged, detailing pertinent fields) + + REFER sip:aanewmr203raswdf@example.com SIP/2.0 + Call-ID: 39fa99r0329493asdsf3n@bob.example.com + Refer-To: <sip:carol@example.com;g=urn:uid:(Carol's UA's bits) + ?Replaces=23rasdnfoa39i4jnasdf@bob.example.com; + to-tag=totag2;from-tag=fromtag2> + Target-Dialog: 13jfdwer230jsdw@alice.example.com; + local-tag=fromtag1;remote-tag=totag1 + Supported: gruu + Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)> + + + + +Sparks Informational [Page 22] + +RFC 5057 Multiple Dialog Usages November 2007 + + + Alice uses the information in the Target-Dialog header field to + determine that this REFER is associated with the dialog she already + has in place with Bob. Alice is now in a position to use the same + admission policy she used for in-dialog REFERs: "Do I have a call + with this person?". She accepts the REFER, sends Bob the obligatory + immediate NOTIFY, and proceeds to INVITE Carol with message F6. + + Message F6 (abridged, detailing pertinent fields) + + sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits) + \ / + \ / + | | + v v + INVITE SIP/2.0 + Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com + Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; + to-tag=totag2;from-tag=fromtag2 + Supported: gruu + Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)> + + Carol accepts Alice's invitation to replace her dialog (invite usage) + with Bob, and notifies him that the REFERenced INVITE succeeded with + F7: + + Message F7 (abridged, detailing pertinent fields) + + NOTIFY sip:boaiidfjjereis@example.com SIP/2.0 + Subscription-State: terminated;reason=noresource + Call-ID: 39fa99r0329493asdsf3n@bob.example.com + Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)> + Content-Type: message/sipfrag + + SIP/2.0 200 OK + + Bob then ends his invite usages with both Alice and Carol using BYEs. + +7. Security Considerations + + Handling multiple usages within a single dialog is complex and + introduces scenarios where the right thing to do is not clear. The + ambiguities described here can result in unexpected disruption of + communication if response codes are chosen carelessly. Furthermore, + these ambiguities could be exploited, particularly by third-parties + injecting unauthenticated requests or inappropriate responses. + Implementations choosing to create or accept multiple usages within a + dialog should give extra attention to the security considerations in + + + + +Sparks Informational [Page 23] + +RFC 5057 Multiple Dialog Usages November 2007 + + + [1], especially those concerning the authenticity of requests and + processing of responses. + + Service implementations should carefully consider the effects on + their service of peers making different choices in these areas of + ambiguity. A service that requires multiple usages needs to pay + particular attention to the effect on service and network utilization + when a client fails to destroy a dialog the service believes should + be destroyed. A service that disallows multiple usages should + consider the effect on clients that, for instance, destroy the entire + dialog when only a usage should be torn down. In the worst case of a + service deployed into a network with a large number of misbehaving + clients trying to create multiple usages in an automated fashion, a + retry storm similar to an avalanche restart could be induced. + +8. Conclusion + + Handling multiple usages within a single dialog is complex and + introduces scenarios where the right thing to do is not clear. + Implementations should avoid entering into multiple usages whenever + possible. New applications should be designed to never introduce + multiple usages. + + There are some accepted SIP practices, including transfer, that + currently require multiple usages. Recent work, most notably GRUU, + makes those practices unnecessary. The standardization of those + practices and the implementations should be revised as soon as + possible to use only single-usage dialogs. + +9. Acknowledgments + + The ideas in this document have been refined over several IETF + meetings with many participants. Significant contribution was + provided by Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, + Jonathan Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the + reSIProcate project also shared their difficulties and discoveries + while implementing multiple-usage dialog handlers. + +10. Informative References + + [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [2] Levin, O., "Suppression of Session Initiation Protocol (SIP) + REFER Method Implicit Subscription", RFC 4488, May 2006. + + + + + +Sparks Informational [Page 24] + +RFC 5057 Multiple Dialog Usages November 2007 + + + [3] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) + Event Package for Key Press Stimulus (KPML)", RFC 4730, + November 2006. + + [4] Niemi, A., "Session Initiation Protocol (SIP) Extension for + Event State Publication", RFC 3903, October 2004. + + [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol + (SIP): Locating SIP Servers", RFC 3263, June 2002. + + [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + [8] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. + + [9] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent (UA) URIs (GRUU) in the Session Initiation Protocol + (SIP)", Work in Progress, June 2006. + + [10] Rosenberg, J., "Request Authorization through Dialog + Identification in the Session Initiation Protocol (SIP)", + RFC 4538, June 2006. + + [11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) + "Join" Header", RFC 3911, October 2004. + +Author's Address + + Robert J. Sparks + Estacado Systems + + EMail: RjS@estacado.net + + + + + + + + + + + + + + + +Sparks Informational [Page 25] + +RFC 5057 Multiple Dialog Usages November 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Sparks Informational [Page 26] + |