XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Intended status: Informational                                C. Boulton
Expires: July 2, 2010                                    NS-Technologies                                L. Miniero
Expires: August 21, 2010                                        Meetecho
                                                               R. Presta
                                                             S P. Romano
                                                    University of Napoli
                                                       December 29, 2009
                                                       February 17, 2010

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
                      draft-ietf-xcon-examples-02
                      draft-ietf-xcon-examples-03

Abstract

   This document provides detailed call flows for the scenarios
   documented in the Centralized Conferencing (XCON) Framework and the
   XCON Scenarios.  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).  The
   objective is to provide a base reference for both protocol
   researchers and developers.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 2, August 21, 2010.

Copyright Notice
   Copyright (c) 2009 2010 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 BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Conference Creation  Working with CCMP  . . . . . . . . . . . . . . . . . . . . .  5 .  6
     5.1.  Basic Conference Creation  CCMP and the Data Model  . . . . . . . . . . . . . . . . .  6
     5.2.  Basic Conference Creation for  Using HTTP as a specific instance of
           Conference Information . . transport  . . . . . . . . . . . . . . . . 11  8
     5.3.  Basic Conference Creation - Cloning an existing  Conference Notifications . . . . . . . . . . . . . . . . . 11
   6.  Conference Creation  . . . . . . . . . . . . . . . . . . . . . 15
     5.4.
     6.1.  Basic Conference Creation using Blueprints  . . . . . . . . . . . 18
   6.  General Conference scenarios and examples . . . . . 15
     6.2.  Conference Creation using Blueprints . . . . . 25
     6.1.  Conference Announcements and Recordings . . . . . . 20
     6.3.  Conference Creation using User-Provided Conference
           Information  . . . 25
     6.2.  Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 29
     6.3.  Adding a Party . 27
     6.4.  Cloning an Existing Conference . . . . . . . . . . . . . . 32
   7.  Conference Users Scenarios and Examples  . . . . . . . 30
     6.4.  Muting a Party . . . . 35
     7.1.  Adding a Party . . . . . . . . . . . . . . . . . . 33
     6.5.  Internal Sidebar . . . . 36
     7.2.  Muting a Party . . . . . . . . . . . . . . . . . 37
     6.6.  External Sidebar . . . . . 39
     7.3.  Conference Announcements and Recordings  . . . . . . . . . 43
     7.4.  Monitoring for DTMF  . . . . . . . 46
     6.7.  Floor control using sidebars . . . . . . . . . . . . 47
     7.5.  Entering a password-protected conference . . . 52
     6.8.  Whispering or Private Messages . . . . . . 47
   8.  Sidebars Scenarios and Examples  . . . . . . . . . 53
     6.9.  Observing and Coaching . . . . . . 49
     8.1.  Internal Sidebar . . . . . . . . . . . . 56
   7.  Removing participants and deleting conferences . . . . . . . . 62
     7.1.  Removing a Party . 50
     8.2.  External Sidebar . . . . . . . . . . . . . . . . . . . . 62
     7.2.  Deleting a Conference . 59
     8.3.  Private Messages . . . . . . . . . . . . . . . . . 65
   8.  Additional Conference Scenarios and Examples . . . . 65
     8.4.  Observing and Coaching . . . . . 67
     8.1.  Chat . . . . . . . . . . . . . 69
   9.  Removing Participants and Deleting Conferences . . . . . . . . 76
     9.1.  Removing a Party . . . . . . 68
       8.1.1.  Basic Chat Operations . . . . . . . . . . . . . . . 76
     9.2.  Deleting a Conference  . 68
       8.1.2.  Advanced Operations . . . . . . . . . . . . . . . . . 72
   9. 79
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 76
   10. 80
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 76
   11. 80
   12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 76
   12. 81
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77
   13. 83
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
     13.1. 83
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 78
     13.2. 83
     14.2. Informative References . . . . . . . . . . . . . . . . . . 78 83
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 84

1.  Introduction

   This document provides detailed call flows for the scenarios
   documented in the Framework for Centralized Conferencing (XCON
   Framework) [RFC5239] and 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)[I-D.ietf-xcon-ccmp].

   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.  Conventions

   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 [RFC2119] and indicate requirement
   levels for compliant implementations.  In this document, these key
   words are used when describing normative functionality based on the
   XCON Framework and CCMP.

   Note that due to RFC formatting conventions, this document often
   splits message details whose content would exceed 72 characters.  A
   backslash character marks where this line folding has taken place.
   This backslash and its trailing CRLF and whitespace would not appear
   in the actual protocol contents.

3.  Terminology

   This document uses the same terminology as found in the referenced
   documents, 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.

   Conferencing

   Conference and Media Client Control Client (CMCC):  As  as defined in the XCON
      Framework.  In the flows in this document, the CMCC is logically
      equivalent to the use of UAC as the client notation in the media
      control call flows [I-D.ietf-mediactrl-call-flows].  A CMCC
      differs from a generic Media Client in being an XCON-aware entity,
      thus being able to also issue CCMP requests.

   Conferencing Server (ConfS):  As defined in the XCON Framework.  In this document, the conferencing server "Conferencing
      Server" term is used interchangeably with the term Application
      Server (AS) as used in the Media Control Architectural Framework
      [RFC5567].  However, these need not  A Conferencing Server is intended to be the
      same entities able to act as
      a Conference Control Server, as defined in an implementation. the XCON framework,
      i.e. it is able to handle CCMP requests and issue CCMP responses.

   Media Server (MS):  As  as defined in the Media Control Architectural
      Framework [RFC5567].

4.  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 [I-D.ietf-xcon-ccmp].  This is
   intended to be a simple guide on for the use of the conference control protocol Conference Control
   Protocol between the Conference Conferencing 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, System, specifically the
   Conference
   Conferencing 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 [I-D.ietf-mediactrl-mixer-control-package], call
   signaling or binary floor control [RFC4582] protocols.  This document
   references the scenarios in the Media Control call flows
   [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
   [RFC4579] and binary floor control protocol documents.

5.  Conference Creation

   This section provides the

   The rest of this document is organized as follows.  Section 5
   presents an overview on CCMP, together with some implementation-
   related details associated and related matters like HTTP transport and
   notifications.  Section 6 presents the reader with examples showing
   the various ways in
   which different approaches CCMP provides to create a conference new conference.
   Section 7 more generally addresses the different user-related
   manipulations that can be created using CCMP and achieved by means of CCMP, by presenting a
   number of interesting scenarios.  Section 8 addresses the XCON framework
   constructs.  As previously mentioned several
   scenarios that may involve the details use of the media
   control, call signaling sidebars.  Section 9 shows how
   CCMP can be used to remove conferences and floor control protocols, where
   applicable, are annotated in the flows without showing all the
   details.  However, for clarification purposes, users from the first example system.
   Finally, Section 5.1 11 provides the a few details of for what concerns the media control messaging along
   Security Considerations when it comes to implementing CCMP.

5.  Working with an example of the standard annotation used throughout CCMP

   This section aims at being a brief introduction to how the
   remainder of this document.  In subsequent flows, only this
   annotation (identified by lower case letters) is included
   Centralized Conferencing Manipulation Protocol (CCMP)
   [I-D.ietf-xcon-ccmp] works and the
   reader is encouraged to refer how it can be transported across a
   network.  Some words will be spent to the call flows in the describe a typical CCMP
   interaction, by focusing on relevant
   documents for details for aspects of the other protocols.  The annotations for
   the call signaling are on the left side of the conferencing server
   vertical bar and those client-server
   communication.  Please notice that this section is by no means to be
   considered as a replacement for the media control messaging are on the
   right side.

5.1.  Basic Conference Creation

   The simplest manner in CCMP document, which remains a conference can be created
   mandatory read before approaching the following sections.  It is
   accomplished by just
   conceived to help the client sending a "confRequest" message with reader take the
   "create" operation as first steps toward the only parameter actual
   protocol interactions.

   First of all, some lines will be devoted to the conference server, protocol by itself in
   Section 5.1, together with the "confUserID" associated with the requesting client
   itself.  This results in the creation some recommendations from an
   implementation point of a default conference, with view.  In Section 5.2, instead, an XCON-URI effective
   CCMP interaction will be presented by exploiting HTTP as a transport.
   Finally, a few words will be spent on notifications in the form of the "confObjID" parameter, the XCON-UserID Section 5.3.

   Once done with these preliminary steps, some actual flows will be
   presented and described in the form of the "confUserID" parameter (the same already present detail in the request) sections to follow.

5.1.  CCMP and the data Data Model

   CCMP is an XML-based protocol.  It has been designed as a request/
   response protocol.  Besides, it is completely stateless, which means
   implementations can safely handle transactions indipendently from
   each other.

   The protocol allows for the manipulation of conference object in objects and
   related users.  By manipulation it is implied, as the
   "confInfo" parameter all returned document
   specifies, that a Conferencing Client (briefly CMCC in all the "confResponse" message.
   According
   following sections) can create, update and remove basically
   everything that is related to the implementation of objects handled by a conferencing
   system.  This is reflected in the framework, this example may
   also add allowed operations (retrieve,
   create, update, delete) and the user that invoked the conference upon creation to the
   conference object (e.g., "method" attribute in specified request types (ranging from
   the "target" element manipulation of "allowed-users-list" may be set blueprints and conferences to "dial out" for this client
   based on the particular conferencing systems default).  This is
   exactly users and
   sidebars).  For instance, CCMP provides ways to:

   o  retrieve the case depicted list of registered and/or active conferences in the figure, which
      system;

   o  create new conferences by exploiting to 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.

   It is presented worthwile to enrich
   the scenario.  Note note that, depending upon while CCMP acts as the conferencing system,
   this default means to
   manipulate conference could be specific objects, its specification does not define
   these objects as well.  In fact, a separate document has been written
   to the client requesting
   the specify how a conference object and thus may all its components have to be different for
   constructed: the initiator than other
   participants (e.g., IVR interactions in this case which are not
   shown).

   The specific data Conference Information Data Model for Centralized
   Conferencing (XCON) [I-D.ietf-xcon-common-data-model].  CCMP,
   according to the request type and the related operation, carries
   pieces of conference objects (or any object is returned in the
   "confResponse" message in as a whole) according to
   the "confInfo" parameter. aforementioned specification.  This allows means that any implementation
   aiming at being compliant with CCMP has to make sure that the
   client (with
   transported objects are completely compliant with the appropriate authorization) to manipulate this data Data Model
   specification and add additional participants 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 conference, interested implementors
   take special care in carefully checking the Data Model handlers as
   well as change
   the data during the conference.  In addition, the client may
   distribute the conferencing information to other participants
   allowing them in order to join, the details of which avoid potential mistakes.

   Of course, there are provided cases where a mandatory element in
   additional flows.  Please notice that, according to the Data
   Model cannot be assigned in a conference object by a CCMP
   specification, user.  For
   instance, a CMCC may be requesting the restitution direct creation of the a new conference data
   conference: in this case, a conference object assumes an 'entity'
   element uniquely identifying the
   "confInfo" parameter is not mandatory: if the "confInfo" parameter of conference to be in place.  Anyway,
   the successful confResponse/create is void, CMCC has no way to a following confRequest/
   retrieve of priori know what the returned "confObjID" can entity will be triggered to provide like,
   considering it will only be generated by the
   requesting client with ConfS after the detailed conference description.

   Clients that are not XCON-aware may join request.
   For scenarios like this one, the conference using a
   specific signaling interface such as SIP [RFC3261], using CCMP specification envisages the
   signaling interface use
   of a dedicated placeholder wildcard to make the conference object
   compliant with the Data Model: the wildcard would then be replaced by
   the ConfS with the right value.

5.2.  Using HTTP as a transport

   [I-D.ietf-xcon-ccmp] presents several ways by which CCMP requests and
   responses can be transported from a client to a server and viceversa.
   Nevertheless, more focus is given on HTTP as described in
   [RFC4579].  However, these details are not shown a solution for this
   transport matter, and a whole chapter is devoted in the message
   flows.  The message flows in this document identity to
   how HTTP can be used for it.  This document is agnostic with respect
   to the point transport in use: this means that all the
   message call flows at which this signaling occurs via herein
   presented will just show the lower case
   letter items (i.e., (a)...(x)) along CCMP interactions, without talking about
   how the messages could have gone across the network.  Nevertheless,
   the following lines will provide a brief explanation, from a more
   practical point of view, of how HTTP might be exploited to carry CCMP
   messages.

   In case HTTP is used as a transport, the specification is very clear
   with respect to how the appropriate text for interaction has to occur.  Specifically, a
   CMCC is assumed to send his request as part of an HTTP POST message,
   and the processing done Server would reply by means of an HTTP 200 message.  In both
   cases, the conferencing server.

   CMCC1          CMCC2        CMCCx        CONFS           MS
     |               |           |           |             |
     |(1)confRequest(confUserID, create)     |             |
     |-------------------------------------->|             |
     |               |         (a)Create +---|             |
     |               |           |Conf   |   |             |
     |               |           |Object |   |             |
     |               |           |& IDs  +-->|             |
     |               |           |           | A1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           |(create conf)|--+ (b)
     | HTTP messages would have the CCMP messages as payload,
   which would be reflected in the Content-Type message.  Figure 1
   presents a ladder diagram of such interaction, which is followed by a
   dump of the exchanged HTTP messages for further analysis:

    CMCC                                           ConfS
      |                                              |
      | 1. HTTP POST (CCMP request)                  |
      |--------------------------------------------->|
      | create                                              |
      |                                              |--+ Parse request,
      |                                              |  | update object
      | conf                                              |<-+ and reply
      |                                              |
      |           | A2.                    2. 200 OK  |<-+ its ID
     |               |           |           |<<+++++++++++|
     |               |           |           |(confid=Y)   |
     |(2)confResponse(confUserID,confObjID,  |             |
     |                create, success,       |             |
     |                version, confInfo)     |             |
     |<--------------------------------------|             |
     |               |           |           |             |
     |               |     (c) Focus     +---|             |
     |               |         sets up   |   |             |
     |               |         signaling |   |             |
     |               |         to CMCC1  +-->|             |
     |               |           | (CCMP response) |
      |<---------------------------------------------|
      |                                              |
      |--+ Parse response and                        |
      |  | B1. CONTROL update local copy                         |
      |<-+ of conference object                      |
      |                                              |           |+++++++++++>>|
     |               |           |           | (join CMCC1 |
     |               |           |           | <->confY)   |
     |               |           |           |             |
     |               |           |           |             |--+(d) join
     |               |           |           |             |  | CMCC1 &
     |               |           |           | B2.200 OK   |<-+ conf Y
     |               |           |           |<<+++++++++++|
     |               |           |           |             |
     |<<#################################################>>|
     |        Now
      .                                              .
      .                                              .

                          Figure 1: CCMP on HTTP

   As it can be seen in the CMCC1 is mixed protocol dump in the conference     |
     |<<#################################################>>|
     |               |           |           |             |
     |******CMCC1 may then manipulate conference data *****|
     |****** following lines, the
   CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve'
   operation) towards the Conferencing Server (ConfS).  The request has
   been carried as payload of an HTTP POST (message 1.) towards a
   previously known location.  The mandatory 'Host' header has been
   specified, and add addt'l users, etc.      |        *****|
     '               '           '           '             '
     '               '           '           '             '
     '               '           '           '             '
             Figure 1: Create Basic Conference - Complete flow

    "Alice"        "Bob"
    CMCC1          CMCC2       CMCCx        CONFS
     |               |           |           |
     |(1)confRequest(confUserID, create)     |
     |-------------------------------------->|
     |               |           |           |
     |               |         (a)Create +---|
     |               |           |Conf   |   |
     |               |           |Object |   |
     |               |           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |           |  | creates
     |               |           |           |  | conf the 'Content-Type' header has been correctly set as
   well (application/ccmp+xml).

   The ConfS, in turn, has handled the request and
     |               |           |           |<-+ its ID
     |               |           |           |   (confid=Y)
     |(2)confResponse(confUserID, confObjID  |
     |               create, success,        |
     |               version, confInfo)      |
     |               |           |           |
     |<--------------------------------------|
     |               |           |           |
     |               |           |           |
     |               |     (c) Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to CMCC1  +-->|
     |               |           |           |
     |               |           |           |--+(d) MS joins
     |               |           |           |  | CMCC1 &
     |               |           |           |<-+ conf Y
     |<<###################################>>|
     | CMCC1 is mixed in replied accordingly.
   The response (a blueprintResponse with a 'success' response code) has
   been carried as payload of an HTTP 200 OK (message 2.).  As before,
   the conference      |
     |<<###################################>>|
     |               |           |           |
     |**CMCC1 then manipulates conference****|
     |** data and add addt'l users, etc.  ***|
     '               '           '           '
     '               '           '           '
     '               '           '           '
   -

            Figure 2: Create Basic Conference - Annotated Flow 'Content-Type' header has been correctly set (application/
   ccmp+xml).

1. confRequest/create message CMCC -> ConfS (HTTP POST, CCMP request)
------------------------------------------
   POST /Xcon/Ccmp HTTP/1.1
   Content-Length: 657
   Content-Type: application/ccmp+xml
   Host: example.com:8080
   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-conf-request-message-type">
                    xsi:type="ccmp:ccmp-blueprint-request-message-type">
           <confUserID>xcon-userid:Alice@example.com</confUserID>
        <operation>create</operation>
           <confObjID>xcon:AudioRoom@example.com</confObjID>
           <operation>retrieve</operation>
           <ccmp:blueprintRequest/>
     </ccmpRequest>
   </ccmp:ccmpRequest>

2. confResponse/create message 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-conf-response-message-type">
                 xsi:type="ccmp:ccmp-blueprint-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <confObjID>xcon:AudioRoom@example.com</confObjID>
       <operation>retrieve</operation>
       <response-code>success</response-code>
       <version>1</version>
       <ccmp:confResponse>
           <confInfo entity="xcon:8977794@example.com">
       <ccmp:blueprintResponse>
         <blueprintInfo entity="xcon:AudioRoom@example.com">
           <info:conference-description>
                  <info:display-text>
                     Default conference initiated by Alice
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@example.com
                        </info:uri>
                        <info:display-text>
                            Conference XCON-URI
                        </info:display-text>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
              <info:display-text>AudioRoom</info:display-text>
              <info:maximum-user-count>2</info:maximum-user-count>
              <info:available-media>
                <info:entry label="11"> label="audioLabel">
                    <info:type>audio</info:type>
                </info:entry>
                </info:available-media>
                    <info:conference-state>
                      <active>false</active>
                    </info:conference-state>
           </info:conference-description>
           <info:users>
              <xcon:join-handling>allow</xcon:join-handling>
                  <xcon:allowed-users-list>
                     <xcon:target uri="xcon-userid:Alice@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>
           </info:users>
           </confInfo>
       </ccmp:confResponse>
           <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>

     Figure 3: Create Basic Conference (Annotated) Detailed Messaging

5.2.  Basic Conference Creation

   Just for a specific instance the sake of Conference
      Information

   A conference can also completeness, a few words will be created by spent about
   the client sending a
   "confRequest" message with occurred CCMP interaction as well.  In fact, despite the "create" operation, along with
   simplicity of the
   desired data in request, this flow already provides some relevant
   information on how CCMP messages are built.  Specifically, both the form
   request and the response share a subset of the "confInfo" parameter for message:

   o  confUserID: this element, provided by the
   conference CMCC, refers to be created.  The request also includes the "confUserID"
      requester by means of his XCON-USERID; except in a few scenarios
      (presented in the requesting entity.  If following sections) this element must always
      contain a valid value;

   o  confObjID: this element refers to the conferencing system can support
   that specific type of target conference (capabilities, etc.), then object,
      according to the request results in place;

   o  operation: this element specifies the creation operation the CMCC wants to
      perform according to the specific request type.

   Besides those elements, the CMCC (in this case Alice, since the
   'confUserID' has been set to 'xcon-userid:Alice@example.com') has
   also provided an additional element, 'blueprintRequest'.  The name of a conference.
   that element varies according to the request type the CMCC is
   interested into.  In this success
   case, an 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 form of the "confObjID" parameter
   provided 'confObjID' target element), and so the
   XCON-UserID request consisted in
   an empty 'blueprintRequest' element.  As it will be clearer in the form of the "confUserID" parameter (again, the
   same
   following sections, different request types may require different
   elements, and as a consequence different content.

   Considering the requesting entity) are returned in request was a 'blueprintRequest', the "confResponse"
   message.  In this example, we choose not to return ConfS has
   replied with a 'blueprintResponse' element.  This element includes a
   complete dump of the created conference object in (compliant with the successful "confResponse" in Data
   Model) describing the "confInfo"
   parameter.

   This example also activates requested blueprint, together with an element
   addressing the conference upon creation (i.e.,
   "method" attribute is set to "dial out" for this client based on result of the
   particular conferencing systems default).  Just as before, client's request (response-
   code=success).

   This section won't delve in additional details for what concerns this
   interaction.  It is
   not to be considered mandatory, since it depends on just worth noticing that this was the
   implementation choices example of
   the framework.  Note that, depending upon
   the conferencing system, simplest CCMP communication that could take place between a CMCC
   and a ConfS, a blueprintRequest: this default scenario will be described in
   more detail in Section 6.2.

