Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6504

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Pages: 78
Informational
Part 2 of 4 – Pages 11 to 31
First   Prev   Next

Top   ToC   RFC6504 - Page 11   prevText

5. Conference Creation

This section provides details associated with the various ways in which a conference can be created using CCMP and the XCON framework constructs. As previously mentioned, the details of the media control, call signaling, and floor control protocols, where applicable, are annotated in 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., HTTPS). However, for clarification purposes, the first example in Section 5.1 provides the details of the media control messaging with the standard annotation used throughout the remainder of this document. In subsequent flows, only this
Top   ToC   RFC6504 - Page 12
   annotation (identified by lowercase letters) is included, and the
   reader is encouraged to refer to the call flows in the relevant
   documents for details about the other protocols.  The annotations for
   the call signaling are on the left side of the conference server
   vertical bar, and those for the media control messaging are on the
   right side.

5.1. Basic Conference Creation

The simplest manner in which a conference can be created is accomplished by the client sending a confRequest message with the <operation> element set to "create" as the 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 the <confObjID> element, the XCON-USERID in the form of the <confUserID> element (the same one already present in the request), and the data for the conference object in the <confInfo> parameter all returned in the confResponse message. This example also adds the issuing user to the conference upon creation with the 'method' attribute in the <target> child element of <allowed-users-list> set to "dial-out". The specific data for the conference object is returned in the confResponse message in the <confInfo> parameter. This allows the client (with the appropriate authorization) to manipulate these data and add additional participants to the conference, as well as change the 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 data in the <confInfo> element is not mandatory: if the <confInfo> parameter of is not included in the successful confResponse/create message, a subsequent confRequest/retrieve message of the returned <confObjID> can be triggered to provide the requesting client with the detailed conference description. Clients that are not XCON-aware can join the conference using a specific signaling interface such as SIP [RFC3261] (using the signaling interface to the conference focus as described in [RFC4579]), or other supported signaling protocols, being XCON- agnostic with respect to them. 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 lowercase letter items (i.e., (a)...(x)) along with the appropriate text for the processing done by the conference server.
Top   ToC   RFC6504 - Page 13
   As previously described, this example also shows how the conferencing
   system may make use of other standard protocol components for
   complete functionality.  An example of that is the media control
   framework [RFC5567], which allows the conferencing system to
   configure conference mixes, Interactive Voice Response (IVR) dialogs,
   and all sorts of media-related interactions an application like this
   may need.  In order to provide the reader with some insight on these
   interactions, the conference server in this example also configures
   and starts a mixer via a media control channel 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
   (MS) in B1/B2).  Note, that the media control interfaces are NOT
   shown in the remaining call flows in this document but rather follow
   the same annotation as with the SIP signaling such that (b)
   correlates with the A1 and A2 transactions and (d) correlates with
   the B1 and B2 transactions.
Top   ToC   RFC6504 - Page 14
   CMCC1          CMCC2        CMCCx       ConfS          MS
     |               |           |           |             |
     |(1)confRequest(confUserID, create)     |             |
     |-------------------------------------->|             |
     |               |         (a)Create +---|             |
     |               |           |Conf   |   |             |
     |               |           |Object |   |             |
     |               |           |& IDs  +-->|             |
     |               |           |           | A1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           |(create conf)|--+ (b)
     |               |           |           |             |  | create
     |               |           |           |             |  | conf and
     |               |           |           | A2. 200 OK  |<-+ its ID
     |               |           |           |<<+++++++++++|
     |               |           |           |(confid=Y)   |
     |(2)confResponse(confUserID,confObjID,  |             |
     |                create, 200, success,  |             |
     |                version, confInfo)     |             |
     |<--------------------------------------|             |
     |               |           |           |             |
     |               |     (c) Focus     +---|             |
     |               |         sets up   |   |             |
     |               |         signaling |   |             |
     |               |         to CMCC1  +-->|             |
     |               |           |           |             |
     |               |           |           | B1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           | (join CMCC1 |
     |               |           |           | <->confY)   |
     |               |           |           |             |
     |               |           |           |             |--+(d) join
     |               |           |           |             |  | CMCC1 &
     |               |           |           | B2.200 OK   |<-+ conf Y
     |               |           |           |<<+++++++++++|
     |               |           |           |             |
     |<<#################################################>>|
     |        Now the CMCC1 is mixed in the conference     |
     |<<#################################################>>|
     |               |           |           |             |
     |******CMCC1 may then manipulate conference data *****|
     |****** and add addt'l users, etc.      |        *****|
     '               '           '           '             '
     '               '           '           '             '
     '               '           '           '             '

             Figure 3: Create Basic Conference - Complete flow
