draft-ietf-xcon-examples-04.txt   draft-ietf-xcon-examples-05.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational L. Miniero Intended status: Informational L. Miniero
Expires: October 16, 2010 Meetecho Expires: January 3, 2011 Meetecho
R. Presta R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
April 14, 2010 July 2, 2010
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-04 draft-ietf-xcon-examples-05
Abstract Abstract
This document provides detailed call flows for the scenarios This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol objective is to provide a base reference for both protocol
researchers and developers. researchers and developers.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 16, 2010. This Internet-Draft will expire on January 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4
4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5
4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6 4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6
4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 13 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 14
5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 13 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 14
5.2. Conference Creation using Blueprints . . . . . . . . . . . 18 5.2. Conference Creation using Blueprints . . . . . . . . . . . 19
5.3. Conference Creation using User-Provided Conference 5.3. Conference Creation using User-Provided Conference
Information . . . . . . . . . . . . . . . . . . . . . . . 25 Information . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 30 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 31
6. Conference Users Scenarios and Examples . . . . . . . . . . . 33 6. Conference Users Scenarios and Examples . . . . . . . . . . . 35
6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Conference Announcements and Recordings . . . . . . . . . 41 6.3. Conference Announcements and Recordings . . . . . . . . . 43
6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 47
6.5. Entering a password-protected conference . . . . . . . . . 45 6.5. Entering a password-protected conference . . . . . . . . . 47
7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 47 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 49
7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 48 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 50
7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 57 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 59
7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 66
7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 70
8. Removing Participants and Deleting Conferences . . . . . . . . 74 8. Removing Participants and Deleting Conferences . . . . . . . . 77
8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 77
8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 80
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 81
11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 82
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.1. Normative References . . . . . . . . . . . . . . . . . . . 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 84
13.2. Informative References . . . . . . . . . . . . . . . . . . 81 13.2. Informative References . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85
1. Introduction 1. Introduction
This document provides detailed call flows for the scenarios This document provides detailed call flows for the scenarios
documented in the Framework for Centralized Conferencing (XCON documented in the Framework for Centralized Conferencing (XCON
Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
scenarios describe a broad range of use cases taking advantage of the scenarios describe a broad range of use cases taking advantage of the
advanced conferencing capabilities provided by a system realization advanced conferencing capabilities provided by a system realization
of the XCON framework. The call flows document the use of the of the XCON framework. The call flows document the use of the
interface between a conference control client and a conference interface between a conference control client and a conference
skipping to change at page 3, line 44 skipping to change at page 3, line 44
text, voice and video, including multiple media types in a single text, voice and video, including multiple media types in a single
active conference. active conference.
Conference and Media Control Client (CMCC): as defined in the XCON Conference and Media Control Client (CMCC): as defined in the XCON
Framework. In the flows in this document, the CMCC is logically Framework. In the flows in this document, the CMCC is logically
equivalent to the use of UAC as the client notation in the media equivalent to the use of UAC as the client notation in the media
control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC
differs from a generic Media Client in being an XCON-aware entity, differs from a generic Media Client in being an XCON-aware entity,
thus being able to also issue CCMP requests. thus being able to also issue CCMP requests.
Conferencing Server (ConfS): In this document, the "Conferencing Conferencing Server (ConfS): In this document, the term
Server" term is used interchangeably with the term Application "Conferencing Server" is used interchangeably with the term
Server (AS) as used in the Media Control Architectural Framework "Application Server" (AS) as used in the Media Control
[RFC5567]. A Conferencing Server is intended to be able to act as Architectural Framework [RFC5567]. A Conferencing Server is
a Conference Control Server, as defined in the XCON framework, intended to be able to act as a Conference Control Server, as
i.e. it is able to handle CCMP requests and issue CCMP responses. defined in the XCON framework, i.e. it is able to handle CCMP
requests and issue CCMP responses.
Media Server (MS): as defined in the Media Control Architectural Media Server (MS): as defined in the Media Control Architectural
Framework [RFC5567]. Framework [RFC5567].
3. Overview 3. Overview
This document provides a sampling of detailed call flows that can be This document provides a sampling of detailed call flows that can be
implemented based on a system realization of the XCON framework implemented based on a system realization of the XCON framework
[RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
intended to be a simple guide for the use of the Conference Control intended to be a simple guide for the use of the Conference Control
skipping to change at page 4, line 43 skipping to change at page 4, line 43
The rest of this document is organized as follows. Section 4 The rest of this document is organized as follows. Section 4
presents an overview on CCMP, together with some implementation- presents an overview on CCMP, together with some implementation-
related details and related matters like HTTP transport and related details and related matters like HTTP transport and
notifications. Section 5 presents the reader with examples showing notifications. Section 5 presents the reader with examples showing
the different approaches CCMP provides to create a new conference. the different approaches CCMP provides to create a new conference.
Section 6 more generally addresses the different user-related Section 6 more generally addresses the different user-related
manipulations that can be achieved by means of CCMP, by presenting a manipulations that can be achieved by means of CCMP, by presenting a
number of interesting scenarios. Section 7 addresses the several number of interesting scenarios. Section 7 addresses the several
scenarios that may involve the use of sidebars. Section 8 shows how scenarios that may involve the use of sidebars. Section 8 shows how
CCMP can be used to remove conferences and users from the system. CCMP can be used to remove conferences and users from the system.
Finally, IANA considerations are discussed in Section 9 while Finally, IANA considerations are discussed in Section 9, while
Section 10 provides a few details for what concerns the Security Section 10 provides a few details for what concerns the Security
Considerations when it comes to implementing CCMP. Considerations when it comes to implementing CCMP.
4. Working with CCMP 4. Working with CCMP
This section aims at being a brief introduction to how the This section aims at being a brief introduction to how the
Centralized Conferencing Manipulation Protocol (CCMP) Centralized Conferencing Manipulation Protocol (CCMP)
[I-D.ietf-xcon-ccmp] works and how it can be transported across a [I-D.ietf-xcon-ccmp] works and how it can be transported across a
network. Some words will be spent to describe a typical CCMP network. Some words will be spent to describe a typical CCMP
skipping to change at page 6, line 27 skipping to change at page 6, line 27
carries a wrong conference object is doomed to result in a failure. carries a wrong conference object is doomed to result in a failure.
For this reason, it is suggested that the interested implementors For this reason, it is suggested that the interested implementors
take special care in carefully checking the Data Model handlers as take special care in carefully checking the Data Model handlers as
well in order to avoid potential mistakes. well in order to avoid potential mistakes.
Of course, there are cases where a mandatory element in the Data Of course, there are cases where a mandatory element in the Data
Model cannot be assigned in a conference object by a CCMP user. For Model cannot be assigned in a conference object by a CCMP user. For
instance, a CMCC may be requesting the direct creation of a new instance, a CMCC may be requesting the direct creation of a new
conference: in this case, a conference object assumes an 'entity' conference: in this case, a conference object assumes an 'entity'
element uniquely identifying the conference to be in place. Anyway, element uniquely identifying the conference to be in place. Anyway,
the CMCC has no way to a priori know what the entity will be like, the CMCC has no way to know a priori what the entity will be like,
considering it will only be generated by the ConfS after the request. considering it will only be generated by the ConfS after the request.
For scenarios like this one, the CCMP specification envisages the use For scenarios like this one, the CCMP specification envisages the use
of a dedicated placeholder wildcard to make the conference object of a dedicated placeholder wildcard to make the conference object
compliant with the Data Model: the wildcard would then be replaced by compliant with the Data Model: the wildcard would then be replaced by
the ConfS with the right value. the ConfS with the right value.
4.2. Using HTTP as a transport 4.2. Using HTTP as a transport
CCMP requests and responses can be transported from a client to a CCMP requests and responses can be transported from a client to a
server and viceversa through several ways, being the protocol server and viceversa through several ways, being the protocol
specification agnostic with respect to the transport in use. In specification agnostic with respect to the transport in use.
[I-D.ietf-xcon-ccmp], focus is given on HTTP as a solution for this Nevertheless, in [I-D.ietf-xcon-ccmp], more focus is given on HTTP as
transport matter, and a whole chapter is devoted in the document to a solution for this transport matter, and a whole chapter is devoted
how HTTP can be used for it. The following lines will provide a in the document to how HTTP can be used for it. The following lines
brief explanation, from a more practical point of view, of how HTTP will provide a brief explanation, from a more practical point of
might be exploited to carry CCMP messages. In this document, view, of how HTTP might be exploited to carry CCMP messages. In this
however, all the call flows herein presented will just show the CCMP document, however, all the call flows herein presented will just show
interactions, without talking about how the messages could have gone the CCMP interactions, without talking about how the messages could
across the network. have gone across the network.
In case HTTP is used as a transport, the specification is very clear In case HTTP is used as a transport, the specification is very clear
with respect to how the interaction has to occur. Specifically, a with respect to how the interaction has to occur. Specifically, a
CMCC is assumed to send his request as part of an HTTP POST message, CMCC is assumed to send his request as part of an HTTP POST message,
and the ConfS would reply by means of an HTTP 200 message. In both and the ConfS would reply by means of an HTTP 200 message. In both
cases, the HTTP messages would have the CCMP messages as payload, cases, the HTTP messages would have the CCMP messages as payload,
which would be reflected in the Content-Type message. Figure 1 which would be reflected in the Content-Type message (application/
presents a ladder diagram of such interaction, which is followed by a ccmp+xml). Figure 1 presents a ladder diagram of such interaction,
dump of the exchanged HTTP messages for further analysis: which is followed by a dump of the exchanged HTTP messages for
further analysis:
CMCC ConfS CMCC ConfS
| | | |
| 1. HTTP POST (CCMP request) | | 1. HTTP POST (CCMP request) |
|--------------------------------------------->| |--------------------------------------------->|
| | | |
| |--+ Parse request, | |--+ Parse request,
| | | update object | | | update object
| |<-+ and reply | |<-+ and reply
| | | |
skipping to change at page 7, line 39 skipping to change at page 7, line 40
As it can be seen in the protocol dump in the following lines, the As it can be seen in the protocol dump in the following lines, the
CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve' CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve'
operation) towards the Conferencing Server (ConfS). The request has operation) towards the Conferencing Server (ConfS). The request has
been carried as payload of an HTTP POST (message 1.) towards a been carried as payload of an HTTP POST (message 1.) towards a
previously known location. The mandatory 'Host' header has been previously known location. The mandatory 'Host' header has been
specified, and the 'Content-Type' header has been correctly set as specified, and the 'Content-Type' header has been correctly set as
well (application/ccmp+xml). well (application/ccmp+xml).
The ConfS, in turn, has handled the request and replied accordingly. The ConfS, in turn, has handled the request and replied accordingly.
The response (a blueprintResponse with a 'success' response code) has The response (a blueprintResponse with a successful response code)
been carried as payload of an HTTP 200 OK (message 2.). As before, has been carried as payload of an HTTP 200 OK (message 2.). As
the 'Content-Type' header has been correctly set (application/ before, the 'Content-Type' header has been correctly set
ccmp+xml). (application/ccmp+xml).
1. CMCC -> ConfS (HTTP POST, CCMP request) 1. CMCC -> ConfS (HTTP POST, CCMP request)
------------------------------------------ ------------------------------------------
POST /Xcon/Ccmp HTTP/1.1 POST /Xcon/Ccmp HTTP/1.1
Content-Length: 657 Content-Length: 657
Content-Type: application/ccmp+xml Content-Type: application/ccmp+xml
Host: example.com:8080 Host: example.com:8080
Connection: Keep-Alive Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5) User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
skipping to change at page 8, line 43 skipping to change at page 8, line 44
<?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> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com"> <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>
skipping to change at page 9, line 41 skipping to change at page 9, line 43
requester by means of his XCON-USERID; except in a few scenarios requester by means of his XCON-USERID; except in a few scenarios
(presented in the following sections) this element must always (presented in the following sections) this element must always
contain a valid value; contain a valid value;
o confObjID: this element refers to the target conference object, o confObjID: this element refers to the target conference object,
according to the request in place; according to the request in place;
o operation: this element specifies the operation the CMCC wants to o operation: this element specifies the operation the CMCC wants to
perform according to the specific request type. perform according to the specific request type.
Besides those elements, the CMCC (in this case Alice, since the Besides those elements, the CMCC (let's say Alice, whose 'confUserID'
'confUserID' has been set to 'xcon-userid:Alice@example.com') has is 'xcon-userid:Alice@example.com') has also provided an additional
also provided an additional element, 'blueprintRequest'. The name of element, 'blueprintRequest'. The name of that element varies
that element varies according to the request type the CMCC is according to the request type the CMCC is interested into. In this
interested into. In this specific scenario, the CMCC was interested specific scenario, the CMCC was interested in acquiring details
in acquiring details concerning a specific blueprint (identified by concerning a specific blueprint (identified by its XCON-URI
its XCON-URI 'xcon:AudioRoom@example.com', as reflected in the 'xcon:AudioRoom@example.com', as reflected in the provided
provided 'confObjID' target element), and so the request consisted in 'confObjID' target element), and so the request consisted in an empty
an empty 'blueprintRequest' element. As it will be clearer in the 'blueprintRequest' element. As it will be clearer in the following
following sections, different request types may require different sections, different request types may require different elements and,
elements, and as a consequence different content. as a consequence, different content.
Considering the request was a 'blueprintRequest', the ConfS has Considering the request was a 'blueprintRequest', the ConfS has
replied with a 'blueprintResponse' element. This element includes a replied with a 'blueprintResponse' element. This element includes a
complete dump of the conference object (compliant with the Data complete dump of the conference object (compliant with the Data
Model) describing the requested blueprint, together with an element Model) describing the requested blueprint.
addressing the result of the client's request (response-
code=success).
This section won't delve in additional details for what concerns this This section won't delve in additional details for what concerns this
interaction. It is just worth noticing that this was the example of interaction. It is just worth noticing that this was the example of
the simplest CCMP communication that could take place between a CMCC the simplest CCMP communication that could take place between a CMCC
and a ConfS, a blueprintRequest: this scenario will be described in and a ConfS, a blueprintRequest: this scenario will be described in
more detail in Section 5.2. more detail in Section 5.2.
4.3. Conference Notifications 4.3. Conference Notifications
[RFC5239] presents several different possible protocol interactions The XCON framework [RFC5239] presents several different possible
between a conferencing server and a conferencing client. One of protocol interactions between a conferencing server and a
those interactions is generically called "Notification Protocol", conferencing client. One of those interactions is generically called
implementing a notification service for all clients interested in "Notification Protocol", implementing a notification service for all
being informed by the server whenever something relevant happens in a clients interested in being informed by the server whenever something
conference. While at first glance it may appear that such a relevant happens in a conference. While at first glance it may
functionality should belong to a conference control protocol, such appear that such a functionality should belong to a conference
feature has been specifically marked as out of scope in CCMP. As a control protocol, such feature has been specifically marked as out of
consequence, CCMP has been conceived as a request/answer protocol, scope in CCMP. As a consequence, CCMP has been conceived as a
and in fact no ways to provide notifications to clients have been request/answer protocol, and in fact no ways to provide notifications
introduced in the specification. to clients have been introduced in the specification.
Nevertheless, the CCMP document by itself has a brief section Nevertheless, the CCMP document by itself has a brief section
presenting some typical ways notifications might be managed. This presenting some typical ways notifications might be managed. This
example document does not foster one rather than another, and all the example document does not foster one rather than another, and all the
flows will always generically present a notification being involved, flows will always generically present a notification being involved,
when it seems appropriate, but not providing any info on how the when it seems appropriate, but not providing any info on how the
notification itself has been sent to the interested clients. Anyway, notification itself has been sent to the interested clients. Anyway,
this section will briefly introduce some of the most typical ways a this section will briefly introduce some of the most typical ways a
notification service could be implemented and integrated with the notification service could be implemented and integrated with the
functionality provided by CCMP. It is by no means to be intended as functionality provided by CCMP. It is by no means to be intended as
skipping to change at page 11, line 38 skipping to change at page 11, line 38
| | 5. SIP NOTIFY (changes) | | | 5. SIP NOTIFY (changes) |
| |-------------------------->| | |-------------------------->|
| | 6. SIP 200 OK | | | 6. SIP 200 OK |
| |<--------------------------| | |<--------------------------|
| | | | | |
. . . . . .
. . . . . .
Figure 2: XCON Event Package: SIP notifications Figure 2: XCON Event Package: SIP notifications
While simple and effective, this solution has a drawback: it assumes
that all clients to be notified have a SIP stack. In fact, the
approach relies on the SIP SUBSCRIBE/NOTIFY mechanism. This means
that a client without a SIP stack would be unable to receive
notifications, in case no other means were available. Of course this
is not a desired situation in a framework as XCON which has been
conceived as being signalling protocol-agnostic.
Considering CCMP is going to be probably most often deployed on HTTP, Considering CCMP is going to be probably most often deployed on HTTP,
another way to achieve notifications might be by exploiting some sort another way to achieve notifications might be by exploiting some sort
of HTTP callbacks, as suggested in the CCMP specification itself. of HTTP callbacks, as suggested in the CCMP specification itself.
This would allow to overcome the previous limitation, since both the This would allow to overcome the previous limitation, since both the
CMCC and the ConfS would already have an HTTP stack to make use of. CMCC and the ConfS would already have an HTTP stack to make use of.
Using this approach, an interested web client might provide the Using this approach, an interested web client might provide the
Conferencing System with an URL to contact whenever updates are Conferencing System with an URL to contact whenever updates are
available: the update could be part of the notification message available: the update could be part of the notification message
itself, or it could be only implicitly referenced by the itself, or it could be only implicitly referenced by the
notification. At the same time, alternative notification means could notification. At the same time, alternative notification means could
be exploited, e.g. by taking advantage of functionality provided by be exploited, e.g. by taking advantage of functionality provided by
other protocols such as XMPP. Figure 3 shows an example of different other protocols such as XMPP. Figure 3 shows an example of different
subscriptions which accordingly trigger notifications after the same subscriptions which accordingly trigger notifications after the same
skipping to change at page 13, line 14 skipping to change at page 14, line 11
rely on several other solutions than the ones presented as periodic rely on several other solutions than the ones presented as periodic
checks of a well known URL by interested clients, long polls, BOSH- checks of a well known URL by interested clients, long polls, BOSH-
based communications, Atom/RSS feeds and the like. based communications, Atom/RSS feeds and the like.
5. Conference Creation 5. Conference Creation
This section starts the sequence of call flows of typical XCON- This section starts the sequence of call flows of typical XCON-
related scenarios provided in this document. Specifically, it related scenarios provided in this document. Specifically, it
provides details associated with the various ways in which a provides details associated with the various ways in which a
conference can be created using CCMP and the XCON framework conference can be created using CCMP and the XCON framework
constructs. As previously mentioned the details of the media constructs. As previously mentioned, the details of the media
control, call signaling and floor control protocols, where control, call signaling and floor control protocols, where
applicable, are annotated in the flows without showing all the applicable, are annotated in the flows without showing all the
details. This also applies to CCMP, whose flows are related to the details. This also applies to CCMP, whose flows are related to the
protocol alone, hiding any detail concerning the transport that may protocol alone, hiding any detail concerning the transport that may
have been used (e.g. HTTP). However, for clarification purposes, have been used (e.g. HTTP). However, for clarification purposes,
the first example Section 5.1 provides the details of the media the first example Section 5.1 provides the details of the media
control messaging along with an example of the standard annotation control messaging along with an example of the standard annotation
used throughout the remainder of this document. In subsequent flows, used throughout the remainder of this document. In subsequent flows,
only this annotation (identified by lower case letters) is included only this annotation (identified by lower case letters) is included
and the reader is encouraged to refer to the call flows in the and the reader is encouraged to refer to the call flows in the
skipping to change at page 13, line 42 skipping to change at page 14, line 39
The simplest manner in which a conference can be created is The simplest manner in which a conference can be created is
accomplished by the client sending a "confRequest" message with the accomplished by the client sending a "confRequest" message with the
"create" operation as the only parameter to the conference server, "create" operation as the only parameter to the conference server,
together with the "confUserID" associated with the requesting client together with the "confUserID" associated with the requesting client
itself. This results in the creation of a default conference, with itself. This results in the creation of a default conference, with
an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
in the form of the "confUserID" parameter (the same already present in the form of the "confUserID" parameter (the same already present
in the request) and the data for the conference object in the in the request) and the data for the conference object in the
"confInfo" parameter all returned in the "confResponse" message. "confInfo" parameter all returned in the "confResponse" message.
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 issuing user to the conference upon creation (e.g.,
conference object (e.g., "method" attribute in the "target" element "method" attribute in the <target> element of <allowed-users-list>
of "allowed-users-list" may be set to "dial out" for this client may be set to "dial out" for this client, based on the particular
based on the particular conferencing systems default). This is conferencing systems default). This is exactly the case depicted in
exactly the case depicted in the figure, which is presented to enrich the figure, which is presented to enrich the scenario.
the scenario.
The specific data for the conference object are returned in the The specific data for the conference object are 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 these data client (with the appropriate authorization) to manipulate these 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. Please notice that, according to the CCMP additional flows. Please notice that, according to the CCMP
specification, the return of the new conference data in the specification, the return of the new conference data in the
"confInfo" parameter is not mandatory: if the "confInfo" parameter of "confInfo" parameter is not mandatory: if the "confInfo" parameter of
the successful confResponse/create is void, a following confRequest/ the successful confResponse/create is void, a following confRequest/
retrieve of the returned "confObjID" can be triggered to provide the retrieve of the returned "confObjID" can be triggered to provide the
requesting client with the detailed conference description. requesting client with the detailed conference description.
Clients that are not XCON-aware can join the conference using a Clients that are not XCON-aware can join the conference using a
specific signaling interface such as SIP [RFC3261] or other supported specific signaling interface such as SIP [RFC3261] (using the
signaling protocols (being XCON agnostic with respect to them), using signaling interface to the conference focus as described in
the signaling interface to the conference focus as described in [RFC4579]), or other supported signaling protocols, being XCON
[RFC4579]. However, these details are not shown in the message agnostic with respect to them. However, these details are not shown
flows. The message flows in this document identify the point in the in the message flows. The message flows in this document identify
message flows at which this signaling occurs via the lower case the point in the message flows at which this signaling occurs via the
letter items (i.e., (a)...(x)) along with the appropriate text for lower case letter items (i.e., (a)...(x)) along with the appropriate
the processing done by the conferencing server. text for the processing done by the conferencing server.
As anticipated at the beginning of this section, this example also As anticipated at the beginning of this section, this example also
shows how the conferencing system may make use of other standard shows how the conferencing system may make use of other standard
components to make available its functionality. An example of that components to make available its functionality. An example of that
is the MEDIACTRL specification, which allows the conferencing system is the MEDIACTRL specification, which allows the conferencing system
to configure conference mixes, IVR dialogs and all sort of media- to configure conference mixes, IVR dialogs and all sort of media-
related interactions an application like this may need. So, just to related interactions an application like this may need. So, just to
provide the reader with some insight on these interactions, the provide the reader with some insight on these interactions, the
conferencing system also configures and starts a mixer via MEDIACTRL conferencing system also configures and starts a mixer via MEDIACTRL
as soon as the conference is created (transactions A1 and A2), and as soon as the conference is created (transactions A1 and A2), and
skipping to change at page 15, line 22 skipping to change at page 16, line 22
| | |& 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(confUserID,confObjID, | | |(2)confResponse(confUserID,confObjID, | |
| create, success, | | | create, 200, success, | |
| version, confInfo) | | | version, confInfo) | |
|<--------------------------------------| | |<--------------------------------------| |
| | | | | | | | | |
| | (c) Focus +---| | | | (c) Focus +---| |
| | sets up | | | | | sets up | | |
| | signaling | | | | | signaling | | |
| | to CMCC1 +-->| | | | to CMCC1 +-->| |
| | | | | | | | | |
| | | | B1. CONTROL | | | | | B1. CONTROL |
| | | |+++++++++++>>| | | | |+++++++++++>>|
skipping to change at page 16, line 22 skipping to change at page 17, line 22
| | (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(confUserID, confObjID | |(2)confResponse(confUserID, confObjID |
| create, success, | | create, 200, success, |
| version, confInfo) | | version, confInfo) |
| | | | | | | |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | | | | | |
| | (c) Focus +---| | | (c) Focus +---|
| | sets up | | | | sets up | |
| | signaling | | | | signaling | |
| | to CMCC1 +-->| | | to CMCC1 +-->|
| | | | | | | |
skipping to change at page 17, line 17 skipping to change at page 18, line 17
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse/create message ("success", created conference 2. confResponse/create message ("success", created conference
object returned) object returned)
<?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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.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>
skipping to change at page 18, line 17 skipping to change at page 19, line 20
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
<info:conference-state> <info:conference-state>
<active>false</active> <active>false</active>
</info:conference-state> </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@example.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 6: Create Basic Conference (Annotated) Detailed Messaging Figure 6: Create Basic Conference (Annotated) Detailed Messaging
5.2. Conference Creation using Blueprints 5.2. Conference Creation using Blueprints
The previous example showed the creation of a new conference using The previous example showed the creation of a new conference using
default values. This means the client provided no information about default values. This means the client provided no information about
how she wanted the conference to be like. Anyway, the XCON framework how she wanted the conference to be like. Anyway, the XCON framework
(and CCMP as a consequence) allows for the exploitation of templates. (and CCMP as a consequence) allows for the exploitation of templates.
These templates are called "conference blueprints", and are basically These templates are called "conference blueprints", and are basically
conference objects with pre-defined settings except for the actual conference objects with pre-defined settings. This means that a
identifiers. This means that a client might get one of these client might get one of these blueprints, choose the one that more
blueprints, choose the one that more fits his needs, and use the fits his needs, and use the chosen blueprint to create a new
chosen blueprint to create a new conference. conference.
This section addresses exactly this scenario, and Figure 7 provides This section addresses exactly this scenario, and Figure 7 provides
an example of one client, "Alice", discovering the conference an example of one client, "Alice", discovering the conference
blueprints available for a particular conferencing system and blueprints available for a particular conferencing system and
creating a conference based on the desired blueprint. In particular, creating a conference based on the desired blueprint. In particular,
Alice is interested in those blueprints suitable to represent a Alice is interested in those blueprints suitable to represent a
"video-conference", i.e. a conference in which both audio and video "video-conference", i.e. a conference in which both audio and video
are available, so she exploits the filter mechanism envisioned by are available, so she exploits the filter mechanism envisioned by
CCMP to make a selective blueprints retrieve request. This results CCMP to make a selective blueprints retrieve request. This results
in three distinct CCMP transactions. in three distinct CCMP transactions.
CMCC "Alice" ConfS CMCC "Alice" ConfS
| | | |
| (1) blueprintsRequest | | (1) blueprintsRequest |
| (confUserID,xpathFilter) | | (confUserID,xpathFilter) |
|------------------------------>| |------------------------------>|
| | | |
| (2) blueprintsResponse | | (2) blueprintsResponse |
| (confUserID, success, | | (confUserID, |
| blueprintsInfo) | | 200, success, |
| blueprintsInfo) |
| |
|<------------------------------| |<------------------------------|
| | | |
|--+ | |--+ |
| | choose preferred | | | choose preferred |
| | blueprint from the | | | blueprint from the |
| | list (blueprintName) | | | list (blueprintName) |
|<-+ | |<-+ |
| | | |
| (3) blueprintRequest | | (3) blueprintRequest |
| (confUserID,confObjID, | | (confUserID,confObjID, |
| retrieve) | | retrieve) |
|------------------------------>| |------------------------------>|
| | | |
| 4) blueprintResponse | | 4) blueprintResponse |
| (confUserID,confObjID,| | (confUserID,confObjID,|
| retrieve,confInfo) | | retrieve, 200, |
| success, confInfo) |
|<------------------------------| |<------------------------------|
| | | |
| (5) confRequest(confUserID, | | (5) confRequest(confUserID, |
| confObjID,create) | | 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)
|(6) confResponse | |(6) confResponse |
| (confUserID, confObjID*, | | (confUserID, confObjID*, |
| create, success) | | create, 200, success) |
|<------------------------------| |<------------------------------|
| | | |
| | | |
| | | |
. . . .
. . . .
Figure 7: Client Creation of Conference using Blueprints Figure 7: Client Creation of Conference using Blueprints
1. Alice first sends a "blueprintsRequest" message to the 1. Alice first sends a "blueprintsRequest" message to the
conferencing system identified by the conference server discovery conferencing system identified by the conference server discovery
process. This request contains the "confUserID" of the user process. This request contains the "confUserID" of the user
issuing the request (Alice's XCON-USERID) and the "xpathFilter" issuing the request (Alice's XCON-USERID) and the "xpathFilter"
parameter by which Alice specifies she desires to obtain only parameter by which Alice specifies she desires to obtain only
blueprints providing support for both audio and video: for this blueprints providing support for both audio and video: for this
skipping to change at page 21, line 36 skipping to change at page 22, line 42
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:VideoRoom@example.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,
4 users can talk and be seen at the same time, 4 users can talk and be seen at the same time,
and the floor requests are automatically accepted. and the floor requests are automatically accepted.
skipping to change at page 22, line 30 skipping to change at page 23, line 43
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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID> <confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:blueprintRequest/> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. blueprintResponse/retrieve message ("success", "VideoRoom" 4. blueprintResponse/retrieve message ("VideoRoom"
conference object returned) conference object returned)
<?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> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID> <confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="xcon:VideoRoom@example.com"> <blueprintInfo entity="xcon:VideoRoom@example.com">
<info:conference-description> <info:conference-description>
<info:display-text>VideoRoom</info:display-text> <info:display-text>VideoRoom</info:display-text>
<info:maximum-user-count>4</info:maximum-user-count> <info:maximum-user-count>4</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:entry label="videoLabel"> <info:entry label="videoLabel">
skipping to change at page 23, line 44 skipping to change at page 25, line 12
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID> <confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:confRequest/> <ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
6. confResponse/create message ("success", cloned conference 6. confResponse/create message (cloned conference
object returned) object returned)
<?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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.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 VideoRoom New conference by Alice cloned from VideoRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
skipping to change at page 25, line 24 skipping to change at page 26, line 40
A conference can also be created by the client sending a A conference can also be created by the client sending a
"confRequest" message with the "create" operation, along with the "confRequest" message with the "create" operation, along with the
desired data in the form of the "confInfo" parameter for the desired data in the form of the "confInfo" parameter for the
conference to be created. The request also includes the "confUserID" conference to be created. The request also includes the "confUserID"
of the requesting entity. of the requesting entity.
This approach allows for a client (in this example Alice) to This approach allows for a client (in this example Alice) to
completely describe how the conference object should look like, completely describe how the conference object should look like,
without just relying on defaults or blueprints: i.e. which media without just relying on defaults or blueprints: i.e. which media
should be available, whish should be the topic, the users allowed to should be available, which should be the topic, the users allowed to
join, any scheduling-related information and so on. This can be join, any scheduling-related information and so on. This can be
done, as anticipated, by providing in the creation request a full done, as anticipated, by providing in the creation request a full
conference object for the server to parse. conference object for the server to parse.
This "confInfo" parameter must comply of course with the Data Model This "confInfo" parameter must comply of course with the Data Model
specification. This means that its "entity" attribute is mandatory, specification. This means that its "entity" attribute is mandatory,
and cannot be missing in the document. Nevertheless, considering in and cannot be missing in the document. Nevertheless, considering in
this example the client is actually requesting the creation of a new this example the client is actually requesting the creation of a new
conference, which doesn't exist yet, this "entity" attribute cannot conference, which doesn't exist yet, this "entity" attribute cannot
be set to a valid value. This is related to an issue already be set to a valid value. This is related to an issue already
skipping to change at page 25, line 49 skipping to change at page 27, line 18
would subsequently be replaced by the conferencing system with the would subsequently be replaced by the conferencing system with the
actual value. This means that, as soon as the conferencing system actual value. This means that, as soon as the conferencing system
actually creates the conference, a valid "entity" value is created actually creates the conference, a valid "entity" value is created
for it as well, which would take the place of the wildcard when for it as well, which would take the place of the wildcard when
completing the actual conference object provided by the client. completing the actual conference object provided by the client.
To give a flavour of what could be added to the conference object, we To give a flavour of what could be added to the conference object, we
assume Alice is also interested in providing scheduling-related assume Alice is also interested in providing scheduling-related
information. So, in this example, Alice also specifies by the information. So, in this example, Alice also specifies by the
<conference-time> element included in the "confInfo" that the <conference-time> element included in the "confInfo" that the
conference she wants to create has to occur on a certain date from a conference she wants to create has to occur on a certain date
certain start time to a certain stop time and has to be replicated spanning from a certain start time to a certain stop time and has to
weekly. be replicated weekly.
Moreover, Alice indicates by means of the <allowed-users-list> that
at the start time Bob, Carol and herself have to be called by the
conferencing system to join the conference (in fact, for each
<target> corresponding to one of the above-mentioned clients, the
"method" attribute is set to "dial-out").
Once Alice has prepared the "confInfo" element and sent it as part of Once Alice has prepared the "confInfo" element and sent it as part of
her request to the server, if the conferencing system can support her request to the server, if the conferencing system can support
that specific type of conference (capabilities, etc.), then the that specific type of conference (capabilities, etc.), then the
request results in the creation of a conference. We assume the request results in the creation of a conference. We assume the
request has been successful, and as a consequence XCON-URI in the request has been successful, and as a consequence XCON-URI in the
form of the "confObjID" parameter and the XCON-USERID in the form of form of the "confObjID" parameter and the XCON-USERID in the form of
the "confUserID" parameter (again, the same as the requesting entity) the "confUserID" parameter (again, the same as the requesting entity)
are returned in the "confResponse" message. are returned in the "confResponse" message.
In this example, we choose not to return the created conference In this example, we choose not to return the created conference
object in the successful "confResponse" in the "confInfo" parameter. object in the successful "confResponse" in the "confInfo" parameter.
Nevertheless, Alice could still retrieve the actual conference object Nevertheless, Alice could still retrieve the actual conference object
by issuing a "confRequest" with a "retrieve" operation on the by issuing a "confRequest" with a "retrieve" operation on the
returned "confObjID". Such a request would show how, as we returned "confObjID". Such a request would show how, as we
anticipated at the beginning of this section, the "entity" attribute anticipated at the beginning of this section, the "entity" attribute
of the conference object in "confInfo" is replaced with the actual of the conference object in "confInfo" is replaced with the actual
information (i.e. "xcon:6845432@example.com"). information (i.e. "xcon:6845432@example.com").
Just for the sake of completeness and to provide the reader with some
insight about how the CCMP conferencing server might interact with
other related components, this example also assumes that the
conference is activated upon creation: i.e., the "method" attribute
is set to "dial out" for this client based on the particular
conferencing systems default. This results (as shown in the ladder
diagram) in Alice, Bob and Carol being called by the conferencing
system. Just as before, this is not to be considered mandatory,
since it depends on the implementation choices of the framework.
Alice Bob Carol ConfS Alice Bob Carol ConfS
| | | | | | | |
| | | | | | | |
|(1)confRequest(confUserID, | | |(1)confRequest(confUserID, | |
| create, confInfo) | | | 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(confUserID | | |(2)confResponse(confUserID,| |
| confObjID, create, | | | confObjID, create, | |
| success, version) | | | 200, success, version) |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
===========================================
... ... ... ...
========== START TIME OCCURS ==============
| | (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 28, line 14 skipping to change at page 29, line 31
|<***All parties connected to conf Y***>| |<***All parties connected to conf Y***>|
| | | | | | | |
| | | | | | | |
" " " " " " " "
" " " " " " " "
" " " " " " " "
Figure 9: Create Basic Conference from user provided conference-info Figure 9: Create Basic Conference from user provided conference-info
1. confRequest/create message (Alice proposes a conference object 1. confRequest/create message (Alice proposes a conference object
to be created - direct creation) to be created)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
skipping to change at page 28, line 43 skipping to change at page 30, line 17
<info:available-media> <info:available-media>
<info:entry label="AUTO_GENERATE_2"> <info:entry label="AUTO_GENERATE_2">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
<xcon:conference-time> <xcon:conference-time>
<xcon:entry> <xcon:entry>
<xcon:base> <xcon:base>
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
PRODID:-//Mozilla.org/NONSGML \ PRODID:-//Mozilla.org/NONSGML
Mozilla Calendar V1.0//EN Mozilla Calendar V1.0//EN
BEGIN:VEVENT BEGIN:VEVENT
DTSTAMP: 20100127T140728Z DTSTAMP: 20100127T140728Z
UID: 20100127T140728Z-345FDA-alice@example.com UID: 20100127T140728Z-345FDA-alice@example.com
ORGANIZER:MAILTO:alice@example.com ORGANIZER:MAILTO:alice@example.com
DTSTART:20100127T143000Z DTSTART:20100127T143000Z
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
DTEND: 20100127T163000Z DTEND: 20100127T163000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
</xcon:base> </xcon:base>
<xcon:mixing-start-offset \ <xcon:mixing-start-offset
required-participant="moderator"> required-participant="moderator">
2010-01-27T14:29:00Z 2010-01-27T14:29:00Z
</xcon:mixing-start-offset> </xcon:mixing-start-offset>
<xcon:mixing-end-offset \ <xcon:mixing-end-offset
required-participant="participant"> required-participant="participant">
2010-01-27T16:31:00Z</xcon:mixing-end-offset> 2010-01-27T16:31:00Z
</xcon:mixing-end-offset>
<xcon:must-join-before-offset> <xcon:must-join-before-offset>
2010-01-27T15:30:00Z 2010-01-27T15:30:00Z
</xcon:must-join-before-offset> </xcon:must-join-before-offset>
</xcon:entry> </xcon:entry>
</xcon:conference-time> </xcon:conference-time>
</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@example.com" <xcon:target uri="xcon-userid:alice@example.com"
skipping to change at page 29, line 34 skipping to change at page 31, line 4
<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@example.com" <xcon:target uri="xcon-userid:alice@example.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:bob83@example.com" <xcon:target uri="sip:bob83@example.com"
method="dial-out"/> method="dial-out"/>
<xcon:target uri="sip:carol@example.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/create message ("success") 2. confResponse/create message (200, "success")
<?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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID> <confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success<response-code> <response-code>200<response-code>
<response-string>success<response-string>
<version>1</version> <version>1</version>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 10: Create Basic Conference Detailed Messaging Figure 10: Create Basic Conference Detailed Messaging
5.4. Cloning an Existing Conference 5.4. Cloning an Existing Conference
A client can also create another conference by cloning an existing A client can also create another conference by cloning an existing
conference, such as an active conference or conference reservation. conference, such as an active conference or conference reservation.
skipping to change at page 30, line 31 skipping to change at page 32, line 4
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.2. The manner by which a client blueprint is provided in Section 5.2. The manner by which a client
in this example might learn about a conference reservation or active in this example might learn about a conference reservation or active
conferences is similar to the first step in the blueprint example, conferences is similar to the first step in the blueprint example,
with the exception of specifying querying for different types of with the exception of querying for different types of conference
conference objects supported by the specific conferencing system. objects supported by the specific conferencing system. For example,
For example, in this example, the client clones a conference in this example, the client clones a conference reservation (i.e., an
reservation (i.e., an inactive conference). 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. conference object returned in the "confResponse" message.
Alice ConfS Alice ConfS
| | | |
|(1)confRequest(confUserID, | |(1)confRequest(confUserID, |
skipping to change at page 31, line 22 skipping to change at page 32, line 32
| Object | | | Object | |
| & IDs +-->| | & IDs +-->|
| |--+ (b) MS | |--+ (b) MS
| | | creates | | | creates
| | | conf and | | | conf and
| |<-+ its ID | |<-+ its ID
| | (confid=Y) | | (confid=Y)
| | | |
|(2)confResponse(confUserID, | |(2)confResponse(confUserID, |
| confObjID*,create, | | confObjID*,create, |
| success, version, | | 200, success, |
| confInfo) | | version, confInfo) |
| | | |
|<------------------------------| |<------------------------------|
| | | |
Figure 11: Create Basic Conference - Clone Figure 11: Create Basic Conference - Clone
1. Alice, a conferencing system client, sends a confRequest message 1. Alice, a conferencing system client, sends a confRequest message
to clone a conference based on an existing conference to clone a conference based on an existing conference
reservation. Alice indicates this conference should be cloned reservation. Alice indicates this conference should be cloned
from the specified parent conference represented by the from the specified parent conference represented by the
skipping to change at page 32, line 10 skipping to change at page 33, line 22
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
use this new identifier. The conferencing system maintains the use this new identifier. The conferencing system maintains the
mapping between this conference ID and the parent conference 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/create message 1. confRequest/create message (Alice clones an existing conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID> <confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse/create message ("success", created conference 2. confResponse/create message (created conference
object returned) object returned)
<?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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.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@example.com xcon:6845432@example.com
</xcon:cloning-parent> </xcon:cloning-parent>
<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>
skipping to change at page 34, line 27 skipping to change at page 36, line 18
|(1) userRequest(confUserID,| | |(1) userRequest(confUserID,| |
| confObjID, create, | | | confObjID, create, | |
| userInfo) | | | | userInfo) | | |
|-------------------------------------->| |-------------------------------------->|
| | | | | | | |
| | (a) Create +---| | | (a) Create +---|
| | | Bob | | | | | Bob | |
| | | as a | | | | | as a | |
| | | user +-->| | | | user +-->|
| | | | | | | |
|(2) userResponse(confUserID,confObjID | |(2) userResponse(confUserID, confObjID |
| create,success,userInfo) | | create, 200, success, userInfo) |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | (b) Focus | | | | (b) Focus |
| | | sets up | | | | sets up |
| | | signaling | | | | signaling |
| | | to Bob | | | | to Bob |
| |<----------------------| | |<----------------------|
| | | | | | | |
| | | (c) Notify| | | | (c) Notify|
| | | ("Bob just| | | | ("Bob just|
| | | joined") | | | | joined") |
| | |<----------| | | |<----------|
| | | | | | | |
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
Figure 13: Client Manipulation of Conference - Add a party Figure 13: Client Manipulation of Conference - Add a party
1. Alice sends a userRequest message with an operation of "create" 1. Alice sends a userRequest message with an operation of "create"
to add Bob to the specific conference as identified by the to add Bob to the specific conference as identified by the
"confObjID". The "create" operation also makes sure that Bob is "confObjID". The "create" operation also makes sure that Bob is
created as a user in the whole conferencing system. This is done created as a user in the whole conferencing system. This is done
by adding a "userInfo" element describing Bob as a user. This is by adding in the request a "userInfo" element describing Bob as a
needed in order to let the conferencing system be aware of Bob's user. This is needed in order to let the conferencing system be
characteristics. In case Bob was already a registered user, aware of Bob's characteristics. In case Bob was already a
Alice would just have referenced him through his XCON-USERID in registered user, Alice would just have referenced him through his
the "entity" attribute of the "userInfo" field, without providing XCON-USERID in the "entity" attribute of the "userInfo" field,
additional data. In fact, that data (including, for instance, without providing additional data. In fact, that data
Bob's SIP-URI to be used subsequently for dial-out) would be (including, for instance, Bob's SIP-URI to be used subsequently
obtained by referencing the extant registration. The conference for dial-out) would be obtained by referencing the extant
server ensures that Alice has the appropriate authority based on registration. The conference server ensures that Alice has the
the policies associated with that specific conference object to appropriate authority based on the policies associated with that
perform the operation. As mentioned before, a new Conference specific conference object to perform the operation. As
User Identifier is created for Bob, and the "userInfo" is used to mentioned before, a new Conference User Identifier is created for
update the conference object accordingly. As already seen in Bob, and the "userInfo" is used to update the conference object
Section 5.3, a placeholder wildcard accordingly. As already seen in Section 5.3, a placeholder
("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages wildcard ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP
below) is used for the "entity" attribute of the "userInfo" messages below) is used for the "entity" attribute of the
element, to be replaced by the actual XCON-USERID later on; "userInfo" element, to be replaced by the actual XCON-USERID
later on;
2. Bob is successfully added to the conference object, and an XCON- 2. Bob is successfully added to the conference object, and an XCON-
USERID is allocated for him ("xcon-userid:Bob@example.com"); this USERID is allocated for him ("xcon-userid:Bob@example.com"); this
identifier is reported in the response as part of the "entity" identifier is reported in the response as part of the "entity"
element of the returned "userInfo"; element of the returned "userInfo";
3. In the presented example, the call signaling to add Bob to the 3. In the presented example, the call signaling to add Bob to the
conference is instigated through the Focus as well. We again conference is instigated through the Focus as well. We again
remind that this is implementation specific. In fact, a remind that this is implementation specific. In fact, a
conferencing system may accomplish different actions after the conferencing system may accomplish different actions after the
user creation, just as it may do nothing at all. Among the user creation, just as it may do nothing at all. Among the
possible actions, for instance Bob may be added as a <target> possible actions, for instance, Bob may be added as a <target>
element to the <allowed-users-list> element, whose joining element to the <allowed-users-list> element, whose joining
"method" may be either "dial-in" or "dial-out". Besides, out-of- "method" may be either "dial-in" or "dial-out". Besides, out-of-
band notification mechanisms may be involved as well, e.g. to band notification mechanisms may be involved as well, e.g. to
notify Bob via mail of the new conference, including details as notify Bob via mail of the new conference, including details as
the date, password, expected participants and so on (see the date, password, expected participants and so on (see
Section 4.3). Section 4.3).
To conclude the overview on this scenario, once Bob has been To conclude the overview on this scenario, once Bob has been
successfully added to the specified conference, per updates to the successfully added to the specified conference, per updates to the
state, and depending upon the policies, other participants state, and depending upon the policies, other participants
skipping to change at page 36, line 33 skipping to change at page 38, line 20
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:bob83@example.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse/create message ("success": a new XCON-USERID is 2. userResponse/create message (a new XCON-USERID is
created for Bob and he is added to the conference) created for Bob and he is added to the conference)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>10</version> <version>10</version>
<ccmp:userResponse> <ccmp:userResponse>
<userInfo entity="xcon-userid:Bob@example.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>
skipping to change at page 37, line 15 skipping to change at page 39, line 4
<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@example.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
</userInfo> </userInfo>
</ccmp:userResponse> </ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 14: Add Party Message Details Figure 14: Add Party Message Details
6.2. Muting a Party 6.2. Muting a Party
This section provides an example of the muting of a party in an This section provides an example of the muting of a party in an
active conference. We assume that the user to mute has already been active conference. We assume that the user to mute has already been
added to the conference. The document only addresses muting, since added to the conference. The document only addresses muting and not
unmuting would involve an almost identical CCMP message flow. unmuting as well, since it would involve an almost identical CCMP
message flow anyway. Although, in case that any external floor
control is involved, whether or not a particular conference client
can actually mute/unmute itself must be considered by the
conferencing system.
Please notice that interaction between CCMP and an ad-hoc designed Please notice that interaction between CCMP and floor control
floor control solution like BFCP should be carefully considered. should be carefully considered. In fact, handling CCMP- and BFCP-
Indeed, CCMP- and BFCP-based media control can be viewed as two based media control has to be considered as multiple layers: i.e.,
alternative and potentially interfering solutions for what a participant may have the BFCP floor granted, but be muted by
concerns floor control actions. As an example, a participant may means of CCMP. If so, he would still be muted in the conference,
have the BFCP floor granted, but be muted by means of CCMP; if so, and would only be unmuted if both the protocols allowed for this.
he would still be muted in the conference and would only be
unmuted if both protocols allowed for this. In general, the
interaction between these potentially conflicting protocols falls
in the wider scope of policy control at the overall system's level
and is not the subject of this document.
Figure 15 provides an example of one client, "Alice", impacting the Figure 15 provides an example of one client, "Alice", impacting the
media state of another client, "Bob". This example assumes an media state of another client, "Bob". This example assumes an
established conference. In this example, Alice, whose role is established conference. In this example, Alice, whose role is
"moderator" of the conference, wants to mute Bob on a medium-size "moderator" of the conference, wants to mute Bob on a medium-size
multi-party conference, as his device is not muted (and he's multi-party conference, as his device is not muted (and he's
obviously not listening to the call) and background noise in his obviously not listening to the call) and background noise in his
office environment is disruptive to the conference. BFCP floor office environment is disruptive to the conference. BFCP floor
control is assumed not to be involved. control is assumed not to be involved.
skipping to change at page 38, line 27 skipping to change at page 40, line 26
| | | |<-----------------| | | | |<-----------------|
| | | | | | | | | |
| |<====== 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(confUserID,confObjID, | | | (2)userResponse(confUserID,confObjID, | |
| update,success,version) | | | update,200,success,version) | |
|<---------------------------------------| | |<---------------------------------------| |
| | | | | | | | | |
| | | (b) Notify | | | | | (b) Notify | |
| | | ("Bob is | | | | | ("Bob is | |
| | | muted") | | | | | muted") | |
| | |<-----------| | | | |<-----------| |
| | | | | | | | | |
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
' ' ' ' ' ' ' ' ' '
skipping to change at page 39, line 22 skipping to change at page 41, line 19
reflecting that Bob's media is not to be mixed with the reflecting that Bob's media is not to be mixed with the
conference media. In case the Conference Server relies on a conference media. In case the Conference Server relies on a
remote Media Server for its multimedia functionality, it remote Media Server for its multimedia functionality, it
subsequently changes Bob's media profile accordingly by means of subsequently changes Bob's media profile accordingly by means of
the related protocol interaction with the MS to enforce the the related protocol interaction with the MS to enforce the
decision. An example describing a possible way of dealing with decision. An example describing a possible way of dealing with
such a situation using the Media Server Control architecture is such a situation using the Media Server Control architecture is
described in [I-D.ietf-mediactrl-call-flows], at "Simple described in [I-D.ietf-mediactrl-call-flows], at "Simple
Bridging: Framework Transactions (2)". Bridging: Framework Transactions (2)".
2. A userResponse message with a response-code of "success" is then 2. A userResponse message with a "200" response-code ("success") is
sent to Alice. Depending upon the policies, the conference then sent to Alice. Depending upon the policies, the conference
server may notify other participants (including Bob) of this server may notify other participants (including Bob) of this
update via any Conference Notification Service that may be in update via any Conference Notification Service that may be in
use. use.
1. userRequest/update message (Alice mutes Bob) 1. userRequest/update message (Alice mutes Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
skipping to change at page 40, line 33 skipping to change at page 42, line 33
<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/update message ("success") 2. userResponse/update message (Bob has been muted)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>7</version> <version>7</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 16: Mute Message Details Figure 16: Mute Message Details
6.3. Conference Announcements and Recordings 6.3. Conference Announcements and Recordings
This section deals with features that are typically required in a This section deals with features that are typically required in a
conferencing system, that are public announcements (e.g. to notify conferencing system, that are public announcements (e.g. to notify
vocally that a new user joined a conference) and name recording. vocally that a new user joined a conference) and name recording.
While this is not strictly CCMP-related (the CCMP signaling is While this is not strictly CCMP-related (the CCMP signaling is
actually the same as the one seen in Section 6.1) it is an actually the same as the one seen in Section 6.1) it is an
interesting scenario to address to see how the several components of interesting scenario to address to see how the several components of
skipping to change at page 42, line 49 skipping to change at page 44, line 49
|<========= 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(confUserID,| | | (2)userResponse(confUserID,| |
| confObjID, create, | | | confObjID,create,200,| |
| success, version) | | | success,version) | |
|<---------------------------| | |<---------------------------| |
| | | | | |
Figure 17: Recording and Announcements Figure 17: Recording and Announcements
1. Upon receipt of the userRequest from Alice to be added to Bob's 1. Upon receipt of the userRequest from Alice to be added to Bob's
conference, the conferencing system determines that a password is conference, the conferencing system determines that a password is
required for this specific conference. Thus an announcement required for this specific conference. Thus an announcement
asking Alice to enter the password is sent back. This may be asking Alice to enter the password is sent back. This may be
achieved by means of typical IVR functionality. Once Alice achieved by means of typical IVR functionality. Once Alice
enters the password, it is validated against the policies enters the password, it is validated against the policies
skipping to change at page 44, line 5 skipping to change at page 46, line 5
conference (if she were to have the appropriate policies), conference (if she were to have the appropriate policies),
including registering for event notifications associated with the including registering for event notifications associated with the
conference. Once the call signaling indicates that Alice has conference. Once the call signaling indicates that Alice has
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.
1. userRequest/create message (Alice - a new conferencing system 1. userRequest/create message (Alice - a new conferencing system client -
client - enters Bob's conference) enters Bob's conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
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">
<confObjID>xcon:bobConf@example.com</confObjID> <confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Alice83@example.com mailto:Alice83@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2.userResponse/create ("success": Alice is provided with a new 2. userResponse/create (Alice provided with a new xcon-userid
xcon-userid and is added to the conference) and added to the conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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">
<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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:bobConf@example.com</confObjID> <confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<version>5</version> <response-string>success</response-string>
<ccmp:userResponse/> <version>5</version>
</ccmpResponse> <ccmp:userResponse/>
</ccmp:ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse>
Figure 18: Announcement Messaging Details Figure 18: Announcement Messaging Details
6.4. Monitoring for DTMF 6.4. Monitoring for DTMF
Conferencing systems often also need the capability to monitor for Conferencing systems often also need the capability to monitor for
DTMF from each individual participant. This would typically be used DTMF from each individual participant. This would typically be used
to enter the identifier and/or access code for joining a specific to enter the identifier and/or access code for joining a specific
conference. This feature is often also exploited to achieve conference. This feature is often also exploited to achieve
interaction between participants and the conference system for non- interaction between participants and the conference system for non-
XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted). XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted).
skipping to change at page 45, line 48 skipping to change at page 47, line 48
add herself in the conference with XCON-URI add herself in the conference with XCON-URI
"xcon:8977777@example.com" (written in the "confObjID" "xcon:8977777@example.com" (written in the "confObjID"
parameter). Alice provides her XCON-USERID via the "confUserID" parameter). Alice provides her XCON-USERID via the "confUserID"
field of the userRequest and leaves out the "userInfo" one field of the userRequest and leaves out the "userInfo" one
(first-party join). In this first attempt, she doesn't insert (first-party join). In this first attempt, she doesn't insert
any password parameter. any password parameter.
2. Upon receipt the userRequest/create message, the conferencing 2. Upon receipt the userRequest/create message, the conferencing
server detects that the indicated conference is not joinable server detects that the indicated conference is not joinable
without providing the relative pass code. Then a userResponse without providing the relative pass code. Then a userResponse
message with "confPasswordRequired" response-code is returned to message with "423" response-code ("conference password
Alice to indicate that her join has been refused and that she has required")is returned to Alice to indicate that her join has been
to recast her request including the appropriate conference refused and that she has to recast her request including the
password in order to participate. appropriate conference password in order to participate.
3. After getting the pass code through out-of-band mechanisms, Alice 3. After getting the pass code through out-of-band mechanisms, Alice
provides it in the proper "password" request field of a new provides it in the proper "password" request field of a new
userRequest/create message and sends the updated request back to userRequest/create message and sends the updated request back to
the server. the server.
4. The conferencing server checks the provided password and then 4. The conferencing server checks the provided password and then
adds Alice to the protected conference. After that, a adds Alice to the protected conference. After that, a
userResponse with a "success" response-code is sent to Alice. userResponse with a "200" response-code ("success") is sent to
Alice.
1. userRequest/create message (Alice tries to enter the conference 1. userRequest/create message (Alice tries to enter the conference
without providing the password) without providing the password)
<?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-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest/> <ccmp:userRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse/create message ("passwordRequired") 2. userResponse/create message (423, "conference password required")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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">
<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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>confPasswordRequired</ccmp:response-code> <ccmp:response-code>423</ccmp:response-code>
<ccmp:userResponse/> <ccmp:response-code>conference password required</ccmp:response-code>
</ccmpResponse> <ccmp:userResponse/>
</ccmp:ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse>
3. userRequest/create message (Alice provides the password)
3. userRequest/create message (Alice provides the password) <?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-user-request-message-type">
xsi:type="ccmp:ccmp-user-request-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID>
<confObjID>xcon:8977794@example.com</confObjID> <operation>create</operation>
<operation>create</operation> <conference-password>8601</conference-password>
<conference-password>8601</conference-password> <ccmp:userRequest/>
<ccmp:userRequest/> </ccmpRequest>
</ccmpRequest> </ccmp:ccmpRequest>
</ccmp:ccmpRequest>
4. userResponse/create message ("success") 4. userResponse/create message (Alice has been added to the conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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">
<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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<version>10</version> <response-string>success</response-string>
<ccmp:userResponse/> <version>10</version>
</ccmpResponse> <ccmp:userResponse/>
</ccmp:ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse>
Figure 19: Password-protected conference join messages details Figure 19: Password-protected conference join messages details
7. Sidebars Scenarios and Examples 7. Sidebars Scenarios and Examples
While creating conferences and manipulating users and their media may While creating conferences and manipulating users and their media may
be considered enough for many scenarios, there may be cases when a be considered enough for many scenarios, there may be cases when a
more complex management is needed. more complex management is needed.
In fact, a feature typically required in conferencing systems is the In fact, a feature typically required in conferencing systems is the
skipping to change at page 48, line 43 skipping to change at page 50, line 46
| confObjID,create) | | confObjID,create) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (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(confUserID, | (parent mapping |(2) sidebarByValResponse(confUserID, | (parent mapping
| (confObjID*, create, success, | conf<->sidebar) | (confObjID*,create,200,success, | conf<->sidebar)
| version, sidebarByValInfo) | | version,sidebarByValInfo) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
|(3) sidebarByValRequest | |(3) sidebarByValRequest |
| (confUserID, confObjID*, | | (confUserID, confObjID*, |
| update,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(confUserID, | |(4) sidebarByValResponse(confUserID, |
| confObjID*, update, | | confObjID*, update, |
| success, version) | | 200, success, version) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
| |(5) userRequest | | |(5) userRequest |
| | (confUserID', | | | (confUserID', |
| | confObjID*, | | | confObjID*, |
| | update,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 |
| | (confUserID', | | | (confUserID', |
| | confObjID*,update| | | confObjID*, |
| | update, 200, |
| | success,version) | | | success,version) |
| |<----------------------| | |<----------------------|
| | | | | |
" " " " " "
" " " " " "
" " " " " "
Figure 20: Client Creation of a Sidebar Conference Figure 20: Client Creation of a Sidebar Conference
1. Upon receipt of CCMP sidebarByValRequest message to create a new 1. Upon receipt of CCMP sidebarByValRequest message to create a new
skipping to change at page 53, line 21 skipping to change at page 55, line 25
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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.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 message ("success", sidebar returned) 2. sidebarByValResponse/create message (sidebar returned)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:sidebarByValResponse> <ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@example.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@example.com xcon:8977878@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
skipping to change at page 55, line 44 skipping to change at page 58, line 4
</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-out" <xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/> uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByValInfo> </sidebarByValInfo>
</ccmp:sidebarByValRequest> </ccmp:sidebarByValRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. sidebarByValResponse/update message ("success", sidebar's 4. sidebarByValResponse/update message (sidebar's
updates accepted) updates accepted)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>2</version> <version>2</version>
<ccmp:sidebarByValResponse/> <ccmp:sidebarByValResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
5. userRequest/update message (Bob updates his media) 5. userRequest/update message (Bob updates his 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"
skipping to change at page 57, line 4 skipping to change at page 59, line 11
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 message ("success", Bob's preferences setted)
6. userResponse/update message (Bob's preferences setted)
<?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@example.com</confUserID> <confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>3</version> <version>3</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Internal Sidebar Messaging Details Figure 22: Internal Sidebar Messaging Details
7.2. External Sidebar 7.2. External Sidebar
Figure 23 provides an example of a different approach towards Figure 23 provides an example of a different approach towards
skipping to change at page 58, line 18 skipping to change at page 61, line 18
| confObjID, create) | | confObjID, create) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (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(confUserID, | (parent mapping |(2) sidebarByRefResponse(confUserID, | (parent mapping
| confObjID*, create, success, | conf<->sidebar) | confObjID*,create,200,success, | conf<->sidebar)
| version, sidebarByRefInfo) | | version,sidebarByRefInfo) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
|(3) sidebarByRefRequest(confUserID, | |(3) sidebarByRefRequest(confUserID, |
| confObjID*,update,sidebarByRefInfo) | | confObjID*,update,sidebarByRefInfo) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (b) Create +---| | | (b) Create +---|
| | new user for | | | | new user for | |
| | Fred | | | | Fred | |
| | +-->| | | +-->|
skipping to change at page 58, line 41 skipping to change at page 61, line 41
| | (c) Update +---| | | (c) Update +---|
| | sidebar-by-ref | | | | sidebar-by-ref | |
| | (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(confUserID, | |(4) sidebarByRefResponse(confUserID, |
| confObjID*, update, | | confObjID*, update, |
| success, version) | | 200, success, version) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
| | Notify (Fred | | | Notify (Fred |
| | added to | | | added to |
| | sidebar users) | | | sidebar users) |
| |<----------------------| | |<----------------------|
| | | | | |
" " " " " "
" " " " " "
" " " " " "
skipping to change at page 60, line 21 skipping to change at page 63, line 21
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:sidebarByRefRequest/> <ccmp:sidebarByRefRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByRefResponse/create message ("success", created 2. sidebarByRefResponse/create message (created
sidebar returned) sidebar returned)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:sidebarByRefResponse> <ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@example.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@example.com xcon:8977878@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
skipping to change at page 63, line 4 skipping to change at page 66, line 5
</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@example.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:Bob@example.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 message ("success", sidebar updated) 4. sidebarByRefResponse/update message (sidebar updated)
<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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID> <confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>2</version> <version>2</version>
<ccmp:sidebarByRefResponse/> <ccmp:sidebarByRefResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 24: External Sidebar Messaging Details Figure 24: External Sidebar Messaging Details
7.3. Private Messages 7.3. Private Messages
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
skipping to change at page 65, line 39 skipping to change at page 68, line 43
uri="xcon-userid:Alice@example.com"/> uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out" <xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/> uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</info:users> </info:users>
</sidebarByValInfo> </sidebarByValInfo>
</ccmp:sidebarByValRequest> </ccmp:sidebarByValRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByValResponse/create message ("success", sidebar returned) 2. sidebarByValResponse/create message (sidebar returned)
<?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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID> <confObjID>xcon:8974545@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>1</version> <version>1</version>
<ccmp:sidebarByValResponse> <ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@example.com"> <sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
private textual sidebar alice - bob private textual sidebar alice - bob
</info:display-text> </info:display-text>
<xcon:sidebar-parent> <xcon:sidebar-parent>
xcon:8977878@example.com xcon:8977878@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
skipping to change at page 69, line 18 skipping to change at page 72, line 19
| confObjID, create) | | confObjID, create) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (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(confUserID, | (parent mapping |(2) sidebarByRefResponse(confUserID, | (parent mapping
| confObjID*, create, success, | conf<->sidebar) | confObjID*,create,200,success, | conf<->sidebar)
| version, sidebarByRefInfo) | | version,sidebarByRefInfo) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
|(3) sidebarByRefRequest(confUserID, | |(3) sidebarByRefRequest(confUserID, |
| confObjID*,update,sidebarByRefInfo) | | confObjID*,update,sidebarByRefInfo) |
|--------------------------------------------->| |--------------------------------------------->|
| | | | | |
| | (b) Update +---| | | (b) Update +---|
| | sidebar-by-val | | | | sidebar-by-val | |
| | (media, users | | | | (media, users | |
| | policy, etc.) +-->| | | policy, etc.) +-->|
| | | Sidebar is modified: | | | Sidebar is modified:
| | | unilateral sidebar | | | unilateral sidebar
| | | audio, Carol excluded | | | audio, Carol excluded
| | | from the sidebar | | | from the sidebar
|(4) sidebarByRefResponse(confUserID, | |(4) sidebarByRefResponse(confUserID, |
| confObjID*, update, | | confObjID*, update, |
| success, version) | | 200, success, version) |
|<---------------------------------------------| |<---------------------------------------------|
| | | | | |
| | Notify (Bob | | | Notify (Bob |
| | he's been added to | | | he's been added to |
| | sidebar users) | | | sidebar users) |
| |<----------------------| | |<----------------------|
| | | | | |
" " " " " "
" " " " " "
" " " " " "
skipping to change at page 71, line 26 skipping to change at page 74, line 29
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID> <confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:sidebarsByRefRequest/> <ccmp:sidebarsByRefRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. sidebarByRefResponse/create message ("success") 2. sidebarByRefResponse/create message (sidebar created)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID> <confObjID>xcon:8971313@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:response-string>success</ccmp:response-string>
<version>1</version> <version>1</version>
<ccmp:sidebarByRefResponse> <ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@example.com"> <sidebarByRefInfo entity="xcon:8971313@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:8971313@example.com xcon:8971313@example.com
</xcon:sidebar-parent> </xcon:sidebar-parent>
skipping to change at page 73, line 50 skipping to change at page 77, line 5
<info:status>recvonly</info:status> <info:status>recvonly</info:status>
</info:media> </info:media>
</info:endpoint> </info:endpoint>
</user> </user>
</info:users> </info:users>
</sidebarByRefInfo> </sidebarByRefInfo>
</ccmp:sidebarByRefRequest> </ccmp:sidebarByRefRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
4. sidebarByRefRequest/update message ("success") 4. sidebarByRefRequest/update message (updates accepted)
<?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@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID> <confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>2</version> <version>2</version>
<ccmp:sidebarByRefResponse/> <ccmp:sidebarByRefResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 28: Coaching and Observing Messaging details Figure 28: Coaching and Observing Messaging details
8. Removing Participants and Deleting Conferences 8. Removing Participants and Deleting Conferences
The following scenarios detail the basic operations associated with The following scenarios detail the basic operations associated with
skipping to change at page 75, line 26 skipping to change at page 78, line 26
| |<----------------------| | |<----------------------|
| | | | | |
| | (b)Deletes+---| | | (b)Deletes+---|
| | | Bob | | | | | Bob | |
| | | as a | | | | | as a | |
| | | user +-->| | | | user +-->|
| | | in | | | | in |
| | | confObj | | | | confObj |
| | | | | | | |
|(2) userResponse(confUserID,confObjID, | |(2) userResponse(confUserID,confObjID, |
| delete,success,version) | | delete,200,success,version) |
|<--------------------------------------| |<--------------------------------------|
| | | | | | | |
| | | | | | | |
| | | (c) Notify| | | | (c) Notify|
| | | ("Bob just| | | | ("Bob just|
| | | left") | | | | left") |
| | |<----------| | | |<----------|
| | | | | | | |
' ' ' ' ' ' ' '
' ' ' ' ' ' ' '
skipping to change at page 76, line 27 skipping to change at page 79, line 27
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/> <userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse/delete message ("success") 2. userResponse/delete message (Bob has been deleted)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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">
<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@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<version>17</version> <version>17</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 30: Removing a Participant Messaging Details Figure 30: Removing a Participant Messaging Details
8.2. Deleting a Conference 8.2. Deleting a Conference
In this section, an example of a successful conference deletion is In this section, an example of a successful conference deletion is
skipping to change at page 77, line 26 skipping to change at page 80, line 26
| Conf | | | Conf | |
| Object | | | Object | |
| +-->| | +-->|
| |--+ (b) MS | |--+ (b) MS
| | | removes related | | | removes related
| | | mixer instances and | | | mixer instances and
| |<-+ their participants | |<-+ their participants
| | (SIP signaling as well) | | (SIP signaling as well)
| | | |
|(2)confResponse(confUserID, | |(2)confResponse(confUserID, |
| confObjID,delete, | | confObjID,delete,200, |
| success) | | success) |
| | | |
|<------------------------------| |<------------------------------|
| | | |
Figure 31: Deleting a conference Figure 31: Deleting a conference
1. The conferencing system client "Alice" sends a confRequest 1. The conferencing system client "Alice" sends a confRequest
message with a "delete" operation to be performed on the message with a "delete" operation to be performed on the
conference identified by the XCON-URI carried in the "confObjID" conference identified by the XCON-URI carried in the "confObjID"
parameter. The conference server, on the basis of the parameter. The conference server, on the basis of the
"confUserID" included in the receipt request, ensures that Alice "confUserID" included in the receipt request, ensures that Alice
has the appropriate authority to fulfill the operation. has the appropriate authority to fulfill the operation.
2. After validating Alice's rights, the conferencing server 2. After validating Alice's rights, the conferencing server
instigates the process to delete the conference object, instigates the process to delete the conference object,
disconnetting participants and removing associated resources such disconnetting participants and removing associated resources such
as mixer instances. Then, the conference server returns a as mixer instances. Then, the conference server returns a
confResponse message to Alice with "success" as "response-code" confResponse message to Alice with "200" as "response-code" and
and the deleted conference XCON-URI in the "confObjID" field. the deleted conference XCON-URI in the "confObjID" field.
1. confRequest/delete message (Alice deletes a conference) 1. confRequest/delete message (Alice deletes a conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
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-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<ccmp:confRequest/> <ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse/delete message ("success") 2. confResponse/delete message (200, "success")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
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">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse 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">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation> <operation>delete</operation>
<response-code>success</response-code> <response-code>200</response-code>
<response-string>success</response-string>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 32: Deleting a Conference Messaging Details Figure 32: Deleting a Conference Messaging Details
9. IANA Considerations 9. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
skipping to change at page 81, line 24 skipping to change at page 84, line 26
[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-06 (work in progress), February 2010. draft-ietf-xcon-ccmp-08 (work in progress), June 2010.
13.2. Informative References 13.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 82, line 4 skipping to change at page 85, line 7
[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.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 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-18 Conferencing (XCON)", draft-ietf-xcon-common-data-model-19
(work in progress), February 2010. (work in progress), May 2010.
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-call-flows]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
"Media Control Channel Framework (CFW) Call Flow "Media Control Channel Framework (CFW) Call Flow
Examples", draft-ietf-mediactrl-call-flows-03 (work in Examples", draft-ietf-mediactrl-call-flows-04 (work in
progress), February 2010. progress), May 2010.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media [RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009. Server Control", RFC 5567, June 2009.
[I-D.ietf-mediactrl-mixer-control-package] [I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework", Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-11 (work in draft-ietf-mediactrl-mixer-control-package-11 (work in
progress), February 2010. progress), February 2010.
 End of changes. 120 change blocks. 
345 lines changed or deleted 380 lines changed or added

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