idnits 2.17.1
draft-ietf-xcon-examples-06.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 12, 2010) is 5008 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-15) exists of
draft-ietf-xcon-ccmp-09
-- 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-19
== Outdated reference: A later version (-13) exists of
draft-ietf-mediactrl-call-flows-04
== Outdated reference: A later version (-14) exists of
draft-ietf-mediactrl-mixer-control-package-11
Summary: 0 errors (**), 0 flaws (~~), 5 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 Polycom
4 Intended status: Informational L. Miniero
5 Expires: January 13, 2011 Meetecho
6 R. Presta
7 S P. Romano
8 University of Napoli
9 July 12, 2010
11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
12 draft-ietf-xcon-examples-06
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 January 13, 2011.
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 . . . . . . . . . . . . . . . . . . . . . 14
66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 14
67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 19
68 5.3. Conference Creation using User-Provided Conference
69 Information . . . . . . . . . . . . . . . . . . . . . . . 26
70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 31
71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 35
72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 35
73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 39
74 6.3. Conference Announcements and Recordings . . . . . . . . . 42
75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45
76 6.5. Entering a password-protected conference . . . . . . . . . 46
77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 48
78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 49
79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 58
80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 65
81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 69
82 8. Removing Participants and Deleting Conferences . . . . . . . . 77
83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 77
84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 80
85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 82
87 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 82
88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 84
89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 84
91 13.2. Informative References . . . . . . . . . . . . . . . . . . 84
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85
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 term
134 "Conferencing Server" is used interchangeably with the term
135 "Application Server" (AS) as used in the Media Control
136 Architectural Framework [RFC5567]. A Conferencing Server is
137 intended to be able to act as a Conference Control Server, as
138 defined in the XCON framework, i.e. it is able to handle CCMP
139 requests and issue CCMP responses.
141 Media Server (MS): as defined in the Media Control Architectural
142 Framework [RFC5567].
144 3. Overview
146 This document provides a sampling of detailed call flows that can be
147 implemented based on a system realization of the XCON framework
148 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
149 intended to be a simple guide for the use of the Conference Control
150 Protocol between the Conferencing Server and the Conference Control
151 Client. The objective is to provide an informational base reference
152 for protocol developers, software developers and researchers.
154 This document focuses on the interaction between the Conference (and
155 Media) Control Client and the Conferencing System, specifically the
156 Conferencing Server. The scenarios are based on those described in
157 the XCON framework, many of which are based on the advanced
158 conferencing capabilities described in the XCON scenarios.
159 Additional scenarios have been added to provide examples of other
160 real life scenarios that are anticipated to be supported by the
161 framework. With the exception of an initial example with media
162 control messaging, the examples do not include the details for the
163 media control [I-D.ietf-mediactrl-mixer-control-package], call
164 signaling or binary floor control [RFC4582] protocols. This document
165 references the scenarios in the Media Control call flows
166 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
167 [RFC4579] and binary floor control protocol documents.
169 The rest of this document is organized as follows. Section 4
170 presents an overview on CCMP, together with some implementation-
171 related details and related matters like HTTP transport and
172 notifications. Section 5 presents the reader with examples showing
173 the different approaches CCMP provides to create a new conference.
174 Section 6 more generally addresses the different user-related
175 manipulations that can be achieved by means of CCMP, by presenting a
176 number of interesting scenarios. Section 7 addresses the several
177 scenarios that may involve the use of sidebars. Section 8 shows how
178 CCMP can be used to remove conferences and users from the system.
179 Finally, IANA considerations are discussed in Section 9, while
180 Section 10 provides a few details for what concerns the Security
181 Considerations when it comes to implementing CCMP.
183 4. Working with CCMP
185 This section aims at being a brief introduction to how the
186 Centralized Conferencing Manipulation Protocol (CCMP)
188 [I-D.ietf-xcon-ccmp] works and how it can be transported across a
189 network. Some words will be spent to describe a typical CCMP
190 interaction, by focusing on relevant aspects of the client-server
191 communication. Please notice that this section is by no means to be
192 considered as a replacement for the CCMP document, which remains a
193 mandatory read before approaching the following sections. It is just
194 conceived to help the reader take the first steps toward the actual
195 protocol interactions.
197 First of all, some lines will be devoted to the protocol by itself in
198 Section 4.1, together with some recommendations from an
199 implementation point of view. In Section 4.2, instead, an effective
200 CCMP interaction will be presented by exploiting HTTP as a transport.
201 Finally, a few words will be spent on notifications in Section 4.3.
203 Once done with these preliminary steps, some actual flows will be
204 presented and described in detail in the sections to follow.
206 4.1. CCMP and the Data Model
208 CCMP is an XML-based protocol. It has been designed as a request/
209 response protocol. Besides, it is completely stateless, which means
210 implementations can safely handle transactions independently from
211 each other.
213 The protocol allows for the manipulation of conference objects and
214 related users. By manipulation it is implied, as the document
215 specifies, that a Conferencing Client (briefly CMCC in all the
216 following sections) can create, update and remove basically
217 everything that is related to the objects handled by a conferencing
218 system. This is reflected in the allowed operations (retrieve,
219 create, update, delete) and the specified request types (ranging from
220 the manipulation of blueprints and conferences to users and
221 sidebars). For instance, CCMP provides ways to:
223 o retrieve the list of registered and/or active conferences in the
224 system;
226 o create new conferences by exploiting to several different
227 approaches;
229 o add/remove users to/from a conference;
231 o update a conference with respect to all of its aspects;
233 and so on.
235 It is worthwile to note that, while CCMP acts as the means to
236 manipulate conference objects, its specification does not define
237 these objects as well. In fact, a separate document has been written
238 to specify how a conference object and all its components have to be
239 constructed: the Conference Information Data Model for Centralized
240 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP,
241 according to the request type and the related operation, carries
242 pieces of conference objects (or any object as a whole) according to
243 the aforementioned specification. This means that any implementation
244 aiming at being compliant with CCMP has to make sure that the
245 transported objects are completely compliant with the Data Model
246 specification and coherent with the constraints defined therein. To
247 make this clearer, there are elements that are mandatory in a
248 conference object: issuing a syntactically correct CCMP request that
249 carries a wrong conference object is doomed to result in a failure.
250 For this reason, it is suggested that the interested implementors
251 take special care in carefully checking the Data Model handlers as
252 well in order to avoid potential mistakes.
254 Of course, there are cases where a mandatory element in the Data
255 Model cannot be assigned in a conference object by a CCMP user. For
256 instance, a CMCC may be requesting the direct creation of a new
257 conference: in this case, a conference object assumes an 'entity'
258 element uniquely identifying the conference to be in place. Anyway,
259 the CMCC has no way to know a priori what the entity will be like,
260 considering it will only be generated by the ConfS after the request.
261 For scenarios like this one, the CCMP specification envisages the use
262 of a dedicated placeholder wildcard to make the conference object
263 compliant with the Data Model: the wildcard would then be replaced by
264 the ConfS with the right value.
266 4.2. Using HTTP as a transport
268 CCMP requests and responses can be transported from a client to a
269 server and viceversa through several ways, being the protocol
270 specification agnostic with respect to the transport in use.
271 Nevertheless, in [I-D.ietf-xcon-ccmp], more focus is given on HTTP as
272 a solution for this transport matter, and a whole chapter is devoted
273 in the document to how HTTP can be used for it. The following lines
274 will provide a brief explanation, from a more practical point of
275 view, of how HTTP might be exploited to carry CCMP messages. In this
276 document, however, all the call flows herein presented will just show
277 the CCMP interactions, without talking about how the messages could
278 have gone across the network.
280 In case HTTP is used as a transport, the specification is very clear
281 with respect to how the interaction has to occur. Specifically, a
282 CMCC is assumed to send his request as part of an HTTP POST message,
283 and the ConfS would reply by means of an HTTP 200 message. In both
284 cases, the HTTP messages would have the CCMP messages as payload,
285 which would be reflected in the Content-Type message (application/
286 ccmp+xml). Figure 1 presents a ladder diagram of such interaction,
287 which is followed by a dump of the exchanged HTTP messages for
288 further analysis:
290 CMCC ConfS
291 | |
292 | 1. HTTP POST (CCMP request) |
293 |--------------------------------------------->|
294 | |
295 | |--+ Parse request,
296 | | | update object
297 | |<-+ and reply
298 | |
299 | 2. 200 OK (CCMP response) |
300 |<---------------------------------------------|
301 | |
302 |--+ Parse response and |
303 | | update local copy |
304 |<-+ of conference object |
305 | |
306 . .
307 . .
309 Figure 1: CCMP on HTTP
311 As it can be seen in the protocol dump in the following lines, the
312 CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve'
313 operation) towards the Conferencing Server (ConfS). The request has
314 been carried as payload of an HTTP POST (message 1.) towards a
315 previously known location. The mandatory 'Host' header has been
316 specified, and the 'Content-Type' header has been correctly set as
317 well (application/ccmp+xml).
319 The ConfS, in turn, has handled the request and replied accordingly.
320 The response (a blueprintResponse with a successful response code)
321 has been carried as payload of an HTTP 200 OK (message 2.). As
322 before, the 'Content-Type' header has been correctly set
323 (application/ccmp+xml).
325 1. CMCC -> ConfS (HTTP POST, CCMP request)
326 ------------------------------------------
327 POST /Xcon/Ccmp HTTP/1.1
328 Content-Length: 657
329 Content-Type: application/ccmp+xml
330 Host: example.com:8080
331 Connection: Keep-Alive
332 User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
334
335
339
341 xcon-userid:Alice@example.com
342 xcon:AudioRoom@example.com
343 retrieve
344
345
346
348 2. CMCC <- ConfS (200 to POST, CCMP response)
349 ---------------------------------------------
350 HTTP/1.1 200 OK
351 X-Powered-By: Servlet/2.5
352 Server: Sun GlassFish Communications Server 1.5
353 Content-Type: application/ccmp+xml;charset=ISO-8859-1
354 Content-Length: 1652
355 Date: Thu, 04 Feb 2010 14:47:56 GMT
357
358
362
365 xcon-userid:Alice@example.com
366 xcon:AudioRoom@example.com
367 retrieve
368 200
369 success
370
371
372
373 AudioRoom
374 2
375
376
377
378 audio
379
380
381
382
383 allow
384
385
386 confirm
387
388
389
390
391
392
393
394
395
397 Just for the sake of completeness, a few words will be spent about
398 the occurred CCMP interaction as well. In fact, despite the
399 simplicity of the request, this flow already provides some relevant
400 information on how CCMP messages are built. Specifically, both the
401 request and the response share a subset of the message:
403 o confUserID: this element, provided by the CMCC, refers to the
404 requester by means of his XCON-USERID; except in a few scenarios
405 (presented in the following sections) this element must always
406 contain a valid value;
408 o confObjID: this element refers to the target conference object,
409 according to the request in place;
411 o operation: this element specifies the operation the CMCC wants to
412 perform according to the specific request type.
414 Besides those elements, the CMCC (let's say Alice, whose 'confUserID'
415 is 'xcon-userid:Alice@example.com') has also provided an additional
416 element, 'blueprintRequest'. The name of that element varies
417 according to the request type the CMCC is interested into. In this
418 specific scenario, the CMCC was interested in acquiring details
419 concerning a specific blueprint (identified by its XCON-URI
420 'xcon:AudioRoom@example.com', as reflected in the provided
421 'confObjID' target element), and so the request consisted in an empty
422 'blueprintRequest' element. As it will be clearer in the following
423 sections, different request types may require different elements and,
424 as a consequence, different content.
426 Considering the request was a 'blueprintRequest', the ConfS has
427 replied with a 'blueprintResponse' element. This element includes a
428 complete dump of the conference object (compliant with the Data
429 Model) describing the requested blueprint.
431 This section won't delve in additional details for what concerns this
432 interaction. It is just worth noticing that this was the example of
433 the simplest CCMP communication that could take place between a CMCC
434 and a ConfS, a blueprintRequest: this scenario will be described in
435 more detail in Section 5.2.
437 4.3. Conference Notifications
439 The XCON framework [RFC5239] presents several different possible
440 protocol interactions between a conferencing server and a
441 conferencing client. One of those interactions is generically called
442 "Notification Protocol", implementing a notification service for all
443 clients interested in being informed by the server whenever something
444 relevant happens in a conference. While at first glance it may
445 appear that such a functionality should belong to a conference
446 control protocol, such feature has been specifically marked as out of
447 scope in CCMP. As a consequence, CCMP has been conceived as a
448 request/answer protocol, and in fact no ways to provide notifications
449 to clients have been introduced in the specification.
451 Nevertheless, the CCMP document by itself has a brief section
452 presenting some typical ways notifications might be managed. This
453 example document does not foster one rather than another, and all the
454 flows will always generically present a notification being involved,
455 when it seems appropriate, but not providing any info on how the
456 notification itself has been sent to the interested clients. Anyway,
457 this section will briefly introduce some of the most typical ways a
458 notification service could be implemented and integrated with the
459 functionality provided by CCMP. It is by no means to be intended as
460 a complete list of solutions: the aim of this section is to provide
461 an overview of some of the possible solutions, together with
462 indications on how they may be integrated into a CCMP-based platform.
464 The first approach that comes to mind is of course the XCON Event
465 Package [I-D.ietf-xcon-event-package]. This specification extends
466 the SIP Event Package for Conference State [RFC4575] and allows for
467 the notification of conference notifications by means of the NOTIFY/
468 SUBSCRIBE mechanisms of SIP. Specifically, any SIP client who
469 subscribed for notifications related to a specific conference would
470 receive notifications via SIP describing all the changes to the
471 document. An example ladder diagram is presented in Figure 2: in
472 this figure, we assume a CMCC has updated a conference object, and
473 the update is notified to a previously subscribed SIP client.
475 CMCC ConfS UAC
476 | | |
477 | | 1. SIP SUBSCRIBE |
478 | |<--------------------------|
479 | Handle +--| |
480 | new | | |
481 | subscription +->| 2. SIP 200 OK |
482 | |-------------------------->|
483 | | |
484 . . .
485 . . .
486 | | |
487 | 3. CCMP (add user) | |
488 |---------------------->| |
489 | |--+ Add user |
490 | | | to conf. |
491 | |<-+ object |
492 | 4. CCMP (success) | |
493 |<----------------------| |
494 | | 5. SIP NOTIFY (changes) |
495 | |-------------------------->|
496 | | 6. SIP 200 OK |
497 | |<--------------------------|
498 | | |
499 . . .
500 . . .
502 Figure 2: XCON Event Package: SIP notifications
504 While simple and effective, this solution has a drawback: it assumes
505 that all clients to be notified have a SIP stack. In fact, the
506 approach relies on the SIP SUBSCRIBE/NOTIFY mechanism. This means
507 that a client without a SIP stack would be unable to receive
508 notifications, in case no other means were available. Of course this
509 is not a desired situation in a framework as XCON which has been
510 conceived as being signalling protocol-agnostic.
512 Considering CCMP is going to be probably most often deployed on HTTP,
513 another way to achieve notifications might be by exploiting some sort
514 of HTTP callbacks, as suggested in the CCMP specification itself.
515 This would allow to overcome the previous limitation, since both the
516 CMCC and the ConfS would already have an HTTP stack to make use of.
517 Using this approach, an interested web client might provide the
518 Conferencing System with an URL to contact whenever updates are
519 available: the update could be part of the notification message
520 itself, or it could be only implicitly referenced by the
521 notification. At the same time, alternative notification means could
522 be exploited, e.g. by taking advantage of functionality provided by
523 other protocols such as XMPP. Figure 3 shows an example of different
524 subscriptions which accordingly trigger notifications after the same
525 relevant event happens.
527 CMCC ConfS Sub1 Sub2
528 | | | |
529 | | 1. Register callback | |
530 | |<--------------------------| |
531 | Handle +--| | |
532 | new HTTP | | | |
533 | subscription +->| 2. Acknlowledge | |
534 | |-------------------------->| |
535 | | | |
536 | | 3. XMPP subscription |
537 | |<---------------------------------------|
538 | Handle +--| | |
539 | new XMPP | | | |
540 | subscription +->| 4. XMPP confirm subscription |
541 | |--------------------------------------->|
542 | | | |
543 . . . .
544 . . . .
545 | | | |
546 | 5. CCMP (add user) | | |
547 |-------------------->| | |
548 | |--+ Add user | |
549 | | | to conf. | |
550 | |<-+ object | |
551 | 6. CCMP (success) | | |
552 |<--------------------| | |
553 | | 7. HTTP POST (changes) | |
554 | |-------------------------->| |
555 | | 8. HTTP 200 OK | |
556 | |<--------------------------| |
557 | | | |
558 | | 9. XMPP notification | |
559 | |--------------------------------------->|
560 | | | |
561 . . . .
562 . . . .
564 Figure 3: Alternative means for notifications
566 That said, there are actually many other ways to achieve
567 notifications in a conferencing system. A conferencing system may
568 rely on several other solutions than the ones presented as periodic
569 checks of a well known URL by interested clients, long polls, BOSH-
570 based communications, Atom/RSS feeds and the like.
572 5. Conference Creation
574 This section starts the sequence of call flows of typical XCON-
575 related scenarios provided in this document. Specifically, it
576 provides details associated with the various ways in which a
577 conference can be created using CCMP and the XCON framework
578 constructs. As previously mentioned, the details of the media
579 control, call signaling and floor control protocols, where
580 applicable, are annotated in the flows without showing all the
581 details. This also applies to CCMP, whose flows are related to the
582 protocol alone, hiding any detail concerning the transport that may
583 have been used (e.g. HTTP). However, for clarification purposes,
584 the first example Section 5.1 provides the details of the media
585 control messaging along with an example of the standard annotation
586 used throughout the remainder of this document. In subsequent flows,
587 only this annotation (identified by lower case letters) is included
588 and the reader is encouraged to refer to the call flows in the
589 relevant documents for details about the other protocols. The
590 annotations for the call signaling are on the left side of the
591 conferencing server vertical bar and those for the media control
592 messaging are on the right side.
594 5.1. Basic Conference Creation
596 The simplest manner in which a conference can be created is
597 accomplished by the client sending a "confRequest" message with the
598 "create" operation as the only parameter to the conference server,
599 together with the "confUserID" associated with the requesting client
600 itself. This results in the creation of a default conference, with
601 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
602 in the form of the "confUserID" parameter (the same already present
603 in the request) and the data for the conference object in the
604 "confInfo" parameter all returned in the "confResponse" message.
605 According to the implementation of the framework, this example may
606 also add the issuing user to the conference upon creation (e.g.,
607 "method" attribute in the element of
608 may be set to "dial out" for this client, based on the particular
609 conferencing systems default). This is exactly the case depicted in
610 the figure, which is presented to enrich the scenario.
612 The specific data for the conference object are returned in the
613 "confResponse" message in the "confInfo" parameter. This allows the
614 client (with the appropriate authorization) to manipulate these data
615 and add additional participants to the conference, as well as change
616 the data during the conference. In addition, the client may
617 distribute the conferencing information to other participants
618 allowing them to join, the details of which are provided in
619 additional flows. Please notice that, according to the CCMP
620 specification, the return of the new conference data in the
621 "confInfo" parameter is not mandatory: if the "confInfo" parameter of
622 the successful confResponse/create is void, a following confRequest/
623 retrieve of the returned "confObjID" can be triggered to provide the
624 requesting client with the detailed conference description.
626 Clients that are not XCON-aware can join the conference using a
627 specific signaling interface such as SIP [RFC3261] (using the
628 signaling interface to the conference focus as described in
629 [RFC4579]), or other supported signaling protocols, being XCON
630 agnostic with respect to them. However, these details are not shown
631 in the message flows. The message flows in this document identify
632 the point in the message flows at which this signaling occurs via the
633 lower case letter items (i.e., (a)...(x)) along with the appropriate
634 text for the processing done by the conferencing server.
636 As anticipated at the beginning of this section, this example also
637 shows how the conferencing system may make use of other standard
638 components to make available its functionality. An example of that
639 is the MEDIACTRL specification, which allows the conferencing system
640 to configure conference mixes, IVR dialogs and all sort of media-
641 related interactions an application like this may need. So, just to
642 provide the reader with some insight on these interactions, the
643 conferencing system also configures and starts a mixer via MEDIACTRL
644 as soon as the conference is created (transactions A1 and A2), and
645 attaches clients to it when necessary (e.g. when CMCC1 joins the
646 conference by means of SIP signaling, its media channels are attached
647 to the Media Server using MEDIACTRL in B1/B2).
649 CMCC1 CMCC2 CMCCx ConfS MS
650 | | | | |
651 |(1)confRequest(confUserID, create) | |
652 |-------------------------------------->| |
653 | | (a)Create +---| |
654 | | |Conf | | |
655 | | |Object | | |
656 | | |& IDs +-->| |
657 | | | | A1. CONTROL |
658 | | | |+++++++++++>>|
659 | | | |(create conf)|--+ (b)
660 | | | | | | create
661 | | | | | | conf and
662 | | | | A2. 200 OK |<-+ its ID
663 | | | |<<+++++++++++|
664 | | | |(confid=Y) |
665 |(2)confResponse(confUserID,confObjID, | |
666 | create, 200, success, | |
667 | version, confInfo) | |
668 |<--------------------------------------| |
669 | | | | |
670 | | (c) Focus +---| |
671 | | sets up | | |
672 | | signaling | | |
673 | | to CMCC1 +-->| |
674 | | | | |
675 | | | | B1. CONTROL |
676 | | | |+++++++++++>>|
677 | | | | (join CMCC1 |
678 | | | | <->confY) |
679 | | | | |
680 | | | | |--+(d) join
681 | | | | | | CMCC1 &
682 | | | | B2.200 OK |<-+ conf Y
683 | | | |<<+++++++++++|
684 | | | | |
685 |<<#################################################>>|
686 | Now the CMCC1 is mixed in the conference |
687 |<<#################################################>>|
688 | | | | |
689 |******CMCC1 may then manipulate conference data *****|
690 |****** and add addt'l users, etc. | *****|
691 ' ' ' ' '
692 ' ' ' ' '
693 ' ' ' ' '
694 Figure 4: Create Basic Conference - Complete flow
696 "Alice" "Bob"
697 CMCC1 CMCC2 CMCCx ConfS
698 | | | |
699 |(1)confRequest(confUserID, create) |
700 |-------------------------------------->|
701 | | | |
702 | | (a)Create +---|
703 | | |Conf | |
704 | | |Object | |
705 | | |& IDs +-->|
706 | | | |--+ (b) MS
707 | | | | | creates
708 | | | | | conf and
709 | | | |<-+ its ID
710 | | | | (confid=Y)
711 |(2)confResponse(confUserID, confObjID |
712 | create, 200, success, |
713 | version, confInfo) |
714 | | | |
715 |<--------------------------------------|
716 | | | |
717 | | | |
718 | | (c) Focus +---|
719 | | sets up | |
720 | | signaling | |
721 | | to CMCC1 +-->|
722 | | | |
723 | | | |--+(d) MS joins
724 | | | | | CMCC1 &
725 | | | |<-+ conf Y
726 |<<###################################>>|
727 | CMCC1 is mixed in the conference |
728 |<<###################################>>|
729 | | | |
730 |**CMCC1 then manipulates conference****|
731 |** data and add addt'l users, etc. ***|
732 ' ' ' '
733 ' ' ' '
734 ' ' ' '
735 -
737 Figure 5: Create Basic Conference - Annotated Flow
739 1. confRequest/create message (Alice creates a default conference)
741
742
746
749 xcon-userid:Alice@example.com
750 create
751
752
753
755 2. confResponse/create message ("success", created conference
756 object returned)
758
759
763
766 xcon-userid:Alice@example.com
767 xcon:8977794@example.com
768 create
769 200
770 success
771 1
772
773
774
775
776 Default conference initiated by Alice
777
778
779
780
781 xcon:8977794@example.com
782
783
784 Conference XCON-URI
785
787
788
789 10
790
791
792
793 audio
794
795
796
797 false
798
799
800
801 allow
802
803
805
806
807
808
809
810
812 Figure 6: Create Basic Conference (Annotated) Detailed Messaging
814 5.2. Conference Creation using Blueprints
816 The previous example showed the creation of a new conference using
817 default values. This means the client provided no information about
818 how she wanted the conference to be like. Anyway, the XCON framework
819 (and CCMP as a consequence) allows for the exploitation of templates.
820 These templates are called "conference blueprints", and are basically
821 conference objects with pre-defined settings. This means that a
822 client might get one of these blueprints, choose the one that more
823 fits his needs, and use the chosen blueprint to create a new
824 conference.
826 This section addresses exactly this scenario, and Figure 7 provides
827 an example of one client, "Alice", discovering the conference
828 blueprints available for a particular conferencing system and
829 creating a conference based on the desired blueprint. In particular,
830 Alice is interested in those blueprints suitable to represent a
831 "video-conference", i.e. a conference in which both audio and video
832 are available, so she exploits the filter mechanism envisioned by
833 CCMP to make a selective blueprints retrieve request. This results
834 in three distinct CCMP transactions.
836 CMCC "Alice" ConfS
837 | |
838 | (1) blueprintsRequest |
839 | (confUserID,xpathFilter) |
840 |------------------------------>|
841 | |
842 | (2) blueprintsResponse |
843 | (confUserID, |
844 | 200, success, |
845 | blueprintsInfo) |
846 | |
847 |<------------------------------|
848 | |
849 |--+ |
850 | | choose preferred |
851 | | blueprint from the |
852 | | list (blueprintName) |
853 |<-+ |
854 | |
855 | (3) blueprintRequest |
856 | (confUserID,confObjID, |
857 | retrieve) |
858 |------------------------------>|
859 | |
860 | 4) blueprintResponse |
861 | (confUserID,confObjID,|
862 | retrieve, 200, |
863 | success, confInfo) |
864 |<------------------------------|
865 | |
866 | (5) confRequest(confUserID, |
867 | confObjID,create) |
868 |------------------------------>|
869 | |
870 | (a)Create +---|
871 | Conf | |
872 | Object | |
873 | & IDs +-->|
874 | |--+ (b) MS
875 | | | creates
876 | | | conf and
877 | |<-+ its ID
878 | | (confid=Y)
879 |(6) confResponse |
880 | (confUserID, confObjID*, |
881 | create, 200, success) |
882 |<------------------------------|
883 | |
884 | |
885 | |
886 . .
887 . .
889 Figure 7: Client Creation of Conference using Blueprints
891 1. Alice first sends a "blueprintsRequest" message to the
892 conferencing system identified by the conference server discovery
893 process. This request contains the "confUserID" of the user
894 issuing the request (Alice's XCON-USERID) and the "xpathFilter"
895 parameter by which Alice specifies she desires to obtain only
896 blueprints providing support for both audio and video: for this
897 purpose, the xpath query contained in this field is: "/
898 conference-info[conference-description/available-media/entry/
899 type='audio' and conference-description/available-media/entry/
900 type='video'"] . Upon receipt of the "blueprintsRequest", the
901 conferencing system would first control, on the basis of the
902 "confUserID" parameter, that Alice has the appropriate authority
903 based on system policies to receive the requested kind of
904 blueprints supported by that system.
906 2. All blueprints that Alice is authorized to use are returned in a
907 "blueprintsResponse" message in the "blueprintsInfo" element.
909 3. Upon receipt of the "blueprintsResponse" containing the
910 blueprints, Alice determines which blueprint to use for the
911 conference to be created. Alice sends a "blueprintRequest"
912 message to get the specific blueprint as identified by the
913 "confObjID".
915 4. The conferencing system returns the "confInfo" associated with
916 the specific blueprint as identified by the "confObjID" in the
917 "blueprintResponse" message.
919 5. Alice finally sends a "confRequest" with a "create" operation to
920 the conferencing system to create a conference reservation
921 cloning the chosen blueprint. This is achieved by writing the
922 blueprint's XCON-URI in the "confObjID" parameter.
924 6. Upon receipt of the "confRequest" message with a "create"
925 operation, the conferencing system uses the received blueprint to
926 clone a conference, allocating a new XCON-URI (again called
927 "confObjID*" in the example). The conferencing server then sends
928 a "confResponse" message including the new "confObjID*"
929 associated with the newly created conference instance. Upon
930 receipt of the "confResponse" message, Alice can now add other
931 users to the conference .
933 1. blueprintsRequest message (Alice requires the list of the
934 available blueprints with video support)
936
937
941
944 xcon-userid:Alice@example.com
945
946 /conference-info
947 [conference-description/
948 available-media/entry/type='audio' and
949 conference-description/available-media/
950 entry/type='video']
951
952
953
954
956 2. blueprintsResponse message (the server provides a
957 descriptions of the available blueprints
958 fitting Alice's request)
960
961
965
968 xcon-userid:Alice@example.com
969 200
970 success
971
972
973
974 xcon:VideoRoom@example.com
975 VideoRoom
976 Video Room:
977 conference room with public access,
978 where both audio and video are available,
979 4 users can talk and be seen at the same time,
980 and the floor requests are automatically accepted.
981
982
983
984 xcon:VideoConference1@example.com
985
986 VideoConference1
987
988 Public Video Conference: conference
989 where both audio and video are available,
990 only one user can talk
991
992
993
994
995
996
998 3. blueprintRequest/retrieve message (Alice wants the
999 "VideoRoom" blueprint)
1001
1002
1006
1009 xcon-userid:Alice@example.com
1010 xcon:VideoRoom@example.com
1011 retrieve
1012
1013
1015
1017 4. blueprintResponse/retrieve message ("VideoRoom"
1018 conference object returned)
1020
1021
1025
1028 xcon-userid:Alice@example.com
1029 xcon:VideoRoom@example.com
1030 retrieve
1031 200
1032 success
1033
1034
1035
1036 VideoRoom
1037 4
1038
1039
1040 audio
1041
1042
1043 video
1044
1045
1046
1047
1048 allow
1049
1050
1051 confirm
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1063 5. confRequest/create message (Alice clones the "VideoRoom" blueprint)
1065
1066
1070
1073 xcon-userid:Alice@example.com
1074 xcon:VideoRoom@example.com
1075 create
1076
1077
1078
1080 6. confResponse/create message (cloned conference
1081 object returned)
1083
1084
1088
1091 xcon-userid:Alice@example.com
1092 xcon:8977794@example.com
1093 create
1094 200
1095 success
1096 1
1097
1098
1099
1100
1101 New conference by Alice cloned from VideoRoom
1102
1103
1104
1105
1106 xcon:8977794@example.com
1107
1108
1109 conference xcon-uri
1111
1112
1113 8601
1114
1115
1116
1117 10
1118
1119
1120
1121 audio
1122
1123
1124 video
1125
1126
1127
1128
1129 allow
1130
1131
1132
1133 confirm
1134
1135
1136
1137
1138
1139
1140
1141
1142
1144 Figure 8: Create Conference (Blueprint) Detailed Messaging
1146 5.3. Conference Creation using User-Provided Conference Information
1148 A conference can also be created by the client sending a
1149 "confRequest" message with the "create" operation, along with the
1150 desired data in the form of the "confInfo" parameter for the
1151 conference to be created. The request also includes the "confUserID"
1152 of the requesting entity.
1154 This approach allows for a client (in this example Alice) to
1155 completely describe how the conference object should look like,
1156 without just relying on defaults or blueprints: i.e. which media
1157 should be available, which should be the topic, the users allowed to
1158 join, any scheduling-related information and so on. This can be
1159 done, as anticipated, by providing in the creation request a full
1160 conference object for the server to parse.
1162 This "confInfo" parameter must comply of course with the Data Model
1163 specification. This means that its "entity" attribute is mandatory,
1164 and cannot be missing in the document. Nevertheless, considering in
1165 this example the client is actually requesting the creation of a new
1166 conference, which doesn't exist yet, this "entity" attribute cannot
1167 be set to a valid value. This is related to an issue already
1168 anticipated in Section 4.1. To cope with this, the CCMP protocol
1169 fosters the use of a wildcard placeholder: this placeholder
1170 ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim
1171 of making the "confInfo" element compliant with the Data Model, and
1172 would subsequently be replaced by the conferencing system with the
1173 actual value. This means that, as soon as the conferencing system
1174 actually creates the conference, a valid "entity" value is created
1175 for it as well, which would take the place of the wildcard when
1176 completing the actual conference object provided by the client.
1178 To give a flavour of what could be added to the conference object, we
1179 assume Alice is also interested in providing scheduling-related
1180 information. So, in this example, Alice also specifies by the
1181 element included in the "confInfo" that the
1182 conference she wants to create has to occur on a certain date
1183 spanning from a certain start time to a certain stop time and has to
1184 be replicated weekly.
1186 Moreover, Alice indicates by means of the that
1187 at the start time Bob, Carol and herself have to be called by the
1188 conferencing system to join the conference (in fact, for each
1189 corresponding to one of the above-mentioned clients, the
1190 "method" attribute is set to "dial-out").
1192 Once Alice has prepared the "confInfo" element and sent it as part of
1193 her request to the server, if the conferencing system can support
1194 that specific type of conference (capabilities, etc.), then the
1195 request results in the creation of a conference. We assume the
1196 request has been successful, and as a consequence XCON-URI in the
1197 form of the "confObjID" parameter and the XCON-USERID in the form of
1198 the "confUserID" parameter (again, the same as the requesting entity)
1199 are returned in the "confResponse" message.
1201 In this example, we choose not to return the created conference
1202 object in the successful "confResponse" in the "confInfo" parameter.
1203 Nevertheless, Alice could still retrieve the actual conference object
1204 by issuing a "confRequest" with a "retrieve" operation on the
1205 returned "confObjID". Such a request would show how, as we
1206 anticipated at the beginning of this section, the "entity" attribute
1207 of the conference object in "confInfo" is replaced with the actual
1208 information (i.e. "xcon:6845432@example.com").
1210 Alice Bob Carol ConfS
1211 | | | |
1212 | | | |
1213 |(1)confRequest(confUserID, | |
1214 | create, confInfo) | |
1215 | | | |
1216 |-------------------------------------->|
1217 | | | |
1218 | | (a)Create +---|
1219 | | |Conf | |
1220 | | |Object | |
1221 | | |& IDs +-->|
1222 | | | |--+ (b) MS
1223 | | | | | creates
1224 | | | | | conf and
1225 | | | |<-+ its ID
1226 | | | | (confid=Y)
1227 |(2)confResponse(confUserID,| |
1228 | confObjID, create, | |
1229 | 200, success, version) |
1230 |<--------------------------------------|
1231 | | | |
1232 ===========================================
1233 ... ... ... ...
1234 ========== START TIME OCCURS ==============
1235 | | (c) Focus +---|
1236 | | sets up | |
1237 | | signaling | |
1238 | | to Alice +-->|
1239 | | | |
1240 | | | |--+(d) MS joins
1241 | | | | | Alice &
1242 | | | |<-+ conf Y
1243 | | | |
1244 | | | |
1245 |<<###################################>>|
1246 | Alice is mixed in the conference |
1247 |<<###################################>>|
1248 | | | |
1249 | | (e)Focus +---|
1250 | | sets up | |
1251 | | signaling | |
1252 | | to Bob | |
1253 | | | +-->|
1254 | | | |
1255 | | | |--+(f)MS joins
1256 | | | | | Bob &
1257 | | | |<-+ conf Y
1258 | | | |
1259 | |<<###################>>|
1260 | | Bob is mixed too |
1261 | |<<###################>>|
1262 | | | |
1263 | | (g )Focus +---|
1264 | | sets up | |
1265 | | signaling | |
1266 | | to Carol | |
1267 | | CMCCx +-->|
1268 | | | |
1269 | | | |--+(h)MS joins
1270 | | | | | CMCCx &
1271 | | | |<-+ conf Y
1272 | | | |
1273 | | |<<#######>>|
1274 | | |Carol mixed|
1275 | | |<<#######>>|
1276 | | | |
1277 | | | |
1278 | | | |
1279 |<***All parties connected to conf Y***>|
1280 | | | |
1281 | | | |
1282 " " " "
1283 " " " "
1284 " " " "
1286 Figure 9: Create Basic Conference from user provided conference-info
1288 1. confRequest/create message (Alice proposes a conference object
1289 to be created)
1291
1292
1297
1300 xcon-userid:Alice@example.com
1301 create
1302
1303
1304
1305
1306 Dial-out conference initiated by Alice
1307
1308 10
1309
1310
1311
1312 audio
1313
1314
1315
1316
1317
1318 BEGIN:VCALENDAR
1319 VERSION:2.0
1320 PRODID:-//Mozilla.org/NONSGML
1321 Mozilla Calendar V1.0//EN
1322 BEGIN:VEVENT
1323 DTSTAMP: 20100127T140728Z
1324 UID: 20100127T140728Z-345FDA-alice@example.com
1325 ORGANIZER:MAILTO:alice@example.com
1326 DTSTART:20100127T143000Z
1327 RRULE:FREQ=WEEKLY
1328 DTEND: 20100127T163000Z
1329 END:VEVENT
1330 END:VCALENDAR
1331
1332
1334 2010-01-27T14:29:00Z
1335
1336
1338 2010-01-27T16:31:00Z
1339
1340
1341 2010-01-27T15:30:00Z
1342
1343
1344
1346
1347
1348 allow
1349
1350
1352
1354
1356
1357
1358
1359
1360
1361
1363 2. confResponse/create message (200, "success")
1365
1366
1370
1373 xcon-userid:Alice@example.com
1374 xcon:6845432@example.com
1375 create
1376 200
1377 success
1378 1
1379
1380
1382 Figure 10: Create Basic Conference Detailed Messaging
1384 5.4. Cloning an Existing Conference
1386 A client can also create another conference by cloning an existing
1387 conference, such as an active conference or conference reservation.
1388 This approach can be seen as a logical extension of the creation of a
1389 new conference using a blueprint: the difference is that, instead of
1390 cloning the pre-defined settings listed in a blueprint, the settings
1391 of an existing conference would be cloned.
1393 In this example, the client sends a "confRequest" message with the
1394 "create" operation, along with the "confUserID" and a specific
1395 "confObjID", from which a new conference is to be created by cloning
1396 an existing conference.
1398 An example of how a client can create a conference based on a
1399 blueprint is provided in Section 5.2. The manner by which a client
1400 in this example might learn about a conference reservation or active
1401 conferences is similar to the first step in the blueprint example,
1402 with the exception of querying for different types of conference
1403 objects supported by the specific conferencing system. For example,
1404 in this example, the client clones a conference reservation (i.e., an
1405 inactive conference).
1407 If the conferencing system can support a new instance of the specific
1408 type of conference (capabilities, etc.), then the request results in
1409 the creation of a conference, with an XCON-URI in the form of a new
1410 value in the "confObjID" parameter to reflect the newly cloned
1411 conference object returned in the "confResponse" message.
1413 Alice ConfS
1414 | |
1415 |(1)confRequest(confUserID, |
1416 | confObjID, create) |
1417 |------------------------------>|
1418 | (a)Create +---|
1419 | Conf | |
1420 | Object | |
1421 | & IDs +-->|
1422 | |--+ (b) MS
1423 | | | creates
1424 | | | conf and
1425 | |<-+ its ID
1426 | | (confid=Y)
1427 | |
1428 |(2)confResponse(confUserID, |
1429 | confObjID*,create, |
1430 | 200, success, |
1431 | version, confInfo) |
1432 | |
1433 |<------------------------------|
1434 | |
1435 Figure 11: Create Basic Conference - Clone
1437 1. Alice, a conferencing system client, sends a confRequest message
1438 to clone a conference based on an existing conference
1439 reservation. Alice indicates this conference should be cloned
1440 from the specified parent conference represented by the
1441 "confObjID" in the request.
1443 2. Upon receipt of the confRequest message containing a "create"
1444 operation and "confObjID", the conferencing system ensures that
1445 the "confObjID" received is valid. The conferencing system
1446 determines the appropriate read/write access of any users to be
1447 added to a conference based on this "confObjID" (using
1448 membership, roles, etc.). The conferencing system uses the
1449 received "confObjID" to clone a conference reservation. The
1450 conferencing system also reserves or allocates a new "confObjID"
1451 (called "confObjID*" in Figure 11) to be used for the cloned
1452 conference object. This new identifier is of course different
1453 from the one associated with the conference to be cloned, since
1454 it represents a different conference object. Any subsequent
1455 protocol requests from any of the members of the conference must
1456 use this new identifier. The conferencing system maintains the
1457 mapping between this conference ID and the parent conference
1458 object ID associated with the reservation through the conference
1459 instance, and this mapping is explicitly addressed through the
1460 "cloning-parent" element of the "conference-description" in the
1461 new conference object.
1463 1. confRequest/create message (Alice clones an existing conference)
1465
1466
1470
1473 xcon-userid:Alice@example.com
1474 xcon:6845432@example.com
1475 create
1476
1477
1479 2. confResponse/create message (created conference
1480 object returned)
1482
1483
1487
1490 xcon-userid:Alice@example.com
1491 xcon:8977794@example.com
1492 create
1493 200
1494 success
1495 1
1496
1497
1498
1499
1500 New conference by Alice cloned from 6845432
1501
1502
1503 xcon:6845432@example.com
1504
1505 10
1506
1507
1508
1509 audio
1510
1511
1512
1513
1514 allow
1515
1516
1518
1520
1522
1523
1524
1525
1526 confirm
1528
1529
1530
1531
1532
1533
1534
1535
1537 Figure 12: Create Basic Conference (Clone) Detailed Messaging
1539 6. Conference Users Scenarios and Examples
1541 Section 5 showed examples describing the several different ways a
1542 conference might be created using CCMP. This section instead focuses
1543 on user-related scenarios, i.e. typical scenarios that may occur
1544 during the lifetime of a conference, like adding new users and
1545 handling their media. The following scenarios are based on those
1546 documented in the XCON framework. The examples assume that a
1547 conference has already been correctly established, with media, if
1548 applicable, per one of the examples in Section 5.
1550 6.1. Adding a Party
1552 In this example, Alice wants to add Bob to an established conference.
1553 In the following example we assume Bob is a new user of the system,
1554 which means Alice also needs to provide some details about him. In
1555 fact, the case of Bob already present as a user in the conferencing
1556 system is much easier to address, and will be discussed later on.
1558 "Alice" "Bob"
1559 CMCC1 CMCC2 CMCCx ConfS
1560 | | | |
1561 |(1) userRequest(confUserID,| |
1562 | confObjID, create, | |
1563 | userInfo) | | |
1564 |-------------------------------------->|
1565 | | | |
1566 | | (a) Create +---|
1567 | | | Bob | |
1568 | | | as a | |
1569 | | | user +-->|
1570 | | | |
1571 |(2) userResponse(confUserID, confObjID |
1572 | create, 200, success, userInfo) |
1573 |<--------------------------------------|
1574 | | | |
1575 | | | (b) Focus |
1576 | | | sets up |
1577 | | | signaling |
1578 | | | to Bob |
1579 | |<----------------------|
1580 | | | |
1581 | | | (c) Notify|
1582 | | | ("Bob just|
1583 | | | joined") |
1584 | | |<----------|
1585 | | | |
1586 ' ' ' '
1587 ' ' ' '
1588 ' ' ' '
1590 Figure 13: Client Manipulation of Conference - Add a party
1592 1. Alice sends a userRequest message with an operation of "create"
1593 to add Bob to the specific conference as identified by the
1594 "confObjID". The "create" operation also makes sure that Bob is
1595 created as a user in the whole conferencing system. This is done
1596 by adding in the request a "userInfo" element describing Bob as a
1597 user. This is needed in order to let the conferencing system be
1598 aware of Bob's characteristics. In case Bob was already a
1599 registered user, Alice would just have referenced him through his
1600 XCON-USERID in the "entity" attribute of the "userInfo" field,
1601 without providing additional data. In fact, that data
1602 (including, for instance, Bob's SIP-URI to be used subsequently
1603 for dial-out) would be obtained by referencing the extant
1604 registration. The conference server ensures that Alice has the
1605 appropriate authority based on the policies associated with that
1606 specific conference object to perform the operation. As
1607 mentioned before, a new Conference User Identifier is created for
1608 Bob, and the "userInfo" is used to update the conference object
1609 accordingly. As already seen in Section 5.3, a placeholder
1610 wildcard ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP
1611 messages below) is used for the "entity" attribute of the
1612 "userInfo" element, to be replaced by the actual XCON-USERID
1613 later on;
1615 2. Bob is successfully added to the conference object, and an XCON-
1616 USERID is allocated for him ("xcon-userid:Bob@example.com"); this
1617 identifier is reported in the response as part of the "entity"
1618 element of the returned "userInfo";
1620 3. In the presented example, the call signaling to add Bob to the
1621 conference is instigated through the Focus as well. We again
1622 remind that this is implementation specific. In fact, a
1623 conferencing system may accomplish different actions after the
1624 user creation, just as it may do nothing at all. Among the
1625 possible actions, for instance, Bob may be added as a
1626 element to the element, whose joining
1627 "method" may be either "dial-in" or "dial-out". Besides, out-of-
1628 band notification mechanisms may be involved as well, e.g. to
1629 notify Bob via mail of the new conference, including details as
1630 the date, password, expected participants and so on (see
1631 Section 4.3).
1633 To conclude the overview on this scenario, once Bob has been
1634 successfully added to the specified conference, per updates to the
1635 state, and depending upon the policies, other participants
1636 (including Bob himself) may be notified of the addition of Bob to
1637 the conference via the Conference Notification Service in use.
1639 1. userRequest/create message (Alice adds Bob)
1641
1642
1646
1649 xcon-userid:Alice@example.com
1650 xcon:8977878@example.com
1651 create
1652
1653
1654 Bob
1655
1656
1657 mailto:bob.depippis@example.com
1658
1659 Bob's email
1660
1661
1662
1663
1664 Bob's laptop
1665
1666
1667
1668
1669
1670
1672 2. userResponse/create message (a new XCON-USERID is
1673 created for Bob and he is added to the conference)
1675
1676
1680
1683 xcon-userid:Alice@example.com
1684 xcon:8977878@example.com
1685 create
1686 200
1687 success
1688 10
1689
1690
1691 Bob
1692
1693
1694 mailto:bob.depippis@example.com
1695
1696 Bob's email
1697
1699
1700
1701
1702 Bob's laptop
1703
1704
1705
1706
1707
1708
1710 Figure 14: Add Party Message Details
1712 6.2. Muting a Party
1714 This section provides an example of the muting of a party in an
1715 active conference. We assume that the user to mute has already been
1716 added to the conference. The document only addresses muting and not
1717 unmuting as well, since it would involve an almost identical CCMP
1718 message flow anyway. Although, in case that any external floor
1719 control is involved, whether or not a particular conference client
1720 can actually mute/unmute itself must be considered by the
1721 conferencing system.
1723 Please notice that interaction between CCMP and floor control
1724 should be carefully considered. In fact, handling CCMP- and BFCP-
1725 based media control has to be considered as multiple layers: i.e.,
1726 a participant may have the BFCP floor granted, but be muted by
1727 means of CCMP. If so, he would still be muted in the conference,
1728 and would only be unmuted if both the protocols allowed for this.
1730 Figure 15 provides an example of one client, "Alice", impacting the
1731 media state of another client, "Bob". This example assumes an
1732 established conference. In this example, Alice, whose role is
1733 "moderator" of the conference, wants to mute Bob on a medium-size
1734 multi-party conference, as his device is not muted (and he's
1735 obviously not listening to the call) and background noise in his
1736 office environment is disruptive to the conference. BFCP floor
1737 control is assumed not to be involved.
1739 From a protocol point of view, muting/unmuting an user basically
1740 consists in updating the conference object by modifying the settings
1741 related to the target user's media streams. Specifically, Bob's
1742 "userInfo" must be updated by modifying its audio
1743 information (e.g. setting it to "recvonly" in case of muting),
1744 identified by the right media id.
1746 "Alice" "Bob"
1747 CMCC1 CMCC2 CMCCx ConfS MS
1748 | | | | |
1749 |(1) userRequest(subject, | | |
1750 | confUserID,confObjID, | | |
1751 | update,userInfo) | | |
1752 | | | | |
1753 |--------------------------------------->| |
1754 | | | | Mute Bob |
1755 | | | |----------------->|
1756 | | | | 200 OK |
1757 | | | |<-----------------|
1758 | | | | |
1759 | |<====== XXX Bob excluded from mix XXX ====>|
1760 | | | | |
1761 | | (a) Update +---| |
1762 | | Bob in | | |
1763 | | Data Model | | |
1764 | | (muted) +-->| |
1765 | | | | |
1766 | (2)userResponse(confUserID,confObjID, | |
1767 | update,200,success,version) | |
1768 |<---------------------------------------| |
1769 | | | | |
1770 | | | (b) Notify | |
1771 | | | ("Bob is | |
1772 | | | muted") | |
1773 | | |<-----------| |
1774 | | | | |
1775 ' ' ' ' '
1776 ' ' ' ' '
1777 ' ' ' ' '
1779 Figure 15: Client Manipulation of Conference - Mute a party
1781 1. Alice sends a userRequest message with an "update" operation and
1782 the userInfo with the "status" field in the "media" element for
1783 Bob's set to "revconly". In order to authenticate
1784 herself, Alice provides in the "subject" request parameter her
1785 registration credentials (i.e. username and password). The
1786 "subject" parameter is an optional one: its use can be systematic
1787 whenever the conferencing server envisages to authenticate each
1788 requestor. In such cases, if the client does not provide the
1789 required authentication information, the conferencing server
1790 answers with a CCMP "authenticationRequired" response message,
1791 indicating that the request cannot be processed without including
1792 the proper "subject" parameter. The Conference Server ensures
1793 that Alice has the appropriate authority based on the policies
1794 associated with that specific conference object to perform the
1795 operation. It recognizes that Alice is allowed to request the
1796 specified modification, since she is moderator of the target
1797 conference, and updates the "userInfo" in the conference object
1798 reflecting that Bob's media is not to be mixed with the
1799 conference media. In case the Conference Server relies on a
1800 remote Media Server for its multimedia functionality, it
1801 subsequently changes Bob's media profile accordingly by means of
1802 the related protocol interaction with the MS to enforce the
1803 decision. An example describing a possible way of dealing with
1804 such a situation using the Media Server Control architecture is
1805 described in [I-D.ietf-mediactrl-call-flows], at "Simple
1806 Bridging: Framework Transactions (2)".
1808 2. A userResponse message with a "200" response-code ("success") is
1809 then sent to Alice. Depending upon the policies, the conference
1810 server may notify other participants (including Bob) of this
1811 update via any Conference Notification Service that may be in
1812 use.
1814 1. userRequest/update message (Alice mutes Bob)
1816
1817
1821
1824
1825 Alice83
1826 13011983
1827
1828 xcon-userid:Alice@example.com
1829 xcon:8977878@example.com
1830 update
1831
1832
1833
1834
1835 123
1836 recvonly
1837
1839
1840
1841
1842
1843
1844
1846 2. userResponse/update message (Bob has been muted)
1848
1849
1853
1856 xcon-userid:Alice@example.com
1857 xcon:8977878@example.com
1858 update
1859 200
1860 success
1861 7
1862
1863
1864
1866 Figure 16: Mute Message Details
1868 6.3. Conference Announcements and Recordings
1870 This section deals with features that are typically required in a
1871 conferencing system, that are public announcements (e.g. to notify
1872 vocally that a new user joined a conference) and name recording.
1873 While this is not strictly CCMP-related (the CCMP signaling is
1874 actually the same as the one seen in Section 6.1) it is an
1875 interesting scenario to address to see how the several components of
1876 an XCON-compliant architecture interact with each other to make it
1877 happen.
1879 In this example, as shown in Figure 17 Alice is joining Bob's
1880 conference that requires that she first enters a pass code. After
1881 successfully entering the pass code, an announcement prompts Alice to
1882 speak her name so it can be recorded. When Alice is added to the
1883 active conference, the recording is played back to all the existing
1884 participants. A very similar example is presented in Figure 33 of
1885 [I-D.ietf-mediactrl-call-flows].
1887 CMCC "Alice" ConfS MS
1888 | | |
1889 |(1)userRequest(confObjID, | |
1890 | create,userInfo) | |
1891 |--------------------------->| |
1892 | |--+ Alice is |
1893 | | | new in the |
1894 | |<-+ system (create |
1895 | | confUserID) |
1896 | ConfS handles +--| |
1897 | SIP signaling | | |
1898 | (Alice<->ConfS<->MS) +->| |
1899 | | |
1900 | |--+ A password is |
1901 | | | required for |
1902 | |<-+ that conference |
1903 | | |
1904 | | Request IVR menu (PIN) |
1905 | |--------------------------->|
1906 | | |
1907 |<========= MS gets PIN from Alice through DTMF =========>|
1908 | | |
1909 | | Provided PIN is... |
1910 | |<---------------------------|
1911 | Check +--| |
1912 | PIN | | |
1913 | +->| |
1914 | |--+ Alice must |
1915 | | | record her |
1916 | |<-+ name |
1917 | | |
1918 | | Request name recording |
1919 | |--------------------------->|
1920 | | |
1921 |<========= MS records Alice's audio RTP (name) =========>|
1922 | | |
1923 | | Audio recording |
1924 | |<---------------------------|
1925 | Complete +--| |
1926 | creation | | |
1927 | of Alice +->| |
1928 | | |
1929 | | |
1930 | (2)userResponse(confUserID,| |
1931 | confObjID,create,200,| |
1932 | success,version) | |
1933 |<---------------------------| |
1934 | | |
1935 Figure 17: Recording and Announcements
1937 1. Upon receipt of the userRequest from Alice to be added to Bob's
1938 conference, the conferencing system determines that a password is
1939 required for this specific conference. Thus an announcement
1940 asking Alice to enter the password is sent back. This may be
1941 achieved by means of typical IVR functionality. Once Alice
1942 enters the password, it is validated against the policies
1943 associated with Bob's active conference. The conferencing system
1944 then connects to a server which prompts and records Alice's name.
1945 The conferencing system must also determine whether Alice is
1946 already a user of this conferencing system or whether she is a
1947 new user. In this case, Alice is a new user for this
1948 conferencing system, so a Conference User Identifier (i. e. an
1949 XCON-USERID) is created for Alice. Based upon the contact
1950 information provided by Alice, the call signaling to add Alice to
1951 the conference is instigated through the Focus.
1953 2. The conference server sends Alice a userResponse message which
1954 includes the "confUserID" assigned by the conferencing system to
1955 her. This would allow Alice to later perform operations on the
1956 conference (if she were to have the appropriate policies),
1957 including registering for event notifications associated with the
1958 conference. Once the call signaling indicates that Alice has
1959 been successfully added to the specific conference, per updates
1960 to the state, and depending upon the policies, other participants
1961 (e.g., Bob) are notified of the addition of Alice to the
1962 conference via the conference notification service and an
1963 announcement is provided to all the participants indicating that
1964 Alice has joined the conference.
1966 1. userRequest/create message (A new conferencing system client,
1967 Alice, enters Bob's conference)
1969
1970
1974
1977 xcon:bobConf@example.com
1978 create
1979
1980
1981
1982
1983
1984 mailto:Alice83@example.com
1985
1986 email
1987
1988
1989
1990
1991
1992
1993
1995 2. userResponse/create (Alice provided with a new xcon-userid
1996 and added to the conference)
1998
1999
2003
2006 xcon-userid:Alice@example.com
2007 xcon:bobConf@example.com
2008 create
2009 200
2010 success
2011 5
2012
2013
2014
2016 Figure 18: Announcement Messaging Details
2018 6.4. Monitoring for DTMF
2020 Conferencing systems often also need the capability to monitor for
2021 DTMF from each individual participant. This would typically be used
2022 to enter the identifier and/or access code for joining a specific
2023 conference. This feature is often also exploited to achieve
2024 interaction between participants and the conference system for non-
2025 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted).
2027 An example of DTMF monitoring, within the context of the framework
2028 elements, is shown in Figure 17. A typical way for the conferencing
2029 system to be aware of all the DTMF interactions within the context of
2030 conferences it is responsible for, is making use of the MEDIACTRL
2031 architecture for what regards media manipulation. Examples in that
2032 sense (specifically for what concerns DTMF interception in conference
2033 instances) are presented in [I-D.ietf-mediactrl-call-flows].
2035 6.5. Entering a password-protected conference
2037 Some conferences may envision a password to be provided by a user who
2038 wants to manipulate the relative conference objects (e.g. join,
2039 update, delete) via CCMP. Such a password would be included in the
2040 element related to the conference XCON-URI in
2041 the appropriate entry and must be then included in
2042 the apposite "conference-password" field in the CCMP request
2043 addressed to that conference.
2045 In the following CCMP transactions, it is depicted a scenario in
2046 which Alice, a conferencing system client, attempts to join a
2047 password-protected conference.
2049 1. Alice sends a userRequest message with a "create" operation to
2050 add herself in the conference with XCON-URI
2051 "xcon:8977777@example.com" (written in the "confObjID"
2052 parameter). Alice provides her XCON-USERID via the "confUserID"
2053 field of the userRequest and leaves out the "userInfo" one
2054 (first-party join). In this first attempt, she doesn't insert
2055 any password parameter.
2057 2. Upon receipt the userRequest/create message, the conferencing
2058 server detects that the indicated conference is not joinable
2059 without providing the relative pass code. Then a userResponse
2060 message with "423" response-code ("conference password
2061 required")is returned to Alice to indicate that her join has been
2062 refused and that she has to recast her request including the
2063 appropriate conference password in order to participate.
2065 3. After getting the pass code through out-of-band mechanisms, Alice
2066 provides it in the proper "password" request field of a new
2067 userRequest/create message and sends the updated request back to
2068 the server.
2070 4. The conferencing server checks the provided password and then
2071 adds Alice to the protected conference. After that, a
2072 userResponse with a "200" response-code ("success") is sent to
2073 Alice.
2075 1. userRequest/create message (Alice tries to enter the conference
2076 without providing the password)
2078
2079
2083
2086 xcon-userid:Alice@example.com
2087 xcon:8977794@example.com
2088 create
2089
2090
2091
2093 2. userResponse/create message (423, "conference password required")
2095
2096
2100
2103 xcon-userid:Alice@example.com
2104 xcon:8977794@example.com
2105 create
2106 423
2107
2108 conference password required
2109
2110
2111
2112
2114 3. userRequest/create message (Alice provides the password)
2115
2116
2120
2123 xcon-userid:Alice@example.com
2124 xcon:8977794@example.com
2125 create
2126 8601
2127
2128
2129
2131 4. userResponse/create message
2132 (Alice has been added to the conference)
2134
2135
2139
2142 xcon-userid:Alice@example.com
2143 xcon:8977794@example.com
2144 create
2145 200
2146 success
2147 10
2148
2149
2150
2152 Figure 19: Password-protected conference join messages details
2154 7. Sidebars Scenarios and Examples
2156 While creating conferences and manipulating users and their media may
2157 be considered enough for many scenarios, there may be cases when a
2158 more complex management is needed.
2160 In fact, a feature typically required in conferencing systems is the
2161 ability to create sidebars. A sidebar is basically a child
2162 conference that usually includes a subset of the participants of the
2163 parent conference, and a subset of its media as well. Sidebars are
2164 typically required whenever some of the participants in a conference
2165 want to discuss privately about something, without interfering with
2166 the main conference.
2168 This section deals with some scenarios that typically envisage the
2169 use of a sidebar, like whispering, private messages and coaching
2170 scenarios. The first subsections, anyway, present some examples of
2171 how a generic sidebar can be created, configured and managed.
2173 7.1. Internal Sidebar
2175 Figure 20 provides an example of one client, "Alice", involved in an
2176 active conference with "Bob" and "Carol". Alice wants to create a
2177 sidebar to have a side discussion with Bob while still viewing the
2178 video associated with the main conference. Alternatively, the audio
2179 from the main conference could be maintained at a reduced volume.
2180 Alice initiates the sidebar by sending a request to the conferencing
2181 system to create a conference reservation based upon the active
2182 conference object. Alice and Bob would remain on the roster of the
2183 main conference, such that other participants could be aware of their
2184 participation in the main conference, while an internal-sidebar
2185 conference is occurring. Besides, Bob decides that he is not
2186 interested in still receiving the conference audio in background (not
2187 even at a lower volume as Alice configured) and so modifies the
2188 sidebar in order to make that stream inactive for him.
2190 Alice Bob ConfS
2191 | | |
2192 |(1) sidebarByValRequest(confUserID, |
2193 | confObjID,create) |
2194 |--------------------------------------------->|
2195 | | |
2196 | | (a) Create +---|
2197 | | sidebar-by-val | |
2198 | | (new conf obj | |
2199 | | cloned from +-->|
2200 | | confObjID) | Sidebar now has
2201 | | | id confObjID*
2202 |(2) sidebarByValResponse(confUserID, | (parent mapping
2203 | (confObjID*,create,200,success, | conf<->sidebar)
2204 | version,sidebarByValInfo) |
2205 |<---------------------------------------------|
2206 | | |
2207 |(3) sidebarByValRequest |
2208 | (confUserID, confObjID*, |
2209 | update,sidebarByValInfo) |
2210 |--------------------------------------------->|
2211 | | |
2212 | | (b) Update +---|
2213 | | sidebar-by-val | |
2214 | | (media, users | |
2215 | | etc.) +-->|
2216 | | | Sidebar is
2217 | | | modified
2218 |(4) sidebarByValResponse(confUserID, |
2219 | confObjID*, update, |
2220 | 200, success, version) |
2221 |<---------------------------------------------|
2222 | | |
2223 | |(5) userRequest |
2224 | | (confUserID', |
2225 | | confObjID*, |
2226 | | update,userInfo)|
2227 | |---------------------->|
2228 | | |
2229 | | (c) Update +---|
2230 | | user settings | |
2231 | | (Bob's media) | |
2232 | | +-->|
2233 | | | Sidebar is modified
2234 | | | (original audio
2235 | | | inactive for Bob)
2236 | |(6) userResponse |
2237 | | (confUserID', |
2238 | | confObjID*, |
2239 | | update, 200, |
2240 | | success,version) |
2241 | |<----------------------|
2242 | | |
2243 " " "
2244 " " "
2245 " " "
2247 Figure 20: Client Creation of a Sidebar Conference
2249 1. Upon receipt of CCMP sidebarByValRequest message to create a new
2250 sidebar-conference based upon the confObjID received in the
2251 request, the conferencing system uses the confObjID to clone a
2252 conference reservation for the sidebar. The sidebar reservation
2253 is NOT independent of the active conference (i.e., parent). The
2254 conferencing system also allocates a new XCON-URI for that
2255 sidebar to be used for any subsequent protocol requests from any
2256 of the members of the conference. The new sidebar identifier
2257 ("confObjID*" in Figure 20) is returned in the response message
2258 confObjID parameter.
2260 2. The relationship information is provided in the
2261 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the
2263 main/parent conference is provided below as well to show how the
2264 cloning process for the creation of the sidebar could take place.
2266 3. Upon receipt of the sidebarByValResponse message to reserve the
2267 conference, Alice can now create an active conference using that
2268 reservation, or create additional reservations based upon the
2269 existing reservations. In this example, Alice wants only Bob to
2270 be involved in the sidebar, thus she manipulates the membership
2271 so that only the two of them appear in the
2272 section. Alice also wants both audio and video from the original
2273 conference to be available in the sidebar. For what concerns the
2274 media belonging to the sidebar itself, Alice wants the audio to
2275 be restricted to the participants in the sidebar (that is, Bob
2276 and herself). Additionally, Alice manipulates the media values
2277 to receive the audio from the main conference at a reduced
2278 volume, so that the communication between her and Bob isn't
2279 affected. Alice sends a sidebarByValRequest message with an
2280 operation of "update" along with the "sidebarByValInfo"
2281 containing the aforementioned sidebar modifications.
2283 4. Upon receipt of the sidebarByValRequest to update the sidebar
2284 reservation, the conference server ensures that Alice has the
2285 appropriate authority based on the policies associated with that
2286 specific conference object to perform the operation. The
2287 conference server must also validate the updated information in
2288 the reservation, ensuring that a member like Bob is already a
2289 user of this conference server. Once the data for the confObjID
2290 is updated, the conference server sends a sidebarByValResponse to
2291 Alice. Depending upon the policies, the initiator of the request
2292 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may
2293 be notified of his addition to the sidebar via the conference
2294 notification service.
2296 5. At this point, Bob sends a userRequest message to the conference
2297 server with an operation of "update" to completely disable the
2298 background audio from the parent conference, since it prevents
2299 him from understanding what Alice says in the sidebar.
2301 6. Notice that Bob's request only changes the media perspective for
2302 Bob. Alice keeps on receiving both the audio from Bob and the
2303 background from the parent conference. This request may be
2304 relayed by the conference server to the Media Server handling the
2305 mixing, if present. Upon completion of the change, the
2306 conference server sends a "userResponse" message to Bob.
2307 Depending upon the policies, the initiator of the request (i.e.,
2308 Bob) and the participants in the sidebar (i.e., Alice) may be
2309 notified of this change via the conference notification service.
2311 That said, let's consider the following conference object:
2313
2314
2319
2320 MAIN CONFERENCE
2321
2322
2323 sip:8977878@example.com
2324 conference sip uri
2325
2326
2327
2328
2329 main conference audio
2330 audio
2331 sendrecv
2332
2333
2334 main conference video
2335 video
2336 sendrecv
2337
2338 single-view
2339
2340
2341
2342
2343
2344 true
2345
2346
2347
2348 Alice
2349
2350
2351 123
2352 sendrecv
2353
2354
2355 456
2356 sendrecv
2357
2358
2359
2360
2361 Bob
2362
2363
2364 123
2365 sendrecv
2366
2367
2368 456
2369 sendrecv
2370
2371
2372
2373
2374 Carol
2375
2376
2377 123
2378 sendrecv
2379
2380
2381 456
2382 sendrecv
2383
2384
2385
2386
2387
2389 Figure 21: Conference with Alice, Bob and Carol
2391 This is the representation of the conference the sidebar is going to
2392 be created in. As such, it will be used by the conferencing system
2393 in order to create the new conference object associated with the
2394 sidebar. In fact, the sidebar creation happens through a cloning of
2395 the parent conference. Once the sidebar is created, an "update"
2396 makes sure that the sidebar is customized as needed. The following
2397 protocol dump makes the process clearer.
2399 1. sidebarByValRequest/create message (Alice creates an
2400 internal sidebar)
2402
2403
2407
2410 xcon-userid:Alice@example.com
2411 xcon:8977878@example.com
2412 create
2413
2414
2415
2417 2. sidebarByValResponse/create message (sidebar returned)
2419
2420
2424
2427 xcon-userid:Alice@example.com
2428 xcon:8974545@example.com
2429 create
2430 200
2431 success
2432 1
2433
2434
2435
2436
2437 SIDEBAR CONFERENCE registered by Alice
2438
2439
2440 xcon:8977878@example.com
2441
2442
2443
2444
2445 main conference audio
2446
2447 audio
2448 sendrecv
2449
2450
2451
2452 main conference video
2453
2454 video
2455 sendrecv
2456
2457
2458
2459
2460 false
2461
2462
2463
2464
2466
2468
2470
2471
2472
2473
2474
2475
2477 3. sidebarByValRequest/update message (Alice updates the
2478 created sidebar)
2480
2481
2485
2488 xcon-userid:Alice@example.com
2489 xcon:8974545@example.com
2490 update
2491
2492
2493
2494
2495 private sidebar Alice - Bob
2496
2497
2498
2499
2500 main conference audio
2501
2502 audio
2503 recvonly
2504
2505 -60
2506
2507
2508
2509
2510 main conference video
2511
2512 video
2513 recvonly
2514
2515
2516
2517 sidebar audio
2518
2519 audio
2520 sendrecv
2521
2522
2523
2524 sidebar video
2525
2526 video
2527 sendrecv
2528
2529
2530
2531
2532
2533
2535
2537
2538
2539
2540
2541
2542
2544 4. sidebarByValResponse/update message (sidebar's
2545 updates accepted)
2547
2548
2552
2555 xcon-userid:Alice@example.com
2556 xcon:8974545@example.com
2557 update
2558 200
2559 success
2560 2
2561
2562
2563
2565 5. userRequest/update message (Bob updates his media)
2567
2568
2572
2575 xcon-userid:Bob@example.com
2576 xcon:8974545@example.com
2577 update
2578
2579
2580
2581
2582
2583 main conference audio
2584
2585 123
2586 inactive
2587
2588
2589
2590
2591
2592
2594 6. userResponse/update message (Bob's preferences setted)
2596
2597
2601
2604 xcon-userid:Bob@example.com
2605 xcon:8974545@example.com
2606 update
2607 200
2608 success
2609 3
2610
2611
2612
2614 Figure 22: Internal Sidebar Messaging Details
2616 7.2. External Sidebar
2618 Figure 23 provides an example of a different approach towards
2619 sidebar. In this scenario, one client, "Alice", is involved in an
2620 active conference with "Bob", "Carol", "David" and "Ethel". Alice
2621 gets an important text message via a whisper from Bob that a critical
2622 customer needs to talk to Alice, Bob and Ethel. Alice creates a
2623 sidebar to have a side discussion with the customer "Fred" including
2624 the participants in the current conference with the exception of
2625 Carol and David, who remain in the active conference. The difference
2626 from the previous scenario is that Fred is not part of the parent
2627 conference: this means that different policies might be involved,
2628 considering that Fred may access information coming from the parent
2629 conference, in case the sidebar was configured accordingly. For this
2630 reason, in this scenario we assume that Alice disables all the media
2631 from the original (parent) conference within the sidebar. This means
2632 that, while in the previous example Alice and Bob still heard the
2633 audio from the main conference in background, this time no background
2634 is made available. Alice initiates the sidebar by sending a request
2635 to the conferencing system to create a conference reservation based
2636 upon the active conference object. Alice, Bob and Ethel would remain
2637 on the roster of the main conference in a hold state. Whether or not
2638 the hold state of these participants is visible to other participants
2639 depends upon the individual and local policy.
2641 Alice Bob ConfS
2642 | | |
2643 |(1) sidebarByRefRequest(confUserID, |
2644 | confObjID, create) |
2645 |--------------------------------------------->|
2646 | | |
2647 | | (a) Create +---|
2648 | | sidebar-by-ref | |
2649 | | (new conf obj | |
2650 | | cloned from +-->|
2651 | | confObjID) | Sidebar now has
2652 | | | id confObjID*
2653 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2654 | confObjID*,create,200,success, | conf<->sidebar)
2655 | version,sidebarByRefInfo) |
2656 |<---------------------------------------------|
2657 | | |
2658 |(3) sidebarByRefRequest(confUserID, |
2659 | confObjID*,update,sidebarByRefInfo) |
2660 |--------------------------------------------->|
2661 | | |
2662 | | (b) Create +---|
2663 | | new user for | |
2664 | | Fred | |
2665 | | +-->|
2666 | | |
2667 | | (c) Update +---|
2668 | | sidebar-by-ref | |
2669 | | (media, users | |
2670 | | policy, etc.) +-->|
2671 | | | Sidebar is modified:
2672 | | | no media from the
2673 | | | parent conference is
2674 | | | available to anyone
2675 |(4) sidebarByRefResponse(confUserID, |
2676 | confObjID*, update, |
2677 | 200, success, version) |
2678 |<---------------------------------------------|
2679 | | |
2680 | | Notify (Fred |
2681 | | added to |
2682 | | sidebar users) |
2683 | |<----------------------|
2684 | | |
2685 " " "
2686 " " "
2687 " " "
2688 Figure 23: Client Creation of an External Sidebar
2690 1. Upon receipt of the "sidebarByRefRequest" message to create a new
2691 sidebar conference, based upon the active conference specified by
2692 "confObjID" in the request, the conferencing system uses that
2693 active conference to clone a conference reservation for the
2694 sidebar. The sidebar reservation is NOT independent of the
2695 active conference (i.e., parent). The conferencing system, as
2696 before, allocates a conference ID (confObjID*) to be used for any
2697 subsequent protocol requests toward the sidebar reservation. The
2698 mapping between the sidebar conference ID and the one associated
2699 with the main conference is mantained by the conferencing system
2700 and it is gathered from the c element in the
2701 sidebar conference object.
2703 2. Upon receipt of the "sidebarByRefResponse" message, which
2704 acknowledges the successful creation of the sidebar object, Alice
2705 decides that only Bob and Ethel, along with the new participant
2706 Fred are to be involved in the sidebar. Thus she manipulates the
2707 membership accordingly. Alice also sets the media in the
2708 "conference-info" such that the participants in the sidebar don't
2709 receive any media from the main conference. All these settings
2710 are provided to the conferencing system by means of a new
2711 "sidebarByRefRequest" message, with an "update" operation.
2713 3. Alice sends the aforementioned "sidebarByRefRequest" to update
2714 the information in the reservation and to create an active
2715 conference. Upon receipt of the "sidebarByRefRequest" with an
2716 operation of "update", the conferencing system ensures that Alice
2717 has the appropriate authority based on the policies associated
2718 with that specific conference object to perform the operation.
2719 The conferencing system also validates the updated information in
2720 the reservation. Since Fred is a new user for this conferencing
2721 system, a conference user identifier is created for Fred.
2722 Specifically, Fred is added to the conference by only providing
2723 his SIP URI. Based upon the contact information provided for
2724 Fred by Alice, the call signaling to add Fred to the conference
2725 may be instigated through the Focus (e.g. if Fred had a "dial-
2726 out" method set as the target for him) at the actual activation
2727 of the sidebar.
2729 4. The conference server sends a "sidebarByRefResponse" message and,
2730 depending upon the policies, the initiator of the request (i.e.,
2731 Alice) and the participants in the sidebar (i.e., Bob and Ethel)
2732 may be notified of his addition to the sidebar via the conference
2733 notification service.
2735 1. sidebarByRefRequest/create message (Alice creates an
2736 external sidebar)
2738
2739
2743
2746 xcon-userid:Alice@example.com
2747 xcon:8977878@example.com
2748 create
2749
2750
2751
2753 2. sidebarByRefResponse/create message (created
2754 sidebar returned)
2756
2757
2761
2764 xcon-userid:Alice@example.com
2765 xcon:8971212@example.com
2766 create
2767 200
2768 success
2769 1
2770
2771
2772
2773
2774 SIDEBAR CONFERENCE registered by Alice
2775
2776
2777 xcon:8977878@example.com
2778
2779
2780
2781
2782 main conference audio
2783
2784 audio
2785 sendrecv
2786
2787
2788
2789 main conference video
2790
2791 video
2792 sendrecv
2793
2794
2795
2796
2797 false
2798
2799
2800
2801
2803
2805
2807
2809
2811
2812
2813
2814
2815
2816
2818 3. sidebarByRefRequest/update message (Alice updates the sidebar)
2820
2824
2827 xcon-userid:Alice@example.com
2828 xcon:8971212@example.com
2829 update
2830
2831
2832
2833
2834 sidebar with Alice, Bob, Ethel & Fred
2835
2836
2837
2838
2839 main conference audio
2840
2841 audio
2842 inactive
2843
2844
2845
2846 main conference video
2847
2848 video
2849 inactive
2850
2851
2852
2853 sidebar audio
2854
2855 audio
2856 sendrecv
2857
2858
2859
2860 sidebar video
2861
2862 video
2863 sendrecv
2864
2865
2866 single-view
2867
2868
2869
2870
2871
2872
2873 false
2874
2875
2876
2877
2879
2881
2883
2884
2885
2886
2887
2888
2890 4. sidebarByRefResponse/update message (sidebar updated)
2892
2896
2899 xcon-userid:Alice@example.com
2900 xcon:8971212@example.com
2901 update
2902 200
2903 success
2904 2
2905
2906
2907
2909 Figure 24: External Sidebar Messaging Details
2911 7.3. Private Messages
2913 The case of private messages can be handled as a sidebar with just
2914 two participants, similarly to the example in Section 7.1. Unlike
2915 the previous example, rather than using audio within the sidebar,
2916 Alice could just add an additional text based media stream to the
2917 sidebar in order to convey her textual messages to Bob, while still
2918 viewing and listening to the main conference.
2920 In this scenario, Alice requests to the conferencing system the
2921 creation of a private chat room within the main conference context
2922 (presented in Figure 21) in which the involved partecipants are just
2923 Bob and herself. This can be achieved through the following CCMP
2924 transaction (Figure 25).
2926 1. Alice forwards a sidebarByValRequest/create to the Conferencing
2927 Control Server with the main conference XCON-URI in the
2928 "confObjID" parameter and the desired sidebar conference object
2929 in the "sidebarByValInfo" field. In this way, a sidebar creation
2930 using user-provided conference information is requested to the
2931 conferencing system. Please note that, unlike the previous
2932 sidebar examples, in this case a comnpletely new conference
2933 object to describe the sidebar is provided: there is no cloning
2934 involved, while the "confObjID" still enforces the parent-child
2935 relationship between the main conference and the to-be-created
2936 sidebar.
2938 2. The Conference Control Server, after checking Alice's rights and
2939 validating the conference-object carried in the request, creates
2940 the required sidebar-by-val conference and a new XCON-URI for it.
2941 Instead of cloning the main conference object, as envisioned in
2942 Section 7.1 and Section 7.2, the sidebar is created on the basis
2943 of the user provided conference information (as anticipated
2944 before). However, the parent relationship between the main
2945 conference and the newly created sidebar is still mantained by
2946 the conferencing system (as a consequence of the chosen CCMP
2947 request message type - the sidebarByVal one) and it is reflected
2948 by the element in the "sidebarByValInfo" element
2949 returned in the sidebarByValResponse message. Please notice
2950 that, according to the CCMP specification, the return of the
2951 created sidebar data in this kind of "success" response is not
2952 mandatory.
2954 1. sidebarByValRequest/create message (Alice creates a private
2955 chat room between Bob and herself)
2957
2958
2962
2965 xcon-userid:Alice@example.com
2966 xcon:8977878@example.com
2967 create
2968
2969
2970
2971
2972 private textual sidebar alice - bob
2973
2974
2975
2976
2977 main conference audio
2978
2979 audio
2980 recvonly
2981
2982
2983
2984 main conference video
2985
2986 video
2987 recvonly
2988
2989
2990
2991 sidebar text
2992
2993 text
2994 sendrecv
2995
2996
2997
2998
2999
3000
3002
3004
3005
3006
3007
3008
3009
3011 2. sidebarByValResponse/create message (sidebar returned)
3013
3014
3018
3021 xcon-userid:Alice@example.com
3022 xcon:8974545@example.com
3023 create
3024 200
3025 success
3026 1
3027
3028
3029
3030
3031 private textual sidebar alice - bob
3032
3033
3034 xcon:8977878@example.com
3035
3036
3037
3038
3039 main conference audio
3040
3041 audio
3042 recvonly
3043
3044
3045
3046 main conference video
3047
3048 video
3049 recvonly
3050
3051
3052
3053 sidebar text
3054
3055 text
3056 sendrecv
3057
3058
3059
3060
3061
3062
3064
3066
3067
3068
3069
3070
3071
3073 Figure 25: Sidebar for Private Messages scenario
3075 7.4. Observing and Coaching
3077 Observing and Coaching is one of the most interesting sidebars-
3078 related scenarios. In fact, it envisages two different interactions
3079 that have to be properly coordinated.
3081 An example of observing and coaching is shown in figure Figure 27.
3082 In this example, call center agent Bob is involved in a conference
3083 with customer Carol. Since Bob is a new agent and Alice sees that he
3084 has been on the call with Carol for longer than normal, she decides
3085 to observe the call and coach Bob as necessary. Of course the
3086 conferencing system must make sure that the customer Carol is not
3087 aware of the presence of the coach Alice. This makes the use of a
3088 sidebar necessary for the success of the scenario.
3090 Consider the following as the conference document associated with the
3091 video conference involving Bob (the call agent) and Carol (the
3092 customer) (Figure 26):
3094
3095
3100
3101
3102 CUSTOMER SERVICE conference
3103
3104
3105
3106 sip:8978383@example.com
3107 conference sip uri
3108
3109
3110
3111
3112 service audio
3113 audio
3114 sendrecv
3115
3116
3117 service video
3118 video
3119 sendrecv
3120
3121 single-view
3122
3123
3124
3125
3126
3127 true
3128
3129
3130
3131 Bob - call agent
3132
3133
3134 123
3135 sendrecv
3136
3137
3138 456
3139 sendrecv
3140
3141
3142
3143
3144 Carol - customer
3145
3146
3147 123
3148 sendrecv
3149
3150
3151 456
3152 sendrecv
3153
3155
3156
3157
3158
3160 Figure 26: A call-center conference object example
3162 Alice Bob ConfS
3163 | | |
3164 |(1) sidebarByRefRequest(confUserID, |
3165 | confObjID, create) |
3166 |--------------------------------------------->|
3167 | | |
3168 | | (a) Create +---|
3169 | | sidebar-by-ref | |
3170 | | (new conf obj | |
3171 | | cloned from +-->|
3172 | | confObjID) | Sidebar now has
3173 | | | id confObjID*
3174 |(2) sidebarByRefResponse(confUserID, | (parent mapping
3175 | confObjID*,create,200,success, | conf<->sidebar)
3176 | version,sidebarByRefInfo) |
3177 |<---------------------------------------------|
3178 | | |
3179 |(3) sidebarByRefRequest(confUserID, |
3180 | confObjID*,update,sidebarByRefInfo) |
3181 |--------------------------------------------->|
3182 | | |
3183 | | (b) Update +---|
3184 | | sidebar-by-val | |
3185 | | (media, users | |
3186 | | policy, etc.) +-->|
3187 | | | Sidebar is modified:
3188 | | | unilateral sidebar
3189 | | | audio, Carol excluded
3190 | | | from the sidebar
3191 |(4) sidebarByRefResponse(confUserID, |
3192 | confObjID*, update, |
3193 | 200, success, version) |
3194 |<---------------------------------------------|
3195 | | |
3196 | | Notify (Bob |
3197 | | he's been added to |
3198 | | sidebar users) |
3199 | |<----------------------|
3200 | | |
3201 " " "
3202 " " "
3203 " " "
3205 Figure 27: Supervisor Creating a Sidebar for Observing/Coaching
3207 1. Upon receipt of the sidbarByRefRequest/create from Alice to
3208 "create" a new sidebar conference from the confObjID received in
3209 the request, the conferencing system uses the received active
3210 conference to clone a conference reservation for the sidebar.
3211 The conferencing system also allocates a conference ID to be used
3212 for any subsequent protocol requests from any of the members of
3213 the conference. The conferencing system maintains the mapping
3214 between this conference ID and the confObjID associated with the
3215 sidebar reservation through the conference instance. The
3216 conference server sends a sidebarByRefResponse message with the
3217 new confObjID and relevant sidebarByRefInfo.
3219 2. Upon receipt of the sidebarByRefResponse message, Alice
3220 manipulates the data received in the sidebarByRefInfo in the
3221 response. Alice wants only Bob to be involved in the sidebar,
3222 thus she updates the to include only Bob and
3223 herself. Alice also wants the audio to be received by herself
3224 and Bob from the original conference, but wants any outgoing
3225 audio from herself to be restricted to the participants in the
3226 sidebar, whereas Bob's outgoing audio should go to the main
3227 conference, so that both Alice and the customer Carol hear the
3228 same audio from Bob. Alice sends a sidebarByRefRequest message
3229 with an "update" operation including the updated sidebar
3230 information.
3232 3. Upon receipt of the sidebarByRefRequest message with an "update"
3233 operation, the conferencing system ensures that Alice has the
3234 appropriate authority based on the policies associated with that
3235 specific conference object to perform the operation. In order to
3236 request the insertion of a further media stream in the sidebar
3237 (i.e. in this example an audio stream from Alice to Bob), the
3238 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label"
3240 attribute of that new entry is filled with a dummy value
3241 "AUTO_GENERATE_1", but it will contain the real server-generated
3242 media stream identifier when the media stream is effectively
3243 allocated on the server side. Similarly, the mandatory "id"
3244 attribute in element referring to the new sidebar audio
3245 stream under both Alice's and Bob's contains a
3246 wildcard value, respectively "AUTO_GENERATED_2" and
3247 "AUTO_GENERATED_3": those values will be replaced with the
3248 appropriated server-generated identifiers upon the creation of
3249 the referred media stream. We are assuming the conferencing
3250 control server is able to recognize those dummy values as place-
3251 holders.
3253 4. After validating the data, the conference server sends a
3254 sidebarByRefResponse message. Based upon the contact information
3255 provided for Bob by Alice, the call signaling to add Bob to the
3256 sidebar with the appropriate media characteristics is instigated
3257 through the Focus. Bob is notified of his addition to the
3258 sidebar via the conference notification service, thus he is aware
3259 that Alice, the supervisor, is available for coaching him through
3260 this call.
3262 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
3264
3265
3269
3272 xcon-userid:Alice@example.com
3273 xcon:8978383@example.com
3274 create
3275
3276
3277
3279 2. sidebarByRefResponse/create message (sidebar created)
3281
3282
3286
3289 xcon-userid:alice@example.com
3290 xcon:8971313@example.com
3291 create
3292 200
3293 success
3294 1
3295
3296
3297
3298
3299 SIDEBAR CONFERENCE registered by alice
3300
3301
3302 xcon:8971313@example.com
3303
3304
3305
3306
3307 main conference audio
3308
3309 audio
3310 sendrecv
3311
3312
3313
3314 main conference video
3315
3316 video
3317 sendrecv
3318
3319
3320
3321
3322 false
3323
3324
3325
3326
3328
3330
3332
3333
3334
3335
3336
3337
3339 3. sidebarByRefRequest/update message (Alice introduces unilateral
3340 sidebar audio and excludes Carol from the sidebar)
3342
3346
3349 xcon-userid:alice@example.com
3350 xcon:8971313@example.com
3351 update
3352
3353
3354
3355
3356 Coaching sidebar Alice and Bob
3357
3358
3359
3360
3361 Alice-to-Bob audio
3362
3363 audio
3364 sendrecv
3365
3366
3367
3368
3369 false
3370
3371
3372
3373
3375
3377
3378
3380
3381 AUTO_GENERATE_1
3382 sendonly
3383
3384
3385
3386
3388
3389 AUTO_GENERATE_1
3390 recvonly
3391
3392
3393
3394
3395
3396
3398
3399
3401 4. sidebarByRefRequest/update message (updates accepted)
3403
3404
3408
3411 xcon-userid:alice@example.com
3412 xcon:8971313@example.com
3413 update
3414 200
3415 success
3416 2
3417
3418
3419
3421 Figure 28: Coaching and Observing Messaging details
3423 8. Removing Participants and Deleting Conferences
3425 The following scenarios detail the basic operations associated with
3426 removing participants from conferences and entirely deleting
3427 conferences. The examples assume that a conference has already been
3428 correctly established, with media, if applicable, per one of the
3429 examples in Section 5.
3431 8.1. Removing a Party
3433 Figure 29 provides an example of a client, "Alice", removing another
3434 participant, "Bob", from a conference. This example assumes an
3435 established conference with Alice, Bob, "Claire" and "Duck". In this
3436 example, Alice wants to remove Bob from the conference so that the
3437 group can continue in the same conference without Bob's
3438 participation.
3440 Alice Bob Claire ConfS
3441 | | | |
3442 |(1) userRequest(confUserID,| |
3443 | confObjID, delete,| |
3444 | userInfo) | |
3445 |-------------------------------------->|
3446 | | | |
3447 | | | (a) Focus |
3448 | | | tears down|
3449 | | | signaling |
3450 | | | to Bob |
3451 | |<----------------------|
3452 | | |
3453 | | (b)Deletes+---|
3454 | | | Bob | |
3455 | | | as a | |
3456 | | | user +-->|
3457 | | | in |
3458 | | | confObj |
3459 | | | |
3460 |(2) userResponse(confUserID,confObjID, |
3461 | delete,200,success,version) |
3462 |<--------------------------------------|
3463 | | | |
3464 | | | |
3465 | | | (c) Notify|
3466 | | | ("Bob just|
3467 | | | left") |
3468 | | |<----------|
3469 | | | |
3470 ' ' ' '
3471 ' ' ' '
3472 ' ' ' '
3474 Figure 29: Client Manipulation of Conference - Remove a party
3476 1. Alice sends a userRequest message, with a "delete" operation.
3477 The conference server ensures that Alice has the appropriate
3478 authority based on the policies associated with that specific
3479 conference object to perform the operation.
3481 2. Based upon the contact and media information in the conference
3482 object for Bob in the "userInfo" element, the conferencing system
3483 starts the process to remove Bob (e.g., the call signaling to
3484 remove Bob from the conference is instigated through the Focus).
3485 The conference server updates the data in the conference object,
3486 thus removing Bob from the list. After updating the
3487 data, the conference server sends a userResponse message to
3488 Alice. Depending upon the policies, other participants (e.g.
3489 "Claire") may be notified of the removal of Bob from the
3490 conference via the Conference Notification Service.
3492 1. userRequest/delete message (Alice deletes Bob):
3494
3495
3499
3502 xcon-userid:Alice@example.com
3503 xcon:8977794@example.com
3504 delete
3505
3506
3507
3508
3509
3511 2. userResponse/delete message (Bob has been deleted)
3513
3514
3518
3521 xcon-userid:Alice@example.com
3522 xcon:8977794@example.com
3523 delete
3524 200
3525 success
3526 17
3527
3528
3529
3530 Figure 30: Removing a Participant Messaging Details
3532 8.2. Deleting a Conference
3534 In this section, an example of a successful conference deletion is
3535 provided (Figure 31).
3537 Alice ConfS
3538 | |
3539 |(1)confRequest(confUserID, |
3540 | confObjID, delete) |
3541 |------------------------------>|
3542 | (a)Delete +---|
3543 | Conf | |
3544 | Object | |
3545 | +-->|
3546 | |--+ (b) MS
3547 | | | removes related
3548 | | | mixer instances and
3549 | |<-+ their participants
3550 | | (SIP signaling as well)
3551 | |
3552 |(2)confResponse(confUserID, |
3553 | confObjID,delete,200, |
3554 | success) |
3555 | |
3556 |<------------------------------|
3557 | |
3559 Figure 31: Deleting a conference
3561 1. The conferencing system client "Alice" sends a confRequest
3562 message with a "delete" operation to be performed on the
3563 conference identified by the XCON-URI carried in the "confObjID"
3564 parameter. The conference server, on the basis of the
3565 "confUserID" included in the receipt request, ensures that Alice
3566 has the appropriate authority to fulfill the operation.
3568 2. After validating Alice's rights, the conferencing server
3569 instigates the process to delete the conference object,
3570 disconnetting participants and removing associated resources such
3571 as mixer instances. Then, the conference server returns a
3572 confResponse message to Alice with "200" as "response-code" and
3573 the deleted conference XCON-URI in the "confObjID" field.
3575 1. confRequest/delete message (Alice deletes a conference)
3577
3578
3582
3585 xcon-userid:Alice@example.com
3586 xcon:8977794@example.com
3587 delete
3588
3589
3590
3592 2. confResponse/delete message (200, "success")
3594
3595
3599
3602 xcon-userid:Alice@example.com
3603 xcon:8977794@example.com
3604 delete
3605 200
3606 success
3607
3608
3609
3611 Figure 32: Deleting a Conference Messaging Details
3613 9. IANA Considerations
3615 This document has no IANA considerations.
3617 10. Security Considerations
3619 The security considerations applicable to the implementation of these
3620 call flows is documented in the XCON Framework, with additional
3621 security considerations documented in the CCMP document. Where
3622 applicable, statements with regards to the necessary security are
3623 discussed in particular flows, however, since this is only an
3624 informational document, readers are strongly recommended to carefully
3625 consider the security considerations defined in the XCON Framework
3626 and the CCMP document.
3628 11. Change Summary
3630 NOTE TO THE RFC-EDITOR: Please remove this section prior to
3631 publication as an RFC.
3633 The following are the major changes between the 02 and the 03
3634 versions of the draft:
3636 o updated the call flows in order to take into account the changes
3637 on CCMP;
3639 o added a completely new introductory section, addressing the
3640 protocol in general, the data model constraints, transport-related
3641 information, and notifications in a practical way;
3643 o reorganized the chapters, grouping user-related scenarios in an
3644 users section, and doing the same for sidebars;
3646 o added more verbose text to almost every section of the document;
3648 The following are the major changes between the 01 and the 02
3649 versions of the draft:
3651 o updated the call flows in order to take into account the new
3652 versioning mechanism of the CCMP;
3654 o clarified, per agreement in Stockholm, that cloning from a
3655 blueprint does not need a cloning-parent to be made available in
3656 the response;
3658 o clarified that BFCP and CCMP-based media control are neither in
3659 conflict nor one the wrapper of the other; they act at different
3660 levels, and when both are involved, it is required that both grant
3661 a resource before it can be used by an interested participant;
3663 o changed all the domains involved in the flows to make them
3664 compliant with [RFC2606];
3666 o clarified that a successful creation of a new conference object
3667 may or may not contain the whole confInfo object in the response;
3668 in case it doesn't, a retrieve of the updated object can be
3669 achieved by issuing a confRequest/retrieve;
3671 o clarified that the scenario in Section 6.3 only involves CCMP in
3672 adding the user to a conference; this includes requiring the use
3673 of a password only in adding the user to the conference object;
3674 the actual request for PIN/Password when joining thw conference is
3675 handled by means of out-of-band mechanisms (in this case at the
3676 media level, with the help of the MEDIACTRL framework);
3678 o added and corrected Sidebars-related scenarios;
3680 o added flows for some previously missing scenarios: Private
3681 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
3682 Conference;
3684 o
3686 The following are the major changes between the 00 and the 01
3687 versions of the draft:
3689 o Updates to reflect change of CCMP to HTTP transport model.
3691 The following are the major changes between the individual 01 version
3692 to the WG 00:
3694 o Updates to reflect most recent version of CCMP, including
3695 parameter names, etc.
3697 o Added protocol details to many of the examples.
3699 o Editorial: Simplifying intro, terms, etc.
3701 12. Acknowledgements
3703 The detailed content for this document is derived from the prototype
3704 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
3705 their colleagues at the University of Napoli.
3707 13. References
3709 13.1. Normative References
3711 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
3712 Centralized Conferencing", RFC 5239, June 2008.
3714 [I-D.ietf-xcon-ccmp]
3715 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
3716 "Centralized Conferencing Manipulation Protocol",
3717 draft-ietf-xcon-ccmp-09 (work in progress), July 2010.
3719 13.2. Informative References
3721 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
3722 Names", BCP 32, RFC 2606, June 1999.
3724 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
3725 A., Peterson, J., Sparks, R., Handley, M., and E.
3726 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
3727 June 2002.
3729 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
3730 (SIP) Call Control - Conferencing for User Agents",
3731 BCP 119, RFC 4579, August 2006.
3733 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
3734 RFC 4597, August 2006.
3736 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
3737 Control Protocol (BFCP)", RFC 4582, November 2006.
3739 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
3740 Initiation Protocol (SIP) Event Package for Conference
3741 State", RFC 4575, August 2006.
3743 [I-D.ietf-xcon-event-package]
3744 Camarillo, G., Srinivasan, S., Even, R., and J.
3745 Urpalainen, "Conference Event Package Data Format
3746 Extension for Centralized Conferencing (XCON)",
3747 draft-ietf-xcon-event-package-01 (work in progress),
3748 September 2008.
3750 [I-D.ietf-xcon-common-data-model]
3751 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
3752 "Conference Information Data Model for Centralized
3753 Conferencing (XCON)", draft-ietf-xcon-common-data-model-19
3754 (work in progress), May 2010.
3756 [I-D.ietf-mediactrl-call-flows]
3757 Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
3758 "Media Control Channel Framework (CFW) Call Flow
3759 Examples", draft-ietf-mediactrl-call-flows-04 (work in
3760 progress), May 2010.
3762 [RFC5567] Melanchuk, T., "An Architectural Framework for Media
3763 Server Control", RFC 5567, June 2009.
3765 [I-D.ietf-mediactrl-mixer-control-package]
3766 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
3767 Control Package for the Media Control Channel Framework",
3768 draft-ietf-mediactrl-mixer-control-package-11 (work in
3769 progress), February 2010.
3771 Authors' Addresses
3773 Mary Barnes
3774 Polycom
3775 TX
3776 US
3778 Email: mary.ietf.barnes@gmail.com
3780 Lorenzo Miniero
3781 Meetecho
3782 Via Carlo Poerio 89/a
3783 Napoli 80121
3784 Italy
3786 Email: lorenzo@meetecho.com
3787 Roberta Presta
3788 University of Napoli
3789 Via Claudio 21
3790 Napoli 80125
3791 Italy
3793 Email: roberta.presta@unina.it
3795 Simon Pietro Romano
3796 University of Napoli
3797 Via Claudio 21
3798 Napoli 80125
3799 Italy
3801 Email: spromano@unina.it