draft-ietf-xcon-examples-00.txt   draft-ietf-xcon-examples-01.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational C. Boulton Intended status: Informational C. Boulton
Expires: January 7, 2010 NS-Technologies Expires: January 14, 2010 NS-Technologies
L. Miniero L. Miniero
Meetecho
R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
July 6, 2009 July 13, 2009
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-00.txt draft-ietf-xcon-examples-01.txt
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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 38
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 5 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 6 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 6
5.2. Basic Conference Creation for a specific instance of 5.2. Basic Conference Creation for a specific instance of
Conference Information . . . . . . . . . . . . . . . . . . 10 Conference Information . . . . . . . . . . . . . . . . . . 11
5.3. Basic Conference Creation - Cloning an existing 5.3. Basic Conference Creation - Cloning an existing
Conference . . . . . . . . . . . . . . . . . . . . . . . . 14 Conference . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Conference Creation using Blueprints . . . . . . . . . . . 17 5.4. Conference Creation using Blueprints . . . . . . . . . . . 18
6. General Conference scenarios and examples . . . . . . . . . . 24 6. General Conference scenarios and examples . . . . . . . . . . 25
6.1. Conference Announcements and Recordings . . . . . . . . . 24 6.1. Conference Announcements and Recordings . . . . . . . . . 25
6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 25 6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 28
6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 25 6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 28
6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 26 6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 31
6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 27 6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 36
6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 28 6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 45
6.7. Floor control using sidebars . . . . . . . . . . . . . . . 30 6.7. Floor control using sidebars . . . . . . . . . . . . . . . 51
6.8. Whispering or Private Messages . . . . . . . . . . . . . . 31 6.8. Whispering or Private Messages . . . . . . . . . . . . . . 52
6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 32 6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 53
7. Removing participants and deleting conferences . . . . . . . . 33 7. Removing participants and deleting conferences . . . . . . . . 54
7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 34 7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 55
7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 34 7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 56
8. Additional Conference Scenarios and Examples . . . . . . . . . 35 8. Additional Conference Scenarios and Examples . . . . . . . . . 57
8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 36 8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 58
8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 40 8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 62
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
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 5, line 8 skipping to change at page 5, line 8
documents, with the following terms and abbreviations used in the documents, with the following terms and abbreviations used in the
call flows. Also, note that the term "call flows" is used in a very call flows. Also, note that the term "call flows" is used in a very
generic sense in this document since the media is not limited to generic sense in this document since the media is not limited to
voice. The calls supported by the XCON framework and CCMP can voice. The calls supported by the XCON framework and CCMP can
consist of media such as text, voice and video, including multiple consist of media such as text, voice and video, including multiple
media types in a single active conference. media types in a single active conference.
Conferencing and Media Client Client (CMCC): As defined in the XCON Conferencing and Media Client 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.miniero-mediactrl-escs]. control call flows [I-D.ietf-mediactrl-call-flows].
Conferencing Server (ConfS): As defined in the XCON Framework. In Conferencing Server (ConfS): As defined in the XCON Framework. In
this document, the conferencing server is used interchangeably this document, the conferencing server is used interchangeably
with the term Application Server (AS) as used in the Media Control with the term Application Server (AS) as used in the Media Control
Architectural Framework [RFC5567]. However, these need not be the Architectural Framework [RFC5567]. However, these need not be the
same entities in an implementation. same entities in an implementation.
Media Server (MS): As defined in the Media Control Architectural Media Server (MS): As defined in the Media Control Architectural
Framework [RFC5567]. Framework [RFC5567].
skipping to change at page 5, line 41 skipping to change at page 5, line 41
Conference Server. The scenarios are based on those described in the Conference Server. The scenarios are based on those described in the
XCON framework, many of which are based on the advanced conferencing XCON framework, many of which are based on the advanced conferencing
capabilities described in the XCON scenarios. Additional scenarios capabilities described in the XCON scenarios. Additional scenarios
have been added to provide examples of other real life scenarios that have been added to provide examples of other real life scenarios that
are anticipated to be supported by the framework. With the exception are anticipated to be supported by the framework. With the exception
of an initial example with media control messaging, the examples do of an initial example with media control messaging, the examples do
not include the details for the media control not include the details for the media control
[I-D.ietf-mediactrl-mixer-control-package], call signaling or binary [I-D.ietf-mediactrl-mixer-control-package], call signaling or binary
floor control [RFC4582] protocols. This document references the floor control [RFC4582] protocols. This document references the
scenarios in the Media Control call flows scenarios in the Media Control call flows
[I-D.miniero-mediactrl-escs], SIP Call Control Conferencing [RFC4579] [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
and binary floor control protocol documents. [RFC4579] and binary floor control protocol documents.
5. Conference Creation 5. Conference Creation
This section provides the details associated with the various ways in This section provides the details associated with the various ways in
which a conference can be created using CCMP and the XCON framework which a conference can be created using CCMP and the XCON framework
constructs. As previously mentioned the details of the media constructs. As previously mentioned the details of the media
control, call signaling and floor control protocols, where control, call signaling and floor control protocols, where
applicable, are annotated in the flows without showing all the applicable, are annotated in the flows without showing all the
details. However, for clarification purposes, the first example details. However, for clarification purposes, the first example
Section 5.1 provides the details of the media control messaging along Section 5.1 provides the details of the media control messaging along
skipping to change at page 6, line 21 skipping to change at page 6, line 21
reader is encouraged to refer to the call flows in the relevant reader is encouraged to refer to the call flows in the relevant
documents for details for the other protocols. The annotations for documents for details for the other protocols. The annotations for
the call signaling are on the left side of the conferencing server the call signaling are on the left side of the conferencing server
vertical bar and those for the media control messaging are on the vertical bar and those for the media control messaging are on the
right side. right side.
5.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,
This results in the creation of a default conference, with an XCON- together with the "confUserID" associated with the requesting client
URI in the form of the "confObjID" parameter, the XCON-UserID in the itself. This results in the creation of a default conference, with
form of the "confUserID" parameter and the data for the conference an XCON-URI in the form of the "confObjID" parameter, the XCON-UserID
object in the "confInfo" parameter all returned in the "confResponse" in the form of the "confUserID" parameter (the same already present
message. This example also adds the user that invoked the conference in the request) and the data for the conference object in the
upon creation (i.e., "method" attribute is set to "dial out" for this "confInfo" parameter all returned in the "confResponse" message.
client based on the particular conferencing systems default). Note, According to the implementation of the framework, this example may
that depending upon the conferencing system, this default conference also add the user that invoked the conference upon creation to the
could be specific to the client requesting the conference and thus conference object (e.g., "method" attribute in the "target" element
may be different for the initiator than other participants (e.g., IVR of "allowed-users-list" may be set to "dial out" for this client
interactions in this case which are not shown). based on the particular conferencing systems default). This is
exactly the case depicted in the figure, which is presented to enrich
the scenario. Note, that depending upon the conferencing system,
this default conference could be specific to the client requesting
the conference and thus may be different for the initiator than other
participants (e.g., IVR interactions in this case which are not
shown).
The specific data for the conference object is returned in the The specific data for the conference object is returned in the
"confResponse" message in the "confInfo" parameter. This allows the "confResponse" message in the "confInfo" parameter. This allows the
client (with the appropriate authorization) to manipulate this data client (with the appropriate authorization) to manipulate this data
and add additional participants to the conference, as well as change and add additional participants to the conference, as well as change
the data during the conference. In addition, the client may the data during the conference. In addition, the client may
distribute the conferencing information to other participants distribute the conferencing information to other participants
allowing them to join, the details of which are provided in allowing them to join, the details of which are provided in
additional flows. additional flows.
skipping to change at page 7, line 7 skipping to change at page 8, line 7
specific signaling interface such as SIP [RFC3261], using the specific signaling interface such as SIP [RFC3261], using the
signaling interface to the conference focus as described in signaling interface to the conference focus as described in
[RFC4579]. However, these details are not shown in the message [RFC4579]. However, these details are not shown in the message
flows. The message flows in this document identity the point in the flows. The message flows in this document identity the point in the
message flows at which this signaling occurs via the lower case message flows at which this signaling occurs via the lower case
letter items (i.e., (a)...(x)) along with the appropriate text for letter items (i.e., (a)...(x)) along with the appropriate text for
the processing done by the conferencing server. the processing done by the conferencing server.
CMCC1 CMCC2 CMCCx CONFS MS CMCC1 CMCC2 CMCCx CONFS MS
| | | | | | | | | |
|1. confRequest | | | | |(1)confRequest(create, confUserID) | |
|-------------------------------------->| | |-------------------------------------->| |
| | (a)Create +---| | | | (a)Create +---| |
| | |Conf | | | | | |Conf | | |
| | |Object | | | | | |Object | | |
| | |& IDs +-->| | | | |& IDs +-->| |
| | | | A1. CONTROL | | | | | A1. CONTROL |
| | | |+++++++++++>>| | | | |+++++++++++>>|
| | | |(create conf)|--+ (b) | | | |(create conf)|--+ (b)
| | | | | | create | | | | | | create
| | | | | | conf and | | | | | | conf and
| | | | A2. 200 OK |<-+ its ID | | | | A2. 200 OK |<-+ its ID
| | | |<<+++++++++++| | | | |<<+++++++++++|
| | | |(confid=Y) | | | | |(confid=Y) |
|(2)confResponse(create,success, | | |(2)confResponse(create,success, | |
|<--------------------------------------| |
| confObjID, confUserID | | | confObjID, confUserID | |
| conf-info) | | | | confInfo) | | |
|<--------------------------------------| |
| | | | | | | | | |
| | (c) Focus +---| | | | (c) Focus +---| |
| | sets up | | | | | sets up | | |
| | signaling | | | | | signaling | | |
| | to CMCC1 +-->| | | | to CMCC1 +-->| |
| | | | | | | | | |
| | | | B1. CONTROL | | | | | B1. CONTROL |
| | | |+++++++++++>>| | | | |+++++++++++>>|
| | | | (join CMCC1 | | | | | (join CMCC1 |
| | | | <->confY) | | | | | <->confY) |
skipping to change at page 8, line 9 skipping to change at page 9, line 9
|******CMCC1 may then manipulate conference data *****| |******CMCC1 may then manipulate conference data *****|
|****** and add addt'l users, etc. | *****| |****** and add addt'l users, etc. | *****|
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
Figure 1: Create Basic Conference - Complete flow Figure 1: Create Basic Conference - Complete flow
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx CONFS CMCC1 CMCC2 CMCCx CONFS
| | | | | | | |
|(1)confRequest | | | |(1)confRequest(create, confUserID) |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | (a)Create +---| | | (a)Create +---|
| | |Conf | | | | |Conf | |
| | |Object | | | | |Object | |
| | |& IDs +-->| | | |& IDs +-->|
| | | |--+ (b) MS | | | |--+ (b) MS
| | | | | creates | | | | | creates
| | | | | conf and | | | | | conf and
| | | |<-+ its ID | | | |<-+ its ID
| | | | (confid=Y) | | | | (confid=Y)
|(2)confResponse(create,success, | |(2)confResponse(create, success |
|<--------------------------------------|
| confObjID, confUserID | | confObjID, confUserID |
| confInfo) | | | confInfo) | |
|<--------------------------------------|
| | | | | | | |
| | | | | | | |
| | (c) Focus +---| | | (c) Focus +---|
| | sets up | | | | sets up | |
| | signaling | | | | signaling | |
| | to CMCC1 +-->| | | to CMCC1 +-->|
| | | | | | | |
| | | |--+(d) MS joins | | | |--+(d) MS joins
| | | | | CMCC1 & | | | | | CMCC1 &
| | | |<-+ conf Y | | | |<-+ conf Y
skipping to change at page 9, line 15 skipping to change at page 10, line 15
1. confRequest message: 1. confRequest message:
<?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@confSystem.com</confUserID>
<operation>create</operation> <operation>create</operation>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message: 2. confResponse message:
<?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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:alice@confSystem.com</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@confSystem.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
Default conference initiated by Alice Default conference initiated by Alice
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@confSystem.com
</info:uri> </info:uri>
<info:display-text> <info:display-text>
Conference XCON-URI Conference XCON-URI
</info:display-text> </info:display-text>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info:maximum-user-count>10</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="11"> <info:entry label="11">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:join-handling>allow</xcon:join-handling>
<xcon: allowed-users-list> <xcon: allowed-users-list>
<xcon: target uri="sip:alice@example.com" <xcon:target uri="xcon-userid:alice@confSystem.com"
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 3: Create Basic Conference (Annotated) Detailed Messaging Figure 3: Create Basic Conference (Annotated) Detailed Messaging
5.2. Basic Conference Creation for a specific instance of Conference 5.2. Basic Conference Creation for a specific instance of Conference
Information 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. If the conferencing system can support conference to be created. The request, as is the case of all CCMP
that specific type of conference (capabilities, etc.), then the requests, also includes the "confUserID" of the requesting entity.
request results in the creation of a conference. In this success If the conferencing system can support that specific type of
case, an XCON-URI in the form of the "confObjID" parameter and the conference (capabilities, etc.), then the request results in the
XCON-UserID in the form of the "confUserID" parameter are returned in creation of a conference. In this success case, an XCON-URI in the
the "confResponse" message. The "confInfo" is not returned unless form of the "confObjID" parameter and the XCON-UserID in the form of
changes have been made, in which case the "responseCode" is the "confUserID" parameter (again, the same as the requesting entity)
"modified". are returned in the "confResponse" message. The "confInfo" is not
returned unless changes have been made, in which case the
"responseCode" is "modified".
This example also activates the conference upon creation (i.e., This example also activates the conference upon creation (i.e.,
"method" attribute is set to "dial out" for this client based on the "method" attribute is set to "dial out" for this client based on the
particular conferencing systems default), Note, that depending upon particular conferencing systems default). Just as before, this is
not to be considered mandatory, since it depends on the
implementation choices of the framework. Note, that depending upon
the conferencing system, this default conference could be specific to the conferencing system, this default conference could be specific to
the client requesting the conference and thus may be different for the client requesting the conference and thus may be different for
the initiator than other participants (e.g., IVR interactions in this the initiator than other participants (e.g., IVR interactions in this
case which are not shown). case which are not shown).
"Alice" "Bob" "Carol" CONFS "Alice" "Bob" "Carol" CONFS
| | | | | | | |
|(1)confRequest | | | |(1)confRequest | | |
|-------------------------------------->|
| ( create, confUserID, confInfo) | | ( create, confUserID, confInfo) |
|-------------------------------------->|
| | | | | | | |
| | (a)Create +---| | | (a)Create +---|
| | |Conf | | | | |Conf | |
| | |Object | | | | |Object | |
| | |& IDs +-->| | | |& IDs +-->|
| | | |--+ (b) MS | | | |--+ (b) MS
| | | | | creates | | | | | creates
| | | | | conf and | | | | | conf and
| | | |<-+ its ID | | | |<-+ its ID
| | | | (confid=Y) | | | | (confid=Y)
|(2) confResponse | | |(2) confResponse | |
|<--------------------------------------|
| ( create,success, confObjID | | ( create,success, confObjID |
| confUserID)| | | | confUserID)| | |
|<--------------------------------------|
| | | | | | | |
| | (c) Focus +---| | | (c) Focus +---|
| | sets up | | | | sets up | |
| | signaling | | | | signaling | |
| | to Alice +-->| | | to Alice +-->|
| | | | | | | |
| | | |--+(d) MS joins | | | |--+(d) MS joins
| | | | | Alice & | | | | | Alice &
| | | |<-+ conf Y | | | |<-+ conf Y
| | | | | | | |
skipping to change at page 12, line 38 skipping to change at page 13, line 42
<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</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest> <ccmp:confRequest>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@confSystem.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
Dial-out conference initiated by Alice Dial-out conference initiated by Alice
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@confSystem.com
</info:uri> </info:uri>
<info:display-text> <info:display-text>
Conference XCON-URI Conference XCON-URI
</info:display-text> </info:display-text>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info:maximum-user-count>10</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="11"> <info:entry label="11">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:join-handling>allow</xcon:join-handling>
<xcon: allowed-users-list> <xcon: allowed-users-list>
<xcon: target uri="sip:alice@example.com" <xcon:target uri="sip:alice@wonderland.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:bob@example.com" <xcon:target uri="sip:bob83@ciccio.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:carol@example.com" <xcon:target uri="sip:carol@pippozzo.com"
method="dial-out"/> method="dial-out"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</confInfo> </confInfo>
</ccmp:confRequest> </ccmp:confRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message: 2. confResponse message:
<?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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:6845432@example.com</confObjID> <confObjID>xcon:6845432@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 5: Create Basic Conference Detailed Messaging Figure 5: Create Basic Conference Detailed Messaging
5.3. Basic Conference Creation - Cloning an existing Conference 5.3. Basic Conference Creation - 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 reseravation. conference, such as an active conference or conference reseravation.
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 a specific "confObjID", from which a "create" operation, along with the "confUserID" and a specific
new conference is to be created by cloning an existing conference. "confObjID", from which a new conference is to be created by cloning
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 5.4. The manner by which a client blueprint is provided in Section 5.4. 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).
skipping to change at page 14, line 33 skipping to change at page 16, line 8
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
value in the "confObjID" parameter to reflect the newly cloned value in the "confObjID" parameter to reflect the newly cloned
conference object returned in the "confResponse" message. The conference object returned in the "confResponse" message. The
"confInfo" is not returned unless there had been changes, in which "confInfo" is not returned unless there had been changes, in which
case the "responseCode" is "modified". case the "responseCode" is "modified".
"Alice" ConfS "Alice" ConfS
| | | |
|(1) confRequest (create, | |(1) confRequest (create, |
| confObjID, confUserId) |
|------------------------------>| |------------------------------>|
| confObjID, confUserId, child)|
| (a)Create +---| | (a)Create +---|
| Conf | | | Conf | |
| Object | | | Object | |
| & IDs +-->| | & IDs +-->|
| |--+ (b) MS | |--+ (b) MS
| | | creates | | | creates
| | | conf and | | | conf and
| |<-+ its ID | |<-+ its ID
| | (confid=Y) | | (confid=Y)
| | | |
|(2) confResponse | |(2) confResponse |
|<------------------------------|
| ( create, success, | | ( create, success, |
| confObjID, confUserID) | | confObjID*, confUserID) |
|<------------------------------|
| | | |
Figure 6: Create Basic Conference - Clone Figure 6: Create Basic Conference - Clone
1. "Alice" sends a confRequest message to clone a conference based 1. "Alice" sends a confRequest message to clone a conference based
on an existing conference reservation. "Alice" indicates this on an existing conference reservation. "Alice" indicates this
conference should be a "child" of the parent conference conference should be cloned from the specified parent conference
represented by the "confObjID" in the request. represented by the "confObjID" in the request.
2. Upon receipt of the confRequest message containing a "create" 2. Upon receipt of the confRequest message containing a "create"
operation and "confObjID", the conferencing system ensures that operation and "confObjID", the conferencing system ensures that
the "confObjID" received is valid. The conferencing system the "confObjID" received is valid. The conferencing system
determines the appropriate read/write access of any users to be determines the appropriate read/write access of any users to be
added to a conference based on this "confObjID" (using added to a conference based on this "confObjID" (using
membership, roles, etc.). The conferencing system uses the membership, roles, etc.). The conferencing system uses the
received "confObjID" to clone a conference reservation. The received "confObjID" to clone a conference reservation. The
conferencing system also reserves or allocates a new "confObjID" conferencing system also reserves or allocates a new "confObjID"
to be used for the cloned conference object. Any subsequent (called "confObjID*" in Figure 6) to be used for the cloned
protocol requests from any of the members of the conference. The conference object. This new identifier is of course different
conferencing system maintains the mapping between this conference from the one associated with the conference to be cloned, since
ID and the parent conference object ID associated with the it represents a different conference object. Any subsequent
reservation through the conference instance. protocol requests from any of the members of the conference must
address this new identifier. The conferencing system maintains
the mapping between this conference ID and the parent conference
object ID associated with the reservation through the conference
instance, and this mapping is explicitly addressed through the
"cloning-parent" element of the "conference-description" in the
new conference object.
1. confRequest message: 1. confRequest message:
<?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">
<confObjID>xcon:6845432@example.com</confObjID> <confObjID>xcon:6845432@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message: 2. confResponse message:
<?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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@confSystem.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from 6845432 New conference by Alice cloned from 6845432
</info:display-text> </info:display-text>
<xcon:cloning-parent>
xcon:6845432@confSystem.com
</xcon:cloning-parent>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@confSystem.com
</info:uri> </info:uri>
<info:display-text> <info:display-text>
conference xcon-uri conference xcon-uri
</info:display-text> </info:display-text>
<xcon:conference-password> <xcon:conference-password>
8601 8601
</xcon:conference-password> </xcon:conference-password>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info:maximum-user-count>10</info:maximum-user-count>
skipping to change at page 18, line 8 skipping to change at page 18, line 48
5.4. Conference Creation using Blueprints 5.4. Conference Creation using Blueprints
Figure 8 provides an example of one client "Alice" determining the Figure 8 provides an example of one client "Alice" determining the
conference blueprints available for a particular conferencing system conference blueprints available for a particular conferencing system
and creating a conference based on the desired blueprint. and creating a conference based on the desired blueprint.
CMCC "Alice" ConfS CMCC "Alice" ConfS
| | | |
| (1) blueprintsRequest | | (1) blueprintsRequest |
|------------------------------>|
| (confUserID) | | (confUserID) |
|------------------------------>|
| | | |
| (2) blueprintsResponse | | (2) blueprintsResponse |
|<------------------------------|
| (confUserID, success, | | (confUserID, success, |
| blueprintsInfo) | | blueprintsInfo) |
|<------------------------------|
| |
|--+ | |--+ |
| | choose preferred | | | choose preferred |
| | blueprint from the | | | blueprint from the |
| | list (blueprintName) | | | list (blueprintName) |
|<-+ | |<-+ |
| | | |
| (3) blueprintRequest | | (3) blueprintRequest |
|------------------------------>|
| (retrieve, confObjID, | | (retrieve, confObjID, |
| confUserID) | | confUserID) |
|------------------------------>|
| | | |
| (4) blueprintResponse | | (4) blueprintResponse |
|<------------------------------|
| (success, confObjID,| | (success, confObjID,|
| confUserID,confInfo)| | confUserID,confInfo)|
|<------------------------------|
| | | |
| (5) confRequest (create, | | (5) confRequest (create, |
|------------------------------>|
| confobjID) | | confobjID) |
|------------------------------>|
| |
| (a)Create +---| | (a)Create +---|
| Conf | | | Conf | |
| Object | | | Object | |
| & IDs +-->| | & IDs +-->|
| |--+ (b) MS | |--+ (b) MS
| | | creates | | | creates
| | | conf and | | | conf and
| |<-+ its ID | |<-+ its ID
| | (confid=Y) | | (confid=Y)
|(6) confResponse | |(6) confResponse |
|<------------------------------|
| (create,success, | | (create,success, |
| confObjID, confUserID) | | confObjID*, confUserID) |
|<------------------------------|
| | | |
| | | |
| | | |
. . . .
. . . .
Figure 8: Client Creation of Conference using Blueprints Figure 8: Client Creation of Conference using Blueprints
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. Upon receipt of the "blueprintsRequest", the process. Upon receipt of the "blueprintsRequest", the
conferencing system would first authenticate "Alice" and then conferencing system would first authenticate "Alice" and then
ensure that "Alice" has the appropriate authority based on system ensure that "Alice" has the appropriate authority based on system
policies to receive any blueprints supported by that system. policies to receive any blueprints supported by that system.
2. Any blueprints that "Alice" is authorized to use are returned in 2. Any blueprint that "Alice" is authorized to use are returned in a
a "blueprintsResponse" message in the "blueprintsInfo" attribute. "blueprintsResponse" message in the "blueprintsInfo" attribute.
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" then sends a "confRequest" with a "create" operation to 5. "Alice" then sends a "confRequest" with a "create" operation to
the conferencing system to create a conference reservation, the conferencing system to create a conference reservation,
including the appropriate "blueprintName" and associated including the appropriate "blueprintName" and associated
"confObjID". "confObjID".
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 "confObjID". The clone a conference, allocating a new "confObjID" (again called
conferencing server then sends a "confResponse" message including "confObjID* in the example). The conferencing server then sends
the "confObjID" associated with the newly created conference a "confResponse" message including the new "confObjID*"
instance. Upon receipt of the "confResponse" message, "Alice" associated with the newly created conference instance. Upon
can now add other users to the conference . receipt of the "confResponse" message, "Alice" can now add other
users to the conference .
[Editors' Note: unlike what happened when cloning an existing
conference as presented in the previous subsection, no "cloning-
parent" is set in the response to the cloning of a blueprint. Is
this a desired behaviour? Or is this implementation specific?
Should the Data Model clarify the behaviour for such an event?]
1. blueprintsRequest message: 1. blueprintsRequest message:
<?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</confUserID> <confUserID>xcon-userid:Alice</confUserID>
skipping to change at page 20, line 20 skipping to change at page 21, line 27
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</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri> <info:uri>xcon:AudioRoom@confSystem.com</info:uri>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room: <info:purpose>Simple Room:
conference room with public access, conference room with public access,
where only audio is available, more users where only audio is available, more users
can talk at the same time can talk at the same time
and the requests for the AudioFloor and the requests for the AudioFloor
are automatically accepted. are automatically accepted.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri> <info:uri>xcon:VideoRoom@confSystem.com</info:uri>
<info:display-text>VideoRoom</info:display-text> <info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room: <info:purpose>Video Room:
conference room with public access, conference room with public access,
where both audio and video are available, where both audio and video are available,
8 users can talk and be seen at the same time, 8 users can talk and be seen at the same time,
and the floor requests are automatically accepted. and the floor requests are automatically accepted.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:AudioConference1@example.com</info:uri> <info:uri>xcon:AudioConference1@confSystem.com</info:uri>
<info:display-text>AudioConference1</info:display-text> <info:display-text>AudioConference1</info:display-text>
<info:purpose>Public Audio Conference: <info:purpose>Public Audio Conference:
conference with public access, conference with public access,
where only audio is available, where only audio is available,
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri> <info:uri>xcon:VideoConference1@confSystem.com</info:uri>
<info:display-text>VideoConference1</info:display-text> <info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference <info:purpose>Public Video Conference: conference
where both audio and video are available, where both audio and video are available,
only one user can talk only one user can talk
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:AudioConference2@example.com</info:uri> <info:uri>xcon:AudioConference2@confSystem.com</info:uri>
<info:display-text>AudioConference2</info:display-text> <info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference: <info:purpose>Basic Audio Conference:
conference with private access, conference with private access,
where only audio is available, where only audio is available,
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
</blueprintsInfo> </blueprintsInfo>
skipping to change at page 21, line 35 skipping to change at page 22, line 43
3. blueprintRequest message: 3. blueprintRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type"> xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<ccmp:blueprintRequest>
<operation>retrieve</operation> <operation>retrieve</operation>
</ccmp:blueprintRequest> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. blueprintResponse message: 4. blueprintResponse message:
<?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 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type"> xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confObjID>xcon:AudioRoom@example.com</confObjID> <operation>retrieve</operation>
<confObjID>xcon:AudioRoom@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="AudioRoom"> <blueprintInfo entity="AudioRoom">
<info:conference-description> <info:conference-description>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count> <info:maximum-user-count>2</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="audioLabel"> <info:entry label="audioLabel">
<info:type>audio</info:type> <info:type>audio</info:type>
skipping to change at page 22, line 44 skipping to change at page 24, line 4
5. confRequest message: 5. confRequest message:
<?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">
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
6. confResponse message: 6. confResponse message:
<?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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@confSystem.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@confSystem.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@confSystem.com
</info:uri> </info:uri>
<info:display-text> <info:display-text>
conference xcon-uri conference xcon-uri
</info:display-text> </info:display-text>
<xcon:conference-password> <xcon:conference-password>
8601 8601
</xcon:conference-password> </xcon:conference-password>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info:maximum-user-count>10</info:maximum-user-count>
skipping to change at page 24, line 27 skipping to change at page 25, line 35
correctly established, with media, if applicable, per one of the correctly established, with media, if applicable, per one of the
examples in Section 5. examples in Section 5.
6.1. Conference Announcements and Recordings 6.1. Conference Announcements and Recordings
In this example, as shown in Figure 10 "Alice" is joining "Bob"'s In this example, as shown in Figure 10 "Alice" is joining "Bob"'s
conference that requires that she first enter a pass code. After conference that requires that she first enter a pass code. After
successfully entering the passcode, an announcement prompts "Alice to successfully entering the passcode, 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. participants. A very similar example is presented in Figure 33 of
[I-D.ietf-mediactrl-call-flows].
(Figure not available yet).
CCMC "Alice" ConfS MS
| | |
|(1)userRequest (create, | |
| confObjID, userInfo) | |
|--------------------------->| |
| |--+ Alice is |
| | | new in the |
| |<-+ system (create |
| | confUserID) |
| ConfS handles +--| |
| SIP signaling | | |
| (Alice<->ConfS<->MS) +->| |
| | |
| |--+ A password is |
| | | required for |
| |<-+ that conference |
| | |
| | Request IVR menu (PIN) |
| |--------------------------->|
| | |
|<========= MS gets PIN from Alice through DTMF =========>|
| | |
| | Provided PIN is... |
| |<---------------------------|
| Check +--| |
| PIN | | |
| +->| |
| |--+ Alice must |
| | | record her |
| |<-+ name |
| | |
| | Request name recording |
| |--------------------------->|
| | |
|<========= MS records Alice's audio RTP (name) =========>|
| | |
| | Audio recording |
| |<---------------------------|
| Complete +--| |
| creation | | |
| of Alice +->| |
| | |
| (2) userResponse | |
| (create, success | |
| confObjID, confUserID) |
|<---------------------------| |
| | |
Figure 10: Recording and Announcements Figure 10: Recording and Announcements
1. Upon receipt of the userRequest from "Alice" to be added to 1. Upon receipt of the userRequest from "Alice" to be added to
"Bob's" conference (i.e., an "update" operation on "Bob's" "Bob's" conference (i.e., an "update" operation on "Bob's"
conference object). The conferencing system determines that a conference object), the conferencing system determines that a
password is required for this specific conference, thus an password is required for this specific conference. Thus an
announcement asking "Alice" to enter the password is provided to announcement asking "Alice" to enter the password is provided to
"Alice". Once "Alice" enters the password, it is validated "Alice". This may be achieved by means of typical IVR
fucntionality. Once "Alice" enters the password, it is validated
against the policies associated with "Bob's" active conference. against the policies associated with "Bob's" active conference.
The conferencing system then connects to a server which prompts The conferencing system then connects to a server which prompts
and records "Alice's" name. The conferencing system must also and records "Alice's" name. The conferencing system must also
determine whether "Alice" is already a user of this conferencing determine whether "Alice" is already a user of this conferencing
system or whether she is a new user. In this case, "Alice" is a system or whether she is a new user. In this case, "Alice" is a
new user for this conferencing system, so a conference user new user for this conferencing system, so a conference user
identifier is created for "Alice". Based upon the addressing identifier is created for "Alice". Based upon the addressing
information provided by "Alice", the call signaling to add information provided by "Alice", the call signaling to add
"Alice" to the conference is instigated through the Focus. "Alice" to the conference is instigated through the Focus.
skipping to change at page 25, line 19 skipping to change at page 27, line 36
the conference (if she were to have the appropriate policies), the conference (if she were to have the appropriate policies),
including registering for event notifications associated with the including registering for event notifications associated with the
conference. Once the call signaling indicates that "Alice" has conference. Once the call signaling indicates that "Alice" has
been successfully added to the specific conference, per updates been successfully added to the specific conference, per updates
to the state, and depending upon the policies, other participants to the state, and depending upon the policies, other participants
(e.g., "Bob") are notified of the addition of "Alice" to the (e.g., "Bob") are notified of the addition of "Alice" to the
conference via the conference notification service and an conference via the conference notification service and an
announcement is provided to all the participants indicating that announcement is provided to all the participants indicating that
"Alice" has joined the conference. "Alice" has joined the conference.
[Editors' Note: this example showed the case of a private conference,
where access required the knowledge of a password. In this case,
access to the conference is handled by delegating the control of such
value to the signaling/media. Nevertheless, the "password" value is
present in CCMP requests as well, according to the latest
specification. Should the presented flow make use of the CCMP
password check alone, or is it ok to leave the signaling/media checks
as well? What is the expected best common practice when dealing with
such a scenario?]
(CCMP Messaging details not available yet). (CCMP Messaging details not available yet).
Figure 11: Announcement Messaging Details Figure 11: Announcement Messaging Details
6.2. Monitoring for DTMF 6.2. Monitoring for DTMF
The conferencing system also needs the capability to monitor for DTMF The conferencing system also needs the capability to monitor for DTMF
from each individual participant. This would typically be used to from each individual participant. This would typically be used to
enter the identifier and/or access code for joining a specific enter the identifier and/or access code for joining a specific
conference. conference.
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 10. elements, is shown in Figure 10. A typical way for the conferencing
system to be aware of all the DTMF interactions within the context of
conferences it is responsible for, is making use of the MEDIACTRL
architecture for what regards media manipulation. Examples in that
sense (specifically for what concerns DTMF interception in conference
instances) are presented in [I-D.ietf-mediactrl-call-flows].
6.3. Adding a Party 6.3. Adding a Party
In this example, "Alice" wants to add "Bob" to an established In this example, "Alice" wants to add "Bob" to an established
conference. conference. In the following example we assume "Bob" is a new user
to the system, which means "Alice" also needs to provide details
about him. In fact, the case of "Bob" already present as a user in
the conferencing system is much easier to address, and will be
discussed later on.
To do. "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS
| | | |
|(1) userRequest(create, | |
| confObjID, confUserID, | |
| userInfo) | | |
|-------------------------------------->|
| | | |
| | (a) Create +---|
| | | "Bob" | |
| | | as a | |
| | | user +-->|
| | | |
|(2) userResponse(create, success |
| confObjID, confUserID |
| userInfo) | |
|<--------------------------------------|
| | | |
| | | (b) Focus |
| | | sets up |
| | | signaling |
| | | to "Bob" |
| |<----------------------|
| | | |
| | | (c) Notify|
| | | ("Bob just|
| | | joined") |
| | |<----------|
| | | |
' ' ' '
' ' ' '
' ' ' '
Figure 12: Client Manipulation of Conference - Add a party Figure 12: Client Manipulation of Conference - Add a party
1. "Alice" sends a userRequest message with an operation of "create" 1. "Alice" sends a userRequest message with an operation of "create"
to add "Bob" to the specific conference as identified by the to add "Bob" to the specific conference as identified by the
confObjID. The conference server ensures that "Alice" has the confObjID. The "create" operation also makes sure that "Bob" is
appropriate authority based on the policies associated with that created as a user in the whole conferencing system. This is done
specific conference object to perform the operation. A by adding a "userInfo" element describing "Bob" as a user. This
Conference User Identifier is created for Bob. is needed in order to let the conferencing system be aware of
"Bob"'s characteristics. In case Bob was already a registered
user, "Alice" would just have referenced him through his XCON
UserID, without providing the additional "userInfo". In fact,
that information (including, for instance, "Bob"'s SIP URI to be
used subsequently for dial-out) would be obtained by referencing
the extant registration. The conference server ensures that
"Alice" has the appropriate authority based on the policies
associated with that specific conference object to perform the
operation. As mentioned before, a new Conference User Identifier
is created for Bob, and the "userInfo" is used to update the
conference object accordingly.
2. The call signaling to add "Bob" to the conference is instigated 2. In the presented example, the call signaling to add "Bob" to the
through the Focus. conference is instigated through the Focus as well. Please
notice that this is implementation specific. In fact, a
conferencing system may accomplish different actions after the
user creation, just as it may do nothing at all. Among the
possible actions, for instance "Bob" may be added as a "target"
element to the "allowed-users-list" element, whose joining
"method" may be either "dial-in" or "dial-out". Besides, out-of-
band notification mechanisms may be involved as well, e.g. to
notify "Bob" via mail of the new conference, including details as
the date, password, expected participants and so on.
3. Once "Bob" has been successfully added to the specific (c) To conclude the overview on this scenario, once "Bob" has been
conference, per updates to the state, and depending upon the successfully added to the specified conference, per updates to the
policies, other participants (including "Bob") may be notified of state, and depending upon the policies, other participants
the addition of "Bob" to the conference via the Conference (including "Bob" himself) may be notified of the addition of "Bob"
Notification Service. to the conference via the Conference Notification Service.
(CCMP Messaging details not available yet). 1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo>
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:bob83@ciccio.com">
<info:display-text>Bob's laptop</info:display-text>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>create</operation>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:userResponse>
<userInfo entity="xcon-userid:bob@confSystem.com">
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:bob83@ciccio.com">
<info:display-text>Bob's laptop</info:display-text>
</info:endpoint>
</userInfo>
</ccmp:userResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 13: Add Party Message Details Figure 13: Add Party Message Details
6.4. Muting a Party 6.4. 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. The unmuting would involve the identical CCMP active conference. The unmuting would involve the identical CCMP
message flow. Although, in the case that floor control is involved, message flow. Although, in the case that floor control is involved,
whether or not a particular conference client can unmute themselves whether or not a particular conference client can unmute itself must
must be considered by the conferencing system. be considered by the conferencing system.
[Editors' Note: The interaction between CCMP and floor control
should be carefully considered. In fact, if floor control is
achieved by means of BFCP [RFC4582], this means could conflict
with the functionality provided by CCMP. A typical example would
be Alice (the CCMP moderator) unmuting Bob by means of CCMP. Such
approach would conflict with BFCP, considering that if a BFCP
chair wants to subsequently revoke the floor from Bob, it cannot
do it, since no FloorRequestID would be associated with the
previous unmute achieved by Alice. Besides, unmuting via CCMP
would bypass the Floor Control Server floor queues. How should we
handle this? Should we envisage CCMP muting/unmuting as a wrapper
to BFCP whenever floor control is involved? Another solution
might be handling CCMP- and BFCP-based media control as multiple
layers: i.e., a participant may have the BFCP floor granted, but
be muted by means of CCMP. If so, he would still be muted in the
conference, and would only be unmuted if both the protocols
allowed for this.]
Figure 14 provides an example of one client "Alice" impacting the Figure 14 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, the client, "Alice" whose established conference. In this example, the client, "Alice" whose
Role is "moderator" of the conference, wants to mute "Bob" on a Role is "moderator" of the conference, wants to mute "Bob" on a
medium-size multi-party conference, as his device is not muted (and medium-size multi-party conference, as his device is not muted (and
he's obviously not listening to the call) and background noise in his he's obviously not listening to the call) and background noise in his
office environment is disruptive to the conference. office environment is disruptive to the conference. BFCP floor
control is assumed not to be involved.
(To be added). "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS MS
| | | | |
|(1) userRequest(update, | | |
| confObjID, confUserID, | | |
| userInfo) | | | |
|------------------------------.-------->| |
| | | | Mute Bob |
| | | |----------------->|
| | | | 200 OK |
| | | |<-----------------|
| | | | |
| |<====== XXX Bob excluded from mix XXX ====>|
| | | | |
| | (a) Update +---| |
| | Bob in | | |
| | Data Model | | |
| | (muted) +-->| |
| | | | |
|(2) userResponse(update, success | |
| confObjID, confUserID) | |
|<---------------------------------------| |
| | | | |
| | | (b) Notify | |
| | | ("Bob is | |
| | | muted") | |
| | |<-----------| |
| | | | |
' ' ' ' '
' ' ' ' '
' ' ' ' '
Figure 14: Client Manipulation of Conference - Mute a party Figure 14: Client Manipulation of Conference - Mute a party
1. Upon receipt of the Conference Control Protocol request to "mute" 1. Upon receipt of userRequest message with an update operation and
a party ("Bob") in the specific conference as identified by the the userInfo with the "status" field in the "media" element for
conference object ID, the Conference Server ensures that "Alice" "Bob" set to "revconly". The Conference Server ensures that
has the appropriate authority based on the policies associated "Alice" has the appropriate authority based on the policies
with that specific conference object to perform the operation. associated with that specific conference object to perform the
"Bob"'s status is marked as "recvonly" and the conference object operation and updates the userInfo in the conference object
is updated to reflect that "Bob"s media is not to be "mixed" with reflect that "Bob"s media is not to be mixed with the conference
the conference media. In case the Conference Server relies on a media. In case the Conference Server relies on a remote Media
remote Media Server for its multimedia functionality, it Server for its multimedia functionality, it subsequently changes
subsequently changes "Bob"'s media profile accordingly by means "Bob"'s media profile accordingly by means of the related
of the related protocol interaction with the MS. An example protocol interaction with the MS. An example describing a
describing a possible way of dealing with such a situation using possible way of dealing with such a situation using the Media
the Media Server Control architecture is described in Server Control architecture is described in
[I-D.miniero-mediactrl-escs], at "Simple Bridging: Framework [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
Transactions (2)". Transactions (2)".
2. ..x Depending upon the policies, other participants (including 2. A userResponse message with a responseCode of "success" is then
"Bob") may be notified of this change via the Conference sent to "Alice". Depending upon the policies, tne conference
Notification Service. server may notify other participants (including "Bob") of this
update via the Conference Notification Service.
(CCMP Messaging details not available yet). 1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:bob@confSystem.com">
<info:endpoint entity="sip:bob83@ciccio.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 15: Mute Message Details Figure 15: Mute Message Details
6.5. Internal Sidebar 6.5. Internal Sidebar
Figure 16 provides an example of one client "Alice" involved in Figure 16 provides an example of one client "Alice" involved in
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 "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference reservation based upon the conferencing system to create a conference reservation based upon the
active conference object. "Alice" and "Bob" would remain on the active conference object. "Alice" and "Bob" would remain on the
roster of the main conference, such that other participants could be roster of the main conference, such that other participants could be
aware of their participation in the main conference, while an aware of their participation in the main conference, while an
internal-sidebar conference is occurring. internal-sidebar conference is occurring. Besides, "Bob" decides
that he is not interested in still receiving the conference audio in
background (not even at a lower volume as "Alice" configured) and so
modifies the sidebar in order to make that stream inactive for him.
(To be added). "Alice" "Bob" ConfS
| | |
|(1) sidebarByValRequest |
| (create, confUserID, |
| confObjID) | |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-val | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByValResponse | (parent mapping
| (create, success, confObjID* | conf<->sidebar)
| confUserID, sidebarByValInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByValRequest |
| (update, confUserID, |
| confObjID*, sidebarByValInfo) |
|--------------------------------------------->|
| | |
| | (b) Update +---|
| | sidebar-by-val | |
| | (media, users | |
| | etc.) +-->|
| | | Sidebar is
| | | modified
|(4) sidebarByValResponse |
| (update, success, confObjID* |
| confUserID) | |
|<---------------------------------------------|
| | |
| |(5) userRequest |
| | (update, confUserID',|
| | confObjID*, |
| | userInfo) |
| |---------------------->|
| | |
| | (c) Update +---|
| | user settings | |
| | (Bob's media) | |
| | +-->|
| | | Sidebar is modified
| | | (original audio
| | | inactive for Bob)
| |(6) userResponse |
| | (update, success |
| | confObjID*, |
| | confUserID') |
| |<----------------------|
| | |
" " "
" " "
" " "
Figure 16: Client Creation of a Sidebar Conference Figure 16: Client Creation of a Sidebar Conference
1. Upon receipt of the Conference Control Protocol request to 1. Upon receipt of CCMP sidebarByValRequest message to "reserve" a
"reserve" a new sidebar conference, based upon the active new sidebar conference based upon the confObjID received in the
conference received in the request, the conferencing system uses request, the conferencing system uses the confObjID to clone a
the received active conference to clone a conference reservation conference reservation for the sidebar. The sidebar reservation
for the sidebar. The sidebar reservation is NOT independent of is NOT independent of the active conference (i.e., parent). The
the active conference (i.e., parent). The conferencing system conferencing system also reserves or allocates a new confObjID to
also reserves or allocates a conference ID to be used for any be used for any subsequent protocol requests from any of the
subsequent protocol requests from any of the members of the members of the conference.
2. The relationship information is provided in the
sidebarByValResponse message, specifically in the "sidebar-
parent" element. A dump of the complete representation of the
main/parent conference is provided below as well to show how the
cloning process for the creation of the sidebar could take place.
3. Upon receipt of the sidebarByValResponse message to reserve the
conference, "Alice" can now create an active conference using
that reservation, or create additional reservations based upon
the existing reservations. In this example, "Alice" wants only
"Bob" to be involved in the sidebar, thus she manipulates the
membership so that only the two of them appear in the "allowed-
users-list" section. "Alice" also wants both audio and the video
from the original conference to be available in the sidebar. For
what concerns the media belonging to the sidebar itself, "Alice"
wants the audio to be restricted to the participants in the
sidebar (that is, her and "Bob"). Additionally, "Alice"
manipulates the media values to recieve the audio from the main
conference at a reduced volume, so that the communication between
her and "Bob" isn't affected. "Alice" sends a
sidebarByValRequest message with an operation of "update" along
with the sidebarByValInfo in the reservation, to create an active
conference. conference.
2. Upon receipt of the conference control protocol response to 4. Upon receipt of the sidebarByValRequest to update the reservation
reserve the conference, "Alice" can now create an active to create an active conference for the sidebar, as identified by
conference using that reservation or create additional the sidebar conference object ID, the conference server ensures
reservations based upon the existing reservations. In this that "Alice" has the appropriate authority based on the policies
example, "Alice" wants only "Bob" to be involved in the sidebar, associated with that specific conference object to perform the
thus she manipulates the membership. "Alice" also only wants the operation. The conference server must also validate the updated
video from the original conference and wants the audio to be information in the reservation, ensuring that a member like "Bob"
restricted to the participants in the sidebar. Alternatively, is already a user of this conference server. Once the data for
"Alice" could manipulate the media values to recieve the audio the confObjID is updated, the conference server sends a
from the main conference at a reduced volume. "Alice" sends a sidebarByValResponse to "Alice". Depending upon the policies,
conference control protocol request to update the information in the initiator of the request (i.e., "Alice") and the participants
the reservation and to create an active conference. in the sidebar (i.e., "Bob") may be notified of his addition to
the sidebar via the conference notification service.
3. Upon receipt of the conference control protocol request to update 5. At this point, "Bob" sends a userRequest message to the
the reservation and to create an active conference for the conference server with an operation of "update" to completely
sidebar, as identified by the conference object ID, the disable the background audio from the parent conference, since it
conferencing system ensures that "Alice" has the appropriate prevents him from understanding what "Alice" says in the sidebar.
authority based on the policies associated with that specific
conference object to perform the operation. The conferencing
system must also validate the updated information in the
reservation, ensuring that a member like "Bob" is already a user
of this conferencing system.
4. ..x. Depending upon the policies, the initiator of the request 6. Notice that "Bob's" request only changes the media perspective
(i.e., "Alice") and the participants in the sidebar (i.e., "Bob") for "Bob". "Alice" keeps on receiving both the audio from "Bob"
may be notified of his addition to the sidebar via the conference and the background from the parent conference. This request may
notification service. be relayed by the conference server to the Media Server handling
the mixing, if present. Upon completion of the change, the
conference server sends a "userResponse" message to "Bob".
Depending upon the policies, the initiator of the request (i.e.,
"Bob") and the participants in the sidebar (i.e., "Alice") may be
notified of this change via the conference notification service.
(CCMP Messaging details not available yet). That said, let's consider the following conference object:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<info:conference-info
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="xcon:8977878@confSystem.com">
<info:conference-description>
<info:display-text>MAIN CONFERENCE</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8977878@confSystem.com</info:uri>
<info:display-text>conference sip uri</info:display-text>
</info:entry>
</info:conf-uris>
<info:available-media>
<info:entry label="123">
<info:display-text>main conference audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>main conference video</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
<xcon:controls>
<xcon:video-layout>single-view</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>true</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:alice@confSystem.com">
<info:display-text>Alice</info:display-text>
<info:endpoint entity="sip:alice@wonderland.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:bob@confSystem.com">
<info:display-text>Bob</info:display-text>
<info:endpoint entity="sip:bob83@ciccio.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:carol@confSystem.com">
<info:display-text>Carol</info:display-text>
<info:endpoint entity="sip:carol@pippozzo.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
</info:users>
</info:conference-info>
This is the representation of the conference the sidebar is going to
be created in. As such, it will be used by the conferencing system
in order to create the new conference object associated with the
sidebar. In fact, the sidebar creation happens through a cloning of
the parent conference. Once the sidebar is created, an "update"
makes sure that the sidebar is customized as needed. The following
protocol dump makes the process clearer.
1. sidebarByValRequest (create)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByValResponse (create success)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@confSystem.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by alice
</info:display-text>
<xcon:sidebar-parent>
xcon:8977878@confSystem.com
</xcon:sidebar-parent>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:alice@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:carol@confSystem.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByValRequest (update)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@confSystem.com">
<info:conference-description>
<info:display-text>
private sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
<xcon:controls>
<xcon:gain>-60</xcon:gain>
</xcon:controls>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="sidebarAudioLabel">
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="sidebarVideoLabel">
<info:display-text>
sidebar video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
4. sidebarByValResponse (update success)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:sidebarByValResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
5. userRequest (Bob's media)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:bob@confSystem.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:bob@confSystem.com">
<info:endpoint entity="sip:bob83@ciccio.com">
<info:media id="1">
<info:display-text>
main conference audio
</info:display-text>
<info:label>123</info:label>
<info:status>inactive</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
6. userResponse (update success)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:bob@confSystem.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 17: Internal Sidebar Messaging Details Figure 17: Internal Sidebar Messaging Details
6.6. External Sidebar 6.6. External Sidebar
Figure 18 provides an example of one client "Alice" involved in an Figure 18 provides an example of a different approach towards
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 gets an important text message via a whisper from "Bob" that a
critical customer needs to talk to "Alice", "Bob" and "Ethel". critical customer needs to talk to "Alice", "Bob" and "Ethel".
"Alice" creates a sidebar to have a side discussion with the customer "Alice" creates a sidebar to have a side discussion with the customer
"Fred" including the participants in the current conference with the "Fred" including the participants in the current conference with the
exception of "Carol" and "David", who remain in the active exception of "Carol" and "David", who remain in the active
conference. "Alice" initiates the sidebar by sending a request to conference. The difference from the previous scenario is that "Fred"
the conferencing system to create a conference reservation based upon is not part of the parent conference: this means that different
the active conference object. "Alice", "Bob" and "Ethel" would policies might be involved, considering that "Fred" may access
remain on the roster of the main conference in a hold state. Whether information coming from the parent conference, in case the sidebar
or not the hold state of these participants is visible to other was configured accordingly. For this reason, in this scenario we
participants depends upon the individual and local policy. assume that "Alice" disables all the media from the original (parent)
conference within the sidebar. This means that, while in the
previous example "Alice" and "Bob" still heard the audio from the
main conference in background, this time no background is made
available. "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference reservation based upon the
active conference object. "Alice", "Bob" and "Ethel" would remain on
the roster of the main conference in a hold state. Whether or not
the hold state of these participants is visible to other participants
depends upon the individual and local policy.
(To be Detailed). "Alice" "Bob" ConfS
| | |
|(1) sidebarByRefRequest |
| (create, confUserID, |
| confObjID) | |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-ref | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByRefResponse | (parent mapping
| (create, success, confObjID* | conf<->sidebar)
| confUserID, sidebarByRefInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByRefRequest |
| (update, confUserID, |
| confObjID*, sidebarByRefInfo) |
|--------------------------------------------->|
| | |
| | (b) Create +---|
| | new user for | |
| | "Fred" | |
| | +-->|
| | |
| | (c) Update +---|
| | sidebar-by-val | |
| | (media, users | |
| | policy, etc.) +-->|
| | | Sidebar is modified:
| | | no media from the
| | | parent conference is
| | | available to anyone
|(4) sidebarByRefResponse |
| (update, success, confObjID* |
| confUserID) | |
|<---------------------------------------------|
| | |
| | Notify ("Fred" |
| | added to |
| | sidebar users) |
| |<----------------------|
| | |
" " "
" " "
" " "
Figure 18: Client Creation of an External Sidebar Figure 18: Client Creation of an External Sidebar
1. Upon receipt of the confRequest message to "reserve" a new 1. Upon receipt of the "sidebarByRefRequest" message to create a new
sidebar conference, based upon the active conference received in sidebar conference, based upon the active conference specified by
the request, the conferencing system uses the received active "confObjID" in the request, the conferencing system uses the
conference to clone a conference reservation for the sidebar. received active conference to clone a conference reservation for
The sidebar reservation is NOT independent of the active the sidebar. The sidebar reservation is NOT independent of the
conference (i.e., parent). The conferencing system also reserves active conference (i.e., parent). The conferencing system as
or allocates a conference ID to be used for any subsequent before reserves or allocates a conference ID (confObjID*) to be
protocol requests from any of the members of the conference. The used for any subsequent protocol requests from any of the members
conferencing system maintains the mapping between this conference of the conference. The conferencing system maintains the mapping
ID and the conference object ID associated with the sidebar between this conference ID and the conference object ID
reservation through the conference instance. associated with the sidebar reservation through the conference
instance. Just as before, this mapping is mantained in "sidebar-
parent".
2. Upon receipt of the confResponse message, "Alice" wants only 2. Upon receipt of the "sidebarByRefResponse" message, which
"Bob" and "Ethel", along with the new participant "Fred" to be acknowledges the successful creation of the sidebar object,
involved in the sidebar, thus she manipulates the membership. "Alice" decides that only "Bob" and "Ethel", along with the new
"Alice" sets the media in the conference-info such that the participant "Fred" are to be involved in the sidebar. Thus she
participants in the sidebar don't receive any media from the main manipulates the membership accordingly. "Alice" also sets the
conference. media in the "conference-info" such that the participants in the
sidebar don't receive any media from the main conference. All
these settings are provided to the conferencing system by means
of a new "sidebarByRefRequest" message, with an "update"
operation.
3. "Alice" sends a confRequest to update the information in the 3. "Alice" sends the aforementioned "sidebarByRefRequest" to update
reservation and to create an active conference. Upon receipt of the information in the reservation and to create an active
the confRequest with an operation of "update", the conferencing conference. Upon receipt of the "sidebarByRefRequest" with an
system ensures that "Alice" has the appropriate authority based operation of "update", the conferencing system ensures that
on the policies associated with that specific conference object "Alice" has the appropriate authority based on the policies
to perform the operation. The conferencing system also validates associated with that specific conference object to perform the
the updated information in the reservation. Since "Fred" is a operation. The conferencing system also validates the updated
new user for this conferencing system, a conference user information in the reservation. Since "Fred" is a new user for
identifier is created for "Fred". Based upon the addressing this conferencing system, a conference user identifier is created
for "Fred". Specifically, "Fred" is added to the conference by
only providing his SIP URI. Based upon the addressing
information provided for "Fred" by "Alice", the call signaling to information provided for "Fred" by "Alice", the call signaling to
add "Fred" to the conference is instigated through the Focus. add "Fred" to the conference may be instigated through the Focus
(e.g. if "Fred" had a "dial-out" method set as the target for
him) at the actual activation of the sidebar.
4. ..x. The conference server sends a confResponse message and 4. The conference server sends a "sidebarByRefResponse" message and,
depending upon the policies, the initiator of the request (i.e., depending upon the policies, the initiator of the request (i.e.,
"Alice") and the participants in the sidebar (i.e., "Bob" and "Alice") and the participants in the sidebar (i.e., "Bob" and
"Ethel") may be notified of his addition to the sidebar via the "Ethel") may be notified of his addition to the sidebar via the
conference notification service. conference notification service.
(CCMP Messaging details not available yet). 1. sidebarByRefRequest (create)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID>
<operation>create</operation>
<ccmp:sidebarsByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByRefResponse (create success)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@confSystem.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by alice
</info:display-text>
<xcon:sidebar-parent>
xcon:8977878@confSystem.com
</xcon:sidebar-parent>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:alice@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:carol@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:david@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:ethel@confSystem.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByRefRequest (update)
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971212@confSystem.com">
<info:conference-description>
<info:display-text>
sidebar alice, bob, ethel & fred
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>inactive</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>inactive</info:status>
</info:entry>
<info:entry>
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry>
<info:display-text>
sidebar video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
<xcon:controls>
<xcon:video-layout>
single-view
</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@confSystem.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/>
<xcon:target method="dial-out"
uri="sip:fred@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
4. sidebarByRefResponse (update success)
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 19: External Sidebar Messaging Details Figure 19: External Sidebar Messaging Details
6.7. Floor control using sidebars 6.7. Floor control using sidebars
Floor control with sidebars can be used to realize conferencing Floor control with sidebars can be used to realize conferencing
scenario such as an analyst briefing. In this scenario, the scenario such as an analyst briefing. In this scenario, the
conference call has a panel of speakers who are allowed to talk in conference call has a panel of speakers who are allowed to talk in
the main conference. The other participants are the analysts, who the main conference. The other participants are the analysts, who
are not allowed to speak unless they have the floor. To request are not allowed to speak unless they have the floor. To request
skipping to change at page 34, line 16 skipping to change at page 55, line 16
7.1. Removing a Party 7.1. Removing a Party
Figure 26 provides an example of one client "Alice" removing another Figure 26 provides an example of one 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 established conference with "Alice", "Bob", "Claire" and "Duck". In
this example, "Alice" wants to remove "Bob" from the conference so this example, "Alice" wants to remove "Bob" from the conference so
that the group can continue in the same conference without "Bob"'s that the group can continue in the same conference without "Bob"'s
participation. participation.
(Figure not available yet). "Alice" "Bob" "Claire" ConfS
| | | |
|(1) userRequest(delete, | |
| confObjID, confUserID, | |
| userInfo) | | |
|-------------------------------------->|
| | | |
| | | (a) Focus |
| | | tears down|
| | | signaling |
| | | to "Bob" |
| |<----------------------|
| | |
| | (b)Deletes+---|
| | | "Bob" | |
| | | as a | |
| | | user +-->|
| | | in |
| | | confObj |
| | | |
|(2) userResponse(delete, success |
| confObjID) | |
| | | |
|<--------------------------------------|
| | | |
| | | |
| | | (c) Notify|
| | | ("Bob just|
| | | left") |
| | |<----------|
| | | |
' ' ' '
' ' ' '
' ' ' '
Figure 26: Client Manipulation of Conference - Remove a party Figure 26: Client Manipulation of Conference - Remove a party
1. "Alice" sends a userRequest message, with a "delete" operation. 1. "Alice" sends a userRequest message, with a "delete" operation.
The conference server ensures that "Alice" has the appropriate The conference server ensures that "Alice" has the appropriate
authority based on the policies associated with that specific authority based on the policies associated with that specific
conference object to perform the operation. conference object to perform the operation.
2. Based upon the addressing and media information in the conference 2. Based upon the addressing and media information in the conference
object for "Bob" in the "user" element, the conference instigates object for "Bob" in the "user" element, the conference instigates
the process to remove "Bob" (e.g., the call signaling to remove the process to remove "Bob" (e.g., the call signaling to remove
"Bob" from the conference is instigated through the Focus). The "Bob" from the conference is instigated through the Focus). The
conference server updates the data in the conference object, thus conference server updates the data in the conference object, thus
removing "Bob" from the "users" list and a userResponse message removing "Bob" from the "users" list. After updating the data,
is sent to "Alice". Depending upon the policies, other the conference server sends a userResponse message to "Alice".
participants (including "Bob") may be notified of the removal of Depending upon the policies, other participants (e.g. "Claire")
"Bob" from the conference via the Conference Notification may be notified of the removal of "Bob" from the conference via
Service. the Conference Notification Service.
(CCMP Messaging details not available yet). (CCMP Messaging details not available yet).
Figure 27: Removing a Participant Messaging Details Figure 27: Removing a Participant Messaging Details
7.2. Deleting a Conference 7.2. Deleting a Conference
Details to be added. Details to be added.
(Figure not available yet). (Figure not available yet).
skipping to change at page 43, line 40 skipping to change at page 65, line 35
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 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 initial examples. o Added protocol details to many of the examples.
o Editorial: Simplifying intro, terms, etc. o Editorial: Simplifying intro, terms, etc.
The following are the major changes between the 00 and the 01 The following are the major changes between the 00 and the 01
versions of the draft: versions of the draft:
o Updates to reflect change of CCMP to HTTP transport model. o Updates to reflect change of CCMP to HTTP transport model.
12. Acknowledgements 12. Acknowledgements
skipping to change at page 45, line 14 skipping to change at page 67, line 8
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-13 Conferencing (XCON)", draft-ietf-xcon-common-data-model-13
(work in progress), April 2009. (work in progress), April 2009.
[I-D.miniero-mediactrl-escs] [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-miniero-mediactrl-escs-03 (work in Examples", draft-ietf-mediactrl-call-flows-00 (work in
progress), November 2008. progress), March 2009.
[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-07 (work in draft-ietf-mediactrl-mixer-control-package-07 (work in
progress), May 2009. progress), May 2009.
[I-D.boulton-xcon-session-chat] [I-D.boulton-xcon-session-chat]
Boulton, C. and M. Barnes, "Chatrooms within a Centralized Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
Conferencing (XCON) System", a Centralized Conferencing (XCON) System",
draft-boulton-xcon-session-chat-03 (work in progress), draft-boulton-xcon-session-chat-04 (work in progress),
March 2009. July 2009.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Lorenzo Miniero Lorenzo Miniero
Meetecho
Via Carlo Poerio 89/a
Napoli 80121
Italy
Email: lminiero@meetecho.com
Roberta Presta
University of Napoli University of Napoli
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
Italy Italy
Email: lorenzo.miniero@unina.it Email: roberta.presta@unina.it
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
Italy Italy
Email: spromano@unina.it Email: spromano@unina.it
 End of changes. 117 change blocks. 
250 lines changed or deleted 1171 lines changed or added

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