XCON Working Group C. Boulton Internet-Draft Avaya Intended status: Standards Track M. Barnes Expires: August 25, 2008 Nortel February 22, 2008 An XCON Client Conference Control Package for the Media Control Channel Framework draft-boulton-xcon-conference-control-package-02 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 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server Boulton & Barnes Expires August 25, 2008 [Page 1] Internet-Draft Conference Control Package February 2008 control, thus optimizing the implementation for some entities participating in an XCON system. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Control Package Detail . . . . . . . . . . . . . . . . . . . . 6 5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 6 5.2. Framework Message Usage . . . . . . . . . . . . . . . . . 6 5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 6 5.4. Control Message Bodies . . . . . . . . . . . . . . . . . . 6 5.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 6 5.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Boulton & Barnes Expires August 25, 2008 [Page 2] Internet-Draft Conference Control Package February 2008 1. Introduction As part of the Centralized Conferencing (XCON) work group in the IETF a Data Model[5] has been created for the purpose of modeling conference based services in a standard way. The XCON group also requires a standards based mechanism that will enable third party conference clients participating to interoperate with conference servers and manipulate conference parameters. The Media Control (MEDIACTRL) Work Group within the IETF has the explicit goal of creating an architecture and framework for controlling Media Servers. As part of this work a Control Channel Framework[7] has been created that is based on the Session Initiation protocol (SIP). It uses SIP to setup, maintain and terminate a reliable control channel for the purpose of exchanging control based interactions. The Control Framework provides an extension template for creating extensions that specify the semantic detail associated with the operations. The extension documents are known as Control Packages and an example is the 'Basic IVR Control Package'[8]. This document will specify a Control Package for Conference Control by participating clients using the SIP Control Framework. The Media Control Channel Framework provides the ideal mechanism for reliably exchanging control messages between a conference client and server. It provides inherent properties such as: o Reliable delivery of control messages. o Lightweight Protocol Data Units (PDU). o Linked asynchronous transactional mechanism. o Asynchronous event mechanism. The SIP Control Framework uses SIP as its overlying rendezvous mechanism. This provides all the inherent benefits like: o SIP Service Location - Use SIP Proxies or Back-to-Back User Agents for discovering Control Servers.. o SIP Security Mechanisms - Leverage established security mechanisms such as Transport Layer Security (TLS) and Client Authentication. o Connection Maintenance - The ability to re-negotiate a connection, ensure it is active, audit parameters, and so forth. o Agnostic - Allows for ease of extension. Not only is the Media Control Channel Framework an ideal mechanism for controlling conference instances by participating clients, it also provides the property of re-use by conferencing systems of functionality implemented for controlling Media Servers etc. This includes re-using the SIP stack for control channel setup as well as the Control Channel Framework stack for receiving/sending the PDUs Boulton & Barnes Expires August 25, 2008 [Page 3] Internet-Draft Conference Control Package February 2008 for multiple control packages in an XCON conference system. It should be noted that this mechanism is a complementary technology to that specified in the document 'A Centralized Conferencing Manipulation Protocol (CCMP)'[9]. In fact this specification simply re-uses the SOAP bindings created in that document for a consistent view (so just the transport mechanism is different). While the mechanism defined in [9] is ideal for certain network deployments (for example Service Orientated Architectures), it is important to offer an alternative access method for clients with non SOA based technologies. Using the SIP Control Framework provides consistency across both XCON and MEDIACTRL work groups. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Terminology This document reuses the terminology defined in the framework and data model for centralized conferencing [6]. In addition, the following acronyms and terms are used in this document: SOAP: Simple Object Access Protocol. WSDL: Web Services Description Language. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. 4. Overview The use of the Media Control Channel Framework offers an ideal mechanism for creating, deleting and manipulating XCON conference instances by participating clients. As the Control Channel Framework is a generic mechanism, this section provides non-normative detail showing how the Control Channel Framework can be applied to this particular use-case. In [6], two distinct roles are defined - A 'Control Client' and a 'Control Server'. Such roles are interchangeable between entities within a session depending on package requirements. A simple diagram is illustrated in Figure 1 Boulton & Barnes Expires August 25, 2008 [Page 4] Internet-Draft Conference Control Package February 2008 +--------------SIP Traffic--------------+ | | v v +-----+ +--+--+ | SIP | | SIP | |Stack| |Stack| +---+-----+---+ +---+-----+---+ | Control | | Control | | Client |<----Control Channel---->| Server | +-------------+ +-------------+ Figure 1: Basic Architecture The XCON Conference Control package will cast a participating XCON compliant User Agent that wishes to control a conference instance as a 'Control Client' as defined in the SIP Control Framework. It will have permission to generate and issue commands in CONTROL messages as defined in Section 5.2 of this document. It will also have the ability to receive responses to Conference Package CONTROL requests that are contained in either appropriate responses or subsequent REPORT messages, also specified in Section 5.2. The specific format of the conference control messages and responses are defined in Section 5.4 and Section 5.5. They re-use the format specified in CCMP[9]. This provides a common binding set with alternative access mechanism depending on client requirements. The previous diagram can be updated as illustrated in Figure 2. +--------------SIP Traffic--------------+ | | v v +-----+ +--+--+ | SIP | | SIP | |Stack| |Stack| +---+-----+---+ +---+-----+---+ | XCON | | XCON | | Control | | Conference | | Client |<----Control Channel---->| System | +-------------+ +-------------+ Figure 2: Conference Control Architecture Editor's Note: The Overview section will be expanded in later versions of the document. Boulton & Barnes Expires August 25, 2008 [Page 5] Internet-Draft Conference Control Package February 2008 5. Control Package Detail The Media Control Channel Framework defines rules that Control Package extensions must provide mandatory information as described in section 10 of [7]. This section fulfills the obligation. 5.1. Control Package Name The SIP Control Framework requires a Control Package definition to specify and register a unique package name. The name and version of this Control Package is "xcon-conf-control/1.0". 5.2. Framework Message Usage The Conference Control package uses the SOAP WSDL [2] defined in CCMP[9]. To maintain the consistency with the design of the WSDL the SIP Control Framework messages will be applied in a similar manner. The CONTROL message will be used to contain requests that enable conference manipulation - as specified in Section 5.4 and can only travel from the client to a Conferencing System. Responses, as specified in Section 5.5, can only travel from the Conferencing System to an expectant client. Depending on the time it takes to process the request (as specified in [7]), responses can either be contained in a Control Framework 200 response or subsequent REPORT method. 5.3. Common XML Support The Control Framework requires a Control Package definition to specify if the attributes for media dialog or conference references are required. This package requires that the XML Schema in Section 16.1 of [7] MUST NOT be supported for media dialogs and conferences. EDITOR'S NOTE: This document could make use of the Conf common schema TBD. 5.4. Control Message Bodies A valid CONTROL body message MUST conform to the WSDL defined in [9]. To be precise, the CONTROL message body MUST comply only to the 'input' element of the WSDL portType (CCMPPortType). 5.5. REPORT Message Bodies A valid CONTROL body message MUST conform to the WSDL defined in [9]. To be precise, the REPORT message body MUST comply only to the Boulton & Barnes Expires August 25, 2008 [Page 6] Internet-Draft Conference Control Package February 2008 'output' element of the WSDL portType (CCMPPortType). 5.6. Examples TODO 6. IANA Considerations TODO 7. Security Considerations Access to conference control functionality needs to be tightly controlled to avoid attackers disrupting conferences, adding themselves to conferences or engaging in theft of services. The Framework for Centralized Conferencing [6] specifies that the protocols used for manipulation and retrieval of confidential information MUST support a confidentiality and integrity mechanism. To support the confidentiality and integrity requirements, all conference control information included in the package defined in this document SHOULD be carried over TLS. Editor's Note: once the security requirements for the control packages are further specified in the Control Framework for SIP [7] additional information may be added to this section. There are also security issues associated with the authorization to perform actions on the conferencing system to invoke specific capabilities. Implementers SHOULD deploy standard SOAP authentication and authorization mechanisms to ensure that only authorized entities are able to manipulate the data. 8. Acknowledgments 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Boulton & Barnes Expires August 25, 2008 [Page 7] Internet-Draft Conference Control Package February 2008 Language", W3C CR CR-wsdl20-20051215, December 2005. [3] Hadley, M., Gudgin, M., Nielsen, H., Mendelsohn, N., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-20030624, June 2003, . [4] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium FirstEdition REC-soap12-part2-20030624, June 2003, . 9.2. Informative References [5] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-08 (work in progress), December 2007. [6] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", draft-ietf-xcon-framework-10 (work in progress), November 2007. [7] Boulton, C., "A Control Framework for the Session Initiation Protocol (SIP)", draft-boulton-sip-control-framework-05 (work in progress), February 2007. [8] Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)", draft-boulton-ivr-control-package-05 (work in progress), November 2007. [9] Barnes, M., "Centralized Conferencing Manipulation Protocol", draft-barnes-xcon-ccmp-03 (work in progress), November 2007. Authors' Addresses Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@avaya.com Boulton & Barnes Expires August 25, 2008 [Page 8] Internet-Draft Conference Control Package February 2008 Mary Barnes Nortel 2380 Performance Drive Richardson, TX Email: mary.barnes@nortel.com Boulton & Barnes Expires August 25, 2008 [Page 9] Internet-Draft Conference Control Package February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Boulton & Barnes Expires August 25, 2008 [Page 10]