tech-invite   World Map     

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

RFC 6504

 
 
 

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Part 2 of 4, p. 11 to 31
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 11 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part