5.3.  Conference Notifications

   [RFC5239] presents several different possible protocol interactions
   between a conferencing server and a conferencing client.  One of
   those interactions is generically called "Notification Protocol",
   implementing a notification service for all clients interested in
   being informed by the server whenever something relevant happens in a
   conference.  While at first glance it may appear that such a
   functionality should belong to a conference could control protocol, such
   feature has been specifically marked as out of scope in CCMP.  As a
   consequence, CCMP has been conceived as a request/answer protocol,
   and in fact no ways to provide notifications to clients have been
   introduced in the specification.

   Nevertheless, the CCMP document by itself has a brief section
   presenting some typical ways notifications might be specific managed.  This
   example document does not foster one rather than another, and all the
   flows will always generically present a notification being involved,
   when it seems appropriate, but not providing any info on how the
   notification itself has been sent to the client requesting interested clients.  Anyway,
   this section will briefly introduce some of the conference most typical ways a
   notification service could be implemented and thus integrated with the
   functionality provided by CCMP.  It is by no means to be intended as
   a complete list of solutions: the aim of this section is to provide
   an overview of some of the possible solutions, together with
   indications on how they may be different integrated into a CCMP-based platform.

   The first approach that comes to mind is of course the XCON Event
   Package [I-D.ietf-xcon-event-package].  This specification extends
   the SIP Event Package for Conference State [RFC4575] and allows for
   the initiator than other participants (e.g., IVR interactions in this
   case which are not shown).

   "Alice"         "Bob"      "Carol"       CONFS
     |               |           |           |
     |               |           |           |
     |(1)confRequest(confUserID, |           |
     |         create, confInfo) |           |
     |               |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |         (a)Create +---|
     |               |           |Conf   |   |
     |               |           |Object |   |
     |               |           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |           |  | creates
     |               |           |           |  | conf notification of conference notifications by means of the NOTIFY/
   SUBSCRIBE mechanisms of SIP.  Specifically, any SIP client who
   subscribed for notifications related to a specific conference would
   receive notifications via SIP describing all the changes to the
   document.  An example ladder diagram is presented in Figure 2: in
   this figure, we assume a CMCC has updated a conference object, and
   the update is notified to a previously subscribed SIP client.

       CMCC                   ConfS                        UAC
        |                       |                           |           |<-+ its ID
        |                       |          1. SIP SUBSCRIBE |
        |   (confid=Y)
     |(2)confResponse(confUserID                       |<--------------------------|
        |             Handle +--|                           |
        |       confObjID, create,                new |  |                           |       success, version)
        |       subscription +->| 2. SIP 200 OK             |
     |<--------------------------------------|
        |                       |-------------------------->|
        |                       |                           |
        .                       .                           .
        .                       .                           .
        |                       |     (c) Focus     +---|                           |
        |         sets up 3. CCMP (add user)    |                           |
        |---------------------->|                           |
        |         signaling                       |--+ Add user               |
        |                       |  | to Alice  +-->|
     |               |           |           |
     |               |           |           |--+(d) MS joins
     |               |           |           |  | Alice &
     | conf.               |
        |                       |<-+ conf Y
     |               |           |           |
     |               |           |           |
     |<<###################################>>|
     | Alice is mixed in the conference      |
     |<<###################################>>| object                 |
        |     4. CCMP (success) |                           |
        |<----------------------|                           |
        |     (e)Focus      +---|                       | 5. SIP NOTIFY (changes)   |        sets up
        |                       |-------------------------->|
        |                       |             6. SIP 200 OK |        signaling
        |                       |<--------------------------|
        |                       |                           |
        .                       .                           .
        .                       .                           .

              Figure 2: XCON Event Package: SIP notifications

   While simple and effective, this solution has a drawback: it assumes
   that all clients to Bob     |   |
     |               |           |       +-->|
     |               | be notified have a SIP stack.  In fact, the
   approach relies on the SIP SUBSCRIBE/NOTIFY mechanism.  This means
   that a client without a SIP stack would be unable to receive
   notifications, in case no other means were available.  Of course this
   is not a desired situation in a framework as XCON which has been
   conceived as being protocol-agnostic.

   Considering CCMP is going to be probably most often deployed on HTTP,
   another way to achieve notifications might be by exploiting some sort
   of HTTP callbacks, as suggested in the CCMP specification itself.
   This would allow to overcome the previous limitation, since both the
   CMCC and the ConfS would already have an HTTP stack to make use of.
   Using this approach, an interested web client might provide the
   Conferencing System with an URL to contact whenever updates are
   available: the update could be part of the notification message
   itself, or it could be only implicitly referenced by the
   notification.  At the same time, alternative notification means could
   be exploited, e.g. by taking advantage of functionality provided by
   other protocols as XMPP.  Figure 3 shows an example of different
   subscriptions which accordingly trigger notifications after the same
   relevant event happens.

      CMCC                 ConfS                       Sub1         Sub2
       |                     |                           |            |
       |           |--+(f)MS joins                     |      1. Register callback |            |
       |                     |<--------------------------|            | Bob &
       |           Handle +--|                           |            |           |<-+ conf Y
       |         new HTTP |  |                           |            |               |<<###################>>|
       |     subscription +->| 2. Acknlowledge           |  Bob is mixed too            |
       |               |<<###################>>|                     |-------------------------->|            |
       |                     |                           |            |
       |     (g )Focus     +---|                     |                   3. XMPP subscription |         sets up
       |                     |<---------------------------------------|
       |           Handle +--|                           |            |         signaling
       |         new XMPP |  |                           |         to Carol            |
       |     subscription +->| 4. XMPP confirm subscription           |
       |         CMCCx     +-->|                     |--------------------------------------->|
       |                     |                           |            |
       .                     .                           .            .
       .                     .                           .            .
       |                     |                           |           |--+(h)MS joins            |
       | 5. CCMP (add user)  |                           |            | CMCCx &
       |-------------------->|                           |            |
       |                     |--+ Add user               |            |
       |                     |  | to conf.               |            |
       |                     |<-+ conf Y object                 |            |
       |   6. CCMP (success) |                           |            |           |<<#######>>|
       |<--------------------|                           |            |           |Carol mixed|
       |                     |           |<<#######>>| 7. HTTP POST (changes)    |            |
       |                     |-------------------------->|            |
       |                     |            8. HTTP 200 OK |            |
       |                     |<--------------------------|            |
       |                     |
     |<***All parties connected to conf Y***>|                           |            |
       |                     | 9. XMPP notification      |            |
       |                     |--------------------------------------->|
       |
     "               "           "           "
     "               "           "           "
     "               "           "           "

   Figure 4: Create Basic Conference from user provided conference-info

  1. confRequest/create message

    <?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-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <operation>create</operation>
        <ccmp:confRequest>
           <confInfo>
              <info:conference-description>
                  <info:display-text>
                     Dial-out conference initiated by Alice
                  </info:display-text>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry>
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
               </info:conference-description>
               <info:users>
                  <xcon:join-handling>allow</xcon:join-handling>
                  <xcon: allowed-users-list>
                     <xcon:target uri="sip:alice@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:bob83@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:carol@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>
               </info:users>
           </confInfo>
        </ccmp:confRequest>
     </ccmpRequest>
  </ccmp:ccmpRequest>

  2. confResponse message

  <?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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:6845432@example.com</confObjID>
       <operation>create</operation>
       <response-code>success<response-code>
       <version>1</version>
      </ccmpResponse>
  </ccmp:ccmpResponse>                     |                           |            |
       .                     .                           .            .
       .                     .                           .            .

               Figure 5: Create Basic Conference Detailed Messaging

5.3.  Basic Conference Creation - Cloning an existing Conference 3: Alternative means for notifications

   That said, there are actually many other ways to achieve
   notifications in a conferencing system.  A client can also create another conference by cloning an existing
   conference, such as an active conference or conference reservation.
   In this example, conferencing system may
   rely on several other solutions than the client sends ones presented as periodic
   checks of a "confRequest" message with well known URL by interested clients, long polls, BOSH-
   based communications, Atom/RSS feeds and the
   "create" operation, along like.

6.  Conference Creation

   This section starts the sequence of call flows of typical XCON-
   related scenarios provided in this document.  Specifically, it
   provides details associated with the "confUserID" and a specific
   "confObjID", from various ways in which a new
   conference is to can be created by cloning
   an existing conference.

   An example using CCMP and the XCON framework
   constructs.  As previously mentioned the details of how a client can create a conference based on a
   blueprint is provided in Section 5.4.  The manner by which a client the media
   control, call signaling and floor control protocols, where
   applicable, are annotated in this example might learn about a conference reservation or active
   conferences is similar the flows without showing all the
   details.  This also applies to CCMP, whose flows are related to the
   protocol alone, hiding any detail concerning the transport that may
   have been used (e.g.  HTTP).  However, for clarification purposes,
   the first step in example Section 6.1 provides the blueprint example, details of the media
   control messaging along with an example of the exception standard annotation
   used throughout the remainder of specifying querying this document.  In subsequent flows,
   only this annotation (identified by lower case letters) is included
   and the reader is encouraged to refer to the call flows in the
   relevant documents for different types details about the other protocols.  The
   annotations for the call signaling are on the left side of
   conference objects supported by the specific
   conferencing system.
   For example, in this example, server vertical bar and those for the client clones media control
   messaging are on the right side.

6.1.  Basic Conference Creation

   The simplest manner in which a conference
   reservation (i.e., an inactive conference).

   If the conferencing system can support be created is
   accomplished by the client sending a new instance of "confRequest" message with the specific
   type of conference(capabilities, etc.), then
   "create" operation as the request only parameter to the conference server,
   together with the "confUserID" associated with the requesting client
   itself.  This results in the creation of a default conference, with
   an XCON-URI in the form of a new
   value in the "confObjID" parameter, the XCON-USERID
   in the form of the "confUserID" parameter to reflect (the same already present
   in the request) and the data for the newly cloned conference object in the
   "confInfo" parameter all returned in the "confResponse" message.

   "Alice"                       ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, create)      |
    |------------------------------>|
    |                 (a)Create +---|
    |                    Conf   |   |
    |                    Object |   |
    |                    & IDs  +-->|
    |                               |--+ (b) MS
    |                               |  | creates
    |                               |  | conf and
    |                               |<-+ its ID
    |                               |   (confid=Y)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID*,create,       |
    |      success, version,        |
    |      confInfo)                |
    |                               |
    |<------------------------------|
    |                               |

                 Figure 6: Create Basic Conference - Clone

   1.  "Alice" sends a confRequest message
   According to clone a conference based
       on an existing conference reservation.  "Alice" indicates this
       conference should be cloned from the specified parent conference
       represented by the "confObjID" in the request.

   2.  Upon receipt implementation of the confRequest message containing a "create"
       operation and "confObjID", framework, this example may
   also add the conferencing system ensures user that invoked the "confObjID" received is valid.  The conferencing system
       determines conference upon creation to the appropriate read/write access
   conference object (e.g., "method" attribute in the "target" element
   of any users to "allowed-users-list" may be
       added set to a conference "dial out" for this client
   based on this "confObjID" (using
       membership, roles, etc.).  The conferencing system uses the
       received "confObjID" to clone a conference reservation.  The particular conferencing system also reserves or allocates a new "confObjID"
       (called "confObjID*" in Figure 6) to be used for the cloned
       conference object. systems default).  This new identifier is of course different
       from
   exactly the one associated with case depicted in the conference figure, which is presented to be cloned, since
       it represents a different conference object.  Any subsequent
       protocol requests from any of the members of enrich
   the conference must
       address this new identifier. scenario.

   The conferencing system maintains
       the mapping between this conference ID and specific data for the parent conference object ID associated with are returned in the reservation through
   "confResponse" message in the conference
       instance, "confInfo" parameter.  This allows the
   client (with the appropriate authorization) to manipulate these data
   and this mapping is explicitly addressed through add additional participants to the
       "cloning-parent" element of conference, as well as change
   the "conference-description" data during the conference.  In addition, the client may
   distribute the conferencing information to other participants
   allowing them to join, the details of which are provided in
   additional flows.  Please notice that, according to the CCMP
   specification, the return of the new conference object.

1. confRequest/create message

  <?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-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:6845432@example.com</confObjID>
        <operation>create</operation>
     </ccmpRequest>
  </ccmp:ccmpRequest>

2. data in the
   "confInfo" parameter is not mandatory: if the "confInfo" parameter of
   the successful confResponse/create message

   <?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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>success</response-code>
       <version>1</version>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from 6845432
                  </info:display-text>
                  <xcon:cloning-parent>
                      xcon:6845432@example.com
                  </xcon:cloning-parent>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
               </info:conference-description>
               <info:users>
                   <xcon:join-handling>allow</xcon:join-handling>
                      <xcon: allowed-users-list>
                     <xcon:target uri="sip:alice@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:bob83@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:carol@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>
               </info:users>
                  <xcon:floor-information>
                     <xcon:floor-request-handling>
                        confirm</xcon:floor-request-handling>
                     <xcon:conference-floor-policy>
                       <xcon:floor id="11"/>
                     </xcon:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

       Figure 7: Create Basic Conference (Clone) Detailed Messaging

5.4.  Conference Creation using Blueprints

   Figure 8 provides an example is void, a following confRequest/
   retrieve of one the returned "confObjID" can be triggered to provide the
   requesting client "Alice" determining with the detailed conference blueprints available for a particular conferencing system
   and creating a conference based on description.

   Clients that are not XCON-aware can join the desired blueprint.

   CMCC "Alice"                   ConfS
    |                               |
    | (1) blueprintsRequest         |
    |      (confUserID)             |
    |------------------------------>|
    |                               | conference using a
   specific signaling interface such as SIP [RFC3261] or other supported
   signaling protocols (being XCON agnostic with respect to them), using
   the signaling interface to the conference focus as described in
   [RFC4579].  However, these details are not shown in the message
   flows.  The message flows in this document identify the point in the
   message flows at which this signaling occurs via the lower case
   letter items (i.e., (a)...(x)) along with the appropriate text for
   the processing done by the conferencing server.

   As anticipated at the beginning of this section, this example also
   shows how the conferencing system may make use of other standard
   components to make available its functionality.  An example of that
   is the MEDIACTRL specification, which allows the conferencing system
   to configure conference mixes, IVR dialogs and all sort of media-
   related interactions an application like this may need.  So, just to
   provide the reader with some insight on these interactions, the
   conferencing system also configures and starts a mixer via MEDIACTRL
   as soon as the conference is created (transactions A1 and A2), and
   attaches clients to it when necessary (e.g. when CMCC1 joins the
   conference by means of SIP signaling, its media channels are attached
   to the Media Server using MEDIACTRL in B1/B2).

   CMCC1          CMCC2        CMCCx       ConfS          MS
     |        (2) blueprintsResponse               |           |      (confUserID, success,           |             |              blueprintsInfo)
     |(1)confRequest(confUserID, create)     |
    |<------------------------------|             |
     |-------------------------------------->|             |
    |--+
     |               |         (a)Create +---|             | choose preferred
     |               |           |Conf   | blueprint from the   |             |
     | list (blueprintName)               |
    |<-+           |Object |   |             |
     | (3) blueprintRequest               |           |& IDs  +-->|             | (confUserID,confObjID,
     |               |  retrieve)           |
    |------------------------------>|           | A1. CONTROL |
     |      4) blueprintResponse               |           |         (confUserID,confObjID,|           |+++++++++++>>|
     |          retrieve,confInfo)               |
    |<------------------------------|           |           |(create conf)|--+ (b)
     |               | (5) confRequest(confUserID,           |           |     confObjID,create)             |
    |------------------------------>|  | create
     |               |                 (a)Create +---|           |                    Conf           |             |  |                    Object conf and
     |               |           |                    & IDs  +-->|           |                               |--+ (b) MS A2. 200 OK  |<-+ its ID
     |               |           | creates           |<<+++++++++++|
     |               |           | conf and
    |                               |<-+ its ID           |(confid=Y)   |
     |(2)confResponse(confUserID,confObjID,  |   (confid=Y)
    |(6) confResponse             |
     | (create,                create, success,       |             |  confObjID*, confUserID)
     |
    |<------------------------------|                version, confInfo)     |             |
     |<--------------------------------------|             |
     |               |           |           |             |
     |               |     (c) Focus     +---|             |
     |               |         sets up   |   |             |
     |               |         signaling |   |             |
     |               |
    .                               .
    .                               .

         Figure 8: Client Creation of Conference using Blueprints

   1.  "Alice" first sends a "blueprintsRequest" message         to CMCC1  +-->|             |
     |               |           |           |             |
     |               |           |           | B1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           | (join CMCC1 |
     |               |           |           | <->confY)   |
     |               |           |           |             |
     |               |           |           |             |--+(d) join
     |               |           |           |             |  | CMCC1 &
     |               |           |           | B2.200 OK   |<-+ conf Y
     |               |           |           |<<+++++++++++|
     |               |           |           |             |
     |<<#################################################>>|
     |        Now the
       conferencing system identified by the conference server discovery
       process.  Upon receipt of the "blueprintsRequest", the
       conferencing system would first authenticate "Alice" and then
       ensure that "Alice" has the appropriate authority based on system
       policies to receive any blueprints supported by that system.

   2.  Any blueprint that "Alice" CMCC1 is authorized to use are returned in a
       "blueprintsResponse" message mixed in the "blueprintsInfo" attribute.

   3.  Upon receipt of the "blueprintsResponse" containing the
       blueprints, "Alice" determines which blueprint to use for the conference to be created.  "Alice" sends a "blueprintRequest"
       message to get the specific blueprint as identified by the
       "confObjID".

   4.  The conferencing system returns the "confInfo" associated with
       the specific blueprint as identified by the 'confObjID' in the
       "blueprintResponse" message.

   5.  "Alice"     |
     |<<#################################################>>|
     |               |           |           |             |
     |******CMCC1 may then sends a "confRequest" with a "create" operation to
       the conferencing system to create a manipulate conference reservation,
       including the appropriate "blueprintName" data *****|
     |****** and associated
       "confObjID".

   6.  Upon receipt of the "confRequest" message with a "create"
       operation, the conferencing system uses the received blueprint add addt'l users, etc.      |        *****|
     '               '           '           '             '
     '               '           '           '             '
     '               '           '           '             '
             Figure 4: Create Basic Conference - Complete flow

    "Alice"        "Bob"
    CMCC1          CMCC2       CMCCx       ConfS
     |               |           |           |
     |(1)confRequest(confUserID, create)     |
     |-------------------------------------->|
     |               |           |           |
     |               |         (a)Create +---|
     |               |           |Conf   |   |
     |               |           |Object |   |
     |               |           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |           |  | creates
     |               |           |           |  | conf and
     |               |           |           |<-+ its ID
     |               |           |           |   (confid=Y)
     |(2)confResponse(confUserID, confObjID  |
     |               create, success,        |
     |               version, confInfo)      |
     |               |           |           |
     |<--------------------------------------|
     |               |           |           |
     |               |           |           |
     |               |     (c) Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to
       clone a conference, allocating a new "confObjID" (again called
       "confObjID* CMCC1  +-->|
     |               |           |           |
     |               |           |           |--+(d) MS joins
     |               |           |           |  | CMCC1 &
     |               |           |           |<-+ conf Y
     |<<###################################>>|
     | CMCC1 is mixed in the example).  The conferencing server then sends
       a "confResponse" message including the new "confObjID*"
       associated with the newly created conference instance.  Upon
       receipt of the "confResponse" message, "Alice" can now      |
     |<<###################################>>|
     |               |           |           |
     |**CMCC1 then manipulates conference****|
     |** data and add other
       users to the conference . addt'l users, etc.  ***|
     '               '           '           '
     '               '           '           '
     '               '           '           '
   -

            Figure 5: Create Basic Conference - Annotated Flow

