draft-ietf-xcon-examples-01.txt   draft-ietf-xcon-examples-02.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 14, 2010 NS-Technologies Expires: July 2, 2010 NS-Technologies
L. Miniero L. Miniero
Meetecho Meetecho
R. Presta R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
July 13, 2009 December 29, 2009
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-01.txt draft-ietf-xcon-examples-02
Abstract
This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol
researchers and developers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted 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 38 skipping to change at page 1, line 48
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 14, 2010. This Internet-Draft will expire on July 2, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides detailed call flows for the scenarios described in the BSD License.
documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol
researchers and developers.
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 . . . . . . . . . . . . . . . . . . 11 Conference Information . . . . . . . . . . . . . . . . . . 11
5.3. Basic Conference Creation - Cloning an existing 5.3. Basic Conference Creation - Cloning an existing
Conference . . . . . . . . . . . . . . . . . . . . . . . . 15 Conference . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Conference Creation using Blueprints . . . . . . . . . . . 18 5.4. Conference Creation using Blueprints . . . . . . . . . . . 18
6. General Conference scenarios and examples . . . . . . . . . . 25 6. General Conference scenarios and examples . . . . . . . . . . 25
6.1. Conference Announcements and Recordings . . . . . . . . . 25 6.1. Conference Announcements and Recordings . . . . . . . . . 25
6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 28 6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 29
6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 31 6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 33
6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 36 6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 37
6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 45 6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 46
6.7. Floor control using sidebars . . . . . . . . . . . . . . . 51 6.7. Floor control using sidebars . . . . . . . . . . . . . . . 52
6.8. Whispering or Private Messages . . . . . . . . . . . . . . 52 6.8. Whispering or Private Messages . . . . . . . . . . . . . . 53
6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 53 6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 56
7. Removing participants and deleting conferences . . . . . . . . 54 7. Removing participants and deleting conferences . . . . . . . . 62
7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 55 7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 62
7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 56 7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 65
8. Additional Conference Scenarios and Examples . . . . . . . . . 57 8. Additional Conference Scenarios and Examples . . . . . . . . . 67
8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 58 8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 68
8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 62 8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 72
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76
11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 65 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 76
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.1. Normative References . . . . . . . . . . . . . . . . . . . 66 13.1. Normative References . . . . . . . . . . . . . . . . . . . 78
13.2. Informative References . . . . . . . . . . . . . . . . . . 66 13.2. Informative References . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79
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 6, line 34 skipping to change at page 6, line 34
an XCON-URI in the form of the "confObjID" parameter, the XCON-UserID an XCON-URI in the form of the "confObjID" parameter, the XCON-UserID
in the form of the "confUserID" parameter (the same already present in the form of the "confUserID" parameter (the same already present
in the request) and the data for the conference object in the in the request) and the data for the conference object in the
"confInfo" parameter all returned in the "confResponse" message. "confInfo" parameter all returned in the "confResponse" message.
According to the implementation of the framework, this example may According to the implementation of the framework, this example may
also add the user that invoked the conference upon creation to the also add the user that invoked the conference upon creation to the
conference object (e.g., "method" attribute in the "target" element conference object (e.g., "method" attribute in the "target" element
of "allowed-users-list" may be set to "dial out" for this client of "allowed-users-list" may be set to "dial out" for this client
based on the particular conferencing systems default). This is based on the particular conferencing systems default). This is
exactly the case depicted in the figure, which is presented to enrich exactly the case depicted in the figure, which is presented to enrich
the scenario. Note, that depending upon the conferencing system, the scenario. Note that, depending upon the conferencing system,
this default conference could be specific to the client requesting this default conference could be specific to the client requesting
the conference and thus may be different for the initiator than other the conference and thus may be different for the initiator than other
participants (e.g., IVR interactions in this case which are not participants (e.g., IVR interactions in this case which are not
shown). 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. Please notice that, according to CCMP
specification, the restitution of the new conference data in the
"confInfo" parameter is not mandatory: if the "confInfo" parameter of
the successful confResponse/create is void, a following confRequest/
retrieve of the returned "confObjID" can be triggered to provide the
requesting client with the detailed conference description.
Clients that are not XCON-aware may join the conference using a Clients that are not XCON-aware may join the conference using a
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(create, confUserID) | | |(1)confRequest(confUserID, create) | |
|-------------------------------------->| | |-------------------------------------->| |
| | (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(confUserID,confObjID, | |
| confObjID, confUserID | | | create, success, | |
| confInfo) | | | | version, confInfo) | |
|<--------------------------------------| | |<--------------------------------------| |
| | | | | | | | | |
| | (c) Focus +---| | | | (c) Focus +---| |
| | sets up | | | | | sets up | | |
| | signaling | | | | | signaling | | |
| | to CMCC1 +-->| | | | to CMCC1 +-->| |
| | | | | | | | | |
| | | | B1. CONTROL | | | | | B1. CONTROL |
| | | |+++++++++++>>| | | | |+++++++++++>>|
| | | | (join CMCC1 | | | | | (join CMCC1 |
skipping to change at page 9, 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(create, confUserID) | |(1)confRequest(confUserID, create) |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | (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(confUserID, confObjID |
| confObjID, confUserID | | create, success, |
| confInfo) | | | version, confInfo) |
| | | |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | | | | | |
| | (c) Focus +---| | | (c) Focus +---|
| | sets up | | | | sets up | |
| | signaling | | | | signaling | |
| | to CMCC1 +-->| | | to CMCC1 +-->|
| | | | | | | |
| | | |--+(d) MS joins | | | |--+(d) MS joins
| | | | | CMCC1 & | | | | | CMCC1 &
skipping to change at page 10, line 5 skipping to change at page 10, line 5
| | | | | | | |
|**CMCC1 then manipulates conference****| |**CMCC1 then manipulates conference****|
|** data and add addt'l users, etc. ***| |** data and add addt'l users, etc. ***|
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
- -
Figure 2: Create Basic Conference - Annotated Flow Figure 2: Create Basic Conference - Annotated Flow
1. confRequest message: 1. confRequest/create 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> <confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation> <operation>create</operation>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message: 2. confResponse/create 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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID>
<ccmp:response-code>success</ccmp:response-code> <operation>create</operation>
<response-code>success</response-code>
<version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@confSystem.com"> <confInfo entity="xcon:8977794@example.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@confSystem.com xcon:8977794@example.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-state>
<active>false</active>
</info:conference-state>
</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="xcon-userid:alice@confSystem.com" <xcon:target uri="xcon-userid:Alice@example.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. The request, as is the case of all CCMP conference to be created. The request also includes the "confUserID"
requests, also includes the "confUserID" of the requesting entity. of the requesting entity. If the conferencing system can support
If the conferencing system can support that specific type of that specific type of conference (capabilities, etc.), then the
conference (capabilities, etc.), then the request results in the request results in the creation of a conference. In this success
creation of a conference. In this success case, an XCON-URI in the case, an XCON-URI in the form of the "confObjID" parameter and the
form of the "confObjID" parameter and the XCON-UserID in the form of XCON-UserID in the form of the "confUserID" parameter (again, the
the "confUserID" parameter (again, the same as the requesting entity) same as the requesting entity) are returned in the "confResponse"
are returned in the "confResponse" message. The "confInfo" is not message. In this example, we choose not to return the created
returned unless changes have been made, in which case the conference object in the successful "confResponse" in the "confInfo"
"responseCode" is "modified". parameter.
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). Just as before, this is particular conferencing systems default). Just as before, this is
not to be considered mandatory, since it depends on the not to be considered mandatory, since it depends on the
implementation choices of the framework. Note, that depending upon 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 | | | | | | |
| (create, confUserID, confInfo) | |(1)confRequest(confUserID, | |
| create, 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(confUserID | |
| (create, success, confObjID | | confObjID, create, | |
| confUserID)| | | | success, version) | |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | (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 13, line 29 skipping to change at page 13, line 37
| | | | | | | |
|<***All parties connected to conf Y***>| |<***All parties connected to conf Y***>|
| | | | | | | |
| | | | | | | |
" " " " " " " "
" " " " " " " "
" " " " " " " "
Figure 4: Create Basic Conference from user provided conference-info Figure 4: Create Basic Conference from user provided conference-info
1. confRequest message: 1. confRequest/create 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</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest> <ccmp:confRequest>
<confInfo entity="xcon:8977794@confSystem.com"> <confInfo>
<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:entry>
<info:uri>
xcon:8977794@confSystem.com
</info:uri>
<info:display-text>
Conference XCON-URI
</info:display-text>
</info:entry>
</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>
<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@wonderland.com" <xcon:target uri="sip:alice@example.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:bob83@ciccio.com" <xcon:target uri="sip:bob83@example.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:carol@pippozzo.com" <xcon:target uri="sip:carol@example.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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice</confUserID> <confObjID>xcon:6845432@example.com</confObjID>
<ccmp:response-code>success</ccmp:response-code> <operation>create</operation>
<response-code>success<response-code>
<version>1</version>
</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 reservation.
In this example, the client sends a "confRequest" message with the In this example, the client sends a "confRequest" message with the
"create" operation, along with the "confUserID" and a specific "create" operation, along with the "confUserID" and a specific
"confObjID", from which a new conference is to be created by cloning "confObjID", from which a new conference is to be created by cloning
an existing conference. an existing conference.
An example of how a client can create a conference based on a An example of how a client can create a conference based on a
blueprint is provided in Section 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).
If the conferencing system can support a new instance of the specific If the conferencing system can support a new instance of the specific
type of conference(capabilities, etc.), then the request results in type of conference(capabilities, etc.), then the request results in
the creation of a conference, with an XCON-URI in the form of a new the creation of a conference, with an XCON-URI in the form of a new
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.
"confInfo" is not returned unless there had been changes, in which
case the "responseCode" is "modified".
"Alice" ConfS "Alice" ConfS
| | | |
|(1) confRequest (create, | |(1)confRequest(confUserID, |
| confObjID, confUserId) | | confObjID, create) |
|------------------------------>| |------------------------------>|
| (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(confUserID, |
| ( create, success, | | confObjID*,create, |
| confObjID*, confUserID) | | success, version, |
| confInfo) |
| |
|<------------------------------| |<------------------------------|
| | | |
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 cloned from the specified 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.
skipping to change at page 17, line 7 skipping to change at page 17, line 9
from the one associated with the conference to be cloned, since from the one associated with the conference to be cloned, since
it represents a different conference object. Any subsequent it represents a different conference object. Any subsequent
protocol requests from any of the members of the conference must protocol requests from any of the members of the conference must
address this new identifier. The conferencing system maintains address this new identifier. The conferencing system maintains
the mapping between this conference ID and the parent conference the mapping between this conference ID and the parent conference
object ID associated with the reservation through the conference object ID associated with the reservation through the conference
instance, and this mapping is explicitly addressed through the instance, and this mapping is explicitly addressed through the
"cloning-parent" element of the "conference-description" in the "cloning-parent" element of the "conference-description" in the
new conference object. new conference object.
1. confRequest message: 1. confRequest/create 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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice</confUserID> <confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message: 2. confResponse/create 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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice</confUserID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@confSystem.com"> <confInfo entity="xcon:8977794@example.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:cloning-parent>
xcon:6845432@confSystem.com xcon:6845432@example.com
</xcon:cloning-parent> </xcon:cloning-parent>
<info:conf-uris>
<info:entry>
<info:uri>
xcon:8977794@confSystem.com
</info:uri>
<info:display-text>
conference xcon-uri
</info:display-text>
<xcon:conference-password>
8601
</xcon:conference-password>
</info:entry>
</info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info: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:target uri="sip:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:bob83@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
</xcon:allowed-users-list>
</info:users> </info:users>
<xcon:floor-information> <xcon:floor-information>
<xcon:floor-request-handling> <xcon:floor-request-handling>
confirm</xcon:floor-request-handling> confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="11"/> <xcon:floor id="11"/>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
skipping to change at page 19, line 18 skipping to change at page 19, line 18
| blueprintsInfo) | | blueprintsInfo) |
|<------------------------------| |<------------------------------|
| | | |
|--+ | |--+ |
| | choose preferred | | | choose preferred |
| | blueprint from the | | | blueprint from the |
| | list (blueprintName) | | | list (blueprintName) |
|<-+ | |<-+ |
| | | |
| (3) blueprintRequest | | (3) blueprintRequest |
| (retrieve, confObjID, | | (confUserID,confObjID, |
| confUserID) | | retrieve) |
|------------------------------>| |------------------------------>|
| | | |
| (4) blueprintResponse | | 4) blueprintResponse |
| (success, confObjID,| | (confUserID,confObjID,|
| confUserID,confInfo)| | retrieve,confInfo) |
|<------------------------------| |<------------------------------|
| | | |
| (5) confRequest (create, | | (5) confRequest(confUserID, |
| confobjID) | | confObjID,create) |
|------------------------------>| |------------------------------>|
| | | |
| (a)Create +---| | (a)Create +---|
| Conf | | | Conf | |
| Object | | | Object | |
| & IDs +-->| | & IDs +-->|
| |--+ (b) MS | |--+ (b) MS
| | | creates | | | creates
| | | conf and | | | conf and
| |<-+ its ID | |<-+ its ID
skipping to change at page 20, line 41 skipping to change at page 20, line 41
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" (again called clone a conference, allocating a new "confObjID" (again called
"confObjID* in the example). The conferencing server then sends "confObjID* in the example). The conferencing server then sends
a "confResponse" message including the new "confObjID*" a "confResponse" message including the new "confObjID*"
associated with the newly created conference instance. Upon associated with the newly created conference instance. Upon
receipt of the "confResponse" message, "Alice" can now add other receipt of the "confResponse" message, "Alice" can now add other
users to the conference . users to the conference .
[Editors' Note: unlike what happened when cloning an existing 1. blueprintsRequest message
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:
<?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@example.com</confUserID>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintsResponse message: 2. blueprintsResponse 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-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:AudioRoom@confSystem.com</info:uri> <info:uri>xcon:AudioRoom@example.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@confSystem.com</info:uri> <info:uri>xcon:VideoRoom@example.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@confSystem.com</info:uri> <info:uri>xcon:AudioConference1@example.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@confSystem.com</info:uri> <info:uri>xcon:VideoConference1@example.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@confSystem.com</info:uri> <info:uri>xcon:AudioConference2@example.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>
</ccmp:blueprintsResponse> </ccmp:blueprintsResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
3. blueprintRequest message: 3. blueprintRequest/retrieve 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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice</confUserID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:blueprintRequest/> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. blueprintResponse message: 4. blueprintResponse/retrieve 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">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<confObjID>xcon:AudioRoom@confSystem.com</confObjID> <response-code>success</response-code>
<confUserID>xcon-userid:Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="AudioRoom"> <blueprintInfo entity="xcon:AudioRoom@example.com">
<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>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
skipping to change at page 23, line 42 skipping to change at page 23, line 37
</xcon:floor-request-handling> </xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</blueprintInfo> </blueprintInfo>
</ccmp:blueprintResponse> </ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
5. confRequest message: 5. confRequest/create 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@example.com</confUserID>
<confObjID>xcon:AudioRoom@confSystem.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<confUserID>xcon-userid:Alice</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest/> <ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
6. confResponse message: 6. confResponse/create 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@confSystem.com</confObjID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice</confUserID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@confSystem.com"> <confInfo entity="xcon:8977794@example.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@confSystem.com xcon:8977794@example.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 26, line 7 skipping to change at page 26, line 7
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. A very similar example is presented in Figure 33 of participants. A very similar example is presented in Figure 33 of
[I-D.ietf-mediactrl-call-flows]. [I-D.ietf-mediactrl-call-flows].
CCMC "Alice" ConfS MS CCMC "Alice" ConfS MS
| | | | | |
|(1)userRequest (create, | | |(1)userRequest(confUserID, | |
| confObjID, userInfo) | | | confObjID,create,userInfo) |
|--------------------------->| | |--------------------------->| |
| |--+ Alice is | | |--+ Alice is |
| | | new in the | | | | new in the |
| |<-+ system (create | | |<-+ system (create |
| | confUserID) | | | confUserID) |
| ConfS handles +--| | | ConfS handles +--| |
| SIP signaling | | | | SIP signaling | | |
| (Alice<->ConfS<->MS) +->| | | (Alice<->ConfS<->MS) +->| |
| | | | | |
| |--+ A password is | | |--+ A password is |
skipping to change at page 26, line 47 skipping to change at page 26, line 47
| |--------------------------->| | |--------------------------->|
| | | | | |
|<========= MS records Alice's audio RTP (name) =========>| |<========= MS records Alice's audio RTP (name) =========>|
| | | | | |
| | Audio recording | | | Audio recording |
| |<---------------------------| | |<---------------------------|
| Complete +--| | | Complete +--| |
| creation | | | | creation | | |
| of Alice +->| | | of Alice +->| |
| | | | | |
| (2) userResponse | | | | |
| (create, success | | | (2)userResponse(confUserID,| |
| confObjID, confUserID) | | confObjID, create, | |
| success, version) | |
|<---------------------------| | |<---------------------------| |
| | | | | |
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". This may be achieved by means of typical IVR "Alice". This may be achieved by means of typical IVR
skipping to change at page 27, line 36 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, 1. userRequest/create message (Alice tries to enter the conference without providing the password)
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). <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse/create message ("passwordRequired")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:response-code>passwordRequired</ccmp:response-code>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
3. userRequest/create message (Alice provides the password)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<password>8601</password>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
4. userResponse/create message ("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:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>success</response-code>
<version>10</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
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.
skipping to change at page 29, line 8 skipping to change at page 30, line 18
In this example, "Alice" wants to add "Bob" to an established In this example, "Alice" wants to add "Bob" to an established
conference. In the following example we assume "Bob" is a new user conference. In the following example we assume "Bob" is a new user
to the system, which means "Alice" also needs to provide details 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 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 the conferencing system is much easier to address, and will be
discussed later on. discussed later on.
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS CMCC1 CMCC2 CMCCx ConfS
| | | | | | | |
|(1) userRequest(create, | | |(1) userRequest(confUserID,| |
| confObjID, confUserID, | | | confObjID, create, | |
| userInfo) | | | | userInfo) | | |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | (a) Create +---| | | (a) Create +---|
| | | "Bob" | | | | | "Bob" | |
| | | as a | | | | | as a | |
| | | user +-->| | | | user +-->|
| | | | | | | |
|(2) userResponse(create, success | |(2) userResponse(confUserID,confObjID |
| confObjID, confUserID | | create,success,userInfo) |
| userInfo) | |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | (b) Focus | | | | (b) Focus |
| | | sets up | | | | sets up |
| | | signaling | | | | signaling |
| | | to "Bob" | | | | to "Bob" |
| |<----------------------| | |<----------------------|
| | | | | | | |
| | | (c) Notify| | | | (c) Notify|
| | | ("Bob just| | | | ("Bob just|
skipping to change at page 30, line 22 skipping to change at page 31, line 35
notice that this is implementation specific. In fact, a notice that this is implementation specific. In fact, a
conferencing system may accomplish different actions after the conferencing system may accomplish different actions after the
user creation, just as it may do nothing at all. Among the user creation, just as it may do nothing at all. Among the
possible actions, for instance "Bob" may be added as a "target" possible actions, for instance "Bob" may be added as a "target"
element to the "allowed-users-list" element, whose joining element to the "allowed-users-list" element, whose joining
"method" may be either "dial-in" or "dial-out". Besides, out-of- "method" may be either "dial-in" or "dial-out". Besides, out-of-
band notification mechanisms may be involved as well, e.g. to band notification mechanisms may be involved as well, e.g. to
notify "Bob" via mail of the new conference, including details as notify "Bob" via mail of the new conference, including details as
the date, password, expected participants and so on. the date, password, expected participants and so on.
(c) To conclude the overview on this scenario, once "Bob" has been To conclude the overview on this scenario, once "Bob" has been
successfully added to the specified conference, per updates to the successfully added to the specified conference, per updates to the
state, and depending upon the policies, other participants state, and depending upon the policies, other participants
(including "Bob" himself) may be notified of the addition of "Bob" (including "Bob" himself) may be notified of the addition of "Bob"
to the conference via the Conference Notification Service. to the conference via the Conference Notification Service.
1. userRequest message: 1. userRequest/create message (Alice adds Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo> <userInfo>
<info:display-text>Bob</info:display-text> <info:display-text>Bob</info:display-text>
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri> <info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text> <info:display-text>Bob's email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:bob83@ciccio.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse message: 2. userResponse/create message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpResponse 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">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>10</version>
<ccmp:userResponse> <ccmp:userResponse>
<userInfo entity="xcon-userid:bob@confSystem.com"> <userInfo entity="xcon-userid:Bob@example.com">
<info:display-text>Bob</info:display-text> <info:display-text>Bob</info:display-text>
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri> <info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text> <info:display-text>Bob's email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:bob83@ciccio.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userResponse> </ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 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 itself must whether or not a particular conference client can unmute itself must
be considered by the conferencing system. be considered by the conferencing system.
skipping to change at page 32, line 5 skipping to change at page 33, line 14
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 itself must whether or not a particular conference client can unmute itself must
be considered by the conferencing system. be considered by the conferencing system.
[Editors' Note: The interaction between CCMP and floor control Please notice that interaction between CCMP and floor control
should be carefully considered. In fact, if floor control is should be carefully considered. In fact, handling CCMP- and BFCP-
achieved by means of BFCP [RFC4582], this means could conflict based media control has to be considered as multiple layers: i.e.,
with the functionality provided by CCMP. A typical example would a participant may have the BFCP floor granted, but be muted by
be Alice (the CCMP moderator) unmuting Bob by means of CCMP. Such means of CCMP. If so, he would still be muted in the conference,
approach would conflict with BFCP, considering that if a BFCP and would only be unmuted if both the protocols allowed for this.
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. BFCP floor office environment is disruptive to the conference. BFCP floor
control is assumed not to be involved. control is assumed not to be involved.
"Alice" "Bob" "Alice" "Bob"
CMCC1 CMCC2 CMCCx ConfS MS CMCC1 CMCC2 CMCCx ConfS MS
| | | | | | | | | |
|(1) userRequest(update, | | | |(1) userRequest(confUserID,| | |
| confObjID, confUserID, | | | | confObjID, update, | | |
| userInfo) | | | | | userInfo) | | | |
|------------------------------.-------->| | |--------------------------------------->| |
| | | | Mute Bob | | | | | Mute Bob |
| | | |----------------->| | | | |----------------->|
| | | | 200 OK | | | | | 200 OK |
| | | |<-----------------| | | | |<-----------------|
| | | | | | | | | |
| |<====== XXX Bob excluded from mix XXX ====>| | |<====== XXX Bob excluded from mix XXX ====>|
| | | | | | | | | |
| | (a) Update +---| | | | (a) Update +---| |
| | Bob in | | | | | Bob in | | |
| | Data Model | | | | | Data Model | | |
| | (muted) +-->| | | | (muted) +-->| |
| | | | | | | | | |
|(2) userResponse(update, success | | | (2)userResponse(confUserID,confObjID, | |
| confObjID, confUserID) | | | update,success,version) | |
|<---------------------------------------| | |<---------------------------------------| |
| | | | | | | | | |
| | | (b) Notify | | | | | (b) Notify | |
| | | ("Bob is | | | | | ("Bob is | |
| | | muted") | | | | | muted") | |
| | |<-----------| | | | |<-----------| |
| | | | | | | | | |
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
skipping to change at page 35, line 5 skipping to change at page 36, line 5
Server Control architecture is described in Server Control architecture is described in
[I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
Transactions (2)". Transactions (2)".
2. A userResponse message with a responseCode of "success" is then 2. A userResponse message with a responseCode of "success" is then
sent to "Alice". Depending upon the policies, tne conference sent to "Alice". Depending upon the policies, tne conference
server may notify other participants (including "Bob") of this server may notify other participants (including "Bob") of this
update via the Conference Notification Service. update via the Conference Notification Service.
1. userRequest message: 1. userRequest/update message (Alice mutes Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:bob@confSystem.com"> <userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@ciccio.com"> <info:endpoint entity="sip:bob83@example.com">
<info:media id="1"> <info:media id="1">
<info:label>123</info:label> <info:label>123</info:label>
<info:status>recvonly</info:status> <info:status>recvonly</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse message: 2. userResponse/update message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpResponse 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">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>7</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp: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
skipping to change at page 36, line 24 skipping to change at page 37, line 24
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. Besides, "Bob" decides internal-sidebar conference is occurring. Besides, "Bob" decides
that he is not interested in still receiving the conference audio in that he is not interested in still receiving the conference audio in
background (not even at a lower volume as "Alice" configured) and so background (not even at a lower volume as "Alice" configured) and so
modifies the sidebar in order to make that stream inactive for him. modifies the sidebar in order to make that stream inactive for him.
"Alice" "Bob" ConfS "Alice" "Bob" ConfS
| | | | | |
|(1) sidebarByValRequest | |(1) sidebarByValRequest(confUserID, |
| (create, confUserID, | | confObjID,create) |
| confObjID) | |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (a) Create +---| | | (a) Create +---|
| | sidebar-by-val | | | | sidebar-by-val | |
| | (new conf obj | | | | (new conf obj | |
| | cloned from +-->| | | cloned from +-->|
| | confObjID) | Sidebar now has | | confObjID) | Sidebar now has
| | | id confObjID* | | | id confObjID*
|(2) sidebarByValResponse | (parent mapping |(2) sidebarByValResponse(confUserID, | (parent mapping
| (create, success, confObjID* | conf<->sidebar) | (confObjID*, create, success, | conf<->sidebar)
| confUserID, sidebarByValInfo) | | version, sidebarByValInfo) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
|(3) sidebarByValRequest | |(3) sidebarByValRequest |
| (update, confUserID, | | (confUserID, confObjID*, |
| confObjID*, sidebarByValInfo) | | update,sidebarByValInfo) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (b) Update +---| | | (b) Update +---|
| | sidebar-by-val | | | | sidebar-by-val | |
| | (media, users | | | | (media, users | |
| | etc.) +-->| | | etc.) +-->|
| | | Sidebar is | | | Sidebar is
| | | modified | | | modified
|(4) sidebarByValResponse | |(4) sidebarByValResponse(confUserID, |
| (update, success, confObjID* | | (confObjID*, update, |
| confUserID) | | | success, version) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
| |(5) userRequest | | |(5) userRequest |
| | (update, confUserID',| | | (confUserID', |
| | confObjID*, | | | confObjID*, |
| | userInfo) | | | update,userInfo)|
| |---------------------->| | |---------------------->|
| | | | | |
| | (c) Update +---| | | (c) Update +---|
| | user settings | | | | user settings | |
| | (Bob's media) | | | | (Bob's media) | |
| | +-->| | | +-->|
| | | Sidebar is modified | | | Sidebar is modified
| | | (original audio | | | (original audio
| | | inactive for Bob) | | | inactive for Bob)
| |(6) userResponse | | |(6) userResponse |
| | (update, success | | | (confUserID', |
| | confObjID*, | | | confObjID*,update|
| | confUserID') | | | success,version) |
| |<----------------------| | |<----------------------|
| | | | | |
" " " " " "
" " " " " "
" " " " " "
Figure 16: Client Creation of a Sidebar Conference Figure 16: Client Creation of a Sidebar Conference
1. Upon receipt of CCMP sidebarByValRequest message to "reserve" a 1. Upon receipt of CCMP sidebarByValRequest message to "reserve" a
new sidebar conference based upon the confObjID received in the new sidebar conference based upon the confObjID received in the
skipping to change at page 39, line 5 skipping to change at page 40, line 5
and the background from the parent conference. This request may and the background from the parent conference. This request may
be relayed by the conference server to the Media Server handling be relayed by the conference server to the Media Server handling
the mixing, if present. Upon completion of the change, the the mixing, if present. Upon completion of the change, the
conference server sends a "userResponse" message to "Bob". conference server sends a "userResponse" message to "Bob".
Depending upon the policies, the initiator of the request (i.e., Depending upon the policies, the initiator of the request (i.e.,
"Bob") and the participants in the sidebar (i.e., "Alice") may be "Bob") and the participants in the sidebar (i.e., "Alice") may be
notified of this change via the conference notification service. notified of this change via the conference notification service.
That said, let's consider the following conference object: That said, let's consider the following conference object:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<info:conference-info <info: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"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="xcon:8977878@confSystem.com"> entity="xcon:8977878@example.com">
<info:conference-description> <info:conference-description>
<info:display-text>MAIN CONFERENCE</info:display-text> <info:display-text>MAIN CONFERENCE</info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri>sip:8977878@confSystem.com</info:uri> <info:uri>sip:8977878@example.com</info:uri>
<info:display-text>conference sip uri</info:display-text> <info:display-text>conference sip uri</info:display-text>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:available-media> <info:available-media>
<info:entry label="123"> <info:entry label="123">
<info:display-text>main conference audio</info:display-text> <info:display-text>main conference audio</info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
<info:entry label="456"> <info:entry label="456">
skipping to change at page 39, line 39 skipping to change at page 40, line 39
<xcon:controls> <xcon:controls>
<xcon:video-layout>single-view</xcon:video-layout> <xcon:video-layout>single-view</xcon:video-layout>
</xcon:controls> </xcon:controls>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:conference-state> <info:conference-state>
<info:active>true</info:active> <info:active>true</info:active>
</info:conference-state> </info:conference-state>
<info:users> <info:users>
<info:user entity="xcon-userid:alice@confSystem.com"> <info:user entity="xcon-userid:Alice@example.com">
<info:display-text>Alice</info:display-text> <info:display-text>Alice</info:display-text>
<info:endpoint entity="sip:alice@wonderland.com"> <info:endpoint entity="sip:Alice@example.com">
<info:media id="1"> <info:media id="1">
<info:label>123</info:label> <info:label>123</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
<info:media id="2"> <info:media id="2">
<info:label>456</info:label> <info:label>456</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</info:user> </info:user>
<info:user entity="xcon-userid:bob@confSystem.com"> <info:user entity="xcon-userid:Bob@example.com">
<info:display-text>Bob</info:display-text> <info:display-text>Bob</info:display-text>
<info:endpoint entity="sip:bob83@ciccio.com"> <info:endpoint entity="sip:bob83@example.com">
<info:media id="1"> <info:media id="1">
<info:label>123</info:label> <info:label>123</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
<info:media id="2"> <info:media id="2">
<info:label>456</info:label> <info:label>456</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</info:user> </info:user>
<info:user entity="xcon-userid:carol@confSystem.com"> <info:user entity="xcon-userid:Carol@example.com">
<info:display-text>Carol</info:display-text> <info:display-text>Carol</info:display-text>
<info:endpoint entity="sip:carol@pippozzo.com"> <info:endpoint entity="sip:carol@example.com">
<info:media id="1"> <info:media id="1">
<info:label>123</info:label> <info:label>123</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
<info:media id="2"> <info:media id="2">
<info:label>456</info:label> <info:label>456</info:label>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</info:user> </info:user>
skipping to change at page 40, line 40 skipping to change at page 41, line 40
</info:conference-info> </info:conference-info>
This is the representation of the conference the sidebar is going to 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 be created in. As such, it will be used by the conferencing system
in order to create the new conference object associated with the in order to create the new conference object associated with the
sidebar. In fact, the sidebar creation happens through a cloning of sidebar. In fact, the sidebar creation happens through a cloning of
the parent conference. Once the sidebar is created, an "update" the parent conference. Once the sidebar is created, an "update"
makes sure that the sidebar is customized as needed. The following makes sure that the sidebar is customized as needed. The following
protocol dump makes the process clearer. protocol dump makes the process clearer.
1. sidebarByValRequest (create) 1. sidebarByValRequest/create 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="ccmp:ccmp-sidebarByVal-request-message-type"> xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:sidebarByValRequest/> <ccmp:sidebarByValRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByValResponse (create success) 2. sidebarByValResponse/create 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-sidebarByVal-response-message-type"> xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>1</version>
<ccmp:sidebarByValResponse> <ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@confSystem.com"> <sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
SIDEBAR CONFERENCE registered by alice SIDEBAR CONFERENCE registered by Alice
</info:display-text> </info:display-text>
<xcon:sidebar-parent> <xcon:sidebar-parent>
xcon:8977878@confSystem.com xcon:8977878@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
<info:available-media> <info:available-media>
<info:entry label="123"> <info:entry label="123">
<info:display-text> <info:display-text>
main conference audio main conference audio
</info:display-text> </info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
<info:entry label="456"> <info:entry label="456">
skipping to change at page 41, line 50 skipping to change at page 43, line 4
<info:display-text> <info:display-text>
main conference video main conference video
</info:display-text> </info:display-text>
<info:type>video</info:type> <info:type>video</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:conference-state> <info:conference-state>
<info:active>false</info:active> <info:active>false</info:active>
</info:conference-state> </info:conference-state>
<info:users> <info:users>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:alice@confSystem.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/> uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:carol@confSystem.com"/> uri="xcon-userid:Carol@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByValInfo> </sidebarByValInfo>
</ccmp:sidebarByValResponse> </ccmp:sidebarByValResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
3. sidebarByValRequest (update) 3. sidebarByValRequest/update message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
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">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type"> xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:sidebarByValRequest> <ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@confSystem.com"> <sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
private sidebar alice - bob private sidebar Alice - bob
</info:display-text> </info:display-text>
<info:available-media> <info:available-media>
<info:entry label="123"> <info:entry label="123">
<info:display-text> <info:display-text>
main conference audio main conference audio
</info:display-text> </info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>recvonly</info:status> <info:status>recvonly</info:status>
<xcon:controls> <xcon:controls>
<xcon:gain>-60</xcon:gain> <xcon:gain>-60</xcon:gain>
skipping to change at page 43, line 28 skipping to change at page 44, line 28
sidebar video sidebar video
</info:display-text> </info:display-text>
<info:type>video</info:type> <info:type>video</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial-in" <xcon:target method="dial-in"
uri="xcon-userid:alice@confSystem.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/> uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByValInfo> </sidebarByValInfo>
</ccmp:sidebarByValRequest> </ccmp:sidebarByValRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. sidebarByValResponse (update success) 4. sidebarByValResponse/update 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-sidebarByVal-response-message-type"> xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>2</version>
<ccmp:sidebarByValResponse/> <ccmp:sidebarByValResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
5. userRequest (Bob's media) 5. userRequest/update message (Alice updates Bob's media)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
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">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:bob@confSystem.com</confUserID> <confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:bob@confSystem.com"> <userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@ciccio.com"> <info:endpoint entity="sip:bob83@example.com">
<info:media id="1"> <info:media id="1">
<info:display-text> <info:display-text>
main conference audio main conference audio
</info:display-text> </info:display-text>
<info:label>123</info:label> <info:label>123</info:label>
<info:status>inactive</info:status> <info:status>inactive</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
6. userResponse (update success) 6. userResponse/update message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpResponse 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">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:bob@confSystem.com</confUserID> <confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@confSystem.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>3</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp: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 a different approach towards Figure 18 provides an example of a different approach towards
sidebar. In this scenario, one client, "Alice", is involved in an sidebar. In this scenario, one client, "Alice", is involved in an
skipping to change at page 45, line 33 skipping to change at page 47, line 7
main conference in background, this time no background is made main conference in background, this time no background is made
available. "Alice" initiates the sidebar by sending a request to the available. "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", "Bob" and "Ethel" would remain on active conference object. "Alice", "Bob" and "Ethel" would remain on
the roster of the main conference in a hold state. Whether or not the roster of the main conference in a hold state. Whether or not
the hold state of these participants is visible to other participants the hold state of these participants is visible to other participants
depends upon the individual and local policy. depends upon the individual and local policy.
"Alice" "Bob" ConfS "Alice" "Bob" ConfS
| | | | | |
|(1) sidebarByRefRequest | |(1) sidebarByRefRequest(confUserID, |
| (create, confUserID, | | confObjID, create) |
| confObjID) | |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (a) Create +---| | | (a) Create +---|
| | sidebar-by-ref | | | | sidebar-by-ref | |
| | (new conf obj | | | | (new conf obj | |
| | cloned from +-->| | | cloned from +-->|
| | confObjID) | Sidebar now has | | confObjID) | Sidebar now has
| | | id confObjID* | | | id confObjID*
|(2) sidebarByRefResponse | (parent mapping |(2) sidebarByRefResponse(confUserID, | (parent mapping
| (create, success, confObjID* | conf<->sidebar) | confObjID*, create, success, | conf<->sidebar)
| confUserID, sidebarByRefInfo) | | version, sidebarByRefInfo) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
|(3) sidebarByRefRequest | |(3) sidebarByRefRequest(confUserID, |
| (update, confUserID, | | confObjID*,update,sidebarByRefInfo) |
| confObjID*, sidebarByRefInfo) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (b) Create +---| | | (b) Create +---|
| | new user for | | | | new user for | |
| | "Fred" | | | | "Fred" | |
| | +-->| | | +-->|
| | | | | |
| | (c) Update +---| | | (c) Update +---|
| | sidebar-by-val | | | | sidebar-by-val | |
| | (media, users | | | | (media, users | |
| | policy, etc.) +-->| | | policy, etc.) +-->|
| | | Sidebar is modified: | | | Sidebar is modified:
| | | no media from the | | | no media from the
| | | parent conference is | | | parent conference is
| | | available to anyone | | | available to anyone
|(4) sidebarByRefResponse | |(4) sidebarByRefResponse(confUserID, |
| (update, success, confObjID* | | confObjID*, update, |
| confUserID) | | | success, version) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
| | Notify ("Fred" | | | Notify ("Fred" |
| | added to | | | added to |
| | sidebar users) | | | sidebar users) |
| |<----------------------| | |<----------------------|
| | | | | |
" " " " " "
" " " " " "
" " " " " "
skipping to change at page 47, line 38 skipping to change at page 49, line 5
add "Fred" to the conference may be 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 (e.g. if "Fred" had a "dial-out" method set as the target for
him) at the actual activation of the sidebar. him) at the actual activation of the sidebar.
4. The conference server sends a "sidebarByRefResponse" message and, 4. The conference server sends a "sidebarByRefResponse" message and,
depending upon the policies, the initiator of the request (i.e., depending upon the policies, the initiator of the request (i.e.,
"Alice") and the participants in the sidebar (i.e., "Bob" and "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.
1. sidebarByRefRequest (create) 1. sidebarByRefRequest/create 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="ccmp:ccmp-sidebarByRef-request-message-type"> xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@confSystem.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:sidebarsByRefRequest/> <ccmp:sidebarByRefRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByRefResponse (create success) 2. sidebarByRefResponse/create 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-sidebarByref-response-message-type"> xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<ccmp:response-code>success</ccmp:response-code> <operation>success</operation>
<response-code>success</response-code>
<version>1</version>
<ccmp:sidebarByRefResponse> <ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@confSystem.com"> <sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
SIDEBAR CONFERENCE registered by alice SIDEBAR CONFERENCE registered by Alice
</info:display-text> </info:display-text>
<xcon:sidebar-parent> <xcon:sidebar-parent>
xcon:8977878@confSystem.com xcon:8977878@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
<info:available-media> <info:available-media>
<info:entry label="123"> <info:entry label="123">
<info:display-text> <info:display-text>
main conference audio main conference audio
</info:display-text> </info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
<info:entry label="456"> <info:entry label="456">
skipping to change at page 49, line 4 skipping to change at page 50, line 19
<info:status>sendrecv</info:status> <info:status>sendrecv</info:status>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:conference-state> <info:conference-state>
<info:active>false</info:active> <info:active>false</info:active>
</info:conference-state> </info:conference-state>
<info:users> <info:users>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:alice@confSystem.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/> uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:carol@confSystem.com"/> uri="xcon-userid:Carol@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:david@confSystem.com"/> uri="xcon-userid:David@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:ethel@confSystem.com"/> uri="xcon-userid:Ethel@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByRefInfo> </sidebarByRefInfo>
</ccmp:sidebarByRefResponse> </ccmp:sidebarByRefResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
3. sidebarByRefRequest (update) 3. sidebarByRefRequest/update message
<ccmp:ccmpRequest <ccmp:ccmpRequest
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">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:sidebarByRefRequest> <ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971212@confSystem.com"> <sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
sidebar alice, bob, ethel & fred sidebar Alice, bob, ethel & fred
</info:display-text> </info:display-text>
<info:available-media> <info:available-media>
<info:entry label="123"> <info:entry label="123">
<info:display-text> <info:display-text>
main conference audio main conference audio
</info:display-text> </info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
<info:status>inactive</info:status> <info:status>inactive</info:status>
</info:entry> </info:entry>
<info:entry label="456"> <info:entry label="456">
skipping to change at page 50, line 33 skipping to change at page 51, line 48
</xcon:controls> </xcon:controls>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:conference-state> <info:conference-state>
<info:active>false</info:active> <info:active>false</info:active>
</info:conference-state> </info:conference-state>
<info:users> <info:users>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial-in" <xcon:target method="dial-in"
uri="xcon-userid:alice@confSystem.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:bob@confSystem.com"/> uri="xcon-userid:Bob@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="sip:fred@example.com"/> uri="sip:fred@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByRefInfo> </sidebarByRefInfo>
</ccmp:sidebarByRefRequest> </ccmp:sidebarByRefRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. sidebarByRefResponse (update success) 4. sidebarByRefResponse/update message
<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-sidebarByref-response-message-type"> xsi:type="ccmp:ccmp-sidebarByref-response-message-type">
<confUserID>xcon-userid:alice@confSystem.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@confSystem.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>success</response-code>
<version>2</version>
<ccmp:sidebarByRefResponse/> <ccmp:sidebarByRefResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp: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
access to the floor, they have to join a new sidebar with the access to the floor, they have to join a new sidebar with the
moderator and ask their question. The moderator can also whisper to moderator and ask their question. The moderator can also whisper to
each analyst what their status/position in the floor control queue, each analyst what their status/position in the floor control queue,
similar to the example in Figure 22. It should be noted that other similar to the example in Figure 23. It should be noted that other
mechanisms which don't make use of sidebars could be used for floor mechanisms which don't make use of sidebars could be used for floor
control such as those detailed in BFCP. control such as those detailed in BFCP.
Figure 20 provides an example of the configuration involved for this Figure 20 provides an example of the configuration involved for this
type of conference. As in the previous sidebar examples, there is type of conference. As in the previous sidebar examples, there is
the main conference along with a sidebar. "Alice" and "Bob" are the the main conference along with a sidebar. "Alice" and "Bob" are the
main participants in the conference, with "A1", "A2" and "A3" main participants in the conference, with "A1", "A2" and "A3"
representing the analysts. The sidebar remains active throughout the representing the analysts. The sidebar remains active throughout the
conference, with the moderator, "Carol", serving as the chair. As conference, with the moderator, "Carol", serving as the chair. As
discussed previously, the sidebar conference is NOT independent of discussed previously, the sidebar conference is NOT independent of
skipping to change at page 52, line 27 skipping to change at page 53, line 40
indicates to the floor control server that "A1" may be granted indicates to the floor control server that "A1" may be granted
the floor. the floor.
(CCMP Messaging details not available yet). (CCMP Messaging details not available yet).
Figure 21: Floor Control Messaging Details Figure 21: Floor Control Messaging Details
6.8. Whispering or Private Messages 6.8. Whispering or Private Messages
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
two participants, similar to the example in section Section 6.5, but two participants, similarly to the example in section Section 6.5.
rather than using audio within the sidebar, "Alice" could add an Unlike the previous example, anyway, rather than using audio within
additional text based media stream to the sidebar. The other the sidebar, "Alice" could just add an additional text based media
context, referred to as whisper, in this document refers to stream to the sidebar in order to convey her whisper. From the
protocol point of view, with reference to the messages described in
Figure 17, only the third CCMP message (a sidebarByValRequest/update)
changes, as depicted in Figure 22.
3. sidebarByValRequest/update message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="sidebarTextLabel">
<info:display-text>
sidebar text
</info:display-text>
<info:type>text</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
Figure 22: SidebarByVal Update for private messages scenario
The other context, referred to as whisper, in this document refers to
situations involving one time media targetted to specific user(s). situations involving one time media targetted to specific user(s).
An example of a whisper would be an announcement injected only to the An example of a whisper would be an announcement injected only to the
conference chair or to a new participant joining a conference. conference chair or to a new participant joining a conference.
Please notice that such an announcement would not be conveyed by
means of CCMP, while rather by means of a notification protocol
related to it, e.g. a SIP event package, XMPP, or even a multimedia
announcement. CCMP would only be involved with respect to the
creation of an ad-hoc sidebar, as it will be clearer in the following
lines.
Figure 22 provides an example of one user "Alice" whose chairing a Figure 23 provides an example of one user "Alice" who's chairing a
fixed length conference with "Bob" and "Carol". The configuration is fixed length conference with "Bob" and "Carol". The configuration is
such that only the chair is providing a warning when there is only 10 such that only the chair is providing a warning when there is only 10
minutes left in the conference. At that time, "Alice" is moved into minutes left in the conference. At that time, "Alice" is moved into
a sidebar created by the conferencing system and only "Alice" a sidebar created by the conferencing system and only "Alice"
receives the announcement. receives the announcement.
(To Be completed). (To Be completed).
Figure 22: Whisper Figure 23: Whisper
1. When the conferencing system determines that there is only 10 1. When the conferencing system determines that there is only 10
minutes left in the conference which "Alice" is chairing, the minutes left in the conference which "Alice" is chairing, the
conferencing system directly creates an active sidebar conferencing system directly creates an active sidebar
conference, based on the active conference associated with conference, based on the active conference associated with
"Alice". This sidebar conference is NOT independent of the "Alice". This sidebar conference is NOT independent of the
active conference (i.e., parent). The conferencing system also active conference (i.e., parent). The conferencing system also
allocates a conference ID to be used for any subsequent allocates a conference ID to be used for any subsequent
manipulations of the sidebar conference. manipulations of the sidebar conference.
skipping to change at page 53, line 28 skipping to change at page 56, line 19
policies, Alice may be notified of her addition to the sidebar policies, Alice may be notified of her addition to the sidebar
via the conference notification service. "Alice" continues to via the conference notification service. "Alice" continues to
receive the media from the main conference. receive the media from the main conference.
3. Upon completion of the announcement, "Alice" is removed from the 3. Upon completion of the announcement, "Alice" is removed from the
siebar and the sidebar conference is deleted. siebar and the sidebar conference is deleted.
4. "Alice" is notified of her removal from the sidebar via the 4. "Alice" is notified of her removal from the sidebar via the
conference notification service. conference notification service.
(CCMP Messaging details not available yet).
Figure 23: Whisper Messaging Details
6.9. Observing and Coaching 6.9. Observing and Coaching
An example of observing and coaching is shown in figure Figure 24. An example of observing and coaching is shown in figure Figure 25.
In this example, call center agent "Bob" is involved in a conference In this example, call center agent "Bob" is involved in a conference
with customer "Carol". Since "Bob" is a new agent and "Alice" sees with customer "Carol". Since "Bob" is a new agent and "Alice" sees
that he has been on the call with "Carol" for longer than normal, she that he has been on the call with "Carol" for longer than normal, she
decides to observe the call and coach "Bob" as necessary. decides to observe the call and coach "Bob" as necessary.
(Figure not available yet). Consider the following as the conference document associated with the
video conference involving Bob (the call agent) and Carol (the
customer) (Figure 24):
Figure 24: Supervisor Creating a Sidebar for Observing/Coaching <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<info:conference-info
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="xcon:8978383@example.com">
<info:conference-description>
<info:display-text>CUSTOMER SERVICE conference</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8978383@example.com</info:uri>
<info:display-text>conference sip uri</info:display-text>
</info:entry>
</info:conf-uris>
<info:available-media>
<info:entry label="123">
<info:display-text>service audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
1. Upon receipt of the confRequest from "Alice" to "create" a new </info:entry>
sidebar conference from the confObjID received in the request, <info:entry label="456">
the conferencing system uses the received active conference to <info:display-text>service video</info:display-text>
clone a conference reservation for the sidebar. The conferencing <info:type>video</info:type>
system also allocates a conference ID to be used for any <info:status>sendrecv</info:status>
subsequent protocol requests from any of the members of the <xcon:controls>
conference. The conferencing system maintains the mapping <xcon:video-layout>single-view</xcon:video-layout>
</xcon:controls>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>true</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:bob@example.com">
<info:display-text>Bob - call agent</info:display-text>
<info:endpoint entity="sip:bob@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:carol@example.com">
<info:display-text>Carol - customer</info:display-text>
<info:endpoint entity="sip:carol@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>456</info:label>
<info:status>sendrecv</info:status>
</info:media>
</info:endpoint>
</info:user>
</info:users>
</info:conference-info>
Figure 24: A call-center conference object example
"Alice" "Bob" ConfS
| | |
|(1) sidebarByRefRequest(confUserID, |
| confObjID, create) |
|--------------------------------------------->|
| | |
| | (a) Create +---|
| | sidebar-by-ref | |
| | (new conf obj | |
| | cloned from +-->|
| | confObjID) | Sidebar now has
| | | id confObjID*
|(2) sidebarByRefResponse(confUserID, | (parent mapping
| confObjID*, create, success, | conf<->sidebar)
| version, sidebarByRefInfo) |
|<---------------------------------------------|
| | |
|(3) sidebarByRefRequest(confUserID, |
| confObjID*,update,sidebarByRefInfo) |
|--------------------------------------------->|
| | |
| | (b) Update +---|
| | sidebar-by-val | |
| | (media, users | |
| | policy, etc.) +-->|
| | | Sidebar is modified:
| | | unilateral sidebar
| | | audio, Carol excluded
| | | from the sidebar
|(4) sidebarByRefResponse(confUserID, |
| confObjID*, update, |
| success, version) |
|<---------------------------------------------|
| | |
| | Notify ("Bob" |
| | he's been added to |
| | sidebar users) |
| |<----------------------|
| | |
" " "
" " "
" " "
Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
1. Upon receipt of the sidbarByRefRequest/create from "Alice" to
"create" a new sidebar conference from the confObjID received in
the request, the conferencing system uses the received active
conference to clone a conference reservation for the sidebar.
The conferencing system also allocates a conference ID to be used
for any subsequent protocol requests from any of the members of
the conference. The conferencing system maintains the mapping
between this conference ID and the confObjID associated with the between this conference ID and the confObjID associated with the
sidebar reservation through the conference instance. The sidebar reservation through the conference instance. The
conference server sends a confResponse message with the new conference server sends a sidebarByRefResponse message with the
confObjID and relevant confInfo. new confObjID and relevant confInfo.
2. Upon receipt of the confResponse message, "Alice" manipulates the 2. Upon receipt of the confResponse message, "Alice" manipulates the
data received in the confInfo in the response. "Alice" wants data received in the confInfo in the response. "Alice" wants
only "Bob" to be involved in the sidebar, thus she updates the only "Bob" to be involved in the sidebar, thus she updates the
"allowed-users-list" to include only "Bob". "Alice" also wants "allowed-users-list" to include only "Bob". "Alice" also wants
the audio to be received by herself and "Bob" from the original the audio to be received by herself and "Bob" from the original
conference, but wants any outgoing audio from herself to be conference, but wants any outgoing audio from herself to be
restricted to the participants in the sidebar, whereas "Bob's" restricted to the participants in the sidebar, whereas "Bob's"
outgoing audio should go to the main conference, so that both outgoing audio should go to the main conference, so that both
"Alice" and the customer "Carol" hear the same audio from "Bob". "Alice" and the customer "Carol" hear the same audio from "Bob".
"Alice" sends a confRequest message with an "update" operation "Alice" sends a sidebarByRefRequest message with an "update"
including the updated conference information. operation including the updated conference information.
3. Upon receipt of the confRequest message with an "update" 3. Upon receipt of the sidbarByRefRequest message with an "update"
operation, the conferencing system ensures that "Alice" has the operation, the conferencing system ensures that "Alice" has the
appropriate authority based on the policies associated with that appropriate authority based on the policies associated with that
specific conference object to perform the operation. specific conference object to perform the operation.
4. After validating the data, the conference server sends a 4. After validating the data, the conference server sends a
confResponse message. Based upon the addressing information sidebarByRefResponse message. Based upon the addressing
provided for "Bob" by "Alice", the call signaling to add "Bob" to information provided for "Bob" by "Alice", the call signaling to
the sidebar with the appropriate media characteristics is add "Bob" to the sidebar with the appropriate media
instigated through the Focus. "Bob" is notified of his addition characteristics is instigated through the Focus. "Bob" is
to the sidebar via the conference notification service, thus he notified of his addition to the sidebar via the conference
is aware that "Alice" the supervisor is available for coaching notification service, thus he is aware that "Alice" the
him through this call. supervisor is available for coaching him through this call.
(CCMP Messaging details not available yet). 1. sidebarByRefRequest/create message (Alice - the coach - creates a sidebar)
Figure 25: Coaching and Observing Messaging details <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarsByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByRefRequest/create message ("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@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<ccmp:response-code>success</ccmp:response-code>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by alice
</info:display-text>
<xcon:sidebar-parent>
xcon:8971313@example.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@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:carol@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByRefRequest/update message (Alice introduces unilateral sidebar audio
and excludes Carol from the sidebar)
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
Coaching sidebar alice(supervisor) - bob(call agent)
</info:display-text>
<info:available-media>
<info:entry label="sidebarAudio">
<info:display-text>
Alice-to-Bob audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@example.com"/>
</xcon:allowed-users-list>
<user entity="xcon-userid:Alice@example.com>
<info:endpoint>
<info:media>
<info:label>sidebarAudio</info:label>
<info:status>sendonly</info:status>
</info:media>
</info:endpoint>
</user>
<user entity="xcon-userid:Bob@example.com>
<info:endpoint>
<info:media>
<info:label>sidebarAudio</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</user>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
Figure 26: Coaching and Observing Messaging details
7. Removing participants and deleting conferences 7. Removing participants and deleting conferences
The following scenarios detail the basic operations associated with The following scenarios detail the basic operations associated with
removing participants from conferences and entirely deleting removing participants from conferences and entirely deleting
conferences. The examples assume that a conference has already been conferences. The examples assume that a conference has already been
correctly established, with media, if applicable, per one of the correctly established, with media, if applicable, per one of the
examples in Section 5. examples in Section 5.
7.1. Removing a Party 7.1. Removing a Party
Figure 26 provides an example of one client "Alice" removing another Figure 27 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.
"Alice" "Bob" "Claire" ConfS "Alice" "Bob" "Claire" ConfS
| | | | | | | |
|(1) userRequest(delete, | | |(1) userRequest(confUserID,| |
| confObjID, confUserID, | | | confObjID, delete,| |
| userInfo) | | | | userInfo) | |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | | (a) Focus | | | | (a) Focus |
| | | tears down| | | | tears down|
| | | signaling | | | | signaling |
| | | to "Bob" | | | | to "Bob" |
| |<----------------------| | |<----------------------|
| | | | | |
| | (b)Deletes+---| | | (b)Deletes+---|
| | | "Bob" | | | | | "Bob" | |
| | | as a | | | | | as a | |
| | | user +-->| | | | user +-->|
| | | in | | | | in |
| | | confObj | | | | confObj |
| | | | | | | |
|(2) userResponse(delete, success | |(2) userResponse(confUserID,confObjID, |
| confObjID) | | | delete,success,version) |
| | | |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | | | | | |
| | | (c) Notify| | | | (c) Notify|
| | | ("Bob just| | | | ("Bob just|
| | | left") | | | | left") |
| | |<----------| | | |<----------|
| | | | | | | |
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
Figure 26: Client Manipulation of Conference - Remove a party
Figure 27: 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. After updating the data, removing "Bob" from the "users" list. After updating the data,
the conference server sends a userResponse message to "Alice". the conference server sends a userResponse message to "Alice".
Depending upon the policies, other participants (e.g. "Claire") Depending upon the policies, other participants (e.g. "Claire")
may be notified of the removal of "Bob" from the conference via may be notified of the removal of "Bob" from the conference via
the Conference Notification Service. the Conference Notification Service.
(CCMP Messaging details not available yet). 1. userRequest/delete message (Alice deletes Bob):
Figure 27: Removing a Participant Messaging Details <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse/delete message
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<response-code>success</response-code>
<version>17</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 28: 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). "Alice" ConfS
| |
|(1)confRequest(confUserID, |
| confObjID, delete) |
|------------------------------>|
| (a)Delete +---|
| Conf | |
| Object | |
| +-->|
| |--+ (b) MS
| | | removes related
| | | mixer instances and
| |<-+ their participants
| | (SIP signaling as well)
| |
|(2)confResponse(confUserID, |
| confObjID,delete, |
| success) |
| |
|<------------------------------|
| |
Figure 28: Deleting a conference Figure 29: Deleting a conference
(Text description to be added). (Text description to be added).
(CCMP Messaging details not available yet). 1. confRequest/delete message (Alice deletes a conference)
Figure 29: Deleting a Conference Messaging Details <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse/delete message ("success")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<response-code>success</response-code>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 30: Deleting a Conference Messaging Details
8. Additional Conference Scenarios and Examples 8. Additional Conference Scenarios and Examples
The following are additional scenarios making use of the XCON The following are additional scenarios making use of the XCON
framework and associated protocols. In some cases, these examples framework and associated protocols. In some cases, these examples
make use of some of the building block scenarios detailed in the make use of some of the building block scenarios detailed in the
previous example sections, in which case the appropriate scenario is previous example sections, in which case the appropriate scenario is
referenced rather than duplicating details. In addition, in cases referenced rather than duplicating details. In addition, in cases
where the scenarios make use of other protocols, as in the previous where the scenarios make use of other protocols, as in the previous
section, the appropriate reference in the form of a title to the section, the appropriate reference in the form of a title to the
skipping to change at page 58, line 34 skipping to change at page 69, line 25
There are different ways to create a conference. A participant can There are different ways to create a conference. A participant can
create a conference using call signaling means only, such as SIP, as create a conference using call signaling means only, such as SIP, as
detailed in [RFC4579]. For a conferencing client to have more detailed in [RFC4579]. For a conferencing client to have more
flexibility in defining the charaterisitics and capabilities of a flexibility in defining the charaterisitics and capabilities of a
chat based conference, a conferencing client would implement a chat based conference, a conferencing client would implement a
conference control protocol client. By using a conference control conference control protocol client. By using a conference control
protocol, the client can determine the capabilities of a conferencing protocol, the client can determine the capabilities of a conferencing
system and its various resources. system and its various resources.
Figure 30 provides an example of one client "Alice" determining the Figure 31 provides an example of one client "Alice" determining the
conference blueprints available to support various types of chat conference blueprints available to support various types of chat
rooms for a particular conferencing system and creating a chat based rooms for a particular conferencing system and creating a chat based
conference using the desired blueprint. conference using the desired blueprint.
Details to be added. Details to be added.
Figure 30: Client Creation of Chat room Figure 31: Client Creation of Chat room
Upon receipt of the Conference Control Protocol request for Upon receipt of the Conference Control Protocol request for
blueprints associated with chat rooms, the conferencing system would blueprints associated with chat rooms, the conferencing system would
first authenticate "Alice" (and allocate a conference user first authenticate "Alice" (and allocate a conference user
identifier, if necessary) and then ensure that "Alice" has the identifier, if necessary) and then ensure that "Alice" has the
appropriate authority based on system policies to receive any chat appropriate authority based on system policies to receive any chat
room based blueprints supported by that system. Any blueprints that room based blueprints supported by that system. Any blueprints that
"Alice" is authorized to use are returned in a response, along with "Alice" is authorized to use are returned in a response, along with
the conference user ID. the conference user ID.
skipping to change at page 59, line 46 skipping to change at page 70, line 37
room. When the first participant, including "Alice", requests to be room. When the first participant, including "Alice", requests to be
added to the conference, an active conference and focus are created. added to the conference, an active conference and focus are created.
The focus is associated with the conference ID received in the The focus is associated with the conference ID received in the
request. request.
(CCMP Messaging details not available yet. (CCMP Messaging details not available yet.
Plan is to reference detailed flows in Plan is to reference detailed flows in
previous sections previous sections
in the example.) in the example.)
Figure 31: Chatroom Creation Messaging Details Figure 32: Chatroom Creation Messaging Details
8.1.1.2. Joining a Chat Room 8.1.1.2. Joining a Chat Room
A participant can join and leave the conference using call signaling A participant can join and leave the conference using call signaling
means only, such as SIP. However, in order to perform richer means only, such as SIP. However, in order to perform richer
conference control a user client can implement a conference control conference control a user client can implement a conference control
protocol client. By using a conference control protocol, the client protocol client. By using a conference control protocol, the client
can affect its own state and the state of other participants, can affect its own state and the state of other participants,
depending upon policies, which may indirectly affect the state of any depending upon policies, which may indirectly affect the state of any
of the conference participants. of the conference participants.
skipping to change at page 60, line 25 skipping to change at page 71, line 15
In the example in section Section 8.1.1.1, "Alice" has reserved a In the example in section Section 8.1.1.1, "Alice" has reserved a
chat room . "Alice" has also already joined the conference and made chat room . "Alice" has also already joined the conference and made
the chat room active. "Alice" can either add additional participants the chat room active. "Alice" can either add additional participants
to the chat room or provide the conference information, including the to the chat room or provide the conference information, including the
necessary conference ID, to desired participants and allow them to necessary conference ID, to desired participants and allow them to
request to join themselves. Any participants that have the authority request to join themselves. Any participants that have the authority
to manipulate the conference would receive the conference object to manipulate the conference would receive the conference object
identifier of the active conference object in the response to their identifier of the active conference object in the response to their
request to join. request to join.
Figure 32 provides an example of "Bob" joining the chat room using Figure 33 provides an example of "Bob" joining the chat room using
the conference ID provided by "Alice" (e.g., in an IM). the conference ID provided by "Alice" (e.g., in an IM).
Details to be added. Details to be added.
Figure 32: Joining a chat room Figure 33: Joining a chat room
Upon receipt of the Conference Control Protocol request to "add" a Upon receipt of the Conference Control Protocol request to "add" a
party ("Bob") in the specific conference as identified by the party ("Bob") in the specific conference as identified by the
conference object ID, the conferencing system must determine whether conference object ID, the conferencing system must determine whether
"Bob" is already a user of this conferencing system or whether he is "Bob" is already a user of this conferencing system or whether he is
a new user. If "Bob" is a new user for this conferencing system, a a new user. If "Bob" is a new user for this conferencing system, a
Conference User Identifier is created for Bob. The conferencing Conference User Identifier is created for Bob. The conferencing
system must also ensure that "Bob" has the appropriate authority system must also ensure that "Bob" has the appropriate authority
based on the policies associated with that specific conference object based on the policies associated with that specific conference object
to perform the operation. to perform the operation.
skipping to change at page 61, line 10 skipping to change at page 71, line 42
Once "Bob" has been successfully added to the chat room, a response Once "Bob" has been successfully added to the chat room, a response
is sent to "Bob". Depending upon the policies, other participants is sent to "Bob". Depending upon the policies, other participants
(including "Bob") may be notified of the addition of "Bob" to the (including "Bob") may be notified of the addition of "Bob" to the
conference via the Conference Notification Service. conference via the Conference Notification Service.
(CCMP Messaging details not available yet. (CCMP Messaging details not available yet.
Plan is to reference detailed flows in Plan is to reference detailed flows in
previous sections as appropriate previous sections as appropriate
in the example.) in the example.)
Figure 33: Chatroom Join Messaging Details Figure 34: Chatroom Join Messaging Details
8.1.1.3. Deleting a Chat Room 8.1.1.3. Deleting a Chat Room
Depending upon the conferencing system policies and policies specific Depending upon the conferencing system policies and policies specific
to the chat room, the creator of the chat would typically be the to the chat room, the creator of the chat would typically be the
participant authorized to delete the chat room. participant authorized to delete the chat room.
In the example in section Section 8.1.1.1, "Alice" has created a chat In the example in section Section 8.1.1.1, "Alice" has created a chat
room and provided the conference information, including the necessary room and provided the conference information, including the necessary
conference ID, to desired participants and allow them to request to conference ID, to desired participants and allow them to request to
join themselves. "Bob" and others are participants in the chat. join themselves. "Bob" and others are participants in the chat.
Figure 34 provides an example of "Alice" later deleting this same Figure 35 provides an example of "Alice" later deleting this same
chat room. chat room.
Details to be added. Details to be added.
Figure 34: Deleting a chat room Figure 35: Deleting a chat room
Upon receipt of the Conference Control Protocol request to "delete" Upon receipt of the Conference Control Protocol request to "delete"
the specific chat room as identified by the conference object ID, the the specific chat room as identified by the conference object ID, the
conferencing system must determine whether "Alice" has the authority conferencing system must determine whether "Alice" has the authority
to delete this conference. Since "Alice" is the creator of the to delete this conference. Since "Alice" is the creator of the
conference, the "delete" operation is performed, with the appropriate conference, the "delete" operation is performed, with the appropriate
signaling sent to the participants, including a response to "Alice" signaling sent to the participants, including a response to "Alice"
indicating that the chat room has been deleted. indicating that the chat room has been deleted.
One step in the deletion of the chat room may include notifitying the One step in the deletion of the chat room may include notifitying the
participants (including "Bob") that they have been removed via the participants (including "Bob") that they have been removed via the
Conference Notification Service. Conference Notification Service.
(CCMP Messaging details not available yet. (CCMP Messaging details not available yet.
Plan is to reference detailed flows in Plan is to reference detailed flows in
previous sections .) previous sections .)
Figure 35: Chatroom Deletion Messaging Details Figure 36: Chatroom Deletion Messaging Details
8.1.2. Advanced Operations 8.1.2. Advanced Operations
This section provides details of the realization of advanced chat This section provides details of the realization of advanced chat
features, such as sidebars and private messages, within the context features, such as sidebars and private messages, within the context
of the centralized conferencing framework. As with Section 8.1.1, of the centralized conferencing framework. As with Section 8.1.1,
the objective of this section is to further illustrate the model, the objective of this section is to further illustrate the model,
mechanisms and protocols presented in the previous sections and also mechanisms and protocols presented in the previous sections and also
serves to validate that the model, mechanisms and protocols are serves to validate that the model, mechanisms and protocols are
sufficient to support advance IM chat features. sufficient to support advance IM chat features.
skipping to change at page 62, line 35 skipping to change at page 73, line 26
parent associated with the existing conference and updating any parent associated with the existing conference and updating any
information specific to the sidebar. A sidebar conference object is information specific to the sidebar. A sidebar conference object is
implicitly linked to the parent conference object (i.e. it is not an implicitly linked to the parent conference object (i.e. it is not an
independent object) and is associated with the parent conference independent object) and is associated with the parent conference
object identifier. A conferencing system manages and enforces the object identifier. A conferencing system manages and enforces the
parent and appropriate localized restrictions on the sidebar parent and appropriate localized restrictions on the sidebar
conference object (e.g., no members from outside the parent conference object (e.g., no members from outside the parent
conference instance can join, sidebar conference can not exist if conference instance can join, sidebar conference can not exist if
parent conference is terminated, etc.). parent conference is terminated, etc.).
Figure 36 provides an example of one client "Alice" involved in Figure 37 provides an example of one client "Alice" involved in
active chat room with "Bob" and "Carol". "Alice" wants to create a active chat room with "Bob" and "Carol". "Alice" wants to create a
sidebar to have a side discussion with "Bob" while still receiving sidebar to have a side discussion with "Bob" while still receiving
the session based messaging associated with the main chat room. the session based messaging associated with the main chat room.
Whether the text is interleaved with the main chat or whether a Whether the text is interleaved with the main chat or whether a
separate window is created for the sidebar is implementation separate window is created for the sidebar is implementation
specific. "Alice" initiates the sidebar by sending a request to the specific. "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference chat reservation based conferencing system to create a conference chat reservation based
upon the active chat conference object. "Alice" and "Bob" would upon the active chat conference object. "Alice" and "Bob" would
remain on the roster of the main conference, such that other remain on the roster of the main conference, such that other
participants could be aware of their participation in the main participants could be aware of their participation in the main
conference, while the text sidebar conference is occurring. conference, while the text sidebar conference is occurring.
Details to be added. Details to be added.
Figure 36: Client Creation of a Sidebar Conference Figure 37: Client Creation of a Sidebar Conference
Upon receipt of the Conference Control Protocol request to "reserve" Upon receipt of the Conference Control Protocol request to "reserve"
a new sidebar chat conference, based upon the active chat conference a new sidebar chat conference, based upon the active chat conference
received in the request, the conferencing system uses the received received in the request, the conferencing system uses the received
active chat conference to clone a conference chat reservation for the active chat conference to clone a conference chat reservation for the
sidebar. As discussed previously, the sidebar reservation is NOT sidebar. As discussed previously, the sidebar reservation is NOT
independent of the active conference (i.e., parent). The independent of the active conference (i.e., parent). The
conferencing system also reserves or allocates a conference ID to be conferencing system also reserves or allocates a conference ID to be
used for any subsequent protocol requests from any of the members of used for any subsequent protocol requests from any of the members of
the conference. The conferencing system maintains the mapping the conference. The conferencing system maintains the mapping
skipping to change at page 63, line 46 skipping to change at page 74, line 38
updated information in the reservation, ensuring that a member like updated information in the reservation, ensuring that a member like
"Bob" is already a user of this conferencing system. "Bob" is already a user of this conferencing system.
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") may be "Alice") and the participants in the sidebar (i.e., "Bob") may be
notified of his addition to the sidebar via the conference notified of his addition to the sidebar via the conference
notification service. notification service.
Details to be added. Details to be added.
Figure 37: Chatroom Sidebar Messaging Details Figure 38: Chatroom Sidebar Messaging Details
8.1.2.2. Private Message 8.1.2.2. Private Message
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
two participants, identical to the example in section two participants, identical to the example in section
Section 8.1.2.1. The other context, referred to as whisper, in this Section 8.1.2.1. The other context, referred to as whisper, in this
document refers to situations involving one time media targetted to document refers to situations involving one time media targetted to
specific user(s). An example of a whisper would be a text message specific user(s). An example of a whisper would be a text message
injected only to the conference chair or to a new participant joining injected only to the conference chair or to a new participant joining
a conference. a conference.
Figure 38 provides an example of one user "Alice" who's chairing a Figure 39 provides an example of one user "Alice" who's chairing a
fixed length conference with "Bob" and "Carol". The configuration is fixed length conference with "Bob" and "Carol". The configuration is
such that only the chair is providing a warning when there is only 10 such that only the chair is providing a warning when there is only 10
minutes left in the conference. At that time, "Alice" is moved into minutes left in the conference. At that time, "Alice" is moved into
a sidebar created by the conferencing system and only "Alice" a sidebar created by the conferencing system and only "Alice"
receives that text message announcing the 10 minute warning. receives that text message announcing the 10 minute warning.
Details to be added. Details to be added.
Figure 38: Whisper Figure 39: Whisper
When the conferencing system determines that there is only 10 minutes When the conferencing system determines that there is only 10 minutes
left in the conference which "Alice" is chairing, rather than left in the conference which "Alice" is chairing, rather than
creating a reservation as was done for the sidebar in creating a reservation as was done for the sidebar in
Section 8.1.2.1, the conferencing system directly creates an active Section 8.1.2.1, the conferencing system directly creates an active
chat sidebar conference, based on the active chat conference chat sidebar conference, based on the active chat conference
associated with "Alice". As discussed previously, the sidebar associated with "Alice". As discussed previously, the sidebar
conference is NOT independent of the active conference (i.e., conference is NOT independent of the active conference (i.e.,
parent). The conferencing system also allocates a conference ID to parent). The conferencing system also allocates a conference ID to
be used for any subsequent manipulations of the sidebar chat be used for any subsequent manipulations of the sidebar chat
skipping to change at page 65, line 7 skipping to change at page 75, line 42
the conference notification service. "Alice" continues to receive the conference notification service. "Alice" continues to receive
the text messages from the main conference. the text messages from the main conference.
Upon delivery of the text announcement, "Alice" is removed from the Upon delivery of the text announcement, "Alice" is removed from the
sidebar and the sidebar conference is deleted. Depending upon the sidebar and the sidebar conference is deleted. Depending upon the
policies, "Alice" may be notified of her removal from the sidebar via policies, "Alice" may be notified of her removal from the sidebar via
the conference notification service. the conference notification service.
Details to be added. Details to be added.
Figure 39: Chatroom Sidebar Messaging Details Figure 40: Chatroom Sidebar Messaging Details
9. IANA Considerations 9. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
10. Security Considerations 10. Security Considerations
The security considerations applicable to the implementation of these The security considerations applicable to the implementation of these
call flows is documented in the XCON Framework, with additional call flows is documented in the XCON Framework, with additional
security considerations documented in the CCMP document. Where security considerations documented in the CCMP document. Where
skipping to change at page 65, line 29 skipping to change at page 76, line 25
discussed in particular flows, however, since this is only an discussed in particular flows, however, since this is only an
informational document, readers are strongly recommended to carefully informational document, readers are strongly recommended to carefully
consider the security considerations defined in the XCON Framework consider the security considerations defined in the XCON Framework
and the CCMP document. and the CCMP document.
11. Change Summary 11. Change Summary
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
The following are the major changes between the 01 and the 02
versions of the draft:
o updated the call flows in order to take into account the new
versioning mechanism of the CCMP;
o clarified, per agreement in Stockholm, that cloning from a
blueprint does not need a cloning-parent to be made available in
the response;
o clarified that BFCP and CCMP-based media control are neither in
conflict nor one the wrapper of the other; they act at different
levels, and when both are involved, it is required that both grant
a resource before it can be used by an interested participant;
o changed all the domains involved in the flows to make them
compliant with [RFC2606];
o clarified that a successful creation of a new conference object
may or may not contain the whole confInfo object in the response;
in case it doesn't, a retrieve of the updated object can be
achieved by issuing a confRequest/retrieve;
o clarified that the scenario in Section 6.1 only involves CCMP in
adding the user to a conference; this includes requiring the use
of a password only in adding the user to the conference object;
the actual request for PIN/Password when joining thw conference is
handled by means of out-of-band mechanisms (in this case at the
media level, with the help of the MEDIACTRL framework);
o added and corrected Sidebars-related scenarios;
o added flows for some previously missing scenarios: Private
Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
Conference;
o
The following are the major changes between the 00 and the 01
versions of the draft:
o Updates to reflect change of CCMP to HTTP transport model.
The following are the major changes between the individual 01 version The following are the major changes between the individual 01 version
to the WG 00: to the WG 00:
o Updates to reflect most recent version of CCMP, including o Updates to reflect most recent version of CCMP, including
parameter names, etc. parameter names, etc.
o Added protocol details to many of the examples. o Added protocol details to many of the examples.
o Editorial: Simplifying intro, terms, etc. o Editorial: Simplifying intro, terms, etc.
The following are the major changes between the 00 and the 01
versions of the draft:
o Updates to reflect change of CCMP to HTTP transport model.
12. Acknowledgements 12. Acknowledgements
The detailed content for this document is derived from the prototype The detailed content for this document is derived from the prototype
work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
their colleagues at the University of Napoli. their colleagues at the University of Napoli.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[I-D.ietf-xcon-ccmp] [I-D.ietf-xcon-ccmp]
Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
skipping to change at page 66, line 24 skipping to change at page 78, line 15
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[I-D.ietf-xcon-ccmp] [I-D.ietf-xcon-ccmp]
Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", "Centralized Conferencing Manipulation Protocol",
draft-ietf-xcon-ccmp-02 (work in progress), March 2009. draft-ietf-xcon-ccmp-05 (work in progress), December 2009.
13.2. Informative References 13.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
RFC 4597, August 2006. RFC 4597, August 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-13 Conferencing (XCON)", draft-ietf-xcon-common-data-model-14
(work in progress), April 2009. (work in progress), November 2009.
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-call-flows]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
"Media Control Channel Framework (CFW) Call Flow "Media Control Channel Framework (CFW) Call Flow
Examples", draft-ietf-mediactrl-call-flows-00 (work in Examples", draft-ietf-mediactrl-call-flows-02 (work in
progress), March 2009. progress), October 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-08 (work in
progress), May 2009. progress), November 2009.
[I-D.boulton-xcon-session-chat] [I-D.boulton-xcon-session-chat]
Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
a Centralized Conferencing (XCON) System", a Centralized Conferencing (XCON) System",
draft-boulton-xcon-session-chat-04 (work in progress), draft-boulton-xcon-session-chat-04 (work in progress),
July 2009. July 2009.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
skipping to change at page 68, line 4 skipping to change at page 79, line 36
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 Meetecho
Via Carlo Poerio 89/a Via Carlo Poerio 89/a
Napoli 80121 Napoli 80121
Italy Italy
Email: lminiero@meetecho.com Email: lorenzo@meetecho.com
Roberta Presta Roberta Presta
University of Napoli University of Napoli
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
Italy Italy
Email: roberta.presta@unina.it Email: roberta.presta@unina.it
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
 End of changes. 230 change blocks. 
423 lines changed or deleted 928 lines changed or added

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