XCON O. Levin
Internet-Draft Microsoft Corporation
Expires: April 27, 2006 R. Even
Polycom
P. Hagendorf
RADVISION
October 24, 2005
Centralized Conference Control Protocol (CCCP)
draft-levin-xcon-cccp-03
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 April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a Centralized Conferencing Control Protocol
(CCCP) as a part of the XCON Working Group protocols suite. CCCP
uses a client-server model for creation, querying, and manipulation
of XCON entities, conference objects and sub-objects. An XCON
entity, which implements a CCCP server, provides a means for
Levin, et al. Expires April 27, 2006 [Page 1]
Internet-Draft CCCP October 2005
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. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Transaction Model . . . . . . . . . . . . . . . . . . . . 4
4.2. Multiple Primitives in a Single Operation . . . . . . . . 5
4.3. Response Codes and Failures . . . . . . . . . . . . . . . 6
5. Using the Data Model . . . . . . . . . . . . . . . . . . . . . 6
6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. System Primitives . . . . . . . . . . . . . . . . . . . . 7
6.1.1. Cancel . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.3. getTemplates . . . . . . . . . . . . . . . . . . . . . 8
6.1.4. getActiveConferences . . . . . . . . . . . . . . . . . 9
6.2. Conference Primitives . . . . . . . . . . . . . . . . . . 9
6.2.1. addConference . . . . . . . . . . . . . . . . . . . . 9
6.2.2. modifyConference . . . . . . . . . . . . . . . . . . . 11
6.2.3. deleteConference . . . . . . . . . . . . . . . . . . . 12
6.2.4. getConference . . . . . . . . . . . . . . . . . . . . 13
6.3. User Primitives . . . . . . . . . . . . . . . . . . . . . 14
6.3.1. addUser . . . . . . . . . . . . . . . . . . . . . . . 14
6.3.2. modifyUser . . . . . . . . . . . . . . . . . . . . . . 15
6.3.3. modifyUserRoles . . . . . . . . . . . . . . . . . . . 16
6.3.4. deleteUser . . . . . . . . . . . . . . . . . . . . . . 17
6.3.5. getUser . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Endpoint Primitives . . . . . . . . . . . . . . . . . . . 19
6.4.1. addEndpoint . . . . . . . . . . . . . . . . . . . . . 19
6.4.2. modifyEndpoint . . . . . . . . . . . . . . . . . . . . 20
6.4.3. deleteEndpoint . . . . . . . . . . . . . . . . . . . . 21
6.4.4. getEndpoint . . . . . . . . . . . . . . . . . . . . . 22
6.5. Endpoint Media Primitives . . . . . . . . . . . . . . . . 24
6.5.1. addEndpointMedia . . . . . . . . . . . . . . . . . . . 24
6.5.2. modifyEndpointMedia . . . . . . . . . . . . . . . . . 25
6.5.3. deleteEndpointMedia . . . . . . . . . . . . . . . . . 25
6.5.4. getEndpointMedia . . . . . . . . . . . . . . . . . . . 26
6.6. Sidebar Primitives . . . . . . . . . . . . . . . . . . . . 27
6.6.1. addSidebar . . . . . . . . . . . . . . . . . . . . . . 27
6.6.2. modifySidebar . . . . . . . . . . . . . . . . . . . . 28
6.6.3. deleteSidebar . . . . . . . . . . . . . . . . . . . . 28
6.6.4. addUserToSidebar . . . . . . . . . . . . . . . . . . . 28
6.6.5. deleteUserFromSidebar . . . . . . . . . . . . . . . . 28
6.6.6. moveUserBetweenSidebars . . . . . . . . . . . . . . . 28
Levin, et al. Expires April 27, 2006 [Page 2]
Internet-Draft CCCP October 2005
6.7. Stimulus Primitives . . . . . . . . . . . . . . . . . . . 28
7. The XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:cccp . . . . . . . . . . . . . . . 47
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Normative References . . . . . . . . . . . . . . . . . . . 49
11.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51
Levin, et al. Expires April 27, 2006 [Page 3]
Internet-Draft CCCP October 2005
1. Introduction
The SIPPING Conference Framework [6] describes a general centralized
conferencing architecture. The XCON Framework [7] defines how this
architecture can be realized by an XCON compliant system. This
document defines a Centralized Conferencing Control Protocol (CCCP)
as a conference control protocol in the XCON protocols suite
described in XCON Framework [7].
CCCP uses a client-server model for creation, querying, and
manipulation of XCON entities, conference objects and sub-objects.
By implementing a CCCP server, an XCON entity provides a means for
authorized CCCP clients (e.g. conference participants) to affect the
behavior of a conference in the XCON system. CCCP is a semantic-
oriented protocol, which uses the XML types defined in the SIPPING
Conference Package [2] for the representation of the conference
object and its sub-objects . In future, the CCCP can be extended to
include manipulations on additional conferencing objects being
represented by XML schemas such as policies and templates.
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. Transport
The protocol design assumes that CCCP runs on 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. This model allows for using different transport
protocols based on the system requirements and also for multiplexing
otherwise independent CCCP communications over a common transport
channel.
4. The Protocol
4.1. Transaction Model
CCCP is a client-server protocol. The protocol defines two
Levin, et al. Expires April 27, 2006 [Page 4]
Internet-Draft CCCP October 2005
operations: request and response.
A client issues requests to a server. The server MUST reply with a
single final response. Two final responses are defined: "failure"
and "success".
Before issuing the final response, the server MAY reply with multiple
provisional responses. Currently a single provisional response
"pending" is defined.
Editor's Note: Timeouts TBD.
A CCCP request carries the following attributes:
requestId: A unique string generated by the CCCP client across all
its requests.
from: A transport URI which identifies the CCCP client.
to: A transport URI which identifies the CCCP server.
originator: A trusted ID of the originator of the request.
The combination of the 'requestId', 'to', and 'from' attributes in
the request constitutes the CCCP transaction ID.
A CCCP response carries the following attributes:
requestId: The original request ID generated by the client and
echoed as is by the server.
from: A transport URI which identifies the CCCP server.
to: A transport URI which identifies the CCCP client.
code: The general response code: success, pending, or failure.
reason: The general CCCP failure reason.
timeout: The updated timeout used with pending responses (details
TBD).
retryAfter: The suggested delay used with serverBusy responses.
4.2. Multiple Primitives in a Single Operation
A CCCP operation (i.e. a request and a corresponding response) MAY
contain multiple primitives. The CCCP MUST process the received
primitives one-by-one in the order they appear in the request body.
If the request contains multiple primitives, the corresponding
response operation MUST contain the response primitive for each and
in the same order as in the request.
Multiple primitives within the same request MUST be executed as an
atomic operation. This means that if one primitive fails, the state
of the object MUST be rolled back to its state before processing the
request.
Levin, et al. Expires April 27, 2006 [Page 5]
Internet-Draft CCCP October 2005
If a CCCP server is not willing to process a multi-primitive request,
it MUST fail the transaction with the response code "notSupported".
4.3. Response Codes and Failures
CCCP defines the following reasons for failure of a request operation
:
serverBusy: Optional retryAfter can be included in the response.
timeout: Operation took too long and was aborted by the server.
unauthorized: Client is not authorized to perform the operation.
requestMalformed: The XML document in the request is either not
well-formed or not compliant with the schema.
requestTooLarge: Result of the request operation length check.
requestCancelled: The pending request was canceled by CCCP.
notSupported: One of the primitives or their combination is not
supported by the server.
otherFailure: Result of any other server fault condition.
Most CCCP primitives define their own optional response codes. This
allows communicating the detailed primitive result in addition to the
CCCP general response code.
5. Using the Data Model
The CCCP operations are applied to the data objects expressed in
terms of SIPPING Conference Package [2] XML types whenever possible.
The considerations listed below MUST be taken into account when using
the schema with CCCP.
The information included in the request expresses the desired data
object state to be achieved after the operation is successfully
completed. By definition, the CCCP primitives allow for inclusion of
any information that can be expressed in terms of the conference-type
and its sub-types.
Attributes 'state' and 'version' of the conference-type and its sub-
types are never used with CCCP. The information in the response is
provided as a feedback to the request only and typically doesn't
carry the full state of the object.
For each primitive request, the CCCP explicitly defines (see
Section 6) what information (i.e. attributes and elements) MUST be
provided by the client and what information (when provided by the
client) MUST NOT be ignored by the server. The rest of the
information included by the client MAY be treated as optional by the
server.
Levin, et al. Expires April 27, 2006 [Page 6]
Internet-Draft CCCP October 2005
For each primitive response, the CCCP explicitly defines (see
Section 6) what information (i.e. attributes and elements) if
included by the server MUST NOT be ignored by the client. The rest
of the information included by the client MAY be treated as optional
by the server. If neither mandatory information nor new data is
generated, the server MAY return minimum schema compliant construct,
such as an element with empty body and the attributes identifying the
corresponding request only. On the other hand, the CCCP server MAY
include any rich dynamically generated information to the client (for
example, to be displayed to a user or be logged in by the system) in
the response. The client MAY ignore any information received in the
response, unless stated otherwise in Section 6.
6. Primitives
This section describes the defined CCCP primitives and includes valid
XML document examples for each. The corresponding CCCP XML schema is
provided in Section 7.
6.1. System Primitives
6.1.1. Cancel
Cancel a pending request.
This primitive can be issued by a client to cancel a pending
transaction. The primitive is an independent transaction on its own.
The body of the primitive MUST carry the requestId of one of the
pending requests.
5
Note that a valid response can contain an empty body.
Levin, et al. Expires April 27, 2006 [Page 7]
Internet-Draft CCCP October 2005
6.1.2. Ping
Ping a CCCP Server.
A successful response is shown below.
6.1.3. getTemplates
Get the list of templates supported by the system.
Levin, et al. Expires April 27, 2006 [Page 8]
Internet-Draft CCCP October 2005
XML TBD.
6.1.4. getActiveConferences
Get the list of conference identifiers for active conference objects
in the system.
XML TBD.
6.2. Conference Primitives
6.2.1. addConference
Create a conference.
The 'conferenceEntity' value in the request is a client's suggestion
only. The CCCP server MAY replace the suggested value with a
different 'conferenceEntity' value in the corresponding response.
Levin, et al. Expires April 27, 2006 [Page 9]
Internet-Draft CCCP October 2005
Design Review
tel:+1-8666119036
FFD bridge
https://company.com/ConfServer
audio
The CCCP server MAY replace the suggested 'conferenceEntity' with a
different value in the corresponding response. In the case of a
successful response, the CCCP client MUST use the new value and
SHOULD use all the new parameters allocated by the server to the
conference.
Levin, et al. Expires April 27, 2006 [Page 10]
Internet-Draft CCCP October 2005
Design Review
tel:+1-8666119036
FFD bridge
https://company.com/ConfServer
audio
6.2.2. modifyConference
Modify conference parameters.
Levin, et al. Expires April 27, 2006 [Page 11]
Internet-Draft CCCP October 2005
Spec Review
6.2.3. deleteConference
Remove conference from the system.
Levin, et al. Expires April 27, 2006 [Page 12]
Internet-Draft CCCP October 2005
6.2.4. getConference
Retrieve the conference information.
Levin, et al. Expires April 27, 2006 [Page 13]
Internet-Draft CCCP October 2005
Design Review
tel:+1-8666119036
FFD bridge
https://company.com/ConfServer
audio
6.3. User Primitives
6.3.1. addUser
The client MUST provide the 'userEntity' value in the request.
Levin, et al. Expires April 27, 2006 [Page 14]
Internet-Draft CCCP October 2005
Bob Hoskins
presenter
6.3.2. modifyUser
Modify the user information.
Levin, et al. Expires April 27, 2006 [Page 15]
Internet-Draft CCCP October 2005
Bob Hoskins III
tel:2562566
the description
optional tbd values
presenter
6.3.3. modifyUserRoles
This is a dedicated primitive to change user's roles. The same
effect can be achieved by using the modifyUser primitive. Note that
a CCCP server can choose to implement both approaches simultaneously
Levin, et al. Expires April 27, 2006 [Page 16]
Internet-Draft CCCP October 2005
to be invoked by different clients.
Editor's Note: The dedicated primitive is defined to demonstrate that
both approaches are possible with CCCP.
presenter
6.3.4. deleteUser
Remove the user from the conference roster.
Levin, et al. Expires April 27, 2006 [Page 17]
Internet-Draft CCCP October 2005
6.3.5. getUser
Retrieve the information about a conference participant.
Levin, et al. Expires April 27, 2006 [Page 18]
Internet-Draft CCCP October 2005
Bob Hoskins III
tel:2562566
the description
optional tbd values
presenter
6.4. Endpoint Primitives
6.4.1. addEndpoint
Bring the specified user into a conference by establishing a call
(signaling and media) with him/her/it.
The endpoint 'entity' value MAY be replaced or augmented by the CCCP
server. The 'media-id' value MAY be replaced or augmented by the
CCCP server. If the server returns this information in the response,
the client MUST use the values provided by the server.
Levin, et al. Expires April 27, 2006 [Page 19]
Internet-Draft CCCP October 2005
Bob's Laptop
dialed-out
main audio
audio
6.4.2. modifyEndpoint
Modify the call description or/and its behaivior.
Levin, et al. Expires April 27, 2006 [Page 20]
Internet-Draft CCCP October 2005
Bob's Laptop
6.4.3. deleteEndpoint
Disconnect the call.
Levin, et al. Expires April 27, 2006 [Page 21]
Internet-Draft CCCP October 2005
6.4.4. getEndpoint
Retrieve the information about the call.
Levin, et al. Expires April 27, 2006 [Page 22]
Internet-Draft CCCP October 2005
Bob's Laptop
dialed-out
main audio
audio
Levin, et al. Expires April 27, 2006 [Page 23]
Internet-Draft CCCP October 2005
6.5. Endpoint Media Primitives
6.5.1. addEndpointMedia
Add the specified media stream to the call.
The 'media-id' value MAY be replaced or augmented by the CCCP server.
The CCCP client MUST use the new value if returned by the server in
the response.
main audio
audio
Levin, et al. Expires April 27, 2006 [Page 24]
Internet-Draft CCCP October 2005
6.5.2. modifyEndpointMedia
Modify the media behavior. This primitive can be used to mute and
un-mute the call.
audio
recvonly
6.5.3. deleteEndpointMedia
Remove the specified media stream from the call.
Levin, et al. Expires April 27, 2006 [Page 25]
Internet-Draft CCCP October 2005
6.5.4. getEndpointMedia
Retrieve the information about the specified stream in the call.
Levin, et al. Expires April 27, 2006 [Page 26]
Internet-Draft CCCP October 2005
audio
recvonly
6.6. Sidebar Primitives
6.6.1. addSidebar
Create a sidebar in the conference.
Levin, et al. Expires April 27, 2006 [Page 27]
Internet-Draft CCCP October 2005
XML TBD.
6.6.2. modifySidebar
Modify the sidebar parameters in the conference.
XML TBD.
6.6.3. deleteSidebar
Remove the sidebar from the conference.
XML TBD.
6.6.4. addUserToSidebar
Add the specified conference participant to the sidebar.
XML TBD.
6.6.5. deleteUserFromSidebar
Remove the specified conference participant from the sidebar.
XML TBD.
6.6.6. moveUserBetweenSidebars
Move the the specified conference participant from sidebar A to
sidebar B.
XML TBD.
6.7. Stimulus Primitives
This operation is used to convey opaque to the CCCP logic requests
from a CCCP client to a CCCP server to be processed by applications
above CCCP.
XML TBD.
7. The XML Schema
Levin, et al. Expires April 27, 2006 [Page 30]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 33]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 35]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 36]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 37]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 38]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 39]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 40]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 41]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 42]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 43]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 44]
Internet-Draft CCCP October 2005
Levin, et al. Expires April 27, 2006 [Page 46]
Internet-Draft CCCP October 2005
8. IANA Considerations
This document registers a new XML namespace and a new XML schema.
8.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cccp
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [5].
URI: The URI for this namespace is urn:ietf:params:xml:ns:cccp
Registrant Contact: IETF XCON Working Group , as
designated by the IESG
XML:
Levin, et al. Expires April 27, 2006 [Page 47]
Internet-Draft CCCP October 2005
BEGIN
Centralized Conference Information Namespace
Namespace for Centralized Conference Control Protocol
urn:ietf:params:xml:ns:cccp
See RFCXXXX.