1. blueprintsRequest confRequest/create message (Alice creates a default conference)

  <?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="xcon:ccmp-blueprints-request-message-type">
           xsi:type="ccmp:ccmp-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <operation>create</operation>
     </ccmpRequest>
  </ccmp:ccmpRequest>

2. blueprintsResponse confResponse/create message ("success", created conference
   object returned)

  <?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-blueprints-response-message-type">
         xsi:type="ccmp:ccmp-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>success</response-code>
        <ccmp:blueprintsResponse>
         <blueprintsInfo>
          <info:entry>
           <info:uri>xcon:AudioRoom@example.com</info:uri>
           <info:display-text>AudioRoom</info:display-text>
           <info:purpose>Simple Room:
       <version>1</version>
       <ccmp:confResponse>
           <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     Default conference room with public access,
              where only audio is available, more users
              can talk at initiated by Alice
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@example.com
                        </info:uri>
                        <info:display-text>
                            Conference XCON-URI
                        </info:display-text>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
                    <info:conference-state>
                      <active>false</active>
                    </info:conference-state>
               </info:conference-description>
               <info:users>
                  <xcon:join-handling>allow</xcon:join-handling>
                  <xcon:allowed-users-list>
                     <xcon:target uri="xcon-userid:Alice@example.com" \
                                  method="dial-out"/>
                   </xcon:allowed-users-list>
               </info:users>
           </confInfo>
       </ccmp:confResponse>
     </ccmpResponse>
  </ccmp:ccmpResponse>

     Figure 6: Create Basic Conference (Annotated) Detailed Messaging

6.2.  Conference Creation using Blueprints

   The previous example showed the same time
              and creation of a new conference using
   default values.  This means the requests for client provided no information about
   how she wanted the AudioFloor
              are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:VideoRoom@example.com</info:uri>
           <info:display-text>VideoRoom</info:display-text>
           <info:purpose>Video Room: conference room with public access,
               where both audio and video are available,
               8 users can talk and to be seen at like.  Anyway, the same time,
               and XCON framework
   (and CCMP as a consequence) allows for the floor requests exploitation of templates.
   These templates are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:AudioConference1@example.com</info:uri>
           <info:display-text>AudioConference1</info:display-text>
           <info:purpose>Public Audio Conference: called "conference blueprints", and are basically
   conference objects with public access,
                where only audio is available,
                only pre-defined settings except for the actual
   identifiers.  This means that a client might get one user can talk at of these
   blueprints, choose the same time, one that more fits his needs, and use the requests for the AudioFloor MUST
                be accepted by
   chosen blueprint to create a Chair.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:VideoConference1@example.com</info:uri>
           <info:display-text>VideoConference1</info:display-text>
             <info:purpose>Public Video Conference: new conference.

   This section addresses exactly this scenario, and Figure 7 provides
   an example of one client, "Alice", discovering the conference
                 where
   blueprints available for a particular conferencing system and
   creating a conference based on the desired blueprint.  In particular,
   Alice is interested in those blueprints suitable to represent a
   "video-conference", i.e. a conference in which both audio and video
   are available,
                 only one user can talk
             </info:purpose>
           </info:entry>
           <info:entry>
            <info:uri>xcon:AudioConference2@example.com</info:uri>
            <info:display-text>AudioConference2</info:display-text>
            <info:purpose>Basic Audio Conference:
                 conference with private access,
                 where only audio is available,
                 only one user can talk at the same time,
                 and the requests for so she exploits the AudioFloor MUST
                 be accepted filter mechanism envisioned by
   CCMP to make a Chair.
            </info:purpose>
           </info:entry>
        </blueprintsInfo>
      </ccmp:blueprintsResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

3. blueprintRequest/retrieve message

   <?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>

4. blueprintResponse/retrieve message

<?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>success</response-code>
       <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>

5. confRequest/create message

  <?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-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:AudioRoom@example.com</confObjID>
        <operation>create</operation>
        <ccmp:confRequest/>
     </ccmpRequest>
  </ccmp:ccmpRequest>

6. confResponse/create message

  <?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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>success</response-code>
       <version>1</version>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned selective blueprints retrieve request.  This results
   in three distinct CCMP transactions.

   CMCC "Alice"                   ConfS
    |                               |
    | (1) blueprintsRequest         |
    |    (confUserID,xpathFilter)   |
    |------------------------------>|
    |                               |
    |        (2) blueprintsResponse |
    |      (confUserID, success,    |
    |              blueprintsInfo)  |
    |<------------------------------|
    |                               |
    |--+                            |
    |  | choose preferred           |
    |  | blueprint from AudioRoom
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@example.com
                        </info:uri>
                        <info:display-text>
                            conference xcon-uri
                        </info:display-text>
                        <xcon:conference-password>
                            8601
                        </xcon:conference-password>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <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="11"/>
                     </xcon:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

        Figure 9: Create Conference (Blueprint) Detailed Messaging

6.  General Conference scenarios and examples

   The following scenarios are based on those documented in the XCON
   framework.  The examples assume that a conference has already been
   correctly established, with media, if applicable, per one of the
   examples in Section 5.

6.1.  Conference Announcements and Recordings

   In this example, as shown in Figure 10 "Alice" is joining "Bob"'s
   conference that requires that she first enter a pass code.  After
   successfully entering the passcode, an announcement prompts "Alice to
   speak her name so it can be recorded.  When "Alice" is added to the
   active conference, the recording is played back to all the existing
   participants.  A very similar example is presented in Figure 33 of
   [I-D.ietf-mediactrl-call-flows].

   CCMC "Alice"                    ConfS                         MS
        |                            |                            |
        |(1)userRequest(confUserID,  |                            |
        |   confObjID,create,userInfo)                            |
        |--------------------------->|                            |
        |                            |--+ Alice is         |
    |  |  | new in the              | list (blueprintName)       |
    |<-+ system (create                            |
    |                               |    confUserID)
    | (3) blueprintRequest          |           ConfS handles +--|
    | (confUserID,confObjID,        |           SIP signaling
    |  retrieve)                    |
    |------------------------------>|
    |                               |    (Alice<->ConfS<->MS) +->|
    |      4) blueprintResponse     |
    |         (confUserID,confObjID,|
    |          retrieve,confInfo)   |                            |--+ A password is
    |<------------------------------|
    |                               |
    | (5) confRequest(confUserID,   | required for
    |     confObjID,create)         |                            |<-+ that conference
    |------------------------------>|
    |                               |
    |                 (a)Create +---|
    |                    Conf   |   | Request IVR menu (PIN)
    |                    Object |                            |--------------------------->|   |
    |                    & IDs  +-->|
    |
        |<=========                               |--+ (b) MS gets PIN from Alice through DTMF =========>|
    |                               |  | creates
    |                               |        Provided PIN is...  | conf and
    |                            |<---------------------------|                               |<-+ its ID
    |                   Check +--|                               |   (confid=Y)
    |(6) confResponse               |                     PIN
    | (confUserID, confObjID*,      |
    |  create, success)             |                         +->|
    |<------------------------------|
    |                               |                            |--+ Alice must              |
        |                            |  | record her              |
        |                            |<-+ name                    |
        |                            |                            |
        |                            | Request name recording     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS records Alice's audio RTP (name) =========>|
        |                            |                            |
        |                            |            Audio recording |
        |                            |<---------------------------|
        |                Complete +--|                            |
        |                creation
    |                               |
    |                               |
    .                               .

    .                               .

         Figure 7: Client Creation of Conference using Blueprints

   1.  Alice +->|                            |
        |                            |                            |
        |                            |                            |
        | (2)userResponse(confUserID,|                            |
        |        confObjID, create,  |                            |
        |        success, version)   |                            |
        |<---------------------------|                            |
        |                            |                            |
                  Figure 10: Recording first sends a "blueprintsRequest" message to the
       conferencing system identified by the conference server discovery
       process.  This request contains the "confUserID" of the user
       issuing the request (Alice's XCON-USERID) and Announcements

   1. the "xpathFilter"
       parameter by which Alice specifies she desires to obtain only
       blueprints providing support for both audio and video: for this
       purpose, the xpath query contained in this field is: "/
       conference-info[conference-description/available-media/entry/
       type='audio' and conference-description/available-media/entry/
       type='video'"] .  Upon receipt of the userRequest from "Alice" to be added to
       "Bob's" conference (i.e., an "update" operation on "Bob's"
       conference object), "blueprintsRequest", the
       conferencing system determines would first authenticate Alice and then
       ensure that a
       password is required for this specific conference.  Thus an
       announcement asking "Alice" Alice has the appropriate authority based on system
       policies to enter receive the password requested kind of blueprints supported by
       that system.

   2.  All blueprints that Alice is provided authorized to
       "Alice".  This may be achieved by means use are returned in a
       "blueprintsResponse" message in the "blueprintsInfo" element.

   3.  Upon receipt of typical IVR
       fucntionality.  Once "Alice" enters the password, it is validated
       against "blueprintsResponse" containing the policies associated with "Bob's" active conference.
       The conferencing system then connects to a server
       blueprints, Alice determines which prompts
       and records "Alice's" name.  The conferencing system must also
       determine whether "Alice" is already a user of this conferencing
       system or whether she is a new user.  In this case, "Alice" is a
       new user for this conferencing system, so a conference user
       identifier is created for "Alice".  Based upon the addressing
       information provided by "Alice", the call signaling to add
       "Alice" blueprint to use for the
       conference is instigated through the Focus.

   2.  The conference server to be created.  Alice sends "Alice" a userResponse "blueprintRequest"
       message which
       includes to get the "confUserID" assigned specific blueprint as identified by the
       "confObjID".

   4.  The conferencing system for
       "Alice".  This would allow "Alice" to later perform operations on
       the conference (if she were to have returns the appropriate policies),
       including registering for event notifications "confInfo" associated with
       the
       conference.  Once specific blueprint as identified by the call signaling indicates that "Alice" has
       been successfully added 'confObjID' in the
       "blueprintResponse" message.

   5.  Alice finally sends a "confRequest" with a "create" operation to
       the specific conference, per updates conferencing system to create a conference reservation
       cloning the state, and depending upon chosen blueprint.  This is achieved by writing the policies, other participants
       (e.g., "Bob") are notified of
       blueprint's XCON-URI in the addition "confObjID" parameter.

   6.  Upon receipt of "Alice" the "confRequest" message with a "create"
       operation, the conferencing system uses the received blueprint to
       clone a conference, allocating a new XCON-URI (again called
       "confObjID*" in the
       conference via example).  The conferencing server then sends
       a "confResponse" message including the new "confObjID*"
       associated with the newly created conference notification service and an
       announcement is provided to all instance.  Upon
       receipt of the participants indicating that
       "Alice" has joined "confResponse" message, Alice can now add other
       users to the conference. conference .

 1. userRequest/create blueprintsRequest message (Alice tries to enter requires the conference without providing list of the password)
    available blueprints)

<?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-user-request-message-type">
         xsi:type="xcon:ccmp-blueprints-request-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>create</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Alice@example.com">
                <info:associated-aors>
                    <info:entry>
                        <info:uri>
                           mailto:Alice83@example.com
                        </info:uri>
                        <info:display-text>email</info:display-text>
                    </info:entry>
                </info:associated-aors>
                <info:endpoint entity="sip:alice_789@example.com"/>
            </userInfo>
        </ccmp:userRequest>
       <ccmp:blueprintsRequest>
                <xpathFilter>/conference-info[
                   conference-description/available-media/entry/type='audio' and
               conference-description/available-media/entry/type='video']
            </xpathFilter>
       </ccmp:blueprintsRequest>
    </ccmpRequest>
   </ccmp:ccmpRequest>

2.      userResponse/create blueprintsResponse message ("passwordRequired") (the server provides a descriptions of
   the available blueprints)

   <?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"
    xmlns:xcon="urn:ietf:params:xml:ns:xcon-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-user-response-message-type">
       xsi:type="ccmp:ccmp-blueprints-response-message-type">
      <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>create</operation>
        <ccmp:response-code>passwordRequired</ccmp:response-code>
        <ccmp:userResponse/>
      <response-code>success</response-code>
        <ccmp:blueprintsResponse>
         <blueprintsInfo>
          <info:entry>
           <info:uri>xcon:VideoRoom@example.com</info:uri>
           <info:display-text>VideoRoom</info:display-text>
           <info:purpose>Video Room:
               conference room with public access,
               where both audio and video are available,
               4 users can talk and be seen at the same time,
               and the floor requests are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:VideoConference1@example.com</info:uri>
           <info:display-text>VideoConference1</info:display-text>
             <info:purpose>Public Video Conference: conference
                 where both audio and video are available,
                 only one user can talk
             </info:purpose>
           </info:entry>
        </blueprintsInfo>
      </ccmp:blueprintsResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

3.      userRequest/create blueprintRequest/retrieve message (Alice provides wants the password)
   "VideoRoom" blueprint)

   <?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-user-request-message-type">
                    xsi:type="ccmp:ccmp-blueprint-request-message-type">
           <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>create</operation>
        <password>8601</password>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Alice@example.com">
                <info:associated-aors>
                    <info:entry>
                        <info:uri>
                           mailto:Alice83@example.com
                        </info:uri>
                        <info:display-text>email</info:display-text>
                    </info:entry>
                </info:associated-aors>
                <info:endpoint entity="sip:alice_789@example.com"/>
            </userInfo>
        </ccmp:userRequest>
           <confObjID>xcon:VideoRoom@example.com</confObjID>
           <operation>retrieve</operation>
           <ccmp:blueprintRequest/>
     </ccmpRequest>
   </ccmp:ccmpRequest>

4.      userResponse/create blueprintResponse/retrieve message ("success") ("success", "VideoRoom"
   conference object returned)

<?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:VideoRoom@example.com</confObjID>
       <operation>retrieve</operation>
       <response-code>success</response-code>
       <ccmp:blueprintResponse>
         <blueprintInfo entity="xcon:VideoRoom@example.com">
           <info:conference-description>
              <info:display-text>VideoRoom</info:display-text>
              <info:maximum-user-count>4</info:maximum-user-count>
              <info:available-media>
                <info:entry label="audioLabel">
                    <info:type>audio</info:type>
                </info:entry>
                <info:entry label="videoLabel">
                    <info:type>video</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:floor id="videoLabel"></xcon:floor>
             </xcon:conference-floor-policy>
           </xcon:floor-information>
         </blueprintInfo>
       </ccmp:blueprintResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

5. confRequest/create message (Alice clones the "AudioRoom" blueprint)

  <?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-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:VideoRoom@example.com</confObjID>
        <operation>create</operation>
        <ccmp:confRequest/>
     </ccmpRequest>
  </ccmp:ccmpRequest>

6. confResponse/create message ("success", cloned conference
   object returned)

  <?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-user-response-message-type">
         xsi:type="ccmp:ccmp-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>success</response-code>
        <version>10</version>
        <ccmp:userResponse/>
    </ccmpResponse>
</ccmp:ccmpResponse>

                 Figure 11: Announcement Messaging Details

6.2.  Monitoring for DTMF

   The conferencing system also needs the capability to monitor for DTMF
       <version>1</version>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from each individual participant.  This would typically VideoRoom
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@example.com
                        </info:uri>
                        <info:display-text>
                            conference xcon-uri
                        </info:display-text>
                        <xcon:conference-password>
                            8601
                        </xcon:conference-password>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <info:type>audio</info:type>
                          </info:entry>
                          <info:entry label="12">
                              <info:type>video</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="11"/>
                       <xcon:floor id="12"/>
                     </xcon:conference-floor-policy>

                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

        Figure 8: Create Conference (Blueprint) Detailed Messaging

6.3.  Conference Creation using User-Provided Conference Information

   A conference can also be used to
   enter created by the identifier and/or access code for joining client sending a specific
   conference.

   An example of DTMF monitoring, within
   "confRequest" message with the context of "create" operation, along with the framework
   elements, is shown
   desired data in Figure 10.  A typical way the form of the "confInfo" parameter for the conferencing
   system
   conference to be aware of all the DTMF interactions within created.  The request also includes the context of
   conferences it is responsible for, is making use "confUserID"
   of the MEDIACTRL
   architecture for what regards media manipulation.  Examples in that
   sense (specifically requesting entity.

   This approach allows for what concerns DTMF interception in conference
   instances) are presented in [I-D.ietf-mediactrl-call-flows].

6.3.  Adding a Party

   In client (in this example, "Alice" wants to add "Bob" to an established
   conference.  In the following example we assume "Bob" is a new user Alice) to
   completely describe how the system, conference object should look like,
   without just relying on defaults or blueprints: i.e. which means "Alice" also needs to provide details
   about him.  In fact, media
   should be available, whish should be the case of "Bob" already present as a user in topic, the conferencing system is much easier users allowed to address,
   join, any scheduling-related information and will be
   discussed later so on.

    "Alice"        "Bob"
    CMCC1          CMCC2       CMCCx        ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |    confObjID, create,     |           |
     |    userInfo)  |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |        (a) Create +---|
     |               |           | "Bob" |   |
     |               |           |  This can be
   done, as anticipated, by providing in the creation request a  |   |
     |               |           | user  +-->|
     |               |           |           |
     |(2) userResponse(confUserID,confObjID  |
     |           create,success,userInfo)    |
     |<--------------------------------------|
     |               |           |           |
     |               |           | (b) Focus |
     |               |           |   sets up |
     |               |           | signaling |
     |               |           | full
   conference object for the server to "Bob" |
     |               |<----------------------|
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  joined") |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

        Figure 12: Client Manipulation parse.

   This "confInfo" parameter must comply of Conference - Add a party

   1.  "Alice" sends a userRequest message course with an operation of "create"
       to add "Bob" to the specific conference as identified by the
       confObjID.  The "create" operation also makes sure Data Model
   specification.  This means that "Bob" its "entity" attribute is
       created as a user mandatory,
   and cannot be missing in the whole conferencing system.  This document.  Nevertheless, considering in
   this example the client is done
       by adding actually requesting the creation of a "userInfo" element describing "Bob" as new
   conference, which doesn't exist yet, this "entity" attribute cannot
   be set to a user. valid value.  This is needed in order related to let an issue already
   anticipated in Section 5.1.  To cope with this, the conferencing system be aware CCMP protocol
   fosters the use of
       "Bob"'s characteristics.  In case Bob was already a registered
       user, "Alice" would just have referenced him through his XCON
       UserID, without providing the additional "userInfo".  In fact,
       that information (including, for instance, "Bob"'s SIP URI to be
       used subsequently for dial-out) wildcard placeholder: this placeholder
   ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim
   of making the "confInfo" element compliant with the Data Model, and
   would subsequently be obtained replaced by referencing the extant registration.  The conference server ensures that
       "Alice" has conferencing system with the appropriate authority based on
   actual value.  This means that, as soon as the policies
       associated with that specific conference object to perform conferencing system
   actually creates the
       operation.  As mentioned before, conference, a new Conference User Identifier valid "entity" value is created
   for Bob, and it as well, which would take the "userInfo" is used to update place of the wildcard when
   completing the actual conference object accordingly.

   2.  In the presented example, provided by the call signaling to add "Bob" client.

   To give a flavour of what could be added to the conference object, we
   assume Alice is instigated through the Focus as well.  Please
       notice that also interested in providing scheduling-related
   information.  So, in this is implementation specific.  In fact, a
       conferencing system may accomplish different actions after example, Alice also specifies by the
       user creation, just as it may do nothing at all.  Among
   <conference-time> element included in the
       possible actions, for instance "Bob" may be added as "confInfo" that the
   conference she wants to create has to occur on a "target"
       element certain date from a
   certain start time to the "allowed-users-list" element, whose joining
       "method" may be either "dial-in" or "dial-out".  Besides, out-of-
       band notification mechanisms may be involved as well, e.g. a certain stop time and has to
       notify "Bob" via mail of be replicated
   weekly.

   Once Alice has prepared the new conference, including details "confInfo" element and sent it as part of
   her request to the date, password, expected participants and so on.

      To conclude server, if the overview on this scenario, once "Bob" conferencing system can support
   that specific type of conference (capabilities, etc.), then the
   request results in the creation of a conference.  We assume the
   request has been
      successfully added to successful, and as a consequence XCON-URI in the specified conference, per updates to
   form of the
      state, "confObjID" parameter and depending upon the policies, other participants
      (including "Bob" himself) may be notified of XCON-USERID in the addition form of "Bob"
   the "confUserID" parameter (again, the same as the requesting entity)
   are returned in the "confResponse" message.

   In this example, we choose not to return the created conference via
   object in the Conference Notification Service.

