SIP D. Worley Internet-Draft Pingtel Expires: August 14, 2007 February 10, 2007 Guidelines for Implementing the Dialog Event Package in User Agents draft-worley-sip-dialog-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 14, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Worley Expires August 14, 2007 [Page 1]
Internet-Draft Guidelines for the Dialog Event Package February 2007 Abstract This document sets out guidelines for how Session Initiation Protocol (SIP) user agents (UAs) should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. The guidelines are in addition to the basic requirements for dialog event package implementation in RFC 3265 and RFC 4235. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Status/Presence . . . . . . . . . . . . . . . . . . . . . 5 2.3. Dialog Package Data . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3.1. Access to All Information . . . . . . . . . . . . . . . . 7 3.2. Access to Busy/Not-busy Information . . . . . . . . . . . 7 4. Current Implementations . . . . . . . . . . . . . . . . . . . 8 5. Revision History . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Changes from draft-worley-sipping-dialog-00 to draft-worley-sip-dialog-00 . . . . . . . . . . . . . . . . 9 5.2. Changes from draft-worley-sip-dialog-00 to draft-worley-sip-dialog-01 . . . . . . . . . . . . . . . . 9 5.3. Changes from draft-worley-sip-dialog-01 to draft-worley-sip-dialog-02 . . . . . . . . . . . . . . . . 9 5.4. Changes from draft-worley-sip-dialog-02 to draft-worley-sip-dialog-03 . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Worley Expires August 14, 2007 [Page 2]
Internet-Draft Guidelines for the Dialog Event Package February 2007 1. Background The Session Initiation Protocol (SIP) [1] implements telephony and similar applications over the Internet. SIP largely conforms to the "end-to-end principle"[4], 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. This scheme for implementing call-control features is called EPCC, end-point controlled call control. 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[2][3]. A user agent can retrieve a second user agent's dialog event package to obtain the identifiers of the second user agent's dialogs, and using those identifiers, the first user agent 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. Worley Expires August 14, 2007 [Page 3]
Internet-Draft Guidelines for the Dialog Event Package February 2007 2. Guidelines This section contains the guidelines for implementing high-quality dialog event packages, and a discussion of the motivation for each guideline. 2.1. Addressing A potential 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 potential 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. In a third case, a potential subscriber knows of a URI that is a GRUU for the UA. GRUUs route through the proxy for a SIP domain (like AORs), but always route to only one UA (like contact URIs). 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. This guideline implies that a UA should use different contact addresses for every AOR for which it registers. Choosing contact addresses can be done in many ways. One method is to apply a URI- parameter with varying values to a base URI. The URI-parameter "x-line-id" is commonly used for this purpose. So the base URI <sip:ua1@10.1.1.1> can be used to generate the series of contact URIs: sip:ua1@10.1.1.1;x-line-id=a123 sip:ua1@10.1.1.1;x-line-id=a842 Worley Expires August 14, 2007 [Page 4]
Internet-Draft Guidelines for the Dialog Event Package February 2007 sip:ua1@10.1.1.1;x-line-id=0 Guideline 3: A SUBSCRIBE to a URI that the UA uses as a contact for a dialog or transaction should obtain dialog events that describe only INVITEs "for the AOR" that corresponds to that URI. 2.2. Status/Presence 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". 2.3. Dialog Package Data RFC 4235 [2] 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 [2] make its intended use clear: Guideline 4: 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 each dialog's identifiers. In addition, in order to be able to select the dialog that has been ringing the longest out of a set of early dialogs, the dialog event package needs to contain the duration element. (The state element is mandatory per [2].) Guideline 5: The dialog event package should include the call-id, local-tag, remote-tag, and direction attributes of the dialog element. It should include the duration and state sub-elements of the dialog element. Worley Expires August 14, 2007 [Page 5]
Internet-Draft Guidelines for the Dialog Event Package February 2007 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 [2] show the intended usage: Guideline 6: The dialog event package should use the following sources for the following elements: A. The local and remote elements are to report the initiator's or recipient's information, as determined by the direction attribute. B. initiator's identity: the "From" header of the original INVITE C. initiator's target: the "Contact" header of the original INVITE, as updated by any UPDATE or re- INVITE D. recipient's identity: 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 alternatively, the "To" header of the original INVITE E. recipient's target: the "Contact" header of the original 2xx response to the INVITE, as 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 7: The local and remote target elements in the dialog event package should be updated when the contacts of the endpoints change. Worley Expires August 14, 2007 [Page 6]
Internet-Draft Guidelines for the Dialog Event Package February 2007 3. Security Considerations 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. 3.1. Access to All Information 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 Jerky Boys subscribing to dialog events for your organization's customer service line.) Guideline 8: 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: A. 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 B. only SUBSCRIBEs authorized by appropriate keys are trusted (which requires a keying infrastructure). Guideline 9: 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. 3.2. Access to Busy/Not-busy Information 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 10: A UA should provide even edited versions of the dialog event package only to subscribers which pass a security/privacy policy, and not indiscriminately. Worley Expires August 14, 2007 [Page 7]
Internet-Draft Guidelines for the Dialog Event Package February 2007 4. Current Implementations Current implementation data has not been analyzed. Worley Expires August 14, 2007 [Page 8]
Internet-Draft Guidelines for the Dialog Event Package February 2007 5. Revision History 5.1. Changes from draft-worley-sipping-dialog-00 to draft-worley-sip-dialog-00 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. 5.2. Changes from draft-worley-sip-dialog-00 to draft-worley-sip-dialog-01 Add requirement for the duration element. Fix reference for "End-to-End Arguments in System Design". (Thanks to Elwyn Davies.) 5.3. Changes from draft-worley-sip-dialog-01 to draft-worley-sip-dialog-02 Update contact information. Add reference to RFC 3265. Use <list style='format Guideline %d:' counter='guidelines'> to number the guidelines automatically. Worley Expires August 14, 2007 [Page 9]
Internet-Draft Guidelines for the Dialog Event Package February 2007 Revised the Current Implementations section. 5.4. Changes from draft-worley-sip-dialog-02 to draft-worley-sip-dialog-03 Update contact information. Revised the Current Implementations section. Add discussion of the need for different contact URIs for different AORs and of the "x-line-id" URI parameter. Add discussion of GRUUs as contact addresses. Worley Expires August 14, 2007 [Page 10]
Internet-Draft Guidelines for the Dialog Event Package February 2007 6. References 6.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", June 2002. [2] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 6.2. Informative References [4] Salzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", ACM TOCS vol. 2, no. 4, pp. 277-288, November 1984. Worley Expires August 14, 2007 [Page 11]
Internet-Draft Guidelines for the Dialog Event Package February 2007 Author's Address Dale R. Worley Pingtel Corp. 400 West Cummings Park, Suite 2200 Woburn, MA 01801 US Phone: +1 781 938 5306 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires August 14, 2007 [Page 12]
Internet-Draft Guidelines for the Dialog Event Package February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Worley Expires August 14, 2007 [Page 13]