SIPPING S. Olson Internet-Draft Microsoft Expires: December 21, 2003 June 22, 2003 Extensions to the Dialog event package for Third Party Call Control draft-olson-sipping-dialog-package-extensions-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 December 21, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines extensions to the dialog event package and corresponding application/dialog-info+xml MIME type for the purpose of third-party call control. Olson Expires December 21, 2003 [Page 1] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. A Filter for the dialog event package . . . . . . . . . . . . 6 4.1 XML schema for the filter . . . . . . . . . . . . . . . . . . 6 4.2 Example filters . . . . . . . . . . . . . . . . . . . . . . . 8 5. Extending application/dialog-info+xml . . . . . . . . . . . . 10 5.1 The replaces element . . . . . . . . . . . . . . . . . . . . . 10 5.2 The referred-by element . . . . . . . . . . . . . . . . . . . 11 5.3 The local-target element . . . . . . . . . . . . . . . . . . . 12 5.4 The local-media-state and remote-media-state elements . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1 application/dialog-filter-qbe+xml MIME Registration . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Olson Expires December 21, 2003 [Page 2] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Olson Expires December 21, 2003 [Page 3] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 2. Introduction The dialog event package [4] defines a mechanism for monitoring the progress of INVITE dialogs involving a specific user through a subscription to that dialog state. The package allows for monitoring all dialogs for that user or a specific dialog identified by Call-ID and local and remote tags. Currently undefined is a mechanism for finer grained filtering of the dialogs for which state is provided. The state of a dialog is conveyed with respect to a finite state machine (FSM) defined in the Internet-Draft. This FSM reflects the transition from the initial INVITE, to a 100 Trying response, to a 1xx response, through a final response (2xx). The application/ dialog-info+xml MIME type defines additional attributes that augment this FSM state. Still, there is important information not immediately conveyed by the dialog event package. This missing information represents additional context for a dialog which helps the watcher determine which dialogs are interesting and which are not from the perspective of call control and advanced services [5]. It is the intention of this document to address these issues by: o defining an XML based MIME type for filtering notifications for the dialog event o extending application/dialog-info+xml with new attributes and elements to provide additional context information Olson Expires December 21, 2003 [Page 4] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 3. Use Cases The use cases of interest include the following: 1. The dialog event watcher wishes to be informed of all dialog state related to dialogs which match a given remote URI 2. The dialog event watcher wishes to know which dialogs are part of a larger conference 3. The dialog event watcher wishes to know when a dialog goes "on hold". "On hold" refers to the situation where the two parties of the dialog are not actively engaged in communication. This information is valuable feeback for the UA which is responsible for placing the dialog "on hold". It is also an indication that the "on hold" party may be available for communication. 4. The dialog event watcher wishes to know which dialogs are part of a call transfer operation 5. The dialog event watcher wishes to know the relationship between a new dialog and the dialog which it is replacing Olson Expires December 21, 2003 [Page 5] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 4. A Filter for the dialog event package This memo defines a new MIME type (application/dialog-filter-qbe+xml) which is intended to be placed in the body of a SUBSCRIBE request for the dialog event package to serve as filter criteria for limiting the list of dialogs which are returned in subsequent NOTIFYs. It is expected that SIP devices which support this event package will also support more advanced conferencing and media services. Therefore, it will not be unusual for a given device to be a participant in many simultaneous INVITE dialogs of various types. This is the rationale behind providing a filtering ability at the subscription target rather than doing filtering at the watcher. One goal of this filtering is to reduce network traffic associated with these NOTIFYs. Another goal is to simplify the implementation of advanced services by allowing watchers to focus on a narrow subset of the dialogs associated with a user. The filter is specified in a query-by-example format. The subscriber specifies the remote URI, Call-ID, state, tags, etc. of interest and omits any element which it does not need to match explicitly (a "don't care" condition). Any element or attribute included in the filter which is not understood by the receiving UA MUST be ignored. The filter is composed of a sequence of one or more elements. Each element in the filter represents one filter criteria. The entire filter is the logical "or" of all of these criteria. Negation is not supported. The filter can be present in any SUBSCRIBE or re-SUBSCRIBE during the life of the subscription. The current filter is replaced (not ammended) by filters in subsequent SUBSCRIBE requests. A subsequent SUBSCRIBE lacking any filter removes the currently active filter. The filter is not persisted across subscriptions and is specific to the subscription dialog. Multiple subscriptions between two UAs may have independent filters. This memo does not define any mechanism for querying the currently active filter. Consequently, no versioning scheme is defined for these filters. A UA receiving a filter format which it does not understand or honor MUST return a 415 error response. 4.1 XML schema for the filter XML Schema for application/dialog-filter-qbe+xml Olson Expires December 21, 2003 [Page 7] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 4.2 Example filters Example 1: Filtering for all dialogs with a specified URI sip:helpdesk@tradewind.com Olson Expires December 21, 2003 [Page 8] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 Example 2: Filtering for all inbound dialogs Example 3: Filtering for dialogs that share a given Call-ID or which are to a given URI sip:conf-factory@tradewind.com Example 4: Filtering for all dialogs in the trying, proceeding, or early states trying early proceeding Example 5: Filtering for a specific dialog Olson Expires December 21, 2003 [Page 9] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 5. Extending application/dialog-info+xml There are three extensions proposed to the XML schema for the application/dialog-info+xml MIME type: An extension to indicate that a dialog is being established to replace another existing dialog An extension to indicate that a dialog is being established as a result of a refer request An extension to indicate the local Contact information for a dialog analogous to "remote-target" All of these extensions are intended to make it easier to correlate dialog information with actions such as blind and consultative transfer as well as multiparty conferencing. 5.1 The replaces element The element is a proposed new child of the element. The purpose is to capture the information of the Replaces headers [6] including the Call-ID, local tag, and remote tag of the dialog which this new dialog is intended to replace. Example of element in dialog-info confirmed proceeding Schema for element in dialog-info Olson Expires December 21, 2003 [Page 10] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 5.2 The referred-by element The element is a proposed new child of the element containing the name-addr of the source of the REFER which caused the creation of that dialog. The purpose of this element is to signal that a dialog was created as part of a call transfer and to identify the source of that transfer operation. The referred-by element SHOULD be included whenever an INVITE dialog is established in response to a REFER request. Example of element in dialog-info early helpdesk@tradewind.com Schema for element in dialog-info Olson Expires December 21, 2003 [Page 11] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 5.3 The local-target element The element is a proposed child element of the element. Its purpose and construction are similar to the remote-target element defined today. The local-target is intended to carry the local-target URI for this UA for this dialog as defined by SIP [2]. The local-target should be present whenever the remote-target element is present. The local-target (and remote-target) should be updated whenever a target refresh operation occurs for this dialog. The primary goal of conveying this information is to capture uniquely identifying information for dialogs which are part of a larger conference (such as the conference URI). Example of element in dialog-info early sip:conf-2342342@conf-factory.tradewind.com sip:conf-leader@b.tradewind.com Schema for element in dialog-info Olson Expires December 21, 2003 [Page 12] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 5.4 The local-media-state and remote-media-state elements The elements are proposed children of the element. Their purpose is to convey the current directionality of media and consequently the level of participation of each party in the dialog. This information corresponds to the "sendonly", "sendrecv", "recvonly", and "inactive" attributes of SDP [7] and their usage as defined in RFC 3264 [3]. The default value for these elements in their absence is "sendrecv". Note that for backwards compatibility, a SDP connection address of "0.0.0.0" is to be interpreted and relayed as a media-state of "inactive". Example of element in dialog-info confirmed sendonly inactive Schema for element in dialog-info Olson Expires December 21, 2003 [Page 13] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 Olson Expires December 21, 2003 [Page 14] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 6. IANA Considerations 6.1 application/dialog-filter-qbe+xml MIME Registration MIME media type name: application MIME subtype name: dialog-filter-qbe+xml Mandatory parameters: none Optional parameters: Same as charset parameter for application/xml as specified in RFC 3023 [8] Encoding considerations: Same as encoding considerations for application/xml as specified in RFC 3023 [8] Security considerations: See section 10 of RFC 3023 [8] Interoperability considerations: none Published specification: this document Applications which use this media type: Conference calling and advanced services built using SIP Additional Information: Magic Number: none File extension: .xml Macintosh file type code: "TEXT" Personal and email address for further information: Sean Olson Intended usage: COMMON Author/Change controller: The IETF. Olson Expires December 21, 2003 [Page 15] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 7. Security Considerations The element is subject to the same security implications as a Referred-By header in a REFER request. Further investigation is necessary to determine how best to address this security concern. Namely, should the referred-by element contain an AIB or perhaps use xmlsig to integrity protect the information? Or should the entire dialog-info XML document be secured using S/ MIME when a referred-by element is present? Olson Expires December 21, 2003 [Page 16] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP", draft-ietf-sipping-dialog-package-01 (work in progress), March 2003. [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-00 (work in progress), April 2003. [6] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03 (work in progress), March 2003. [7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. Author's Address Sean Olson Microsoft One Microsoft Way Redmond, WA 98052 US Phone: +1-425-707-2846 EMail: seanol@microsoft.com URI: http://www.microsoft.com/rtc Olson Expires December 21, 2003 [Page 17] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Olson Expires December 21, 2003 [Page 18] Internet-Draft Extensions to the Dialog event package for Third Party Call Control June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Olson Expires December 21, 2003 [Page 19]