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 September 4, 2006.

Copyright Notice

Copyright © The Internet Society (2006).

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 RFC 4235.

Table of Contents

1.  Background
2.  Guidelines
    2.1.  Addressing
    2.2.  Status/Presence
    2.3.  Dialog Package Data
3.  Security Considerations
    3.1.  Access to All Information
    3.2.  Access to Busy/Not-busy Information
4.  Current Implementations
5.  Revision history
    5.1.  Changes from draft-worley-sipping-dialog-00 to draft-worley-sip-dialog-00
    5.2.  Changes from draft-worley-sip-dialog-00 to draft-worley-sip-dialog-01
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Background

SIP implements telephony and similar applications over the Internet. SIP largely conforms to the "end-to-end principle"[3] (Salzer, J., Reed, D., and D. Clark, “End-to-End Arguments in System Design,” November 1984.), 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[1] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.). 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.

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 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.

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

[1] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.) 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 [1] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.) 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. 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.

Guideline 4: 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 sub-element 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 [1] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.) 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.

initiator's identity:

the "From" header of the original INVITE

initiator's target:

the "Contact" header of the original INVITE, updated by any UPDATE or re-INVITE

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 the "To" header of the original INVITE

recipient's target:

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.

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 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:

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).

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 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.

4. Current Implementations

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.

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.)

6. References

6.1. Normative References

6.2. Informative References

Author's Address

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 © The Internet Society (2006). 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.