1. userRequest/create message (Alice adds Bob)

 <?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-user-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:userRequest>
          <userInfo>
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
          </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. userResponse/create message

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse 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">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <response-code>success</response-code>
        <version>10</version>
        <ccmp:userResponse>
          <userInfo entity="xcon-userid:Bob@example.com">
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
          </userInfo>
        </ccmp:userResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>
                   Figure 13: Add Party Message Details

6.4.  Muting successful "confResponse" in the "confInfo" parameter.
   Nevertheless, Alice could still retrieve the actual conference object
   by issuing a Party

   This section provides an example of "confRequest" with a "retrieve" operation on the muting of
   returned "confObjID".  Such a party in an
   active conference.  The unmuting request would involve show how, as we
   anticipated at the identical CCMP
   message flow.  Although, in beginning of this section, the case that floor control is involved,
   whether or not a particular conference client can unmute itself must
   be considered by "entity" attribute
   of the conferencing system.

      Please notice that interaction between CCMP and floor control
      should be carefully considered.  In fact, handling CCMP- and BFCP-
      based media control has to be considered as multiple layers: i.e.,
      a participant may have the BFCP floor granted, but be muted by
      means of CCMP.  If so, he would still be muted conference object in "confInfo" is replaced with the conference,
      and would only be unmuted if both the protocols allowed actual
   information (i.e. "xcon:6845432@example.com").

   Just for this.

   Figure 14 provides an example of one client "Alice" impacting the
   media state sake of another client "Bob".  This completeness and to provide the reader with some
   insight about how the CCMP conferencing server might interact with
   other related components, this example also assumes an
   established conference.  In this example, that the client, "Alice" whose
   Role
   conference is "moderator" of activated upon creation: i.e., the conference, wants to mute "Bob" on a
   medium-size multi-party conference, as his device "method" attribute
   is not muted (and
   he's obviously not listening set to "dial out" for this client based on the call) and background noise particular
   conferencing systems default.  This results (as shown in his
   office environment is disruptive to the conference.  BFCP floor
   control ladder
   diagram) in Alice, Bob and Carol being called by the conferencing
   system.  Just as before, this is assumed not to be involved.

    "Alice"        "Bob"
    CMCC1          CMCC2       CMCCx considered mandatory,
   since it depends on the implementation choices of the framework.

   Alice            Bob        Carol       ConfS                MS
     |               |           |           |
     |
     |(1) userRequest(confUserID,|               |           |           |    confObjID, update,
     |(1)confRequest(confUserID, |           |
     |         create, confInfo) |    userInfo)           |
     |               |           |
     |--------------------------------------->|           |
     |-------------------------------------->|
     |               |           |           | Mute Bob
     |               |         (a)Create +---|
     |               |            |----------------->|           |Conf   |   |
     |               |           200 OK           |Object |   |
     |               |            |<-----------------|           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |               |<====== XXX Bob excluded from mix XXX ====>|           |  | creates
     |               |           |           |  |         (a) Update +---| conf and
     |               |           |             Bob in           |<-+ its ID
     |               |           |           |   (confid=Y)
     |(2)confResponse(confUserID |         Data Model           |
     |       confObjID, create,  |           |
     |            (muted) +-->|       success, version)   |           |
     |<--------------------------------------|
     |               |           |           |
     | (2)userResponse(confUserID,confObjID,               |     (c) Focus     +---|
     |               |               update,success,version)         sets up   |   |
     |<---------------------------------------|
     |               |         signaling |   |
     |               |         to Alice  +-->|
     |               |           | (b) Notify           |
     |               |           |           |--+(d) MS joins
     |   ("Bob is               |           |           |  | Alice &
     |    muted")               |           |           |<-+ conf Y
     |               |           |<-----------|           |           |
     |               |           |           |
     '               '           '            '                  '
     '               '           '            '                  '
     '               '           '            '                  '

        Figure 14: Client Manipulation of Conference - Mute a party

   1.  Upon receipt of userRequest message with an update operation and
       the userInfo with the "status" field
     |<<###################################>>|
     | Alice is mixed in the "media" element for
       "Bob" set to "revconly".  The Conference Server ensures that
       "Alice" has the appropriate authority based on the policies
       associated with that specific conference object      |
     |<<###################################>>|
     |               |           |           |
     |               |     (e)Focus      +---|
     |               |        sets up    |   |
     |               |        signaling  |   |
     |               |        to perform the
       operation and updates the userInfo in the conference object
       reflect that "Bob"s media Bob     |   |
     |               |           |       +-->|
     |               |           |           |
     |               |           |           |--+(f)MS joins
     |               |           |           |  | Bob &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |<<###################>>|
     |               |  Bob is not to be mixed with the conference
       media.  In case the Conference Server relies on a remote Media
       Server for its multimedia functionality, it subsequently changes
       "Bob"'s media profile accordingly by means of the related
       protocol interaction with the MS.  An example describing a
       possible way of dealing with such a situation using the Media
       Server Control architecture is described in

       [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
       Transactions (2)".

   2.  A userResponse message with a responseCode of "success" is then
       sent too     |
     |               |<<###################>>|
     |               |           |           |
     |               |     (g )Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to "Alice".  Depending upon the policies, tne conference
       server may notify other participants (including "Bob") of this
       update via the Carol  |   |
     |               |         CMCCx     +-->|
     |               |           |           |
     |               |           |           |--+(h)MS joins
     |               |           |           |  | CMCCx &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |           |<<#######>>|
     |               |           |Carol mixed|
     |               |           |<<#######>>|
     |               |           |           |
     |               |           |           |
     |               |           |           |
     |<***All parties connected to conf Y***>|
     |               |           |           |
     |               |           |           |
     "               "           "           "
     "               "           "           "
     "               "           "           "

   Figure 9: Create Basic Conference Notification Service. from user provided conference-info

  1. userRequest/update confRequest/create message (Alice mutes Bob) proposes a conference object
     to be created - direct creation)

    <?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-user-request-message-type">
           xsi:type="ccmp:ccmp-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:label>123</info:label>
                        <info:status>recvonly</info:status>
                    </info:media>
                </info:endpoint>
            </userInfo>
        </ccmp:userRequest>
        <operation>create</operation>
        <ccmp:confRequest>
           <confInfo entity="xcon:AUTO_GENERATE_1@example.com">
              <info:conference-description>
                  <info:display-text>
                     Dial-out conference initiated by Alice
                  </info:display-text>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="AUTO_GENERATE_2">
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
                   <xcon:conference-time>
                    <xcon:entry>
                     <xcon:base>
                       BEGIN:VCALENDAR
                       VERSION:2.0
                       PRODID:-//Mozilla.org/NONSGML \
                                               Mozilla Calendar V1.0//EN
                       BEGIN:VEVENT
                       DTSTAMP: 20100127T140728Z
                       UID: 20100127T140728Z-345FDA-alice@example.com
                       ORGANIZER:MAILTO:alice@example.com
                       DTSTART:20100127T143000Z
                       RRULE:FREQ=WEEKLY
                       DTEND: 20100127T163000Z
                       END:VEVENT
                       END:VCALENDAR
                     </xcon:base>
                     <xcon:mixing-start-offset \
                                       required-participant="moderator">
                          2010-01-27T14:29:00Z
                     </xcon:mixing-start-offset>
                     <xcon:mixing-end-offset \
                                     required-participant="participant">
                          2010-01-27T16:31:00Z</xcon:mixing-end-offset>
                     <xcon:must-join-before-offset>
                          2010-01-27T15:30:00Z
                     </xcon:must-join-before-offset>
                    </xcon:entry>
                   </xcon:conference-time>
               </info:conference-description>
               <info:users>
                  <xcon:join-handling>allow</xcon:join-handling>
                  <xcon: allowed-users-list>
                     <xcon:target uri="xcon-userid:alice@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:bob83@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:carol@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>
               </info:users>
           </confInfo>
        </ccmp:confRequest>
     </ccmpRequest>
  </ccmp:ccmpRequest>

  2. userResponse/update confResponse/create message ("success")

  <?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"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-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-user-response-message-type">
         xsi:type="ccmp:ccmp-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>7</version>
        <ccmp:userResponse/>
       <confObjID>xcon:6845432@example.com</confObjID>
       <operation>create</operation>
       <response-code>success<response-code>
       <version>1</version>
      </ccmpResponse>
  </ccmp:ccmpResponse>

           Figure 15: Mute Message Details

6.5.  Internal Sidebar

   Figure 16 provides 10: Create Basic Conference Detailed Messaging

6.4.  Cloning an example of one Existing Conference

   A client "Alice" involved in can also create another conference by cloning an existing
   conference, such as an active conference with "Bob" and "Carol".  "Alice" wants to create or conference reservation.
   This approach can be seen as a
   sidebar to have logical extension of the creation of a side discussion with "Bob" while still viewing
   new conference using a blueprint: the
   video associated difference is that, instead of
   cloning the pre-defined settings listed in a blueprint, the settings
   of an existing conference would be cloned.

   In this example, the client sends a "confRequest" message with the main conference.  Alternatively,
   "create" operation, along with the audio "confUserID" and a specific
   "confObjID", from the main which a new conference could is to be maintained at created by cloning
   an existing conference.

   An example of how a reduced volume.
   "Alice" initiates the sidebar client can create a conference based on a
   blueprint is provided in Section 6.2.  The manner by sending which a request client
   in this example might learn about a conference reservation or active
   conferences is similar to the first step in the blueprint example,
   with the exception of specifying querying for different types of
   conference objects supported by the specific conferencing system to create system.
   For example, in this example, the client clones a conference
   reservation based upon the
   active conference object.  "Alice" and "Bob" would remain on (i.e., an inactive conference).

   If the
   roster conferencing system can support a new instance of the main conference, such that other participants could be
   aware specific
   type of their participation conference (capabilities, etc.), then the request results in
   the main creation of a conference, while with an
   internal-sidebar conference is occurring.  Besides, "Bob" decides
   that he is not interested XCON-URI in still receiving the conference audio in
   background (not even at form of a lower volume as "Alice" configured) and so
   modifies the sidebar new
   value in order to make that stream inactive for him.

  "Alice"                "Bob" the "confObjID" parameter to reflect the newly cloned
   conference object returned in the "confResponse" message.

   Alice                          ConfS
    |                               |                       |
    |(1) sidebarByValRequest(confUserID,           |
    |                  confObjID,create)           |
    |--------------------------------------------->|
    |
    |(1)confRequest(confUserID,     |
    |       confObjID, create)      |
    |------------------------------>|
    |        (a) Create                 (a)Create +---|
    |                      |    sidebar-by-val |   |                    Conf   |   |     (new conf obj
    |                    Object |   |
    |       cloned from                    & IDs  +-->|
    |                      |        confObjID)     | Sidebar now has
    |                      |                       | id confObjID*
    |(2) sidebarByValResponse(confUserID,          | (parent mapping
    |       (confObjID*, create, success,          | conf<->sidebar)
    |        version, sidebarByValInfo)            |
    |<---------------------------------------------|
    |                      |                       |
    |(3) sidebarByValRequest                       |
    |       (confUserID, confObjID*,               |
    |       update,sidebarByValInfo)               |
    |--------------------------------------------->|
    |                      |                       |
    |                      |                               |--+ (b) Update +---|
    |                      |    sidebar-by-val |   |
    | MS
    |     (media, users                               |  | creates
    |                               |       etc.)       +-->|  | conf and
    |                               |<-+ its ID
    | Sidebar is                               |   (confid=Y)
    |                               | modified
    |(4) sidebarByValResponse(confUserID,
    |(2)confResponse(confUserID,    |
    |                (confObjID*, update,      confObjID*,create,       |
    |      success, version)           |
    |<---------------------------------------------|
    |                      |                       |
    |                      |(5) userRequest        |
    |                      |      (confUserID',    |
    |                      |       confObjID*,     |
    |                      |       update,userInfo)|
    |                      |---------------------->|
    |                      |                       |
    |                      |        (c) Update +---|
    |                      |     user settings |   |
    |                      |     (Bob's media) |   |
    |                      |                   +-->|
    |                      |                       | Sidebar is modified
    |                      |                       | (original audio
    |                      |                       | inactive for Bob)
    |                      |(6) userResponse       |
    |                      |     (confUserID',     |
    |                      |      confObjID*,update| version,        |
    |      success,version)      confInfo)                |
    |                      |<----------------------|                               |
    |<------------------------------|
    |                               |
    "                      "                       "
    "                      "                       "
    "                      "                       "

                Figure 16: Client Creation of a Sidebar 11: Create Basic Conference - Clone

   1.  Upon receipt of CCMP sidebarByValRequest message to "reserve"  Alice, a
       new sidebar conference based upon the confObjID received in the
       request, the conferencing system uses the confObjID client, sends a confRequest message
       to clone a conference reservation for based on an existing conference
       reservation.  Alice indicates this conference should be cloned
       from the sidebar.  The sidebar reservation specified parent conference represented by the
       "confObjID" in the request.

   2.  Upon receipt of the confRequest message containing a "create"
       operation and "confObjID", the conferencing system ensures that
       the "confObjID" received is NOT independent valid.  The conferencing system
       determines the appropriate read/write access of any users to be
       added to a conference based on this "confObjID" (using
       membership, roles, etc.).  The conferencing system uses the active
       received "confObjID" to clone a conference (i.e., parent). reservation.  The
       conferencing system also reserves or allocates a new confObjID "confObjID"
       (called "confObjID*" in Figure 11) to be used for any the cloned
       conference object.  This new identifier is of course different
       from the one associated with the conference to be cloned, since
       it represents a different conference object.  Any subsequent
       protocol requests from any of the members of the conference.

   2. conference must
       use this new identifier.  The relationship information is provided in conferencing system maintains the
       sidebarByValResponse message, specifically in
       mapping between this conference ID and the "sidebar-
       parent" element.  A dump of parent conference
       object ID associated with the complete representation of reservation through the
       main/parent conference
       instance, and this mapping is provided below as well to show how the
       cloning process for explicitly addressed through the creation
       "cloning-parent" element of the sidebar could take place.

   3.  Upon receipt of "conference-description" in the sidebarByValResponse
       new conference object.

1. confRequest/create message to reserve the
       conference, "Alice" can now create an active

  <?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-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:6845432@example.com</confObjID>
        <operation>create</operation>
     </ccmpRequest>
  </ccmp:ccmpRequest>

2. confResponse/create message ("success", created conference using
       that reservation, or create additional reservations based upon
       the existing reservations.  In this example, "Alice" wants only
       "Bob" to be involved in the sidebar, thus she manipulates the
       membership so that only the two of them appear in the "allowed-
       users-list" section.  "Alice" also wants both audio and the video
   object returned)

   <?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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>success</response-code>
       <version>1</version>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from 6845432

                  </info:display-text>
                  <xcon:cloning-parent>
                      xcon:6845432@example.com
                  </xcon:cloning-parent>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
               </info:conference-description>
               <info:users>
                   <xcon:join-handling>allow</xcon:join-handling>
                      <xcon: allowed-users-list>
                     <xcon:target uri="sip:alice@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:bob83@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:carol@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>
               </info:users>
                  <xcon:floor-information>
                     <xcon:floor-request-handling>
                        confirm</xcon:floor-request-handling>
                     <xcon:conference-floor-policy>
                       <xcon:floor id="11"/>
                     </xcon:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

       Figure 12: Create Basic Conference (Clone) Detailed Messaging

7.  Conference Users Scenarios and Examples

   Section 6 showed examples describing the original several different ways a
   conference to be available in the sidebar.  For
       what concerns the media belonging to the sidebar itself, "Alice"
       wants the audio to might be restricted to the participants in created using CCMP.  This section instead focuses
   on user-related scenarios, i.e. typical scenarios that may occur
   during the
       sidebar (that is, her lifetime of a conference, like adding new users and "Bob").  Additionally, "Alice"
       manipulates the media values to recieve the audio from
   handling their media.  The following scenarios are based on those
   documented in the main
       conference at a reduced volume, so XCON framework.  The examples assume that the communication between
       her and "Bob" isn't affected.  "Alice" sends a
       sidebarByValRequest message
   conference has already been correctly established, with an operation media, if
   applicable, per one of "update" along
       with the sidebarByValInfo examples in the reservation, Section 6.

7.1.  Adding a Party

   In this example, Alice wants to add Bob to create an active established conference.

   4.  Upon receipt of
   In the sidebarByValRequest to update following example we assume Bob is a new user of the reservation system,
   which means Alice also needs to create an active conference for provide some details about him.  In
   fact, the sidebar, case of Bob already present as identified by
       the sidebar conference object ID, a user in the conference server ensures
       that conferencing
   system is much easier to address, and will be discussed later on.

    "Alice" has the appropriate authority based on the policies
       associated        "Bob"
    CMCC1          CMCC2       CMCCx       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |    confObjID, create,     |           |
     |    userInfo)  |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |        (a) Create +---|
     |               |           | Bob   |   |
     |               |           | as a  |   |
     |               |           | user  +-->|
     |               |           |           |
     |(2) userResponse(confUserID,confObjID  |
     |           create,success,userInfo)    |
     |<--------------------------------------|
     |               |           |           |
     |               |           | (b) Focus |
     |               |           |   sets up |
     |               |           | signaling |
     |               |           |  to Bob   |
     |               |<----------------------|
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  joined") |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

        Figure 13: Client Manipulation of Conference - Add a party

   1.  Alice sends a userRequest message with that an operation of "create"
       to add Bob to the specific conference object to perform as identified by the
       operation.
       "confObjID".  The conference server must "create" operation also validate the updated
       information in the reservation, ensuring makes sure that a member like "Bob" Bob is already
       created as a user of this conference server.  Once the data for in the confObjID whole conferencing system.  This is updated, the conference server sends done
       by adding a
       sidebarByValResponse to "Alice".  Depending upon the policies,
       the initiator of the request (i.e., "Alice") and the participants "userInfo" element describing Bob as a user.  This is
       needed in order to let the sidebar (i.e., "Bob") may conferencing system be notified aware of Bob's
       characteristics.  In case Bob was already a registered user,
       Alice would just have referenced him through his addition to XCON-USERID in
       the sidebar via "entity" attribute of the conference notification service.

   5.  At this point, "Bob" sends a userRequest message "userInfo" field, without providing
       additional data.  In fact, that data (including, for instance,
       Bob's SIP-URI to be used subsequently for dial-out) would be
       obtained by referencing the extant registration.  The conference
       server ensures that Alice has the appropriate authority based on
       the policies associated with an operation of "update" that specific conference object to completely
       disable
       perform the background audio from operation.  As mentioned before, a new Conference
       User Identifier is created for Bob, and the parent conference, since it
       prevents him from understanding what "Alice" says in "userInfo" is used to
       update the sidebar.

   6.  Notice that "Bob's" request only changes conference object accordingly.  As already seen in
       Section 6.3, a placeholder wildcard
       ("xcon-userid:AUTO_GENERATE@example.com" in the media perspective CCMP messages
       below) is used for "Bob".  "Alice" keeps on receiving both the audio from "Bob"
       and the background from "entity" attribute of the parent conference.  This request may "userInfo"
       element, to be relayed replaced by the conference server actual XCON-USERID later on;

   2.  Bob is successfully added to the Media Server handling conference object, and an XCON-
       USERID is allocated for him ("xcon-userid:Bob@example.com"); this
       identifier is reported in the mixing, if present.  Upon completion response as part of the change, "entity"
       element of the
       conference server sends a "userResponse" message returned "userInfo";

   3.  In the presented example, the call signaling to add Bob to "Bob".
       Depending upon the policies,
       conference is instigated through the initiator Focus as well.  We again
       remind that this is implementation specific.  In fact, a
       conferencing system may accomplish different actions after the
       user creation, just as it may do nothing at all.  Among the
       possible actions, for instance Bob may be added as a <target>
       element to the <allowed-users-list> element, whose joining
       "method" may be either "dial-in" or "dial-out".  Besides, out-of-
       band notification mechanisms may be involved as well, e.g. to
       notify Bob via mail of the request (i.e.,
       "Bob") and new conference, including details as
       the date, password, expected participants in and so on (see
       Section 5.3).

      To conclude the sidebar (i.e., "Alice") overview on this scenario, once Bob has been
      successfully added to the specified conference, per updates to the
      state, and depending upon the policies, other participants
      (including Bob himself) may be notified of this change via the conference notification service.

   That said, let's consider addition of Bob to
      the following conference object: via the Conference Notification Service in use.

1. userRequest/create message (Alice adds Bob)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <info:conference-info
  <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"
                entity="xcon:8977878@example.com">
     <info:conference-description>
        <info:display-text>MAIN CONFERENCE</info:display-text>
        <info:conf-uris>
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:userRequest>
          <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>
               <info:uri>sip:8977878@example.com</info:uri>
               <info:display-text>conference sip uri</info:display-text>
            </info:entry>
        </info:conf-uris>
        <info:available-media>
          <info:entry label="123">
            <info:display-text>main conference audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>
          </info:entry>
          <info:entry label="456">
            <info:display-text>main conference video</info:display-text>
            <info:type>video</info:type>
            <info:status>sendrecv</info:status>
            <xcon:controls>
                    <xcon:video-layout>single-view</xcon:video-layout>
           </xcon:controls>
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
        </info:available-media>
    </info:conference-description>
    <info:conference-state>
        <info:active>true</info:active>
    </info:conference-state>
    <info:users>
        <info:user entity="xcon-userid:Alice@example.com">
            <info:display-text>Alice</info:display-text>
            <info:endpoint entity="sip:Alice@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Bob@example.com">
            <info:display-text>Bob</info:display-text>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Carol@example.com">
            <info:display-text>Carol</info:display-text>
            <info:endpoint entity="sip:carol@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
        </info:user>
    </info:users>
  </info:conference-info>

   This is the representation of the conference the sidebar is going to
   be created in.  As such, it will be used by the conferencing system
   in order to create the new conference object associated with the
   sidebar.  In fact, the sidebar creation happens through
          </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. userResponse/create message ("success": a cloning of
   the parent conference.  Once the sidebar new XCON-USERID is created, an "update"
   makes sure that the sidebar
   created for Bob and he is customized as needed.  The following
   protocol dump makes added to the process clearer.

1. sidebarByValRequest/create message conference)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
  <ccmp:ccmpResponse 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
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByValRequest/>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. sidebarByValResponse/create message

  <?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-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <response-code>success</response-code>
            <version>1</version>
        <ccmp:sidebarByValResponse>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                    <info:display-text>
                         SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                         xcon:8977878@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                  main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                  main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
        <version>10</version>
        <ccmp:userResponse>
          <userInfo entity="xcon-userid:Bob@example.com">
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>

                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Carol@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

3. sidebarByValRequest/update message

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
            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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                  <info:display-text>
                        private sidebar Alice - bob
                  </info:display-text>
                  <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                            <xcon:controls>
                                <xcon:gain>-60</xcon:gain>
                            </xcon:controls>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="sidebarAudioLabel">
                            <info:display-text>
                                sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="sidebarVideoLabel">
                            <info:display-text>
                                sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

4. sidebarByValResponse/update message

  <?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-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>2</version>
        <ccmp:sidebarByValResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

5. userRequest/update message (Alice updates Bob's media)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
           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">
      <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:display-text>
                            main conference audio
                        </info:display-text>
                        <info:label>123</info:label>
                        <info:status>inactive</info:status>
                    </info:media>
                </info:endpoint>
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

6. userResponse/update message

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse 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">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>3</version>
        <ccmp:userResponse/>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
          </userInfo>
        </ccmp:userResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

                   Figure 17: Internal Sidebar Messaging 14: Add Party Message Details

6.6.  External Sidebar

   Figure 18

7.2.  Muting a Party

   This section provides an example of the muting of a different approach towards
   sidebar.  In this scenario, one client, "Alice", is involved party in an
   active conference with "Bob", "Carol", "David" and "Ethel".  "Alice"
   gets an important text message via a whisper from "Bob" conference.  We assume that a
   critical customer needs to talk the user to "Alice", "Bob" and "Ethel".
   "Alice" creates a sidebar mute has already been
   added to have a side discussion with the customer
   "Fred" including the participants in the current conference with the
   exception of "Carol" and "David", who remain in the active conference.  The difference from the previous scenario is document only addresses muting and not
   unmuting as well, since it would involve an almost identical CCMP
   message flow anyway.  Although, in case that "Fred" any external floor
   control is involved, whether or not part of the parent conference: this means that different
   policies might a particular conference client
   can actually mute/unmute itself must be involved, considering that "Fred" may access
   information coming from the parent conference, in case considered by the sidebar
   was configured accordingly.  For this reason, in this scenario we
   assume
   conferencing system.

      Please notice that "Alice" disables all the interaction between CCMP and floor control
      should be carefully considered.  In fact, handling CCMP- and BFCP-
      based media from the original (parent)
   conference within control has to be considered as multiple layers: i.e.,
      a participant may have the sidebar.  This BFCP floor granted, but be muted by
      means that, while of CCMP.  If so, he would still be muted in the
   previous example "Alice" conference,
      and "Bob" still heard would only be unmuted if both the audio from protocols allowed for this.

   Figure 15 provides an example of one client, "Alice", impacting the
   main conference in background,
   media state of another client, "Bob".  This example assumes an
   established conference.  In this time no background example, Alice, whose role is made
   available.  "Alice" initiates the sidebar by sending a request to
   "moderator" of the
   conferencing system conference, wants to create mute Bob on a conference reservation based upon medium-size
   multi-party conference, as his device is not muted (and he's
   obviously not listening to the
   active conference object.  "Alice", "Bob" call) and "Ethel" would remain on background noise in his
   office environment is disruptive to the roster conference.  BFCP floor
   control is assumed not to be involved.

   From a protocol point of view, muting/unmuting an user basically
   consists in updating the main conference in a hold state.  Whether or not object by modifying the hold state of these participants is visible settings
   related to other participants
   depends upon the individual and local policy. target user's media streams.  Specifically, Bob's
   "userInfo" must be updated by modifying its audio <endpoint>
   information (e.g. setting it to "recvonly" in case of muting),
   identified by the right media id.

    "Alice"        "Bob"
    CMCC1          CMCC2       CMCCx        ConfS                MS
     |               |           |
   |(1) sidebarByRefRequest(confUserID,           |            |                 confObjID, create)                  |
   |--------------------------------------------->|
     |(1) userRequest(confUserID,|            |                  |
     |    confObjID, update,     |            |        (a) Create +---|                  |
     |    sidebar-by-ref    userInfo)  |           |            |                  |     (new conf obj
     |--------------------------------------->|                  |
     |               |           |       cloned from +-->|            | Mute Bob         |        confObjID)
     | Sidebar now has               |           |            |----------------->|
     | id confObjID*
   |(2) sidebarByRefResponse(confUserID,               | (parent mapping           |        confObjID*, create, success,            | conf<->sidebar)           200 OK |          version, sidebarByRefInfo)
     |
   |<---------------------------------------------|               |           |            |<-----------------|
     |
   |(3) sidebarByRefRequest(confUserID,               |           |      confObjID*,update,sidebarByRefInfo)            |
   |--------------------------------------------->|                  |
     |               |<====== XXX Bob excluded from mix XXX ====>|
     |               |           |        (b) Create +---|            |                  |      new user for
     |               |         (a) Update +---|                  |
     |            "Fred"               |             Bob in |   |                  |                   +-->|
     |               |         Data Model |   |                  |        (c) Update +---|
     |               |    sidebar-by-val            (muted) +-->|                  |
     |               |           |     (media, users            |                  |
     | (2)userResponse(confUserID,confObjID,  |     policy, etc.) +-->|                  |
     |               update,success,version)  | Sidebar is modified:                  |
     |<---------------------------------------|                  |
     | no media from the               |           |            | parent conference is                  |
     |               | available to anyone
   |(4) sidebarByRefResponse(confUserID,           | (b) Notify |                 confObjID*, update,                  |
     |                  success, version)               |
   |<---------------------------------------------|           |   ("Bob is |                  |
     |               |        Notify ("Fred"           |    muted") |                  |              added to
     |               |           |<-----------|                  |        sidebar users)
     |               |                      |<----------------------|           |            |                  |
   "                      "                       "
   "                      "                       "
   "                      "                       "
     '               '           '            '                  '
     '               '           '            '                  '
     '               '           '            '                  '

        Figure 18: 15: Client Creation Manipulation of an External Sidebar Conference - Mute a party

   1.  Upon receipt of the "sidebarByRefRequest" message to create  Alice sends a new
       sidebar conference, based upon userRequest message with an "update" operation and
       the active conference specified by
       "confObjID" userInfo with the "status" field in the request, "media" element for
       Bob set to "revconly".  The Conference Server ensures that Alice
       has the conferencing system uses appropriate authority based on the
       received active policies associated
       with that specific conference object to clone a conference reservation for
       the sidebar.  The sidebar reservation is NOT independent of the
       active conference (i.e., parent).  The conferencing system as
       before reserves or allocates a conference ID (confObjID*) to be
       used for any subsequent protocol requests from any of the members
       of the conference.  The conferencing system maintains perform the mapping
       between this conference ID operation and
       updates the conference object ID
       associated with the sidebar reservation through the conference
       instance.  Just as before, this mapping is mantained "userInfo" in "sidebar-
       parent".

   2.  Upon receipt of the "sidebarByRefResponse" message, which
       acknowledges the successful creation of the sidebar object,
       "Alice" decides conference object reflecting that only "Bob" and "Ethel", along with the new
       participant "Fred" are
       Bob's media is not to be involved in the sidebar.  Thus she
       manipulates the membership accordingly.  "Alice" also sets the
       media in the "conference-info" such that mixed with the participants in conference media.  In
       case the
       sidebar don't receive any Conference Server relies on a remote Media Server for
       its multimedia functionality, it subsequently changes Bob's media from the main conference.  All
       these settings are provided to the conferencing system
       profile accordingly by means of a new "sidebarByRefRequest" message, the related protocol interaction
       with an "update"
       operation.

   3.  "Alice" sends the aforementioned "sidebarByRefRequest" MS to update enforce the information in the reservation and to create an active
       conference.  Upon receipt decision.  An example describing a
       possible way of dealing with such a situation using the "sidebarByRefRequest" Media
       Server Control architecture is described in

       [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
       Transactions (2)".

   2.  A userResponse message with an
       operation a response-code of "update", the conferencing system ensures that
       "Alice" has "success" is then
       sent to Alice.  Depending upon the appropriate authority based on policies, the policies
       associated with that specific conference object to perform the
       operation.  The conferencing system also validates the updated
       information in the reservation.  Since "Fred" is a new user for
       this conferencing system, a conference user identifier is created
       for "Fred".  Specifically, "Fred" is added to the conference by
       only providing his SIP URI.  Based upon the addressing
       information provided for "Fred" by "Alice", the call signaling to
       add "Fred" to the conference may be instigated through the Focus
       (e.g. if "Fred" had a "dial-out" method set as the target for
       him) at the actual activation of the sidebar.

   4.  The conference
       server sends a "sidebarByRefResponse" message and,
       depending upon the policies, the initiator of the request (i.e.,
       "Alice") and the participants in the sidebar (i.e., "Bob" and
       "Ethel") may be notified notify other participants (including Bob) of his addition to the sidebar this
       update via the
       conference notification service. any Conference Notification Service that may be in
       use.

1. sidebarByRefRequest/create userRequest/update message (Alice mutes Bob)

  <?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-sidebarByRef-request-message-type">
       xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByRefRequest/>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:label>123</info:label>
                        <info:status>recvonly</info:status>
                    </info:media>
                </info:endpoint>
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. sidebarByRefResponse/create userResponse/update message ("success")

  <?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">
               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
                  xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>success</operation>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                        xcon:8977878@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Carol@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:David@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Ethel@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

3. sidebarByRefRequest/update message

  <ccmp:ccmpRequest
                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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        sidebar Alice, bob, ethel & fred

                    </info:display-text>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                        </info:display-text>
                            <info:type>video</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry>
                            <info:display-text>
                                 sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry>
                            <info:display-text>
                                 sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                            <xcon:controls>
                                 <xcon:video-layout>
                                       single-view
                                 </xcon:video-layout>
                            </xcon:controls>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-out"
                              uri="sip:fred@example.com"/>

                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

4. sidebarByRefResponse/update message

  <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-sidebarByref-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>2</version>
        <ccmp:sidebarByRefResponse/>
            <version>7</version>
        <ccmp:userResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

                      Figure 19: External Sidebar Messaging 16: Mute Message Details

6.7.  Floor control using sidebars

   Floor control

7.3.  Conference Announcements and Recordings

   This section deals with sidebars can be used to realize conferencing
   scenario such as an analyst briefing.  In this scenario, the
   conference call has a panel of speakers who features that are allowed to talk typically required in
   the main conference.  The other participants are the analysts, who a
   conferencing system, that are not allowed to speak unless they have the floor.  To request
   access to the floor, they have public announcements (e.g. to join notify
   vocally that a new sidebar with the
   moderator user joined a conference) and ask their question.  The moderator can also whisper to
   each analyst what their status/position in name recording.
   While this is not strictly CCMP-related (the CCMP signaling is
   actually the floor control queue,
   similar to same as the example one seen in Figure 23.  It should be noted that Section 7.1) it is an
   interesting scenario to address to see how the several components of
   an XCON-compliant architecture interact with each other
   mechanisms which don't to make use of sidebars could be used for floor
   control such it
   happen.

   In this example, as those detailed shown in BFCP. Figure 20 provides an example of the configuration involved for this
   type of conference.  As in the previous sidebar examples, there 17 Alice is
   the main joining Bob's
   conference along with that requires that she first enters a sidebar.  "Alice" and "Bob" are the
   main participants in the conference, with "A1", "A2" and "A3"
   representing the analysts.  The sidebar remains active throughout the
   conference, with the moderator, "Carol", serving as the chair.  As
   discussed previously, the sidebar conference is NOT independent of
   the active conference (i.e., parent).  The analysts are provided the
   conference object ID associated with the active sidebar when they
   join pass code.  After
   successfully entering the main conference.  The conferencing system also allocates a
   conference ID pass code, an announcement prompts Alice to
   speak her name so it can be used for any subsequent manipulations of the
   sidebar conference.  The conferencing system maintains the mapping
   between this conference ID and the conference object ID associated
   with recorded.  When Alice is added to the
   active sidebar conference through the conference instance.
   The analysts are permanently muted while in conference, the main conference.  The
   analysts are moved recording is played back to all the sidebar when they wish to speak.  Only one
   analyst existing
   participants.  A very similar example is given the floor at a given time.  All participants in the
   main conference receive audio from the sidebar conference, as well as
   audio provided by the panelists presented in the main conference.

      (To Be added). Figure 20: Floor Control with sidebars

   1.  "A1" wishes to ask a question, so he sends a Floor Request
       message to the floor control server.

   2.  Upon receipt of the request, the floor control server notifies
       the moderator, "Carol" 33 of
   [I-D.ietf-mediactrl-call-flows].

   CMCC "Alice"                    ConfS                         MS
        |                            |                            |
        |(1)userRequest(confObjID,   |                            |
        |         create,userInfo)   |                            |
        |--------------------------->|                            |
        |                            |--+ Alice is                |
        |                            |  | new in the active sidebar conference, whose
       serving as the floor chair.

   3.  Since no other analysts have yet requested the floor, "Carol"
       indicates to the floor control server              |
        |                            |<-+ system (create          |
        |                            |    confUserID)             |
        |           ConfS handles +--|                            |
        |           SIP signaling |  |                            |
        |    (Alice<->ConfS<->MS) +->|                            |
        |                            |                            |
        |                            |--+ A password is           |
        |                            |  | required for            |
        |                            |<-+ that "A1" may be granted
       the floor.

                           (CCMP Messaging details not available yet). conference         |
        |                            |                            |
        |                            | Request IVR menu (PIN)     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS gets PIN from Alice through DTMF =========>|
        |                            |                            |
        |                            |        Provided PIN is...  |
        |                            |<---------------------------|
        |                   Check +--|                            |
        |                     PIN |  |                            |
        |                         +->|                            |
        |                            |--+ Alice must              |
        |                            |  | record her              |
        |                            |<-+ name                    |
        |                            |                            |
        |                            | Request name recording     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS records Alice's audio RTP (name) =========>|
        |                            |                            |
        |                            |            Audio recording |
        |                            |<---------------------------|
        |                Complete +--|                            |
        |                creation |  |                            |
        |                of Alice +->|                            |
        |                            |                            |
        |                            |                            |
        | (2)userResponse(confUserID,|                            |
        |        confObjID, create,  |                            |
        |        success, version)   |                            |
        |<---------------------------|                            |
        |                            |                            |
                  Figure 21: Floor Control Messaging Details

6.8.  Whispering or Private Messages

   The case 17: Recording and Announcements

   1.  Upon receipt of private messages can the userRequest from Alice to be handled as added to Bob's
       conference, the conferencing system determines that a sidebar with just
   two participants, similarly password is
       required for this specific conference.  Thus an announcement
       asking Alice to enter the example in section Section 6.5.
   Unlike the previous example, anyway, rather than using audio within
   the sidebar, "Alice" could just add an additional text based media
   stream to the sidebar in order to convey her whisper.  From the
   protocol point password is sent back.  This may be
       achieved by means of view, with reference to typical IVR functionality.  Once Alice
       enters the messages described in
   Figure 17, only password, it is validated against the third CCMP message (a sidebarByValRequest/update)
   changes, as depicted in Figure 22.

3. sidebarByValRequest/update message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
            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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                  <info:display-text>
                        private sidebar alice - bob
                  </info:display-text>
                  <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="sidebarTextLabel">
                            <info:display-text>
                                sidebar text
                            </info:display-text>
                            <info:type>text</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

       Figure 22: SidebarByVal Update for private messages scenario policies
       associated with Bob's active conference.  The other context, referred to as whisper, in this document refers to
   situations involving one time media targetted conferencing system
       then connects to specific user(s).
   An example of a whisper would be an announcement injected only to the
   conference chair server which prompts and records Alice's name.
       The conferencing system must also determine whether Alice is
       already a user of this conferencing system or to whether she is a
       new participant joining user.  In this case, Alice is a conference.
   Please notice that such new user for this
       conferencing system, so a Conference User Identifier (i. e. an announcement would not be conveyed by
   means of CCMP, while rather
       XCON-USERID) is created for Alice.  Based upon the contact
       information provided by means of a notification protocol
   related Alice, the call signaling to it, e.g. a SIP event package, XMPP, or even a multimedia
   announcement.  CCMP would only be involved with respect add Alice to
       the
   creation of an ad-hoc sidebar, as it will be clearer in the following
   lines.

   Figure 23 provides an example of one user "Alice" who's chairing a
   fixed length conference with "Bob" and "Carol".  The configuration is
   such that only instigated through the chair is providing Focus.

   2.  The conference server sends Alice a warning when there is only 10
   minutes left in userResponse message which
       includes the conference.  At that time, "Alice" is moved into
   a sidebar created "confUserID" assigned by the conferencing system and only "Alice"
   receives the announcement.

          (To Be completed).

                            Figure 23: Whisper

   1.  When the conferencing system determines that there is only 10
       minutes left in the conference which "Alice" is chairing, the
       conferencing system directly creates an active sidebar
       conference, based on the active conference associated with
       "Alice". to
       her.  This sidebar conference is NOT independent of would allow Alice to later perform operations on the
       active conference (i.e., parent).  The conferencing system also
       allocates a
       conference ID (if she were to be used have the appropriate policies),
       including registering for any subsequent
       manipulations of event notifications associated with the sidebar
       conference.

   2.  Immediately upon creation of  Once the active sidebar conference, call signaling indicates that Alice has
       been successfully added to the
       announcement media is provided specific conference, per updates
       to "Alice".  Depending the state, and depending upon the policies, Alice may be other participants
       (e.g., Bob) are notified of her the addition of Alice to the sidebar
       conference via the conference notification service.  "Alice" continues service and an
       announcement is provided to
       receive all the media from participants indicating that
       Alice has joined the main conference.

   3.  Upon completion of the announcement, "Alice" is removed from the
       siebar and the sidebar conference is deleted.

   4.  "Alice" is notified of her removal

  1. userRequest/create message (Alice - a new conferencing system
     client - enters Bob's conference)

  <?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-user-request-message-type">
          <confObjID>xcon:bobConf@example.com</confObjID>
          <operation>create</operation>
          <ccmp:userRequest>
            <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
                  <info:associated-aors>
                      <info:entry>
                          <info:uri>
                             mailto:Alice83@example.com
                          </info:uri>
                          <info:display-text>email</info:display-text>
                      </info:entry>
                  </info:associated-aors>
                  <info:endpoint entity="sip:alice_789@example.com"/>
              </userInfo>
          </ccmp:userRequest>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  2.userResponse/create ("success": Alice is provided with a new
    xcon-userid and is added to the conference)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
      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">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:type="ccmp:ccmp-user-response-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:bobConf@example.com</confObjID>
          <operation>create</operation>
          <response-code>success</response-code>
          <version>5</version>
          <ccmp:userResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>
                 Figure 18: Announcement Messaging Details

7.4.  Monitoring for DTMF

   Conferencing systems often also need the capability to monitor for
   DTMF from each individual participant.  This would typically be used
   to enter the sidebar via identifier and/or access code for joining a specific
   conference.  This feature is often also exploited to achieve
   interaction between participants and the conference notification service.

6.9.  Observing and Coaching system for non-
   XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted).

   An example of observing and coaching DTMF monitoring, within the context of the framework
   elements, is shown in figure Figure 25.
   In this example, call center agent "Bob" is involved in a conference
   with customer "Carol".  Since "Bob" is a new agent and "Alice" sees
   that he has been on the call with "Carol" 17.  A typical way for longer than normal, she
   decides the conferencing
   system to observe be aware of all the call and coach "Bob" as necessary.

   Consider DTMF interactions within the following as context of
   conferences it is responsible for, is making use of the MEDIACTRL
   architecture for what regards media manipulation.  Examples in that
   sense (specifically for what concerns DTMF interception in conference document associated with the
   video
   instances) are presented in [I-D.ietf-mediactrl-call-flows].

7.5.  Entering a password-protected conference involving Bob (the call agent) and Carol (the
   customer) (Figure 24):

   Some conferences may envision a password to be provided by a user who
   wants to manipulate the relative conference objects (e.g. join,
   update, delete) via CCMP.  Such a password would be included in the
   <conference-password> element related to the conference XCON-URI in
   the appropriate <conference-uris> entry and must be then included in
   the apposite "conference-password" field in the CCMP request
   addressed to that conference.

   In the following CCMP transactions, it is depicted a scenario in
   which Alice, a conferencing system client, attempts to join a
   password-protected conference.

   1.  Alice sends a userRequest message with a "create" operation to
       add herself in the conference with XCON-URI
       "xcon:8977777@example.com" (written in the "confObjID"
       parameter).  Alice provides her XCON-USERID via the "confUserID"
       field of the userRequest and leaves out the "userInfo" one
       (first-party join).  In this first attempt, she doesn't insert
       any password parameter.

   2.  Upon receipt the userRequest/create message, the conferencing
       server detects that the indicated conference is not joinable
       without providing the relative pass code.  Then a userResponse
       message with "confPasswordRequired" response-code is returned to
       Alice to indicate that her join has been refused and that she has
       to recast her request including the appropriate conference
       password in order to participate.

   3.  After getting the pass code through out-of-band mechanisms, Alice
       provides it in the proper "password" request field of a new
       userRequest/create message and sends the updated request back to
       the server.

   4.  The conferencing server checks the provided password and then
       adds Alice to the protected conference.  After that, a
       userResponse with a "success" response-code is sent to Alice.

  1. userRequest/create message (Alice tries to enter the conference
     without providing the password)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <info:conference-info
                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"
                entity="xcon:8978383@example.com">
     <info:conference-description>
        <info:display-text>CUSTOMER SERVICE conference</info:display-text>
        <info:conf-uris>
            <info:entry>
               <info:uri>sip:8978383@example.com</info:uri>
               <info:display-text>conference sip uri</info:display-text>
            </info:entry>
        </info:conf-uris>
        <info:available-media>
          <info:entry label="123">
            <info:display-text>service audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>

          </info:entry>
          <info:entry label="456">
            <info:display-text>service video</info:display-text>
            <info:type>video</info:type>
            <info:status>sendrecv</info:status>
            <xcon:controls>
                    <xcon:video-layout>single-view</xcon:video-layout>
           </xcon:controls>
          </info:entry>
        </info:available-media>
    </info:conference-description>
    <info:conference-state>
        <info:active>true</info:active>
    </info:conference-state>
    <info:users>
        <info:user entity="xcon-userid:bob@example.com">
            <info:display-text>Bob - call agent</info:display-text>
            <info:endpoint entity="sip:bob@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:carol@example.com">
            <info:display-text>Carol - customer</info:display-text>
            <info:endpoint entity="sip:carol@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
    </info:users>
  </info:conference-info>

            Figure 24: A call-center conference object example

"Alice"                 "Bob"                  ConfS
  |                      |                       |
  |(1) sidebarByRefRequest(confUserID,           |
  |                 confObjID, create)           |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (a) Create +---|
  |                      |    sidebar-by-ref |   |
  |                      |     (new conf obj |   |
  |                      |       cloned from +-->|
  |                      |        confObjID)     | Sidebar now has
  |                      |                       | id confObjID*
  |(2) sidebarByRefResponse(confUserID,          | (parent mapping
  |        confObjID*, create, success,          | conf<->sidebar)
  |          version, sidebarByRefInfo)          |
  |<---------------------------------------------|
  |                      |                       |
  |(3) sidebarByRefRequest(confUserID,           |
  |      confObjID*,update,sidebarByRefInfo)     |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (b) Update +---|
  |                      |    sidebar-by-val |   |
  |                      |     (media, users |   |
  |                      |     policy, etc.) +-->|
  |                      |                       | Sidebar is modified:
  |                      |                       | unilateral sidebar
  |                      |                       | audio, Carol excluded
  |                      |                       | from the sidebar
  |(4) sidebarByRefResponse(confUserID,          |
  |                 confObjID*, update,          |
  |                  success, version)           |
  |<---------------------------------------------|
  |                      |                       |
  |                      |         Notify ("Bob" |
  |                      |    he's been added to |
  |                      |        sidebar users) |
  |                      |<----------------------|
  |                      |                       |
  "                      "                       "
  "                      "                       "
  "                      "                       "

      Figure 25: Supervisor Creating a Sidebar for Observing/Coaching

   1.  Upon receipt of the sidbarByRefRequest/create from "Alice" to
       "create" a new sidebar conference from the confObjID received in
       the request, the conferencing system uses the received active
       conference to clone a conference reservation for the sidebar.
       The conferencing system also allocates a conference ID to be used
       for any subsequent protocol requests from any of the members of
       the conference.  The conferencing system maintains the mapping
       between this conference ID and the confObjID associated with the
       sidebar reservation through the conference instance.  The
       conference server sends a sidebarByRefResponse message with the
       new confObjID and relevant confInfo.

   2.  Upon receipt of the confResponse message, "Alice" manipulates the
       data received in the confInfo in the response.  "Alice" wants
       only "Bob" to be involved in the sidebar, thus she updates the
       "allowed-users-list" to include only "Bob".  "Alice" also wants
       the audio to be received by herself and "Bob" from the original
       conference, but wants any outgoing audio from herself to be
       restricted to the participants in the sidebar, whereas "Bob's"
       outgoing audio should go to the main conference, so that both
       "Alice" and the customer "Carol" hear the same audio from "Bob".
       "Alice" sends a sidebarByRefRequest message with an "update"
       operation including the updated conference information.

   3.  Upon receipt of the sidbarByRefRequest message with an "update"
       operation, the conferencing system ensures that "Alice" has the
       appropriate authority based on the policies associated with that
       specific conference object to perform the operation.

   4.  After validating the data, the conference server sends a
       sidebarByRefResponse message.  Based upon the addressing
       information provided for "Bob" by "Alice", the call signaling to
       add "Bob" to the sidebar with the appropriate media
       characteristics is instigated through the Focus.  "Bob" is
       notified of his addition to the sidebar via the conference
       notification service, thus he is aware that "Alice" the
       supervisor is available for coaching him through this call.

1. sidebarByRefRequest/create message (Alice - the coach - creates a sidebar)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
  <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-sidebarByRef-request-message-type">
              xsi:type="ccmp:ccmp-user-request-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8978383@example.com</confObjID>
          <confObjID>xcon:8977794@example.com</confObjID>
          <operation>create</operation>
        <ccmp:sidebarsByRefRequest/>
          <ccmp:userRequest/>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  2. sidebarByRefRequest/create userResponse/create message ("success") ("passwordRequired")

  <?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">
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <ccmp:response-code>success</ccmp:response-code>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971313@example.com">
                <info:conference-description>
                    <info:display-text>
                        SIDEBAR CONFERENCE registered by alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                        xcon:8971313@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>

                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:bob@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:carol@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
                    xsi:type="ccmp:ccmp-user-response-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:8977794@example.com</confObjID>
          <operation>create</operation>
          <ccmp:response-code>confPasswordRequired</ccmp:response-code>
          <ccmp:userResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>

  3. sidebarByRefRequest/update userRequest/create message (Alice introduces unilateral sidebar audio
     and excludes Carol from provides the sidebar) password)
  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
                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">
             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-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971313@example.com">
                <info:conference-description>
                    <info:display-text>
                        Coaching sidebar alice(supervisor) - bob(call agent)
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="sidebarAudio">
                            <info:display-text>
                                 Alice-to-Bob audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:bob@example.com"/>
                    </xcon:allowed-users-list>
                    <user entity="xcon-userid:Alice@example.com>
                      <info:endpoint>
                        <info:media>
                         <info:label>sidebarAudio</info:label>
                         <info:status>sendonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </user>
                    <user entity="xcon-userid:Bob@example.com>
                      <info:endpoint>
                        <info:media>
                         <info:label>sidebarAudio</info:label>
                         <info:status>recvonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </user>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
              xsi:type="ccmp:ccmp-user-request-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:8977794@example.com</confObjID>
          <operation>create</operation>
          <conference-password>8601</conference-password>
          <ccmp:userRequest/>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  4. userResponse/create message ("success")

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
      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">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:type="ccmp:ccmp-user-response-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:8977794@example.com</confObjID>
          <operation>create</operation>
          <response-code>success</response-code>
          <version>10</version>
          <ccmp:userResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>

      Figure 26: Coaching and Observing Messaging 19: Password-protected conference join messages details

7.  Removing participants

8.  Sidebars Scenarios and deleting Examples

   While creating conferences

   The following scenarios detail and manipulating users and their media may
   be considered enough for many scenarios, there may be cases when a
   more complex management is needed.

   In fact, a feature typically required in conferencing systems is the
   ability to create sidebars.  A sidebar is basically a child
   conference that usually includes a subset of the basic operations associated with
   removing participants from conferences of the
   parent conference, and entirely deleting
   conferences.  The examples assume that a subset of its media as well.  Sidebars are
   typically required whenever some of the participants in a conference has already been
   correctly established,
   want to discuss privately about something, without interfering with media, if applicable, per one of
   the main conference.

   This section deals with some scenarios that typically envisage the
   use of a sidebar, like whispering, private messages and coaching
   scenarios.  The first subsections, anyway, present some examples in Section 5.

7.1.  Removing of
   how a Party generic sidebar can be created, configured and managed.

8.1.  Internal Sidebar

   Figure 27 20 provides an example of one client "Alice" removing another
   participant "Bob" from a conference.  This example assumes client, "Alice", involved in an
   established
   active conference with "Alice", "Bob", "Claire" "Bob" and "Duck".  In
   this example, "Alice" "Carol".  Alice wants to remove "Bob" create a
   sidebar to have a side discussion with Bob while still viewing the
   video associated with the main conference.  Alternatively, the audio
   from the main conference so could be maintained at a reduced volume.
   Alice initiates the sidebar by sending a request to the conferencing
   system to create a conference reservation based upon the active
   conference object.  Alice and Bob would remain on the roster of the
   main conference, such that other participants could be aware of their
   participation in the group can continue main conference, while an internal-sidebar
   conference is occurring.  Besides, Bob decides that he is not
   interested in still receiving the same conference without "Bob"'s
   participation.

    "Alice"         "Bob"      "Claire" audio in background (not
   even at a lower volume as Alice configured) and so modifies the
   sidebar in order to make that stream inactive for him.

  Alice                   Bob                    ConfS
    |                      |                       |           |
    |(1) userRequest(confUserID,| sidebarByValRequest(confUserID,           |
    |         confObjID, delete,|                  confObjID,create)           |
    |--------------------------------------------->|
    |                      |         userInfo)                       |
    |
     |-------------------------------------->|                      |        (a) Create +---|
    |                      |    sidebar-by-val |   |
    |                      |     (new conf obj | (a) Focus   |
    |                      |       cloned from +-->|
    | tears down|                      |        confObjID)     | Sidebar now has
    | signaling                      |                       | id confObjID*
    |(2) sidebarByValResponse(confUserID,          | (parent mapping
    |  to "Bob"       (confObjID*, create, success,          | conf<->sidebar)
    |               |<----------------------|        version, sidebarByValInfo)            |
    |<---------------------------------------------|
    |                      |                       |
    |(3) sidebarByValRequest                       |
    |         (b)Deletes+---|       (confUserID, confObjID*,               |
    |       update,sidebarByValInfo)               | "Bob"
    |--------------------------------------------->|
    |                      |                       |
    |                      | as a        (b) Update +---|
    |                      |    sidebar-by-val |   |
    |                      |     (media, users |   |
    |                      |       etc.)       +-->|
    |                      |                       | Sidebar is
    |                      |                       | modified
    |(4) sidebarByValResponse(confUserID,          |
    |                 confObjID*, update,          |
    |                  success, version)           |
    |<---------------------------------------------|
    |                      |                       |
    |                      |(5) userRequest        |
    |                      |      (confUserID',    |
    |                      |       confObjID*,     |
    |                      | user  +-->|       update,userInfo)|
    |                      |---------------------->|
    |                      | in                       |
    |                      |        (c) Update +---|
    | confObj                      |     user settings |   |
    |                      |
     |(2) userResponse(confUserID,confObjID,     (Bob's media) |   |               delete,success,version)
    |
     |<--------------------------------------|                      |                   +-->|
    |                      |                       | Sidebar is modified
    |                      |                       | (original audio
    |                      |                       | inactive for Bob)
    | (c) Notify|                      |(6) userResponse       |
    |                      | ("Bob just|     (confUserID',     |
    |                      |  left")      confObjID*,update|
    |                      |      success,version) |           |<----------|
    |                      |<----------------------|
    |                      |                       |
     '               '           '           '
     '               '           '           '
     '               '           '           '
    "                      "                       "
    "                      "                       "
    "                      "                       "

            Figure 27: 20: Client Manipulation Creation of a Sidebar Conference - Remove

   1.  Upon receipt of CCMP sidebarByValRequest message to create a new
       sidebar-conference based upon the confObjID received in the
       request, the conferencing system uses the confObjID to clone a
       conference reservation for the sidebar.  The sidebar reservation
       is NOT independent of the active conference (i.e., parent).  The
       conferencing system also allocates a new XCON-URI for that
       sidebar to be used for any subsequent protocol requests from any
       of the members of the conference.  The new sidebar identifier
       ("confObjID*" in Figure 20) is returned in the response message
       confObjID parameter.

   2.  The relationship information is provided in the
       sidebarByValResponse message, specifically in the <sidebar-
       parent> element.  A dump of the complete representation of the
       main/parent conference is provided below as well to show how the
       cloning process for the creation of the sidebar could take place.

   3.  Upon receipt of the sidebarByValResponse message to reserve the
       conference, Alice can now create an active conference using that
       reservation, or create additional reservations based upon the
       existing reservations.  In this example, Alice wants only Bob to
       be involved in the sidebar, thus she manipulates the membership
       so that only the two of them appear in the <allowed-users-list>
       section.  Alice also wants both audio and video from the original
       conference to be available in the sidebar.  For what concerns the
       media belonging to the sidebar itself, Alice wants the audio to
       be restricted to the participants in the sidebar (that is, Bob
       and herself).  Additionally, Alice manipulates the media values
       to receive the audio from the main conference at a party

   1.  "Alice" reduced
       volume, so that the communication between her and Bob isn't
       affected.  Alice sends a userRequest message, sidebarByValRequest message with a "delete" operation.
       The an
       operation of "update" along with the "sidebarByValInfo"
       containing the aforementioned sidebar modifications.

   4.  Upon receipt of the sidebarByValRequest to update the sidebar
       reservation, the conference server ensures that "Alice" Alice has the
       appropriate authority based on the policies associated with that
       specific conference object to perform the operation.

   2.  Based upon  The
       conference server must also validate the addressing and media updated information in
       the reservation, ensuring that a member like Bob is already a
       user of this conference
       object server.  Once the data for "Bob" in the "user" element, confObjID
       is updated, the conference instigates server sends a sidebarByValResponse to
       Alice.  Depending upon the process policies, the initiator of the request
       (i.e., Alice) and the participants in the sidebar (i.e., Bob) may
       be notified of his addition to remove "Bob" (e.g., the call signaling sidebar via the conference
       notification service.

   5.  At this point, Bob sends a userRequest message to remove
       "Bob" from the conference is instigated through
       server with an operation of "update" to completely disable the
       background audio from the parent conference, since it prevents
       him from understanding what Alice says in the sidebar.

   6.  Notice that Bob's request only changes the media perspective for
       Bob. Alice keeps on receiving both the audio from Bob and the
       background from the parent conference.  This request may be
       relayed by the Focus).  The conference server updates the data in to the conference object, thus
       removing "Bob" from Media Server handling the "users" list.  After updating
       mixing, if present.  Upon completion of the data, change, the
       conference server sends a userResponse "userResponse" message to "Alice". Bob.
       Depending upon the policies, other the initiator of the request (i.e.,
       Bob) and the participants (e.g.  "Claire") in the sidebar (i.e., Alice) may be
       notified of this change via the removal conference notification service.

   That said, let's consider the following conference object:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <info:conference-info
                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"
                entity="xcon:8977878@example.com">
     <info:conference-description>
        <info:display-text>MAIN CONFERENCE</info:display-text>
        <info:conf-uris>
            <info:entry>
               <info:uri>sip:8977878@example.com</info:uri>
               <info:display-text>conference sip uri</info:display-text>
            </info:entry>
        </info:conf-uris>
        <info:available-media>
          <info:entry label="123">
            <info:display-text>main conference audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>
          </info:entry>
          <info:entry label="456">
            <info:display-text>main conference video</info:display-text>
            <info:type>video</info:type>
            <info:status>sendrecv</info:status>
            <xcon:controls>
                    <xcon:video-layout>single-view</xcon:video-layout>
           </xcon:controls>
          </info:entry>
        </info:available-media>
    </info:conference-description>
    <info:conference-state>
        <info:active>true</info:active>
    </info:conference-state>
    <info:users>
        <info:user entity="xcon-userid:Alice@example.com">
            <info:display-text>Alice</info:display-text>
            <info:endpoint entity="sip:Alice@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Bob@example.com">
            <info:display-text>Bob</info:display-text>
            <info:endpoint entity="sip:bob83@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Carol@example.com">
            <info:display-text>Carol</info:display-text>
            <info:endpoint entity="sip:carol@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
    </info:users>
  </info:conference-info>

              Figure 21: Conference with Alice, Bob and Carol

   This is the representation of "Bob" from the conference via the Conference Notification Service. sidebar is going to
   be created in.  As such, it will be used by the conferencing system
   in order to create the new conference object associated with the
   sidebar.  In fact, the sidebar creation happens through a cloning of
   the parent conference.  Once the sidebar is created, an "update"
   makes sure that the sidebar is customized as needed.  The following
   protocol dump makes the process clearer.

1. userRequest/delete sidebarByValRequest/create message (Alice deletes Bob): creates an
   internal sidebar)

  <?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-user-request-message-type">
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:userRequest>
             <userInfo entity="xcon-userid:Bob@example.com"/>
         </ccmp:userRequest>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByValRequest/>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. userResponse/delete sidebarByValResponse/create message ("success", sidebar returned)

  <?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"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-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-user-response-message-type">
                xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
          <operation>delete</operation>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>create</operation>
        <response-code>success</response-code>
         <version>17</version>
         <ccmp:userResponse/>
            <version>1</version>
        <ccmp:sidebarByValResponse>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                    <info:display-text>
                         SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                         xcon:8977878@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                  main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                  main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Carol@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

            Figure 28: Removing a Participant Messaging Details

7.2.  Deleting a Conference

   Details to be added.

   "Alice"                       ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, delete)      |
    |------------------------------>|
    |                 (a)Delete +---|
    |                    Conf   |   |
    |                    Object |   |
    |                           +-->|
    |                               |--+ (b) MS
    |                               |  | removes related
    |                               |  | mixer instances and
    |                               |<-+ their participants
    |                               |    (SIP signaling as well)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID,delete,        |
    |      success)                 |
    |                               |
    |<------------------------------|
    |                               |

                     Figure 29: Deleting a

3. sidebarByValRequest/update message (Alice updates the
   created sidebar)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
            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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                  <info:display-text>
                        private sidebar Alice - Bob
                  </info:display-text>
                  <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                main conference

   (Text description to be added).

 1. confRequest/delete audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                            <xcon:controls>
                                <xcon:gain>-60</xcon:gain>
                            </xcon:controls>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_2">
                            <info:display-text>
                                sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

4. sidebarByValResponse/update message (Alice deletes a conference) ("success", sidebar's
   updates accepted)

  <?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-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
            <version>2</version>
        <ccmp:sidebarByValResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

5. userRequest/update message (Bob updates his media)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
           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"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
           xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
      <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-conf-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:confRequest/>
                   xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:display-text>
                            main conference audio
                        </info:display-text>
                        <info:label>123</info:label>
                        <info:status>inactive</info:status>
                    </info:media>
                </info:endpoint>
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

 2. confResponse/delete
6. userResponse/update message ("success") ("success", Bob's preferences setted)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse 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">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-conf-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
                  xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
         <ccmp:confResponse/>
        <version>3</version>
        <ccmp:userResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

               Figure 30: Deleting a Conference 22: Internal Sidebar Messaging Details

8.  Additional Conference Scenarios and Examples

   The following are additional scenarios making use

8.2.  External Sidebar

   Figure 23 provides an example of the XCON
   framework and associated protocols. a different approach towards
   sidebar.  In some cases, these examples
   make use of some of this scenario, one client, "Alice", is involved in an
   active conference with "Bob", "Carol", "David" and "Ethel".  Alice
   gets an important text message via a whisper from Bob that a critical
   customer needs to talk to Alice, Bob and Ethel.  Alice creates a
   sidebar to have a side discussion with the building block scenarios detailed customer "Fred" including
   the participants in the
   previous example sections, current conference with the exception of
   Carol and David, who remain in which case the appropriate active conference.  The difference
   from the previous scenario is
   referenced rather than duplicating details.  In addition, that Fred is not part of the parent
   conference: this means that different policies might be involved,
   considering that Fred may access information coming from the parent
   conference, in cases
   where case the scenarios make use of other protocols, as sidebar was configured accordingly.  For this
   reason, in this scenario we assume that Alice disables all the previous
   section, media
   from the appropriate reference original (parent) conference within the sidebar.  This means
   that, while in the form of a title to previous example Alice and Bob still heard the
   specific flow in
   audio from the appropriate protocol document is included.

8.1.  Chat

   The chat functionality described main conference in background, this section of the document
   allows clients that use time no background
   is made available.  Alice initiates the XCON framework and protocols for other
   media types (e.g. voice/video) sidebar by sending a request
   to utilize the same conference control
   mechanisms and conferencing system to establish, update and delete create a conference instance associated with an Instant Messaging (IM) chat
   session, independent of reservation based
   upon the IM chat protocol.  In some cases(e.g.,
   Message Session Relay Protocol (MSRP) chat), this active conference object.  Alice, Bob and Ethel would provide
   additional capabilities, such as sidebars.  This approach also allows
   the conferencing system to provide a natural interworking point for
   various IM protocols, remain
   on the details roster of the interworking are outside main conference in a hold state.  Whether or not
   the
   scope hold state of this document.

   An IM client wishing these participants is visible to join a conference uses standardized
   centralized conferencing mechanisms other participants
   depends upon the individual and local policy.

 Alice                   Bob                   ConfS
   |                      |                       |
   |(1) sidebarByRefRequest(confUserID,           |
   |                 confObjID, create)           |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (a) Create +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (new conf obj |   |
   |                      |       cloned from +-->|
   |                      |        confObjID)     | Sidebar now has
   |                      |                       | id confObjID*
   |(2) sidebarByRefResponse(confUserID,          | (parent mapping
   |        confObjID*, create, success,          | conf<->sidebar)
   |          version, sidebarByRefInfo)          |
   |<---------------------------------------------|
   |                      |                       |
   |(3) sidebarByRefRequest(confUserID,           |
   |      confObjID*,update,sidebarByRefInfo)     |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (b) Create +---|
   |                      |      new user for creating and joining a
   conference, as identified in the previous sections.  The request to
   send an IM to an IM media session is specific to the IM protocol
   (e.g., MSRP SEND), just as there |   |
   |                      |            Fred   |   |
   |                      |                   +-->|
   |                      |                       |
   |                      |        (c) Update +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (media, users |   |
   |                      |     policy, etc.) +-->|
   |                      |                       | Sidebar is specific media control messaging
   for other types of sessions.  An IM client connecting to a
   conferencing system has a 1:1 relationship with the IM modified:
   |                      |                       | no media
   signaling entity in from the conferencing system.  This relationship
   |                      |                       | parent conference is
   referred
   |                      |                       | available to as an IM session.  Further details of the correlation of
   the IM session identifiers with the XCON session identifiers is
   provided in [I-D.boulton-xcon-session-chat].  The IM media signaling
   entity is responsible for distribution of all the messages anyone
   |(4) sidebarByRefResponse(confUserID,          |
   |                 confObjID*, update,          |
   |                  success, version)           |
   |<---------------------------------------------|
   |                      |                       |
   |                      |        Notify (Fred   |
   |                      |              added to the
   other participants.

   As with the other example conferences created, each IM session is
   logically associated with a specific conference.  The conference
   itself has a specific identifier in the form |
   |                      |        sidebar users) |
   |                      |<----------------------|
   |                      |                       |
   "                      "                       "
   "                      "                       "
   "                      "                       "
             Figure 23: Client Creation of an External Sidebar

   1.  Upon receipt of the XCON-URI, which
   is passed in the "confObjID" element in the CCMP messages.  This
   provides the relevant association between IM session and a
   centralized conference.

   An IM client wishing "sidebarByRefRequest" message to delete a chat room uses standardized
   mechanisms for deleting create a new
       sidebar conference, based upon the active conference instance, such as those detailed specified by
       "confObjID" in Section 7.2.

8.1.1.  Basic Chat Operations

   This section provides details of the realization of request, the Multi-party
   IM (chat) within conferencing system uses that
       active conference to clone a conference reservation for the context
       sidebar.  The sidebar reservation is NOT independent of the centralized
       active conference (i.e., parent).  The conferencing
   framework.  A brief discussion and diagrams are provided for
   creating, joining, and deleting system, as
       before, allocates a chat based conference. conference ID (confObjID*) to be used for any
       subsequent protocol requests toward the sidebar reservation.  The
   discovery of chat rooms available on a specific conferencing system
   is inherent in
       mapping between the blueprint capability provided sidebar conference ID and the one associated
       with the main conference is mantained by the conferencing
   system.  The objective of this section system
       and it is to further illustrate gathered from the
   model, mechanisms and protocols presented c<sidebar-parent> element in the previous sections
   and also serves to validate that
       sidebar conference object.

   2.  Upon receipt of the model, mechanisms "sidebarByRefResponse" message, which
       acknowledges the successful creation of the sidebar object, Alice
       decides that only Bob and protocols Ethel, along with the new participant
       Fred are sufficient to support IM chat.

   It should be noted that not all entities impacted by the request are
   shown involved in the diagram (e.g., Focus), but rather sidebar.  Thus she manipulates the emphasis is on
       membership accordingly.  Alice also sets the
   new entities introduced by this centralized conferencing framework.

8.1.1.1.  Creating a Chat Room

   There are different ways to create a conference.  A participant can
   create a conference using call signaling means only, such as SIP, as
   detailed in [RFC4579].  For a conferencing client to have more
   flexibility media in defining the charaterisitics and capabilities of a
   chat based conference, a conferencing client would implement a
   conference control protocol client.  By using a conference control
   protocol, the client can determine
       "conference-info" such that the capabilities of a conferencing
   system and its various resources.

   Figure 31 provides an example of one client "Alice" determining participants in the
   conference blueprints available sidebar don't
       receive any media from the main conference.  All these settings
       are provided to support various types of chat
   rooms for a particular the conferencing system and creating by means of a chat based
   conference using new
       "sidebarByRefRequest" message, with an "update" operation.

   3.  Alice sends the desired blueprint.

      Details aforementioned "sidebarByRefRequest" to be added.

                  Figure 31: Client Creation of Chat room update
       the information in the reservation and to create an active
       conference.  Upon receipt of the Conference Control Protocol request for
   blueprints associated "sidebarByRefRequest" with chat rooms, an
       operation of "update", the conferencing system would
   first authenticate "Alice" (and allocate a conference user
   identifier, if necessary) and then ensure ensures that "Alice" Alice
       has the appropriate authority based on system the policies to receive any chat
   room based blueprints supported by that system.  Any blueprints associated
       with that
   "Alice" is authorized specific conference object to use are returned perform the operation.
       The conferencing system also validates the updated information in a response, along with
       the reservation.  Since Fred is a new user for this conferencing
       system, a conference user ID.

   Upon receipt identifier is created for Fred.
       Specifically, Fred is added to the conference by only providing
       his SIP URI.  Based upon the contact information provided for
       Fred by Alice, the call signaling to add Fred to the conference
       may be instigated through the Focus (e.g. if Fred had a "dial-
       out" method set as the target for him) at the actual activation
       of the Conference Control Protocol response containing sidebar.

   4.  The conference server sends a "sidebarByRefResponse" message and,
       depending upon the policies, the initiator of the request (i.e.,
       Alice) and the participants in the blueprints, "Alice" determines which blueprint sidebar (i.e., Bob and Ethel)
       may be notified of his addition to use for the sidebar via the conference to be created.  "Alice"
       notification service.

1. sidebarByRefRequest/create message (Alice creates a an
   external sidebar)

  <?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-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByRefRequest/>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. sidebarByRefResponse/create message ("success", created
   sidebar returned)

  <?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-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
            <operation>create</operation>
        <response-code>success</response-code>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                        xcon:8977878@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference object based
   on audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Carol@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:David@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Ethel@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

3. sidebarByRefRequest/update message (Alice updates the blueprint (i.e., clones) and modifies applicable fields, such sidebar)

  <ccmp:ccmpRequest
                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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        sidebar with Alice, Bob, Ethel & Fred
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                        </info:display-text>
                            <info:type>video</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                 sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_2">
                            <info:display-text>
                                 sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                            <xcon:controls>
                                 <xcon:video-layout>
                                       single-view
                                 </xcon:video-layout>
                            </xcon:controls>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>

                        <xcon:target method="dial-out"
                              uri="sip:fred@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

4. sidebarByRefResponse/update message ("success", sidebar updated)

  <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-sidebarByref-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <response-code>success</response-code>
        <version>2</version>
        <ccmp:sidebarByRefResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

               Figure 24: External Sidebar Messaging Details

8.3.  Private Messages

   The case of private messages can be handled as membership list, topic details, and start time.  "Alice" then
   sends a request to the conferencing system to create a conference
   reservation based upon the updated blueprint.

   Upon receipt of the Conference Control Protocol request sidebar with just
   two participants, similarly to "create" a
   conference based upon the blueprint example in Section 8.1.  Unlike
   the request, the conferencing
   system ensures that the blueprint received is a valid blueprint (i.e.
   the values of the various field are previous example, rather than using audio within range).  The conferencing
   system determines the appropriate read/write access of any users to
   be added to a conference sidebar,
   Alice could just add an additional text based on this blueprint (using membership,
   roles, etc.).  The conferencing system uses media stream to the received blueprint
   sidebar in order to
   clone a conference reservation.  The conferencing system also
   reserves or allocates a conference ID convey her textual messages to Bob, while still
   viewing and listening to be used for any subsequent
   protocol requests from any of the members of the main conference.  The
   conferencing system maintains the mapping between

   In this conference ID
   and the conference object ID associated with scenario, Alice requests to the reservation through conferencing system the conference instance.

   Upon receipt
   creation of the conference control protocol response to reserve
   the conference, "Alice" now creates an active a private chat room using that
   reservation.  "Alice" provides the conference information, including within the necessary main conference ID, to desired participants to allow them to
   join the chat room.  "Alice" may also add other users to the chat
   room.  When context
   (presented in Figure 21) in which the first participant, including "Alice", requests to involved partecipants are just
   Bob and herself.  This can be
   added achieved through the following CCMP
   transaction (Figure 25).

   1.  Alice forwards a sidebarByValRequest/create to the conference, an active conference and focus are created.
   The focus is associated Conferencing
       Control Server with the main conference ID received in the
   request.

                           (CCMP Messaging details not available yet.
          Plan is to reference detailed flows in
          previous sections XCON-URI in the example.)

              Figure 32: Chatroom Creation Messaging Details

8.1.1.2.  Joining a Chat Room

   A participant can join
       "confObjID" parameter and leave the desired sidebar conference using call signaling
   means only, such as SIP.  However, object
       in order to perform richer
   conference control a user client can implement the "sidebarByValInfo" field.  In this way, a conference control
   protocol client.  By sidebar creation
       using user-provided conference information is requested to the
       conferencing system.  Please note that, unlike the previous
       sidebar examples, in this case a comnpletely new conference control protocol,
       object to describe the client
   can affect its own state and sidebar is provided: there is no cloning
       involved, while the state of other participants,
   depending upon policies, which may indirectly affect "confObjID" still enforces the state of any
   of parent-child
       relationship between the main conference participants.

   In and the example to-be-created
       sidebar.

   2.  The Conference Control Server, after checking Alice's rights and
       validating the conference-object carried in section Section 8.1.1.1, "Alice" has reserved the request, creates
       the required sidebar-by-val conference and a
   chat room .  "Alice" has also already joined new XCON-URI for it.
       Instead of cloning the main conference object, as envisioned in
       Section 8.1 and made Section 8.2, the chat room active.  "Alice" can either add additional participants
   to sidebar is created on the chat room or provide basis
       of the user provided conference information, including information (as anticipated
       before).  However, the
   necessary parent relationship between the main
       conference ID, to desired participants and allow them to
   request to join themselves.  Any participants that have the authority
   to manipulate newly created sidebar is still mantained by
       the conferencing system (as a consequence of the conference would receive chosen CCMP
       request message type - the conference object
   identifier of sidebarByVal one) and it is reflected
       by the active conference object <sidebar-parent> element in the response to their
   request "sidebarByValInfo" element
       returned in the sidebarByValResponse message.  Please notice
       that, according to join.

   Figure 33 provides an example of "Bob" joining the chat room using CCMP specification, the conference ID provided by "Alice" (e.g., return of the
       created sidebar data in an IM).

     Details to be added.

                      Figure 33: Joining this kind of "success" response is not
       mandatory.

1. sidebarByValRequest/create message (Alice creates a private
   chat room

   Upon receipt of the Conference Control Protocol request to "add" a
   party ("Bob") in the specific between Bob and herself)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
            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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">
                <info:conference-description>
                  <info:display-text>
                        private textual sidebar alice - bob
                  </info:display-text>
                  <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                main conference as identified by the audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference object ID, the conferencing system must determine whether
   "Bob" video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_2">
                            <info:display-text>
                                sidebar text
                            </info:display-text>
                            <info:type>text</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

2. sidebarByValResponse/create message ("success", sidebar returned)

  <?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-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>create</operation>
        <response-code>success</response-code>
            <version>1</version>
        <ccmp:sidebarByValResponse>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                    <info:display-text>
                        private textual sidebar alice - bob
                    </info:display-text>
                    <xcon:sidebar-parent>
                         xcon:8977878@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="789">
                            <info:display-text>
                                sidebar text
                            </info:display-text>
                            <info:type>text</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>
             Figure 25: Sidebar for Private Messages scenario

8.4.  Observing and Coaching

   Observing and Coaching is already a user one of the most interesting sidebars-
   related scenarios.  In fact, it envisages two different interactions
   that have to be properly coordinated.

   An example of observing and coaching is shown in figure Figure 27.
   In this conferencing system or whether he example, call center agent Bob is involved in a new user.  If "Bob" conference
   with customer Carol.  Since Bob is a new user for this conferencing system, a
   Conference User Identifier is created for Bob. The conferencing
   system must also ensure agent and Alice sees that "Bob" he
   has the appropriate authority
   based been on the policies associated call with that specific conference object Carol for longer than normal, she decides
   to perform observe the operation.

   Once "Bob" has been successfully added to call and coach Bob as necessary.  Of course the chat room, a response
   conferencing system must make sure that the customer Carol is sent to "Bob".  Depending upon not
   aware of the policies, other participants
   (including "Bob") may be notified presence of the addition coach Alice.  This makes the use of "Bob" to a
   sidebar necessary for the
   conference via success of the Conference Notification Service.

                           (CCMP Messaging details not available yet.
         Plan is to reference detailed flows in
          previous sections scenario.

   Consider the following as appropriate
          in the example.) conference document associated with the
   video conference involving Bob (the call agent) and Carol (the
   customer) (Figure 26):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <info:conference-info
                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"
                entity="xcon:8978383@example.com">
     <info:conference-description>
        <info:display-text>
                CUSTOMER SERVICE conference
        </info:display-text>
        <info:conf-uris>
            <info:entry>
               <info:uri>sip:8978383@example.com</info:uri>
               <info:display-text>conference sip uri</info:display-text>
            </info:entry>
        </info:conf-uris>
        <info:available-media>
          <info:entry label="123">
            <info:display-text>service audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>
          </info:entry>
          <info:entry label="456">
            <info:display-text>service video</info:display-text>
            <info:type>video</info:type>
            <info:status>sendrecv</info:status>
            <xcon:controls>
                    <xcon:video-layout>single-view</xcon:video-layout>
           </xcon:controls>
          </info:entry>
        </info:available-media>
    </info:conference-description>
    <info:conference-state>
        <info:active>true</info:active>
    </info:conference-state>
    <info:users>
        <info:user entity="xcon-userid:bob@example.com">
            <info:display-text>Bob - call agent</info:display-text>
            <info:endpoint entity="sip:bob@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:carol@example.com">
            <info:display-text>Carol - customer</info:display-text>
            <info:endpoint entity="sip:carol@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
    </info:users>
  </info:conference-info>

            Figure 34: Chatroom Join Messaging Details

8.1.1.3.  Deleting a Chat Room

   Depending upon the conferencing system policies and policies specific
   to the chat room, the creator of the chat would typically be the
   participant authorized to delete the chat room.

   In the 26: A call-center conference object example in section Section 8.1.1.1, "Alice"

Alice                   Bob                    ConfS
  |                      |                       |
  |(1) sidebarByRefRequest(confUserID,           |
  |                 confObjID, create)           |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (a) Create +---|
  |                      |    sidebar-by-ref |   |
  |                      |     (new conf obj |   |
  |                      |       cloned from +-->|
  |                      |        confObjID)     | Sidebar now has created a chat
   room and provided the conference information, including the necessary
   conference ID, to desired participants and allow them to request to
   join themselves.  "Bob" and others are participants in
  |                      |                       | id confObjID*
  |(2) sidebarByRefResponse(confUserID,          | (parent mapping
  |        confObjID*, create, success,          | conf<->sidebar)
  |          version, sidebarByRefInfo)          |
  |<---------------------------------------------|
  |                      |                       |
  |(3) sidebarByRefRequest(confUserID,           |
  |      confObjID*,update,sidebarByRefInfo)     |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (b) Update +---|
  |                      |    sidebar-by-val |   |
  |                      |     (media, users |   |
  |                      |     policy, etc.) +-->|
  |                      |                       | Sidebar is modified:
  |                      |                       | unilateral sidebar
  |                      |                       | audio, Carol excluded
  |                      |                       | from the chat.
   Figure 35 provides an example of "Alice" later deleting this same
   chat room.

   Details sidebar
  |(4) sidebarByRefResponse(confUserID,          |
  |                 confObjID*, update,          |
  |                  success, version)           |
  |<---------------------------------------------|
  |                      |                       |
  |                      |         Notify (Bob   |
  |                      |    he's been added to be added. |
  |                      |        sidebar users) |
  |                      |<----------------------|
  |                      |                       |
  "                      "                       "
  "                      "                       "
  "                      "                       "

      Figure 35: Deleting 27: Supervisor Creating a chat room Sidebar for Observing/Coaching

   1.  Upon receipt of the Conference Control Protocol request sidbarByRefRequest/create from Alice to "delete"
       "create" a new sidebar conference from the specific chat room as identified by confObjID received in
       the conference object ID, request, the conferencing system must determine whether "Alice" has uses the authority received active
       conference to delete this conference.  Since "Alice" is clone a conference reservation for the sidebar.
       The conferencing system also allocates a conference ID to be used
       for any subsequent protocol requests from any of the creator members of
       the
   conference, conference.  The conferencing system maintains the "delete" operation is performed, mapping
       between this conference ID and the confObjID associated with the appropriate
   signaling sent to
       sidebar reservation through the participants, including conference instance.  The
       conference server sends a response to "Alice"
   indicating that the chat room has been deleted.

   One step in sidebarByRefResponse message with the deletion
       new confObjID and relevant sidebarByRefInfo.

   2.  Upon receipt of the chat room may include notifitying sidebarByRefResponse message, Alice
       manipulates the
   participants (including "Bob") that they have been removed via data received in the
   Conference Notification Service.

                           (CCMP Messaging details not available yet.
          Plan is sidebarByRefInfo in the
       response.  Alice wants only Bob to reference detailed flows be involved in
          previous sections .)

              Figure 36: Chatroom Deletion Messaging Details

8.1.2.  Advanced Operations

   This section provides details of the realization of advanced chat
   features, such as sidebars and private messages, within sidebar,
       thus she updates the context
   of <allowed-users-list> to include only Bob and
       herself.  Alice also wants the centralized conferencing framework.  As with Section 8.1.1, audio to be received by herself
       and Bob from the objective of this section is original conference, but wants any outgoing
       audio from herself to be restricted to further illustrate the model,
   mechanisms and protocols presented participants in the previous sections and also
   serves to validate that the model, mechanisms and protocols are
   sufficient
       sidebar, whereas Bob's outgoing audio should go to support advance IM chat features.

8.1.2.1.  Text Sidebar

   The concept of a 'sidebar' in conferencing system is fully described
   in the Sidebar section main
       conference, so that both Alice and related subsections within the
   Conferencing Scenarios Realization section of the centralized
   conferencing framework document [RFC5239].  The creation,
   manipulation and deletion of sidebars for chat rooms follows customer Carol hear the
       same
   principles.

   A conference object representing audio from Bob. Alice sends a sidebar is created by cloning the
   parent associated sidebarByRefRequest message
       with an "update" operation including the existing conference and updating any
   information specific to the sidebar.  A updated sidebar conference object is
   implicitly linked to
       information.

   3.  Upon receipt of the parent conference object (i.e. it is not an
   independent object) and is associated sidebarByRefRequest message with an "update"
       operation, the parent conference
   object identifier.  A conferencing system manages and enforces ensures that Alice has the
   parent and
       appropriate localized restrictions authority based on the sidebar policies associated with that
       specific conference object (e.g., no members from outside to perform the parent
   conference instance can join, sidebar conference can not exist if
   parent conference is terminated, etc.).

   Figure 37 provides an example of one client "Alice" involved in
   active chat room with "Bob" and "Carol".  "Alice" wants operation.  In order to create
       request the insertion of a further media stream in the sidebar
       (i.e. in this example an audio stream from Alice to have Bob), the
       requestor has to provide a side discussion with "Bob" while still receiving new <entry> element in the session based messaging associated with <available-
       media> field of the main chat room.
   Whether "sidebarByRefInfo".  The mandatory "label"
       attribute of that new entry is filled with a dummy value
       "AUTO_GENERATE_1", but it will contain the text is interleaved with real server-generated
       media stream identifier when the main chat or whether a
   separate window media stream is created for effectively
       allocated on the sidebar is implementation
   specific.  "Alice" initiates server side.  Similarly, the sidebar by sending a request mandatory "id"
       attribute in <media> element referring to the
   conferencing system to create new sidebar audio
       stream under both Alice's and Bob's <endpoint> contains a conference chat reservation based
   upon the active chat conference object.  "Alice"
       wildcard value, respectively "AUTO_GENERATE_2" and "Bob" would
   remain on
       "AUTO_GENERATE_3": those values will be replaced with the roster of
       appropriated server-generated identifiers upon the main conference, such that other
   participants could be aware creation of their participation in
       the main
   conference, while referred media stream.  We are assuming the text sidebar conference conferencing
       control server is occurring.

       Details able to be added.

            Figure 37: Client Creation of recognize those dummy values as place-
       holders.

   4.  After validating the data, the conference server sends a Sidebar Conference

   Upon receipt of
       sidebarByRefResponse message.  Based upon the Conference Control Protocol request contact information
       provided for Bob by Alice, the call signaling to "reserve"
   a new add Bob to the
       sidebar chat conference, based upon with the active chat conference
   received in appropriate media characteristics is instigated
       through the request, Focus.  Bob is notified of his addition to the conferencing system uses
       sidebar via the received
   active chat conference to clone a notification service, thus he is aware
       that Alice, the supervisor, is available for coaching him through
       this call.

1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)

<?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-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8978383@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarsByRefRequest/>
    </ccmpRequest>
</ccmp:ccmpRequest>

2. sidebarByRefResponse/create message ("success")

<?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-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <operation>create</operation>
        <ccmp:response-code>success</ccmp:response-code>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971313@example.com">
                <info:conference-description>
                    <info:display-text>
                        SIDEBAR CONFERENCE registered by alice
                    </info:display-text>
                    <xcon:sidebar-parent>
                        xcon:8971313@example.com
                    </xcon:sidebar-parent>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference chat reservation for the
   sidebar.  As discussed previously, the video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:alice@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:bob@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:carol@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

  3. sidebarByRefRequest/update message (Alice introduces unilateral
     sidebar reservation is NOT
   independent of the active conference (i.e., parent).  The
   conferencing system also reserves or allocates a conference ID to be
   used for any subsequent protocol requests audio and excludes Carol from any of the members of
   the conference.  The conferencing system maintains the mapping
   between this conference ID sidebar)

  <ccmp:ccmpRequest
                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">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971313@example.com">
                <info:conference-description>
                    <info:display-text>
                        Coaching sidebar Alice and Bob
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                 Alice-to-Bob audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:bob@example.com"/>
                    </xcon:allowed-users-list>
                    <user entity="xcon-userid:Alice@example.com>
                      <info:endpoint entity="sip:Alice@example.com">
                        <info:media id="AUTO_GENERATE_2">
                         <info:label>AUTO_GENERATE_1</info:label>
                         <info:status>sendonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </user>
                    <user entity="xcon-userid:Bob@example.com>
                      <info:endpoint entity="sip:Bob@example.com">
                        <info:media id="AUTO_GENERATE_3">
                         <info:label>AUTO_GENERATE_1</info:label>
                         <info:status>recvonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </user>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

4. sidebarByRefRequest/update message ("success")
<?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-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <operation>update</operation>
        <ccmp:response-code>success</ccmp:response-code>
        <version>2</version>
        <ccmp:sidebarByRefResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

            Figure 28: Coaching and Observing Messaging details

9.  Removing Participants and Deleting Conferences

   The following scenarios detail the conference object ID basic operations associated with the sidebar reservation through the
   removing participants from conferences and entirely deleting
   conferences.  The examples assume that a conference instance.

   Upon receipt has already been
   correctly established, with media, if applicable, per one of the conference control protocol response to reserve
   the conference, "Alice" can now create
   examples in Section 6.

9.1.  Removing a Party

   Figure 29 provides an active chat example of a client, "Alice", removing another
   participant, "Bob", from a conference.  This example assumes an
   established conference
   using that reservation or create additional reservations based upon
   the existing reservations. with Alice, Bob, "Claire" and "Duck".  In this
   example, "Alice" Alice wants only "Bob" to be involved in the sidebar, thus she manipulates the membership.
   "Alice" also only wants the text remove Bob from the original conference, but
   wants the text within the sidebar to be restricted to the
   participants in the sidebar.  "Alice" sends a conference control
   protocol request to update so that the information
   group can continue in the reservation and to
   create an active conference.

   Upon receipt of the same conference control protocol request to update the
   reservation and without Bob's
   participation.

   Alice            Bob       Claire       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |         confObjID, delete,|           |
     |         userInfo)         |           |
     |-------------------------------------->|
     |               |           |           |
     |               |           | (a) Focus |
     |               |           | tears down|
     |               |           | signaling |
     |               |           |  to create an active chat conference for the sidebar, Bob |
     |               |<----------------------|
     |               |                       |
     |               |         (b)Deletes+---|
     |               |           | Bob   |   |
     |               |           | as identified by the a  |   |
     |               |           | user  +-->|
     |               |           | in        |
     |               |           | confObj   |
     |               |           |           |
     |(2) userResponse(confUserID,confObjID, |
     |               delete,success,version) |
     |<--------------------------------------|
     |               |           |           |
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  left")   |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

       Figure 29: Client Manipulation of Conference - Remove a party

   1.  Alice sends a userRequest message, with a "delete" operation.
       The conference object ID, the conferencing system server ensures that "Alice" Alice has the appropriate
       authority based on the policies associated with that specific
       conference object to perform the operation.  The conferencing system must also validate

   2.  Based upon the
   updated contact and media information in the reservation, ensuring that a member like
   "Bob" is already a user of this conference
       object for Bob in the "userInfo" element, the conferencing system.

   Depending upon system
       starts the policies, process to remove Bob (e.g., the initiator of call signaling to
       remove Bob from the request (i.e.,
   "Alice") and conference is instigated through the participants Focus).
       The conference server updates the data in the sidebar (i.e., "Bob") may be
   notified of his addition to conference object,
       thus removing Bob from the sidebar via <users> list.  After updating the
       data, the conference
   notification service.

                           Details to be added.

               Figure 38: Chatroom Sidebar Messaging Details

8.1.2.2.  Private Message

   The case of private messages can be handled as server sends a sidebar with just
   two participants, identical userResponse message to
       Alice.  Depending upon the example in section
   Section 8.1.2.1.  The policies, other context, referred to as whisper, in this
   document refers to situations involving one time media targetted to
   specific user(s).  An example of a whisper would participants (e.g.
       "Claire") may be a text message
   injected only to notified of the removal of Bob from the
       conference chair or to via the Conference Notification Service.

 1. userRequest/delete message (Alice deletes Bob):

 <?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-user-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:userRequest>
             <userInfo entity="xcon-userid:Bob@example.com"/>
         </ccmp:userRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. userResponse/delete message ("success")

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpResponse
        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">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
             <operation>delete</operation>
         <response-code>success</response-code>
         <version>17</version>
         <ccmp:userResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

            Figure 30: Removing a new participant joining Participant Messaging Details

9.2.  Deleting a conference.

   Figure 39 provides Conference

   In this section, an example of one user "Alice" who's chairing a
   fixed length successful conference with "Bob" and "Carol".  The configuration is
   such that only the chair is providing a warning when there is only 10
   minutes left in the conference.  At that time, "Alice" deletion is moved into
   a sidebar created by the conferencing system
   provided (Figure 31).

   Alice                          ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, delete)      |
    |------------------------------>|
    |                 (a)Delete +---|
    |                    Conf   |   |
    |                    Object |   |
    |                           +-->|
    |                               |--+ (b) MS
    |                               |  | removes related
    |                               |  | mixer instances and only "Alice"
   receives that text message announcing the 10 minute warning.

         Details to be added.
    |                               |<-+ their participants
    |                               |    (SIP signaling as well)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID,delete,        |
    |      success)                 |
    |                               |
    |<------------------------------|
    |                               |

                     Figure 39: Whisper

   When the conferencing system determines that there is only 10 minutes
   left in the conference which "Alice" is chairing, rather than
   creating 31: Deleting a reservation as was done for the sidebar in
   Section 8.1.2.1, the conferencing system directly creates an active
   chat sidebar conference, based on the active chat conference
   associated with "Alice".  As discussed previously, the sidebar
   conference is NOT independent of the active conference (i.e.,
   parent).

   1.  The conferencing system also allocates client "Alice" sends a conference ID confRequest
       message with a "delete" operation to be used for any subsequent manipulations of the sidebar chat
   conference.  The conferencing system maintains the mapping between
   this conference ID and the conference object ID associated with the
   active sidebar conference through performed on the
       conference instance.

   Immediately upon creation of identified by the active chat sidebar conference, XCON-URI carried in the
   text announcement is provided to "Alice".  Depending upon "confObjID"
       parameter.  The conference server, on the
   policies, Alice may be notified basis of her addition to the sidebar via
       "confUserID" included in the conference notification service.  "Alice" continues receipt request, ensures that Alice
       has the appropriate authority to receive fulfill the text messages from operation.

   2.  After validating Alice's rights, the main conference.

   Upon delivery of conferencing server
       instigates the text announcement, "Alice" is removed from process to delete the
   sidebar conference object,
       disconnetting participants and removing associated resources such
       as mixer instances.  Then, the sidebar conference is deleted.  Depending upon the
   policies, "Alice" may be notified of her removal from the sidebar via server returns a
       confResponse message to Alice with "success" as "response-code"
       and the deleted conference notification service.

                   Details to be added. XCON-URI in the "confObjID" field.

 1. confRequest/delete message (Alice deletes a conference)

 <?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-conf-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:confRequest/>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. confResponse/delete message ("success")

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpResponse
        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">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-conf-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <response-code>success</response-code>
         <ccmp:confResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

            Figure 40: Chatroom Sidebar 32: Deleting a Conference Messaging Details

9.

10.  IANA Considerations

   This document has no IANA considerations.

10.

11.  Security Considerations

   The security considerations applicable to the implementation of these
   call flows is documented in the XCON Framework, with additional
   security considerations documented in the CCMP document.  Where
   applicable, statements with regards to the necessary security are
   discussed in particular flows, however, since this is only an
   informational document, readers are strongly recommended to carefully
   consider the security considerations defined in the XCON Framework
   and the CCMP document.

11.

12.  Change Summary

   NOTE TO THE RFC-Editor: RFC-EDITOR: Please remove this section prior to
   publication as an RFC.

   The following are the major changes between the 02 and the 03
   versions of the draft:

   o  updated the call flows in order to take into account the changes
      on CCMP;

   o  added a completely new introductory section, addressing the
      protocol in general, the data model constraints, transport-related
      information, and notifications in a practical way;

   o  reorganized the chapters, grouping user-related scenarios in an
      users section, and doing the same for sidebars;

   o  added more verbose text to almost every section of the document;

   The following are the major changes between the 01 and the 02
   versions of the draft:

   o  updated the call flows in order to take into account the new
      versioning mechanism of the CCMP;

   o  clarified, per agreement in Stockholm, that cloning from a
      blueprint does not need a cloning-parent to be made available in
      the response;

   o  clarified that BFCP and CCMP-based media control are neither in
      conflict nor one the wrapper of the other; they act at different
      levels, and when both are involved, it is required that both grant
      a resource before it can be used by an interested participant;

   o  changed all the domains involved in the flows to make them
      compliant with [RFC2606];

   o  clarified that a successful creation of a new conference object
      may or may not contain the whole confInfo object in the response;
      in case it doesn't, a retrieve of the updated object can be
      achieved by issuing a confRequest/retrieve;

   o  clarified that the scenario in Section 6.1 7.3 only involves CCMP in
      adding the user to a conference; this includes requiring the use
      of a password only in adding the user to the conference object;
      the actual request for PIN/Password when joining thw conference is
      handled by means of out-of-band mechanisms (in this case at the
      media level, with the help of the MEDIACTRL framework);

   o  added and corrected Sidebars-related scenarios;

   o  added flows for some previously missing scenarios: Private
      Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
      Conference;

   o

   The following are the major changes between the 00 and the 01
   versions of the draft:

   o  Updates to reflect change of CCMP to HTTP transport model.

   The following are the major changes between the individual 01 version
   to the WG 00:

   o  Updates to reflect most recent version of CCMP, including
      parameter names, etc.

   o  Added protocol details to many of the examples.

   o  Editorial: Simplifying intro, terms, etc.

12.

13.  Acknowledgements

   The detailed content for this document is derived from the prototype
   work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
   their colleagues at the University of Napoli.

13.

14.  References
13.1.

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.

   [I-D.ietf-xcon-ccmp]
              Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
              "Centralized Conferencing Manipulation Protocol",
              draft-ietf-xcon-ccmp-05 (work in progress), December 2009.

13.2.

14.2.  Informative References

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
              (SIP) Call Control - Conferencing for User Agents",
              BCP 119, RFC 4579, August 2006.

   [RFC4597]  Even, R. and N. Ismail, "Conferencing Scenarios",
              RFC 4597, August 2006.

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

   [I-D.ietf-xcon-event-package]
              Camarillo, G., Srinivasan, S., Even, R., and J.

              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing (XCON)",
              draft-ietf-xcon-event-package-01 (work in progress),
              September 2008.

   [I-D.ietf-xcon-common-data-model]
              Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", draft-ietf-xcon-common-data-model-14 draft-ietf-xcon-common-data-model-16
              (work in progress), November 2009. February 2010.

   [I-D.ietf-mediactrl-call-flows]
              Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
              "Media Control Channel Framework (CFW) Call Flow
              Examples", draft-ietf-mediactrl-call-flows-02 draft-ietf-mediactrl-call-flows-03 (work in
              progress), October 2009. February 2010.

   [RFC5567]  Melanchuk, T., "An Architectural Framework for Media
              Server Control", RFC 5567, June 2009.

   [I-D.ietf-mediactrl-mixer-control-package]
              McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
              Control Package for the Media Control Channel Framework",
              draft-ietf-mediactrl-mixer-control-package-08
              draft-ietf-mediactrl-mixer-control-package-10 (work in
              progress), November 2009. January 2010.

   [I-D.boulton-xcon-session-chat]
              Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
              a Centralized Conferencing (XCON) System",
              draft-boulton-xcon-session-chat-04 (work in progress),
              July 2009.

Authors' Addresses

   Mary Barnes
   Nortel
   2201 Lakeside Blvd
   Richardson, TX

   Email: mary.barnes@nortel.com

   Chris Boulton
   NS-Technologies

   Email: chris@ns-technologies.com
   Lorenzo Miniero
   Meetecho
   Via Carlo Poerio 89/a
   Napoli  80121
   Italy

   Email: lorenzo@meetecho.com

   Roberta Presta
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: roberta.presta@unina.it

   Simon Pietro Romano
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: spromano@unina.it