summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6504.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6504.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6504.txt')
-rw-r--r--doc/rfc/rfc6504.txt4371
1 files changed, 4371 insertions, 0 deletions
diff --git a/doc/rfc/rfc6504.txt b/doc/rfc/rfc6504.txt
new file mode 100644
index 0000000..03b5c72
--- /dev/null
+++ b/doc/rfc/rfc6504.txt
@@ -0,0 +1,4371 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Barnes
+Request for Comments: 6504 Polycom
+Category: Informational L. Miniero
+ISSN: 2070-1721 Meetecho
+ R. Presta
+ S P. Romano
+ University of Napoli
+ March 2012
+
+
+ Centralized Conferencing Manipulation Protocol (CCMP)
+ Call Flow Examples
+
+Abstract
+
+ This document provides detailed call flows for the scenarios
+ documented in the Framework for Centralized Conferencing (XCON) (RFC
+ 5239) and in the XCON scenarios (RFC 4597). The call flows document
+ the use of the interface between a conference control client and a
+ conference control server using the Centralized Conferencing
+ Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide
+ detailed examples for reference by both protocol researchers and
+ developers.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6504.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 1]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Overview ........................................................4
+ 4. Working with CCMP ...............................................4
+ 4.1. CCMP and the Data Model ....................................5
+ 4.2. Using HTTP/TLS as a Transport ..............................6
+ 4.3. Conference Notifications ..................................10
+ 5. Conference Creation ............................................11
+ 5.1. Basic Conference Creation .................................12
+ 5.2. Conference Creation Using Blueprints ......................16
+ 5.3. Conference Creation Using User-Provided Conference
+ Information ...............................................23
+ 5.4. Cloning an Existing Conference ............................28
+ 6. Conference Users Scenarios and Examples ........................31
+ 6.1. Adding a Party ............................................32
+ 6.2. Muting a Party ............................................35
+ 6.3. Conference Announcements and Recordings ...................38
+ 6.4. Monitoring for DTMF .......................................41
+ 6.5. Entering a Password-Protected Conference ..................42
+ 7. Sidebars Scenarios and Examples ................................44
+ 7.1. Internal Sidebar ..........................................45
+ 7.2. External Sidebar ..........................................54
+ 7.3. Private Messages ..........................................60
+ 7.4. Observing and Coaching ....................................64
+ 8. Removing Participants and Deleting Conferences .................71
+ 8.1. Removing a Party ..........................................71
+ 8.2. Deleting a Conference .....................................74
+ 9. Security Considerations ........................................75
+ 10. Acknowledgements ..............................................76
+ 11. References ....................................................76
+ 11.1. Normative References .....................................76
+ 11.2. Informative References ...................................76
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 2]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+1. Introduction
+
+ This document provides detailed call flows for the scenarios
+ documented in the Framework for Centralized Conferencing (XCON)
+ [RFC5239] and in the XCON scenarios [RFC4597]. The XCON scenarios
+ describe a broad range of use cases taking advantage of the advanced
+ conferencing capabilities provided by a system realization of the
+ XCON framework. The call flows document the use of the interface
+ between a conference control client and a conference control server
+ using the Centralized Conferencing Manipulation Protocol (CCMP)
+ [RFC6503].
+
+ Due to the broad range of functionality provided by the XCON
+ framework and the flexibility of the CCMP messaging, these call flows
+ should not be considered inclusive of all the functionality that can
+ provided by the XCON framework and protocol implementations. These
+ flows represent a sample to provide an overview of the feature-rich
+ capabilities of the XCON framework and CCMP messaging for protocol
+ developers, software developers, and researchers.
+
+2. Terminology
+
+ This document uses the same terminology as found in the Architectural
+ Framework for Media Server Control [RFC5567] and in the Media Control
+ Channel Framework Call Flow Examples [CALL-FLOWS], with the following
+ terms and abbreviations used in the call flows. Also, note that the
+ term "call flows" is used in a very generic sense in this document
+ since the media is not limited to voice. The calls supported by the
+ XCON framework and CCMP can consist of media such as text, voice, and
+ video, including multiple media types in a single active conference.
+
+ Conference and Media Control Client (CMCC): as defined in the XCON
+ framework. In the flows in this document, the CMCC is logically
+ equivalent to the use of a User Agent Client (UAC) as the client
+ notation in the media control call flows [CALL-FLOWS]. A CMCC
+ differs from a generic media client in being an XCON-aware entity,
+ thus, also being able to issue CCMP requests.
+
+ Conference Server (ConfS): In this document, the term "conference
+ server" is used interchangeably with the term "Application Server
+ (AS)" as used in the media control architectural framework
+ [RFC5567]. A conference server is intended to be able to act as a
+ conference control server, as defined in the XCON framework, i.e.,
+ it is able to handle CCMP requests and issue CCMP responses.
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 3]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ Media Server (MS): as defined in the media control architectural
+ framework [RFC5567].
+
+3. Overview
+
+ This document provides a sampling of detailed call flows that can be
+ implemented based on a system realization of the XCON framework
+ [RFC5239] and implementation of CCMP [RFC6503]. This is intended to
+ be a simple guide for the use of the conference control protocol
+ between the conference server and the conference control client. The
+ objective is to provide an informational base reference for protocol
+ developers, software developers, and researchers.
+
+ This document focuses on the interaction between the conference and
+ media control client and the conferencing system, specifically the
+ conference server. The scenarios are based on those described in the
+ XCON framework, many of which are based on the advanced conferencing
+ capabilities described in the XCON scenarios. Additional scenarios
+ have been added to provide examples of other real-life scenarios that
+ are anticipated to be supported by the framework. With the exception
+ of an initial example with media control messaging, the examples do
+ not include the details for the media control [RFC6505], call
+ signaling, or Binary Floor Control Protocols (BFCPs) [RFC4582]. This
+ document references the scenarios in the media control call flows
+ [CALL-FLOWS], SIP call control conferencing, [RFC4579], and BFCP
+ documents.
+
+ The rest of this document is organized as follows. Section 4
+ presents an overview on CCMP, together with some implementation-
+ related details and related matters like HTTPS transport and
+ notifications. Section 5 presents the reader with examples showing
+ the different approaches CCMP provides to create a new conference.
+ Section 6 more generally addresses the different user-related
+ manipulations that can be achieved by means of CCMP, by presenting a
+ number of interesting scenarios. Section 7 addresses several
+ scenarios that may involve the use of sidebars. Section 8 shows how
+ CCMP can be used to remove conferences and users from the system.
+ Finally, Section 9 provides a few details on the security
+ considerations when it comes to implementing CCMP.
+
+4. Working with CCMP
+
+ This section provides a brief introduction as to how the Centralized
+ Conferencing Manipulation Protocol (CCMP) [RFC6503] works and how it
+ can be transported across a network. A typical CCMP interaction
+ focusing on relevant aspects of the client-server communication is
+
+
+
+
+
+Barnes, et al. Informational [Page 4]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ described. Please note that this section assumes the reader has read
+ and understood the CCMP document. This section is intended to help
+ the reader understand the actual protocol interactions.
+
+ First, a description of the protocol itself is provided Section 4.1,
+ including some implementation considerations. In Section 4.2, an
+ effective CCMP interaction is presented by exploiting HTTPS as a
+ transport. Finally, notifications are described in Section 4.3.
+
+ The document then presents and describes some actual flows in detail
+ in the sections to follow.
+
+4.1. CCMP and the Data Model
+
+ CCMP is an protocol based on XML [W3C.REC-xml-20081126]. It has been
+ designed as a request/response protocol. It is completely stateless,
+ which means implementations can safely handle transactions
+ independently from each other.
+
+ The protocol allows for the manipulation of conference objects and
+ related users. This manipulation allows a conference and media
+ control client (briefly CMCC in all the following sections) to
+ create, update, and remove basically everything that is related to
+ the objects handled by a conferencing system. This is reflected in
+ the allowed operations (retrieve, create, update, delete) and the
+ specified request types (ranging from the manipulation of blueprints
+ and conferences to users and sidebars). For instance, CCMP provides
+ ways to:
+
+ o retrieve the list of registered and/or active conferences in the
+ system;
+
+ o create new conferences by exploiting several different approaches;
+
+ o add/remove users to/from a conference;
+
+ o update a conference with respect to all of its aspects;
+
+ and so on.
+
+ While CCMP acts as the means to manipulate conference objects, CCMP
+ does not define these conference objects. A separate document
+ specifies how a conference object and all its components have to be
+ constructed (Conference Information Data Model for Centralized
+ Conferencing (XCON) [RFC6501]). CCMP, depending upon the request
+ type and the related operation, carries pieces of conference objects
+ (or any object as a whole) according to the aforementioned
+
+
+
+
+Barnes, et al. Informational [Page 5]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ specification. This means that any implementation aiming at being
+ compliant with CCMP has to make sure that the transported objects are
+ completely compliant with the data model specification and coherent
+ with the constraints defined therein. To make this clearer, there
+ are elements that are mandatory in a conference object: issuing a
+ syntactically correct CCMP request that carries a wrong conference
+ object is doomed to result in a failure. For this reason, it is
+ suggested that the interested implementers take special care in
+ carefully checking the data model handlers as well in order to avoid
+ potential mistakes.
+
+ However, there are cases when a mandatory element in the data model
+ cannot be assigned in a conference object by a CCMP user. For
+ example, a CMCC may be requesting the direct creation of a new
+ conference; in this case, a conference object assumes an 'entity'
+ attribute uniquely identifying the conference to be in place. Thus,
+ the CMCC has no way to know a priori what the entity will be, since
+ it is generated by the ConfS after the request. For scenarios like
+ this one, the CCMP specification describes the use of a dedicated
+ placeholder wildcard (i.e., "AUTO_GENERATE_X", where X is an integer)
+ to make the conference object compliant with the data model: the
+ wildcard would then be replaced by the ConfS with the right value.
+
+4.2. Using HTTP/TLS as a Transport
+
+ CCMP requires that implementations support HTTP/TLS as the transport
+ mechanism. Per CCMP, a CMCC sends a request as part of an HTTPS POST
+ message, and the ConfS would reply with a 200 OK HTTPS response. In
+ both cases, the HTTPS messages carry the CCMP messages as payload,
+ which is reflected in the Content-Type header
+ ("application/ccmp+xml"). Figure 1 presents a ladder diagram of such
+ an interaction, which is followed by a dump of the exchanged HTTPS
+ messages for further analysis. The examples in the remainder of this
+ document show only the CCMP interactions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 6]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ CMCC ConfS
+ | |
+ | 1. HTTPS POST (CCMP request) |
+ |--------------------------------------------->|
+ | |
+ | |--+ Parse request,
+ | | | update object
+ | |<-+ and reply
+ | |
+ | 2. 200 OK (CCMP response) |
+ |<---------------------------------------------|
+ | |
+ |--+ Parse response and |
+ | | update local copy |
+ |<-+ of conference object |
+ | |
+ ' '
+ ' '
+
+ Figure 1: CCMP on HTTPS
+
+ Per the protocol dump in the following lines, the CMCC has issued a
+ CCMP request (a blueprintRequest message asking for a blueprint
+ retrieval, i.e., with the <operation> element set to "retrieve" )
+ towards the ConfS. The request has been carried as payload of an
+ HTTPS POST (message 1.) towards a previously known location. The
+ mandatory Host header has been specified, and the Content-Type header
+ has been correctly set as well ("application/ccmp+xml").
+
+ The ConfS, in turn, has handled the request and replied accordingly.
+ The response (a blueprintResponse message with a <response-code> set
+ to a successful value, "200") has been carried as payload of a 200 OK
+ HTTPS response (message 2.). As before, the Content-Type header has
+ been correctly set ("application/ccmp+xml").
+
+1. CMCC -> ConfS (HTTPS POST, CCMP request)
+------------------------------------------
+ POST /Xcon/Ccmp HTTP/1.1
+ Content-Length: 657
+ Content-Type: application/ccmp+xml
+ Host: example.com:443
+ Connection: Keep-Alive
+ User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 7]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <?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. CMCC <- ConfS (200 to POST, CCMP response)
+---------------------------------------------
+ HTTP/1.1 200 OK
+ X-Powered-By: Servlet/2.5
+ Server: Sun GlassFish Communications Server 1.5
+ Content-Type: application/ccmp+xml;charset=ISO-8859-1
+ Content-Length: 1652
+ Date: Thu, 04 Feb 2010 14:47:56 GMT
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-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:maximum-user-count>2</info:maximum-user-count>
+ <info:available-media>
+ <info:entry label="audioLabel">
+ <info:type>audio</info:type>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:users>
+ <xcon:join-handling>allow</xcon:join-handling>
+
+
+
+Barnes, et al. Informational [Page 8]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </info:users>
+ <xcon:floor-information>
+ <xcon:floor-request-handling>confirm
+ </xcon:floor-request-handling>
+ <xcon:conference-floor-policy>
+ <xcon:floor id="audioLabel"></xcon:floor>
+ </xcon:conference-floor-policy>
+ </xcon:floor-information>
+ </blueprintInfo>
+ </ccmp:blueprintResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+
+ For completeness, the following provides some details of the CCMP
+ interaction. Despite the simplicity of the request, this flow
+ provides some relevant information on how CCMP messages are built.
+ Specifically, both the CCMP request and the CCMP response share a
+ subset of the message:
+
+ o <confUserID>: this element, provided by the CMCC, refers to the
+ requester by means of his XCON-USERID; except in a few scenarios
+ (presented in the following sections), this element must always
+ contain a valid value;
+
+ o <confObjID>: this element refers to the target conference object,
+ according to the request in place;
+
+ o <operation>: this element specifies the operation the CMCC wants
+ to perform, according to the specific request type.
+
+ Besides those elements, the CMCC (let's say Alice, whose XCON-USERID
+ is "xcon-userid:Alice@example.com") has also provided an additional
+ element, <blueprintRequest>. The name of that element varies
+ according to the request type in which the CMCC is interested. In
+ this specific scenario, the CMCC was interested in acquiring details
+ concerning a specific blueprint (identified by its XCON-URI
+ "xcon:AudioRoom@example.com", as reflected in the provided
+ <confObjID> target element), and so the request consisted in an empty
+ <blueprintRequest> element. It will be clearer in the following
+ sections that different request types may require different elements
+ and, as a consequence, different content.
+
+ Considering the request was a blueprintRequest message, the ConfS has
+ replied with a blueprintResponse message containing a
+ <blueprintResponse> element. This element includes a complete dump
+ of the conference object (compliant with the data model) describing
+ the requested blueprint.
+
+
+
+Barnes, et al. Informational [Page 9]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ Without providing additional details of this interaction, it is worth
+ noting that this was the example of the simplest CCMP communication
+ that could take place between a CMCC and a ConfS, a blueprint
+ request: this scenario will be described in more detail in
+ Section 5.2.
+
+4.3. Conference Notifications
+
+ The XCON framework [RFC5239] identifies several different possible
+ protocol interactions between a conference server and a conferencing
+ client. One of those interactions is generically called
+ "notification protocol" providing a mechanism for all clients
+ interested in being informed by the server whenever something
+ relevant happens in a conference. When SIP is used as the call
+ signaling protocol in a CCMP implementation, the XCON event package
+ [RFC6502], which extends the SIP event package for conference state
+ [RFC4575] must be supported. A SIP client uses the SIP SUBSCRIBE
+ message for the XCON event package to subscribe to notifications
+ related to a specific conference. A SIP client would receive
+ notifications describing all the changes to the document via a SIP
+ NOTIFY message. An example ladder diagram is presented in Figure 2;
+ in this figure, we assume a CMCC has updated a conference object, and
+ a previously subscribed SIP client is notified of the update.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 10]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ CMCC ConfS UAC
+ | | |
+ | | 1. SIP SUBSCRIBE |
+ | |<--------------------------|
+ | Handle +--| |
+ | new | | |
+ | subscription +->| 2. SIP 200 OK |
+ | |-------------------------->|
+ | | |
+ ' ' '
+ ' ' '
+ | | |
+ | 3. CCMP (add user) | |
+ |---------------------->| |
+ | |--+ Add user |
+ | | | to conf. |
+ | |<-+ object |
+ | 4. CCMP (success) | |
+ |<----------------------| |
+ | | 5. SIP NOTIFY (changes) |
+ | |-------------------------->|
+ | | 6. SIP 200 OK |
+ | |<--------------------------|
+ | | |
+ ' ' '
+ ' ' '
+
+ Figure 2: XCON Event Package: SIP Notifications
+
+ The detailed flows in this document generically present a
+ notification, when appropriate, but do not include the SIP messaging
+ details.
+
+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
+
+
+
+
+
+Barnes, et al. Informational [Page 11]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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.
+
+
+
+
+
+Barnes, et al. Informational [Page 12]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 13]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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
+
+
+
+
+Barnes, et al. Informational [Page 14]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+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>
+
+
+
+
+Barnes, et al. Informational [Page 15]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </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.
+
+
+
+
+
+Barnes, et al. Informational [Page 16]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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) |
+ |<------------------------------|
+ | |
+
+
+
+Barnes, et al. Informational [Page 17]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ | |
+ | |
+ ' '
+ ' '
+
+ 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.
+
+
+
+
+Barnes, et al. Informational [Page 18]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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>
+
+
+
+Barnes, et al. Informational [Page 19]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <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>
+
+
+
+Barnes, et al. Informational [Page 20]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <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>
+
+
+
+
+
+Barnes, et al. Informational [Page 21]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+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>
+
+
+
+Barnes, et al. Informational [Page 22]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </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
+
+
+
+Barnes, et al. Informational [Page 23]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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").
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 24]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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
+
+
+
+Barnes, et al. Informational [Page 25]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ | | | |
+ | |<<###################>>|
+ | | 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
+
+
+
+Barnes, et al. Informational [Page 26]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </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>
+
+
+
+Barnes, et al. Informational [Page 27]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </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
+
+
+
+
+Barnes, et al. Informational [Page 28]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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
+
+
+
+Barnes, et al. Informational [Page 29]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 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>
+
+
+
+Barnes, et al. Informational [Page 30]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <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
+
+6. Conference Users Scenarios and Examples
+
+ Section 5 showed examples describing the several different ways a
+ conference might be created using CCMP. This section focuses on
+ user-related scenarios, i.e., typical scenarios that may occur during
+
+
+
+Barnes, et al. Informational [Page 31]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ the lifetime of a conference, like adding new users and handling
+ their media. The following scenarios are based on those documented
+ in the XCON framework. The examples assume that a conference has
+ already been correctly established, with media, if applicable, per
+ one of the examples in Section 5.
+
+6.1. Adding a Party
+
+ In this example, Alice wants to add Bob to an established conference.
+ In the following example we assume Bob is a new user of the system,
+ which means Alice also needs to provide some details about him. In
+ fact, the case of Bob already present as a user in the conferencing
+ system is much easier to address, and will be discussed later.
+
+ Alice Bob
+ CMCC1 CMCC2 CMCCx ConfS
+ | | | |
+ |(1) userRequest(confUserID,| |
+ | confObjID, create, | |
+ | userInfo) | | |
+ |-------------------------------------->|
+ | | | |
+ | | (a) Create +---|
+ | | | Bob | |
+ | | | as a | |
+ | | | user +-->|
+ | | | |
+ |(2) userResponse(confUserID, confObjID |
+ | create, 200, success, userInfo) |
+ |<--------------------------------------|
+ | | | |
+ | | | (b) Focus |
+ | | | sets up |
+ | | | signaling |
+ | | | to Bob |
+ | |<----------------------|
+ | | | |
+ | | | (c) Notify|
+ | | | ("Bob just|
+ | | | joined") |
+ | | |<----------|
+ | | | |
+ ' ' ' '
+ ' ' ' '
+ ' ' ' '
+
+ Figure 11: Client Manipulation of Conference - Add a Party
+
+
+
+
+Barnes, et al. Informational [Page 32]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 1. Alice sends a userRequest message with an operation of "create"
+ to add Bob to the specific conference as identified by the XCON-
+ URI in the <confObjID>. The "create" <operation> also makes sure
+ that Bob is created as a user in the whole conferencing system.
+ This is done by adding in the request a <userInfo> element
+ describing Bob as a user. This is needed in order to let the
+ conferencing system be aware of Bob's characteristics. In case
+ Bob was already a registered user, Alice would just have
+ referenced him through his XCON-USERID in the 'entity' attribute
+ of the <userInfo> field, without providing additional data. In
+ fact, that data (including, for instance, Bob's SIP-URI to be
+ used subsequently for dial-out) would be obtained by referencing
+ the extant registration. The conference server ensures that
+ Alice has the appropriate authority based on the policies
+ associated with that specific conference object to perform the
+ operation. As mentioned before, a new XCON-USERID is created for
+ Bob, and the <userInfo> is used to update the conference object
+ accordingly. As already seen in Section 5.3, a placeholder
+ wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
+ messages below) is used for the 'entity' attribute of the
+ <userInfo> element, to be replaced by the actual XCON-USERID
+ later;
+
+ 2. Bob is successfully added to the conference object, and an XCON-
+ USERID is allocated for him ("xcon-userid:Bob@example.com"); this
+ identifier is reported in the response as the value of the
+ 'entity' attribute of the returned <userInfo>;
+
+ 3. In the presented example, the call signaling to add Bob to the
+ conference is instigated through the focus as well. As noted
+ previously, this is implementation specific. In fact, a
+ conferencing system may accomplish different actions after the
+ user creation, just as it may do nothing at all. Among the
+ possible actions, for instance, Bob may be added as a <target>
+ element to the <allowed-users-list> element, whose joining
+ 'method' may be either "dial-in" or "dial-out". Besides, out-of-
+ band notification mechanisms may be involved as well, e.g., to
+ notify Bob via mail of the new conference, including details as
+ the date, password, expected participants, and so on (see
+ Section 4.3).
+
+ Once Bob has been successfully added to the specified conference,
+ per updates to the state, and depending upon the policies, other
+ participants (including Bob himself) may be notified of the
+ addition of Bob to the conference via the conference notification
+ service in use.
+
+
+
+
+
+Barnes, et al. Informational [Page 33]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+1. userRequest/create message (Alice adds Bob)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:userRequest>
+ <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
+ <info:display-text>Bob</info:display-text>
+ <info:associated-aors>
+ <info:entry>
+ <info:uri>mailto:bob.depippis@example.com</info:uri>
+ <info:display-text>Bob's email</info:display-text>
+ </info:entry>
+ </info:associated-aors>
+ <info:endpoint entity="sip:bob83@example.com">
+ <info:display-text>Bob's laptop</info:display-text>
+ </info:endpoint>
+ </userInfo>
+ </ccmp:userRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+2. userResponse/create message (a new XCON-USERID is
+ created for Bob and he is added to the conference)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>10</version>
+ <ccmp:userResponse>
+ <userInfo entity="xcon-userid:Bob@example.com">
+ <info:display-text>Bob</info:display-text>
+ <info:associated-aors>
+ <info:entry>
+
+
+
+Barnes, et al. Informational [Page 34]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:uri>mailto:bob.depippis@example.com</info:uri>
+ <info:display-text>Bob's email</info:display-text>
+ </info:entry>
+ </info:associated-aors>
+ <info:endpoint entity="sip:bob83@example.com">
+ <info:display-text>Bob's laptop</info:display-text>
+ </info:endpoint>
+ </userInfo>
+ </ccmp:userResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 12: Add Party Message Details
+
+6.2. Muting a Party
+
+ This section provides an example of the muting of a party in an
+ active conference. We assume that the user to mute has already been
+ added to the conference. The document only addresses muting and not
+ unmuting, since the latter would involve an almost identical CCMP
+ message flow anyway. However, if any external floor control is
+ involved, whether a particular conferencing client can actually mute/
+ unmute itself must be considered by the conferencing system.
+
+ Please notice that interaction between CCMP and floor control
+ should be carefully considered. In fact, handling CCMP- and BFCP-
+ based media control has to be considered as multiple layers: that
+ is, a participant may have the BFCP floor granted, but be muted by
+ means of CCMP. If so, he would still be muted in the conference,
+ and would only be unmuted if both the protocols allowed for this.
+
+ Figure 13 provides an example of one client, Alice, impacting the
+ media state of another client, Bob. This example assumes an
+ established conference. In this example, Alice, who is the moderator
+ of the conference, wants to mute Bob on a medium-sized multi-party
+ conference, as his device is not muted (and he's obviously not
+ listening to the call) and background noise in his office environment
+ is disruptive to the conference. BFCP floor control is assumed not
+ to be involved.
+
+ Muting can be accomplished using the <mute> control element
+ associated with the target user's audio, in which case the conference
+ server must update the settings associated with the user's media
+ streams. Muting/unmuting can also be accomplished by directly
+ modifying the settings related to the target user's media streams,
+ which is the approach shown in this example. Specifically, Bob's
+ <userInfo> is updated by modifying the <endpoint> element in the
+
+
+
+
+Barnes, et al. Informational [Page 35]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <media> part related to audio information, identified by the 'id'
+ attribute. The modification consists in setting the audio <status>
+ to "recvonly", in case of muting.
+
+ Alice Bob
+ CMCC1 CMCC2 CMCCx ConfS MS
+ | | | | |
+ |(1) userRequest(subject, | | |
+ | confUserID,confObjID, | | |
+ | update,userInfo) | | |
+ | | | | |
+ |--------------------------------------->| |
+ | | | | Mute Bob |
+ | | | |----------------->|
+ | | | | 200 OK |
+ | | | |<-----------------|
+ | | | | |
+ | |<====== XXX Bob excluded from mix XXX ====>|
+ | | | | |
+ | | (a) Update +---| |
+ | | Bob in | | |
+ | | data model | | |
+ | | (muted) +-->| |
+ | | | | |
+ | (2)userResponse(confUserID,confObjID, | |
+ | update,200,success,version) | |
+ |<---------------------------------------| |
+ | | | | |
+ | | | (b) Notify | |
+ | | | ("Bob is | |
+ | | | muted") | |
+ | | |<-----------| |
+ | | | | |
+ ' ' ' ' '
+ ' ' ' ' '
+ ' ' ' ' '
+
+ Figure 13: Client Manipulation of Conference - Mute a Party
+
+ 1. Alice sends a userRequest message with an "update" <operation>
+ and the <userInfo> with the <status> field in the <media> element
+ for Bob's <endpoint> set to "revconly". In order to authenticate
+ herself, Alice provides in the <subject> request parameter her
+ registration credentials (i.e., username and password). The
+ <subject> parameter is an optional one: its use can be systematic
+ whenever the conference server envisages to authenticate each
+
+
+
+
+
+Barnes, et al. Informational [Page 36]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ requester. In such cases, if the client does not provide the
+ required authentication information, the conferencing server
+ answers with a CCMP "authenticationRequired" <response-code>,
+ indicating that the request cannot be processed without including
+ the proper <subject> parameter. The conference server ensures
+ that Alice has the appropriate authority based on the policies
+ associated with that specific conference object to perform the
+ operation. It recognizes that Alice is allowed to request the
+ specified modification, since she is moderator of the target
+ conference, and updates the <userInfo> in the conference object
+ reflecting that Bob's media is not to be mixed with the
+ conference media. If the conference server relies on a remote
+ media server for its multimedia functionality, it subsequently
+ changes Bob's media profile accordingly by means of the related
+ protocol interaction with the MS. An example describing a
+ possible way of dealing with such a situation using the media
+ server control architecture [RFC5567] is described in Figure 31,
+ "Simple Bridging: Framework Transactions (2)", in [CALL-FLOWS].
+
+ 2. A userResponse message with a "200" <response-code> ("success")
+ is then sent to Alice. Depending upon the policies, the
+ conference server may notify other participants (including Bob)
+ of this update via any conference notification service that may
+ be in use.
+
+ 1. userRequest/update message (Alice mutes Bob)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-request-message-type">
+ <subject>
+ <username>Alice83</username>
+ <conference-password>13011983</conference-password>
+ </subject>
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>update</operation>
+ <ccmp:userRequest>
+ <userInfo entity="xcon-userid:Bob@example.com">
+ <info:endpoint entity="sip:bob83@example.com">
+ <info:media id="1">
+ <info:label>123</info:label>
+ <info:status>recvonly</info:status>
+ </info:media>
+ </info:endpoint>
+
+
+
+Barnes, et al. Informational [Page 37]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </userInfo>
+ </ccmp:userRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+2. userResponse/update message (Bob has been muted)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>update</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>7</version>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 14: Mute Message Details
+
+6.3. Conference Announcements and Recordings
+
+ This section deals with features that are typically required in a
+ conferencing system, such as public announcements (e.g., to notify
+ vocally that a new user joined a conference) and name recording.
+ While this is not strictly CCMP-related (the CCMP signaling is
+ actually the same as the one seen in Section 6.1), it is an
+ interesting scenario to address to see how several components of an
+ XCON-compliant architecture interact with each other to make it
+ happen.
+
+ In this example, as shown in Figure 15, Alice is joining Bob's
+ conference that requires that she first enter a passcode. After
+ successfully entering the passcode, an announcement prompts Alice to
+ speak her name so it can be recorded. When Alice is added to the
+ active conference, the recording is played back to all the existing
+ participants. A very similar example is presented in Figure 33 of
+ [CALL-FLOWS].
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 38]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ CMCC Alice ConfS MS
+ | | |
+ |(1)userRequest(confObjID, | |
+ | create,userInfo) | |
+ |--------------------------->| |
+ | |--+ Alice is |
+ | | | new in the |
+ | |<-+ system (create |
+ | | confUserID) |
+ | ConfS handles +--| |
+ | SIP signaling | | |
+ | (Alice<->ConfS<->MS) +->| |
+ | | |
+ | |--+ A password is |
+ | | | required for |
+ | |<-+ that conference |
+ | | |
+ | | Request IVR menu (PIN) |
+ | |--------------------------->|
+ | | |
+ |<========= MS gets PIN from Alice through DTMF =========>|
+ | | |
+ | | Provided PIN is... |
+ | |<---------------------------|
+ | Check +--| |
+ | PIN | | |
+ | +->| |
+ | |--+ Alice must |
+ | | | record her |
+ | |<-+ name |
+ | | |
+ | | Request name recording |
+ | |--------------------------->|
+ | | |
+ |<========= MS records Alice's audio RTP (name) =========>|
+ | | |
+ | | Audio recording |
+ | |<---------------------------|
+ | Complete +--| |
+ | creation | | |
+ | of Alice +->| |
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 39]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ | | |
+ | | |
+ | (2)userResponse(confUserID,| |
+ | confObjID,create,200,| |
+ | success,version) | |
+ |<---------------------------| |
+ | | |
+ ' ' '
+
+ Figure 15: Recording and Announcements
+
+ 1. Upon receipt of the userRequest message from Alice to be added to
+ Bob's conference, the conference server determines that a
+ password is required for this specific conference. Thus, an
+ announcement asking Alice to enter the password is sent back.
+ This may be achieved by means of typical IVR functionality. Once
+ Alice enters the password, it is validated against the policies
+ associated with Bob's active conference. The conference server
+ then connects to a server that prompts and records Alice's name.
+ The conference server must also determine whether Alice is
+ already a user of this conferencing system or whether she is a
+ new user. In this case, Alice is a new user for this
+ conferencing system, so a new XCON-USERID is created for Alice.
+ Based upon the contact information provided by Alice, the call
+ signaling to add Alice to the conference is instigated through
+ the focus.
+
+ 2. The conference server sends Alice a userResponse message that
+ includes in the <confUserID> the XCON-USERID assigned by the
+ conferencing system to her. This would allow Alice to later
+ perform operations on the conference (if she were to have the
+ appropriate policies), including registering for event
+ notifications associated with the conference. Once the call
+ signaling indicates that Alice has been successfully added to the
+ specific conference, per updates to the state, and depending upon
+ the policies, other participants (e.g., Bob) are notified of the
+ addition of Alice to the conference via the conference
+ notification service and an announcement is provided to all the
+ participants indicating that Alice has joined the conference.
+
+ 1. userRequest/create message (a new conferencing system client,
+ Alice, enters Bob's conference)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+
+
+
+Barnes, et al. Informational [Page 40]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-request-message-type">
+ <confObjID>xcon:bobConf@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:userRequest>
+ <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
+ <info:associated-aors>
+ <info:entry>
+ <info:uri>
+ mailto:Alice83@example.com
+ </info:uri>
+ <info:display-text>email</info:display-text>
+ </info:entry>
+ </info:associated-aors>
+ <info:endpoint entity="sip:alice_789@example.com"/>
+ </userInfo>
+ </ccmp:userRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. userResponse/create message (Alice provided with a new XCON-USERID
+ and added to the conference)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:bobConf@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>5</version>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 16: Announcement Messaging Details
+
+6.4. Monitoring for DTMF
+
+ Conferencing systems also often need the capability to monitor for
+ dual-tone multi-frequency (DTMF) from each individual participant.
+ This would typically be used to enter the identifier and/or access
+ code for joining a specific conference. This feature is also often
+
+
+
+Barnes, et al. Informational [Page 41]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ exploited to achieve interaction between participants and the
+ conferencing system for non-XCON-aware user agents (e.g., using DTMF
+ tones to get muted/unmuted).
+
+ An example of DTMF monitoring, within the context of the framework
+ elements, is shown in Figure 15. The media control architecture and
+ protocols [RFC5567] can be used by the conference server for all the
+ DTMF interactions. Examples for DTMF interception in conference
+ instances are presented in [CALL-FLOWS].
+
+6.5. Entering a Password-Protected Conference
+
+ Some conferences may require a password to be provided by a user who
+ wants to manipulate the conference objects (e.g., join, update,
+ delete) via CCMP. In this case, a password would be included in the
+ <conference-password> element in the appropriate <conference-uris>
+ entry of the conference data model. Such password must be then
+ included in the <conference-password> field in the CCMP request
+ addressed to that conference.
+
+ In the following example, Alice, a conferencing system client,
+ attempts to join a password-protected conference.
+
+ 1. Alice sends a userRequest message with a "create" <operation> to
+ add herself in the conference with XCON-URI
+ "xcon:8977777@example.com" (written in the <confObjID>
+ parameter). Alice provides her XCON-USERID via the <confUserID>
+ field of the userRequest message and leaves out the <userInfo>
+ one (first-party join). In this first attempt, she doesn't
+ insert any password parameter.
+
+ 2. Upon receipt the userRequest/create message, the conference
+ server detects that the indicated conference is not joinable
+ without providing the appropriate passcode. A userResponse
+ message with a "423" <response-code> ("conference password
+ required") is returned to Alice to indicate that her join has
+ been refused and that she has to resend her request including the
+ appropriate conference password in order to participate.
+
+ 3. After getting the passcode through out-of-band mechanisms, Alice
+ provides it in the proper <conference-password> request field of
+ a new userRequest/create message and sends the updated request
+ back to the server.
+
+ 4. The conference server checks the provided password and then adds
+ Alice to the protected conference. After that, a userResponse
+ message with a "200" <response-code> ("success") is sent to
+ Alice.
+
+
+
+Barnes, et al. Informational [Page 42]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 1. userRequest/create message (Alice tries to enter the conference
+ without providing the password)
+
+ <?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/>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. userResponse/create message ("423", "conference password required")
+
+ <?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>423</response-code>
+ <response-string>conference password required</response-string>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ 3. userRequest/create message (Alice provides the password)
+
+ <?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>
+ <conference-password>8601</conference-password>
+
+
+
+Barnes, et al. Informational [Page 43]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <ccmp:userRequest/>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 4. userResponse/create message
+ (Alice has been added to the conference)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>10</version>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 17: Password-Protected Conference Join Messages Details
+
+7. Sidebars Scenarios and Examples
+
+ While creating conferences and manipulating users and their media are
+ sufficient for many scenarios, there may be cases when more complex
+ management is needed.
+
+ In fact, a feature typically required in conferencing systems is the
+ ability to create sidebars. A sidebar is basically a child
+ conference that usually includes a subset of the participants of the
+ parent conference and a subset of its media as well. Sidebars are
+ typically required whenever some of the participants in a conference
+ want a private discussion, without interfering with the main
+ conference.
+
+ This section deals with some typical scenarios using a sidebar, like
+ whispering, private messaging, and coaching scenarios. The first
+ subsections present some examples of how a generic sidebar can be
+ created, configured, and managed.
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 44]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+7.1. Internal Sidebar
+
+ Figure 18 provides an example of one client, Alice, involved in an
+ active conference with Bob and Carol. Alice wants to create a
+ sidebar to have a side discussion with Bob while still viewing the
+ video associated with the main conference. Alternatively, the audio
+ from the main conference could be maintained at a reduced volume.
+ Alice initiates the sidebar by sending a request to the ConfS to
+ create a conference reservation based upon the active conference
+ object. Alice and Bob would remain on the roster of the main
+ conference, such that other participants could be aware of their
+ participation in the main conference, while an internal-sidebar
+ conference is occurring. Besides, Bob decides that he is not
+ interested in still receiving the conference audio in background (not
+ even at a lower volume as Alice configured) and so modifies the
+ sidebar in order to make that stream inactive for him.
+
+ Alice Bob ConfS
+ | | |
+ |(1) sidebarByValRequest(confUserID, |
+ | confObjID,create) |
+ |--------------------------------------------->|
+ | | |
+ | | (a) Create +---|
+ | | sidebar-by-val | |
+ | | (new conf obj | |
+ | | cloned from +-->|
+ | | confObjID) | Sidebar now has
+ | | | id confObjID*
+ |(2) sidebarByValResponse(confUserID, | (parent mapping
+ | (confObjID*,create,200,success, | conf<->sidebar)
+ | version,sidebarByValInfo) |
+ |<---------------------------------------------|
+ | | |
+ |(3) sidebarByValRequest |
+ | (confUserID, confObjID*, |
+ | update,sidebarByValInfo) |
+ |--------------------------------------------->|
+ | | |
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 45]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ | | (b) Update +---|
+ | | sidebar-by-val | |
+ | | (media, users | |
+ | | etc.) +-->|
+ | | | Sidebar is
+ | | | modified
+ |(4) sidebarByValResponse(confUserID, |
+ | confObjID*, update, |
+ | 200, success, version) |
+ |<---------------------------------------------|
+ | | |
+ | |(5) userRequest |
+ | | (confUserID', |
+ | | confObjID*, |
+ | | update,userInfo)|
+ | |---------------------->|
+ | | |
+ | | (c) Update +---|
+ | | user settings | |
+ | | (Bob's media) | |
+ | | +-->|
+ | | | Sidebar is modified
+ | | | (original audio
+ | | | inactive for Bob)
+ | |(6) userResponse |
+ | | (confUserID', |
+ | | confObjID*, |
+ | | update, 200, |
+ | | success,version) |
+ | |<----------------------|
+ | | |
+ ' ' '
+ ' ' '
+ ' ' '
+
+ Figure 18: Client Creation of a Sidebar Conference
+
+ 1. Upon receipt of CCMP sidebarByValRequest message to create a new
+ sidebar based upon the conference whose XCON-URI is in the
+ <confObjID> received in the request, the conference server uses
+ such XCON-URI to clone a conference reservation for the sidebar.
+ The sidebar reservation is NOT independent of the active main
+ conference (i.e., parent). The conference server also allocates
+ a new XCON-URI ("confObjID*" in Figure 18) for that sidebar to be
+ used for any subsequent protocol requests from any of the members
+ of the conference. The new XCON-URI is returned in the response
+ message <confObjID> parameter.
+
+
+
+
+Barnes, et al. Informational [Page 46]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 2. The relationship information is provided in the
+ sidebarByValResponse message, specifically in the <sidebar-
+ parent> element. A dump of the complete representation of the
+ main/parent conference is provided below as well to show how the
+ cloning process for the creation of the sidebar could take place.
+
+ 3. Upon receipt of the sidebarByValResponse message to reserve the
+ conference, Alice can now create an active conference using that
+ reservation or create additional reservations based upon the
+ existing reservations. In this example, Alice wants only Bob to
+ be involved in the sidebar; thus, she manipulates the membership
+ so that only the two of them appear in the <allowed-users-list>
+ section. Alice also wants both audio and video from the original
+ conference to be available in the sidebar. For what concerns the
+ media belonging to the sidebar itself, Alice wants the audio to
+ be restricted to the participants in the sidebar (that is, Bob
+ and herself). Additionally, Alice manipulates the media values
+ to receive the audio from the main conference at a reduced
+ volume, so that the communication between her and Bob isn't
+ affected. Alice sends a sidebarByValRequest message with an
+ operation of "update" along with the <sidebarByValInfo>
+ containing the aforementioned sidebar modifications.
+
+ 4. Upon receipt of the sidebarByValRequest message to update the
+ sidebar reservation, the conference server ensures that Alice has
+ the appropriate authority based on the policies associated with
+ that specific conference object to perform the operation. The
+ conference server must also validate the updated information in
+ the reservation, ensuring that a member like Bob is already a
+ user of this conference server. Once the data for the conference
+ identified by the <confObjID> is updated, the conference server
+ sends a sidebarByValResponse message to Alice. Depending upon
+ the policies, the initiator of the request (i.e., Alice) and the
+ participants in the sidebar (i.e., Bob) may be notified of his
+ addition to the sidebar via the conference notification service.
+
+ 5. At this point, Bob sends a userRequest message to the conference
+ server with an operation of "update" to completely disable the
+ background audio from the parent conference, since it prevents
+ him from understanding what Alice says in the sidebar.
+
+ 6. Notice that Bob's request only changes the media perspective for
+ Bob. Alice keeps on receiving both the audio from Bob and the
+ background from the parent conference. This request may be
+ relayed by the conference server to the media server handling the
+ mixing, if present. Upon completion of the change, the
+
+
+
+
+
+Barnes, et al. Informational [Page 47]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ conference server sends a userResponse message to Bob. Depending
+ upon the policies, the initiator of the request (i.e., Bob) and
+ the participants in the sidebar (i.e., Alice) may be notified of
+ this change via the conference notification service.
+
+ The following conference object represents the conference in which
+ the sidebar is to be created. It will be used by the conference
+ server to create the new conference object associated with the
+ sidebar.
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <info:conference-info
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ entity="xcon:8977878@example.com">
+ <info:conference-description>
+ <info:display-text>MAIN CONFERENCE</info:display-text>
+ <info:conf-uris>
+ <info:entry>
+ <info:uri>sip:8977878@example.com</info:uri>
+ <info:display-text>conference sip uri</info:display-text>
+ </info:entry>
+ </info:conf-uris>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>main conference audio</info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>main conference video</info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ <xcon:controls>
+ <xcon:video-layout>single-view</xcon:video-layout>
+ </xcon:controls>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>true</info:active>
+ </info:conference-state>
+ <info:users>
+ <info:user entity="xcon-userid:Alice@example.com">
+ <info:display-text>Alice</info:display-text>
+ <info:endpoint entity="sip:Alice@example.com">
+ <info:media id="1">
+
+
+
+Barnes, et al. Informational [Page 48]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:label>123</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ <info:media id="2">
+ <info:label>456</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ <info:user entity="xcon-userid:Bob@example.com">
+ <info:display-text>Bob</info:display-text>
+ <info:endpoint entity="sip:bob83@example.com">
+ <info:media id="1">
+ <info:label>123</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ <info:media id="2">
+ <info:label>456</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ <info:user entity="xcon-userid:Carol@example.com">
+ <info:display-text>Carol</info:display-text>
+ <info:endpoint entity="sip:carol@example.com">
+ <info:media id="1">
+ <info:label>123</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ <info:media id="2">
+ <info:label>456</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ </info:users>
+ </info:conference-info>
+
+ Figure 19: Conference with Alice, Bob, and Carol
+
+ The sidebar creation happens through a cloning of the parent
+ conference. Once the sidebar is created, an update request makes
+ sure that the sidebar is customized as needed. The following
+ protocol dump makes the process clearer.
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 49]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+1. sidebarByValRequest/create message (Alice creates an
+ internal sidebar)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:sidebarByValRequest/>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+2. sidebarByValResponse/create message (sidebar returned)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>1</version>
+ <ccmp:sidebarByValResponse>
+ <sidebarByValInfo entity="xcon:8974545@example.com">
+ <info:conference-description>
+ <info:display-text>
+ SIDEBAR CONFERENCE registered by Alice
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+
+
+
+Barnes, et al. Informational [Page 50]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>false</info:active>
+ </info:conference-state>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Bob@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Carol@example.com"/>
+ </xcon:allowed-users-list>
+ <xcon:sidebar-parent>
+ xcon:8977878@example.com
+ </xcon:sidebar-parent>
+ </info:users>
+ </sidebarByValInfo>
+ </ccmp:sidebarByValResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+3. sidebarByValRequest/update message (Alice updates the
+ created sidebar)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>update</operation>
+ <ccmp:sidebarByValRequest>
+ <sidebarByValInfo entity="xcon:8974545@example.com">
+ <info:conference-description>
+ <info:display-text>
+ private sidebar Alice - Bob
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+
+
+
+Barnes, et al. Informational [Page 51]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>recvonly</info:status>
+ <xcon:controls>
+ <xcon:gain>-60</xcon:gain>
+ </xcon:controls>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>recvonly</info:status>
+ </info:entry>
+ <info:entry label="AUTO_GENERATE_1">
+ <info:display-text>
+ sidebar audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="AUTO_GENERATE_2">
+ <info:display-text>
+ sidebar video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Bob@example.com"/>
+ </xcon:allowed-users-list>
+ </info:users>
+ </sidebarByValInfo>
+ </ccmp:sidebarByValRequest>
+ </ccmpRequest>
+</ccmp:ccmpRequest>
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 52]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+4. sidebarByValResponse/update message (sidebar's
+ updates accepted)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>update</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>2</version>
+ <ccmp:sidebarByValResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+5. userRequest/update message (Bob updates his media)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-request-message-type">
+ <confUserID>xcon-userid:Bob@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>update</operation>
+ <ccmp:userRequest>
+ <userInfo entity="xcon-userid:Bob@example.com">
+ <info:endpoint entity="sip:bob83@example.com">
+ <info:media id="1">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:label>123</info:label>
+ <info:status>inactive</info:status>
+ </info:media>
+ </info:endpoint>
+ </userInfo>
+ </ccmp:userRequest>
+ </ccmpRequest>
+</ccmp:ccmpRequest>
+
+
+
+
+Barnes, et al. Informational [Page 53]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+6. userResponse/update message (Bob's preferences are set)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Bob@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>update</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>3</version>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 20: Internal Sidebar Messaging Details
+
+7.2. External Sidebar
+
+ Figure 21 provides an example of a different approach towards
+ sidebars. In this scenario, one client, Alice, is involved in an
+ active conference with Bob, Carol, David, and Ethel. Alice gets an
+ important text message via a whisper from Bob that a critical
+ customer needs to talk to Alice, Bob, and Ethel. Alice creates a
+ sidebar to have a side discussion with the customer Fred including
+ the participants in the current conference with the exception of
+ Carol and David, who remain in the active conference. The difference
+ from the previous scenario is that Fred is not part of the parent
+ conference: this means that different policies might be involved,
+ considering that Fred may access information coming from the parent
+ conference, in case the sidebar was configured accordingly. For this
+ reason, in this scenario, we assume that Alice disables all the media
+ from the original (parent) conference within the sidebar. This means
+ that, while in the previous example Alice and Bob still heard the
+ audio from the main conference in background, this time no background
+ is made available. Alice initiates the sidebar by sending a request
+ to the conference server to create a conference reservation based
+ upon the active conference object. Alice, Bob and Ethel would remain
+ on the roster of the main conference in a hold state. Whether or not
+ the hold state of these participants is visible to other participants
+ depends upon the individual and local policy. However, providing the
+ hold state allows the participants in the main conference to see that
+ others in the conference are busy. Note, that a separate conference
+ could have been created by Alice to allow Bob and Ethel to talk to
+ Fred. However, creating a sidebar has somewhat of an advantage by
+
+
+
+Barnes, et al. Informational [Page 54]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ allowing the conference to be created using some of the same settings
+ (e.g., role, floor control, etc.) that Bob and Ethel had in the main
+ conference and it would allow for updates such that the media could
+ be updated, for example, to provide audio from the main conference.
+
+ Alice Bob ConfS
+ | | |
+ |(1) sidebarByRefRequest(confUserID, |
+ | confObjID, create) |
+ |--------------------------------------------->|
+ | | |
+ | | (a) Create +---|
+ | | sidebar-by-ref | |
+ | | (new conf obj | |
+ | | cloned from +-->|
+ | | confObjID) | Sidebar now has
+ | | | id confObjID*
+ |(2) sidebarByRefResponse(confUserID, | (parent mapping
+ | confObjID*,create,200,success, | conf<->sidebar)
+ | version,sidebarByRefInfo) |
+ |<---------------------------------------------|
+ | | |
+ |(3) sidebarByRefRequest(confUserID, |
+ | confObjID*,update,sidebarByRefInfo) |
+ |--------------------------------------------->|
+ | | |
+ | | (b) Create +---|
+ | | new user for | |
+ | | Fred | |
+ | | +-->|
+ | | |
+ | | (c) Update +---|
+ | | sidebar-by-ref | |
+ | | (media, users | |
+ | | policy, etc.) +-->|
+ | | | Sidebar is modified:
+ | | | media from the
+ | | | parent conference is
+ | | | not available to
+ |(4) sidebarByRefResponse(confUserID, | anyone
+ | confObjID*, update, |
+ | 200, success, version) |
+ |<---------------------------------------------|
+ | | |
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 55]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ | | Notify (Fred |
+ | | added to |
+ | | sidebar users) |
+ | |<----------------------|
+ | | |
+ ' ' '
+ ' ' '
+ ' ' '
+
+ Figure 21: Client Creation of an External Sidebar
+
+ 1. Upon receipt of the sidebarByRefRequest message to create a new
+ sidebar conference, based upon the active conference specified by
+ <confObjID> in the request, the conference server uses that
+ active conference to clone a conference reservation for the
+ sidebar. The sidebar reservation is NOT independent of the
+ active conference (i.e., parent). The conference server, as
+ before, allocates a new XCON-URI ("confObjID*" in Figure 21) to
+ be used for any subsequent protocol requests toward the sidebar
+ reservation. The mapping between the sidebar XCON-URI and the
+ one associated with the main conference is maintained by the
+ conference server and it is gathered from the <sidebar-parent>
+ element in the sidebar conference object.
+
+ 2. Upon receipt of the sidebarByRefResponse message, which
+ acknowledges the successful creation of the sidebar object, Alice
+ decides that only Bob and Ethel, along with the new participant
+ Fred are to be involved in the sidebar. Thus, she manipulates
+ the membership accordingly. Alice also sets the media in the
+ <conference-info> such that the participants in the sidebar don't
+ receive any media from the main conference. All these settings
+ are provided to the conferencing server by means of a new
+ sidebarByRefRequest message, with an "update" <operation>.
+
+ 3. Alice sends the aforementioned sidebarByRefRequest message to
+ update the information in the reservation and to create an active
+ conference. Upon receipt of the sidebarByRefRequest/update
+ message, the conference server ensures that Alice has the
+ appropriate authority based on the policies associated with that
+ specific conference object to perform the operation. The
+ conference server also validates the updated information in the
+ reservation. Since Fred is a new user for this conferencing
+ system, a conference user identifier (XCON-USERID) is created for
+ Fred. Specifically, Fred is added to the conference by only
+ providing his SIP URI. Based upon the contact information
+ provided for Fred by Alice, the call signaling to add Fred to the
+ conference may be instigated through the focus (e.g., if Fred had
+
+
+
+
+Barnes, et al. Informational [Page 56]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ a "dial-out" value for the 'method' attribute in his <target>
+ field under <allowed-users-list>) at the actual activation of the
+ sidebar.
+
+ 4. The conference server sends a sidebarByRefResponse message and,
+ depending upon the policies, the initiator of the request (i.e.,
+ Alice) and the participants in the sidebar (i.e., Bob and Ethel)
+ may be notified of his addition to the sidebar via the conference
+ notification service.
+
+1. sidebarByRefRequest/create message (Alice creates an
+ external sidebar)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:sidebarByRefRequest/>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+2. sidebarByRefResponse/create message (created
+ sidebar returned)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8971212@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>1</version>
+ <ccmp:sidebarByRefResponse>
+ <sidebarByRefInfo entity="xcon:8971212@example.com">
+ <info:conference-description>
+ <info:display-text>
+ SIDEBAR CONFERENCE registered by Alice
+ </info:display-text>
+
+
+
+Barnes, et al. Informational [Page 57]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>false</info:active>
+ </info:conference-state>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Bob@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Carol@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:David@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:Ethel@example.com"/>
+ </xcon:allowed-users-list>
+ <xcon:sidebar-parent>
+ xcon:8977878@example.com
+ </xcon:sidebar-parent>
+ </info:users>
+ </sidebarByRefInfo>
+ </ccmp:sidebarByRefResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+3. sidebarByRefRequest/update message (Alice updates the sidebar)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+
+
+
+Barnes, et al. Informational [Page 58]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8971212@example.com</confObjID>
+ <operation>update</operation>
+ <ccmp:sidebarByRefRequest>
+ <sidebarByRefInfo entity="xcon:8971212@example.com">
+ <info:conference-description>
+ <info:display-text>
+ sidebar with Alice, Bob, Ethel and Fred
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>inactive</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>inactive</info:status>
+ </info:entry>
+ <info:entry label="AUTO_GENERATE_1">
+ <info:display-text>
+ sidebar audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="AUTO_GENERATE_2">
+ <info:display-text>
+ sidebar video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ <xcon:controls>
+ <xcon:video-layout>
+ single-view
+ </xcon:video-layout>
+ </xcon:controls>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+
+
+
+Barnes, et al. Informational [Page 59]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:conference-state>
+ <info:active>false</info:active>
+ </info:conference-state>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Bob@example.com"/>
+ <xcon:target method="dial-out"
+ uri="sip:fred@example.com"/>
+ </xcon:allowed-users-list>
+ </info:users>
+ </sidebarByRefInfo>
+ </ccmp:sidebarByRefRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+4. sidebarByRefResponse/update message (sidebar updated)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8971212@example.com</confObjID>
+ <operation>update</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>2</version>
+ <ccmp:sidebarByRefResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 22: External Sidebar Messaging Details
+
+7.3. Private Messages
+
+ The case of private messages can be handled as a sidebar with just
+ two participants, similar to the example in Section 7.1. Unlike the
+ previous example, rather than using audio within the sidebar, Alice
+ could just add an additional text-based media stream to the sidebar
+ in order to convey her textual messages to Bob, while still viewing
+ and listening to the main conference.
+
+
+
+
+Barnes, et al. Informational [Page 60]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ In this scenario, Alice requests to the conference server the
+ creation of a private chat room within the main conference context
+ (presented in Figure 19) in which the involved participants are just
+ Bob and herself. This can be achieved through the following CCMP
+ transaction (Figure 23).
+
+ 1. Alice forwards a sidebarByValRequest/create message to the
+ conference server with the main conference XCON-URI in the
+ <confObjID> parameter and the desired sidebar conference object
+ in the <sidebarByValInfo> field. In this way, a sidebar creation
+ using user-provided conference information is requested from the
+ conference server. Please note that, unlike the previous sidebar
+ examples, in this case, a completely new conference object to
+ describe the sidebar is provided: there is no cloning involved,
+ while the <confObjID> still enforces the parent-child
+ relationship between the main conference and the to-be-created
+ sidebar.
+
+ 2. The conference server, after checking Alice's rights and
+ validating the conference object carried in the request, creates
+ the required sidebar-by-val conference and a new XCON-URI for it.
+ Instead of cloning the main conference object, as shown in
+ Sections 7.1 and 7.2, the sidebar is created on the basis of the
+ user-provided conference information. However, the parent
+ relationship between the main conference and the newly created
+ sidebar is still maintained by the conference server (as a
+ consequence of the chosen CCMP request message type -- the
+ sidebarByVal one) and it is reflected by the <sidebar-parent>
+ element in the <sidebarByValInfo> element returned in the
+ sidebarByValResponse message. Please notice that, according to
+ the CCMP specification, the return of the created sidebar data in
+ this kind of "success" response is not mandatory.
+
+1. sidebarByValRequest/create message (Alice creates a private
+ chat room between Bob and herself)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977878@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:sidebarByValRequest>
+ <sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">
+
+
+
+Barnes, et al. Informational [Page 61]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:conference-description>
+ <info:display-text>
+ private textual sidebar alice - bob
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>recvonly</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>recvonly</info:status>
+ </info:entry>
+ <info:entry label="AUTO_GENERATE_2">
+ <info:display-text>
+ sidebar text
+ </info:display-text>
+ <info:type>text</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Bob@example.com"/>
+ </xcon:allowed-users-list>
+ </info:users>
+ </sidebarByValInfo>
+ </ccmp:sidebarByValRequest>
+ </ccmpRequest>
+</ccmp:ccmpRequest>
+
+2. sidebarByValResponse/create message (sidebar returned)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+
+
+
+Barnes, et al. Informational [Page 62]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8974545@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>1</version>
+ <ccmp:sidebarByValResponse>
+ <sidebarByValInfo entity="xcon:8974545@example.com">
+ <info:conference-description>
+ <info:display-text>
+ private textual sidebar alice - bob
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>recvonly</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>recvonly</info:status>
+ </info:entry>
+ <info:entry label="789">
+ <info:display-text>
+ sidebar text
+ </info:display-text>
+ <info:type>text</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ <xcon:sidebar-parent>
+ xcon:8977878@example.com
+ </xcon:sidebar-parent>
+ </info:conference-description>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Alice@example.com"/>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:Bob@example.com"/>
+ </xcon:allowed-users-list>
+
+
+
+Barnes, et al. Informational [Page 63]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </info:users>
+ </sidebarByValInfo>
+ </ccmp:sidebarByValResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 23: Sidebar for Private Messages Scenario
+
+7.4. Observing and Coaching
+
+ "Observing and Coaching" is one of the most interesting sidebar-
+ related scenarios. In fact, it highlights two different interactions
+ that have to be properly coordinated.
+
+ An example of observing and coaching is shown in Figure 25. In this
+ example, call center agent Bob is involved in a conference with
+ customer Carol. Since Bob is a new agent and Alice sees that he has
+ been on the call with Carol for longer than normal, she decides to
+ observe the call and coach Bob as necessary. Of course, the
+ conferencing system must make sure that the customer Carol is not
+ aware of the presence of the coach Alice. This makes the use of a
+ sidebar necessary for the success of the scenario.
+
+ Consider the following as the conference document associated with the
+ video conference involving Bob (the call agent) and Carol (the
+ customer) (Figure 24):
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <info:conference-info
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ entity="xcon:8978383@example.com">
+ <info:conference-description>
+ <info:display-text>
+ CUSTOMER SERVICE conference
+ </info:display-text>
+ <info:conf-uris>
+ <info:entry>
+ <info:uri>sip:8978383@example.com</info:uri>
+ <info:display-text>conference sip uri</info:display-text>
+ </info:entry>
+ </info:conf-uris>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>service audio</info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+
+
+
+Barnes, et al. Informational [Page 64]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>service video</info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ <xcon:controls>
+ <xcon:video-layout>single-view</xcon:video-layout>
+ </xcon:controls>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>true</info:active>
+ </info:conference-state>
+ <info:users>
+ <info:user entity="xcon-userid:bob@example.com">
+ <info:display-text>Bob - call agent</info:display-text>
+ <info:endpoint entity="sip:bob@example.com">
+ <info:media id="1">
+ <info:label>123</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ <info:media id="2">
+ <info:label>456</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ <info:user entity="xcon-userid:carol@example.com">
+ <info:display-text>Carol - customer</info:display-text>
+ <info:endpoint entity="sip:carol@example.com">
+ <info:media id="1">
+ <info:label>123</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ <info:media id="2">
+ <info:label>456</info:label>
+ <info:status>sendrecv</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ </info:users>
+ </info:conference-info>
+
+ Figure 24: A Call-Center Conference Object Example
+
+
+
+
+
+
+Barnes, et al. Informational [Page 65]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+Alice Bob ConfS
+ | | |
+ |(1) sidebarByRefRequest(confUserID, |
+ | confObjID, create) |
+ |--------------------------------------------->|
+ | | |
+ | | (a) Create +---|
+ | | sidebar-by-ref | |
+ | | (new conf obj | |
+ | | cloned from +-->|
+ | | confObjID) | Sidebar now has
+ | | | id confObjID*
+ |(2) sidebarByRefResponse(confUserID, | (parent mapping
+ | confObjID*,create,200,success, | conf<->sidebar)
+ | version,sidebarByRefInfo) |
+ |<---------------------------------------------|
+ | | |
+ |(3) sidebarByRefRequest(confUserID, |
+ | confObjID*,update,sidebarByRefInfo) |
+ |--------------------------------------------->|
+ | | |
+ | | (b) Update +---|
+ | | sidebar-by-val | |
+ | | (media, users | |
+ | | policy, etc.) +-->|
+ | | | Sidebar is modified:
+ | | | unilateral sidebar
+ | | | audio, Carol excluded
+ | | | from the sidebar
+ |(4) sidebarByRefResponse(confUserID, |
+ | confObjID*, update, |
+ | 200, success, version) |
+ |<---------------------------------------------|
+ | | |
+ | | Notify (Bob |
+ | | he's been added to |
+ | | sidebar users) |
+ | |<----------------------|
+ | | |
+ ' ' '
+ ' ' '
+ ' ' '
+
+ Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 66]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 1. Upon receipt of the sidbarByRefRequest/create message from Alice
+ to create a new sidebar conference from the <confObjID> received
+ in the request, the conference server uses the received active
+ conference to clone a conference reservation for the sidebar.
+ The conference server also allocates a new XCON-URI to be used
+ for any subsequent protocol requests directed to the new sidebar.
+ The conference server maintains the mapping between this sidebar
+ conference ID and the one associated with the main conference
+ instance. The conference server sends a sidebarByRefResponse
+ message with the new XCON-URI in the <confObjID> field and other
+ relevant information in the <sidebarByRefInfo>.
+
+ 2. Upon receipt of the sidebarByRefResponse message, Alice
+ manipulates the data received in the <sidebarByRefInfo> in the
+ response. Alice wants only Bob to be involved in the sidebar;
+ thus, she updates the <allowed-users-list> to include only Bob
+ and herself. Alice also wants the audio to be received by
+ herself and Bob from the original conference, but wants any
+ outgoing audio from herself to be restricted to the participants
+ in the sidebar, whereas Bob's outgoing audio should go to the
+ main conference, so that both Alice and the customer Carol hear
+ the same audio from Bob. Alice sends a sidebarByRefRequest
+ message with an "update" <operation> including the updated
+ sidebar information in the <sidebarByRefInfo> element.
+
+ 3. Upon receipt of the sidebarByRefRequest/update message, the
+ conference server ensures that Alice has the appropriate
+ authority based on the policies associated with that specific
+ conference object to perform the operation. In order to request
+ the insertion of a further media stream in the sidebar (i.e., in
+ this example an audio stream from Alice to Bob), the requester
+ has to provide a new <entry> element in the <available-media>
+ field of the <sidebarByRefInfo>. The mandatory 'label' attribute
+ of that new <entry> is filled with a dummy value
+ "AUTO_GENERATE_1", but it will contain the real server-generated
+ media stream identifier when the media stream is effectively
+ allocated on the server side. Similarly, the mandatory 'id'
+ attribute in the <media> element referring to the new sidebar
+ audio stream under both Alice's and Bob's <endpoint> contains a
+ wildcard value, respectively, "AUTO_GENERATE_2" and
+ "AUTO_GENERATE_3": those values will be replaced with the
+ appropriated server-generated identifiers upon the creation of
+ the referred media stream. We are assuming the conference server
+ is able to recognize those dummy values as placeholders.
+
+ 4. After validating the data, the conference server sends a
+ sidebarByRefResponse message. Based upon the contact information
+ provided for Bob by Alice, the call signaling to add Bob to the
+
+
+
+Barnes, et al. Informational [Page 67]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ sidebar with the appropriate media characteristics is instigated
+ through the focus. Bob is notified of his addition to the
+ sidebar via the conference notification service; thus, he is
+ aware that Alice, the supervisor, is available for coaching him
+ through this call.
+
+1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
+ <confUserID>xcon-userid:alice@example.com</confUserID>
+ <confObjID>xcon:8978383@example.com</confObjID>
+ <operation>create</operation>
+ <ccmp:sidebarByRefRequest/>
+ </ccmpRequest>
+</ccmp:ccmpRequest>
+
+2. sidebarByRefResponse/create message (sidebar created)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
+ <confUserID>xcon-userid:alice@example.com</confUserID>
+ <confObjID>xcon:8971313@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>Success</response-string>
+ <version>1</version>
+ <ccmp:sidebarByRefResponse>
+ <sidebarByRefInfo entity="xcon:8971313@example.com">
+ <info:conference-description>
+ <info:display-text>
+ SIDEBAR CONFERENCE registered by alice
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="123">
+ <info:display-text>
+ main conference audio
+ </info:display-text>
+ <info:type>audio</info:type>
+
+
+
+Barnes, et al. Informational [Page 68]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ <info:entry label="456">
+ <info:display-text>
+ main conference video
+ </info:display-text>
+ <info:type>video</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ <xcon:sidebar-parent>
+ xcon:8971313@example.com
+ </xcon:sidebar-parent>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>false</info:active>
+ </info:conference-state>
+ <info:users>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:alice@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:bob@example.com"/>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:carol@example.com"/>
+ </xcon:allowed-users-list>
+ </info:users>
+ </sidebarByRefInfo>
+ </ccmp:sidebarByRefResponse>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ 3. sidebarByRefRequest/update message (Alice introduces unilateral
+ sidebar audio and excludes Carol from the sidebar)
+
+ <ccmp:ccmpRequest
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
+ <confUserID>xcon-userid:alice@example.com</confUserID>
+ <confObjID>xcon:8971313@example.com</confObjID>
+ <operation>update</operation>
+ <ccmp:sidebarByRefRequest>
+ <sidebarByRefInfo entity="xcon:8971313@example.com">
+
+
+
+
+
+Barnes, et al. Informational [Page 69]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ <info:conference-description>
+ <info:display-text>
+ Coaching sidebar Alice and Bob
+ </info:display-text>
+ <info:available-media>
+ <info:entry label="AUTO_GENERATE_1">
+ <info:display-text>
+ Alice-to-Bob audio
+ </info:display-text>
+ <info:type>audio</info:type>
+ <info:status>sendrecv</info:status>
+ </info:entry>
+ </info:available-media>
+ </info:conference-description>
+ <info:conference-state>
+ <info:active>false</info:active>
+ </info:conference-state>
+ <info:users>
+ <info:user entity="xcon-userid:alice@example.com">
+ <info:endpoint entity="sip:alice@example.com">
+ <info:media id="AUTO_GENERATE_2">
+ <info:label>AUTO_GENERATE_1</info:label>
+ <info:status>sendonly</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ <info:user entity="xcon-userid:bob@example.com">
+ <info:endpoint entity="sip:bob@example.com">
+ <info:media id="AUTO_GENERATE_3">
+ <info:label>AUTO_GENERATE_1</info:label>
+ <info:status>recvonly</info:status>
+ </info:media>
+ </info:endpoint>
+ </info:user>
+ <xcon:allowed-users-list>
+ <xcon:target method="dial-in"
+ uri="xcon-userid:alice@example.com"/>
+ <xcon:target method="dial-out"
+ uri="xcon-userid:bob@example.com"/>
+ </xcon:allowed-users-list>
+ </info:users>
+ </sidebarByRefInfo>
+ </ccmp:sidebarByRefRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+
+
+
+
+
+Barnes, et al. Informational [Page 70]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+4. sidebarByRefRequest/update message (updates accepted)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
+ <confUserID>xcon-userid:alice@example.com</confUserID>
+ <confObjID>xcon:8971313@example.com</confObjID>
+ <operation>update</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>2</version>
+ <ccmp:sidebarByRefResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 26: Coaching and Observing Messaging Details
+
+8. Removing Participants and Deleting Conferences
+
+ The following scenarios detail the basic operations associated with
+ removing participants from conferences and entirely deleting
+ conferences. The examples assume that a conference has already been
+ correctly established, with media, if applicable, per one of the
+ examples in Section 5.
+
+8.1. Removing a Party
+
+ Figure 27 provides an example of a client, Alice, removing another
+ participant, Bob, from a conference. This example assumes an
+ established conference with Alice, Bob, Claire, and Duck. In this
+ example, Alice wants to remove Bob from the conference so that the
+ group can continue in the same conference without Bob's
+ participation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 71]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ Alice Bob Claire ConfS
+ | | | |
+ |(1) userRequest(confUserID,| |
+ | confObjID, delete,| |
+ | userInfo) | |
+ |-------------------------------------->|
+ | | | |
+ | | | (a) Focus |
+ | | | tears down|
+ | | | signaling |
+ | | | to Bob |
+ | |<----------------------|
+ | | |
+ | | (b)Deletes+---|
+ | | | Bob | |
+ | | | as a | |
+ | | | user +-->|
+ | | | in |
+ | | | confObj |
+ | | | |
+ |(2) userResponse(confUserID,confObjID, |
+ | delete,200,success,version) |
+ |<--------------------------------------|
+ | | | |
+ | | | |
+ | | | (c) Notify|
+ | | | ("Bob just|
+ | | | left") |
+ | | |<----------|
+ | | | |
+ ' ' ' '
+ ' ' ' '
+ ' ' ' '
+
+ Figure 27: Client Manipulation of Conference - Remove a Party
+
+ 1. Alice sends a userRequest message with a "delete" <operation>.
+ The conference server ensures that Alice has the appropriate
+ authority based on the policies associated with that specific
+ conference object to perform the operation.
+
+ 2. Based upon the contact and media information in the conference
+ object for Bob in the <userInfo> element, the conferencing system
+ starts the process to remove Bob (e.g., the call signaling to
+ remove Bob from the conference is instigated through the focus).
+ The conference server updates the data in the conference object,
+ thus, removing Bob from the <users> list. After updating the
+ data, the conference server sends a userResponse message to
+
+
+
+Barnes, et al. Informational [Page 72]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ Alice. Depending upon the policies, other participants (e.g.,
+ Claire) may be notified of the removal of Bob from the conference
+ via the conference notification service.
+
+ 1. userRequest/delete message (Alice deletes Bob)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>delete</operation>
+ <ccmp:userRequest>
+ <userInfo entity="xcon-userid:Bob@example.com"/>
+ </ccmp:userRequest>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. userResponse/delete message (Bob has been deleted)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-user-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>delete</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <version>17</version>
+ <ccmp:userResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 28: Removing a Participant Messaging Details
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 73]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+8.2. Deleting a Conference
+
+ In this section, an example of a successful conference deletion is
+ provided (Figure 29).
+
+ Alice ConfS
+ | |
+ |(1)confRequest(confUserID, |
+ | confObjID, delete) |
+ |------------------------------>|
+ | (a)Delete +---|
+ | Conf | |
+ | Object | |
+ | +-->|
+ | |--+ (b) MS
+ | | | removes related
+ | | | mixer instances and
+ | |<-+ their participants
+ | | (SIP signaling as well)
+ | |
+ |(2)confResponse(confUserID, |
+ | confObjID,delete,200, |
+ | success) |
+ | |
+ |<------------------------------|
+ | |
+ ' '
+
+ Figure 29: Deleting a Conference
+
+ 1. The conferencing system client Alice sends a confRequest message
+ with a "delete" operation to be performed on the conference
+ identified by the XCON-URI carried in the <confObjID> parameter.
+ The conference server, on the basis of the <confUserID> included
+ in the receipt request, ensures that Alice has the appropriate
+ authority to fulfill the operation.
+
+ 2. After validating Alice's rights, the conference server instigates
+ the process to delete the conference object, disconnecting
+ participants and removing associated resources such as mixer
+ instances. Then, the conference server returns a confResponse
+ message to Alice with "200" as <response-code> and the deleted
+ conference XCON-URI in the <confObjID> field.
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 74]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ 1. confRequest/delete message (Alice deletes a conference)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-conf-request-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>delete</operation>
+ <ccmp:confRequest/>
+ </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. confResponse/delete message ("200", "success")
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+ xmlns:info="urn:ietf:params:xml:ns:conference-info"
+ xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
+ xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+ <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:type="ccmp:ccmp-conf-response-message-type">
+ <confUserID>xcon-userid:Alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>delete</operation>
+ <response-code>200</response-code>
+ <response-string>success</response-string>
+ <ccmp:confResponse/>
+ </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+ Figure 30: Deleting a Conference Messaging Details
+
+9. Security Considerations
+
+ The security considerations applicable to the implementation of these
+ call flows are documented in the XCON framework, with additional
+ security considerations documented in the CCMP document. Statements
+ with regard to the necessary security are discussed in particular
+ flows; however, this is for informational purposes only. The
+ implementer is encouraged to carefully consider the security
+ requirements in the normative documents.
+
+
+
+
+
+
+Barnes, et al. Informational [Page 75]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+10. Acknowledgements
+
+ The detailed content for this document is derived from the prototype
+ work of Lorenzo Miniero, Simon Pietro Romano, Tobia Castaldi, and
+ their colleagues at the University of Napoli.
+
+11. References
+
+11.1. Normative References
+
+ [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
+ Centralized Conferencing", RFC 5239, June 2008.
+
+ [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+ "Conference Information Data Model for Centralized
+ Conferencing (XCON)", RFC 6501, March 2012.
+
+ [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J.
+ Urpalainen, "Conference Event Package Data Format
+ Extension for Centralized Conferencing (XCON)", RFC 6502,
+ March 2012.
+
+ [RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
+ "Centralized Conferencing Manipulation Protocol",
+ RFC 6503, March 2012.
+
+ [W3C.REC-xml-20081126]
+ Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", World Wide Web Consortium Recommendation REC-
+ xml-20081126, November 2008,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+11.2. Informative References
+
+ [CALL-FLOWS]
+ Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
+ "Media Control Channel Framework (CFW) Call Flow
+ Examples", Work in Progress, July 2011.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
+ Initiation Protocol (SIP) Event Package for Conference
+ State", RFC 4575, August 2006.
+
+
+
+Barnes, et al. Informational [Page 76]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+ [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
+ (SIP) Call Control - Conferencing for User Agents",
+ BCP 119, RFC 4579, August 2006.
+
+ [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
+ Control Protocol (BFCP)", RFC 4582, November 2006.
+
+ [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
+ RFC 4597, August 2006.
+
+ [RFC5567] Melanchuk, T., "An Architectural Framework for Media
+ Server Control", RFC 5567, June 2009.
+
+ [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
+ Control Package for the Media Control Channel Framework",
+ RFC 6505, March 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 77]
+
+RFC 6504 CCMP Call Flow Examples March 2012
+
+
+Authors' Addresses
+
+ Mary Barnes
+ Polycom
+ TX
+ USA
+
+ EMail: mary.ietf.barnes@gmail.com
+
+
+ Lorenzo Miniero
+ Meetecho
+ Via Carlo Poerio 89/a
+ Napoli 80121
+ Italy
+
+ EMail: lorenzo@meetecho.com
+
+
+ Roberta Presta
+ University of Napoli
+ Via Claudio 21
+ Napoli 80125
+ Italy
+
+ EMail: roberta.presta@unina.it
+
+
+ Simon Pietro Romano
+ University of Napoli
+ Via Claudio 21
+ Napoli 80125
+ Italy
+
+ EMail: spromano@unina.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al. Informational [Page 78]
+