XCON O. Levin
Internet-Draft Microsoft Corporation
Expires: August 24, 2005 R. Even
Polycom
P. Hagendorf
RADVISION
February 20, 2005
Centralized Conference Data Model
draft-levin-xcon-cccp-02
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 August 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
Levin, et al. Expires August 24, 2005 [Page 1]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Transaction Model and Operations . . . . . . . . . . . . . . . 5
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1 System Primitives . . . . . . . . . . . . . . . . . . . . 7
6.1.1 getTemplates . . . . . . . . . . . . . . . . . . . . . 7
6.1.2 getReservedConferences . . . . . . . . . . . . . . . . 7
6.1.3 getActiveConferences . . . . . . . . . . . . . . . . . 7
6.2 Conference Primitives . . . . . . . . . . . . . . . . . . 7
6.2.1 addConference . . . . . . . . . . . . . . . . . . . . 7
6.2.2 getConference . . . . . . . . . . . . . . . . . . . . 7
6.2.3 deleteConference . . . . . . . . . . . . . . . . . . . 7
6.3 User Primitives . . . . . . . . . . . . . . . . . . . . . 7
6.3.1 addUser . . . . . . . . . . . . . . . . . . . . . . . 7
6.3.2 getUser . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.3 deleteUser . . . . . . . . . . . . . . . . . . . . . . 8
6.4 Endpoint Primitives . . . . . . . . . . . . . . . . . . . 8
6.4.1 addEndpoint . . . . . . . . . . . . . . . . . . . . . 8
6.4.2 getEndpoint . . . . . . . . . . . . . . . . . . . . . 8
6.4.3 deleteEndpoint . . . . . . . . . . . . . . . . . . . . 8
6.5 Media Primitives . . . . . . . . . . . . . . . . . . . . . 8
6.5.1 addMedia . . . . . . . . . . . . . . . . . . . . . . . 8
6.5.2 getMedia . . . . . . . . . . . . . . . . . . . . . . . 8
6.5.3 deleteMedia . . . . . . . . . . . . . . . . . . . . . 9
6.5.4 modifyMediaStatus . . . . . . . . . . . . . . . . . . 9
6.6 Stimulus Primitives . . . . . . . . . . . . . . . . . . . 9
7. The XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1 Normative References . . . . . . . . . . . . . . . . . . . 26
12.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Levin, et al. Expires August 24, 2005 [Page 2]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
Intellectual Property and Copyright Statements . . . . . . . . 28
Levin, et al. Expires August 24, 2005 [Page 3]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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, et al. Expires August 24, 2005 [Page 4]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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.
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".
The following reasons for failure are defined:
serverBusy with optional retryAfter
timeout performing operation
unauthorized
requestMalformed
requestTooLarge
Each CCCP response and each CCCP request carries the following
attributes: 'requestId', 'from', and 'to'.
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.
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
Levin, et al. Expires August 24, 2005 [Page 5]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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
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
Levin, et al. Expires August 24, 2005 [Page 6]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
6.1 System Primitives
6.1.1 getTemplates
Get the list of template identifiers supported by the system.
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 conference
"blueprint", 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.
Levin, et al. Expires August 24, 2005 [Page 7]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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'.
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.
Levin, et al. Expires August 24, 2005 [Page 8]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
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.
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
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cccp" xmlns:tns="urn:ietf:params:xml:ns:cccp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:cccp" elementFormDefault="qualified" attributeFormDefault="unqualified">
<!--
This import brings in the XML language attribute xml:lang
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
<!--
CONFERENCE REQUEST ELEMENT
-->
<xs:element name="request" type="request-type"/>
<!--
CONFERENCE RESPONSE ELEMENT
-->
<xs:element name="response" type="response-type"/>
<!--
CONFERENCE REQUEST TYPE
-->
<xs:complexType name="request-type">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="getMcu" type="get-mcu-type"/>
<xs:element name="addConference" type="add-conference-type"/>
<xs:element name="getConference" type="get-conference-type"/>
<xs:element name="deleteConference" type="delete-conference-type"/>
Levin, et al. Expires August 24, 2005 [Page 9]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:element name="addUser" type="add-user-type"/>
<xs:element name="modifyUser" type="add-user-type"/>
<xs:element name="getUser" type="get-user-type"/>
<xs:element name="deleteUser" type="delete-user-type"/>
<xs:element name="addEndpoint" type="add-endpoint-type"/>
<xs:element name="getEndpoint" type="get-endpoint-type"/>
<xs:element name="deleteEndpoint" type="delete-endpoint-type"/>
<xs:element name="addMedia" type="add-media-type"/>
<xs:element name="modifyMedia" type="add-media-type"/>
<xs:element name="getMedia" type="get-media-type"/>
<xs:element name="deleteMedia" type="delete-media-type"/>
<xs:element name="modifyMediaStatus" type="modify-media-status-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="requestId" type="xs:string"/>
<xs:attribute name="from" type="xs:anyURI"/>
<xs:attribute name="to" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
CONFERENCE RESPONSE TYPE
-->
<xs:complexType name="response-type">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="getMcu" type="get-mcu-response-type"/>
<xs:element name="addConference" type="add-conference-response-type"/>
<xs:element name="getConference" type="get-conference-response-type"/>
<xs:element name="deleteConference" type="delete-conference-response-type"/>
<xs:element name="addUser" type="add-user-response-type"/>
<xs:element name="modifyUser" type="add-user-response-type"/>
<xs:element name="getUser" type="get-user-response-type"/>
<xs:element name="deleteUser" type="delete-user-response-type"/>
<xs:element name="addEndpoint" type="add-endpoint-response-type"/>
<xs:element name="getEndpoint" type="get-endpoint-response-type"/>
<xs:element name="deleteEndpoint" type="delete-endpoint-response-type"/>
<xs:element name="addMedia" type="add-media-response-type"/>
<xs:element name="modifyMedia" type="add-media-response-type"/>
<xs:element name="getMedia" type="get-media-response-type"/>
<xs:element name="deleteMedia" type="delete-media-response-type"/>
<xs:element name="modifyMediaStatus" type="modify-media-status-response-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="requestId" type="xs:string"/>
<xs:attribute name="from" type="xs:anyURI"/>
<xs:attribute name="to" type="xs:anyURI"/>
Levin, et al. Expires August 24, 2005 [Page 10]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:attribute name="code" type="response-code-type"/>
<xs:attribute name="reason" type="reason-code-type" use="optional"/>
<xs:attribute name="displayString" type="xs:string" use="optional"/>
<xs:attribute name="timeOut" type="xs:nonNegativeInteger" use="optional"/>
<xs:attribute name="retryAfter" type="xs:nonNegativeInteger" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
RESPONSE CODE TYPE
-->
<xs:simpleType name="response-code-type">
<xs:restriction base="xs:string">
<xs:enumeration value="success"/>
<xs:enumeration value="pending"/>
<xs:enumeration value="failure"/>
</xs:restriction>
</xs:simpleType>
<!--
REASON CODE TYPE
-->
<xs:simpleType name="reason-code-type">
<xs:restriction base="xs:string">
<xs:enumeration value="serverBusy"/>
<xs:enumeration value="timeout"/>
<xs:enumeration value="unauthorized"/>
<xs:enumeration value="requestMalformed"/>
<xs:enumeration value="requestTooLarge"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE KEYS TYPE
-->
<xs:complexType name="conference-keys-type">
<xs:attribute name="confEntity" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
USER KEYS TYPE
-->
<xs:complexType name="user-keys-type">
<xs:attribute name="confEntity" type="xs:anyURI"/>
<xs:attribute name="userEntity" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ENDPOINT KEYS TYPE
Levin, et al. Expires August 24, 2005 [Page 11]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
-->
<xs:complexType name="endpoint-keys-type">
<xs:attribute name="confEntity" type="xs:anyURI"/>
<xs:attribute name="userEntity" type="xs:anyURI"/>
<xs:attribute name="endpointEntity" type="xs:anyURI"/>
<xs:attribute name="callId" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
MEDIA KEYS TYPE
-->
<xs:complexType name="media-keys-type">
<xs:attribute name="confEntity" type="xs:anyURI"/>
<xs:attribute name="userEntity" type="xs:anyURI"/>
<xs:attribute name="endpointEntity" type="xs:anyURI"/>
<xs:attribute name="callId" type="xs:string" use="optional"/>
<xs:attribute name="mediaId" type="xs:string"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET MCU TYPE
-->
<xs:complexType name="get-mcu-type">
<xs:sequence>
<xs:element name="conference" type="conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET MCU RESPONSE TYPE
-->
<xs:complexType name="get-mcu-response-type">
<xs:sequence>
<xs:element name="mcu" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD CONFERENCE TYPE
-->
<xs:complexType name="add-conference-type">
<xs:sequence>
<xs:element name="conference" type="conference-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
Levin, et al. Expires August 24, 2005 [Page 12]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD CONFERENCE RESPONSE TYPE
-->
<xs:complexType name="add-conference-response-type">
<xs:sequence>
<xs:element name="conference" type="conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET CONFERENCE TYPE
-->
<xs:complexType name="get-conference-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET CONFERENCE RESPONSE TYPE
-->
<xs:complexType name="get-conference-response-type">
<xs:sequence>
<xs:element name="conference" type="conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE CONFERENCE TYPE
-->
<xs:complexType name="delete-conference-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE CONFERENCE RESPONSE TYPE
-->
<xs:complexType name="delete-conference-response-type">
<xs:sequence>
<xs:element name="conference" type="conference-type" minOccurs="0"/>
Levin, et al. Expires August 24, 2005 [Page 13]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD USER TYPE
-->
<xs:complexType name="add-user-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type"/>
<xs:element name="user" type="user-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD USER RESPONSE TYPE
-->
<xs:complexType name="add-user-response-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
<xs:element name="user" type="user-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET USER TYPE
-->
<xs:complexType name="get-user-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET USER RESPONSE TYPE
-->
<xs:complexType name="get-user-response-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
<xs:element name="user" type="user-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
Levin, et al. Expires August 24, 2005 [Page 14]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
DELETE USER TYPE
-->
<xs:complexType name="delete-user-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE USER RESPONSE TYPE
-->
<xs:complexType name="delete-user-response-type">
<xs:sequence>
<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
<xs:element name="user" type="user-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD ENDPOINT TYPE
-->
<xs:complexType name="add-endpoint-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type"/>
<xs:element name="endpoint" type="endpoint-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD ENDPOINT RESPONSE TYPE
-->
<xs:complexType name="add-endpoint-response-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET ENDPOINT TYPE
-->
<xs:complexType name="get-endpoint-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type"/>
Levin, et al. Expires August 24, 2005 [Page 15]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET ENDPOINT RESPONSE TYPE
-->
<xs:complexType name="get-endpoint-response-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE ENDPOINT TYPE
-->
<xs:complexType name="delete-endpoint-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE ENDPOINT RESPONSE TYPE
-->
<xs:complexType name="delete-endpoint-response-type">
<xs:sequence>
<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
ADD MEDIA TYPE
-->
<xs:complexType name="add-media-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type"/>
<xs:element name="media" type="media-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
Levin, et al. Expires August 24, 2005 [Page 16]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
ADD MEDIA RESPONSE TYPE
-->
<xs:complexType name="add-media-response-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
<xs:element name="media" type="media-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET MEDIA TYPE
-->
<xs:complexType name="get-media-type">
<xs:sequence>
<xs:element name="mediaKeys" type="media-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
GET MEDIA RESPONSE TYPE
-->
<xs:complexType name="get-media-response-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
<xs:element name="media" type="media-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE MEDIA TYPE
-->
<xs:complexType name="delete-media-type">
<xs:sequence>
<xs:element name="mediaKeys" type="media-keys-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
DELETE MEDIA RESPONSE TYPE
-->
<xs:complexType name="delete-media-response-type">
<xs:sequence>
<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
<xs:element name="media" type="media-type" minOccurs="0"/>
Levin, et al. Expires August 24, 2005 [Page 17]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
MODIFY MEDIA STATUS TYPE
-->
<xs:complexType name="modify-media-status-type">
<xs:sequence>
<xs:element name="mediaKeys" type="media-keys-type"/>
<xs:element name="mediaStatus" type="media-status-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<!--
MODIFY MEDIA STATUS RESPONSE TYPE
-->
<xs:complexType name="modify-media-status-response-type">
<xs:sequence>
<xs:element name="mediaKeys" type="media-keys-type" minOccurs="0"/>
<xs:element name="mediaStatus" type="media-status-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
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
<request requestId="1" from="sip:someone@example.com" to="conf1@mcu.example.com" aaId="ANBDSJ">
<getMcu>
<conference entity="sip:conf233@example.com">
<!--
CONFERENCE INFO
-->
Levin, et al. Expires August 24, 2005 [Page 18]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<conference-description>
<maximum-user-count>
<entry role="any">
<count>100</count>
</entry>
</maximum-user-count>
<available-media>
<entry id="1">
<type>audio</type>
</entry>
<entry id="2">
<type>video</type>
</entry>
</available-media>
</conference-description>
</conference>
</getMcu>
<addConference>
<conference entity="sip:conf233@example.com">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>Agenda: This month's goals</subject>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>
<entry role="any">
<count>52</count>
</entry>
<entry role="participant">
<count>50</count>
</entry>
</maximum-user-count>
<available-media>
<entry id="1">
<display-text>main audio</display-text>
Levin, et al. Expires August 24, 2005 [Page 19]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<type>audio</type>
</entry>
<entry id="2">
<display-text>main video</display-text>
<type>video</type>
</entry>
</available-media>
</conference-description>
</conference>
</addConference>
<getConference>
<conferenceKeys confEntity="sip:conf233@example.com"/>
</getConference>
<deleteConference>
<conferenceKeys confEntity="sip:conf233@example.com"/>
</deleteConference>
<addUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc4.example.com">
<display-text>Bob's Laptop</display-text>
<joining-method>dialed-out</joining-method>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</endpoint>
</user>
</addUser>
<modifyUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com">
<roles>
<entry>participant</entry>
</roles>
</user>
Levin, et al. Expires August 24, 2005 [Page 20]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
</modifyUser>
<getUser>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
</getUser>
<deleteUser>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
</deleteUser>
<addEndpoint>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
<endpoint entity="sip:bob@pc4.example.com">
<display-text>Bob's Laptop</display-text>
<joining-method>dialed-out</joining-method>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</endpoint>
</addEndpoint>
<getEndpoint>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
</getEndpoint>
<deleteEndpoint>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
</deleteEndpoint>
<addMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</addMedia>
<!--
MODIFY MEDIA
-->
<modifyMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1">
Levin, et al. Expires August 24, 2005 [Page 21]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<status>recvonly</status>
</media>
</modifyMedia>
<getMedia>
<mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
</getMedia>
<deleteMedia>
<mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
</deleteMedia>
<!--
MODIFY MEDIA STATUS
-->
<modifyMediaStatus>
<mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
<mediaStatus>recvonly</mediaStatus>
</modifyMediaStatus>
</request>
8.2 Response
<response requestId="1" from="sip:someone@example.com" to="conf1@mcu.example.com" aaId="ANBDSJ" code="success">
<addConference>
<conference entity="sip:conf233@example.com">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>Agenda: This month's goals</subject>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>
<entry role="any">
Levin, et al. Expires August 24, 2005 [Page 22]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<count>52</count>
</entry>
<entry role="participant">
<count>50</count>
</entry>
</maximum-user-count>
<available-media>
<entry id="1">
<type>audio</type>
</entry>
<entry id="2">
<type>video</type>
</entry>
</available-media>
</conference-description>
</conference>
</addConference>
<getConference>
<conference entity="sip:conf233@example.com">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>Agenda: This month's goals</subject>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>
<entry role="any">
<count>52</count>
</entry>
<entry role="participant">
<count>50</count>
</entry>
</maximum-user-count>
<available-media>
<entry id="1">
<type>audio</type>
Levin, et al. Expires August 24, 2005 [Page 23]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
</entry>
<entry id="2">
<type>video</type>
</entry>
</available-media>
</conference-description>
</conference>
</getConference>
<deleteConference>
<conference entity="sip:conf233@example.com"/>
</deleteConference>
<addUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com"></user>
</addUser>
<ModifyUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com"></user>
</ModifyUser>
<getUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc4.example.com">
<display-text>Bob's Laptop</display-text>
<joining-method>dialed-out</joining-method>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</endpoint>
</user>
</getUser>
<deleteUser>
<conferenceKeys confEntity="sip:conf233@example.com"/>
<user entity="sip:bob@example.com"></user>
Levin, et al. Expires August 24, 2005 [Page 24]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
</deleteUser>
<addEndpoint>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
<endpoint entity="sip:bob@pc4.example.com"></endpoint>
</addEndpoint>
<getEndpoint>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
<endpoint entity="sip:bob@pc4.example.com">
<display-text>Bob's Laptop</display-text>
<joining-method>dialed-out</joining-method>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</endpoint>
</getEndpoint>
<deleteEndpoint>
<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
<endpoint entity="sip:bob@pc4example.com"></endpoint>
</deleteEndpoint>
<addMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</addMedia>
<ModifyMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1"> </media>
</ModifyMedia>
<getMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</getMedia>
Levin, et al. Expires August 24, 2005 [Page 25]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
<deleteMedia>
<endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
</media>
</deleteMedia>
<!--
MODIFY MEDIA STATUS RESPONSE
-->
<modifyMediaStatus>
<mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
<mediaStatus>recvonly</mediaStatus>
</modifyMediaStatus>
</response>
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",
Internet-Draft draft-ietf-sipping-conference-package-08,
December 2004.
Levin, et al. Expires August 24, 2005 [Page 26]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 2005
12.2 Informative References
[3] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
Internet-Draft draft-ietf-sipping-conferencing-framework-03,
October 2004.
[4] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing",
Internet-Draft draft-barnes-xcon-framework-02, February 2005.
Authors' Addresses
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: oritl@microsoft.com
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva, 49130
Israel
Email: roni.even@polycom.co.il
Pierre Hagendorf
RADVISION
24, Raul Wallenberg St.
Tel-Aviv, 69719
Israel
Email: pierre@radvision.com
Levin, et al. Expires August 24, 2005 [Page 27]
Internet-Draft Centralized Conference Control Protocol (CCCP) February 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.
Levin, et al. Expires August 24, 2005 [Page 28]