Guidelines for Implementing the Dialog Event Package in User Agents

SIP implements telephony and similar applications over the Internet. SIP largely conforms to the "end-to-end principle", putting the major responsibility for "call-control features" on the user agents (telephones) themselves, in contrast to traditional telephony, where the intelligence is concentrated in a small number of centralized switches. In order for a user agent to interact with dialogs (calls) that are present on other user agents, those user agents must publish the state of the dialogs in which they are participating in a dialog event package. A user agent can retrieve another user agent's dialog event package to obtain the identifiers of the second user agent's dialogs, and using those identifiers, it can manipulate those dialogs. Unfortunately, the dialog event package was specified before the breadth of its importance was fully understood, so its specification is relatively loose. Loose enough that many implementations conforming to the standard are not usable for end-point call control (EPCC). It is the purpose of this document to provide a specification of the dialog event package that is tight enough to ensure that a user agent can fully participate in current and future EPCC operations. This document is not intended to advance toward standardization. However, if it proves valuable to implementors, it may evolve into a statement of best common practice.

This section contains the guidelines for implementing high-quality dialog event packages, and a discussion of the motivation for each guideline.

A subscriber to the dialog event package will often know only an AOR (address of record) to identify the UA with which it desires to communicate, so the subscriber will have to route its SUBSCRIBE through a proxy for the AOR. The proxy will route the SUBSCRIBE to the registered contact URIs for that AOR. Alternatively, a subscriber may know of a contact URI that the UA has used within a transaction or dialog. Contact URIs may route directly to the UA. Guideline 1: A UA should accept SUBSCRIBEs to all URIs that it uses as contacts for AORs, and all URIs that it uses as contacts in transactions or dialogs. A single UA may have contacts for multiple AORs, some of which may have contacts at other UAs. So dialog events "for an AOR" should only contain information about dialogs that were somehow addressed to that AOR. Guideline 2: A SUBSCRIBE to a URI that the UA uses as a contact for an AOR should obtain dialog events that describe only INVITEs "for the AOR" that corresponds to that URI.

Attendant consoles and other status reporting devices sometimes want information about the status of a UA as a whole (and thus implicitly its user's status), rather than about all dialogs that were addressed to a particular AOR. It would be desirable if there was a way to subscribe to events for all dialogs on a UA, but there seems to be no way for the UA to disseminate such a URI, and no standardized way to construct one. Perhaps a parameter on the request URI, or a parameter on the event package name in the Event header, could be used to indicate a desire for information for the entire UA. The concept of such a subscription raises the question of "What are all the URIs for a UA?", since the UA may not be a discrete physical object. The concept of to "URIs being lines on the same UA" doesn't seem to be intrinsic to SIP. Perhaps the set of contact URIs that share a +sip.instance value should be considered to comprise "a UA".

does not define what is to be considered the "resource" that is the subject of a dialog event subscription, and thus, what is to be the value of the entity attribute of the dialog-info element. But the examples in make its intended use clear: Guideline 3: The entity attribute of the dialog-info element should contain the AOR corresponding to the contact URI that was the request-URI of the SUBSCRIBE establishing the subscription. In order to implement EPCC, the dialog event package needs to contain enough information to allow the subscriber to construct requests (REFER, INVITE with Replaces, etc) that can operate on the dialog. Guideline 4: The dialog event package should include the call-id, local-tag, remote-tag, and direction attributes of the dialog element. In order to allow a variety of EPCC functions, the data in the dialog event package needs to comprehensively describe the dialog's endpoints in a standard way. The examples in show the intended usage: Guideline 5: The dialog event package should use the following sources for the following elements: The local and remote elements are to report the initiator's or recipient's information, as determined by the direction attribute. the "From" header of the original INVITE the "Contact" header of the original INVITE, updated by any UPDATE or re-INVITE the "From" header that would be used when initiating a call from the AOR corresponding to the request-URI as seen by the recipient, or the "To" header of the original INVITE the "Contact" header of the original 2xx response to the INVITE, updated by any UPDATE or re-INVITE Note that both Contact headers can be updated by re-INVITE and UPDATE requests during the dialog: Guideline 6: The target elements in the dialog event package should be updated when the contacts of the endpoints change.

Privacy and security considerations suggest that different components of the dialog package should be accessible to different subscribers. At a minimum, three levels of access can be distinguished: all dialog information, busy/not-busy information, and no information. Further work is needed to determine appropriate levels of access and how to restrict each level of access to the appropriate subscribers.

Because an agent that knows a dialog's parameters has total control over the dialog, dissemination of the parameters should be restricted to trusted agents. (E.g., imagine the Jerkey Boys subscribing to dialog events for your organization's customer service line.) Guideline 7: A UA should have a way of restricting dialog information to trusted subscribers. A UA should provide one of the following methods to determine which subscribers are trusted: only SUBSCRIBEs coming directly from specified IP address(es) are trusted (which delegates security decisions to the SIP agent(s) at those address(es)), or only SUBSCRIBEs authorized by appropriate keys are trusted (which requires a keying infrastructure). If method A is used, an additional mechanism may be needed for the SIP agent(s) which make the security decisions to communicate to the UA the level of disclosure to be made by the subscription.

Untrusted SUBSCRIBEs may come from any place on the Internet. Because the dialog event package provides presence information even if the dialog identifiers are removed, and presence information has privacy implications: Guideline 8: A UA should provided even edited versions of the dialog event package (e.g., omitting the dialog identifiers and only providing the state) only to subscribers which pass a security/privacy policy, and not indiscriminately.

The information in this section of the previous version of this document was collected at SIPit 17, which was held in September 2005. As most UA software has been updated since then, the information gathered there is now obsolete. This section will be revised once current information is collected.

Changed document name base from "draft-worley-sipping-dialog" to "draft-worley-sip-dialog" since the dialog event package now is an RFC and is now a SIP WG responsibility. Add a statement regarding the intended future of this draft. Narrowed the URIs that a UA must accept to contacts that it has registered or used in transactions, since a subscriber cannot reliably guess at any other URI. (Thanks to Michael Procter.) Added a discussion of the open question of how to subscribe to information about all the dialogs on a single UA. (Thanks to Michael Procter.) Added guideline on correspondence between the SUBSCRIBE request-URI and the entity attribute. Renumbered the guidelines. Removed information on current implementations. Start correcting reference for "End-to-End Arguments in System Design". Various edits to improve clarity.