draft-ietf-xcon-examples-03.txt   draft-ietf-xcon-examples-04.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational L. Miniero Intended status: Informational L. Miniero
Expires: August 21, 2010 Meetecho Expires: October 16, 2010 Meetecho
R. Presta R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
February 17, 2010 April 14, 2010
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-03 draft-ietf-xcon-examples-04
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 16, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 9
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4
5. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 6 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5
5.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 6 4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6
5.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 8 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
5.3. Conference Notifications . . . . . . . . . . . . . . . . . 11 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 13
6. Conference Creation . . . . . . . . . . . . . . . . . . . . . 15 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 13
6.1. Basic Conference Creation . . . . . . . . . . . . . . . . 15 5.2. Conference Creation using Blueprints . . . . . . . . . . . 18
6.2. Conference Creation using Blueprints . . . . . . . . . . . 20 5.3. Conference Creation using User-Provided Conference
6.3. Conference Creation using User-Provided Conference Information . . . . . . . . . . . . . . . . . . . . . . . 25
Information . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 30
6.4. Cloning an Existing Conference . . . . . . . . . . . . . . 32 6. Conference Users Scenarios and Examples . . . . . . . . . . . 33
7. Conference Users Scenarios and Examples . . . . . . . . . . . 35 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 34
7.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 36 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 37
7.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Conference Announcements and Recordings . . . . . . . . . 41
7.3. Conference Announcements and Recordings . . . . . . . . . 43 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45
7.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 47 6.5. Entering a password-protected conference . . . . . . . . . 45
7.5. Entering a password-protected conference . . . . . . . . . 47 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 47
8. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 49 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 48
8.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 50 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 57
8.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 59 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63
8.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 65 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67
8.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 69 8. Removing Participants and Deleting Conferences . . . . . . . . 74
9. Removing Participants and Deleting Conferences . . . . . . . . 76 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74
9.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 76 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77
9.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79
12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
14.1. Normative References . . . . . . . . . . . . . . . . . . . 83 13.2. Informative References . . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
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 4, line 25 skipping to change at page 3, line 25
Protocol (CCMP)[I-D.ietf-xcon-ccmp]. Protocol (CCMP)[I-D.ietf-xcon-ccmp].
Due to the broad range of functionality provided by the XCON Due to the broad range of functionality provided by the XCON
Framework and the flexibility of the CCMP messaging, these call flows Framework and the flexibility of the CCMP messaging, these call flows
should not be considered inclusive of all the functionality that can should not be considered inclusive of all the functionality that can
provided by the XCON Framework and protocol implementations. These provided by the XCON Framework and protocol implementations. These
flows represent a sample to provide an overview of the feature rich flows represent a sample to provide an overview of the feature rich
capabilities of the XCON framework and CCMP messaging for protocol capabilities of the XCON framework and CCMP messaging for protocol
developers, software developers and researchers. developers, software developers and researchers.
2. Conventions 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations. In this document, these key
words are used when describing normative functionality based on the
XCON Framework and CCMP.
Note that due to RFC formatting conventions, this document often
splits message details whose content would exceed 72 characters. A
backslash character marks where this line folding has taken place.
This backslash and its trailing CRLF and whitespace would not appear
in the actual protocol contents.
3. Terminology
This document uses the same terminology as found in the referenced This document uses the same terminology as found in the Media Control
documents, with the following terms and abbreviations used in the Architectural Framework [RFC5567] and Media Control Channel Framework
call flows. Also, note that the term "call flows" is used in a very Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the
generic sense in this document since the media is not limited to following terms and abbreviations used in the call flows. Also, note
voice. The calls supported by the XCON framework and CCMP can that the term "call flows" is used in a very generic sense in this
consist of media such as text, voice and video, including multiple document since the media is not limited to voice. The calls
media types in a single active conference. 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 Conference and Media Control Client (CMCC): as defined in the XCON
Framework. In the flows in this document, the CMCC is logically Framework. In the flows in this document, the CMCC is logically
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 "Conferencing Conferencing Server (ConfS): In this document, the "Conferencing
Server" term is used interchangeably with the term Application Server" term is used interchangeably with the term Application
Server (AS) as used in the Media Control Architectural Framework Server (AS) as used in the Media Control Architectural Framework
[RFC5567]. A Conferencing Server is intended to be able to act as [RFC5567]. A Conferencing Server is intended to be able to act as
a Conference Control Server, as defined in the XCON framework, a Conference Control Server, as defined in the XCON framework,
i.e. it is able to handle CCMP requests and issue CCMP responses. i.e. it is able to handle CCMP 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].
4. 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
intended to be a simple guide for the use of the Conference Control intended to be a simple guide for the use of the Conference Control
Protocol between the Conferencing Server and the Conference Control Protocol between the Conferencing Server and the Conference Control
Client. The objective is to provide an informational base reference Client. The objective is to provide an informational base reference
for protocol developers, software developers and researchers. for protocol developers, software developers and researchers.
This document focuses on the interaction between the Conference (and This document focuses on the interaction between the Conference (and
skipping to change at page 5, line 47 skipping to change at page 4, line 33
Additional scenarios have been added to provide examples of other Additional scenarios have been added to provide examples of other
real life scenarios that are anticipated to be supported by the real life scenarios that are anticipated to be supported by the
framework. With the exception of an initial example with media framework. With the exception of an initial example with media
control messaging, the examples do not include the details for the control messaging, the examples do not include the details for the
media control [I-D.ietf-mediactrl-mixer-control-package], call media control [I-D.ietf-mediactrl-mixer-control-package], call
signaling or binary floor control [RFC4582] protocols. This document signaling or binary floor control [RFC4582] protocols. This document
references the scenarios in the Media Control call flows references the scenarios in the Media Control call flows
[I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
[RFC4579] and binary floor control protocol documents. [RFC4579] and binary floor control protocol documents.
The rest of this document is organized as follows. Section 5 The rest of this document is organized as follows. Section 4
presents an overview on CCMP, together with some implementation- presents an overview on CCMP, together with some implementation-
related details and related matters like HTTP transport and related details and related matters like HTTP transport and
notifications. Section 6 presents the reader with examples showing notifications. Section 5 presents the reader with examples showing
the different approaches CCMP provides to create a new conference. the different approaches CCMP provides to create a new conference.
Section 7 more generally addresses the different user-related Section 6 more generally addresses the different user-related
manipulations that can be achieved by means of CCMP, by presenting a manipulations that can be achieved by means of CCMP, by presenting a
number of interesting scenarios. Section 8 addresses the several number of interesting scenarios. Section 7 addresses the several
scenarios that may involve the use of sidebars. Section 9 shows how scenarios that may involve the use of sidebars. Section 8 shows how
CCMP can be used to remove conferences and users from the system. CCMP can be used to remove conferences and users from the system.
Finally, Section 11 provides a few details for what concerns the Finally, IANA considerations are discussed in Section 9 while
Security Considerations when it comes to implementing CCMP. Section 10 provides a few details for what concerns the Security
Considerations when it comes to implementing CCMP.
5. Working with CCMP 4. Working with CCMP
This section aims at being a brief introduction to how the This section aims at being a brief introduction to how the
Centralized Conferencing Manipulation Protocol (CCMP) Centralized Conferencing Manipulation Protocol (CCMP)
[I-D.ietf-xcon-ccmp] works and how it can be transported across a [I-D.ietf-xcon-ccmp] works and how it can be transported across a
network. Some words will be spent to describe a typical CCMP network. Some words will be spent to describe a typical CCMP
interaction, by focusing on relevant aspects of the client-server interaction, by focusing on relevant aspects of the client-server
communication. Please notice that this section is by no means to be communication. Please notice that this section is by no means to be
considered as a replacement for the CCMP document, which remains a considered as a replacement for the CCMP document, which remains a
mandatory read before approaching the following sections. It is just mandatory read before approaching the following sections. It is just
conceived to help the reader take the first steps toward the actual conceived to help the reader take the first steps toward the actual
protocol interactions. protocol interactions.
First of all, some lines will be devoted to the protocol by itself in First of all, some lines will be devoted to the protocol by itself in
skipping to change at page 6, line 28 skipping to change at page 5, line 15
[I-D.ietf-xcon-ccmp] works and how it can be transported across a [I-D.ietf-xcon-ccmp] works and how it can be transported across a
network. Some words will be spent to describe a typical CCMP network. Some words will be spent to describe a typical CCMP
interaction, by focusing on relevant aspects of the client-server interaction, by focusing on relevant aspects of the client-server
communication. Please notice that this section is by no means to be communication. Please notice that this section is by no means to be
considered as a replacement for the CCMP document, which remains a considered as a replacement for the CCMP document, which remains a
mandatory read before approaching the following sections. It is just mandatory read before approaching the following sections. It is just
conceived to help the reader take the first steps toward the actual conceived to help the reader take the first steps toward the actual
protocol interactions. protocol interactions.
First of all, some lines will be devoted to the protocol by itself in First of all, some lines will be devoted to the protocol by itself in
Section 5.1, together with some recommendations from an Section 4.1, together with some recommendations from an
implementation point of view. In Section 5.2, instead, an effective implementation point of view. In Section 4.2, instead, an effective
CCMP interaction will be presented by exploiting HTTP as a transport. CCMP interaction will be presented by exploiting HTTP as a transport.
Finally, a few words will be spent on notifications in Section 5.3. Finally, a few words will be spent on notifications in Section 4.3.
Once done with these preliminary steps, some actual flows will be Once done with these preliminary steps, some actual flows will be
presented and described in detail in the sections to follow. presented and described in detail in the sections to follow.
5.1. CCMP and the Data Model 4.1. CCMP and the Data Model
CCMP is an XML-based protocol. It has been designed as a request/ CCMP is an XML-based protocol. It has been designed as a request/
response protocol. Besides, it is completely stateless, which means response protocol. Besides, it is completely stateless, which means
implementations can safely handle transactions indipendently from implementations can safely handle transactions independently from
each other. each other.
The protocol allows for the manipulation of conference objects and The protocol allows for the manipulation of conference objects and
related users. By manipulation it is implied, as the document related users. By manipulation it is implied, as the document
specifies, that a Conferencing Client (briefly CMCC in all the specifies, that a Conferencing Client (briefly CMCC in all the
following sections) can create, update and remove basically following sections) can create, update and remove basically
everything that is related to the objects handled by a conferencing everything that is related to the objects handled by a conferencing
system. This is reflected in the allowed operations (retrieve, system. This is reflected in the allowed operations (retrieve,
create, update, delete) and the specified request types (ranging from create, update, delete) and the specified request types (ranging from
the manipulation of blueprints and conferences to users and the manipulation of blueprints and conferences to users and
skipping to change at page 8, line 5 skipping to change at page 6, line 34
instance, a CMCC may be requesting the direct creation of a new instance, 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. Anyway, element uniquely identifying the conference to be in place. Anyway,
the CMCC has no way to a priori know what the entity will be like, the CMCC has no way to a priori know what the entity will be like,
considering it will only be generated by the ConfS after the request. considering it will only be generated by the ConfS after the request.
For scenarios like this one, the CCMP specification envisages the use For scenarios like this one, the CCMP specification envisages the use
of a dedicated placeholder wildcard to make the conference object of a dedicated placeholder wildcard to make the conference object
compliant with the Data Model: the wildcard would then be replaced by compliant with the Data Model: the wildcard would then be replaced by
the ConfS with the right value. the ConfS with the right value.
5.2. Using HTTP as a transport 4.2. Using HTTP as a transport
[I-D.ietf-xcon-ccmp] presents several ways by which CCMP requests and CCMP requests and responses can be transported from a client to a
responses can be transported from a client to a server and viceversa. server and viceversa through several ways, being the protocol
Nevertheless, more focus is given on HTTP as a solution for this specification agnostic with respect to the transport in use. In
[I-D.ietf-xcon-ccmp], focus is given on HTTP as a solution for this
transport matter, and a whole chapter is devoted in the document to transport matter, and a whole chapter is devoted in the document to
how HTTP can be used for it. This document is agnostic with respect how HTTP can be used for it. The following lines will provide a
to the transport in use: this means that all the call flows herein brief explanation, from a more practical point of view, of how HTTP
presented will just show the CCMP interactions, without talking about might be exploited to carry CCMP messages. In this document,
how the messages could have gone across the network. Nevertheless, however, all the call flows herein presented will just show the CCMP
the following lines will provide a brief explanation, from a more interactions, without talking about how the messages could have gone
practical point of view, of how HTTP might be exploited to carry CCMP across the network.
messages.
In case HTTP is used as a transport, the specification is very clear In case HTTP is used as a transport, the specification is very clear
with respect to how the interaction has to occur. Specifically, a with respect to how the interaction has to occur. Specifically, a
CMCC is assumed to send his request as part of an HTTP POST message, CMCC is assumed to send his request as part of an HTTP POST message,
and the Server would reply by means of an HTTP 200 message. In both and the ConfS would reply by means of an HTTP 200 message. In both
cases, the HTTP messages would have the CCMP messages as payload, cases, the HTTP messages would have the CCMP messages as payload,
which would be reflected in the Content-Type message. Figure 1 which would be reflected in the Content-Type message. Figure 1
presents a ladder diagram of such interaction, which is followed by a presents a ladder diagram of such interaction, which is followed by a
dump of the exchanged HTTP messages for further analysis: dump of the exchanged HTTP messages for further analysis:
CMCC ConfS CMCC ConfS
| | | |
| 1. HTTP POST (CCMP request) | | 1. HTTP POST (CCMP request) |
|--------------------------------------------->| |--------------------------------------------->|
| | | |
skipping to change at page 11, line 34 skipping to change at page 10, line 17
replied with a 'blueprintResponse' element. This element includes a replied with a 'blueprintResponse' element. This element includes a
complete dump of the conference object (compliant with the Data complete dump of the conference object (compliant with the Data
Model) describing the requested blueprint, together with an element Model) describing the requested blueprint, together with an element
addressing the result of the client's request (response- addressing the result of the client's request (response-
code=success). code=success).
This section won't delve in additional details for what concerns this This section won't delve in additional details for what concerns this
interaction. It is just worth noticing that this was the example of interaction. It is just worth noticing that this was the example of
the simplest CCMP communication that could take place between a CMCC the simplest CCMP communication that could take place between a CMCC
and a ConfS, a blueprintRequest: this scenario will be described in and a ConfS, a blueprintRequest: this scenario will be described in
more detail in Section 6.2. more detail in Section 5.2.
5.3. Conference Notifications 4.3. Conference Notifications
[RFC5239] presents several different possible protocol interactions [RFC5239] presents several different possible protocol interactions
between a conferencing server and a conferencing client. One of between a conferencing server and a conferencing client. One of
those interactions is generically called "Notification Protocol", those interactions is generically called "Notification Protocol",
implementing a notification service for all clients interested in implementing a notification service for all clients interested in
being informed by the server whenever something relevant happens in a being informed by the server whenever something relevant happens in a
conference. While at first glance it may appear that such a conference. While at first glance it may appear that such a
functionality should belong to a conference control protocol, such functionality should belong to a conference control protocol, such
feature has been specifically marked as out of scope in CCMP. As a feature has been specifically marked as out of scope in CCMP. As a
consequence, CCMP has been conceived as a request/answer protocol, consequence, CCMP has been conceived as a request/answer protocol,
skipping to change at page 13, line 34 skipping to change at page 11, line 38
| | 5. SIP NOTIFY (changes) | | | 5. SIP NOTIFY (changes) |
| |-------------------------->| | |-------------------------->|
| | 6. SIP 200 OK | | | 6. SIP 200 OK |
| |<--------------------------| | |<--------------------------|
| | | | | |
. . . . . .
. . . . . .
Figure 2: XCON Event Package: SIP notifications Figure 2: XCON Event Package: SIP notifications
While simple and effective, this solution has a drawback: it assumes
that all clients to be notified have a SIP stack. In fact, the
approach relies on the SIP SUBSCRIBE/NOTIFY mechanism. This means
that a client without a SIP stack would be unable to receive
notifications, in case no other means were available. Of course this
is not a desired situation in a framework as XCON which has been
conceived as being protocol-agnostic.
Considering CCMP is going to be probably most often deployed on HTTP, Considering CCMP is going to be probably most often deployed on HTTP,
another way to achieve notifications might be by exploiting some sort another way to achieve notifications might be by exploiting some sort
of HTTP callbacks, as suggested in the CCMP specification itself. of HTTP callbacks, as suggested in the CCMP specification itself.
This would allow to overcome the previous limitation, since both the This would allow to overcome the previous limitation, since both the
CMCC and the ConfS would already have an HTTP stack to make use of. CMCC and the ConfS would already have an HTTP stack to make use of.
Using this approach, an interested web client might provide the Using this approach, an interested web client might provide the
Conferencing System with an URL to contact whenever updates are Conferencing System with an URL to contact whenever updates are
available: the update could be part of the notification message available: the update could be part of the notification message
itself, or it could be only implicitly referenced by the itself, or it could be only implicitly referenced by the
notification. At the same time, alternative notification means could notification. At the same time, alternative notification means could
be exploited, e.g. by taking advantage of functionality provided by be exploited, e.g. by taking advantage of functionality provided by
other protocols as XMPP. Figure 3 shows an example of different other protocols such as XMPP. Figure 3 shows an example of different
subscriptions which accordingly trigger notifications after the same subscriptions which accordingly trigger notifications after the same
relevant event happens. relevant event happens.
CMCC ConfS Sub1 Sub2 CMCC ConfS Sub1 Sub2
| | | | | | | |
| | 1. Register callback | | | | 1. Register callback | |
| |<--------------------------| | | |<--------------------------| |
| Handle +--| | | | Handle +--| | |
| new HTTP | | | | | new HTTP | | | |
| subscription +->| 2. Acknlowledge | | | subscription +->| 2. Acknlowledge | |
skipping to change at page 15, line 9 skipping to change at page 13, line 8
. . . . . . . .
Figure 3: Alternative means for notifications Figure 3: Alternative means for notifications
That said, there are actually many other ways to achieve That said, there are actually many other ways to achieve
notifications in a conferencing system. A conferencing system may notifications in a conferencing system. A conferencing system may
rely on several other solutions than the ones presented as periodic rely on several other solutions than the ones presented as periodic
checks of a well known URL by interested clients, long polls, BOSH- checks of a well known URL by interested clients, long polls, BOSH-
based communications, Atom/RSS feeds and the like. based communications, Atom/RSS feeds and the like.
6. Conference Creation 5. Conference Creation
This section starts the sequence of call flows of typical XCON- This section starts the sequence of call flows of typical XCON-
related scenarios provided in this document. Specifically, it related scenarios provided in this document. Specifically, it
provides details associated with the various ways in which a provides details associated with the various ways in which a
conference can be created using CCMP and the XCON framework 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 6.1 provides the details of the media the first example Section 5.1 provides the details of the media
control messaging along with an example of the standard annotation control messaging along with an example of the standard annotation
used throughout the remainder of this document. In subsequent flows, used throughout the remainder of this document. In subsequent flows,
only this annotation (identified by lower case letters) is included only this annotation (identified by lower case letters) is included
and the reader is encouraged to refer to the call flows in the and the reader is encouraged to refer to the call flows in the
relevant documents for details about the other protocols. The relevant documents for details about the other protocols. The
annotations for the call signaling are on the left side of the annotations for the call signaling are on the left side of the
conferencing server vertical bar and those for the media control conferencing server vertical bar and those for the media control
messaging are on the right side. messaging are on the right side.
6.1. Basic Conference Creation 5.1. Basic Conference Creation
The simplest manner in which a conference can be created is The simplest manner in which a conference can be created is
accomplished by the client sending a "confRequest" message with the accomplished by the client sending a "confRequest" message with the
"create" operation as the only parameter to the conference server, "create" operation as the only parameter to the conference server,
together with the "confUserID" associated with the requesting client together with the "confUserID" associated with the requesting client
itself. This results in the creation of a default conference, with itself. This results in the creation of a default conference, with
an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
in the form of the "confUserID" parameter (the same already present in the form of the "confUserID" parameter (the same already present
in the request) and the data for the conference object in the in the request) and the data for the conference object in the
"confInfo" parameter all returned in the "confResponse" message. "confInfo" parameter all returned in the "confResponse" message.
skipping to change at page 20, line 28 skipping to change at page 18, line 28
method="dial-out"/> method="dial-out"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 6: Create Basic Conference (Annotated) Detailed Messaging Figure 6: Create Basic Conference (Annotated) Detailed Messaging
6.2. Conference Creation using Blueprints 5.2. Conference Creation using Blueprints
The previous example showed the creation of a new conference using The previous example showed the creation of a new conference using
default values. This means the client provided no information about default values. This means the client provided no information about
how she wanted the conference to be like. Anyway, the XCON framework how she wanted the conference to be like. Anyway, the XCON framework
(and CCMP as a consequence) allows for the exploitation of templates. (and CCMP as a consequence) allows for the exploitation 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 except for the actual conference objects with pre-defined settings except for the actual
identifiers. This means that a client might get one of these identifiers. This means that a client might get one of these
blueprints, choose the one that more fits his needs, and use the blueprints, choose the one that more fits his needs, and use the
chosen blueprint to create a new conference. chosen blueprint to create a new conference.
skipping to change at page 22, line 19 skipping to change at page 20, line 19
1. Alice first sends a "blueprintsRequest" message to the 1. Alice first sends a "blueprintsRequest" message to the
conferencing system identified by the conference server discovery conferencing system identified by the conference server discovery
process. This request contains the "confUserID" of the user process. This request contains the "confUserID" of the user
issuing the request (Alice's XCON-USERID) and the "xpathFilter" issuing the request (Alice's XCON-USERID) and the "xpathFilter"
parameter by which Alice specifies she desires to obtain only parameter by which Alice specifies she desires to obtain only
blueprints providing support for both audio and video: for this blueprints providing support for both audio and video: for this
purpose, the xpath query contained in this field is: "/ purpose, the xpath query contained in this field is: "/
conference-info[conference-description/available-media/entry/ conference-info[conference-description/available-media/entry/
type='audio' and conference-description/available-media/entry/ type='audio' and conference-description/available-media/entry/
type='video'"] . Upon receipt of the "blueprintsRequest", the type='video'"] . Upon receipt of the "blueprintsRequest", the
conferencing system would first authenticate Alice and then conferencing system would first control, on the basis of the
ensure that Alice has the appropriate authority based on system "confUserID" parameter, that Alice has the appropriate authority
policies to receive the requested kind of blueprints supported by based on system policies to receive the requested kind of
that system. blueprints supported by that system.
2. All blueprints that Alice is authorized to use are returned in a 2. All blueprints that Alice is authorized to use are returned in a
"blueprintsResponse" message in the "blueprintsInfo" element. "blueprintsResponse" message in the "blueprintsInfo" element.
3. Upon receipt of the "blueprintsResponse" containing the 3. Upon receipt of the "blueprintsResponse" containing the
blueprints, Alice determines which blueprint to use for the blueprints, Alice determines which blueprint to use for the
conference to be created. Alice sends a "blueprintRequest" conference to be created. Alice sends a "blueprintRequest"
message to get the specific blueprint as identified by the message to get the specific blueprint as identified by the
"confObjID". "confObjID".
4. The conferencing system returns the "confInfo" associated with 4. The conferencing system returns the "confInfo" associated with
the specific blueprint as identified by the 'confObjID' in the the specific blueprint as identified by the "confObjID" in the
"blueprintResponse" message. "blueprintResponse" message.
5. Alice finally sends a "confRequest" with a "create" operation to 5. Alice finally sends a "confRequest" with a "create" operation to
the conferencing system to create a conference reservation the conferencing system to create a conference reservation
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) 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="xcon:ccmp-blueprints-request-message-type"> xsi:type="xcon:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:blueprintsRequest> <ccmp:blueprintsRequest>
<xpathFilter>/conference-info[ <xpathFilter>/conference-info[conference-description/
conference-description/available-media/entry/type='audio' and available-media/entry/type='audio' and
conference-description/available-media/entry/type='video'] conference-description/available-media/entry/type='video']
</xpathFilter> </xpathFilter>
</ccmp:blueprintsRequest> </ccmp:blueprintsRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintsResponse message (the server provides a descriptions of 2. blueprintsResponse message (the server provides a descriptions of
the available blueprints) the available blueprints fitting Alice's request)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
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">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
skipping to change at page 25, line 27 skipping to change at page 23, line 27
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor id="audioLabel"></xcon:floor>
<xcon:floor id="videoLabel"></xcon:floor> <xcon:floor id="videoLabel"></xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</blueprintInfo> </blueprintInfo>
</ccmp:blueprintResponse> </ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
5. confRequest/create message (Alice clones the "AudioRoom" blueprint) 5. confRequest/create message (Alice clones the "VideoRoom" blueprint)
<?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 <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
skipping to change at page 27, line 13 skipping to change at page 25, line 13
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 8: Create Conference (Blueprint) Detailed Messaging Figure 8: Create Conference (Blueprint) Detailed Messaging
6.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 how the conference object should look like, completely describe how the conference object should look like,
without just relying on defaults or blueprints: i.e. which media without just relying on defaults or blueprints: i.e. which media
skipping to change at page 27, line 35 skipping to change at page 25, line 35
join, any scheduling-related information and so on. This can be join, any scheduling-related information and so on. This can be
done, as anticipated, by providing in the creation request a full done, as anticipated, by providing in the creation request a full
conference object for the server to parse. conference object for the server to parse.
This "confInfo" parameter must comply of course with the Data Model This "confInfo" parameter must comply of course with the Data Model
specification. This means that its "entity" attribute is mandatory, specification. This means that its "entity" attribute is mandatory,
and cannot be missing in the document. Nevertheless, considering in and cannot be missing in the document. Nevertheless, considering in
this example the client is actually requesting the creation of a new this example the client is actually requesting the creation of a new
conference, which doesn't exist yet, this "entity" attribute cannot conference, which doesn't exist yet, this "entity" attribute cannot
be set to a valid value. This is related to an issue already be set to a valid value. This is related to an issue already
anticipated in Section 5.1. To cope with this, the CCMP protocol anticipated in Section 4.1. To cope with this, the CCMP protocol
fosters the use of a wildcard placeholder: this placeholder fosters the use of a wildcard placeholder: this placeholder
("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim
of making the "confInfo" element compliant with the Data Model, and of making the "confInfo" element compliant with the Data Model, and
would subsequently be replaced by the conferencing system with the would subsequently be replaced by the conferencing system with the
actual value. This means that, as soon as the conferencing system actual value. This means that, as soon as the conferencing system
actually creates the conference, a valid "entity" value is created actually creates the conference, a valid "entity" value is created
for it as well, which would take the place of the wildcard when for it as well, which would take the place of the wildcard when
completing the actual conference object provided by the client. completing the actual conference object provided by the client.
To give a flavour of what could be added to the conference object, we To give a flavour of what could be added to the conference object, we
skipping to change at page 32, line 13 skipping to change at page 30, line 13
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID> <confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success<response-code> <response-code>success<response-code>
<version>1</version> <version>1</version>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 10: Create Basic Conference Detailed Messaging Figure 10: Create Basic Conference Detailed Messaging
6.4. Cloning an Existing Conference 5.4. Cloning an Existing Conference
A client can also create another conference by cloning an existing A client can also create another conference by cloning an existing
conference, such as an active conference or conference reservation. conference, such as an active conference or conference reservation.
This approach can be seen as a logical extension of the creation of a 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 new conference using a blueprint: the difference is that, instead of
cloning the pre-defined settings listed in a blueprint, the settings cloning the pre-defined settings listed in a blueprint, the settings
of an existing conference would be cloned. of an existing conference would be cloned.
In this example, the client sends a "confRequest" message with the In this example, the client sends a "confRequest" message with the
"create" operation, along with the "confUserID" and a specific "create" operation, along with the "confUserID" and a specific
"confObjID", from which a new conference is to be created by cloning "confObjID", from which a new conference is to be created by cloning
an existing conference. an existing conference.
An example of how a client can create a conference based on a An example of how a client can create a conference based on a
blueprint is provided in Section 6.2. The manner by which a client blueprint is provided in Section 5.2. The manner by which a client
in this example might learn about a conference reservation or active in this example might learn about a conference reservation or active
conferences is similar to the first step in the blueprint example, conferences is similar to the first step in the blueprint example,
with the exception of specifying querying for different types of with the exception of specifying querying for different types of
conference objects supported by the specific conferencing system. conference objects supported by the specific conferencing system.
For example, in this example, the client clones a conference For example, in this example, the client clones a conference
reservation (i.e., an inactive conference). reservation (i.e., an inactive conference).
If the conferencing system can support a new instance of the specific If the conferencing system can support a new instance of the specific
type of conference (capabilities, etc.), then the request results in 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 the creation of a conference, with an XCON-URI in the form of a new
skipping to change at page 35, line 41 skipping to change at page 33, line 41
<xcon:floor id="11"/> <xcon:floor id="11"/>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 12: Create Basic Conference (Clone) Detailed Messaging Figure 12: Create Basic Conference (Clone) Detailed Messaging
7. Conference Users Scenarios and Examples 6. Conference Users Scenarios and Examples
Section 6 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 instead focuses conference might be created using CCMP. This section instead focuses
on user-related scenarios, i.e. typical scenarios that may occur on user-related scenarios, i.e. typical scenarios that may occur
during the lifetime of a conference, like adding new users and during the lifetime of a conference, like adding new users and
handling their media. The following scenarios are based on those handling their media. The following scenarios are based on those
documented in the XCON framework. The examples assume that a documented in the XCON framework. The examples assume that a
conference has already been correctly established, with media, if conference has already been correctly established, with media, if
applicable, per one of the examples in Section 6. applicable, per one of the examples in Section 5.
7.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,
which means Alice also needs to provide some details about him. In 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 fact, the case of Bob already present as a user in the conferencing
system is much easier to address, and will be discussed later on. system is much easier to address, and will be discussed later on.
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS CMCC1 CMCC2 CMCCx ConfS
| | | | | | | |
skipping to change at page 37, line 22 skipping to change at page 35, line 22
Alice would just have referenced him through his XCON-USERID in Alice would just have referenced him through his XCON-USERID in
the "entity" attribute of the "userInfo" field, without providing the "entity" attribute of the "userInfo" field, without providing
additional data. In fact, that data (including, for instance, additional data. In fact, that data (including, for instance,
Bob's SIP-URI to be used subsequently for dial-out) would be Bob's SIP-URI to be used subsequently for dial-out) would be
obtained by referencing the extant registration. The conference obtained by referencing the extant registration. The conference
server ensures that Alice has the appropriate authority based on server ensures that Alice has the appropriate authority based on
the policies associated with that specific conference object to the policies associated with that specific conference object to
perform the operation. As mentioned before, a new Conference perform the operation. As mentioned before, a new Conference
User Identifier is created for Bob, and the "userInfo" is used to User Identifier is created for Bob, and the "userInfo" is used to
update the conference object accordingly. As already seen in update the conference object accordingly. As already seen in
Section 6.3, a placeholder wildcard Section 5.3, a placeholder wildcard
("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages
below) is used for the "entity" attribute of the "userInfo" below) is used for the "entity" attribute of the "userInfo"
element, to be replaced by the actual XCON-USERID later on; element, to be replaced by the actual XCON-USERID later on;
2. Bob is successfully added to the conference object, and an XCON- 2. Bob is successfully added to the conference object, and an XCON-
USERID is allocated for him ("xcon-userid:Bob@example.com"); this USERID is allocated for him ("xcon-userid:Bob@example.com"); this
identifier is reported in the response as part of the "entity" identifier is reported in the response as part of the "entity"
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. We again conference is instigated through the Focus as well. We again
remind that this is implementation specific. In fact, a remind that 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 5.3). Section 4.3).
To conclude the overview on this scenario, once Bob has been To conclude the overview on this scenario, once Bob has been
successfully added to the specified conference, per updates to the successfully added to the specified conference, per updates to the
state, and depending upon the policies, other participants state, and depending upon the policies, other participants
(including Bob himself) may be notified of the addition of Bob to (including Bob himself) may be notified of the addition of Bob to
the conference via the Conference Notification Service in use. the conference via the Conference Notification Service in use.
1. userRequest/create message (Alice adds Bob) 1. userRequest/create message (Alice adds Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
skipping to change at page 39, line 18 skipping to change at page 37, line 18
<info:endpoint entity="sip:bob83@example.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userResponse> </ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 14: Add Party Message Details Figure 14: Add Party Message Details
7.2. Muting a Party 6.2. Muting a Party
This section provides an example of the muting of a party in an 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 active conference. We assume that the user to mute has already been
added to the conference. The document only addresses muting and not added to the conference. The document only addresses muting, since
unmuting as well, since it would involve an almost identical CCMP unmuting would involve an almost identical CCMP message flow.
message flow anyway. Although, in case that any external floor
control is involved, whether or not a particular conference client
can actually mute/unmute itself must be considered by the
conferencing system.
Please notice that interaction between CCMP and floor control Please notice that interaction between CCMP and an ad-hoc designed
should be carefully considered. In fact, handling CCMP- and BFCP- floor control solution like BFCP should be carefully considered.
based media control has to be considered as multiple layers: i.e., Indeed, CCMP- and BFCP-based media control can be viewed as two
a participant may have the BFCP floor granted, but be muted by alternative and potentially interfering solutions for what
means of CCMP. If so, he would still be muted in the conference, concerns floor control actions. As an example, a participant may
and would only be unmuted if both the protocols allowed for this. 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 protocols allowed for this. In general, the
interaction between these potentially conflicting protocols falls
in the wider scope of policy control at the overall system's level
and is not the subject of this document.
Figure 15 provides an example of one client, "Alice", impacting the Figure 15 provides an example of one client, "Alice", impacting the
media state of another client, "Bob". This example assumes an media state of another client, "Bob". This example assumes an
established conference. In this example, Alice, whose role is established conference. In this example, Alice, whose role is
"moderator" of the conference, wants to mute Bob on a medium-size "moderator" of the conference, wants to mute Bob on a medium-size
multi-party conference, as his device is not muted (and he's multi-party conference, as his device is not muted (and he's
obviously not listening to the call) and background noise in his obviously not listening to the call) and background noise in his
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.
From a protocol point of view, muting/unmuting an user basically From a protocol point of view, muting/unmuting an user basically
consists in updating the conference object by modifying the settings consists in updating the conference object by modifying the settings
related to the target user's media streams. Specifically, Bob's related to the target user's media streams. Specifically, Bob's
"userInfo" must be updated by modifying its audio <endpoint> "userInfo" must be updated by modifying its audio <endpoint>
information (e.g. setting it to "recvonly" in case of muting), information (e.g. setting it to "recvonly" in case of muting),
identified by the right media id. identified by the right media id.
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS MS CMCC1 CMCC2 CMCCx ConfS MS
| | | | | | | | | |
|(1) userRequest(confUserID,| | | |(1) userRequest(subject, | | |
| confObjID, update, | | | | confUserID,confObjID, | | |
| userInfo) | | | | | update,userInfo) | | |
| | | | |
|--------------------------------------->| | |--------------------------------------->| |
| | | | Mute Bob | | | | | Mute Bob |
| | | |----------------->| | | | |----------------->|
| | | | 200 OK | | | | | 200 OK |
| | | |<-----------------| | | | |<-----------------|
| | | | | | | | | |
| |<====== XXX Bob excluded from mix XXX ====>| | |<====== XXX Bob excluded from mix XXX ====>|
| | | | | | | | | |
| | (a) Update +---| | | | (a) Update +---| |
| | Bob in | | | | | Bob in | | |
skipping to change at page 40, line 41 skipping to change at page 38, line 43
| | |<-----------| | | | |<-----------| |
| | | | | | | | | |
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
Figure 15: Client Manipulation of Conference - Mute a party Figure 15: 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 set to "revconly". The Conference Server ensures that Alice Bob's <endpoint> set to "revconly". In order to authenticate
has the appropriate authority based on the policies associated herself, Alice provides in the "subject" request parameter her
with that specific conference object to perform the operation and registration credentials (i.e. username and password). The
updates the "userInfo" in the conference object reflecting that "subject" parameter is an optional one: its use can be systematic
Bob's media is not to be mixed with the conference media. In whenever the conferencing server envisages to authenticate each
case the Conference Server relies on a remote Media Server for requestor. In such cases, if the client does not provide the
its multimedia functionality, it subsequently changes Bob's media required authentication information, the conferencing server
profile accordingly by means of the related protocol interaction answers with a CCMP "authenticationRequired" response message,
with the MS to enforce the decision. An example describing a indicating that the request cannot be processed without including
possible way of dealing with such a situation using the Media the proper "subject" parameter. The Conference Server ensures
Server Control architecture is described in that Alice has the appropriate authority based on the policies
associated with that specific conference object to perform the
[I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework operation. It recognizes that Alice is allowed to request the
Transactions (2)". 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. In case 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 to enforce the
decision. An example describing a possible way of dealing with
such a situation using the Media Server Control architecture is
described in [I-D.ietf-mediactrl-call-flows], at "Simple
Bridging: Framework Transactions (2)".
2. A userResponse message with a response-code of "success" is then 2. A userResponse message with a response-code of "success" is then
sent to Alice. Depending upon the policies, the conference sent to Alice. Depending upon the policies, the conference
server may notify other participants (including Bob) of this server may notify other participants (including Bob) of this
update via any Conference Notification Service that may be in update via any Conference Notification Service that may be in
use. use.
1. userRequest/update message (Alice mutes Bob) 1. userRequest/update message (Alice mutes Bob)
<?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-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<subject>
<username>Alice83</username>
<password>13011983</password>
</subject>
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"> <userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@example.com"> <info:endpoint entity="sip:bob83@example.com">
<info:media id="1"> <info:media id="1">
<info:label>123</info:label> <info:label>123</info:label>
<info:status>recvonly</info:status> <info:status>recvonly</info:status>
</info:media> </info:media>
skipping to change at page 43, line 5 skipping to change at page 41, line 5
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>7</version> <version>7</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 16: Mute Message Details Figure 16: Mute Message Details
7.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, that are public announcements (e.g. to notify conferencing system, that are 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 7.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 the several components of interesting scenario to address to see how the several components of
an XCON-compliant architecture interact with each other to make it an XCON-compliant architecture interact with each other to make it
happen. happen.
In this example, as shown in Figure 17 Alice is joining Bob's In this example, as shown in Figure 17 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
speak her name so it can be recorded. When Alice is added to the 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 active conference, the recording is played back to all the existing
participants. A very similar example is presented in Figure 33 of participants. A very similar example is presented in Figure 33 of
skipping to change at page 47, line 6 skipping to change at page 45, line 6
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:bobConf@example.com</confObjID> <confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>5</version> <version>5</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 18: Announcement Messaging Details Figure 18: Announcement Messaging Details
7.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 17. A typical way for the conferencing elements, is shown in Figure 17. A typical way for the conferencing
system to be aware of all the DTMF interactions within the context of system to be aware of all the DTMF interactions within the context of
conferences it is responsible for, is making use of the MEDIACTRL conferences it is responsible for, is making use of the MEDIACTRL
architecture for what regards media manipulation. Examples in that architecture for what regards media manipulation. Examples in that
sense (specifically for what concerns DTMF interception in conference sense (specifically for what concerns DTMF interception in conference
instances) are presented in [I-D.ietf-mediactrl-call-flows]. instances) are presented in [I-D.ietf-mediactrl-call-flows].
7.5. Entering a password-protected conference 6.5. Entering a password-protected conference
Some conferences may envision a password to be provided by a user who Some conferences may envision a password to be provided by a user who
wants to manipulate the relative conference objects (e.g. join, wants to manipulate the relative conference objects (e.g. join,
update, delete) via CCMP. Such a password would be included in the update, delete) via CCMP. Such 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 apposite "conference-password" field in the CCMP request the apposite "conference-password" field in the CCMP request
addressed to that conference. addressed to that conference.
In the following CCMP transactions, it is depicted a scenario in In the following CCMP transactions, it is depicted a scenario in
skipping to change at page 49, line 39 skipping to change at page 47, line 39
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>10</version> <version>10</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 19: Password-protected conference join messages details Figure 19: Password-protected conference join messages details
8. Sidebars Scenarios and Examples 7. Sidebars Scenarios and Examples
While creating conferences and manipulating users and their media may While creating conferences and manipulating users and their media may
be considered enough for many scenarios, there may be cases when a be considered enough for many scenarios, there may be cases when a
more complex management is needed. more complex management is needed.
In fact, a feature typically required in conferencing systems is the In fact, a feature typically required in conferencing systems is the
ability to create sidebars. A sidebar is basically a child ability to create sidebars. A sidebar is basically a child
conference that usually includes a subset of the participants of the conference that usually includes a subset of the participants of the
parent conference, and a subset of its media as well. Sidebars are parent conference, and a subset of its media as well. Sidebars are
typically required whenever some of the participants in a conference typically required whenever some of the participants in a conference
want to discuss privately about something, without interfering with want to discuss privately about something, without interfering with
the main conference. the main conference.
This section deals with some scenarios that typically envisage the This section deals with some scenarios that typically envisage the
use of a sidebar, like whispering, private messages and coaching use of a sidebar, like whispering, private messages and coaching
scenarios. The first subsections, anyway, present some examples of scenarios. The first subsections, anyway, present some examples of
how a generic sidebar can be created, configured and managed. how a generic sidebar can be created, configured and managed.
8.1. Internal Sidebar 7.1. Internal Sidebar
Figure 20 provides an example of one client, "Alice", involved in an Figure 20 provides an example of one client, "Alice", involved in an
active conference with "Bob" and "Carol". Alice wants to create a active conference with "Bob" and "Carol". Alice wants to create a
sidebar to have a side discussion with Bob while still viewing the sidebar to have a side discussion with Bob while still viewing the
video associated with the main conference. Alternatively, the audio video associated with the main conference. Alternatively, the audio
from the main conference could be maintained at a reduced volume. from the main conference could be maintained at a reduced volume.
Alice initiates the sidebar by sending a request to the conferencing Alice initiates the sidebar by sending a request to the conferencing
system to create a conference reservation based upon the active system to create a conference reservation based upon the active
conference object. Alice and Bob would remain on the roster of the conference object. Alice and Bob would remain on the roster of the
main conference, such that other participants could be aware of their main conference, such that other participants could be aware of their
skipping to change at page 59, line 23 skipping to change at page 57, line 23
<confObjID>xcon:8974545@example.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>3</version> <version>3</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Internal Sidebar Messaging Details Figure 22: Internal Sidebar Messaging Details
8.2. External Sidebar 7.2. External Sidebar
Figure 23 provides an example of a different approach towards Figure 23 provides an example of a different approach towards
sidebar. In this scenario, one client, "Alice", is involved in an sidebar. In this scenario, one client, "Alice", is involved in an
active conference with "Bob", "Carol", "David" and "Ethel". Alice active conference with "Bob", "Carol", "David" and "Ethel". Alice
gets an important text message via a whisper from Bob that a critical 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 customer needs to talk to Alice, Bob and Ethel. Alice creates a
sidebar to have a side discussion with the customer "Fred" including sidebar to have a side discussion with the customer "Fred" including
the participants in the current conference with the exception of the participants in the current conference with the exception of
Carol and David, who remain in the active conference. The difference Carol and David, who remain in the active conference. The difference
from the previous scenario is that Fred is not part of the parent from the previous scenario is that Fred is not part of the parent
skipping to change at page 65, line 33 skipping to change at page 63, line 33
<confObjID>xcon:8971212@example.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>2</version> <version>2</version>
<ccmp:sidebarByRefResponse/> <ccmp:sidebarByRefResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 24: External Sidebar Messaging Details Figure 24: External Sidebar Messaging Details
8.3. Private Messages 7.3. Private Messages
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 8.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 21) in which the involved partecipants are just (presented in Figure 21) in which the involved partecipants 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 25). transaction (Figure 25).
skipping to change at page 66, line 17 skipping to change at page 64, line 17
sidebar examples, in this case a comnpletely new conference sidebar examples, in this case a comnpletely new conference
object to describe the sidebar is provided: there is no cloning object 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 envisioned in Instead of cloning the main conference object, as envisioned in
Section 8.1 and Section 8.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 (as anticipated of the user provided conference information (as anticipated
before). However, the parent relationship between the main before). However, the parent relationship between the main
conference and the newly created sidebar is still mantained by conference and the newly created sidebar is still mantained by
the conferencing system (as a consequence of the chosen CCMP the conferencing system (as a consequence of the chosen CCMP
request message type - the sidebarByVal one) and it is reflected request message type - the sidebarByVal one) and it is reflected
by the <sidebar-parent> element in the "sidebarByValInfo" element by the <sidebar-parent> element in the "sidebarByValInfo" element
returned in the sidebarByValResponse message. Please notice returned in the sidebarByValResponse message. Please notice
that, according to the CCMP specification, the return of the that, according to the CCMP specification, the return of the
created sidebar data in this kind of "success" response is not created sidebar data in this kind of "success" response is not
mandatory. mandatory.
skipping to change at page 69, line 6 skipping to change at page 67, line 6
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/> uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByValInfo> </sidebarByValInfo>
</ccmp:sidebarByValResponse> </ccmp:sidebarByValResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 25: Sidebar for Private Messages scenario Figure 25: Sidebar for Private Messages scenario
8.4. Observing and Coaching 7.4. Observing and Coaching
Observing and Coaching is one of the most interesting sidebars- Observing and Coaching is one of the most interesting sidebars-
related scenarios. In fact, it envisages two different interactions related scenarios. In fact, it envisages two different interactions
that have to be properly coordinated. that have to be properly coordinated.
An example of observing and coaching is shown in figure Figure 27. An example of observing and coaching is shown in figure Figure 27.
In this example, call center agent Bob is involved in a conference 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 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 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 to observe the call and coach Bob as necessary. Of course the
skipping to change at page 72, line 44 skipping to change at page 70, line 44
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_GENERATED_2" and
"AUTO_GENERATE_3": those values will be replaced with the "AUTO_GENERATED_3": those values will be replaced with the
appropriated server-generated identifiers upon the creation of appropriated server-generated identifiers upon the creation of
the referred media stream. We are assuming the conferencing the referred media stream. We are assuming the conferencing
control server is able to recognize those dummy values as place- control server is able to recognize those dummy values as place-
holders. holders.
4. After validating the data, the conference server sends a 4. After validating the data, the conference server sends a
sidebarByRefResponse message. Based upon the contact information sidebarByRefResponse message. Based upon the contact information
provided for Bob by Alice, the call signaling to add Bob to the provided for Bob by Alice, the call signaling to add Bob to the
sidebar with the appropriate media characteristics is instigated sidebar with the appropriate media characteristics is instigated
through the Focus. Bob is notified of his addition to the through the Focus. Bob is notified of his addition to the
skipping to change at page 76, line 22 skipping to change at page 74, line 22
<confObjID>xcon:8971313@example.com</confObjID> <confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<version>2</version> <version>2</version>
<ccmp:sidebarByRefResponse/> <ccmp:sidebarByRefResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 28: Coaching and Observing Messaging details Figure 28: Coaching and Observing Messaging details
9. Removing Participants and Deleting Conferences 8. Removing Participants and Deleting Conferences
The following scenarios detail the basic operations associated with The following scenarios detail the basic operations associated with
removing participants from conferences and entirely deleting removing participants from conferences and entirely deleting
conferences. The examples assume that a conference has already been conferences. The examples assume that a conference has already been
correctly established, with media, if applicable, per one of the correctly established, with media, if applicable, per one of the
examples in Section 6. examples in Section 5.
9.1. Removing a Party 8.1. Removing a Party
Figure 29 provides an example of a client, "Alice", removing another Figure 29 provides an example of a client, "Alice", removing another
participant, "Bob", from a conference. This example assumes an participant, "Bob", from a conference. This example assumes an
established conference with Alice, Bob, "Claire" and "Duck". In this established conference with Alice, Bob, "Claire" and "Duck". In this
example, Alice wants to remove Bob from the conference so that the example, Alice wants to remove Bob from the conference so that the
group can continue in the same conference without Bob's group can continue in the same conference without Bob's
participation. participation.
Alice Bob Claire ConfS Alice Bob Claire ConfS
| | | | | | | |
skipping to change at page 79, line 5 skipping to change at page 77, line 5
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<response-code>success</response-code> <response-code>success</response-code>
<version>17</version> <version>17</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 30: Removing a Participant Messaging Details Figure 30: Removing a Participant Messaging Details
9.2. Deleting a Conference 8.2. Deleting a Conference
In this section, an example of a successful conference deletion is In this section, an example of a successful conference deletion is
provided (Figure 31). provided (Figure 31).
Alice ConfS Alice ConfS
| | | |
|(1)confRequest(confUserID, | |(1)confRequest(confUserID, |
| confObjID, delete) | | confObjID, delete) |
|------------------------------>| |------------------------------>|
| (a)Delete +---| | (a)Delete +---|
skipping to change at page 80, line 40 skipping to change at page 78, line 40
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<response-code>success</response-code> <response-code>success</response-code>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 32: Deleting a Conference Messaging Details Figure 32: Deleting a Conference Messaging Details
10. IANA Considerations 9. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
11. 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 is documented in the XCON Framework, with additional call flows is documented in the XCON Framework, with additional
security considerations documented in the CCMP document. Where security considerations documented in the CCMP document. Where
applicable, statements with regards to the necessary security are applicable, statements with regards to the necessary security are
discussed in particular flows, however, since this is only an discussed in particular flows, however, since this is only an
informational document, readers are strongly recommended to carefully informational document, readers are strongly recommended to carefully
consider the security considerations defined in the XCON Framework consider the security considerations defined in the XCON Framework
and the CCMP document. and the CCMP document.
12. Change Summary 11. Change Summary
NOTE TO THE RFC-EDITOR: Please remove this section prior to NOTE TO THE RFC-EDITOR: Please remove this section prior to
publication as an RFC. publication as an RFC.
The following are the major changes between the 02 and the 03 The following are the major changes between the 02 and the 03
versions of the draft: versions of the draft:
o updated the call flows in order to take into account the changes o updated the call flows in order to take into account the changes
on CCMP; on CCMP;
skipping to change at page 82, line 13 skipping to change at page 80, line 13
a resource before it can be used by an interested participant; a resource before it can be used by an interested participant;
o changed all the domains involved in the flows to make them o changed all the domains involved in the flows to make them
compliant with [RFC2606]; compliant with [RFC2606];
o clarified that a successful creation of a new conference object o clarified that a successful creation of a new conference object
may or may not contain the whole confInfo object in the response; 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 in case it doesn't, a retrieve of the updated object can be
achieved by issuing a confRequest/retrieve; achieved by issuing a confRequest/retrieve;
o clarified that the scenario in Section 7.3 only involves CCMP in o clarified that the scenario in Section 6.3 only involves CCMP in
adding the user to a conference; this includes requiring the use adding the user to a conference; this includes requiring the use
of a password only in adding the user to the conference object; of a password only in adding the user to the conference object;
the actual request for PIN/Password when joining thw conference is the actual request for PIN/Password when joining thw conference is
handled by means of out-of-band mechanisms (in this case at the handled by means of out-of-band mechanisms (in this case at the
media level, with the help of the MEDIACTRL framework); media level, with the help of the MEDIACTRL framework);
o added and corrected Sidebars-related scenarios; o added and corrected Sidebars-related scenarios;
o added flows for some previously missing scenarios: Private o added flows for some previously missing scenarios: Private
Message/Whisper, Coaching Scenario, Removing a Party, Deleting a Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
skipping to change at page 83, line 5 skipping to change at page 81, line 5
The following are the major changes between the individual 01 version The following are the major changes between the individual 01 version
to the WG 00: to the WG 00:
o Updates to reflect most recent version of CCMP, including o Updates to reflect most recent version of CCMP, including
parameter names, etc. parameter names, etc.
o Added protocol details to many of the examples. o Added protocol details to many of the examples.
o Editorial: Simplifying intro, terms, etc. o Editorial: Simplifying intro, terms, etc.
13. Acknowledgements 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.
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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-05 (work in progress), December 2009. draft-ietf-xcon-ccmp-06 (work in progress), February 2010.
14.2. Informative References 13.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. 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
skipping to change at page 84, line 13 skipping to change at page 82, line 13
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-16 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18
(work in progress), February 2010. (work in progress), February 2010.
[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-03 (work in Examples", draft-ietf-mediactrl-call-flows-03 (work in
progress), February 2010. progress), February 2010.
[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-10 (work in draft-ietf-mediactrl-mixer-control-package-11 (work in
progress), January 2010. progress), February 2010.
[I-D.boulton-xcon-session-chat] [I-D.boulton-xcon-session-chat]
Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
a Centralized Conferencing (XCON) System", a Centralized Conferencing (XCON) System",
draft-boulton-xcon-session-chat-04 (work in progress), draft-boulton-xcon-session-chat-04 (work in progress),
July 2009. July 2009.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
 End of changes. 84 change blocks. 
196 lines changed or deleted 186 lines changed or added

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