Top   ToC   RFC6504 - Page 15
1. 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="ccmp:ccmp-conf-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <operation>create</operation>
        <ccmp:confRequest/>
     </ccmpRequest>
  </ccmp:ccmpRequest>

2. 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-conf-response-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:8977794@example.com</confObjID>
          <operation>create</operation>
          <response-code>200</response-code>
          <response-string>success</response-string>
          <version>1</version>
          <ccmp:confResponse>
              <confInfo entity="xcon:8977794@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>
Top   ToC   RFC6504 - Page 16
                           </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:conference-state>
                         <info:active>false</info:active>
                       </info:conference-state>
                  <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 4: Create Basic Conference Detailed Messaging

5.2. Conference Creation Using Blueprints

The previous example showed the creation of a new conference using default values. This means the client provided no information about how she wanted the conference to be created. The XCON framework (and CCMP as a consequence) allows for the implementation of templates. These templates are called "conference blueprints" and are basically conference objects with predefined settings. This means that a client might get a list of blueprints, choose the one that most fits his needs, and use the chosen blueprint to create a new conference. Figure 5 provides an example of one client, Alice, discovering the conference 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, so she makes use of the filter mechanism provided by CCMP to make a selective blueprints retrieve request. This results in three distinct CCMP transactions.
Top   ToC   RFC6504 - Page 17
   CMCC Alice                   ConfS
    |                               |
    | (1) blueprintsRequest         |
    |    (confUserID,xpathFilter)   |
    |------------------------------>|
    |                               |
    |        (2) blueprintsResponse |
    |           (confUserID,        |
    |            200, success,      |
    |            blueprintsInfo)    |
    |                               |
    |<------------------------------|
    |                               |
    |--+                            |
    |  | choose preferred           |
    |  | blueprint from the         |
    |  | list (blueprintName)       |
    |<-+                            |
    |                               |
    | (3) blueprintRequest          |
    | (confUserID,confObjID,        |
    |  retrieve)                    |
    |------------------------------>|
    |                               |
    |      4) blueprintResponse     |
    |         (confUserID,confObjID,|
    |          retrieve, 200,       |
    |          success, confInfo)   |
    |<------------------------------|
    |                               |
    | (5) confRequest(confUserID,   |
    |     confObjID,create)         |
    |------------------------------>|
    |                               |
    |                 (a)Create +---|
    |                    Conf   |   |
    |                    Object |   |
    |                    & IDs  +-->|
    |                               |--+ (b) MS
    |                               |  | creates
    |                               |  | conf and
    |                               |<-+ its ID
    |                               |   (confid=Y)
    |(6) confResponse               |
    | (confUserID, confObjID*,      |
    |  create, 200, success)        |
    |<------------------------------|
    |                               |
