RFC 6503
Centralized Conferencing Manipulation Protocol
5.3.11. extendedRequest and extendedResponse
In order to allow specifying new request and response pairs for conference control, CCMP defines the extendedRequest and extendedResponse messages. Such messages constitute a CCMP skeleton in which implementers can transport the information needed to realize conference control mechanisms not explicitly envisioned in the CCMP specification; these mechanisms are called, in this context, "extensions". Each extension is assumed to be characterized by an appropriate name that MUST be carried in the extendedRequest/ extendedResponse pair in the provided <extensionName> field. Extension-specific information can be transported in the form of schema-defined XML elements inside the <any> element present in both extendedRequest and extendedResponse. The conferencing client SHOULD be able to determine the extensions supported by a CCMP server and to recover the XML schema defining the related specific elements by means of an optionsRequest/ optionsResponse CCMP transaction (see Section 5.3.12). The meaning of the common CCMP parameters inherited by the extendedRequest and extendedResponse from the basic CCMP request and response messages SHOULD be preserved and exploited appropriately while defining an extension.
<!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType --> <xs:element name="extendedResponse" type="extendedResponseType"/> <xs:complexType name="extendedResponseType"> <xs:sequence> <xs:element name="extensionName" type="xs:string" minOccurs="1"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> Figure 17: Structure of the extendedRequest and extendedResponse Messages5.3.12. optionsRequest and optionsResponse
The optionsRequest message (Figure 18) retrieves general information about conference server capabilities. These capabilities include the standard CCMP messages (request/response pairs) and potential extension messages supported by the conference server. As such, it is a basic CCMP message, rather than a specialization of the general CCMP request. The optionsResponse returns, in the appropriate <options> field, a list of the supported CCMP message pairs as defined in this specification. These messages are in the form of a list: <standard- message-list> including each of the supported messages as reflected by <standard-message> elements. The optionsResponse message also allows for an <extended-message-list>, which is a list of additional message types in the form of <extended-message-list> elements that are currently undefined, to allow for future extensibility. The following information is provided for both types of messages: o <name> (REQUIRED): in case of standard messages, it can be one of the 10 standard message names defined in this document (i.e., "blueprintsRequest", "confsRequest", etc.). In case of extensions, this element MUST carry the same value of the <extension-name> inserted in the corresponding extendedRequest/ extendedResponse message pair. o <operations> (OPTIONAL): this field is a list of <operation> entries, each representing the Create, Read, Update, Delete (CRUD) operation supported by the server for the message. If this element is absent, the client SHOULD assume the server is able to
handle the entire set of CRUD operations or, in case of standard
messages, all the operations envisioned for that message in this
document.
o <schema-ref> (OPTIONAL): since all CCMP messages can potentially
contain XML elements not envisioned in the CCMP schema (due to the
presence of <any> elements and attributes), a reference to a
proper schema definition specifying such new elements/attributes
can also be sent back to the clients by means of such field. If
this element is absent, no new elements are introduced in the
messages other than those explicitly defined in the CCMP
specification.
o <description> (OPTIONAL): human-readable information about the
related message.
The only parameter needed in the optionsRequest is the sender
confUserID, which is mirrored in the same parameter of the
corresponding optionsResponse.
The CCMP server MUST include the <standard-message-list> containing
at least one <operation> element in the optionsResponse, since a CCMP
server is REQUIRED to be able to handle both the request and response
messages for at least one of the operations.
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message"
type="standard-message-type"
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name"
type="standard-message-name-type"
minOccurs="1"/>
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def"
type="xs:string" minOccurs="0"/>
<xs:element name="description"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<!-- operations-type --> <xs:complexType name="operations-type"> <xs:sequence> <xs:element name="operation" type="operationType" minOccurs="1" maxOccurs="4"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> Figure 18: Structure of the optionsRequest and optionsResponse Messages5.4. CCMP Response Codes
All CCMP response messages MUST include a <response-code>. This document defines an IANA registry for the CCMP response codes, as described in Section 12.5.2. The following summarizes the CCMP response codes: 200 Success: Successful completion of the requested operation. 400 Bad Request: Syntactically malformed request. 401 Unauthorized: User not allowed to perform the required operation. 403 Forbidden: Operation not allowed (e.g., cancellation of a blueprint). 404 Object Not Found: The target conference object does not exist at the server (The object in the error message refers to the <confObjID> parameter in the generic request message). 409 Conflict: A generic error associated with all those situations in which a requested client operation cannot be successfully completed by the server. An example of such a situation is when the modification of an object cannot be applied due to conflicts arising at the
server's side, e.g., because the client version of the object is
an obsolete one and the requested modifications collide with the
up-to-date state of the object stored at the server. Such code
would also be used if a client attempts to create an object
(conference or user) with an entity that already exists.
420 User Not Found:
Target user missing at the server (it is related to the XCON-
USERID in the 'entity' attribute of the <userInfo> parameter when
it is included in userRequests).
421 Invalid confUserID:
User does not exist at the server (This code is returned for
requests where the <confUserID> parameter is invalid).
422 Invalid Conference Password:
The password for the target conference object contained in the
request is wrong.
423 Conference Password Required:
"conference-password" missing in a request to access a password-
protected conference object.
424 Authentication Required:
User's authentication information is missing or invalid.
425 Forbidden Delete Parent:
Cancel operation failed since the target object is a parent of
child objects that depend on it, or because it affects, based on
the "parent-enforceable" mechanism, the corresponding element in a
child object.
426 Forbidden Change Protected:
Update refused by the server because the target element cannot be
modified due to its implicit dependence on the value of a parent
object ("parent-enforceable" mechanism).
427 Invalid Domain Name:
The domain name in an AUTO_GENERATE_X instance in the conference
object is not within the CCMP server's domain of responsibility.
500 Server Internal Error:
The server cannot complete the required service due to a system
internal error.
501 Not Implemented:
Operation defined by the protocol, but not implemented by this
server.
510 Request Timeout:
The time required to serve the request has exceeded the configured
service threshold.
511 Resources Not Available:
This code is used when the CCMP server cannot execute a command
because of resource issues, e.g., it cannot create a sub-
conference because the system has reached its limits on the number
of sub-conferences, or if a request for adding a new user fails
because the max number of users has been reached for the
conference or the max number of users has been reached for the
conferencing system.
The handling of a <response-code> of "404", "409", "420", "421",
"425", "426", or "427" is only applicable to specific operations for
specialized message responses and the details are provided in
Section 5.3. The following table summarizes these response codes and
the specialized message and operation to which they are applicable:
+----------+-------------+--------------+-------------+-------------+ | Response | Create | Retrieve | Update | Delete | | code | | | | | +----------+-------------+--------------+-------------+-------------+ | 404 | userRequest | All retrieve | All update | All delete | | | sidebarBy | requests | requests | requests | | | ValRequest, | EXCEPT: | | | | | sidebarsBy | blueprints | | | | | RefRequest | Request, | | | | | | confsRequest | | | | -------- | ----------- | ------------ | ----------- | ----------- | | 409 | N/A | N/A | All update | N/A | | | | | requests | | | -------- | ----------- | ----------- | ----------- | ----------- | | 420 | userRequest | userRequest | userRequest | userRequest | | | (third- | | | | | | party | | | | | | invite with | | | | | | third-user | | | | | | entity) (*) | | | | | -------- | ----------- | ----------- | ----------- | ----------- | | 421 | All create | All retrieve | All update | All delete | | | requests | requests | requests | requests | | | EXCEPT: | | | | | | userRequest | | | | | | with no | | | | | | confUserID | | | | | | (**) | | | | | -------- | ----------- | ----------- | ----------- | ----------- | | 425 | N/A | N/A | N/A | All delete | | | | | | request | | -------- | ----------- | ----------- | ----------- | ----------- | | 426 | N/A | N/A | All update | N/A | | | | | requests | | | -------- | ----------- | ----------- | ----------- | ----------- | | 427 | ConfRequest | N/A | All update | N/A | | | UserRequest | | requests | | +----------+-------------+--------------+-------------+-------------+ Table 2: Response Codes and Associated Operations (*) "420" in answer to a "userRequest/create" operation: In the case of a third-party invite, this code can be returned if the <confUserID> (contained in the 'entity' attribute of the <userInfo> parameter) of the user to be added is unknown. In the case above, if instead it is the <confUserID> parameter of the sender of the request that is invalid, a <response-code> of "421" is returned to the client.
(**) "421" is not sent in answer to userRequest/create messages having a "null" confUserID, since this case is associated with a user who is unaware of his own XCON-USERID, but wants to enter a known conference. In the case of a <response-code> of "510", a conferencing client MAY re-attempt the request within a period of time that would be specific to a conferencing client or conference server. A <response-code> of "400" indicates that the conferencing client sent a malformed request, which is indicative of an error in the conferencing client or in the conference server. The handling is specific to the conferencing client implementation (e.g., generate a log, display an error message, etc.). It is NOT RECOMMENDED that the client re-attempt the request in this case. A <response-code> of "401" or "403" indicates the client does not have the appropriate permissions, or there is an error in the permissions: re-attempting the request would likely not succeed and thus it is NOT RECOMMENDED. Any unexpected or unknown <response-code> SHOULD be treated by the client in the same manner as a <response-code> of "500", the handling of which is specific to the conferencing client implementation.6. A Complete Example of CCMP in Action
In this section a typical, non-normative, scenario in which CCMP comes into play is described, by showing the actual composition of the various CCMP messages. In the call flows of the example, the conferencing client is a CCMP-enabled client, and the conference server is a CCMP-enabled server. The XCON-USERID of the client, Alice, is "xcon-userid:alice@example.com" and it appears in the <confUserID> parameter in all requests. The sequence of operations is as follows: 1. Alice retrieves the list of available blueprints from the server (Section 6.1); 2. Alice asks for detailed information about a specific blueprint (Section 6.2); 3. Alice decides to create a new conference by cloning the retrieved blueprint (Section 6.3); 4. Alice modifies information (e.g., XCON-URI, name, and description) associated with the newly created blueprint (Section 6.4);
5. Alice specifies a list of users to be contacted when the
conference is activated (Section 6.5);
6. Alice joins the conference (Section 6.6);
7. Alice lets a new user, Ciccio, (whose XCON-USERID is
"xcon-userid:Ciccio@example.com") join the conference
(Section 6.7).
8. Alice asks for the CCMP server capabilities (Section 6.8);
9. Alice exploits an extension of the CCMP server (Section 6.9).
Note that the examples do not include any details beyond the basic
operation.
In the following sections, we deal with each of the aforementioned
actions separately.
6.1. Alice Retrieves the Available Blueprints
This section illustrates the transaction associated with retrieval of
the blueprints, together with a dump of the two messages exchanged
(blueprintsRequest and blueprintsResponse). As shown in the figure,
the blueprintsResponse message contains, in the <blueprintsInfo>
parameter, information about the available blueprints, in the form of
the standard XCON-URI of the blueprint, plus additional (and
optional) information, like its display-text and purpose.
Alice retrieves from the server the list of available blueprints:
CCMP Client CCMP Server
| |
| CCMP blueprintsRequest message |
| - confUserID: Alice |
| - confObjID: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintsResponse message |
| - confUserID: Alice |
| - confObjID: (null) |
| - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------|
| |
. .
. .
1. blueprintsRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<ccmp:blueprintsRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintsResponse message from the server:
<?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>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room:
conference room with public access,
where only audio is available, more users
can talk at the same time
and the requests for the AudioFloor
are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
8 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry> <info:entry> <info:uri>xcon:AudioConference1@example.com</info:uri> <info:display-text>AudioConference1</info:display-text> <info:purpose>Public Audio Conference: conference with public access, where only audio is available, only one user can talk at the same time, and the requests for the AudioFloor MUST be accepted by a Chair. </info:purpose> </info:entry> <info:entry> <info:uri>xcon:VideoConference1@example.com</info:uri> <info:display-text>VideoConference1</info:display-text> <info:purpose>Public Video Conference: conference where both audio and video are available, only one user can talk. </info:purpose> </info:entry> <info:entry> <info:uri>xcon:AudioConference2@example.com</info:uri> <info:display-text>AudioConference2</info:display-text> <info:purpose>Basic Audio Conference: conference with private access, where only audio is available, only one user can talk at the same time, and the requests for the AudioFloor MUST be accepted by a Chair. </info:purpose> </info:entry> </blueprintsInfo> </ccmp:blueprintsResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 19: Getting Blueprints from the Server6.2. Alice Gets Detailed Information about a Specific Blueprint
This section illustrates the second transaction in the overall flow. In this case, Alice, who now knows the XCON-URIs of the blueprints available at the server, makes a drill-down query, in the form of a CCMP blueprintRequest message, to get detailed information about one of them (the one called with XCON-URI "xcon:AudioRoom@example.com"). The picture shows such a transaction. Notice that the response contains, in the <blueprintInfo> parameter, a document compliant with the standard XCON data model.
Alice retrieves detailed information about a specified blueprint:
CCMP Client CCMP Server
| |
| CCMP blueprintRequest message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - blueprintInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintResponse message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - response-code: 200 |
| - blueprintInfo: bp123Info |
|<------------------------------------------------------|
| |
. .
. .
1. blueprintRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <operation>retrieve</operation> <response-code>200</response-code> <response-string>Success</response-string> <ccmp:blueprintResponse> <blueprintInfo entity="xcon:AudioRoom@example.com"> <info:conference-description> <info:display-text>AudioRoom</info:display-text> <info:available-media> <info:entry label="audioLabel"> <info:display-text>audio stream</info:display-text> <info:type>audio</info:type> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling> </info:users> <xcon:floor-information> <xcon:floor-request-handling>confirm</xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="audioFloor"> <xcon:media-label>audioLabel</xcon:media-label> </xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </blueprintInfo> </ccmp:blueprintResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 20: Getting Information about a Specific Blueprint6.3. Alice Creates a New Conference through a Cloning Operation
This section illustrates the third transaction in the overall flow. Alice decides to create a new conference by cloning the blueprint having XCON-URI "xcon:AudioRoom@example.com", for which she just retrieved detailed information through the blueprintRequest message. This is achieved by sending a confRequest/create message having the blueprint's URI in the <confObjID> parameter. The picture shows such a transaction. Notice that the response contains, in the <confInfo> parameter, the document associated with the newly created conference, which is compliant with the standard XCON data model. The <confObjID> parameter in the response is set to the XCON-URI of the new conference (in this case, "xcon:8977794@example.com"). We also
notice that this value is equal to the value of the 'entity'
attribute of the <conference-info> element of the document
representing the newly created conference object.
Alice creates a new conference by cloning the
"xcon:AudioRoom@example.com" blueprint:
CCMP Client CCMP Server
| |
| CCMP confRequest message |
| - confUserID: Alice |
| - confObjID: AudioRoom |
| - operation: create |
| - confInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP confResponse message |
| - confUserID: Alice |
| - confObjID: newConfId |
| - operation: create |
| - response-code: 200 |
| - version: 1 |
| - confInfo: newConfInfo |
|<------------------------------------------------------|
| |
. .
. .
1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse message from the server: <?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 AudioRoom </info:display-text> <info:available-media> <info:entry label="333"> <info:display-text>audio stream</info:display-text> <info:type>audio</info:type> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling> </info:users> <xcon:floor-information> <xcon:floor-request-handling>confirm</xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="11"> <xcon:media-label>333</xcon:media-label> </xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </confInfo> </ccmp:confResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 21: Creating a New Conference by Cloning a Blueprint
6.4. Alice Updates Conference Information
This section illustrates the fourth transaction in the overall flow. Alice decides to modify some of the details associated with the conference she just created. More precisely, she changes the <display-text> element under the <conference-description> element of the document representing the conference. This is achieved through a confRequest/update message carrying the fragment of the conference document to which the required changes have to be applied. As shown in the picture, the response contains a code of "200", which acknowledges the modifications requested by the client, while also updating the conference version number from 1 to 2, as reflected in the "version" parameter. Alice updates information about the conference she just created: CCMP Client CCMP Server | | | CCMP confRequest message | | - confUserID: Alice | | - confObjID: 8977794 | | - operation: update | | - confInfo: confUpdates | |------------------------------------------------------>| | | | CCMP confResponse message | | - confUserID: Alice | | - confObjID: 8977794 | | - operation: update | | - response-code: 200 | | - version: 2 | | - confInfo: (null) | |<------------------------------------------------------| | | . . . . 1. confRequest message: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-conf-request-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <operation>update</operation> <ccmp:confRequest> <confInfo entity="xcon:8977794@example.com"> <info:conference-description> <info:display-text> Alice's conference </info:display-text> </info:conference-description> </confInfo> </ccmp:confRequest> </ccmpRequest> </ccmp:ccmpRequest> 2. confResponse message from the server: <?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>update</operation> <response-code>200</response-code> <response-string>Success</response-string> <version>2</version> <ccmp:confResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 22: Updating Conference Information6.5. Alice Inserts a List of Users into the Conference Object
This section illustrates the fifth transaction in the overall flow. Alice modifies the <allowed-users-list> under the <users> element in the document associated with the conference she created. To achieve this, she makes use of the usersRequest message provided by CCMP. Alice updates information about the list of users to whom access to the conference is permitted:
CCMP Client CCMP Server
| |
| CCMP usersRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - usersInfo: usersUpdates |
|------------------------------------------------------>|
| |
| CCMP usersResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - response-code: 200 |
| - version: 3 |
| - usersInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. usersRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<ccmp:usersRequest>
<usersInfo>
<xcon:allowed-users-list>
<xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer"
uri="tel:+1-972-555-1234"/>
<xcon:target method="refer"
uri="sip:Carol@example.com"/>
</xcon:allowed-users-list>
</usersInfo>
</ccmp:usersRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. usersResponse message from the server: <?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-users-response-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>retrieve</operation> <response-code>200</response-code> <response-string>Success</response-string> <version>3</version> <ccmp:usersResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 23: Updating the List of Allowed Users for the Conference 'xcon:8977794@example.com'6.6. Alice Joins the Conference
This section illustrates the sixth transaction in the overall flow. Alice uses CCMP to add herself to the newly created conference. This is achieved through a userRequest/create message containing, in the <userInfo> parameter, a <user> element compliant with the XCON data model representation. Notice that such an element includes information about the user's Addresses of Record, as well as her current endpoint. The picture below shows the transaction. Notice how the <confUserID> parameter is equal to the 'entity' attribute of the <userInfo> element, which indicates that the request issued by the client is a first-party one. Alice joins the conference by issuing a userRequest/create message with her own ID to the server:
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: AliceUserInfo |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 4 |
| - userInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse message from the server: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <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>4</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 24: Alice Joins the Conference through CCMP6.7. Alice Adds a New User to the Conference
This section illustrates the seventh and last transaction in the overall flow. Alice uses CCMP to add a new conferencing system user, Ciccio, to the conference. This "third-party" request is realized through a userRequest/create message containing, in the <userInfo> parameter, a <user> element compliant with the XCON data model representation. Notice that such an element includes information about Ciccio's Addresses of Record, as well as his current endpoint, but has a placeholder 'entity' attribute, "AUTO_GENERATE_1@example.com" as discussed in Section 4.3, since the XCON-USERID is initially unknown to Alice. Thus, the conference server is in charge of generating a new XCON-USERID for the user Alice indicates (i.e., Ciccio), and returning it in the 'entity' attribute of the <userInfo> parameter carried in the response, as well as adding the user to the conference. The picture below shows the transaction. Alice adds user "Ciccio" to the conference by issuing a third-party userRequest/create message to the server:
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: dummyUserID, CiccioUserInfo |
|------------------------------------------------------>|
| |
| CCMP optionsResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 5 |
| - userInfo: userIDCiccio, |
| CiccioUserInfo |
| |
|<------------------------------------------------------|
| |
. .
. .
1. "third-party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest> 2. "third-party" userResponse message from the server: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <version>5</version> <ccmp:userResponse> <userInfo entity="xcon-userid:Ciccio@example.com"> <info:associated-aors> <info:entry> <info:uri> mailto:Ciccio@example.com </info:uri> <info:display-text>email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:Ciccio@example.com"/> </userInfo> </ccmp:userResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 25: Alice Adds a New User to the Conference through CCMP6.8. Alice Asks for the CCMP Server Capabilities
This section illustrates how Alice can discover which standard CCMP messages and what extensions are supported by the CCMP server with which she interacts through an optionsRequest/optionsResponse transaction. To prepare the optionsRequest, Alice just puts her XCON-USERID in the <confUserID> parameter. Looking at the <options> element in the received optionsResponse, Alice infers the following server capabilities as regards standard CCMP messages:
o the server doesn't support sidebarsByValRequest nor the
sidebarByValRequest messages, since they do not appear in the
<standard-message-list>;
o the only implemented operation for the blueprintRequest message is
"retrieve", since no other <operation> entries are included in the
related <operations> field.
By analyzing the <extended-message-list>, Alice discovers the server
implements a bluePrint extension, referred to as "confSummaryRequest"
in this example. This extension allows Alice to recover via CCMP a
brief description of a specific conference; the XML elements involved
in this extended conference control transaction are available at the
URL indicated in the <schema-ref> element, and the only operation
provided by this extension is "retrieve". To better understand how
Alice can exploit the "confSummaryRequest" extension via CCMP, see
Section 6.9.
The figure below shows the optionsRequest/optionsResponse message
exchange between Alice and the CCMP server.
CCMP Client CCMP Server
| |
| CCMP optionsRequest message |
| - confUserID: Alice |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
1. optionsRequest (Alice asks for CCMP server capabilities)
<?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-options-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
</ccmpRequest>
</ccmp:ccmpRequest>
2. optionsResponse (the server returns the list of its conference
control capabilities)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
<standard-message>
<name>blueprintRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
</standard-message>
<standard-message>
<name>confsRequest</name>
</standard-message>
<standard-message>
<name>confRequest</name>
</standard-message>
<standard-message>
<name>usersRequest</name>
</standard-message>
<standard-message>
<name>userRequest</name>
</standard-message>
<standard-message>
<name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list>
<extended-message-list>
<extended-message> <name>confSummaryRequest</name> <operations> <operation>retrieve</operation> </operations> <schema-def> http://example.com/ccmp-extension-schema.xsd </schema-def> <description> confSummaryRequest is intended to allow the requestor to retrieve a brief description of the conference indicated in the confObjID request parameter </description> </extended-message> </extended-message-list> </options> </ccmp:optionsResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 26: Alice Asks for the Server Control Capabilities6.9. Alice Makes Use of a CCMP Server Extension
In this section, a very simple example of CCMP extension support is provided. Alice can recover information about this and other server- supported extensions by issuing an optionsRequest (see Section 6.8). The extension in question is named "confSummaryRequest" and allows a CCMP client to obtain from the CCMP server synthetic information about a specific conference. The conference summary is carried in the form of an XML element as follows: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://example.com/ccmp-extension" xmlns="http://example.com/ccmp-extension"> <xs:element name="confSummary" type="conf-summary-type"/> <xs:complexType name="conf-summary-type"> <xs:sequence> <xs:element name="title" type="xs:string"/> <xs:element name="status" type="xs:string"/> <xs:element name="public" type="xs:boolean"/> <xs:element name="media" type="xs:string"/>
</xs:sequence> </xs:complexType> </xs:schema> Figure 27: Example of XML Schema defining an extension parameter (ccmp-extension-schema.xsd) As can be inferred from the schema file, the <confSummary> element contains conference information related to the following: o title o status (active or registered) o participation modality (if everyone is allowed to participate, the boolean <public> element is set to "true") o involved media In order to retrieve a conference summary related to the conference she participates in, Alice sends to the CCMP server an extendedRequest with a "confSummaryRequest" <extensionName>, specifying the conference XCON-URI in the confObjID request parameter, as depicted in the figure below. CCMP Client CCMP Server | | | CCMP extendedRequest message | | - confUserID: Alice | | - confObjID: 8977794 | | - operation: retrieve | | - extensionName: confSummaryRequest | |------------------------------------------------------>| | | | CCMP extendedResponse message | | - confUserID: Alice | | - confObjID: 8977794 | | - operation: retrieve | | - response-code: 200 | | - extensionName: | | confSummaryRequest | | - confSummary | |<------------------------------------------------------| | | . . . .
1. extendedRequest (Alice makes use of the "confSummaryRequest") <?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" xmlns:example="http://example.com/ccmp-extension"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-extended-request-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>retrieve</operation> <ccmp:extendedRequest> <extensionName>confRequestSummary</extensionName> </ccmp:extendedRequest> </ccmpRequest> </ccmp:ccmpRequest> 2. extendedResponse (the server provides Alice with a brief description of the desired conference) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:example="http://example.com/ccmp-extension"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-extended-response-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>retrieve</operation> <response-code>200</response-code> <response-string>success</response-string> <ccmp:extendedResponse> <extensionName>confSummaryRequest</extensionName> <example:confSummary> <title> Alice's conference </title> <status> active </status> <public> true </public> <media> audio </media> </example:confSummary> </ccmp:extendedResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 28: Alice Exploits the 'confSummaryRequest' Extension
7. Locating a Conference Server
If a conferencing client is not pre-configured to use a specific conference server for the requests, the client MUST first discover the conference server before it can send any requests. The result of the discovery process, is the address of the server supporting conferencing. In this document, the result is an http: or https: URI, which identifies a conference server. DNS is RECOMMENDED to be used to locate a conference server in the case that the client is not pre-configured to use a specific conference server. URI-Enabled NAPTR (U-NAPTR) resolution for conferencing takes a domain name as input and produces a URI that identifies the conference server. This process also requires an Application Service tag and an Application Protocol tag, which differentiate conferencing-related NAPTR records from other records for that domain. Section 12.4.1 defines an Application Service tag of "XCON", which is used to identify the centralized conferencing (XCON) server for a particular domain. The Application Protocol tag "CCMP", defined in Section 12.4.2, is used to identify an XCON server that understands CCMP. The NAPTR records in the following example (Figure 29) demonstrate the use of the Application Service and Application Protocol tags. Iterative NAPTR resolution is used to delegate responsibility for the conferencing service from "zonea.example.com." and "zoneb.example.com." to "outsource.example.com.".
zonea.example.com. ;; order pref flags IN NAPTR 100 10 "" "XCON-CCMP" ( ; service "" ; regex outsource.example.com. ; replacement ) zoneb.example.com. ;; order pref flags IN NAPTR 100 10 "" "XCON-CCMP" ( ; service "" ; regex outsource.example.com. ; replacement ) outsource.example.com. ;; order pref flags IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service "!*.!https://confs.example.com/!" ; regex . ; replacement ) Figure 29: Sample XCON-CCMP Service NAPTR Records Details for the "XCON" Application Service tag and the "CCMP" Application Protocol tag are included in Section 12.4.8. Managing Notifications
As per [RFC5239], CCMP is one of the following four protocols, which have been formally identified within the XCON framework: Conference Control Protocol: mediates between conference and media control client (conferencing client) and conference server. This document describes such a protocol. Binary floor Control Protocol: operates between the floor control client and the floor control server. An example of such a protocol is the Binary Floor Control Protocol (BFCP), specified in [RFC4582]. Call Signaling Protocol: operates between the Call Signaling Client and the focus. Examples of call signaling protocols include SIP, H.323 and IAX. Such protocols are capable of negotiating a conferencing session.
Notification Protocol:
operates between the Notification Client and the XCON Notification
Service. This specification does not define a new notification
protocol. For clients that use SIP as the call signaling
protocol, the XCON event package [RFC6502] MUST be used by the
client for notifications of changes in the conference data as
described below.
The protocol specified in this document is a proactive one and is
used by a conferencing client to send requests to a conference server
in order to retrieve information about the conference objects stored
by the server and to possibly manipulate them. However, a complete
conferencing solution is not prohibited from providing clients with a
means for receiving asynchronous updates about the status of the
objects available at the server. The notification protocol, while
conceptually independent of all the mentioned companion protocols,
can nonetheless be chosen in a way that is consistent with the
overall protocol architecture characterizing a specific deployment,
as discussed in the following.
When the conferencing control client uses SIP [RFC3261] as the
signaling protocol to participate in the conference, SIP event
notification can be used. In such a case, the conferencing control
client MUST implement the conference event package for XCON
[RFC6502]. This is the default mechanism for conferencing clients as
is SIP for signaling per the XCON framework [RFC5239].
In the case where the interface to the conference server is entirely
web based, there is a common mechanism for web-based systems that
could be used -- a "call back". With this mechanism, the
conferencing client provides the conference server with an HTTP URL
that is invoked when a change occurs. This is a common
implementation mechanism for e-commerce. This works well in the
scenarios whereby the conferencing client is a web server that
provides the graphical HTML user interface and uses CCMP as the back-
end interface to the conference server. This model can coexist with
the SIP event notification model. PC-based clients behind NATs could
provide a SIP event URI, whereas web-based clients using CCMP in the
back end would probably find the HTTP call back approach much easier.
The details of this approach are out of scope for CCMP; thus, we
expect a future specification will document this solution.
9. HTTP Transport
This section describes the use of HTTP [RFC2616] and HTTP over TLS
[RFC2818] as transport mechanisms for CCMP, which a conforming
conference server and conferencing client MUST support.
Although CCMP uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a conferencing server might not be a fully compliant HTTP server. It is intended that a conference server can easily be built using an HTTP server with extensibility mechanisms, and that a conferencing client can trivially use existing HTTP libraries. This subset of requirements helps implementers avoid ambiguity with the many options the full HTTP protocol offers. Support of HTTP authentication [RFC2617] and cookies [RFC6265] is OPTIONAL for a conferencing client that conforms to this specification. These mechanisms are unnecessary because CCMP requests carry their own authentication information (in the "subject" field; see Section 5.1). A conferencing client SHOULD include support for HTTP proxy authentication. A CCMP request is carried in the body of an HTTP POST request. The conferencing client MUST include a Host header in the request. The MIME type of CCMP request and response bodies is "application/ ccmp+xml". The conference server and conferencing client MUST provide this value in the HTTP Content-Type and Accept header fields. If the conference server does not receive the appropriate Content- Type and Accept header fields, the conference server SHOULD fail the request, returning a 406 (Not Acceptable) response. CCMP responses SHOULD include a Content-Length header. Conferencing clients MUST NOT use the Expect header or the Range header in CCMP requests. The conference server MAY return 501 (Not Implemented) errors if either of these HTTP features are used. In the case that the conference server receives a request from the conferencing client containing an If-* (conditional) header, the conference server SHOULD return a 412 (precondition failed) response. The POST method is the only method REQUIRED for CCMP. If a conference server chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a conferencing client only uses a POST method, the GET or HEAD MUST be either a URL that was found outside its normal context (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody is testing or debugging a system. The conference server could provide information in the CCMP response indicating that the URL corresponds to a conference server and only responds to CCMP POST requests or the conference server could instead try to avoid any leak of information by returning a very generic HTTP error message such as 405 (Method Not Allowed).
The conference server populates the HTTP headers of responses so that they are consistent with the contents of the message. In particular, the CacheControl header SHOULD be set to disable caching of any conference information by HTTP intermediaries. Otherwise, there is the risk of stale information and/or the unauthorized disclosure of the information. The HTTP status code MUST indicate a 2xx series response for all CCMP Response and Error messages. The conference server MAY redirect a CCMP request. A conference server MUST NOT include CCMP responses in a 3xx response. A conferencing client MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the conferencing client MUST observe the delay indicated by the Retry-After header. The conferencing client MUST authenticate the server that returns the redirect response before following the redirect. A conferencing client SHOULD authenticate the conference server indicated in a redirect. The conference server SHOULD support persistent connections and request pipelining. If pipelining is not supported, the conference server MUST NOT allow persistent connections. The conference server MUST support termination of a response by the closing of a connection. Implementations of CCMP that implement HTTP transport MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the conferencing client and the conference server. The conferencing client MUST implement the server authentication method described in HTTPS [RFC2818]. The device uses the URI obtained during conference server discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the conferencing client SHOULD fail a request if server authentication fails.
(page 82 continued on part 4)
