RFC 6504
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
Pages: 78
Informational
Informational
Part 1 of 4 – Pages 1 to 11
Internet Engineering Task Force (IETF) M. Barnes Request for Comments: 6504 Polycom Category: Informational L. Miniero ISSN: 2070-1721 Meetecho R. Presta S P. Romano University of Napoli March 2012 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow ExamplesAbstract
This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6504. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 2. Terminology .....................................................3 3. Overview ........................................................4 4. Working with CCMP ...............................................4 4.1. CCMP and the Data Model ....................................5 4.2. Using HTTP/TLS as a Transport ..............................6 4.3. Conference Notifications ..................................10 5. Conference Creation ............................................11 5.1. Basic Conference Creation .................................12 5.2. Conference Creation Using Blueprints ......................16 5.3. Conference Creation Using User-Provided Conference Information ...............................................23 5.4. Cloning an Existing Conference ............................28 6. Conference Users Scenarios and Examples ........................31 6.1. Adding a Party ............................................32 6.2. Muting a Party ............................................35 6.3. Conference Announcements and Recordings ...................38 6.4. Monitoring for DTMF .......................................41 6.5. Entering a Password-Protected Conference ..................42 7. Sidebars Scenarios and Examples ................................44 7.1. Internal Sidebar ..........................................45 7.2. External Sidebar ..........................................54 7.3. Private Messages ..........................................60 7.4. Observing and Coaching ....................................64 8. Removing Participants and Deleting Conferences .................71 8.1. Removing a Party ..........................................71 8.2. Deleting a Conference .....................................74 9. Security Considerations ........................................75 10. Acknowledgements ..............................................76 11. References ....................................................76 11.1. Normative References .....................................76 11.2. Informative References ...................................76
1. Introduction
This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) [RFC5239] and in the XCON scenarios [RFC4597]. The XCON scenarios describe a broad range of use cases taking advantage of the advanced conferencing capabilities provided by a system realization of the XCON framework. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503]. Due to the broad range of functionality provided by the XCON framework and the flexibility of the CCMP messaging, these call flows should not be considered inclusive of all the functionality that can provided by the XCON framework and protocol implementations. These flows represent a sample to provide an overview of the feature-rich capabilities of the XCON framework and CCMP messaging for protocol developers, software developers, and researchers.2. Terminology
This document uses the same terminology as found in the Architectural Framework for Media Server Control [RFC5567] and in the Media Control Channel Framework Call Flow Examples [CALL-FLOWS], with the following terms and abbreviations used in the call flows. Also, note that the term "call flows" is used in a very generic sense in this document since the media is not limited to voice. The calls supported by the XCON framework and CCMP can consist of media such as text, voice, and video, including multiple media types in a single active conference. Conference and Media Control Client (CMCC): as defined in the XCON framework. In the flows in this document, the CMCC is logically equivalent to the use of a User Agent Client (UAC) as the client notation in the media control call flows [CALL-FLOWS]. A CMCC differs from a generic media client in being an XCON-aware entity, thus, also being able to issue CCMP requests. Conference Server (ConfS): In this document, the term "conference server" is used interchangeably with the term "Application Server (AS)" as used in the media control architectural framework [RFC5567]. A conference server is intended to be able to act as a conference control server, as defined in the XCON framework, i.e., it is able to handle CCMP requests and issue CCMP responses.
Media Server (MS): as defined in the media control architectural
framework [RFC5567].
3. Overview
This document provides a sampling of detailed call flows that can be
implemented based on a system realization of the XCON framework
[RFC5239] and implementation of CCMP [RFC6503]. This is intended to
be a simple guide for the use of the conference control protocol
between the conference server and the conference control client. The
objective is to provide an informational base reference for protocol
developers, software developers, and researchers.
This document focuses on the interaction between the conference and
media control client and the conferencing system, specifically the
conference server. The scenarios are based on those described in the
XCON framework, many of which are based on the advanced conferencing
capabilities described in the XCON scenarios. Additional scenarios
have been added to provide examples of other real-life scenarios that
are anticipated to be supported by the framework. With the exception
of an initial example with media control messaging, the examples do
not include the details for the media control [RFC6505], call
signaling, or Binary Floor Control Protocols (BFCPs) [RFC4582]. This
document references the scenarios in the media control call flows
[CALL-FLOWS], SIP call control conferencing, [RFC4579], and BFCP
documents.
The rest of this document is organized as follows. Section 4
presents an overview on CCMP, together with some implementation-
related details and related matters like HTTPS transport and
notifications. Section 5 presents the reader with examples showing
the different approaches CCMP provides to create a new conference.
Section 6 more generally addresses the different user-related
manipulations that can be achieved by means of CCMP, by presenting a
number of interesting scenarios. Section 7 addresses several
scenarios that may involve the use of sidebars. Section 8 shows how
CCMP can be used to remove conferences and users from the system.
Finally, Section 9 provides a few details on the security
considerations when it comes to implementing CCMP.
4. Working with CCMP
This section provides a brief introduction as to how the Centralized
Conferencing Manipulation Protocol (CCMP) [RFC6503] works and how it
can be transported across a network. A typical CCMP interaction
focusing on relevant aspects of the client-server communication is
described. Please note that this section assumes the reader has read and understood the CCMP document. This section is intended to help the reader understand the actual protocol interactions. First, a description of the protocol itself is provided Section 4.1, including some implementation considerations. In Section 4.2, an effective CCMP interaction is presented by exploiting HTTPS as a transport. Finally, notifications are described in Section 4.3. The document then presents and describes some actual flows in detail in the sections to follow.4.1. CCMP and the Data Model
CCMP is an protocol based on XML [W3C.REC-xml-20081126]. It has been designed as a request/response protocol. It is completely stateless, which means implementations can safely handle transactions independently from each other. The protocol allows for the manipulation of conference objects and related users. This manipulation allows a conference and media control client (briefly CMCC in all the following sections) to create, update, and remove basically everything that is related to the objects handled by a conferencing system. This is reflected in the allowed operations (retrieve, create, update, delete) and the specified request types (ranging from the manipulation of blueprints and conferences to users and sidebars). For instance, CCMP provides ways to: o retrieve the list of registered and/or active conferences in the system; o create new conferences by exploiting several different approaches; o add/remove users to/from a conference; o update a conference with respect to all of its aspects; and so on. While CCMP acts as the means to manipulate conference objects, CCMP does not define these conference objects. A separate document specifies how a conference object and all its components have to be constructed (Conference Information Data Model for Centralized Conferencing (XCON) [RFC6501]). CCMP, depending upon the request type and the related operation, carries pieces of conference objects (or any object as a whole) according to the aforementioned
specification. This means that any implementation aiming at being compliant with CCMP has to make sure that the transported objects are completely compliant with the data model specification and coherent with the constraints defined therein. To make this clearer, there are elements that are mandatory in a conference object: issuing a syntactically correct CCMP request that carries a wrong conference object is doomed to result in a failure. For this reason, it is suggested that the interested implementers take special care in carefully checking the data model handlers as well in order to avoid potential mistakes. However, there are cases when a mandatory element in the data model cannot be assigned in a conference object by a CCMP user. For example, a CMCC may be requesting the direct creation of a new conference; in this case, a conference object assumes an 'entity' attribute uniquely identifying the conference to be in place. Thus, the CMCC has no way to know a priori what the entity will be, since it is generated by the ConfS after the request. For scenarios like this one, the CCMP specification describes the use of a dedicated placeholder wildcard (i.e., "AUTO_GENERATE_X", where X is an integer) to make the conference object compliant with the data model: the wildcard would then be replaced by the ConfS with the right value.4.2. Using HTTP/TLS as a Transport
CCMP requires that implementations support HTTP/TLS as the transport mechanism. Per CCMP, a CMCC sends a request as part of an HTTPS POST message, and the ConfS would reply with a 200 OK HTTPS response. In both cases, the HTTPS messages carry the CCMP messages as payload, which is reflected in the Content-Type header ("application/ccmp+xml"). Figure 1 presents a ladder diagram of such an interaction, which is followed by a dump of the exchanged HTTPS messages for further analysis. The examples in the remainder of this document show only the CCMP interactions.
CMCC ConfS | | | 1. HTTPS POST (CCMP request) | |--------------------------------------------->| | | | |--+ Parse request, | | | update object | |<-+ and reply | | | 2. 200 OK (CCMP response) | |<---------------------------------------------| | | |--+ Parse response and | | | update local copy | |<-+ of conference object | | | ' ' ' ' Figure 1: CCMP on HTTPS Per the protocol dump in the following lines, the CMCC has issued a CCMP request (a blueprintRequest message asking for a blueprint retrieval, i.e., with the <operation> element set to "retrieve" ) towards the ConfS. The request has been carried as payload of an HTTPS POST (message 1.) towards a previously known location. The mandatory Host header has been specified, and the Content-Type header has been correctly set as well ("application/ccmp+xml"). The ConfS, in turn, has handled the request and replied accordingly. The response (a blueprintResponse message with a <response-code> set to a successful value, "200") has been carried as payload of a 200 OK HTTPS response (message 2.). As before, the Content-Type header has been correctly set ("application/ccmp+xml"). 1. CMCC -> ConfS (HTTPS POST, CCMP request) ------------------------------------------ POST /Xcon/Ccmp HTTP/1.1 Content-Length: 657 Content-Type: application/ccmp+xml Host: example.com:443 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. CMCC <- ConfS (200 to POST, CCMP response)
---------------------------------------------
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/ccmp+xml;charset=ISO-8859-1
Content-Length: 1652
Date: Thu, 04 Feb 2010 14:47:56 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description>
<info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count>
<info:available-media>
<info:entry label="audioLabel">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm
</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
For completeness, the following provides some details of the CCMP
interaction. Despite the simplicity of the request, this flow
provides some relevant information on how CCMP messages are built.
Specifically, both the CCMP request and the CCMP response share a
subset of the message:
o <confUserID>: this element, provided by the CMCC, refers to the
requester by means of his XCON-USERID; except in a few scenarios
(presented in the following sections), this element must always
contain a valid value;
o <confObjID>: this element refers to the target conference object,
according to the request in place;
o <operation>: this element specifies the operation the CMCC wants
to perform, according to the specific request type.
Besides those elements, the CMCC (let's say Alice, whose XCON-USERID
is "xcon-userid:Alice@example.com") has also provided an additional
element, <blueprintRequest>. The name of that element varies
according to the request type in which the CMCC is interested. In
this specific scenario, the CMCC was interested in acquiring details
concerning a specific blueprint (identified by its XCON-URI
"xcon:AudioRoom@example.com", as reflected in the provided
<confObjID> target element), and so the request consisted in an empty
<blueprintRequest> element. It will be clearer in the following
sections that different request types may require different elements
and, as a consequence, different content.
Considering the request was a blueprintRequest message, the ConfS has
replied with a blueprintResponse message containing a
<blueprintResponse> element. This element includes a complete dump
of the conference object (compliant with the data model) describing
the requested blueprint.
Without providing additional details of this interaction, it is worth noting that this was the example of the simplest CCMP communication that could take place between a CMCC and a ConfS, a blueprint request: this scenario will be described in more detail in Section 5.2.4.3. Conference Notifications
The XCON framework [RFC5239] identifies several different possible protocol interactions between a conference server and a conferencing client. One of those interactions is generically called "notification protocol" providing a mechanism for all clients interested in being informed by the server whenever something relevant happens in a conference. When SIP is used as the call signaling protocol in a CCMP implementation, the XCON event package [RFC6502], which extends the SIP event package for conference state [RFC4575] must be supported. A SIP client uses the SIP SUBSCRIBE message for the XCON event package to subscribe to notifications related to a specific conference. A SIP client would receive notifications describing all the changes to the document via a SIP NOTIFY message. An example ladder diagram is presented in Figure 2; in this figure, we assume a CMCC has updated a conference object, and a previously subscribed SIP client is notified of the update.
CMCC ConfS UAC | | | | | 1. SIP SUBSCRIBE | | |<--------------------------| | Handle +--| | | new | | | | subscription +->| 2. SIP 200 OK | | |-------------------------->| | | | ' ' ' ' ' ' | | | | 3. CCMP (add user) | | |---------------------->| | | |--+ Add user | | | | to conf. | | |<-+ object | | 4. CCMP (success) | | |<----------------------| | | | 5. SIP NOTIFY (changes) | | |-------------------------->| | | 6. SIP 200 OK | | |<--------------------------| | | | ' ' ' ' ' ' Figure 2: XCON Event Package: SIP Notifications The detailed flows in this document generically present a notification, when appropriate, but do not include the SIP messaging details.
(page 11 continued on part 2)