idnits 2.17.1
draft-ietf-xcon-examples-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (April 14, 2010) is 5119 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 3605, but no explicit
reference was found in the text
== Unused Reference: 'I-D.boulton-xcon-session-chat' is defined on line
3669, but no explicit reference was found in the text
== Outdated reference: A later version (-15) exists of
draft-ietf-xcon-ccmp-06
-- Obsolete informational reference (is this intentional?): RFC 4582
(Obsoleted by RFC 8855)
== Outdated reference: A later version (-32) exists of
draft-ietf-xcon-common-data-model-18
== Outdated reference: A later version (-13) exists of
draft-ietf-mediactrl-call-flows-03
== Outdated reference: A later version (-14) exists of
draft-ietf-mediactrl-mixer-control-package-11
== Outdated reference: A later version (-08) exists of
draft-boulton-xcon-session-chat-04
Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XCON Working Group M. Barnes
3 Internet-Draft Nortel
4 Intended status: Informational L. Miniero
5 Expires: October 16, 2010 Meetecho
6 R. Presta
7 S P. Romano
8 University of Napoli
9 April 14, 2010
11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
12 draft-ietf-xcon-examples-04
14 Abstract
16 This document provides detailed call flows for the scenarios
17 documented in the Centralized Conferencing (XCON) Framework and the
18 XCON Scenarios. The call flows document the use of the interface
19 between a conference control client and a conference control server
20 using the Centralized Conferencing Manipulation Protocol (CCMP). The
21 objective is to provide a base reference for both protocol
22 researchers and developers.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on October 16, 2010.
41 Copyright Notice
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4
62 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5
63 4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6
64 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
65 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 13
66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 13
67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 18
68 5.3. Conference Creation using User-Provided Conference
69 Information . . . . . . . . . . . . . . . . . . . . . . . 25
70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 30
71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 33
72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 34
73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 37
74 6.3. Conference Announcements and Recordings . . . . . . . . . 41
75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45
76 6.5. Entering a password-protected conference . . . . . . . . . 45
77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 47
78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 48
79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 57
80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63
81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67
82 8. Removing Participants and Deleting Conferences . . . . . . . . 74
83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74
84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77
85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
87 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79
88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81
89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
91 13.2. Informative References . . . . . . . . . . . . . . . . . . 81
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
94 1. Introduction
96 This document provides detailed call flows for the scenarios
97 documented in the Framework for Centralized Conferencing (XCON
98 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
99 scenarios describe a broad range of use cases taking advantage of the
100 advanced conferencing capabilities provided by a system realization
101 of the XCON framework. The call flows document the use of the
102 interface between a conference control client and a conference
103 control server using the Centralized Conferencing Manipulation
104 Protocol (CCMP)[I-D.ietf-xcon-ccmp].
106 Due to the broad range of functionality provided by the XCON
107 Framework and the flexibility of the CCMP messaging, these call flows
108 should not be considered inclusive of all the functionality that can
109 provided by the XCON Framework and protocol implementations. These
110 flows represent a sample to provide an overview of the feature rich
111 capabilities of the XCON framework and CCMP messaging for protocol
112 developers, software developers and researchers.
114 2. Terminology
116 This document uses the same terminology as found in the Media Control
117 Architectural Framework [RFC5567] and Media Control Channel Framework
118 Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the
119 following terms and abbreviations used in the call flows. Also, note
120 that the term "call flows" is used in a very generic sense in this
121 document since the media is not limited to voice. The calls
122 supported by the XCON framework and CCMP can consist of media such as
123 text, voice and video, including multiple media types in a single
124 active conference.
126 Conference and Media Control Client (CMCC): as defined in the XCON
127 Framework. In the flows in this document, the CMCC is logically
128 equivalent to the use of UAC as the client notation in the media
129 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC
130 differs from a generic Media Client in being an XCON-aware entity,
131 thus being able to also issue CCMP requests.
133 Conferencing Server (ConfS): In this document, the "Conferencing
134 Server" term is used interchangeably with the term Application
135 Server (AS) as used in the Media Control Architectural Framework
136 [RFC5567]. A Conferencing Server is intended to be able to act as
137 a Conference Control Server, as defined in the XCON framework,
138 i.e. it is able to handle CCMP requests and issue CCMP responses.
140 Media Server (MS): as defined in the Media Control Architectural
141 Framework [RFC5567].
143 3. Overview
145 This document provides a sampling of detailed call flows that can be
146 implemented based on a system realization of the XCON framework
147 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
148 intended to be a simple guide for the use of the Conference Control
149 Protocol between the Conferencing Server and the Conference Control
150 Client. The objective is to provide an informational base reference
151 for protocol developers, software developers and researchers.
153 This document focuses on the interaction between the Conference (and
154 Media) Control Client and the Conferencing System, specifically the
155 Conferencing Server. The scenarios are based on those described in
156 the XCON framework, many of which are based on the advanced
157 conferencing capabilities described in the XCON scenarios.
158 Additional scenarios have been added to provide examples of other
159 real life scenarios that are anticipated to be supported by the
160 framework. With the exception of an initial example with media
161 control messaging, the examples do not include the details for the
162 media control [I-D.ietf-mediactrl-mixer-control-package], call
163 signaling or binary floor control [RFC4582] protocols. This document
164 references the scenarios in the Media Control call flows
165 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
166 [RFC4579] and binary floor control protocol documents.
168 The rest of this document is organized as follows. Section 4
169 presents an overview on CCMP, together with some implementation-
170 related details and related matters like HTTP transport and
171 notifications. Section 5 presents the reader with examples showing
172 the different approaches CCMP provides to create a new conference.
173 Section 6 more generally addresses the different user-related
174 manipulations that can be achieved by means of CCMP, by presenting a
175 number of interesting scenarios. Section 7 addresses the several
176 scenarios that may involve the use of sidebars. Section 8 shows how
177 CCMP can be used to remove conferences and users from the system.
178 Finally, IANA considerations are discussed in Section 9 while
179 Section 10 provides a few details for what concerns the Security
180 Considerations when it comes to implementing CCMP.
182 4. Working with CCMP
184 This section aims at being a brief introduction to how the
185 Centralized Conferencing Manipulation Protocol (CCMP)
187 [I-D.ietf-xcon-ccmp] works and how it can be transported across a
188 network. Some words will be spent to describe a typical CCMP
189 interaction, by focusing on relevant aspects of the client-server
190 communication. Please notice that this section is by no means to be
191 considered as a replacement for the CCMP document, which remains a
192 mandatory read before approaching the following sections. It is just
193 conceived to help the reader take the first steps toward the actual
194 protocol interactions.
196 First of all, some lines will be devoted to the protocol by itself in
197 Section 4.1, together with some recommendations from an
198 implementation point of view. In Section 4.2, instead, an effective
199 CCMP interaction will be presented by exploiting HTTP as a transport.
200 Finally, a few words will be spent on notifications in Section 4.3.
202 Once done with these preliminary steps, some actual flows will be
203 presented and described in detail in the sections to follow.
205 4.1. CCMP and the Data Model
207 CCMP is an XML-based protocol. It has been designed as a request/
208 response protocol. Besides, it is completely stateless, which means
209 implementations can safely handle transactions independently from
210 each other.
212 The protocol allows for the manipulation of conference objects and
213 related users. By manipulation it is implied, as the document
214 specifies, that a Conferencing Client (briefly CMCC in all the
215 following sections) can create, update and remove basically
216 everything that is related to the objects handled by a conferencing
217 system. This is reflected in the allowed operations (retrieve,
218 create, update, delete) and the specified request types (ranging from
219 the manipulation of blueprints and conferences to users and
220 sidebars). For instance, CCMP provides ways to:
222 o retrieve the list of registered and/or active conferences in the
223 system;
225 o create new conferences by exploiting to several different
226 approaches;
228 o add/remove users to/from a conference;
230 o update a conference with respect to all of its aspects;
232 and so on.
234 It is worthwile to note that, while CCMP acts as the means to
235 manipulate conference objects, its specification does not define
236 these objects as well. In fact, a separate document has been written
237 to specify how a conference object and all its components have to be
238 constructed: the Conference Information Data Model for Centralized
239 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP,
240 according to the request type and the related operation, carries
241 pieces of conference objects (or any object as a whole) according to
242 the aforementioned specification. This means that any implementation
243 aiming at being compliant with CCMP has to make sure that the
244 transported objects are completely compliant with the Data Model
245 specification and coherent with the constraints defined therein. To
246 make this clearer, there are elements that are mandatory in a
247 conference object: issuing a syntactically correct CCMP request that
248 carries a wrong conference object is doomed to result in a failure.
249 For this reason, it is suggested that the interested implementors
250 take special care in carefully checking the Data Model handlers as
251 well in order to avoid potential mistakes.
253 Of course, there are cases where a mandatory element in the Data
254 Model cannot be assigned in a conference object by a CCMP user. For
255 instance, a CMCC may be requesting the direct creation of a new
256 conference: in this case, a conference object assumes an 'entity'
257 element uniquely identifying the conference to be in place. Anyway,
258 the CMCC has no way to a priori know what the entity will be like,
259 considering it will only be generated by the ConfS after the request.
260 For scenarios like this one, the CCMP specification envisages the use
261 of a dedicated placeholder wildcard to make the conference object
262 compliant with the Data Model: the wildcard would then be replaced by
263 the ConfS with the right value.
265 4.2. Using HTTP as a transport
267 CCMP requests and responses can be transported from a client to a
268 server and viceversa through several ways, being the protocol
269 specification agnostic with respect to the transport in use. In
270 [I-D.ietf-xcon-ccmp], focus is given on HTTP as a solution for this
271 transport matter, and a whole chapter is devoted in the document to
272 how HTTP can be used for it. The following lines will provide a
273 brief explanation, from a more practical point of view, of how HTTP
274 might be exploited to carry CCMP messages. In this document,
275 however, all the call flows herein presented will just show the CCMP
276 interactions, without talking about how the messages could have gone
277 across the network.
279 In case HTTP is used as a transport, the specification is very clear
280 with respect to how the interaction has to occur. Specifically, a
281 CMCC is assumed to send his request as part of an HTTP POST message,
282 and the ConfS would reply by means of an HTTP 200 message. In both
283 cases, the HTTP messages would have the CCMP messages as payload,
284 which would be reflected in the Content-Type message. Figure 1
285 presents a ladder diagram of such interaction, which is followed by a
286 dump of the exchanged HTTP messages for further analysis:
288 CMCC ConfS
289 | |
290 | 1. HTTP POST (CCMP request) |
291 |--------------------------------------------->|
292 | |
293 | |--+ Parse request,
294 | | | update object
295 | |<-+ and reply
296 | |
297 | 2. 200 OK (CCMP response) |
298 |<---------------------------------------------|
299 | |
300 |--+ Parse response and |
301 | | update local copy |
302 |<-+ of conference object |
303 | |
304 . .
305 . .
307 Figure 1: CCMP on HTTP
309 As it can be seen in the protocol dump in the following lines, the
310 CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve'
311 operation) towards the Conferencing Server (ConfS). The request has
312 been carried as payload of an HTTP POST (message 1.) towards a
313 previously known location. The mandatory 'Host' header has been
314 specified, and the 'Content-Type' header has been correctly set as
315 well (application/ccmp+xml).
317 The ConfS, in turn, has handled the request and replied accordingly.
318 The response (a blueprintResponse with a 'success' response code) has
319 been carried as payload of an HTTP 200 OK (message 2.). As before,
320 the 'Content-Type' header has been correctly set (application/
321 ccmp+xml).
323 1. CMCC -> ConfS (HTTP POST, CCMP request)
324 ------------------------------------------
325 POST /Xcon/Ccmp HTTP/1.1
326 Content-Length: 657
327 Content-Type: application/ccmp+xml
328 Host: example.com:8080
329 Connection: Keep-Alive
330 User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
332
333
337
339 xcon-userid:Alice@example.com
340 xcon:AudioRoom@example.com
341 retrieve
342
343
344
346 2. CMCC <- ConfS (200 to POST, CCMP response)
347 ---------------------------------------------
348 HTTP/1.1 200 OK
349 X-Powered-By: Servlet/2.5
350 Server: Sun GlassFish Communications Server 1.5
351 Content-Type: application/ccmp+xml;charset=ISO-8859-1
352 Content-Length: 1652
353 Date: Thu, 04 Feb 2010 14:47:56 GMT
355
356
360
362 xcon-userid:Alice@example.com
363 xcon:AudioRoom@example.com
364 retrieve
365 success
366
367
368
369 AudioRoom
370 2
371
372
373 audio
374
375
376
377
378 allow
379
380
381 confirm
382
383
384
385
386
387
388
389
390
392 Just for the sake of completeness, a few words will be spent about
393 the occurred CCMP interaction as well. In fact, despite the
394 simplicity of the request, this flow already provides some relevant
395 information on how CCMP messages are built. Specifically, both the
396 request and the response share a subset of the message:
398 o confUserID: this element, provided by the CMCC, refers to the
399 requester by means of his XCON-USERID; except in a few scenarios
400 (presented in the following sections) this element must always
401 contain a valid value;
403 o confObjID: this element refers to the target conference object,
404 according to the request in place;
406 o operation: this element specifies the operation the CMCC wants to
407 perform according to the specific request type.
409 Besides those elements, the CMCC (in this case Alice, since the
410 'confUserID' has been set to 'xcon-userid:Alice@example.com') has
411 also provided an additional element, 'blueprintRequest'. The name of
412 that element varies according to the request type the CMCC is
413 interested into. In this specific scenario, the CMCC was interested
414 in acquiring details concerning a specific blueprint (identified by
415 its XCON-URI 'xcon:AudioRoom@example.com', as reflected in the
416 provided 'confObjID' target element), and so the request consisted in
417 an empty 'blueprintRequest' element. As it will be clearer in the
418 following sections, different request types may require different
419 elements, and as a consequence different content.
421 Considering the request was a 'blueprintRequest', the ConfS has
422 replied with a 'blueprintResponse' element. This element includes a
423 complete dump of the conference object (compliant with the Data
424 Model) describing the requested blueprint, together with an element
425 addressing the result of the client's request (response-
426 code=success).
428 This section won't delve in additional details for what concerns this
429 interaction. It is just worth noticing that this was the example of
430 the simplest CCMP communication that could take place between a CMCC
431 and a ConfS, a blueprintRequest: this scenario will be described in
432 more detail in Section 5.2.
434 4.3. Conference Notifications
436 [RFC5239] presents several different possible protocol interactions
437 between a conferencing server and a conferencing client. One of
438 those interactions is generically called "Notification Protocol",
439 implementing a notification service for all clients interested in
440 being informed by the server whenever something relevant happens in a
441 conference. While at first glance it may appear that such a
442 functionality should belong to a conference control protocol, such
443 feature has been specifically marked as out of scope in CCMP. As a
444 consequence, CCMP has been conceived as a request/answer protocol,
445 and in fact no ways to provide notifications to clients have been
446 introduced in the specification.
448 Nevertheless, the CCMP document by itself has a brief section
449 presenting some typical ways notifications might be managed. This
450 example document does not foster one rather than another, and all the
451 flows will always generically present a notification being involved,
452 when it seems appropriate, but not providing any info on how the
453 notification itself has been sent to the interested clients. Anyway,
454 this section will briefly introduce some of the most typical ways a
455 notification service could be implemented and integrated with the
456 functionality provided by CCMP. It is by no means to be intended as
457 a complete list of solutions: the aim of this section is to provide
458 an overview of some of the possible solutions, together with
459 indications on how they may be integrated into a CCMP-based platform.
461 The first approach that comes to mind is of course the XCON Event
462 Package [I-D.ietf-xcon-event-package]. This specification extends
463 the SIP Event Package for Conference State [RFC4575] and allows for
464 the notification of conference notifications by means of the NOTIFY/
465 SUBSCRIBE mechanisms of SIP. Specifically, any SIP client who
466 subscribed for notifications related to a specific conference would
467 receive notifications via SIP describing all the changes to the
468 document. An example ladder diagram is presented in Figure 2: in
469 this figure, we assume a CMCC has updated a conference object, and
470 the update is notified to a previously subscribed SIP client.
472 CMCC ConfS UAC
473 | | |
474 | | 1. SIP SUBSCRIBE |
475 | |<--------------------------|
476 | Handle +--| |
477 | new | | |
478 | subscription +->| 2. SIP 200 OK |
479 | |-------------------------->|
480 | | |
481 . . .
482 . . .
483 | | |
484 | 3. CCMP (add user) | |
485 |---------------------->| |
486 | |--+ Add user |
487 | | | to conf. |
488 | |<-+ object |
489 | 4. CCMP (success) | |
490 |<----------------------| |
491 | | 5. SIP NOTIFY (changes) |
492 | |-------------------------->|
493 | | 6. SIP 200 OK |
494 | |<--------------------------|
495 | | |
496 . . .
497 . . .
499 Figure 2: XCON Event Package: SIP notifications
501 Considering CCMP is going to be probably most often deployed on HTTP,
502 another way to achieve notifications might be by exploiting some sort
503 of HTTP callbacks, as suggested in the CCMP specification itself.
504 This would allow to overcome the previous limitation, since both the
505 CMCC and the ConfS would already have an HTTP stack to make use of.
506 Using this approach, an interested web client might provide the
507 Conferencing System with an URL to contact whenever updates are
508 available: the update could be part of the notification message
509 itself, or it could be only implicitly referenced by the
510 notification. At the same time, alternative notification means could
511 be exploited, e.g. by taking advantage of functionality provided by
512 other protocols such as XMPP. Figure 3 shows an example of different
513 subscriptions which accordingly trigger notifications after the same
514 relevant event happens.
516 CMCC ConfS Sub1 Sub2
517 | | | |
518 | | 1. Register callback | |
519 | |<--------------------------| |
520 | Handle +--| | |
521 | new HTTP | | | |
522 | subscription +->| 2. Acknlowledge | |
523 | |-------------------------->| |
524 | | | |
525 | | 3. XMPP subscription |
526 | |<---------------------------------------|
527 | Handle +--| | |
528 | new XMPP | | | |
529 | subscription +->| 4. XMPP confirm subscription |
530 | |--------------------------------------->|
531 | | | |
532 . . . .
533 . . . .
534 | | | |
535 | 5. CCMP (add user) | | |
536 |-------------------->| | |
537 | |--+ Add user | |
538 | | | to conf. | |
539 | |<-+ object | |
540 | 6. CCMP (success) | | |
541 |<--------------------| | |
542 | | 7. HTTP POST (changes) | |
543 | |-------------------------->| |
544 | | 8. HTTP 200 OK | |
545 | |<--------------------------| |
546 | | | |
547 | | 9. XMPP notification | |
548 | |--------------------------------------->|
549 | | | |
550 . . . .
551 . . . .
553 Figure 3: Alternative means for notifications
555 That said, there are actually many other ways to achieve
556 notifications in a conferencing system. A conferencing system may
557 rely on several other solutions than the ones presented as periodic
558 checks of a well known URL by interested clients, long polls, BOSH-
559 based communications, Atom/RSS feeds and the like.
561 5. Conference Creation
563 This section starts the sequence of call flows of typical XCON-
564 related scenarios provided in this document. Specifically, it
565 provides details associated with the various ways in which a
566 conference can be created using CCMP and the XCON framework
567 constructs. As previously mentioned the details of the media
568 control, call signaling and floor control protocols, where
569 applicable, are annotated in the flows without showing all the
570 details. This also applies to CCMP, whose flows are related to the
571 protocol alone, hiding any detail concerning the transport that may
572 have been used (e.g. HTTP). However, for clarification purposes,
573 the first example Section 5.1 provides the details of the media
574 control messaging along with an example of the standard annotation
575 used throughout the remainder of this document. In subsequent flows,
576 only this annotation (identified by lower case letters) is included
577 and the reader is encouraged to refer to the call flows in the
578 relevant documents for details about the other protocols. The
579 annotations for the call signaling are on the left side of the
580 conferencing server vertical bar and those for the media control
581 messaging are on the right side.
583 5.1. Basic Conference Creation
585 The simplest manner in which a conference can be created is
586 accomplished by the client sending a "confRequest" message with the
587 "create" operation as the only parameter to the conference server,
588 together with the "confUserID" associated with the requesting client
589 itself. This results in the creation of a default conference, with
590 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
591 in the form of the "confUserID" parameter (the same already present
592 in the request) and the data for the conference object in the
593 "confInfo" parameter all returned in the "confResponse" message.
594 According to the implementation of the framework, this example may
595 also add the user that invoked the conference upon creation to the
596 conference object (e.g., "method" attribute in the "target" element
597 of "allowed-users-list" may be set to "dial out" for this client
598 based on the particular conferencing systems default). This is
599 exactly the case depicted in the figure, which is presented to enrich
600 the scenario.
602 The specific data for the conference object are returned in the
603 "confResponse" message in the "confInfo" parameter. This allows the
604 client (with the appropriate authorization) to manipulate these data
605 and add additional participants to the conference, as well as change
606 the data during the conference. In addition, the client may
607 distribute the conferencing information to other participants
608 allowing them to join, the details of which are provided in
609 additional flows. Please notice that, according to the CCMP
610 specification, the return of the new conference data in the
611 "confInfo" parameter is not mandatory: if the "confInfo" parameter of
612 the successful confResponse/create is void, a following confRequest/
613 retrieve of the returned "confObjID" can be triggered to provide the
614 requesting client with the detailed conference description.
616 Clients that are not XCON-aware can join the conference using a
617 specific signaling interface such as SIP [RFC3261] or other supported
618 signaling protocols (being XCON agnostic with respect to them), using
619 the signaling interface to the conference focus as described in
620 [RFC4579]. However, these details are not shown in the message
621 flows. The message flows in this document identify the point in the
622 message flows at which this signaling occurs via the lower case
623 letter items (i.e., (a)...(x)) along with the appropriate text for
624 the processing done by the conferencing server.
626 As anticipated at the beginning of this section, this example also
627 shows how the conferencing system may make use of other standard
628 components to make available its functionality. An example of that
629 is the MEDIACTRL specification, which allows the conferencing system
630 to configure conference mixes, IVR dialogs and all sort of media-
631 related interactions an application like this may need. So, just to
632 provide the reader with some insight on these interactions, the
633 conferencing system also configures and starts a mixer via MEDIACTRL
634 as soon as the conference is created (transactions A1 and A2), and
635 attaches clients to it when necessary (e.g. when CMCC1 joins the
636 conference by means of SIP signaling, its media channels are attached
637 to the Media Server using MEDIACTRL in B1/B2).
639 CMCC1 CMCC2 CMCCx ConfS MS
640 | | | | |
641 |(1)confRequest(confUserID, create) | |
642 |-------------------------------------->| |
643 | | (a)Create +---| |
644 | | |Conf | | |
645 | | |Object | | |
646 | | |& IDs +-->| |
647 | | | | A1. CONTROL |
648 | | | |+++++++++++>>|
649 | | | |(create conf)|--+ (b)
650 | | | | | | create
651 | | | | | | conf and
652 | | | | A2. 200 OK |<-+ its ID
653 | | | |<<+++++++++++|
654 | | | |(confid=Y) |
655 |(2)confResponse(confUserID,confObjID, | |
656 | create, success, | |
657 | version, confInfo) | |
658 |<--------------------------------------| |
659 | | | | |
660 | | (c) Focus +---| |
661 | | sets up | | |
662 | | signaling | | |
663 | | to CMCC1 +-->| |
664 | | | | |
665 | | | | B1. CONTROL |
666 | | | |+++++++++++>>|
667 | | | | (join CMCC1 |
668 | | | | <->confY) |
669 | | | | |
670 | | | | |--+(d) join
671 | | | | | | CMCC1 &
672 | | | | B2.200 OK |<-+ conf Y
673 | | | |<<+++++++++++|
674 | | | | |
675 |<<#################################################>>|
676 | Now the CMCC1 is mixed in the conference |
677 |<<#################################################>>|
678 | | | | |
679 |******CMCC1 may then manipulate conference data *****|
680 |****** and add addt'l users, etc. | *****|
681 ' ' ' ' '
682 ' ' ' ' '
683 ' ' ' ' '
684 Figure 4: Create Basic Conference - Complete flow
686 "Alice" "Bob"
687 CMCC1 CMCC2 CMCCx ConfS
688 | | | |
689 |(1)confRequest(confUserID, create) |
690 |-------------------------------------->|
691 | | | |
692 | | (a)Create +---|
693 | | |Conf | |
694 | | |Object | |
695 | | |& IDs +-->|
696 | | | |--+ (b) MS
697 | | | | | creates
698 | | | | | conf and
699 | | | |<-+ its ID
700 | | | | (confid=Y)
701 |(2)confResponse(confUserID, confObjID |
702 | create, success, |
703 | version, confInfo) |
704 | | | |
705 |<--------------------------------------|
706 | | | |
707 | | | |
708 | | (c) Focus +---|
709 | | sets up | |
710 | | signaling | |
711 | | to CMCC1 +-->|
712 | | | |
713 | | | |--+(d) MS joins
714 | | | | | CMCC1 &
715 | | | |<-+ conf Y
716 |<<###################################>>|
717 | CMCC1 is mixed in the conference |
718 |<<###################################>>|
719 | | | |
720 |**CMCC1 then manipulates conference****|
721 |** data and add addt'l users, etc. ***|
722 ' ' ' '
723 ' ' ' '
724 ' ' ' '
725 -
727 Figure 5: Create Basic Conference - Annotated Flow
729 1. confRequest/create message (Alice creates a default conference)
731
732
736
739 xcon-userid:Alice@example.com
740 create
741
742
744 2. confResponse/create message ("success", created conference
745 object returned)
747
748
752
755 xcon-userid:Alice@example.com
756 xcon:8977794@example.com
757 create
758 success
759 1
760
761
762
763
764 Default conference initiated by Alice
765
766
767
768
769 xcon:8977794@example.com
770
771
772 Conference XCON-URI
773
774
775
776 10
777
778
779 audio
780
781
782
783 false
784
785
786
787 allow
788
789
791
792
793
794
795
796
798 Figure 6: Create Basic Conference (Annotated) Detailed Messaging
800 5.2. Conference Creation using Blueprints
802 The previous example showed the creation of a new conference using
803 default values. This means the client provided no information about
804 how she wanted the conference to be like. Anyway, the XCON framework
805 (and CCMP as a consequence) allows for the exploitation of templates.
806 These templates are called "conference blueprints", and are basically
807 conference objects with pre-defined settings except for the actual
808 identifiers. This means that a client might get one of these
809 blueprints, choose the one that more fits his needs, and use the
810 chosen blueprint to create a new conference.
812 This section addresses exactly this scenario, and Figure 7 provides
813 an example of one client, "Alice", discovering the conference
814 blueprints available for a particular conferencing system and
815 creating a conference based on the desired blueprint. In particular,
816 Alice is interested in those blueprints suitable to represent a
817 "video-conference", i.e. a conference in which both audio and video
818 are available, so she exploits the filter mechanism envisioned by
819 CCMP to make a selective blueprints retrieve request. This results
820 in three distinct CCMP transactions.
822 CMCC "Alice" ConfS
823 | |
824 | (1) blueprintsRequest |
825 | (confUserID,xpathFilter) |
826 |------------------------------>|
827 | |
828 | (2) blueprintsResponse |
829 | (confUserID, success, |
830 | blueprintsInfo) |
831 |<------------------------------|
832 | |
833 |--+ |
834 | | choose preferred |
835 | | blueprint from the |
836 | | list (blueprintName) |
837 |<-+ |
838 | |
839 | (3) blueprintRequest |
840 | (confUserID,confObjID, |
841 | retrieve) |
842 |------------------------------>|
843 | |
844 | 4) blueprintResponse |
845 | (confUserID,confObjID,|
846 | retrieve,confInfo) |
847 |<------------------------------|
848 | |
849 | (5) confRequest(confUserID, |
850 | confObjID,create) |
851 |------------------------------>|
852 | |
853 | (a)Create +---|
854 | Conf | |
855 | Object | |
856 | & IDs +-->|
857 | |--+ (b) MS
858 | | | creates
859 | | | conf and
860 | |<-+ its ID
861 | | (confid=Y)
862 |(6) confResponse |
863 | (confUserID, confObjID*, |
864 | create, success) |
865 |<------------------------------|
866 | |
867 | |
868 | |
869 . .
871 . .
873 Figure 7: Client Creation of Conference using Blueprints
875 1. Alice first sends a "blueprintsRequest" message to the
876 conferencing system identified by the conference server discovery
877 process. This request contains the "confUserID" of the user
878 issuing the request (Alice's XCON-USERID) and the "xpathFilter"
879 parameter by which Alice specifies she desires to obtain only
880 blueprints providing support for both audio and video: for this
881 purpose, the xpath query contained in this field is: "/
882 conference-info[conference-description/available-media/entry/
883 type='audio' and conference-description/available-media/entry/
884 type='video'"] . Upon receipt of the "blueprintsRequest", the
885 conferencing system would first control, on the basis of the
886 "confUserID" parameter, that Alice has the appropriate authority
887 based on system policies to receive the requested kind of
888 blueprints supported by that system.
890 2. All blueprints that Alice is authorized to use are returned in a
891 "blueprintsResponse" message in the "blueprintsInfo" element.
893 3. Upon receipt of the "blueprintsResponse" containing the
894 blueprints, Alice determines which blueprint to use for the
895 conference to be created. Alice sends a "blueprintRequest"
896 message to get the specific blueprint as identified by the
897 "confObjID".
899 4. The conferencing system returns the "confInfo" associated with
900 the specific blueprint as identified by the "confObjID" in the
901 "blueprintResponse" message.
903 5. Alice finally sends a "confRequest" with a "create" operation to
904 the conferencing system to create a conference reservation
905 cloning the chosen blueprint. This is achieved by writing the
906 blueprint's XCON-URI in the "confObjID" parameter.
908 6. Upon receipt of the "confRequest" message with a "create"
909 operation, the conferencing system uses the received blueprint to
910 clone a conference, allocating a new XCON-URI (again called
911 "confObjID*" in the example). The conferencing server then sends
912 a "confResponse" message including the new "confObjID*"
913 associated with the newly created conference instance. Upon
914 receipt of the "confResponse" message, Alice can now add other
915 users to the conference .
917 1. blueprintsRequest message (Alice requires the list of the
918 available blueprints with video support)
920
921
924
926 xcon-userid:Alice@example.com
927
928 /conference-info[conference-description/
929 available-media/entry/type='audio' and
930 conference-description/available-media/entry/type='video']
931
932
933
934
936 2. blueprintsResponse message (the server provides a descriptions of
937 the available blueprints fitting Alice's request)
939
940
944
947 xcon-userid:Alice@example.com
948 success
949
950
951
952 xcon:VideoRoom@example.com
953 VideoRoom
954 Video Room:
955 conference room with public access,
956 where both audio and video are available,
957 4 users can talk and be seen at the same time,
958 and the floor requests are automatically accepted.
959
960
961
962 xcon:VideoConference1@example.com
963 VideoConference1
964 Public Video Conference: conference
965 where both audio and video are available,
966 only one user can talk
967
968
969
970
971
972
974 3. blueprintRequest/retrieve message (Alice wants the
975 "VideoRoom" blueprint)
977
978
982
984 xcon-userid:Alice@example.com
985 xcon:VideoRoom@example.com
986 retrieve
987
988
989
991 4. blueprintResponse/retrieve message ("success", "VideoRoom"
992 conference object returned)
994
995
999
1001 xcon-userid:Alice@example.com
1002 xcon:VideoRoom@example.com
1003 retrieve
1004 success
1005
1006
1007
1008 VideoRoom
1009 4
1010
1011
1012 audio
1013
1014
1015 video
1016
1017
1018
1019
1020 allow
1021
1022
1023 confirm
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1035 5. confRequest/create message (Alice clones the "VideoRoom" blueprint)
1037
1038
1042
1045 xcon-userid:Alice@example.com
1046 xcon:VideoRoom@example.com
1047 create
1048
1049
1050
1052 6. confResponse/create message ("success", cloned conference
1053 object returned)
1055
1056
1060
1063 xcon-userid:Alice@example.com
1064 xcon:8977794@example.com
1065 create
1066 success
1067 1
1068
1069
1070
1071
1072 New conference by Alice cloned from VideoRoom
1073
1074
1075
1076
1077 xcon:8977794@example.com
1078
1079
1080 conference xcon-uri
1081
1082
1083 8601
1084
1085
1086
1087 10
1088
1089
1090 audio
1091
1092
1093 video
1094
1095
1096
1097
1098 allow
1099
1100
1101
1102 confirm
1103
1104
1105
1106
1108
1109
1110
1111
1112
1114 Figure 8: Create Conference (Blueprint) Detailed Messaging
1116 5.3. Conference Creation using User-Provided Conference Information
1118 A conference can also be created by the client sending a
1119 "confRequest" message with the "create" operation, along with the
1120 desired data in the form of the "confInfo" parameter for the
1121 conference to be created. The request also includes the "confUserID"
1122 of the requesting entity.
1124 This approach allows for a client (in this example Alice) to
1125 completely describe how the conference object should look like,
1126 without just relying on defaults or blueprints: i.e. which media
1127 should be available, whish should be the topic, the users allowed to
1128 join, any scheduling-related information and so on. This can be
1129 done, as anticipated, by providing in the creation request a full
1130 conference object for the server to parse.
1132 This "confInfo" parameter must comply of course with the Data Model
1133 specification. This means that its "entity" attribute is mandatory,
1134 and cannot be missing in the document. Nevertheless, considering in
1135 this example the client is actually requesting the creation of a new
1136 conference, which doesn't exist yet, this "entity" attribute cannot
1137 be set to a valid value. This is related to an issue already
1138 anticipated in Section 4.1. To cope with this, the CCMP protocol
1139 fosters the use of a wildcard placeholder: this placeholder
1140 ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim
1141 of making the "confInfo" element compliant with the Data Model, and
1142 would subsequently be replaced by the conferencing system with the
1143 actual value. This means that, as soon as the conferencing system
1144 actually creates the conference, a valid "entity" value is created
1145 for it as well, which would take the place of the wildcard when
1146 completing the actual conference object provided by the client.
1148 To give a flavour of what could be added to the conference object, we
1149 assume Alice is also interested in providing scheduling-related
1150 information. So, in this example, Alice also specifies by the
1151 element included in the "confInfo" that the
1152 conference she wants to create has to occur on a certain date from a
1153 certain start time to a certain stop time and has to be replicated
1154 weekly.
1156 Once Alice has prepared the "confInfo" element and sent it as part of
1157 her request to the server, if the conferencing system can support
1158 that specific type of conference (capabilities, etc.), then the
1159 request results in the creation of a conference. We assume the
1160 request has been successful, and as a consequence XCON-URI in the
1161 form of the "confObjID" parameter and the XCON-USERID in the form of
1162 the "confUserID" parameter (again, the same as the requesting entity)
1163 are returned in the "confResponse" message.
1165 In this example, we choose not to return the created conference
1166 object in the successful "confResponse" in the "confInfo" parameter.
1167 Nevertheless, Alice could still retrieve the actual conference object
1168 by issuing a "confRequest" with a "retrieve" operation on the
1169 returned "confObjID". Such a request would show how, as we
1170 anticipated at the beginning of this section, the "entity" attribute
1171 of the conference object in "confInfo" is replaced with the actual
1172 information (i.e. "xcon:6845432@example.com").
1174 Just for the sake of completeness and to provide the reader with some
1175 insight about how the CCMP conferencing server might interact with
1176 other related components, this example also assumes that the
1177 conference is activated upon creation: i.e., the "method" attribute
1178 is set to "dial out" for this client based on the particular
1179 conferencing systems default. This results (as shown in the ladder
1180 diagram) in Alice, Bob and Carol being called by the conferencing
1181 system. Just as before, this is not to be considered mandatory,
1182 since it depends on the implementation choices of the framework.
1184 Alice Bob Carol ConfS
1185 | | | |
1186 | | | |
1187 |(1)confRequest(confUserID, | |
1188 | create, confInfo) | |
1189 | | | |
1190 |-------------------------------------->|
1191 | | | |
1192 | | (a)Create +---|
1193 | | |Conf | |
1194 | | |Object | |
1195 | | |& IDs +-->|
1196 | | | |--+ (b) MS
1197 | | | | | creates
1198 | | | | | conf and
1199 | | | |<-+ its ID
1200 | | | | (confid=Y)
1201 |(2)confResponse(confUserID | |
1202 | confObjID, create, | |
1203 | success, version) | |
1204 |<--------------------------------------|
1205 | | | |
1206 | | (c) Focus +---|
1207 | | sets up | |
1208 | | signaling | |
1209 | | to Alice +-->|
1210 | | | |
1211 | | | |--+(d) MS joins
1212 | | | | | Alice &
1213 | | | |<-+ conf Y
1214 | | | |
1215 | | | |
1216 |<<###################################>>|
1217 | Alice is mixed in the conference |
1218 |<<###################################>>|
1219 | | | |
1220 | | (e)Focus +---|
1221 | | sets up | |
1222 | | signaling | |
1223 | | to Bob | |
1224 | | | +-->|
1225 | | | |
1226 | | | |--+(f)MS joins
1227 | | | | | Bob &
1228 | | | |<-+ conf Y
1229 | | | |
1230 | |<<###################>>|
1231 | | Bob is mixed too |
1232 | |<<###################>>|
1233 | | | |
1234 | | (g )Focus +---|
1235 | | sets up | |
1236 | | signaling | |
1237 | | to Carol | |
1238 | | CMCCx +-->|
1239 | | | |
1240 | | | |--+(h)MS joins
1241 | | | | | CMCCx &
1242 | | | |<-+ conf Y
1243 | | | |
1244 | | |<<#######>>|
1245 | | |Carol mixed|
1246 | | |<<#######>>|
1247 | | | |
1248 | | | |
1249 | | | |
1250 |<***All parties connected to conf Y***>|
1251 | | | |
1252 | | | |
1253 " " " "
1254 " " " "
1255 " " " "
1257 Figure 9: Create Basic Conference from user provided conference-info
1259 1. confRequest/create message (Alice proposes a conference object
1260 to be created - direct creation)
1262
1263
1267
1270 xcon-userid:Alice@example.com
1271 create
1272
1273
1274
1275
1276 Dial-out conference initiated by Alice
1277
1278 10
1279
1280
1281 audio
1282
1283
1284
1285
1286
1287 BEGIN:VCALENDAR
1288 VERSION:2.0
1289 PRODID:-//Mozilla.org/NONSGML \
1290 Mozilla Calendar V1.0//EN
1291 BEGIN:VEVENT
1292 DTSTAMP: 20100127T140728Z
1293 UID: 20100127T140728Z-345FDA-alice@example.com
1294 ORGANIZER:MAILTO:alice@example.com
1295 DTSTART:20100127T143000Z
1296 RRULE:FREQ=WEEKLY
1297 DTEND: 20100127T163000Z
1298 END:VEVENT
1299 END:VCALENDAR
1300
1301
1303 2010-01-27T14:29:00Z
1304
1305
1307 2010-01-27T16:31:00Z
1308
1309 2010-01-27T15:30:00Z
1310
1311
1312
1313
1314
1315 allow
1316
1317
1319
1321
1323
1324
1325
1326
1327
1328
1330 2. confResponse/create message ("success")
1332
1333
1337
1340 xcon-userid:Alice@example.com
1341 xcon:6845432@example.com
1342 create
1343 success
1344 1
1345
1346
1348 Figure 10: Create Basic Conference Detailed Messaging
1350 5.4. Cloning an Existing Conference
1352 A client can also create another conference by cloning an existing
1353 conference, such as an active conference or conference reservation.
1354 This approach can be seen as a logical extension of the creation of a
1355 new conference using a blueprint: the difference is that, instead of
1356 cloning the pre-defined settings listed in a blueprint, the settings
1357 of an existing conference would be cloned.
1359 In this example, the client sends a "confRequest" message with the
1360 "create" operation, along with the "confUserID" and a specific
1361 "confObjID", from which a new conference is to be created by cloning
1362 an existing conference.
1364 An example of how a client can create a conference based on a
1365 blueprint is provided in Section 5.2. The manner by which a client
1366 in this example might learn about a conference reservation or active
1367 conferences is similar to the first step in the blueprint example,
1368 with the exception of specifying querying for different types of
1369 conference objects supported by the specific conferencing system.
1370 For example, in this example, the client clones a conference
1371 reservation (i.e., an inactive conference).
1373 If the conferencing system can support a new instance of the specific
1374 type of conference (capabilities, etc.), then the request results in
1375 the creation of a conference, with an XCON-URI in the form of a new
1376 value in the "confObjID" parameter to reflect the newly cloned
1377 conference object returned in the "confResponse" message.
1379 Alice ConfS
1380 | |
1381 |(1)confRequest(confUserID, |
1382 | confObjID, create) |
1383 |------------------------------>|
1384 | (a)Create +---|
1385 | Conf | |
1386 | Object | |
1387 | & IDs +-->|
1388 | |--+ (b) MS
1389 | | | creates
1390 | | | conf and
1391 | |<-+ its ID
1392 | | (confid=Y)
1393 | |
1394 |(2)confResponse(confUserID, |
1395 | confObjID*,create, |
1396 | success, version, |
1397 | confInfo) |
1398 | |
1399 |<------------------------------|
1400 | |
1402 Figure 11: Create Basic Conference - Clone
1404 1. Alice, a conferencing system client, sends a confRequest message
1405 to clone a conference based on an existing conference
1406 reservation. Alice indicates this conference should be cloned
1407 from the specified parent conference represented by the
1408 "confObjID" in the request.
1410 2. Upon receipt of the confRequest message containing a "create"
1411 operation and "confObjID", the conferencing system ensures that
1412 the "confObjID" received is valid. The conferencing system
1413 determines the appropriate read/write access of any users to be
1414 added to a conference based on this "confObjID" (using
1415 membership, roles, etc.). The conferencing system uses the
1416 received "confObjID" to clone a conference reservation. The
1417 conferencing system also reserves or allocates a new "confObjID"
1418 (called "confObjID*" in Figure 11) to be used for the cloned
1419 conference object. This new identifier is of course different
1420 from the one associated with the conference to be cloned, since
1421 it represents a different conference object. Any subsequent
1422 protocol requests from any of the members of the conference must
1423 use this new identifier. The conferencing system maintains the
1424 mapping between this conference ID and the parent conference
1425 object ID associated with the reservation through the conference
1426 instance, and this mapping is explicitly addressed through the
1427 "cloning-parent" element of the "conference-description" in the
1428 new conference object.
1430 1. confRequest/create message
1432
1433
1437
1440 xcon-userid:Alice@example.com
1441 xcon:6845432@example.com
1442 create
1443
1444
1446 2. confResponse/create message ("success", created conference
1447 object returned)
1449
1450
1454
1457 xcon-userid:Alice@example.com
1458 xcon:8977794@example.com
1459 create
1460 success
1461 1
1462
1463
1464
1465
1466 New conference by Alice cloned from 6845432
1468
1469
1470 xcon:6845432@example.com
1471
1472 10
1473
1474
1475 audio
1476
1477
1478
1479
1480 allow
1481
1482
1484
1486
1488
1489
1490
1491
1492 confirm
1493
1494
1495
1496
1497
1498
1499
1500
1502 Figure 12: Create Basic Conference (Clone) Detailed Messaging
1504 6. Conference Users Scenarios and Examples
1506 Section 5 showed examples describing the several different ways a
1507 conference might be created using CCMP. This section instead focuses
1508 on user-related scenarios, i.e. typical scenarios that may occur
1509 during the lifetime of a conference, like adding new users and
1510 handling their media. The following scenarios are based on those
1511 documented in the XCON framework. The examples assume that a
1512 conference has already been correctly established, with media, if
1513 applicable, per one of the examples in Section 5.
1515 6.1. Adding a Party
1517 In this example, Alice wants to add Bob to an established conference.
1518 In the following example we assume Bob is a new user of the system,
1519 which means Alice also needs to provide some details about him. In
1520 fact, the case of Bob already present as a user in the conferencing
1521 system is much easier to address, and will be discussed later on.
1523 "Alice" "Bob"
1524 CMCC1 CMCC2 CMCCx ConfS
1525 | | | |
1526 |(1) userRequest(confUserID,| |
1527 | confObjID, create, | |
1528 | userInfo) | | |
1529 |-------------------------------------->|
1530 | | | |
1531 | | (a) Create +---|
1532 | | | Bob | |
1533 | | | as a | |
1534 | | | user +-->|
1535 | | | |
1536 |(2) userResponse(confUserID,confObjID |
1537 | create,success,userInfo) |
1538 |<--------------------------------------|
1539 | | | |
1540 | | | (b) Focus |
1541 | | | sets up |
1542 | | | signaling |
1543 | | | to Bob |
1544 | |<----------------------|
1545 | | | |
1546 | | | (c) Notify|
1547 | | | ("Bob just|
1548 | | | joined") |
1549 | | |<----------|
1550 | | | |
1551 ' ' ' '
1552 ' ' ' '
1553 ' ' ' '
1555 Figure 13: Client Manipulation of Conference - Add a party
1557 1. Alice sends a userRequest message with an operation of "create"
1558 to add Bob to the specific conference as identified by the
1559 "confObjID". The "create" operation also makes sure that Bob is
1560 created as a user in the whole conferencing system. This is done
1561 by adding a "userInfo" element describing Bob as a user. This is
1562 needed in order to let the conferencing system be aware of Bob's
1563 characteristics. In case Bob was already a registered user,
1564 Alice would just have referenced him through his XCON-USERID in
1565 the "entity" attribute of the "userInfo" field, without providing
1566 additional data. In fact, that data (including, for instance,
1567 Bob's SIP-URI to be used subsequently for dial-out) would be
1568 obtained by referencing the extant registration. The conference
1569 server ensures that Alice has the appropriate authority based on
1570 the policies associated with that specific conference object to
1571 perform the operation. As mentioned before, a new Conference
1572 User Identifier is created for Bob, and the "userInfo" is used to
1573 update the conference object accordingly. As already seen in
1574 Section 5.3, a placeholder wildcard
1575 ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages
1576 below) is used for the "entity" attribute of the "userInfo"
1577 element, to be replaced by the actual XCON-USERID later on;
1579 2. Bob is successfully added to the conference object, and an XCON-
1580 USERID is allocated for him ("xcon-userid:Bob@example.com"); this
1581 identifier is reported in the response as part of the "entity"
1582 element of the returned "userInfo";
1584 3. In the presented example, the call signaling to add Bob to the
1585 conference is instigated through the Focus as well. We again
1586 remind that this is implementation specific. In fact, a
1587 conferencing system may accomplish different actions after the
1588 user creation, just as it may do nothing at all. Among the
1589 possible actions, for instance Bob may be added as a
1590 element to the element, whose joining
1591 "method" may be either "dial-in" or "dial-out". Besides, out-of-
1592 band notification mechanisms may be involved as well, e.g. to
1593 notify Bob via mail of the new conference, including details as
1594 the date, password, expected participants and so on (see
1595 Section 4.3).
1597 To conclude the overview on this scenario, once Bob has been
1598 successfully added to the specified conference, per updates to the
1599 state, and depending upon the policies, other participants
1600 (including Bob himself) may be notified of the addition of Bob to
1601 the conference via the Conference Notification Service in use.
1603 1. userRequest/create message (Alice adds Bob)
1605
1606
1609
1611 xcon-userid:Alice@example.com
1612 xcon:8977878@example.com
1613 create
1614
1615
1616 Bob
1617
1618
1619 mailto:bob.depippis@example.com
1620 Bob's email
1621
1622
1623
1624 Bob's laptop
1625
1626
1627
1628
1629
1631 2. userResponse/create message ("success": a new XCON-USERID is
1632 created for Bob and he is added to the conference)
1634
1635
1638
1640 xcon-userid:Alice@example.com
1641 xcon:8977878@example.com
1642 create
1643 success
1644 10
1645
1646
1647 Bob
1648
1649
1650 mailto:bob.depippis@example.com
1651 Bob's email
1652
1653
1654
1655 Bob's laptop
1656
1657
1658
1659
1660
1662 Figure 14: Add Party Message Details
1664 6.2. Muting a Party
1666 This section provides an example of the muting of a party in an
1667 active conference. We assume that the user to mute has already been
1668 added to the conference. The document only addresses muting, since
1669 unmuting would involve an almost identical CCMP message flow.
1671 Please notice that interaction between CCMP and an ad-hoc designed
1672 floor control solution like BFCP should be carefully considered.
1673 Indeed, CCMP- and BFCP-based media control can be viewed as two
1674 alternative and potentially interfering solutions for what
1675 concerns floor control actions. As an example, a participant may
1676 have the BFCP floor granted, but be muted by means of CCMP; if so,
1677 he would still be muted in the conference and would only be
1678 unmuted if both protocols allowed for this. In general, the
1679 interaction between these potentially conflicting protocols falls
1680 in the wider scope of policy control at the overall system's level
1681 and is not the subject of this document.
1683 Figure 15 provides an example of one client, "Alice", impacting the
1684 media state of another client, "Bob". This example assumes an
1685 established conference. In this example, Alice, whose role is
1686 "moderator" of the conference, wants to mute Bob on a medium-size
1687 multi-party conference, as his device is not muted (and he's
1688 obviously not listening to the call) and background noise in his
1689 office environment is disruptive to the conference. BFCP floor
1690 control is assumed not to be involved.
1692 From a protocol point of view, muting/unmuting an user basically
1693 consists in updating the conference object by modifying the settings
1694 related to the target user's media streams. Specifically, Bob's
1695 "userInfo" must be updated by modifying its audio
1696 information (e.g. setting it to "recvonly" in case of muting),
1697 identified by the right media id.
1699 "Alice" "Bob"
1700 CMCC1 CMCC2 CMCCx ConfS MS
1701 | | | | |
1702 |(1) userRequest(subject, | | |
1703 | confUserID,confObjID, | | |
1704 | update,userInfo) | | |
1705 | | | | |
1706 |--------------------------------------->| |
1707 | | | | Mute Bob |
1708 | | | |----------------->|
1709 | | | | 200 OK |
1710 | | | |<-----------------|
1711 | | | | |
1712 | |<====== XXX Bob excluded from mix XXX ====>|
1713 | | | | |
1714 | | (a) Update +---| |
1715 | | Bob in | | |
1716 | | Data Model | | |
1717 | | (muted) +-->| |
1718 | | | | |
1719 | (2)userResponse(confUserID,confObjID, | |
1720 | update,success,version) | |
1721 |<---------------------------------------| |
1722 | | | | |
1723 | | | (b) Notify | |
1724 | | | ("Bob is | |
1725 | | | muted") | |
1726 | | |<-----------| |
1727 | | | | |
1728 ' ' ' ' '
1729 ' ' ' ' '
1730 ' ' ' ' '
1732 Figure 15: Client Manipulation of Conference - Mute a party
1734 1. Alice sends a userRequest message with an "update" operation and
1735 the userInfo with the "status" field in the "media" element for
1736 Bob's set to "revconly". In order to authenticate
1737 herself, Alice provides in the "subject" request parameter her
1738 registration credentials (i.e. username and password). The
1739 "subject" parameter is an optional one: its use can be systematic
1740 whenever the conferencing server envisages to authenticate each
1741 requestor. In such cases, if the client does not provide the
1742 required authentication information, the conferencing server
1743 answers with a CCMP "authenticationRequired" response message,
1744 indicating that the request cannot be processed without including
1745 the proper "subject" parameter. The Conference Server ensures
1746 that Alice has the appropriate authority based on the policies
1747 associated with that specific conference object to perform the
1748 operation. It recognizes that Alice is allowed to request the
1749 specified modification, since she is moderator of the target
1750 conference, and updates the "userInfo" in the conference object
1751 reflecting that Bob's media is not to be mixed with the
1752 conference media. In case the Conference Server relies on a
1753 remote Media Server for its multimedia functionality, it
1754 subsequently changes Bob's media profile accordingly by means of
1755 the related protocol interaction with the MS to enforce the
1756 decision. An example describing a possible way of dealing with
1757 such a situation using the Media Server Control architecture is
1758 described in [I-D.ietf-mediactrl-call-flows], at "Simple
1759 Bridging: Framework Transactions (2)".
1761 2. A userResponse message with a response-code of "success" is then
1762 sent to Alice. Depending upon the policies, the conference
1763 server may notify other participants (including Bob) of this
1764 update via any Conference Notification Service that may be in
1765 use.
1767 1. userRequest/update message (Alice mutes Bob)
1769
1770
1773
1775
1776 Alice83
1777 13011983
1778
1779 xcon-userid:Alice@example.com
1780 xcon:8977878@example.com
1781 update
1782
1783
1784
1785
1786 123
1787 recvonly
1788
1789
1790
1791
1792
1793
1795 2. userResponse/update message ("success")
1797
1798
1801
1803 xcon-userid:Alice@example.com
1804 xcon:8977878@example.com
1805 update
1806 success
1807 7
1808
1809
1810
1812 Figure 16: Mute Message Details
1814 6.3. Conference Announcements and Recordings
1816 This section deals with features that are typically required in a
1817 conferencing system, that are public announcements (e.g. to notify
1818 vocally that a new user joined a conference) and name recording.
1819 While this is not strictly CCMP-related (the CCMP signaling is
1820 actually the same as the one seen in Section 6.1) it is an
1821 interesting scenario to address to see how the several components of
1822 an XCON-compliant architecture interact with each other to make it
1823 happen.
1825 In this example, as shown in Figure 17 Alice is joining Bob's
1826 conference that requires that she first enters a pass code. After
1827 successfully entering the pass code, an announcement prompts Alice to
1828 speak her name so it can be recorded. When Alice is added to the
1829 active conference, the recording is played back to all the existing
1830 participants. A very similar example is presented in Figure 33 of
1831 [I-D.ietf-mediactrl-call-flows].
1833 CMCC "Alice" ConfS MS
1834 | | |
1835 |(1)userRequest(confObjID, | |
1836 | create,userInfo) | |
1837 |--------------------------->| |
1838 | |--+ Alice is |
1839 | | | new in the |
1840 | |<-+ system (create |
1841 | | confUserID) |
1842 | ConfS handles +--| |
1843 | SIP signaling | | |
1844 | (Alice<->ConfS<->MS) +->| |
1845 | | |
1846 | |--+ A password is |
1847 | | | required for |
1848 | |<-+ that conference |
1849 | | |
1850 | | Request IVR menu (PIN) |
1851 | |--------------------------->|
1852 | | |
1853 |<========= MS gets PIN from Alice through DTMF =========>|
1854 | | |
1855 | | Provided PIN is... |
1856 | |<---------------------------|
1857 | Check +--| |
1858 | PIN | | |
1859 | +->| |
1860 | |--+ Alice must |
1861 | | | record her |
1862 | |<-+ name |
1863 | | |
1864 | | Request name recording |
1865 | |--------------------------->|
1866 | | |
1867 |<========= MS records Alice's audio RTP (name) =========>|
1868 | | |
1869 | | Audio recording |
1870 | |<---------------------------|
1871 | Complete +--| |
1872 | creation | | |
1873 | of Alice +->| |
1874 | | |
1875 | | |
1876 | (2)userResponse(confUserID,| |
1877 | confObjID, create, | |
1878 | success, version) | |
1879 |<---------------------------| |
1880 | | |
1881 Figure 17: Recording and Announcements
1883 1. Upon receipt of the userRequest from Alice to be added to Bob's
1884 conference, the conferencing system determines that a password is
1885 required for this specific conference. Thus an announcement
1886 asking Alice to enter the password is sent back. This may be
1887 achieved by means of typical IVR functionality. Once Alice
1888 enters the password, it is validated against the policies
1889 associated with Bob's active conference. The conferencing system
1890 then connects to a server which prompts and records Alice's name.
1891 The conferencing system must also determine whether Alice is
1892 already a user of this conferencing system or whether she is a
1893 new user. In this case, Alice is a new user for this
1894 conferencing system, so a Conference User Identifier (i. e. an
1895 XCON-USERID) is created for Alice. Based upon the contact
1896 information provided by Alice, the call signaling to add Alice to
1897 the conference is instigated through the Focus.
1899 2. The conference server sends Alice a userResponse message which
1900 includes the "confUserID" assigned by the conferencing system to
1901 her. This would allow Alice to later perform operations on the
1902 conference (if she were to have the appropriate policies),
1903 including registering for event notifications associated with the
1904 conference. Once the call signaling indicates that Alice has
1905 been successfully added to the specific conference, per updates
1906 to the state, and depending upon the policies, other participants
1907 (e.g., Bob) are notified of the addition of Alice to the
1908 conference via the conference notification service and an
1909 announcement is provided to all the participants indicating that
1910 Alice has joined the conference.
1912 1. userRequest/create message (Alice - a new conferencing system
1913 client - enters Bob's conference)
1915
1916
1920
1922 xcon:bobConf@example.com
1923 create
1924
1925
1926
1927
1928
1929 mailto:Alice83@example.com
1930
1931 email
1932
1933
1934
1935
1936
1937
1938
1940 2.userResponse/create ("success": Alice is provided with a new
1941 xcon-userid and is added to the conference)
1943
1944
1948
1950 xcon-userid:Alice@example.com
1951 xcon:bobConf@example.com
1952 create
1953 success
1954 5
1955
1956
1957
1958 Figure 18: Announcement Messaging Details
1960 6.4. Monitoring for DTMF
1962 Conferencing systems often also need the capability to monitor for
1963 DTMF from each individual participant. This would typically be used
1964 to enter the identifier and/or access code for joining a specific
1965 conference. This feature is often also exploited to achieve
1966 interaction between participants and the conference system for non-
1967 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted).
1969 An example of DTMF monitoring, within the context of the framework
1970 elements, is shown in Figure 17. A typical way for the conferencing
1971 system to be aware of all the DTMF interactions within the context of
1972 conferences it is responsible for, is making use of the MEDIACTRL
1973 architecture for what regards media manipulation. Examples in that
1974 sense (specifically for what concerns DTMF interception in conference
1975 instances) are presented in [I-D.ietf-mediactrl-call-flows].
1977 6.5. Entering a password-protected conference
1979 Some conferences may envision a password to be provided by a user who
1980 wants to manipulate the relative conference objects (e.g. join,
1981 update, delete) via CCMP. Such a password would be included in the
1982 element related to the conference XCON-URI in
1983 the appropriate entry and must be then included in
1984 the apposite "conference-password" field in the CCMP request
1985 addressed to that conference.
1987 In the following CCMP transactions, it is depicted a scenario in
1988 which Alice, a conferencing system client, attempts to join a
1989 password-protected conference.
1991 1. Alice sends a userRequest message with a "create" operation to
1992 add herself in the conference with XCON-URI
1993 "xcon:8977777@example.com" (written in the "confObjID"
1994 parameter). Alice provides her XCON-USERID via the "confUserID"
1995 field of the userRequest and leaves out the "userInfo" one
1996 (first-party join). In this first attempt, she doesn't insert
1997 any password parameter.
1999 2. Upon receipt the userRequest/create message, the conferencing
2000 server detects that the indicated conference is not joinable
2001 without providing the relative pass code. Then a userResponse
2002 message with "confPasswordRequired" response-code is returned to
2003 Alice to indicate that her join has been refused and that she has
2004 to recast her request including the appropriate conference
2005 password in order to participate.
2007 3. After getting the pass code through out-of-band mechanisms, Alice
2008 provides it in the proper "password" request field of a new
2009 userRequest/create message and sends the updated request back to
2010 the server.
2012 4. The conferencing server checks the provided password and then
2013 adds Alice to the protected conference. After that, a
2014 userResponse with a "success" response-code is sent to Alice.
2016 1. userRequest/create message (Alice tries to enter the conference
2017 without providing the password)
2019
2020
2024
2026 xcon-userid:Alice@example.com
2027 xcon:8977794@example.com
2028 create
2029
2030
2031
2033 2. userResponse/create message ("passwordRequired")
2035
2036
2040
2042 xcon-userid:Alice@example.com
2043 xcon:8977794@example.com
2044 create
2045 confPasswordRequired
2046
2047
2048
2050 3. userRequest/create message (Alice provides the password)
2051
2052
2056
2058 xcon-userid:Alice@example.com
2059 xcon:8977794@example.com
2060 create
2061 8601
2062
2063
2064
2066 4. userResponse/create message ("success")
2068
2069
2073
2075 xcon-userid:Alice@example.com
2076 xcon:8977794@example.com
2077 create
2078 success
2079 10
2080
2081
2082
2084 Figure 19: Password-protected conference join messages details
2086 7. Sidebars Scenarios and Examples
2088 While creating conferences and manipulating users and their media may
2089 be considered enough for many scenarios, there may be cases when a
2090 more complex management is needed.
2092 In fact, a feature typically required in conferencing systems is the
2093 ability to create sidebars. A sidebar is basically a child
2094 conference that usually includes a subset of the participants of the
2095 parent conference, and a subset of its media as well. Sidebars are
2096 typically required whenever some of the participants in a conference
2097 want to discuss privately about something, without interfering with
2098 the main conference.
2100 This section deals with some scenarios that typically envisage the
2101 use of a sidebar, like whispering, private messages and coaching
2102 scenarios. The first subsections, anyway, present some examples of
2103 how a generic sidebar can be created, configured and managed.
2105 7.1. Internal Sidebar
2107 Figure 20 provides an example of one client, "Alice", involved in an
2108 active conference with "Bob" and "Carol". Alice wants to create a
2109 sidebar to have a side discussion with Bob while still viewing the
2110 video associated with the main conference. Alternatively, the audio
2111 from the main conference could be maintained at a reduced volume.
2112 Alice initiates the sidebar by sending a request to the conferencing
2113 system to create a conference reservation based upon the active
2114 conference object. Alice and Bob would remain on the roster of the
2115 main conference, such that other participants could be aware of their
2116 participation in the main conference, while an internal-sidebar
2117 conference is occurring. Besides, Bob decides that he is not
2118 interested in still receiving the conference audio in background (not
2119 even at a lower volume as Alice configured) and so modifies the
2120 sidebar in order to make that stream inactive for him.
2122 Alice Bob ConfS
2123 | | |
2124 |(1) sidebarByValRequest(confUserID, |
2125 | confObjID,create) |
2126 |--------------------------------------------->|
2127 | | |
2128 | | (a) Create +---|
2129 | | sidebar-by-val | |
2130 | | (new conf obj | |
2131 | | cloned from +-->|
2132 | | confObjID) | Sidebar now has
2133 | | | id confObjID*
2134 |(2) sidebarByValResponse(confUserID, | (parent mapping
2135 | (confObjID*, create, success, | conf<->sidebar)
2136 | version, sidebarByValInfo) |
2137 |<---------------------------------------------|
2138 | | |
2139 |(3) sidebarByValRequest |
2140 | (confUserID, confObjID*, |
2141 | update,sidebarByValInfo) |
2142 |--------------------------------------------->|
2143 | | |
2144 | | (b) Update +---|
2145 | | sidebar-by-val | |
2146 | | (media, users | |
2147 | | etc.) +-->|
2148 | | | Sidebar is
2149 | | | modified
2150 |(4) sidebarByValResponse(confUserID, |
2151 | confObjID*, update, |
2152 | success, version) |
2153 |<---------------------------------------------|
2154 | | |
2155 | |(5) userRequest |
2156 | | (confUserID', |
2157 | | confObjID*, |
2158 | | update,userInfo)|
2159 | |---------------------->|
2160 | | |
2161 | | (c) Update +---|
2162 | | user settings | |
2163 | | (Bob's media) | |
2164 | | +-->|
2165 | | | Sidebar is modified
2166 | | | (original audio
2167 | | | inactive for Bob)
2168 | |(6) userResponse |
2169 | | (confUserID', |
2170 | | confObjID*,update|
2171 | | success,version) |
2172 | |<----------------------|
2173 | | |
2174 " " "
2175 " " "
2176 " " "
2178 Figure 20: Client Creation of a Sidebar Conference
2180 1. Upon receipt of CCMP sidebarByValRequest message to create a new
2181 sidebar-conference based upon the confObjID received in the
2182 request, the conferencing system uses the confObjID to clone a
2183 conference reservation for the sidebar. The sidebar reservation
2184 is NOT independent of the active conference (i.e., parent). The
2185 conferencing system also allocates a new XCON-URI for that
2186 sidebar to be used for any subsequent protocol requests from any
2187 of the members of the conference. The new sidebar identifier
2188 ("confObjID*" in Figure 20) is returned in the response message
2189 confObjID parameter.
2191 2. The relationship information is provided in the
2192 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the
2194 main/parent conference is provided below as well to show how the
2195 cloning process for the creation of the sidebar could take place.
2197 3. Upon receipt of the sidebarByValResponse message to reserve the
2198 conference, Alice can now create an active conference using that
2199 reservation, or create additional reservations based upon the
2200 existing reservations. In this example, Alice wants only Bob to
2201 be involved in the sidebar, thus she manipulates the membership
2202 so that only the two of them appear in the
2203 section. Alice also wants both audio and video from the original
2204 conference to be available in the sidebar. For what concerns the
2205 media belonging to the sidebar itself, Alice wants the audio to
2206 be restricted to the participants in the sidebar (that is, Bob
2207 and herself). Additionally, Alice manipulates the media values
2208 to receive the audio from the main conference at a reduced
2209 volume, so that the communication between her and Bob isn't
2210 affected. Alice sends a sidebarByValRequest message with an
2211 operation of "update" along with the "sidebarByValInfo"
2212 containing the aforementioned sidebar modifications.
2214 4. Upon receipt of the sidebarByValRequest to update the sidebar
2215 reservation, the conference server ensures that Alice has the
2216 appropriate authority based on the policies associated with that
2217 specific conference object to perform the operation. The
2218 conference server must also validate the updated information in
2219 the reservation, ensuring that a member like Bob is already a
2220 user of this conference server. Once the data for the confObjID
2221 is updated, the conference server sends a sidebarByValResponse to
2222 Alice. Depending upon the policies, the initiator of the request
2223 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may
2224 be notified of his addition to the sidebar via the conference
2225 notification service.
2227 5. At this point, Bob sends a userRequest message to the conference
2228 server with an operation of "update" to completely disable the
2229 background audio from the parent conference, since it prevents
2230 him from understanding what Alice says in the sidebar.
2232 6. Notice that Bob's request only changes the media perspective for
2233 Bob. Alice keeps on receiving both the audio from Bob and the
2234 background from the parent conference. This request may be
2235 relayed by the conference server to the Media Server handling the
2236 mixing, if present. Upon completion of the change, the
2237 conference server sends a "userResponse" message to Bob.
2238 Depending upon the policies, the initiator of the request (i.e.,
2239 Bob) and the participants in the sidebar (i.e., Alice) may be
2240 notified of this change via the conference notification service.
2242 That said, let's consider the following conference object:
2244
2245
2250
2251 MAIN CONFERENCE
2252
2253
2254 sip:8977878@example.com
2255 conference sip uri
2256
2257
2258
2259
2260 main conference audio
2261 audio
2262 sendrecv
2263
2264
2265 main conference video
2266 video
2267 sendrecv
2268
2269 single-view
2270
2271
2272
2273
2274
2275 true
2276
2277
2278
2279 Alice
2280
2281
2282 123
2283 sendrecv
2284
2285
2286 456
2287 sendrecv
2288
2289
2290
2291
2292 Bob
2293
2294
2295 123
2296 sendrecv
2297
2298
2299 456
2300 sendrecv
2301
2302
2303
2304
2305 Carol
2306
2307
2308 123
2309 sendrecv
2310
2311
2312 456
2313 sendrecv
2314
2315
2316
2317
2318
2320 Figure 21: Conference with Alice, Bob and Carol
2322 This is the representation of the conference the sidebar is going to
2323 be created in. As such, it will be used by the conferencing system
2324 in order to create the new conference object associated with the
2325 sidebar. In fact, the sidebar creation happens through a cloning of
2326 the parent conference. Once the sidebar is created, an "update"
2327 makes sure that the sidebar is customized as needed. The following
2328 protocol dump makes the process clearer.
2330 1. sidebarByValRequest/create message (Alice creates an
2331 internal sidebar)
2333
2334
2337
2339 xcon-userid:Alice@example.com
2340 xcon:8977878@example.com
2341 create
2342
2343
2344
2346 2. sidebarByValResponse/create message ("success", sidebar returned)
2348
2349
2353
2355 xcon-userid:Alice@example.com
2356 xcon:8974545@example.com
2357 create
2358 success
2359 1
2360
2361
2362
2363
2364 SIDEBAR CONFERENCE registered by Alice
2365
2366
2367 xcon:8977878@example.com
2368
2369
2370
2371
2372 main conference audio
2373
2374 audio
2375 sendrecv
2376
2377
2378
2379 main conference video
2380
2381 video
2382 sendrecv
2383
2384
2385
2386
2387 false
2388
2389
2390
2391
2393
2395
2397
2398
2399
2400
2401
2402
2404 3. sidebarByValRequest/update message (Alice updates the
2405 created sidebar)
2407
2408
2412
2414 xcon-userid:Alice@example.com
2415 xcon:8974545@example.com
2416 update
2417
2418
2419
2420
2421 private sidebar Alice - Bob
2422
2423
2424
2425
2426 main conference audio
2427
2428 audio
2429 recvonly
2430
2431 -60
2432
2433
2434
2435
2436 main conference video
2437
2438 video
2439 recvonly
2440
2441
2442
2443 sidebar audio
2444
2445 audio
2446 sendrecv
2447
2448
2449
2450 sidebar video
2451
2452 video
2453 sendrecv
2454
2455
2456
2457
2458
2459
2461
2463
2464
2465
2466
2467
2468
2470 4. sidebarByValResponse/update message ("success", sidebar's
2471 updates accepted)
2473
2474
2478
2480 xcon-userid:Alice@example.com
2481 xcon:8974545@example.com
2482 update
2483 success
2484 2
2485
2486
2487
2489 5. userRequest/update message (Bob updates his media)
2491
2492
2496
2498 xcon-userid:Bob@example.com
2499 xcon:8974545@example.com
2500 update
2501
2502
2503
2504
2505
2506 main conference audio
2507
2508 123
2509 inactive
2510
2511
2512
2513
2514
2515
2516 6. userResponse/update message ("success", Bob's preferences setted)
2518
2519
2522
2524 xcon-userid:Bob@example.com
2525 xcon:8974545@example.com
2526 update
2527 success
2528 3
2529
2530
2531
2533 Figure 22: Internal Sidebar Messaging Details
2535 7.2. External Sidebar
2537 Figure 23 provides an example of a different approach towards
2538 sidebar. In this scenario, one client, "Alice", is involved in an
2539 active conference with "Bob", "Carol", "David" and "Ethel". Alice
2540 gets an important text message via a whisper from Bob that a critical
2541 customer needs to talk to Alice, Bob and Ethel. Alice creates a
2542 sidebar to have a side discussion with the customer "Fred" including
2543 the participants in the current conference with the exception of
2544 Carol and David, who remain in the active conference. The difference
2545 from the previous scenario is that Fred is not part of the parent
2546 conference: this means that different policies might be involved,
2547 considering that Fred may access information coming from the parent
2548 conference, in case the sidebar was configured accordingly. For this
2549 reason, in this scenario we assume that Alice disables all the media
2550 from the original (parent) conference within the sidebar. This means
2551 that, while in the previous example Alice and Bob still heard the
2552 audio from the main conference in background, this time no background
2553 is made available. Alice initiates the sidebar by sending a request
2554 to the conferencing system to create a conference reservation based
2555 upon the active conference object. Alice, Bob and Ethel would remain
2556 on the roster of the main conference in a hold state. Whether or not
2557 the hold state of these participants is visible to other participants
2558 depends upon the individual and local policy.
2560 Alice Bob ConfS
2561 | | |
2562 |(1) sidebarByRefRequest(confUserID, |
2563 | confObjID, create) |
2564 |--------------------------------------------->|
2565 | | |
2566 | | (a) Create +---|
2567 | | sidebar-by-ref | |
2568 | | (new conf obj | |
2569 | | cloned from +-->|
2570 | | confObjID) | Sidebar now has
2571 | | | id confObjID*
2572 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2573 | confObjID*, create, success, | conf<->sidebar)
2574 | version, sidebarByRefInfo) |
2575 |<---------------------------------------------|
2576 | | |
2577 |(3) sidebarByRefRequest(confUserID, |
2578 | confObjID*,update,sidebarByRefInfo) |
2579 |--------------------------------------------->|
2580 | | |
2581 | | (b) Create +---|
2582 | | new user for | |
2583 | | Fred | |
2584 | | +-->|
2585 | | |
2586 | | (c) Update +---|
2587 | | sidebar-by-ref | |
2588 | | (media, users | |
2589 | | policy, etc.) +-->|
2590 | | | Sidebar is modified:
2591 | | | no media from the
2592 | | | parent conference is
2593 | | | available to anyone
2594 |(4) sidebarByRefResponse(confUserID, |
2595 | confObjID*, update, |
2596 | success, version) |
2597 |<---------------------------------------------|
2598 | | |
2599 | | Notify (Fred |
2600 | | added to |
2601 | | sidebar users) |
2602 | |<----------------------|
2603 | | |
2604 " " "
2605 " " "
2606 " " "
2607 Figure 23: Client Creation of an External Sidebar
2609 1. Upon receipt of the "sidebarByRefRequest" message to create a new
2610 sidebar conference, based upon the active conference specified by
2611 "confObjID" in the request, the conferencing system uses that
2612 active conference to clone a conference reservation for the
2613 sidebar. The sidebar reservation is NOT independent of the
2614 active conference (i.e., parent). The conferencing system, as
2615 before, allocates a conference ID (confObjID*) to be used for any
2616 subsequent protocol requests toward the sidebar reservation. The
2617 mapping between the sidebar conference ID and the one associated
2618 with the main conference is mantained by the conferencing system
2619 and it is gathered from the c element in the
2620 sidebar conference object.
2622 2. Upon receipt of the "sidebarByRefResponse" message, which
2623 acknowledges the successful creation of the sidebar object, Alice
2624 decides that only Bob and Ethel, along with the new participant
2625 Fred are to be involved in the sidebar. Thus she manipulates the
2626 membership accordingly. Alice also sets the media in the
2627 "conference-info" such that the participants in the sidebar don't
2628 receive any media from the main conference. All these settings
2629 are provided to the conferencing system by means of a new
2630 "sidebarByRefRequest" message, with an "update" operation.
2632 3. Alice sends the aforementioned "sidebarByRefRequest" to update
2633 the information in the reservation and to create an active
2634 conference. Upon receipt of the "sidebarByRefRequest" with an
2635 operation of "update", the conferencing system ensures that Alice
2636 has the appropriate authority based on the policies associated
2637 with that specific conference object to perform the operation.
2638 The conferencing system also validates the updated information in
2639 the reservation. Since Fred is a new user for this conferencing
2640 system, a conference user identifier is created for Fred.
2641 Specifically, Fred is added to the conference by only providing
2642 his SIP URI. Based upon the contact information provided for
2643 Fred by Alice, the call signaling to add Fred to the conference
2644 may be instigated through the Focus (e.g. if Fred had a "dial-
2645 out" method set as the target for him) at the actual activation
2646 of the sidebar.
2648 4. The conference server sends a "sidebarByRefResponse" message and,
2649 depending upon the policies, the initiator of the request (i.e.,
2650 Alice) and the participants in the sidebar (i.e., Bob and Ethel)
2651 may be notified of his addition to the sidebar via the conference
2652 notification service.
2654 1. sidebarByRefRequest/create message (Alice creates an
2655 external sidebar)
2657
2658
2661
2663 xcon-userid:Alice@example.com
2664 xcon:8977878@example.com
2665 create
2666
2667
2668
2670 2. sidebarByRefResponse/create message ("success", created
2671 sidebar returned)
2673
2674
2678
2680 xcon-userid:Alice@example.com
2681 xcon:8971212@example.com
2682 create
2683 success
2684 1
2685
2686
2687
2688
2689 SIDEBAR CONFERENCE registered by Alice
2690
2691
2692 xcon:8977878@example.com
2693
2694
2695
2696
2697 main conference audio
2698
2699 audio
2700 sendrecv
2701
2702
2703
2704 main conference video
2705
2706 video
2707 sendrecv
2708
2709
2710
2711
2712 false
2713
2714
2715
2716
2718
2720
2722
2724
2726
2727
2728
2729
2730
2731
2733 3. sidebarByRefRequest/update message (Alice updates the sidebar)
2735
2739
2741 xcon-userid:Alice@example.com
2742 xcon:8971212@example.com
2743 update
2744
2745
2746
2747
2748 sidebar with Alice, Bob, Ethel & Fred
2749
2750
2751
2752
2753 main conference audio
2754
2755 audio
2756 inactive
2757
2758
2759
2760 main conference video
2761
2762 video
2763 inactive
2764
2765
2766
2767 sidebar audio
2768
2769 audio
2770 sendrecv
2771
2772
2773
2774 sidebar video
2775
2776 video
2777 sendrecv
2778
2779
2780 single-view
2781
2782
2783
2784
2785
2786
2787 false
2788
2789
2790
2791
2793
2796
2798
2799
2800
2801
2802
2803
2805 4. sidebarByRefResponse/update message ("success", sidebar updated)
2807
2811
2813 xcon-userid:Alice@example.com
2814 xcon:8971212@example.com
2815 update
2816 success
2817 2
2818
2819
2820
2822 Figure 24: External Sidebar Messaging Details
2824 7.3. Private Messages
2826 The case of private messages can be handled as a sidebar with just
2827 two participants, similarly to the example in Section 7.1. Unlike
2828 the previous example, rather than using audio within the sidebar,
2829 Alice could just add an additional text based media stream to the
2830 sidebar in order to convey her textual messages to Bob, while still
2831 viewing and listening to the main conference.
2833 In this scenario, Alice requests to the conferencing system the
2834 creation of a private chat room within the main conference context
2835 (presented in Figure 21) in which the involved partecipants are just
2836 Bob and herself. This can be achieved through the following CCMP
2837 transaction (Figure 25).
2839 1. Alice forwards a sidebarByValRequest/create to the Conferencing
2840 Control Server with the main conference XCON-URI in the
2841 "confObjID" parameter and the desired sidebar conference object
2842 in the "sidebarByValInfo" field. In this way, a sidebar creation
2843 using user-provided conference information is requested to the
2844 conferencing system. Please note that, unlike the previous
2845 sidebar examples, in this case a comnpletely new conference
2846 object to describe the sidebar is provided: there is no cloning
2847 involved, while the "confObjID" still enforces the parent-child
2848 relationship between the main conference and the to-be-created
2849 sidebar.
2851 2. The Conference Control Server, after checking Alice's rights and
2852 validating the conference-object carried in the request, creates
2853 the required sidebar-by-val conference and a new XCON-URI for it.
2854 Instead of cloning the main conference object, as envisioned in
2855 Section 7.1 and Section 7.2, the sidebar is created on the basis
2856 of the user provided conference information (as anticipated
2857 before). However, the parent relationship between the main
2858 conference and the newly created sidebar is still mantained by
2859 the conferencing system (as a consequence of the chosen CCMP
2860 request message type - the sidebarByVal one) and it is reflected
2861 by the element in the "sidebarByValInfo" element
2862 returned in the sidebarByValResponse message. Please notice
2863 that, according to the CCMP specification, the return of the
2864 created sidebar data in this kind of "success" response is not
2865 mandatory.
2867 1. sidebarByValRequest/create message (Alice creates a private
2868 chat room between Bob and herself)
2870
2871
2875
2877 xcon-userid:Alice@example.com
2878 xcon:8977878@example.com
2879 create
2880
2881
2882
2883
2884 private textual sidebar alice - bob
2885
2886
2887
2888
2889 main conference audio
2890
2891 audio
2892 recvonly
2893
2894
2895
2896 main conference video
2897
2898 video
2899 recvonly
2900
2901
2902
2903 sidebar text
2904
2905 text
2906 sendrecv
2907
2908
2909
2910
2911
2912
2914
2916
2917
2918
2919
2920
2921
2923 2. sidebarByValResponse/create message ("success", sidebar returned)
2925
2926
2930
2932 xcon-userid:Alice@example.com
2933 xcon:8974545@example.com
2934 create
2935 success
2936 1
2937
2938
2939
2940
2941 private textual sidebar alice - bob
2942
2943
2944 xcon:8977878@example.com
2945
2946
2947
2948
2949 main conference audio
2950
2951 audio
2952 recvonly
2953
2954
2955
2956 main conference video
2957
2958 video
2959 recvonly
2960
2961
2962
2963 sidebar text
2964
2965 text
2966 sendrecv
2967
2968
2969
2970
2971
2972
2974
2976
2977
2978
2979
2980
2981
2982 Figure 25: Sidebar for Private Messages scenario
2984 7.4. Observing and Coaching
2986 Observing and Coaching is one of the most interesting sidebars-
2987 related scenarios. In fact, it envisages two different interactions
2988 that have to be properly coordinated.
2990 An example of observing and coaching is shown in figure Figure 27.
2991 In this example, call center agent Bob is involved in a conference
2992 with customer Carol. Since Bob is a new agent and Alice sees that he
2993 has been on the call with Carol for longer than normal, she decides
2994 to observe the call and coach Bob as necessary. Of course the
2995 conferencing system must make sure that the customer Carol is not
2996 aware of the presence of the coach Alice. This makes the use of a
2997 sidebar necessary for the success of the scenario.
2999 Consider the following as the conference document associated with the
3000 video conference involving Bob (the call agent) and Carol (the
3001 customer) (Figure 26):
3003
3004
3009
3010
3011 CUSTOMER SERVICE conference
3012
3013
3014
3015 sip:8978383@example.com
3016 conference sip uri
3017
3018
3019
3020
3021 service audio
3022 audio
3023 sendrecv
3024
3025
3026 service video
3027 video
3028 sendrecv
3029
3030 single-view
3031
3032
3033
3034
3035
3036 true
3037
3038
3039
3040 Bob - call agent
3041
3042
3043 123
3044 sendrecv
3045
3046
3047 456
3048 sendrecv
3049
3050
3051
3052
3053 Carol - customer
3054
3055
3056 123
3057 sendrecv
3058
3059
3060 456
3061 sendrecv
3062
3063
3064
3065
3066
3068 Figure 26: A call-center conference object example
3070 Alice Bob ConfS
3071 | | |
3072 |(1) sidebarByRefRequest(confUserID, |
3073 | confObjID, create) |
3074 |--------------------------------------------->|
3075 | | |
3076 | | (a) Create +---|
3077 | | sidebar-by-ref | |
3078 | | (new conf obj | |
3079 | | cloned from +-->|
3080 | | confObjID) | Sidebar now has
3081 | | | id confObjID*
3082 |(2) sidebarByRefResponse(confUserID, | (parent mapping
3083 | confObjID*, create, success, | conf<->sidebar)
3084 | version, sidebarByRefInfo) |
3085 |<---------------------------------------------|
3086 | | |
3087 |(3) sidebarByRefRequest(confUserID, |
3088 | confObjID*,update,sidebarByRefInfo) |
3089 |--------------------------------------------->|
3090 | | |
3091 | | (b) Update +---|
3092 | | sidebar-by-val | |
3093 | | (media, users | |
3094 | | policy, etc.) +-->|
3095 | | | Sidebar is modified:
3096 | | | unilateral sidebar
3097 | | | audio, Carol excluded
3098 | | | from the sidebar
3099 |(4) sidebarByRefResponse(confUserID, |
3100 | confObjID*, update, |
3101 | success, version) |
3102 |<---------------------------------------------|
3103 | | |
3104 | | Notify (Bob |
3105 | | he's been added to |
3106 | | sidebar users) |
3107 | |<----------------------|
3108 | | |
3109 " " "
3110 " " "
3111 " " "
3113 Figure 27: Supervisor Creating a Sidebar for Observing/Coaching
3115 1. Upon receipt of the sidbarByRefRequest/create from Alice to
3116 "create" a new sidebar conference from the confObjID received in
3117 the request, the conferencing system uses the received active
3118 conference to clone a conference reservation for the sidebar.
3119 The conferencing system also allocates a conference ID to be used
3120 for any subsequent protocol requests from any of the members of
3121 the conference. The conferencing system maintains the mapping
3122 between this conference ID and the confObjID associated with the
3123 sidebar reservation through the conference instance. The
3124 conference server sends a sidebarByRefResponse message with the
3125 new confObjID and relevant sidebarByRefInfo.
3127 2. Upon receipt of the sidebarByRefResponse message, Alice
3128 manipulates the data received in the sidebarByRefInfo in the
3129 response. Alice wants only Bob to be involved in the sidebar,
3130 thus she updates the to include only Bob and
3131 herself. Alice also wants the audio to be received by herself
3132 and Bob from the original conference, but wants any outgoing
3133 audio from herself to be restricted to the participants in the
3134 sidebar, whereas Bob's outgoing audio should go to the main
3135 conference, so that both Alice and the customer Carol hear the
3136 same audio from Bob. Alice sends a sidebarByRefRequest message
3137 with an "update" operation including the updated sidebar
3138 information.
3140 3. Upon receipt of the sidebarByRefRequest message with an "update"
3141 operation, the conferencing system ensures that Alice has the
3142 appropriate authority based on the policies associated with that
3143 specific conference object to perform the operation. In order to
3144 request the insertion of a further media stream in the sidebar
3145 (i.e. in this example an audio stream from Alice to Bob), the
3146 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label"
3148 attribute of that new entry is filled with a dummy value
3149 "AUTO_GENERATE_1", but it will contain the real server-generated
3150 media stream identifier when the media stream is effectively
3151 allocated on the server side. Similarly, the mandatory "id"
3152 attribute in element referring to the new sidebar audio
3153 stream under both Alice's and Bob's contains a
3154 wildcard value, respectively "AUTO_GENERATED_2" and
3155 "AUTO_GENERATED_3": those values will be replaced with the
3156 appropriated server-generated identifiers upon the creation of
3157 the referred media stream. We are assuming the conferencing
3158 control server is able to recognize those dummy values as place-
3159 holders.
3161 4. After validating the data, the conference server sends a
3162 sidebarByRefResponse message. Based upon the contact information
3163 provided for Bob by Alice, the call signaling to add Bob to the
3164 sidebar with the appropriate media characteristics is instigated
3165 through the Focus. Bob is notified of his addition to the
3166 sidebar via the conference notification service, thus he is aware
3167 that Alice, the supervisor, is available for coaching him through
3168 this call.
3170 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
3172
3173
3176
3178 xcon-userid:Alice@example.com
3179 xcon:8978383@example.com
3180 create
3181
3182
3183
3185 2. sidebarByRefResponse/create message ("success")
3187
3188
3192
3194 xcon-userid:alice@example.com
3195 xcon:8971313@example.com
3196 create
3197 success
3198 1
3199
3200
3201
3202
3203 SIDEBAR CONFERENCE registered by alice
3204
3205
3206 xcon:8971313@example.com
3207
3208
3209
3210
3211 main conference audio
3212
3213 audio
3214 sendrecv
3215
3216
3217
3218 main conference video
3219
3220 video
3221 sendrecv
3222
3223
3224
3225
3226 false
3227
3228
3229
3230
3232
3234
3236
3237
3238
3239
3240
3241
3243 3. sidebarByRefRequest/update message (Alice introduces unilateral
3244 sidebar audio and excludes Carol from the sidebar)
3246
3250
3252 xcon-userid:alice@example.com
3253 xcon:8971313@example.com
3254 update
3255
3256
3257
3258
3259 Coaching sidebar Alice and Bob
3260
3261
3262
3263
3264 Alice-to-Bob audio
3265
3266 audio
3267 sendrecv
3268
3269
3270
3271
3272 false
3273
3274
3275
3276
3278
3280
3281
3283
3284 AUTO_GENERATE_1
3285 sendonly
3286
3287
3288
3289
3291
3292 AUTO_GENERATE_1
3293 recvonly
3294
3295
3296
3297
3298
3299
3300
3301
3303 4. sidebarByRefRequest/update message ("success")
3304
3305
3309
3311 xcon-userid:alice@example.com
3312 xcon:8971313@example.com
3313 update
3314 success
3315 2
3316
3317
3318
3320 Figure 28: Coaching and Observing Messaging details
3322 8. Removing Participants and Deleting Conferences
3324 The following scenarios detail the basic operations associated with
3325 removing participants from conferences and entirely deleting
3326 conferences. The examples assume that a conference has already been
3327 correctly established, with media, if applicable, per one of the
3328 examples in Section 5.
3330 8.1. Removing a Party
3332 Figure 29 provides an example of a client, "Alice", removing another
3333 participant, "Bob", from a conference. This example assumes an
3334 established conference with Alice, Bob, "Claire" and "Duck". In this
3335 example, Alice wants to remove Bob from the conference so that the
3336 group can continue in the same conference without Bob's
3337 participation.
3339 Alice Bob Claire ConfS
3340 | | | |
3341 |(1) userRequest(confUserID,| |
3342 | confObjID, delete,| |
3343 | userInfo) | |
3344 |-------------------------------------->|
3345 | | | |
3346 | | | (a) Focus |
3347 | | | tears down|
3348 | | | signaling |
3349 | | | to Bob |
3350 | |<----------------------|
3351 | | |
3352 | | (b)Deletes+---|
3353 | | | Bob | |
3354 | | | as a | |
3355 | | | user +-->|
3356 | | | in |
3357 | | | confObj |
3358 | | | |
3359 |(2) userResponse(confUserID,confObjID, |
3360 | delete,success,version) |
3361 |<--------------------------------------|
3362 | | | |
3363 | | | |
3364 | | | (c) Notify|
3365 | | | ("Bob just|
3366 | | | left") |
3367 | | |<----------|
3368 | | | |
3369 ' ' ' '
3370 ' ' ' '
3371 ' ' ' '
3373 Figure 29: Client Manipulation of Conference - Remove a party
3375 1. Alice sends a userRequest message, with a "delete" operation.
3376 The conference server ensures that Alice has the appropriate
3377 authority based on the policies associated with that specific
3378 conference object to perform the operation.
3380 2. Based upon the contact and media information in the conference
3381 object for Bob in the "userInfo" element, the conferencing system
3382 starts the process to remove Bob (e.g., the call signaling to
3383 remove Bob from the conference is instigated through the Focus).
3384 The conference server updates the data in the conference object,
3385 thus removing Bob from the list. After updating the
3386 data, the conference server sends a userResponse message to
3387 Alice. Depending upon the policies, other participants (e.g.
3388 "Claire") may be notified of the removal of Bob from the
3389 conference via the Conference Notification Service.
3391 1. userRequest/delete message (Alice deletes Bob):
3393
3394
3398
3400 xcon-userid:Alice@example.com
3401 xcon:8977794@example.com
3402 delete
3403
3404
3405
3406
3407
3409 2. userResponse/delete message ("success")
3411
3412
3416
3418 xcon-userid:Alice@example.com
3419 xcon:8977794@example.com
3420 delete
3421 success
3422 17
3423
3424
3425
3427 Figure 30: Removing a Participant Messaging Details
3429 8.2. Deleting a Conference
3431 In this section, an example of a successful conference deletion is
3432 provided (Figure 31).
3434 Alice ConfS
3435 | |
3436 |(1)confRequest(confUserID, |
3437 | confObjID, delete) |
3438 |------------------------------>|
3439 | (a)Delete +---|
3440 | Conf | |
3441 | Object | |
3442 | +-->|
3443 | |--+ (b) MS
3444 | | | removes related
3445 | | | mixer instances and
3446 | |<-+ their participants
3447 | | (SIP signaling as well)
3448 | |
3449 |(2)confResponse(confUserID, |
3450 | confObjID,delete, |
3451 | success) |
3452 | |
3453 |<------------------------------|
3454 | |
3456 Figure 31: Deleting a conference
3458 1. The conferencing system client "Alice" sends a confRequest
3459 message with a "delete" operation to be performed on the
3460 conference identified by the XCON-URI carried in the "confObjID"
3461 parameter. The conference server, on the basis of the
3462 "confUserID" included in the receipt request, ensures that Alice
3463 has the appropriate authority to fulfill the operation.
3465 2. After validating Alice's rights, the conferencing server
3466 instigates the process to delete the conference object,
3467 disconnetting participants and removing associated resources such
3468 as mixer instances. Then, the conference server returns a
3469 confResponse message to Alice with "success" as "response-code"
3470 and the deleted conference XCON-URI in the "confObjID" field.
3472 1. confRequest/delete message (Alice deletes a conference)
3474
3475
3479
3481 xcon-userid:Alice@example.com
3482 xcon:8977794@example.com
3483 delete
3484
3485
3486
3488 2. confResponse/delete message ("success")
3490
3491
3495
3497 xcon-userid:Alice@example.com
3498 xcon:8977794@example.com
3499 delete
3500 success
3501
3502
3503
3505 Figure 32: Deleting a Conference Messaging Details
3507 9. IANA Considerations
3509 This document has no IANA considerations.
3511 10. Security Considerations
3513 The security considerations applicable to the implementation of these
3514 call flows is documented in the XCON Framework, with additional
3515 security considerations documented in the CCMP document. Where
3516 applicable, statements with regards to the necessary security are
3517 discussed in particular flows, however, since this is only an
3518 informational document, readers are strongly recommended to carefully
3519 consider the security considerations defined in the XCON Framework
3520 and the CCMP document.
3522 11. Change Summary
3524 NOTE TO THE RFC-EDITOR: Please remove this section prior to
3525 publication as an RFC.
3527 The following are the major changes between the 02 and the 03
3528 versions of the draft:
3530 o updated the call flows in order to take into account the changes
3531 on CCMP;
3533 o added a completely new introductory section, addressing the
3534 protocol in general, the data model constraints, transport-related
3535 information, and notifications in a practical way;
3537 o reorganized the chapters, grouping user-related scenarios in an
3538 users section, and doing the same for sidebars;
3540 o added more verbose text to almost every section of the document;
3542 The following are the major changes between the 01 and the 02
3543 versions of the draft:
3545 o updated the call flows in order to take into account the new
3546 versioning mechanism of the CCMP;
3548 o clarified, per agreement in Stockholm, that cloning from a
3549 blueprint does not need a cloning-parent to be made available in
3550 the response;
3552 o clarified that BFCP and CCMP-based media control are neither in
3553 conflict nor one the wrapper of the other; they act at different
3554 levels, and when both are involved, it is required that both grant
3555 a resource before it can be used by an interested participant;
3557 o changed all the domains involved in the flows to make them
3558 compliant with [RFC2606];
3560 o clarified that a successful creation of a new conference object
3561 may or may not contain the whole confInfo object in the response;
3562 in case it doesn't, a retrieve of the updated object can be
3563 achieved by issuing a confRequest/retrieve;
3565 o clarified that the scenario in Section 6.3 only involves CCMP in
3566 adding the user to a conference; this includes requiring the use
3567 of a password only in adding the user to the conference object;
3568 the actual request for PIN/Password when joining thw conference is
3569 handled by means of out-of-band mechanisms (in this case at the
3570 media level, with the help of the MEDIACTRL framework);
3572 o added and corrected Sidebars-related scenarios;
3574 o added flows for some previously missing scenarios: Private
3575 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
3576 Conference;
3578 o
3580 The following are the major changes between the 00 and the 01
3581 versions of the draft:
3583 o Updates to reflect change of CCMP to HTTP transport model.
3585 The following are the major changes between the individual 01 version
3586 to the WG 00:
3588 o Updates to reflect most recent version of CCMP, including
3589 parameter names, etc.
3591 o Added protocol details to many of the examples.
3593 o Editorial: Simplifying intro, terms, etc.
3595 12. Acknowledgements
3597 The detailed content for this document is derived from the prototype
3598 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
3599 their colleagues at the University of Napoli.
3601 13. References
3603 13.1. Normative References
3605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3606 Requirement Levels", BCP 14, RFC 2119, March 1997.
3608 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
3609 Centralized Conferencing", RFC 5239, June 2008.
3611 [I-D.ietf-xcon-ccmp]
3612 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
3613 "Centralized Conferencing Manipulation Protocol",
3614 draft-ietf-xcon-ccmp-06 (work in progress), February 2010.
3616 13.2. Informative References
3618 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
3619 Names", BCP 32, RFC 2606, June 1999.
3621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
3622 A., Peterson, J., Sparks, R., Handley, M., and E.
3623 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
3624 June 2002.
3626 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
3627 (SIP) Call Control - Conferencing for User Agents",
3628 BCP 119, RFC 4579, August 2006.
3630 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
3631 RFC 4597, August 2006.
3633 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
3634 Control Protocol (BFCP)", RFC 4582, November 2006.
3636 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
3637 Initiation Protocol (SIP) Event Package for Conference
3638 State", RFC 4575, August 2006.
3640 [I-D.ietf-xcon-event-package]
3641 Camarillo, G., Srinivasan, S., Even, R., and J.
3643 Urpalainen, "Conference Event Package Data Format
3644 Extension for Centralized Conferencing (XCON)",
3645 draft-ietf-xcon-event-package-01 (work in progress),
3646 September 2008.
3648 [I-D.ietf-xcon-common-data-model]
3649 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
3650 "Conference Information Data Model for Centralized
3651 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18
3652 (work in progress), February 2010.
3654 [I-D.ietf-mediactrl-call-flows]
3655 Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
3656 "Media Control Channel Framework (CFW) Call Flow
3657 Examples", draft-ietf-mediactrl-call-flows-03 (work in
3658 progress), February 2010.
3660 [RFC5567] Melanchuk, T., "An Architectural Framework for Media
3661 Server Control", RFC 5567, June 2009.
3663 [I-D.ietf-mediactrl-mixer-control-package]
3664 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
3665 Control Package for the Media Control Channel Framework",
3666 draft-ietf-mediactrl-mixer-control-package-11 (work in
3667 progress), February 2010.
3669 [I-D.boulton-xcon-session-chat]
3670 Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
3671 a Centralized Conferencing (XCON) System",
3672 draft-boulton-xcon-session-chat-04 (work in progress),
3673 July 2009.
3675 Authors' Addresses
3677 Mary Barnes
3678 Nortel
3679 2201 Lakeside Blvd
3680 Richardson, TX
3682 Email: mary.barnes@nortel.com
3683 Lorenzo Miniero
3684 Meetecho
3685 Via Carlo Poerio 89/a
3686 Napoli 80121
3687 Italy
3689 Email: lorenzo@meetecho.com
3691 Roberta Presta
3692 University of Napoli
3693 Via Claudio 21
3694 Napoli 80125
3695 Italy
3697 Email: roberta.presta@unina.it
3699 Simon Pietro Romano
3700 University of Napoli
3701 Via Claudio 21
3702 Napoli 80125
3703 Italy
3705 Email: spromano@unina.it