Multiple Dialog Usages in the Session Initiation Protocol
RFC 5057
Document | Type | RFC - Informational (November 2007; No errata) | |
---|---|---|---|
Author | Robert Sparks | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5057 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jon Peterson | ||
Send notices to | (None) |
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 newShow full document text