RFC 6504
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
Pages: 78
Informational
Informational
Part 2 of 4 – Pages 11 to 31
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
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.
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.
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
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>
</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 Messaging5.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.
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) |
|<------------------------------|
| |
| | | | ' ' ' ' 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.
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>
<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>
<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>
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>
</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 Messaging5.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
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").
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
| | | | | |<<###################>>| | | 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
</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. 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 Messaging5.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
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
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>
<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)