tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6504

Informational
Pages: 78
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: XCON

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Part 1 of 4, p. 1 to 11
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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 RFC Part