Top   ToC   RFC6504 - Page 18
    |                               |
    |                               |
    '                               '
    '                               '

         Figure 5: Client Creation of Conference Using Blueprints

   1.  Alice first sends a blueprintsRequest message to the conference
       server identified by the conference server discovery process.
       This request contains the <confUserID> set to the XCON-USERID of
       the user issuing the request (in this case, the one belonging to
       Alice) and the <xpathFilter> element 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
       blueprintsRequest message, the conference server would first
       ensure, on the basis of the <confUserID> parameter, that Alice
       has the appropriate authority based on system policies to receive
       the requested kind of blueprints supported by that system.

   2.  All blueprints that Alice is authorized to use are returned in a
       blueprintsResponse message in the <blueprintsInfo> element.

   3.  Upon receipt of the blueprintsResponse message 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 conference server returns the details associated with the
       specific blueprint identified by the <confObjID> in the
       <confInfo> element within the blueprintResponse message.

   5.  Alice finally sends a confRequest message with a "create"
       <operation> to the conference server to create a conference
       reservation cloning the chosen blueprint.  This is achieved by
       writing the blueprint's XCON-URI in the <confObjID> parameter.

   6.  Upon receipt of the confRequest/create message, the conference
       server uses the received blueprint to clone a conference,
       allocating a new XCON-URI (called "confObjID*" in the example).
       The conference server then sends a confResponse message including
       the new "confObjID*" associated with the newly created conference
       instance as the value of the <confObjID> parameter.  Upon receipt
       of the confResponse message, Alice can now add other users to the
       conference.
