XCON O. Levin Internet-Draft Microsoft Corporation Expires: June 1, 2005 December 2004 Centralized Conference Data Model draft-levin-xcon-cccp-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 June 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document is a part of a suite of protocols being developed in the XCON Working Group and defines a client-server Centralized Conferencing Control Protocol (CCCP) for query, creation, and manipulation of both the XCON system information (e.g. supported templates) and a particular conference information during the conference lifetime cycle (e.g. reservation and state). An XCON server, which implements a CCCP server, provides the means for authorized CCCP clients (e.g. conference participants) to affect the Levin Expires June 1, 2005 [Page 1] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 behavior of a conference in the XCON system. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Transaction Model and Operations . . . . . . . . . . . . . . . 4 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 System Primitives . . . . . . . . . . . . . . . . . . . . 5 6.1.1 getTemplates . . . . . . . . . . . . . . . . . . . . . 5 6.1.2 getReservedConferences . . . . . . . . . . . . . . . . 6 6.1.3 getActiveConferences . . . . . . . . . . . . . . . . . 6 6.2 Conference Primitives . . . . . . . . . . . . . . . . . . 6 6.2.1 addConference . . . . . . . . . . . . . . . . . . . . 6 6.2.2 getConference . . . . . . . . . . . . . . . . . . . . 6 6.2.3 deleteConference . . . . . . . . . . . . . . . . . . . 6 6.3 User Primitives . . . . . . . . . . . . . . . . . . . . . 6 6.3.1 addUser . . . . . . . . . . . . . . . . . . . . . . . 6 6.3.2 getUser . . . . . . . . . . . . . . . . . . . . . . . 7 6.3.3 deleteUser . . . . . . . . . . . . . . . . . . . . . . 7 6.4 Endpoint Primitives . . . . . . . . . . . . . . . . . . . 7 6.4.1 addEndpoint . . . . . . . . . . . . . . . . . . . . . 7 6.4.2 getEndpoint . . . . . . . . . . . . . . . . . . . . . 7 6.4.3 deleteEndpoint . . . . . . . . . . . . . . . . . . . . 7 6.5 Media Primitives . . . . . . . . . . . . . . . . . . . . . 7 6.5.1 addMedia . . . . . . . . . . . . . . . . . . . . . . . 7 6.5.2 getMedia . . . . . . . . . . . . . . . . . . . . . . . 7 6.5.3 deleteMedia . . . . . . . . . . . . . . . . . . . . . 7 6.5.4 modifyMediaStatus . . . . . . . . . . . . . . . . . . 8 6.6 Stimulus Primitives . . . . . . . . . . . . . . . . . . . 8 7. The XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 12.2 Informative References . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 Levin Expires June 1, 2005 [Page 2] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 1. Introduction General centralized conferencing architecture is described in the SIPPING Conference Framework [3]. The XCON Framework [4] defines how this architecture can be realized by an XCON compliant system. The XCON framework defines the concepts of the conference policy and the conference information as the top data objects for representing a conference. This document is a part of a suite of protocols being developed in the XCON Working Group and defines a client-server Centralized Conferencing Control Protocol (CCCP) for query, creation, and manipulation of both the XCON system information (e.g. supported templates) and a particular conference information during the conference lifetime cycle (e.g. reservation and state). An XCON server, which implements a CCCP server, provides the means for authorized CCCP clients (e.g. conference participants) to affect the behavior of a conference in the XCON system. 2. Terminology 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. General CCCP can be used to modify any of the conference information objects defined in the XCON Framework document [5]. These include the conference template, reservation, and state. Whenever reasonable, same CCCP primitives are used to access conference information during different stages of the conference life cycle. In order to distinguish between reservation and possible multiple instances of the same conference different URIs are used for each. Editor's Note: URI conventions or parameters TBD in the XCON Framework [4]. CCCP uses the conference information schema type and its sub-types (as defined in the SIPPING Conference Package [2]) for construction of the CCCP data objects. It is expected that additional sub-types will be introduced by XCON in order to express extended conferencing information relevant to XCON-compliant systems. Levin Expires June 1, 2005 [Page 3] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 4. Transaction Model and Operations CCCP MUST run over a reliable transport protocol. CCCP is agnostic to the details of the transport protocol being used beneath and does not rely on any information being conveyed on the transport level only. CCCP is a transaction client-server protocol. Two types of operations are defined with CCCP : request and response. A client issues requests to a server. The server MAY reply with multiple provisional responses before replying with the final response. Currently a single provisional response "pending" is defined. Editor's Note: Timeout behavior TBD. The server MUST reply with a single final response. Two final responses are defined: "failure" and "success". Each CCCP response and each CCCP request carries the following attributes: 'requestId', 'from', 'to', and optionally 'aaId'. The combination of the 'requestId', 'from' and 'to' attributes in the request and in the response constitutes the CCCP transaction ID: requestId: A string generated by the CCCP client and unique for each CCCP request generated by the client. from: A URI which identifies the CCCP client. to: A URI which identifies the CCCP server. Note that 'to' is mandatory but is not used in order to uniquely identify a particular transaction. The 'aaId' attribute holds a secured identity of the issuer of the CCCP request. Its value is being used by the CCCP server for authorization purposes. Multiple primitives can be included in a single CCCP operation (i.e. in a request and a corresponding response). The primitives within the request operation MUST be performed by the CCCP server one-by-one in the order they appear in the request body. The corresponding response operation MUST include the response primitive for each of the issued primitives in the exact same order. Note, that for this reason, the primitives inside the operation bodies are not numbered. Multiple primitives within the same request MUST be executed as an Levin Expires June 1, 2005 [Page 4] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 atomic operation. It means that if one primitive fails, the state of the object MUST be rolled back to its previous state, i.e. before the request had been processed. 5. Data Model The CCCP operations can be issued on the conference template, conference reservation, and any of the conference instance data objects. All these data objects are expressed in terms of conference-info-type defined in SIPPING Conference Package [2]. Consequently, CCCP requests are expressed using the same conference-info type and its sub-types whenever it makes sense. The information included in the request expresses the desired data object state to be achieved after the operation is successfully completed. The considerations listed below MUST be taken into account when using the schema with CCCP. Attributes 'state' and 'version' of the conference-info-type and its sub-types are never used with CCCP. The primitives' definition allows for inclusion of any element defined by the conference-info-type and its sub-types. Note that it is optional to include these elements by both the client and the server and their processing is optional by the receiving side, unless explicitly stated otherwise in the normative description of the CCCP primitives in Section 6. For example, when adding or creating objects (e.g. a conference, a user, an endpoint, a media, etc.) the client MUST include only the information that is required for the object creation. The client MUST assume that the Server MAY return new dynamically generated information in a successful response. On the other hand, the Server MAY return minimum information in the response or even an empty element corresponding to a successful request. CCCP allows the inclusion of richer information that can be displayed to a user or be logged in by the system, but doesn't mandate to always include this information in the response. 6. Primitives 6.1 System Primitives 6.1.1 getTemplates Get the list of template identifiers supported by the system. Levin Expires June 1, 2005 [Page 5] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 XML TBD. 6.1.2 getReservedConferences Get the list of reservation identifiers allocated by the system. XML TBD. 6.1.3 getActiveConferences Get the list of conference identifiers of active instances running in the system. XML TBD. 6.2 Conference Primitives 6.2.1 addConference Create a conference. The conference can be a new template, new reservation, or a new ad-hoc instance. For XML definition see Section 7. The 'conferenceEntity' value in the request is a client's suggestion only. The CCCP server can replace the suggested value with a different 'conferenceEntity' value in the corresponding response. 6.2.2 getConference For XML definition see Section 7. 6.2.3 deleteConference For XML definition see Section 7. 6.3 User Primitives 6.3.1 addUser For XML definition see Section 7. The Client MUST provide the 'userEntity' value in the request. If the client doesn't care (and/or) doesn't know the 'endpointEntity' value, it must populate it with the value equal to the 'userEntity'. The client MUST expect to receive in the successful response a real value of the 'endpointEntity'. Levin Expires June 1, 2005 [Page 6] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 6.3.2 getUser For XML definition see Section 7. 6.3.3 deleteUser For XML definition see Section 7. 6.4 Endpoint Primitives 6.4.1 addEndpoint For XML definition see Section 7. The Client MUST provide a valid 'endpointEntity' value in the request. 6.4.2 getEndpoint For XML definition see Section 7. 6.4.3 deleteEndpoint For XML definition see Section 7. 6.5 Media Primitives 6.5.1 addMedia The 'mediaId' value in the request is ignored by the CCCP server. The CCCP server MUST replace the value with the real 'media-id' value in the corresponding response. 6.5.2 getMedia This operation is used to get the description of a media stream of a participant in the conference. For XML definition see Section 7. 6.5.3 deleteMedia This operation is used to remove a media stream from a participant in the conference. For XML definition see Section 7. Levin Expires June 1, 2005 [Page 7] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 6.5.4 modifyMediaStatus This operation can be used for muting and un-muting media streams. For XML definition see Section 7. 6.6 Stimulus Primitives This operation is used to convey opaque pre-defined requests from a CCCP client to a CCCP server. XML TBD. 7. The XML Levin Expires June 1, 2005 [Page 8] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 9] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 10] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 11] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 12] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 13] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 15] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Levin Expires June 1, 2005 [Page 16] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 8. Example In order to illustrate the CCCP syntax, the example below shows all possible primitives issued in a single request and the corresponding answers are included in a single response. In this case all the primitives are executed as a single atomic operation. EditorĘs Note: In the next version of this document the example will be split into separate operations with clear semantics for each. 8.1 Request Agenda: This month's goals tel:+18005671234 TTI Bridge http://sharepoint/salesgroup/ web-page any 52 participant 50 audio Levin Expires June 1, 2005 [Page 17] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 video Bob Hoskins Bob's Laptop dialed-out main audio audio Levin Expires June 1, 2005 [Page 18] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Bob's Laptop dialed-out main audio audio main audio audio Bob Hoskins Levin Expires June 1, 2005 [Page 19] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 recvonly 8.2 Response Agenda: This month's goals tel:+18005671234 TTI Bridge http://sharepoint/salesgroup/ web-page any 52 participant 50 audio video Levin Expires June 1, 2005 [Page 20] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Agenda: This month's goals tel:+18005671234 TTI Bridge http://sharepoint/salesgroup/ web-page any 52 participant 50 audio video Levin Expires June 1, 2005 [Page 21] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Bob Hoskins Bob's Laptop dialed-out main audio audio Bob's Laptop dialed-out Levin Expires June 1, 2005 [Page 22] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 main audio audio main audio audio main audio audio main audio audio Bob Hoskins Levin Expires June 1, 2005 [Page 23] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 recvonly 9. IANA Considerations TBD. 10. Security Considerations TBD. 11. Acknowledgements The author would like to thank Gur Kimchi for his earlier work that served as the starting point for this specification. 12. References 12.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-08 (work in progress), December 2004. 12.2 Informative References [3] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [4] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencingg", draft-barnes-xcon-framework-01 (work in progress), December 2004. Levin Expires June 1, 2005 [Page 24] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 Author's Address Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: oritl@microsoft.com Levin Expires June 1, 2005 [Page 25] Internet-Draft Centralized Conference Control Protocol (CCCP) December 2004 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 (2004). 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. Levin Expires June 1, 2005 [Page 26]