draft-ietf-xcon-examples-08.txt   draft-ietf-xcon-examples-09.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Informational L. Miniero Intended status: Informational L. Miniero
Expires: August 18, 2011 Meetecho Expires: January 12, 2012 Meetecho
R. Presta R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
February 14, 2011 July 11, 2011
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-08 draft-ietf-xcon-examples-09
Abstract Abstract
This document provides detailed call flows for the scenarios This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol objective is to provide a base reference for both protocol
researchers and developers. researchers and developers.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4
4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5
4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6 4.2. Using HTTP/TLS as a transport . . . . . . . . . . . . . . 6
4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 11 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 11
5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 12 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 12
5.2. Conference Creation using Blueprints . . . . . . . . . . . 16 5.2. Conference Creation using Blueprints . . . . . . . . . . . 16
5.3. Conference Creation using User-Provided Conference 5.3. Conference Creation using User-Provided Conference
Information . . . . . . . . . . . . . . . . . . . . . . . 23 Information . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 28 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 28
6. Conference Users Scenarios and Examples . . . . . . . . . . . 32 6. Conference Users Scenarios and Examples . . . . . . . . . . . 32
6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 36 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 2, line 42 skipping to change at page 2, line 42
7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 46 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 46
7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 47 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 47
7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 56 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 56
7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63
7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67
8. Removing Participants and Deleting Conferences . . . . . . . . 74 8. Removing Participants and Deleting Conferences . . . . . . . . 74
8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74
8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 12. Informative References . . . . . . . . . . . . . . . . . . . . 79
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80
13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
13.2. Informative References . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
This document provides detailed call flows for the scenarios This document provides detailed call flows for the scenarios
documented in the Framework for Centralized Conferencing (XCON documented in the Framework for Centralized Conferencing (XCON
Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
scenarios describe a broad range of use cases taking advantage of the scenarios describe a broad range of use cases taking advantage of the
advanced conferencing capabilities provided by a system realization advanced conferencing capabilities provided by a system realization
of the XCON framework. The call flows document the use of the of the XCON framework. The call flows document the use of the
interface between a conference control client and a conference interface between a conference control client and a conference
skipping to change at page 3, line 49 skipping to change at page 3, line 49
equivalent to the use of UAC as the client notation in the media equivalent to the use of UAC as the client notation in the media
control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC
differs from a generic Media Client in being an XCON-aware entity, differs from a generic Media Client in being an XCON-aware entity,
thus being able to also issue CCMP requests. thus being able to also issue CCMP requests.
Conferencing Server (ConfS): In this document, the term Conferencing Server (ConfS): In this document, the term
"Conferencing Server" is used interchangeably with the term "Conferencing Server" is used interchangeably with the term
"Application Server" (AS) as used in the Media Control "Application Server" (AS) as used in the Media Control
Architectural Framework [RFC5567]. A Conferencing Server is Architectural Framework [RFC5567]. A Conferencing Server is
intended to be able to act as a Conference Control Server, as 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 defined in the XCON framework, i.e., it is able to handle CCMP
requests and issue CCMP responses. requests and issue CCMP responses.
Media Server (MS): as defined in the Media Control Architectural Media Server (MS): as defined in the Media Control Architectural
Framework [RFC5567]. Framework [RFC5567].
3. Overview 3. Overview
This document provides a sampling of detailed call flows that can be This document provides a sampling of detailed call flows that can be
implemented based on a system realization of the XCON framework implemented based on a system realization of the XCON framework
[RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
skipping to change at page 6, line 28 skipping to change at page 6, line 28
example, a CMCC may be requesting the direct creation of a new example, a CMCC may be requesting the direct creation of a new
conference: in this case, a conference object assumes an 'entity' conference: in this case, a conference object assumes an 'entity'
element uniquely identifying the conference to be in place. Thus, element uniquely identifying the conference to be in place. Thus,
the CMCC has no way to know a priori what the entity will be, since 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 it is generated by the ConfS after the request. For scenarios like
this one, the CCMP specification describes the use of a dedicated this one, the CCMP specification describes the use of a dedicated
placeholder wildcard (i.e., AUTO_GENERATE_X, where X is an integer) placeholder wildcard (i.e., AUTO_GENERATE_X, where X is an integer)
to make the conference object compliant with the Data Model: the to make the conference object compliant with the Data Model: the
wildcard would then be replaced by the ConfS with the right value. wildcard would then be replaced by the ConfS with the right value.
4.2. Using HTTP as a transport 4.2. Using HTTP/TLS as a transport
CCMP requests and responses can be transported from a client to a
server and viceversa in several ways, since the protocol
specification is agnostic with respect to the transport. However,
[I-D.ietf-xcon-ccmp] requires that implementations support HTTP. The
following provides a brief explanation, from a more practical point
of view, of how HTTP might be exploited to carry CCMP messages. In
this document, however, all the call flows presented just show the
CCMP interactions, without describing how the messages are
transported.
When HTTP is used as a transport, a CMCC sends his request as part of The CCMP requires that implementations support HTTP/TLS as the
an HTTP POST message, and the ConfS would reply with an HTTP 200 transport mechanism. Per the CCMP, a CMCC sends a request as part of
message. In both cases, the HTTP messages would have the CCMP an HTTPS POST message, and the ConfS would reply with a 200 OK HTTPS
messages as payload, which would be reflected in the Content-Type response. In both cases, the HTTPS messages carry the CCMP messages
message (application/ccmp+xml). Figure 1 presents a ladder diagram as payload, which is reflected in the Content-Type message
of such interaction, which is followed by a dump of the exchanged (application/ccmp+xml). Figure 1 presents a ladder diagram of such
HTTP messages for further analysis: 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.
CMCC ConfS CMCC ConfS
| | | |
| 1. HTTP POST (CCMP request) | | 1. HTTPS POST (CCMP request) |
|--------------------------------------------->| |--------------------------------------------->|
| | | |
| |--+ Parse request, | |--+ Parse request,
| | | update object | | | update object
| |<-+ and reply | |<-+ and reply
| | | |
| 2. 200 OK (CCMP response) | | 2. 200 OK (CCMP response) |
|<---------------------------------------------| |<---------------------------------------------|
| | | |
|--+ Parse response and | |--+ Parse response and |
| | update local copy | | | update local copy |
|<-+ of conference object | |<-+ of conference object |
| | | |
. . . .
. . . .
Figure 1: CCMP on HTTP Figure 1: CCMP on HTTPS
Per the protocol dump in the following lines, the CMCC has issued a Per the protocol dump in the following lines, the CMCC has issued a
CCMP request (a blueprintRequest with a 'retrieve' operation) towards CCMP request (a blueprintRequest with a 'retrieve' operation) towards
the Conferencing Server (ConfS). The request has been carried as the Conferencing Server (ConfS). The request has been carried as
payload of an HTTP POST (message 1.) towards a previously known payload of an HTTPS POST (message 1.) towards a previously known
location. The mandatory 'Host' header has been specified, and the location. The mandatory 'Host' header has been specified, and the
'Content-Type' header has been correctly set as well (application/ 'Content-Type' header has been correctly set as well (application/
ccmp+xml). ccmp+xml).
The ConfS, in turn, has handled the request and replied accordingly. The ConfS, in turn, has handled the request and replied accordingly.
The response (a blueprintResponse with a successful response code) The response (a blueprintResponse with a successful response code)
has been carried as payload of an HTTP 200 OK (message 2.). As has been carried as payload of a 200 OK HTTPS response (message 2.).
before, the 'Content-Type' header has been correctly set As before, the 'Content-Type' header has been correctly set
(application/ccmp+xml). (application/ccmp+xml).
1. CMCC -> ConfS (HTTP POST, CCMP request) 1. CMCC -> ConfS (HTTPS POST, CCMP request)
------------------------------------------ ------------------------------------------
POST /Xcon/Ccmp HTTP/1.1 POST /Xcon/Ccmp HTTP/1.1
Content-Length: 657 Content-Length: 657
Content-Type: application/ccmp+xml Content-Type: application/ccmp+xml
Host: example.com:8080 Host: example.com:443
Connection: Keep-Alive Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5) User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type"> xsi:type="ccmp:ccmp-blueprint-request-message-type">
skipping to change at page 11, line 47 skipping to change at page 11, line 47
5. Conference Creation 5. Conference Creation
This section provides details associated with the various ways in This section provides details associated with the various ways in
which a conference can be created using CCMP and the XCON framework which a conference can be created using CCMP and the XCON framework
constructs. As previously mentioned, the details of the media constructs. As previously mentioned, the details of the media
control, call signaling and floor control protocols, where control, call signaling and floor control protocols, where
applicable, are annotated in the flows without showing all the applicable, are annotated in the flows without showing all the
details. This also applies to CCMP, whose flows are related to the details. This also applies to CCMP, whose flows are related to the
protocol alone, hiding any detail concerning the transport that may protocol alone, hiding any detail concerning the transport that may
have been used (e.g. HTTP). However, for clarification purposes, have been used (e.g., HTTP). However, for clarification purposes,
the first example Section 5.1 provides the details of the media the first example Section 5.1 provides the details of the media
control messaging with the standard annotation used throughout the control messaging with the standard annotation used throughout the
remainder of this document. In subsequent flows, only this remainder of this document. In subsequent flows, only this
annotation (identified by lower case letters) is included and the annotation (identified by lower case letters) is included and the
reader is encouraged to refer to the call flows in the relevant reader is encouraged to refer to the call flows in the relevant
documents for details about the other protocols. The annotations for documents for details about the other protocols. The annotations for
the call signaling are on the left side of the conferencing server the call signaling are on the left side of the conferencing server
vertical bar and those for the media control messaging are on the vertical bar and those for the media control messaging are on the
right side. right side.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
As previously described, this example also shows how the conferencing As previously described, this example also shows how the conferencing
system may make use of other standard protocol components for system may make use of other standard protocol components for
complete functionality. An example of that is the MEDIACTRL complete functionality. An example of that is the MEDIACTRL
specification, which allows the conferencing system to configure specification, which allows the conferencing system to configure
conference mixes, IVR dialogs and all sort of media-related conference mixes, IVR dialogs and all sort of media-related
interactions an application like this may need. In order to provide interactions an application like this may need. In order to provide
the reader with some insight on these interactions, the conferencing the reader with some insight on these interactions, the conferencing
system in this example also configures and starts a mixer via system in this example also configures and starts a mixer via
MEDIACTRL as soon as the conference is created (transactions A1 and MEDIACTRL as soon as the conference is created (transactions A1 and
A2), and attaches clients to it when necessary (e.g. when CMCC1 joins A2), and attaches clients to it when necessary (e.g., when CMCC1
the conference by means of SIP signaling, its media channels are joins the conference by means of SIP signaling, its media channels
attached to the Media Server using MEDIACTRL in B1/B2). Note, that are attached to the Media Server using MEDIACTRL in B1/B2). Note,
the MEDIACTRL interfaces are NOT shown in the remaining call flows in that the MEDIACTRL interfaces are NOT shown in the remaining call
this document, but rather follow the same annotation as with the SIP flows in this document, but rather follow the same annotation as with
signaling such that (b) correlates with the A1 and A2 transactions the SIP signaling such that (b) correlates with the A1 and A2
and (d) correlates with the B1 and B2 transactions. transactions and (d) correlates with the B1 and B2 transactions.
CMCC1 CMCC2 CMCCx ConfS MS CMCC1 CMCC2 CMCCx ConfS MS
| | | | | | | | | |
|(1)confRequest(confUserID, create) | | |(1)confRequest(confUserID, create) | |
|-------------------------------------->| | |-------------------------------------->| |
| | (a)Create +---| | | | (a)Create +---| |
| | |Conf | | | | | |Conf | | |
| | |Object | | | | | |Object | | |
| | |& IDs +-->| | | | |& IDs +-->| |
| | | | A1. CONTROL | | | | | A1. CONTROL |
skipping to change at page 16, line 51 skipping to change at page 16, line 51
CCMP as a consequence) allows for the implementation of templates. CCMP as a consequence) allows for the implementation of templates.
These templates are called "conference blueprints", and are basically These templates are called "conference blueprints", and are basically
conference objects with pre-defined settings. This means that a conference objects with pre-defined settings. This means that a
client might get a list of blueprints, choose the one that more fits client might get a list of blueprints, choose the one that more fits
his needs, and use the chosen blueprint to create a new conference. his needs, and use the chosen blueprint to create a new conference.
This section Figure 5 provides an example of one client, "Alice", This section Figure 5 provides an example of one client, "Alice",
discovering the conference blueprints available for a particular discovering the conference blueprints available for a particular
conferencing system and creating a conference based on the desired conferencing system and creating a conference based on the desired
blueprint. In particular, Alice is interested in those blueprints blueprint. In particular, Alice is interested in those blueprints
suitable to represent a "video-conference", i.e. a conference in suitable to represent a "video-conference", i.e., a conference in
which both audio and video are available, so she makes use of the which both audio and video are available, so she makes use of the
filter mechanism provided by CCMP to make a selective blueprints filter mechanism provided by CCMP to make a selective blueprints
retrieve request. This results in three distinct CCMP transactions. retrieve request. This results in three distinct CCMP transactions.
CMCC "Alice" ConfS CMCC "Alice" ConfS
| | | |
| (1) blueprintsRequest | | (1) blueprintsRequest |
| (confUserID,xpathFilter) | | (confUserID,xpathFilter) |
|------------------------------>| |------------------------------>|
| | | |
skipping to change at page 19, line 12 skipping to change at page 19, line 12
cloning the chosen blueprint. This is achieved by writing the cloning the chosen blueprint. This is achieved by writing the
blueprint's XCON-URI in the "confObjID" parameter. blueprint's XCON-URI in the "confObjID" parameter.
6. Upon receipt of the "confRequest" message with a "create" 6. Upon receipt of the "confRequest" message with a "create"
operation, the conferencing system uses the received blueprint to operation, the conferencing system uses the received blueprint to
clone a conference, allocating a new XCON-URI (again called clone a conference, allocating a new XCON-URI (again called
"confObjID*" in the example). The conferencing server then sends "confObjID*" in the example). The conferencing server then sends
a "confResponse" message including the new "confObjID*" a "confResponse" message including the new "confObjID*"
associated with the newly created conference instance. Upon associated with the newly created conference instance. Upon
receipt of the "confResponse" message, Alice can now add other receipt of the "confResponse" message, Alice can now add other
users to the conference . users to the conference.
1. blueprintsRequest message (Alice requires the list of the 1. blueprintsRequest message (Alice requires the list of the
available blueprints with video support) available blueprints with video support)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-request-message-type"> xsi:type="ccmp:ccmp-blueprints-request-message-type">
skipping to change at page 23, line 50 skipping to change at page 23, line 50
5.3. Conference Creation using User-Provided Conference Information 5.3. Conference Creation using User-Provided Conference Information
A conference can also be created by the client sending a A conference can also be created by the client sending a
"confRequest" message with the "create" operation, along with the "confRequest" message with the "create" operation, along with the
desired data in the form of the "confInfo" parameter for the desired data in the form of the "confInfo" parameter for the
conference to be created. The request also includes the "confUserID" conference to be created. The request also includes the "confUserID"
of the requesting entity. of the requesting entity.
This approach allows for a client (in this example Alice) to This approach allows for a client (in this example Alice) to
completely describe what the conference object should look like, completely describe what the conference object should look like,
without relying on defaults or blueprints: e.g, which media should be without relying on defaults or blueprints: e.g., which media should
available, the topic, the users allowed to join, any scheduling- be available, the topic, the users allowed to join, any scheduling-
related information and so on. This can be done by providing in the related information and so on. This can be done by providing in the
creation request a full conference object for the server to parse. creation request a full conference object for the server to parse.
This "confInfo" parameter must comply with the Data Model This "confInfo" parameter must comply with the Data Model
specification. This means that the "entity" attribute is mandatory, specification. This means that the "entity" attribute is mandatory,
and cannot be missing in the document. However, in this example the and cannot be missing in the document. However, in this example the
client is actually requesting the creation of a new conference, which client is actually requesting the creation of a new conference, which
doesn't exist yet, so the "entity" attribute is unknown. As doesn't exist yet, so the "entity" attribute is unknown. As
discussed in Section 4.1, the CCMP protocol allows for the use of a discussed in Section 4.1, the CCMP protocol allows for the use of a
wildcard placeholder. This placeholder wildcard placeholder. This placeholder
("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure ("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure
the "confInfo" element is compliant with the Data Model, and would the "confInfo" element is compliant with the Data Model, and would
subsequently be replaced by the conferencing system with the actual subsequently be replaced by the conferencing system with the actual
value. Thus, when the conferencing system actually creates the value. Thus, when the conferencing system actually creates the
conference, a valid "entity" value is created for it as well, which conference, a valid "entity" value is created for it as well, which
takes the place of the wildcard value when the actual conference takes the place of the wildcard value when the actual conference
object provided by the client is populated. object provided by the client is populated.
To give a flavour of what could be added to the conference object, we To give a flavor of what could be added to the conference object, we
assume Alice is also interested in providing scheduling-related assume Alice is also interested in providing scheduling-related
information. So, in this example, Alice also specifies by the information. So, in this example, Alice also specifies by the
<conference-time> element included in the "confInfo" that the <conference-time> element included in the "confInfo" that the
conference she wants to create has to occur on a certain date 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 spanning from a certain start time to a certain stop time and has to
be replicated weekly. be replicated weekly.
Moreover, Alice indicates by means of the <allowed-users-list> that Moreover, Alice indicates by means of the <allowed-users-list> that
at the start time Bob, Carol and herself have to be called by the at the start time Bob, Carol and herself have to be called by the
conferencing system to join the conference (in fact, for each conferencing system to join the conference (in fact, for each
skipping to change at page 24, line 51 skipping to change at page 24, line 51
form of the "confObjID" parameter and the XCON-USERID in the form of form of the "confObjID" parameter and the XCON-USERID in the form of
the "confUserID" parameter (again, the same as the requesting entity) the "confUserID" parameter (again, the same as the requesting entity)
are returned in the "confResponse" message. are returned in the "confResponse" message.
In this example, the created conference object is not returned in the In this example, the created conference object is not returned in the
successful "confResponse" in the "confInfo" parameter. Nevertheless, successful "confResponse" in the "confInfo" parameter. Nevertheless,
Alice could still retrieve the actual conference object by issuing a Alice could still retrieve the actual conference object by issuing a
"confRequest" with a "retrieve" operation on the returned "confRequest" with a "retrieve" operation on the returned
"confObjID". Such a request would show how, as described at the "confObjID". Such a request would show how, as described at the
beginning of this section, the "entity" attribute of the conference beginning of this section, the "entity" attribute of the conference
object in "confInfo" is replaced with the actual information (i.e. object in "confInfo" is replaced with the actual information (i.e.,
"xcon:6845432@example.com"). "xcon:6845432@example.com").
Alice Bob Carol ConfS Alice Bob Carol ConfS
| | | | | | | |
| | | | | | | |
|(1)confRequest(confUserID, | | |(1)confRequest(confUserID, | |
| create, confInfo) | | | create, confInfo) | |
| | | | | | | |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
skipping to change at page 32, line 20 skipping to change at page 32, line 20
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 10: Create Basic Conference (Clone) Detailed Messaging Figure 10: Create Basic Conference (Clone) Detailed Messaging
6. Conference Users Scenarios and Examples 6. Conference Users Scenarios and Examples
Section 5 showed examples describing the several different ways a Section 5 showed examples describing the several different ways a
conference might be created using CCMP. This section focuses on conference might be created using CCMP. This section focuses on
user-related scenarios, i.e. typical scenarios that may occur during user-related scenarios, i.e., typical scenarios that may occur during
the lifetime of a conference, like adding new users and handling the lifetime of a conference, like adding new users and handling
their media. The following scenarios are based on those documented their media. The following scenarios are based on those documented
in the XCON framework. The examples assume that a conference has in the XCON framework. The examples assume that a conference has
already been correctly established, with media, if applicable, per already been correctly established, with media, if applicable, per
one of the examples in Section 5. one of the examples in Section 5.
6.1. Adding a Party 6.1. Adding a Party
In this example, Alice wants to add Bob to an established conference. 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, In the following example we assume Bob is a new user of the system,
skipping to change at page 34, line 27 skipping to change at page 34, line 27
element of the returned "userInfo"; element of the returned "userInfo";
3. In the presented example, the call signaling to add Bob to the 3. In the presented example, the call signaling to add Bob to the
conference is instigated through the Focus as well. As noted conference is instigated through the Focus as well. As noted
previously, this is implementation specific. In fact, a previously, this is implementation specific. In fact, a
conferencing system may accomplish different actions after the conferencing system may accomplish different actions after the
user creation, just as it may do nothing at all. Among the user creation, just as it may do nothing at all. Among the
possible actions, for instance, Bob may be added as a <target> possible actions, for instance, Bob may be added as a <target>
element to the <allowed-users-list> element, whose joining element to the <allowed-users-list> element, whose joining
"method" may be either "dial-in" or "dial-out". Besides, out-of- "method" may be either "dial-in" or "dial-out". Besides, out-of-
band notification mechanisms may be involved as well, e.g. to band notification mechanisms may be involved as well, e.g., to
notify Bob via mail of the new conference, including details as notify Bob via mail of the new conference, including details as
the date, password, expected participants and so on (see the date, password, expected participants and so on (see
Section 4.3). Section 4.3).
Once Bob has been successfully added to the specified conference, Once Bob has been successfully added to the specified conference,
per updates to the state, and depending upon the policies, other per updates to the state, and depending upon the policies, other
participants (including Bob himself) may be notified of the participants (including Bob himself) may be notified of the
addition of Bob to the conference via the Conference Notification addition of Bob to the conference via the Conference Notification
Service in use. Service in use.
skipping to change at page 36, line 39 skipping to change at page 36, line 39
office environment is disruptive to the conference. BFCP floor office environment is disruptive to the conference. BFCP floor
control is assumed not to be involved. control is assumed not to be involved.
Muting can be accomplished using the "mute" control in the conference Muting can be accomplished using the "mute" control in the conference
object, in which case the conference server must update the settings object, in which case the conference server must update the settings
associated with the user's media streams. Muting/unmuting can also associated with the user's media streams. Muting/unmuting can also
be accomplished by directly updating the conference object with be accomplished by directly updating the conference object with
modified settings related to the target user's media streams, which modified settings related to the target user's media streams, which
is the approach shown in this example. Specifically, Bob's is the approach shown in this example. Specifically, Bob's
"userInfo" is updated by modifying its audio <endpoint> information "userInfo" is updated by modifying its audio <endpoint> information
(e.g. setting it to "recvonly" in case of muting), identified by the (e.g., setting it to "recvonly" in case of muting), identified by the
right media id. right media id.
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS MS CMCC1 CMCC2 CMCCx ConfS MS
| | | | | | | | | |
|(1) userRequest(subject, | | | |(1) userRequest(subject, | | |
| confUserID,confObjID, | | | | confUserID,confObjID, | | |
| update,userInfo) | | | | update,userInfo) | | |
| | | | | | | | | |
|--------------------------------------->| | |--------------------------------------->| |
skipping to change at page 37, line 44 skipping to change at page 37, line 44
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
Figure 13: Client Manipulation of Conference - Mute a party Figure 13: Client Manipulation of Conference - Mute a party
1. Alice sends a userRequest message with an "update" operation and 1. Alice sends a userRequest message with an "update" operation and
the userInfo with the "status" field in the "media" element for the userInfo with the "status" field in the "media" element for
Bob's <endpoint> set to "revconly". In order to authenticate Bob's <endpoint> set to "revconly". In order to authenticate
herself, Alice provides in the "subject" request parameter her herself, Alice provides in the "subject" request parameter her
registration credentials (i.e. username and password). The registration credentials (i.e., username and password). The
"subject" parameter is an optional one: its use can be systematic "subject" parameter is an optional one: its use can be systematic
whenever the conferencing server envisages to authenticate each whenever the conferencing server envisages to authenticate each
requestor. In such cases, if the client does not provide the requestor. In such cases, if the client does not provide the
required authentication information, the conferencing server required authentication information, the conferencing server
answers with a CCMP "authenticationRequired" response message, answers with a CCMP "authenticationRequired" response message,
indicating that the request cannot be processed without including indicating that the request cannot be processed without including
the proper "subject" parameter. The Conference Server ensures the proper "subject" parameter. The Conference Server ensures
that Alice has the appropriate authority based on the policies that Alice has the appropriate authority based on the policies
associated with that specific conference object to perform the associated with that specific conference object to perform the
operation. It recognizes that Alice is allowed to request the operation. It recognizes that Alice is allowed to request the
skipping to change at page 40, line 9 skipping to change at page 40, line 9
<response-string>success</response-string> <response-string>success</response-string>
<version>7</version> <version>7</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 14: Mute Message Details Figure 14: Mute Message Details
6.3. Conference Announcements and Recordings 6.3. Conference Announcements and Recordings
This section deals with features that are typically required in a This section deals with features that are typically required in a
conferencing system, such as public announcements (e.g. to notify conferencing system, such as public announcements (e.g., to notify
vocally that a new user joined a conference) and name recording. vocally that a new user joined a conference) and name recording.
While this is not strictly CCMP-related (the CCMP signaling is 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 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 interesting scenario to address to see how several components of an
XCON-compliant architecture interact with each other to make it XCON-compliant architecture interact with each other to make it
happen. happen.
In this example, as shown in Figure 15 Alice is joining Bob's In this example, as shown in Figure 15 Alice is joining Bob's
conference that requires that she first enters a pass code. After conference that requires that she first enters a pass code. After
successfully entering the pass code, an announcement prompts Alice to successfully entering the pass code, an announcement prompts Alice to
skipping to change at page 42, line 17 skipping to change at page 42, line 17
conference, the conferencing system determines that a password is conference, the conferencing system determines that a password is
required for this specific conference. Thus an announcement required for this specific conference. Thus an announcement
asking Alice to enter the password is sent back. This may be asking Alice to enter the password is sent back. This may be
achieved by means of typical IVR functionality. Once Alice achieved by means of typical IVR functionality. Once Alice
enters the password, it is validated against the policies enters the password, it is validated against the policies
associated with Bob's active conference. The conferencing system associated with Bob's active conference. The conferencing system
then connects to a server which prompts and records Alice's name. then connects to a server which prompts and records Alice's name.
The conferencing system must also determine whether Alice is The conferencing system must also determine whether Alice is
already a user of this conferencing system or whether she is a already a user of this conferencing system or whether she is a
new user. In this case, Alice is a new user for this new user. In this case, Alice is a new user for this
conferencing system, so a Conference User Identifier (i. e. an conferencing system, so a Conference User Identifier (i.e., an
XCON-USERID) is created for Alice. Based upon the contact XCON-USERID) is created for Alice. Based upon the contact
information provided by Alice, the call signaling to add Alice to information provided by Alice, the call signaling to add Alice to
the conference is instigated through the Focus. the conference is instigated through the Focus.
2. The conference server sends Alice a userResponse message which 2. The conference server sends Alice a userResponse message which
includes the "confUserID" assigned by the conferencing system to includes the "confUserID" assigned by the conferencing system to
her. This would allow Alice to later perform operations on the her. This would allow Alice to later perform operations on the
conference (if she were to have the appropriate policies), conference (if she were to have the appropriate policies),
including registering for event notifications associated with the including registering for event notifications associated with the
conference. Once the call signaling indicates that Alice has conference. Once the call signaling indicates that Alice has
skipping to change at page 44, line 13 skipping to change at page 44, line 13
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 16: Announcement Messaging Details Figure 16: Announcement Messaging Details
6.4. Monitoring for DTMF 6.4. Monitoring for DTMF
Conferencing systems often also need the capability to monitor for Conferencing systems often also need the capability to monitor for
DTMF from each individual participant. This would typically be used DTMF from each individual participant. This would typically be used
to enter the identifier and/or access code for joining a specific to enter the identifier and/or access code for joining a specific
conference. This feature is often also exploited to achieve conference. This feature is often also exploited to achieve
interaction between participants and the conference system for non- interaction between participants and the conference system for non-
XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted). XCON-aware user agents (e.g., using DTMF tones to get muted/unmuted).
An example of DTMF monitoring, within the context of the framework An example of DTMF monitoring, within the context of the framework
elements, is shown in Figure 15. The mediactrl architecture/ elements, is shown in Figure 15. The mediactrl architecture/
protocols can be used by the conferencing system for all the DTMF protocols can be used by the conferencing system for all the DTMF
interactions. Examples for DTMF interception in conference instances interactions. Examples for DTMF interception in conference instances
are presented in [I-D.ietf-mediactrl-call-flows]. are presented in [I-D.ietf-mediactrl-call-flows].
6.5. Entering a password-protected conference 6.5. Entering a password-protected conference
Some conferences may require a password to be provided by a user who Some conferences may require a password to be provided by a user who
wants to manipulate the conference objects (e.g. join, update, wants to manipulate the conference objects (e.g., join, update,
delete) via CCMP. In this case, a password would be included in the delete) via CCMP. In this case, a password would be included in the
<conference-password> element related to the conference XCON-URI in <conference-password> element related to the conference XCON-URI in
the appropriate <conference-uris> entry and must be then included in the appropriate <conference-uris> entry and must be then included in
the "conference-password" field in the CCMP request addressed to a the "conference-password" field in the CCMP request addressed to a
specific conference. specific conference.
In the following example, Alice, a conferencing system client, In the following example, Alice, a conferencing system client,
attempts to join a password-protected conference. attempts to join a password-protected conference.
1. Alice sends a userRequest message with a "create" operation to 1. Alice sends a userRequest message with a "create" operation to
skipping to change at page 57, line 6 skipping to change at page 57, line 6
to the conferencing system to create a conference reservation based to the conferencing system to create a conference reservation based
upon the active conference object. Alice, Bob and Ethel would remain 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 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 the hold state of these participants is visible to other participants
depends upon the individual and local policy. However, providing the depends upon the individual and local policy. However, providing the
hold state allows the participants in the main conference to see that hold state allows the participants in the main conference to see that
others in the conference are busy. Note, that a separate conference 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 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 Fred. However, creating a sidebar has somewhat of an advantage by
allowing the conference to be created using some of the same settings 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 (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 conference and it would allow for updates such that the media could
be updated, for example, to provide audio from the main conference. be updated, for example, to provide audio from the main conference.
Alice Bob ConfS Alice Bob ConfS
| | | | | |
|(1) sidebarByRefRequest(confUserID, | |(1) sidebarByRefRequest(confUserID, |
| confObjID, create) | | confObjID, create) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (a) Create +---| | | (a) Create +---|
skipping to change at page 59, line 15 skipping to change at page 59, line 15
1. Upon receipt of the "sidebarByRefRequest" message to create a new 1. Upon receipt of the "sidebarByRefRequest" message to create a new
sidebar conference, based upon the active conference specified by sidebar conference, based upon the active conference specified by
"confObjID" in the request, the conferencing system uses that "confObjID" in the request, the conferencing system uses that
active conference to clone a conference reservation for the active conference to clone a conference reservation for the
sidebar. The sidebar reservation is NOT independent of the sidebar. The sidebar reservation is NOT independent of the
active conference (i.e., parent). The conferencing system, as active conference (i.e., parent). The conferencing system, as
before, allocates a conference ID (confObjID*) to be used for any before, allocates a conference ID (confObjID*) to be used for any
subsequent protocol requests toward the sidebar reservation. The subsequent protocol requests toward the sidebar reservation. The
mapping between the sidebar conference ID and the one associated mapping between the sidebar conference ID and the one associated
with the main conference is mantained by the conferencing system with the main conference is maintained by the conferencing system
and it is gathered from the c<sidebar-parent> element in the and it is gathered from the c<sidebar-parent> element in the
sidebar conference object. sidebar conference object.
2. Upon receipt of the "sidebarByRefResponse" message, which 2. Upon receipt of the "sidebarByRefResponse" message, which
acknowledges the successful creation of the sidebar object, Alice acknowledges the successful creation of the sidebar object, Alice
decides that only Bob and Ethel, along with the new participant decides that only Bob and Ethel, along with the new participant
Fred are to be involved in the sidebar. Thus she manipulates the Fred are to be involved in the sidebar. Thus she manipulates the
membership accordingly. Alice also sets the media in the membership accordingly. Alice also sets the media in the
"conference-info" such that the participants in the sidebar don't "conference-info" such that the participants in the sidebar don't
receive any media from the main conference. All these settings receive any media from the main conference. All these settings
skipping to change at page 59, line 41 skipping to change at page 59, line 41
conference. Upon receipt of the "sidebarByRefRequest" with an conference. Upon receipt of the "sidebarByRefRequest" with an
operation of "update", the conferencing system ensures that Alice operation of "update", the conferencing system ensures that Alice
has the appropriate authority based on the policies associated has the appropriate authority based on the policies associated
with that specific conference object to perform the operation. with that specific conference object to perform the operation.
The conferencing system also validates the updated information in The conferencing system also validates the updated information in
the reservation. Since Fred is a new user for this conferencing the reservation. Since Fred is a new user for this conferencing
system, a conference user identifier is created for Fred. system, a conference user identifier is created for Fred.
Specifically, Fred is added to the conference by only providing Specifically, Fred is added to the conference by only providing
his SIP URI. Based upon the contact information provided for his SIP URI. Based upon the contact information provided for
Fred by Alice, the call signaling to add Fred to the conference Fred by Alice, the call signaling to add Fred to the conference
may be instigated through the Focus (e.g. if Fred had a "dial- may be instigated through the Focus (e.g., if Fred had a "dial-
out" method set as the target for him) at the actual activation out" method set as the target for him) at the actual activation
of the sidebar. of the sidebar.
4. The conference server sends a "sidebarByRefResponse" message and, 4. The conference server sends a "sidebarByRefResponse" message and,
depending upon the policies, the initiator of the request (i.e., depending upon the policies, the initiator of the request (i.e.,
Alice) and the participants in the sidebar (i.e., Bob and Ethel) Alice) and the participants in the sidebar (i.e., Bob and Ethel)
may be notified of his addition to the sidebar via the conference may be notified of his addition to the sidebar via the conference
notification service. notification service.
1. sidebarByRefRequest/create message (Alice creates an 1. sidebarByRefRequest/create message (Alice creates an
skipping to change at page 63, line 45 skipping to change at page 63, line 45
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
two participants, similarly to the example in Section 7.1. Unlike two participants, similarly to the example in Section 7.1. Unlike
the previous example, rather than using audio within the sidebar, the previous example, rather than using audio within the sidebar,
Alice could just add an additional text based media stream to the Alice could just add an additional text based media stream to the
sidebar in order to convey her textual messages to Bob, while still sidebar in order to convey her textual messages to Bob, while still
viewing and listening to the main conference. viewing and listening to the main conference.
In this scenario, Alice requests to the conferencing system the In this scenario, Alice requests to the conferencing system the
creation of a private chat room within the main conference context creation of a private chat room within the main conference context
(presented in Figure 19) in which the involved partecipants are just (presented in Figure 19) in which the involved participants are just
Bob and herself. This can be achieved through the following CCMP Bob and herself. This can be achieved through the following CCMP
transaction (Figure 23). transaction (Figure 23).
1. Alice forwards a sidebarByValRequest/create to the Conferencing 1. Alice forwards a sidebarByValRequest/create to the Conferencing
Control Server with the main conference XCON-URI in the Control Server with the main conference XCON-URI in the
"confObjID" parameter and the desired sidebar conference object "confObjID" parameter and the desired sidebar conference object
in the "sidebarByValInfo" field. In this way, a sidebar creation in the "sidebarByValInfo" field. In this way, a sidebar creation
using user-provided conference information is requested to the using user-provided conference information is requested to the
conferencing system. Please note that, unlike the previous conferencing system. Please note that, unlike the previous
sidebar examples, in this case a comnpletely new conference sidebar examples, in this case a completely new conference object
object to describe the sidebar is provided: there is no cloning to describe the sidebar is provided: there is no cloning
involved, while the "confObjID" still enforces the parent-child involved, while the "confObjID" still enforces the parent-child
relationship between the main conference and the to-be-created relationship between the main conference and the to-be-created
sidebar. sidebar.
2. The Conference Control Server, after checking Alice's rights and 2. The Conference Control Server, after checking Alice's rights and
validating the conference-object carried in the request, creates validating the conference-object carried in the request, creates
the required sidebar-by-val conference and a new XCON-URI for it. the required sidebar-by-val conference and a new XCON-URI for it.
Instead of cloning the main conference object, as shown in Instead of cloning the main conference object, as shown in
Section 7.1 and Section 7.2, the sidebar is created on the basis Section 7.1 and Section 7.2, the sidebar is created on the basis
of the user provided conference information. However, the parent of the user provided conference information. However, the parent
relationship between the main conference and the newly created relationship between the main conference and the newly created
sidebar is still mantained by the conferencing system (as a sidebar is still maintained by the conferencing system (as a
consequence of the chosen CCMP request message type - the consequence of the chosen CCMP request message type - the
sidebarByVal one) and it is reflected by the <sidebar-parent> sidebarByVal one) and it is reflected by the <sidebar-parent>
element in the "sidebarByValInfo" element returned in the element in the "sidebarByValInfo" element returned in the
sidebarByValResponse message. Please notice that, according to sidebarByValResponse message. Please notice that, according to
the CCMP specification, the return of the created sidebar data in the CCMP specification, the return of the created sidebar data in
this kind of "success" response is not mandatory. this kind of "success" response is not mandatory.
1. sidebarByValRequest/create message (Alice creates a private 1. sidebarByValRequest/create message (Alice creates a private
chat room between Bob and herself) chat room between Bob and herself)
skipping to change at page 70, line 35 skipping to change at page 70, line 35
conference, so that both Alice and the customer Carol hear the conference, so that both Alice and the customer Carol hear the
same audio from Bob. Alice sends a sidebarByRefRequest message same audio from Bob. Alice sends a sidebarByRefRequest message
with an "update" operation including the updated sidebar with an "update" operation including the updated sidebar
information. information.
3. Upon receipt of the sidebarByRefRequest message with an "update" 3. Upon receipt of the sidebarByRefRequest message with an "update"
operation, the conferencing system ensures that Alice has the operation, the conferencing system ensures that Alice has the
appropriate authority based on the policies associated with that appropriate authority based on the policies associated with that
specific conference object to perform the operation. In order to specific conference object to perform the operation. In order to
request the insertion of a further media stream in the sidebar request the insertion of a further media stream in the sidebar
(i.e. in this example an audio stream from Alice to Bob), the (i.e., in this example an audio stream from Alice to Bob), the
requestor has to provide a new <entry> element in the <available- requestor has to provide a new <entry> element in the <available-
media> field of the "sidebarByRefInfo". The mandatory "label" media> field of the "sidebarByRefInfo". The mandatory "label"
attribute of that new entry is filled with a dummy value attribute of that new entry is filled with a dummy value
"AUTO_GENERATE_1", but it will contain the real server-generated "AUTO_GENERATE_1", but it will contain the real server-generated
media stream identifier when the media stream is effectively media stream identifier when the media stream is effectively
allocated on the server side. Similarly, the mandatory "id" allocated on the server side. Similarly, the mandatory "id"
attribute in <media> element referring to the new sidebar audio attribute in <media> element referring to the new sidebar audio
stream under both Alice's and Bob's <endpoint> contains a stream under both Alice's and Bob's <endpoint> contains a
wildcard value, respectively "AUTO_GENERATE_2" and wildcard value, respectively "AUTO_GENERATE_2" and
"AUTO_GENERATE_3": those values will be replaced with the "AUTO_GENERATE_3": those values will be replaced with the
skipping to change at page 71, line 19 skipping to change at page 71, line 19
this call. this call.
1. sidebarByRefRequest/create message (Alice as coach creates a sidebar) 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID> <confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:sidebarByRefRequest/> <ccmp:sidebarByRefRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByRefResponse/create message (sidebar created) 2. sidebarByRefResponse/create message (sidebar created)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
skipping to change at page 73, line 24 skipping to change at page 73, line 24
</info:display-text> </info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:conference-state> <info:conference-state>
<info:active>false</info:active> <info:active>false</info:active>
</info:conference-state> </info:conference-state>
<info:users> <info:users>
<info:user entity="xcon-userid:Alice@example.com"> <info:user entity="xcon-userid:alice@example.com">
<info:endpoint entity="sip:Alice@example.com"> <info:endpoint entity="sip:alice@example.com">
<info:media id="AUTO_GENERATE_2"> <info:media id="AUTO_GENERATE_2">
<info:label>AUTO_GENERATE_1</info:label> <info:label>AUTO_GENERATE_1</info:label>
<info:status>sendonly</info:status> <info:status>sendonly</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</info:user> </info:user>
<info:user entity="xcon-userid:Bob@example.com"> <info:user entity="xcon-userid:bob@example.com">
<info:endpoint entity="sip:Bob@example.com"> <info:endpoint entity="sip:bob@example.com">
<info:media id="AUTO_GENERATE_3"> <info:media id="AUTO_GENERATE_3">
<info:label>AUTO_GENERATE_1</info:label> <info:label>AUTO_GENERATE_1</info:label>
<info:status>recvonly</info:status> <info:status>recvonly</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</info:user> </info:user>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial-in" <xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/> uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
skipping to change at page 75, line 15 skipping to change at page 75, line 15
Alice Bob Claire ConfS Alice Bob Claire ConfS
| | | | | | | |
|(1) userRequest(confUserID,| | |(1) userRequest(confUserID,| |
| confObjID, delete,| | | confObjID, delete,| |
| userInfo) | | | userInfo) | |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | | (a) Focus | | | | (a) Focus |
| | | tears down| | | | tears down|
| | | signaling | | | | signaling |
| | | to Bob | | | | to Bob |
| |<----------------------| | |<----------------------|
| | | | | |
| | (b)Deletes+---| | | (b)Deletes+---|
| | | Bob | | | | | Bob | |
| | | as a | | | | | as a | |
| | | user +-->| | | | user +-->|
| | | in | | | | in |
| | | confObj | | | | confObj |
| | | | | | | |
|(2) userResponse(confUserID,confObjID, | |(2) userResponse(confUserID,confObjID, |
skipping to change at page 76, line 5 skipping to change at page 76, line 5
authority based on the policies associated with that specific authority based on the policies associated with that specific
conference object to perform the operation. conference object to perform the operation.
2. Based upon the contact and media information in the conference 2. Based upon the contact and media information in the conference
object for Bob in the "userInfo" element, the conferencing system object for Bob in the "userInfo" element, the conferencing system
starts the process to remove Bob (e.g., the call signaling to starts the process to remove Bob (e.g., the call signaling to
remove Bob from the conference is instigated through the Focus). remove Bob from the conference is instigated through the Focus).
The conference server updates the data in the conference object, The conference server updates the data in the conference object,
thus removing Bob from the <users> list. After updating the thus removing Bob from the <users> list. After updating the
data, the conference server sends a userResponse message to data, the conference server sends a userResponse message to
Alice. Depending upon the policies, other participants (e.g. Alice. Depending upon the policies, other participants (e.g.,
"Claire") may be notified of the removal of Bob from the "Claire") may be notified of the removal of Bob from the
conference via the Conference Notification Service. conference via the Conference Notification Service.
1. userRequest/delete message (Alice deletes Bob): 1. userRequest/delete message (Alice deletes Bob):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
skipping to change at page 77, line 43 skipping to change at page 77, line 43
1. The conferencing system client "Alice" sends a confRequest 1. The conferencing system client "Alice" sends a confRequest
message with a "delete" operation to be performed on the message with a "delete" operation to be performed on the
conference identified by the XCON-URI carried in the "confObjID" conference identified by the XCON-URI carried in the "confObjID"
parameter. The conference server, on the basis of the parameter. The conference server, on the basis of the
"confUserID" included in the receipt request, ensures that Alice "confUserID" included in the receipt request, ensures that Alice
has the appropriate authority to fulfill the operation. has the appropriate authority to fulfill the operation.
2. After validating Alice's rights, the conferencing server 2. After validating Alice's rights, the conferencing server
instigates the process to delete the conference object, instigates the process to delete the conference object,
disconnetting participants and removing associated resources such disconnecting participants and removing associated resources such
as mixer instances. Then, the conference server returns a as mixer instances. Then, the conference server returns a
confResponse message to Alice with "200" as "response-code" and confResponse message to Alice with "200" as "response-code" and
the deleted conference XCON-URI in the "confObjID" field. the deleted conference XCON-URI in the "confObjID" field.
1. confRequest/delete message (Alice deletes a conference) 1. confRequest/delete message (Alice deletes a conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
skipping to change at page 79, line 10 skipping to change at page 79, line 10
10. Security Considerations 10. Security Considerations
The security considerations applicable to the implementation of these The security considerations applicable to the implementation of these
call flows are documented in the XCON Framework, with additional call flows are documented in the XCON Framework, with additional
security considerations documented in the CCMP document. Statements security considerations documented in the CCMP document. Statements
with regards to the necessary security are discussed in particular with regards to the necessary security are discussed in particular
flows, however, this is for informational purposes only. The flows, however, this is for informational purposes only. The
implementor is encouraged to carefully consider the security implementor is encouraged to carefully consider the security
requirements in the normative documents. requirements in the normative documents.
11. Change Summary 11. Acknowledgements
NOTE TO THE RFC-EDITOR: Please remove this section prior to
publication as an RFC.
The following are the major changes between the 02 and the 03
versions of the draft:
o updated the call flows in order to take into account the changes
on CCMP;
o added a completely new introductory section, addressing the
protocol in general, the data model constraints, transport-related
information, and notifications in a practical way;
o reorganized the chapters, grouping user-related scenarios in an
users section, and doing the same for sidebars;
o added more verbose text to almost every section of the document;
The following are the major changes between the 01 and the 02
versions of the draft:
o updated the call flows in order to take into account the new
versioning mechanism of the CCMP;
o clarified, per agreement in Stockholm, that cloning from a
blueprint does not need a cloning-parent to be made available in
the response;
o clarified that BFCP and CCMP-based media control are neither in
conflict nor one the wrapper of the other; they act at different
levels, and when both are involved, it is required that both grant
a resource before it can be used by an interested participant;
o changed all the domains involved in the flows to make them
compliant with [RFC2606];
o clarified that a successful creation of a new conference object
may or may not contain the whole confInfo object in the response;
in case it doesn't, a retrieve of the updated object can be
achieved by issuing a confRequest/retrieve;
o clarified that the scenario in Section 6.3 only involves CCMP in
adding the user to a conference; this includes requiring the use
of a password only in adding the user to the conference object;
the actual request for PIN/Password when joining thw conference is
handled by means of out-of-band mechanisms (in this case at the
media level, with the help of the MEDIACTRL framework);
o added and corrected Sidebars-related scenarios;
o added flows for some previously missing scenarios: Private
Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
Conference;
o
The following are the major changes between the 00 and the 01
versions of the draft:
o Updates to reflect change of CCMP to HTTP transport model.
The following are the major changes between the individual 01 version
to the WG 00:
o Updates to reflect most recent version of CCMP, including
parameter names, etc.
o Added protocol details to many of the examples.
o Editorial: Simplifying intro, terms, etc.
12. Acknowledgements
The detailed content for this document is derived from the prototype The detailed content for this document is derived from the prototype
work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
their colleagues at the University of Napoli. their colleagues at the University of Napoli.
13. References 12. Informative References
13.1. Normative References
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[I-D.ietf-xcon-ccmp] [I-D.ietf-xcon-ccmp]
Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", "Centralized Conferencing Manipulation Protocol",
draft-ietf-xcon-ccmp-11 (work in progress), October 2010. draft-ietf-xcon-ccmp-13 (work in progress), May 2011.
13.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
skipping to change at page 82, line 9 skipping to change at page 80, line 9
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-23 Conferencing (XCON)", draft-ietf-xcon-common-data-model-31
(work in progress), February 2011. (work in progress), June 2011.
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-call-flows]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
"Media Control Channel Framework (CFW) Call Flow "Media Control Channel Framework (CFW) Call Flow
Examples", draft-ietf-mediactrl-call-flows-05 (work in Examples", draft-ietf-mediactrl-call-flows-07 (work in
progress), October 2010. progress), July 2011.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media [RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009. Server Control", RFC 5567, June 2009.
[I-D.ietf-mediactrl-mixer-control-package] [I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework", Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-14 (work in draft-ietf-mediactrl-mixer-control-package-14 (work in
progress), January 2011. progress), January 2011.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
US USA
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Via Carlo Poerio 89/a Via Carlo Poerio 89/a
Napoli 80121 Napoli 80121
Italy Italy
Email: lorenzo@meetecho.com Email: lorenzo@meetecho.com
 End of changes. 49 change blocks. 
164 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/