Top   ToC   RFC6504 - Page 19
 1. blueprintsRequest message (Alice requires the list of the
    available blueprints with video support)

   <?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-blueprints-request-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <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. blueprintsResponse message (the server provides a
   descriptions of the available blueprints
   fitting Alice's request)

   <?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">
      <confUserID>xcon-userid:Alice@example.com</confUserID>
      <response-code>200</response-code>
      <response-string>success</response-string>
        <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>
Top   ToC   RFC6504 - Page 20
           <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. blueprintRequest/retrieve message (Alice wants the
   "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-blueprint-request-message-type">
           <confUserID>xcon-userid:Alice@example.com</confUserID>
           <confObjID>xcon:VideoRoom@example.com</confObjID>
           <operation>retrieve</operation>
           <ccmp:blueprintRequest/>
     </ccmpRequest>
   </ccmp:ccmpRequest>

4. blueprintResponse/retrieve message ("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>200</response-code>
       <response-string>success</response-string>
       <ccmp:blueprintResponse>
         <blueprintInfo entity="xcon:VideoRoom@example.com">
           <info:conference-description>
              <info:display-text>VideoRoom</info:display-text>
Top   ToC   RFC6504 - Page 21
              <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="audioFloor">
                    <xcon:media-label>audioLabel</xcon:media-label>
                   </xcon:floor>
                   <xcon:floor id="videoFloor">
                        <xcon:media-label>videoLabel</xcon:media-label>
                   </xcon:floor>
             </xcon:conference-floor-policy>
           </xcon:floor-information>
         </blueprintInfo>
       </ccmp:blueprintResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

5. confRequest/create message (Alice clones the "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-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>
Top   ToC   RFC6504 - Page 22
6. confResponse/create message (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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>200</response-code>
       <response-string>success</response-string>
       <version>1</version>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from 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>
Top   ToC   RFC6504 - Page 23
               </info:users>
                  <xcon:floor-information>
                     <xcon:floor-request-handling>
                        confirm</xcon:floor-request-handling>
                     <xcon:conference-floor-policy>
                       <xcon:floor id="1">
                       <xcon:media-label>11</xcon:media-label>
                       </xcon:floor>
                       <xcon:floor id="2">
                       <xcon:media-label>12</xcon:media-label>
                       </xcon:floor>
                     </xcon:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

        Figure 6: Create Conference (Blueprint) Detailed Messaging

5.3. Conference Creation Using User-Provided Conference Information

A conference can also be created by the client sending a confRequest message with the "create" <operation>, along with the desired data in the form of the <confInfo> element for the conference to be created. The request also includes the <confUserID> set to the XCON-USERID of the requesting entity. This approach allows for a client (in this example Alice) to completely describe what the conference object should look like, without relying on defaults or blueprints; for example, which media should be available, the topic, the users allowed to join, any scheduling-related information, and so on. This can be done by providing, in the creation request, a full conference object for the server to parse. This <confInfo> parameter must comply with the data model specification. This means that the 'entity' attribute is mandatory and cannot be missing in the document. However, in this example, the client is actually requesting the creation of a new conference, which doesn't exist yet, so the 'entity' attribute is unknown. As discussed in Section 4.1, CCMP allows for the use of a wildcard placeholder. This placeholder ("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure the <confInfo> element is compliant with the data model and would subsequently be replaced by the conference server with the actual value. Thus, when the conference server actually creates the conference, a valid value for the 'entity' attribute is created for it as well, which takes the place
Top   ToC   RFC6504 - Page 24
   of the wildcard value when the actual conference object provided by
   the client is populated.

   To give a flavor of what could be added to the conference object, we
   assume Alice is also interested in providing scheduling-related
   information.  So, in this example, Alice also specifies by the
   <conference-time> element included in the <confInfo> that the
   conference she wants to create has to occur on a certain date
   spanning from a certain start time to a certain stop time and has to
   be replicated weekly.

   Moreover, Alice indicates by means of the <allowed-users-list>
   element that at the start time Bob, Carol, and herself have to be
   called by the conferencing system to join the conference (in fact,
   for each <target> field corresponding to one of the aforementioned
   clients, the 'method' attribute is set to "dial-out").

   Once Alice has prepared the <confInfo> element and sent it as part of
   her request to the server, if the 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 successful, and as a consequence, the XCON-URI in
   the form of the <confObjID> parameter and the XCON-USERID in the form
   of the <confUserID> parameter (again, the same as the requesting
   entity) are returned in the confResponse message.

   In this example, the created conference object is not returned in the
   successful confResponse message in the <confInfo> parameter.
   Nevertheless, Alice could still retrieve the actual conference object
   by issuing a confRequest message with a "retrieve" <operation> on the
   XCON-URI returned in the <confObjID> of the previous response.  Such
   a request would show how, as described at the beginning of this
   section, the 'entity' attribute of the conference object in the
   <confInfo> field is replaced with the actual information (i.e.,
   "xcon:6845432@example.com").
Top   ToC   RFC6504 - Page 25
   Alice            Bob        Carol       ConfS
     |               |           |           |
     |               |           |           |
     |(1)confRequest(confUserID, |           |
     |         create, confInfo) |           |
     |               |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |         (a)Create +---|
     |               |           |Conf   |   |
     |               |           |Object |   |
     |               |           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |           |  | creates
     |               |           |           |  | conf and
     |               |           |           |<-+ its ID
     |               |           |           |   (confid=Y)
     |(2)confResponse(confUserID,|           |
     |       confObjID, create,  |           |
     |       200, success, version)          |
     |<--------------------------------------|
     |               |           |           |
    ===========================================
    ...             ...         ...         ...
    ========== START TIME OCCURS ==============
     |               |     (c) Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to Alice  +-->|
     |               |           |           |
     |               |           |           |--+(d) MS joins
     |               |           |           |  | Alice &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |           |           |
     |<<###################################>>|
     | Alice is mixed in the conference      |
     |<<###################################>>|
     |               |           |           |
     |               |     (e)Focus      +---|
     |               |        sets up    |   |
     |               |        signaling  |   |
     |               |        to Bob     |   |
     |               |           |       +-->|
     |               |           |           |
     |               |           |           |--+(f)MS joins
     |               |           |           |  | Bob &
     |               |           |           |<-+ conf Y
Top   ToC   RFC6504 - Page 26
     |               |           |           |
     |               |<<###################>>|
     |               |  Bob is mixed too     |
     |               |<<###################>>|
     |               |           |           |
     |               |     (g )Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to Carol  |   |
     |               |         CMCCx     +-->|
     |               |           |           |
     |               |           |           |--+(h)MS joins
     |               |           |           |  | CMCCx &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |           |<<#######>>|
     |               |           |Carol mixed|
     |               |           |<<#######>>|
     |               |           |           |
     |               |           |           |
     |               |           |           |
     |<***All parties connected to conf Y***>|
     |               |           |           |
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

   Figure 7: Create Basic Conference from User-Provided Conference Info

  1. confRequest/create message (Alice proposes a conference object
     to be created)

    <?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 entity="xcon:AUTO_GENERATE_1@example.com">
              <info:conference-description>
                  <info:display-text>
                     Dial-out conference initiated by Alice
Top   ToC   RFC6504 - Page 27
                  </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>
Top   ToC   RFC6504 - Page 28
               </info:users>
           </confInfo>
        </ccmp:confRequest>
     </ccmpRequest>
  </ccmp:ccmpRequest>

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

           Figure 8: Create Basic Conference Detailed Messaging

5.4. Cloning an Existing Conference

A client can also create another conference by cloning an existing conference, such as an active conference or conference reservation. This approach can be seen as a logical extension of the creation of a new conference using a blueprint: the difference is that, instead of cloning the predefined 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 "create" <operation>, along with her XCON-USERID in the <confUserID> element and the XCON-URI of the conference from which a new conference is to be cloned in the <confObjID> element. An example of how a client can create a conference based on a blueprint is provided in Section 5.2. The manner by which a 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 querying for different types of conference
Top   ToC   RFC6504 - Page 29
   objects supported by the specific conferencing system.  For instance,
   in this example, the client clones a conference reservation (i.e., an
   inactive conference).

   If the conferencing system can support a new instance of the specific
   type of conference (capabilities, etc.), then the request results in
   the creation of a conference, with an XCON-URI in the form of a new
   value in the <confObjID> parameter to reflect the newly cloned
   conference object 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,       |
    |      200, success,            |
    |      version, confInfo)       |
    |                               |
    |<------------------------------|
    |                               |
    '                               '

                 Figure 9: Create Basic Conference - Clone

   1.  Alice, a conferencing system client, sends a confRequest message
       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 XCON-URI
       in the <confObjID> provided in the request.

   2.  Upon receipt of the confRequest message containing a "create"
       <operation> and the aforementioned XCON-URI in the <confObjID>,
       the conference server ensures that such received XCON-URI is
       valid.  The conference server determines the appropriate read/
       write access of any users to be added to a conference based on
       this XCON-URI (using membership, roles, etc.).  The conference
Top   ToC   RFC6504 - Page 30
       server uses the received <confObjID> to clone a conference
       reservation.  The conference server also reserves or allocates a
       new XCON-URI (called "confObjID*" in Figure 9) to be used for 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 must use this new identifier.  The conference server
       maintains the mapping between this conference ID and the parent
       conference object ID associated with the reservation through the
       conference instance, and this mapping is explicitly addressed
       through the <cloning-parent> element of the <conference-
       description> in the new conference object.

1. confRequest/create message (Alice clones an existing 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:6845432@example.com</confObjID>
        <operation>create</operation>
        <ccmp:confRequest/>
     </ccmpRequest>
  </ccmp:ccmpRequest>

2. confResponse/create message (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-conf-response-message-type">
       <confUserID>xcon-userid:Alice@example.com</confUserID>
       <confObjID>xcon:8977794@example.com</confObjID>
       <operation>create</operation>
       <response-code>200</response-code>
       <response-string>success</response-string>
       <version>1</version>
Top   ToC   RFC6504 - Page 31
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@example.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from 6845432
                  </info:display-text>
                   <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>
                   <xcon:cloning-parent>
                      xcon:6845432@example.com
                  </xcon:cloning-parent>
               </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="1">
                        <xcon:media-label>11</xcon:media-label>
                       </xcon:floor>
                     </xcon:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

       Figure 10: Create Basic Conference (Clone) Detailed Messaging



(page 31 continued on part 3)

Next Section