Sipping D. Worley Internet-Draft Pingtel Expires: April 7, 2006 October 4, 2005 Guidelines for Implementing the Dialog Event Package in User Agents draft-worley-sipping-dialog-00 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 April 7, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document sets out guidelines for how user agents should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. It is in addition to the basic requirements for dialog event package implementation in RFC 3265 and draft-ietf-sipping-dialog-package. Worley Expires April 7, 2006 [Page 1] Internet-Draft Guidelines for the Dialog Event Package October 2005 1. Background SIP implements telephony and similar applications over the Internet. SIP largely conforms to the "end-to-end princple"[1], putting the major responsibility for "call-control features" in the user agents (telephones) themselves, in constrast 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[2]. 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. Unfortnately, 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 within the standard are not usable for end-point call control (EPCC). It is the purpose of this memo 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. Worley Expires April 7, 2006 [Page 2] Internet-Draft Guidelines for the Dialog Event Package October 2005 2. Guidelines This section contains the guidelines for implementing high-quality dialog event packages, and a brief discussion of the motiviation for each guideline. 2.1. Addressing UAs accept requests bearing one of a set of request-URIs. Since the UA does not control which "host parts" of URIs can route to it; Guideline 1: A UA should not be sensitive to the host part of the request-URI in processing a request, as long as the host part resolves to specify the UA. Since a subscriber to the dialog event package may know only an AOR (address of record) to identify the UA with which it desires to communicate, the UA may have to route its SUBSCRIBE through a proxy via the AOR. The proxy will send the SUBSCRIBE to the registered contact URIs for that AOR. Guideline 2: A UA should accept SUBSCRIBEs to all URIs that it uses as contacts for AORs. 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 3: A SUBSCRIBE to a URI that the UA uses as a contact for an AOR should obtain dialog events that describe only INVITEs to that URI (and URIs that the UA treats as equivalent). 2.2. Status/Presence Attendant consoles and other status reporting devices sometimes want information about the status of a UA, rather than about all dialogs that were addressed to a particular AOR. Guideline 4: A UA should accept SUBSCRIBEs to URIs with a null "user". These subscriptions should report dialog events that describe all dialogs at the UA. 2.3. Dialog Package Data 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. Worley Expires April 7, 2006 [Page 3] Internet-Draft Guidelines for the Dialog Event Package October 2005 Guideline 5: 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. Guideline 6: The dialog event package should use the following sources for the following elements: initiator's identity: the "From" header of the INVITE initiator's target: the "Contact" header of the latest INVITE recipient's identity: the "To" header of the INVITE, or the "From" header that would be used when initiating a call from the "user" specified in the SUBSCRIBE recipient's target: the "Contact" header of the latest 2xx response to an INVITE Note that both Contact headers can be updated by re-INVITE and UPDATE requests during the dialog: Guideline 7: The data in the dialog event package should be updated when the contacts of the endpoints change. 2.4. Security Because an agent that knows a dialog's parameters has total control over the dialog, dissemination of that information should be restricted to trusted agents. (E.g., imagine the Jerkey 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 a specified IP address are trusted, or Worley Expires April 7, 2006 [Page 4] Internet-Draft Guidelines for the Dialog Event Package October 2005 B. only SUBSCRIBEs authorized by trusted keys are trusted. 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: Guideline 9: A UA receiving an untrusted SUBSCRIBE should reject it rather than providing an edited version (e.g., omitting the dialog identifiers and only providing the state). Worley Expires April 7, 2006 [Page 5] Internet-Draft Guidelines for the Dialog Event Package October 2005 3. Current Implementations This section compares the dialog event packages generated by five current, popular commercial UAs. The data was taken by a test tool from current products that claimed to implement the dialog event package. The first table (Table 1) lists the responses to SUBSCRIBEs and INVITEs to both the URI specifying the first "line number" supported by the UA and to the URI that gives the phone's IP address but no user. Only one of the five implementations will accept SUBSCRIBES to both URIs (Guidelines 2 and 4). Method/user combinations accepted: +--------+--------------+---------------+-------------+-------------+ | User | SUBSCRIBE to | SUBSCRIBE to | INVITE to | INVITE to | | Agent | Line 1 | no user | Line 1 | no user | +--------+--------------+---------------+-------------+-------------+ | A | 200 | 404 | 200 | 404 | | | | | | | | B | 200 | 404 | 200 | 404 | | | | | | | | C | 404 | 200 | 200 | 200 | | | | | | | | D | 200 | 200 | 200 | 200 | | | | | | | | E | 200 | 404 | 200 | 404 | +--------+--------------+---------------+-------------+-------------+ Table 1 The second table (Table 2) lists which INVITEs will be reported in the dialog event packages returned for which SUBSCRIBEs. Only one of the five UAs accepts all recommended SUBSCRIBEs, and it does not return all the dialogs specified by Guideline 4. Worley Expires April 7, 2006 [Page 6] Internet-Draft Guidelines for the Dialog Event Package October 2005 Which SUBSCRIBEs report which INVITEs: +-------+--------------+--------------+--------------+--------------+ | User | INVITE on | INVITE on | INVITE on no | INVITE on no | | Agent | Line 1, | Line 1, | user, | user, | | | SUBSCRIBE on | SUBSCRIBE on | SUBSCRIBE on | SUBSCRIBE on | | | Line 1 | no user | Line 1 | no user | +-------+--------------+--------------+--------------+--------------+ | A | Y | - | - | - | | | | | | | | B | Y | - | - | - | | | | | | | | C | - | Y | - | Y | | | | | | | | D | Y | N | N | Y | | | | | | | | E | Y | - | - | - | +-------+--------------+--------------+--------------+--------------+ "Y" means that the INVITE is reported for the SUBSCRIBE, "N" means that it is not, "-" means that the UA does not accept the INVITE or SUBSCRIBE Table 2 The third table (Table 3) lists the data items present in the dialog events generated by each UA. Four of the five UAs provide all of the dialog identifiers (Guideline 5), but the populating of the identity and target fields is quite weak (Guideline 6). Which data are present in the dialog events (for incoming calls): +------------+---------------+-----------+ | User Agent | Call-Id, Tags | Direction | +------------+---------------+-----------+ | A | N | N | | | | | | B | Y | Y | | | | | | C | Y | Y | | | | | | D | Y | Y | | | | | | E | Y | Y | +------------+---------------+-----------+ Table 3 Worley Expires April 7, 2006 [Page 7] Internet-Draft Guidelines for the Dialog Event Package October 2005 Which data are present in the dialog events (part 2): +----------+-------------+------------+---------------+-------------+ | User | Local | Local | Remote | Remote | | Agent | identity | target | identity | target | +----------+-------------+------------+---------------+-------------+ | A | - | - | - | - | | | | | | | | B | To | Contact | From | - | | | | | | | | C | - | To | Contact | - | | | | | | | | D | To | To | From | From | | | | | | | | E | To | Fixed | From | Contact | | | | value | | | +----------+-------------+------------+---------------+-------------+ "To" means value of the To header, "Contact" means value of the appropriate Contact header, "From" means value of the From header, "Fixed value" means a fixed string, "-" means no value 4. References [1] Salzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", RFC 2200, STD 1, November 1984. [2] Salzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", November 1984. Worley Expires April 7, 2006 [Page 8] Internet-Draft Guidelines for the Dialog Event Package October 2005 Author's Address Dale R. Worley Pingtel Corp. Worley Expires April 7, 2006 [Page 9] Internet-Draft Guidelines for the Dialog Event Package October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Worley Expires April 7, 2006 [Page 10]