Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6504

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Pages: 78
Informational
Part 1 of 4 – Pages 1 to 11
None   None   Next

Top   ToC   RFC6504 - Page 1
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 Examples

Abstract

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.
Top   ToC   RFC6504 - Page 2
   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
Top   ToC   RFC6504 - Page 3

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.
Top   ToC   RFC6504 - Page 4
   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
Top   ToC   RFC6504 - Page 5
   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
Top   ToC   RFC6504 - Page 6
   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.
Top   ToC   RFC6504 - Page 7
    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)
Top   ToC   RFC6504 - Page 8
   <?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>
Top   ToC   RFC6504 - Page 9
           </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.
Top   ToC   RFC6504 - Page 10
   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.
Top   ToC   RFC6504 - Page 11
       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)

Next Section