idnits 2.17.1
draft-ietf-xcon-examples-09.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 11, 2011) is 4671 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-13
-- 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-31
== Outdated reference: A later version (-13) exists of
draft-ietf-mediactrl-call-flows-07
Summary: 0 errors (**), 0 flaws (~~), 4 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 12, 2012 Meetecho
6 R. Presta
7 S P. Romano
8 University of Napoli
9 July 11, 2011
11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
12 draft-ietf-xcon-examples-09
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 12, 2012.
41 Copyright Notice
43 Copyright (c) 2011 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/TLS as a transport . . . . . . . . . . . . . . 6
64 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
65 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 11
66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 12
67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 16
68 5.3. Conference Creation using User-Provided Conference
69 Information . . . . . . . . . . . . . . . . . . . . . . . 23
70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 28
71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 32
72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 32
73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 36
74 6.3. Conference Announcements and Recordings . . . . . . . . . 40
75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 44
76 6.5. Entering a password-protected conference . . . . . . . . . 44
77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 46
78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 47
79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 56
80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63
81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67
82 8. Removing Participants and Deleting Conferences . . . . . . . . 74
83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74
84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77
85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79
88 12. Informative References . . . . . . . . . . . . . . . . . . . . 79
89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80
91 1. Introduction
93 This document provides detailed call flows for the scenarios
94 documented in the Framework for Centralized Conferencing (XCON
95 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
96 scenarios describe a broad range of use cases taking advantage of the
97 advanced conferencing capabilities provided by a system realization
98 of the XCON framework. The call flows document the use of the
99 interface between a conference control client and a conference
100 control server using the Centralized Conferencing Manipulation
101 Protocol (CCMP)[I-D.ietf-xcon-ccmp].
103 Due to the broad range of functionality provided by the XCON
104 Framework and the flexibility of the CCMP messaging, these call flows
105 should not be considered inclusive of all the functionality that can
106 provided by the XCON Framework and protocol implementations. These
107 flows represent a sample to provide an overview of the feature rich
108 capabilities of the XCON framework and CCMP messaging for protocol
109 developers, software developers and researchers.
111 2. Terminology
113 This document uses the same terminology as found in the Media Control
114 Architectural Framework [RFC5567] and Media Control Channel Framework
115 Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the
116 following terms and abbreviations used in the call flows. Also, note
117 that the term "call flows" is used in a very generic sense in this
118 document since the media is not limited to voice. The calls
119 supported by the XCON framework and CCMP can consist of media such as
120 text, voice and video, including multiple media types in a single
121 active conference.
123 Conference and Media Control Client (CMCC): as defined in the XCON
124 Framework. In the flows in this document, the CMCC is logically
125 equivalent to the use of UAC as the client notation in the media
126 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC
127 differs from a generic Media Client in being an XCON-aware entity,
128 thus being able to also issue CCMP requests.
130 Conferencing Server (ConfS): In this document, the term
131 "Conferencing Server" is used interchangeably with the term
132 "Application Server" (AS) as used in the Media Control
133 Architectural Framework [RFC5567]. A Conferencing Server is
134 intended to be able to act as a Conference Control Server, as
135 defined in the XCON framework, i.e., it is able to handle CCMP
136 requests and issue CCMP responses.
138 Media Server (MS): as defined in the Media Control Architectural
139 Framework [RFC5567].
141 3. Overview
143 This document provides a sampling of detailed call flows that can be
144 implemented based on a system realization of the XCON framework
145 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
146 intended to be a simple guide for the use of the Conference Control
147 Protocol between the Conferencing Server and the Conference Control
148 Client. The objective is to provide an informational base reference
149 for protocol developers, software developers and researchers.
151 This document focuses on the interaction between the Conference (and
152 Media) Control Client and the Conferencing System, specifically the
153 Conferencing Server. The scenarios are based on those described in
154 the XCON framework, many of which are based on the advanced
155 conferencing capabilities described in the XCON scenarios.
156 Additional scenarios have been added to provide examples of other
157 real life scenarios that are anticipated to be supported by the
158 framework. With the exception of an initial example with media
159 control messaging, the examples do not include the details for the
160 media control [I-D.ietf-mediactrl-mixer-control-package], call
161 signaling or binary floor control [RFC4582] protocols. This document
162 references the scenarios in the Media Control call flows
163 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
164 [RFC4579] and binary floor control protocol documents.
166 The rest of this document is organized as follows. Section 4
167 presents an overview on CCMP, together with some implementation-
168 related details and related matters like HTTP transport and
169 notifications. Section 5 presents the reader with examples showing
170 the different approaches CCMP provides to create a new conference.
171 Section 6 more generally addresses the different user-related
172 manipulations that can be achieved by means of CCMP, by presenting a
173 number of interesting scenarios. Section 7 addresses the several
174 scenarios that may involve the use of sidebars. Section 8 shows how
175 CCMP can be used to remove conferences and users from the system.
176 Finally, Section 10 provides a few details for what concerns the
177 Security Considerations when it comes to implementing CCMP.
179 4. Working with CCMP
181 This section provides a brief introduction as to how the Centralized
182 Conferencing Manipulation Protocol (CCMP) [I-D.ietf-xcon-ccmp] works
183 and how it can be transported across a network. A typical CCMP
184 interaction focusing on relevant aspects of the client-server
185 communication is described. Please note that this section assumes
186 the reader has an understanding of and has read the CCMP document.
187 This section is intended to help the reader understand the actual
188 protocol interactions.
190 First a description of the protocol itself is provided Section 4.1,
191 including some implementation considerations. In Section 4.2, an
192 effective CCMP interaction is presented by exploiting HTTP as a
193 transport. Finally, notifications are described in Section 4.3.
195 The document then presents and describes some actual flows in detail
196 in the sections to follow.
198 4.1. CCMP and the Data Model
200 CCMP is an XML-based protocol. It has been designed as a request/
201 response protocol. It is completely stateless, which means
202 implementations can safely handle transactions independently from
203 each other.
205 The protocol allows for the manipulation of conference objects and
206 related users. This manipulation allows a Conferencing Client
207 (briefly CMCC in all the following sections) to create, update and
208 remove basically everything that is related to the objects handled by
209 a conferencing system. This is reflected in the allowed operations
210 (retrieve, create, update, delete) and the specified request types
211 (ranging from the manipulation of blueprints and conferences to users
212 and sidebars). For instance, CCMP provides ways to:
214 o retrieve the list of registered and/or active conferences in the
215 system;
217 o create new conferences by exploiting to several different
218 approaches;
220 o add/remove users to/from a conference;
222 o update a conference with respect to all of its aspects;
224 and so on.
226 While CCMP acts as the means to manipulate conference objects, CCMP
227 does not define these conference objects. A separate document
228 specifies how a conference object and all its components have to be
229 constructed: the Conference Information Data Model for Centralized
230 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP,
231 depending upon the request type and the related operation, carries
232 pieces of conference objects (or any object as a whole) according to
233 the aforementioned specification. This means that any implementation
234 aiming at being compliant with CCMP has to make sure that the
235 transported objects are completely compliant with the Data Model
236 specification and coherent with the constraints defined therein. To
237 make this clearer, there are elements that are mandatory in a
238 conference object: issuing a syntactically correct CCMP request that
239 carries a wrong conference object is doomed to result in a failure.
240 For this reason, it is suggested that the interested implementors
241 take special care in carefully checking the Data Model handlers as
242 well in order to avoid potential mistakes.
244 However, there are cases when a mandatory element in the Data Model
245 cannot be assigned in a conference object by a CCMP user. For
246 example, a CMCC may be requesting the direct creation of a new
247 conference: in this case, a conference object assumes an 'entity'
248 element uniquely identifying the conference to be in place. Thus,
249 the CMCC has no way to know a priori what the entity will be, since
250 it is generated by the ConfS after the request. For scenarios like
251 this one, the CCMP specification describes the use of a dedicated
252 placeholder wildcard (i.e., AUTO_GENERATE_X, where X is an integer)
253 to make the conference object compliant with the Data Model: the
254 wildcard would then be replaced by the ConfS with the right value.
256 4.2. Using HTTP/TLS as a transport
258 The CCMP requires that implementations support HTTP/TLS as the
259 transport mechanism. Per the CCMP, a CMCC sends a request as part of
260 an HTTPS POST message, and the ConfS would reply with a 200 OK HTTPS
261 response. In both cases, the HTTPS messages carry the CCMP messages
262 as payload, which is reflected in the Content-Type message
263 (application/ccmp+xml). Figure 1 presents a ladder diagram of such
264 interaction, which is followed by a dump of the exchanged HTTPS
265 messages for further analysis. The examples in the remainder of this
266 document show only the CCMP interactions.
268 CMCC ConfS
269 | |
270 | 1. HTTPS POST (CCMP request) |
271 |--------------------------------------------->|
272 | |
273 | |--+ Parse request,
274 | | | update object
275 | |<-+ and reply
276 | |
277 | 2. 200 OK (CCMP response) |
278 |<---------------------------------------------|
279 | |
280 |--+ Parse response and |
281 | | update local copy |
282 |<-+ of conference object |
283 | |
284 . .
285 . .
287 Figure 1: CCMP on HTTPS
289 Per the protocol dump in the following lines, the CMCC has issued a
290 CCMP request (a blueprintRequest with a 'retrieve' operation) towards
291 the Conferencing Server (ConfS). The request has been carried as
292 payload of an HTTPS POST (message 1.) towards a previously known
293 location. The mandatory 'Host' header has been specified, and the
294 'Content-Type' header has been correctly set as well (application/
295 ccmp+xml).
297 The ConfS, in turn, has handled the request and replied accordingly.
298 The response (a blueprintResponse with a successful response code)
299 has been carried as payload of a 200 OK HTTPS response (message 2.).
300 As before, the 'Content-Type' header has been correctly set
301 (application/ccmp+xml).
303 1. CMCC -> ConfS (HTTPS POST, CCMP request)
304 ------------------------------------------
305 POST /Xcon/Ccmp HTTP/1.1
306 Content-Length: 657
307 Content-Type: application/ccmp+xml
308 Host: example.com:443
309 Connection: Keep-Alive
310 User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
312
313
317
319 xcon-userid:Alice@example.com
320 xcon:AudioRoom@example.com
321 retrieve
322
323
324
326 2. CMCC <- ConfS (200 to POST, CCMP response)
327 ---------------------------------------------
328 HTTP/1.1 200 OK
329 X-Powered-By: Servlet/2.5
330 Server: Sun GlassFish Communications Server 1.5
331 Content-Type: application/ccmp+xml;charset=ISO-8859-1
332 Content-Length: 1652
333 Date: Thu, 04 Feb 2010 14:47:56 GMT
335
336
340
342 xcon-userid:Alice@example.com
343 xcon:AudioRoom@example.com
344 retrieve
345 200
346 success
347
348
349
350 AudioRoom
351 2
352
353
354 audio
355
356
357
358
359 allow
360
361
362 confirm
363
364
365
366
367
368
369
370
371
373 For completeness, the following provides some details of the CCMP
374 interaction. Despite the simplicity of the request, this flow
375 provides some relevant information on how CCMP messages are built.
376 Specifically, both the request and the response share a subset of the
377 message:
379 o confUserID: this element, provided by the CMCC, refers to the
380 requester by means of his XCON-USERID; except in a few scenarios
381 (presented in the following sections) this element must always
382 contain a valid value;
384 o confObjID: this element refers to the target conference object,
385 according to the request in place;
387 o operation: this element specifies the operation the CMCC wants to
388 perform according to the specific request type.
390 Besides those elements, the CMCC (let's say Alice, whose 'confUserID'
391 is 'xcon-userid:Alice@example.com') has also provided an additional
392 element, 'blueprintRequest'. The name of that element varies
393 according to the request type the CMCC is interested in. In this
394 specific scenario, the CMCC was interested in acquiring details
395 concerning a specific blueprint (identified by its XCON-URI
396 'xcon:AudioRoom@example.com', as reflected in the provided
397 'confObjID' target element), and so the request consisted in an empty
398 'blueprintRequest' element. It will be clearer in the following
399 sections that different request types may require different elements
400 and, as a consequence, different content.
402 Considering the request was a 'blueprintRequest', the ConfS has
403 replied with a 'blueprintResponse' element. This element includes a
404 complete dump of the conference object (compliant with the Data
405 Model) describing the requested blueprint.
407 Without providing additional details of this interaction, it is worth
408 noting that this was the example of the simplest CCMP communication
409 that could take place between a CMCC and a ConfS, a blueprintRequest:
410 this scenario will be described in more detail in Section 5.2.
412 4.3. Conference Notifications
414 The XCON framework [RFC5239] identifies several different possible
415 protocol interactions between a conferencing server and a
416 conferencing client. One of those interactions is generically called
417 "Notification Protocol" providing a mechanism for all clients
418 interested in being informed by the server whenever something
419 relevant happens in a conference. When SIP is used as the call
420 signaling protocol in a CCMP implementation, the XCON Event Package
421 [I-D.ietf-xcon-event-package], which extends the SIP Event Package
422 for Conference State [RFC4575] must be supported. A SIP client uses
423 the SIP SUBSCRIBE message for the XCON Event Package to subscribe to
424 notifications related to a specific conference. A SIP client would
425 receive notifications describing all the changes to the document via
426 SIP NOTIFY message. An example ladder diagram is presented in
427 Figure 2: in this figure, we assume a CMCC has updated a conference
428 object, and a previously subscribed SIP client is notified of the
429 update.
431 CMCC ConfS UAC
432 | | |
433 | | 1. SIP SUBSCRIBE |
434 | |<--------------------------|
435 | Handle +--| |
436 | new | | |
437 | subscription +->| 2. SIP 200 OK |
438 | |-------------------------->|
439 | | |
440 . . .
441 . . .
442 | | |
443 | 3. CCMP (add user) | |
444 |---------------------->| |
445 | |--+ Add user |
446 | | | to conf. |
447 | |<-+ object |
448 | 4. CCMP (success) | |
449 |<----------------------| |
450 | | 5. SIP NOTIFY (changes) |
451 | |-------------------------->|
452 | | 6. SIP 200 OK |
453 | |<--------------------------|
454 | | |
455 . . .
456 . . .
458 Figure 2: XCON Event Package: SIP notifications
460 The detailed flows in this document generically present a
461 notification, when appropriate, but do not include the SIP messaging
462 details.
464 5. Conference Creation
466 This section provides details associated with the various ways in
467 which a conference can be created using CCMP and the XCON framework
468 constructs. As previously mentioned, the details of the media
469 control, call signaling and floor control protocols, where
470 applicable, are annotated in the flows without showing all the
471 details. This also applies to CCMP, whose flows are related to the
472 protocol alone, hiding any detail concerning the transport that may
473 have been used (e.g., HTTP). However, for clarification purposes,
474 the first example Section 5.1 provides the details of the media
475 control messaging with the standard annotation used throughout the
476 remainder of this document. In subsequent flows, only this
477 annotation (identified by lower case letters) is included and the
478 reader is encouraged to refer to the call flows in the relevant
479 documents for details about the other protocols. The annotations for
480 the call signaling are on the left side of the conferencing server
481 vertical bar and those for the media control messaging are on the
482 right side.
484 5.1. Basic Conference Creation
486 The simplest manner in which a conference can be created is
487 accomplished by the client sending a "confRequest" message with the
488 "create" operation as the only parameter to the conference server,
489 together with the "confUserID" associated with the requesting client
490 itself. This results in the creation of a default conference, with
491 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
492 in the form of the "confUserID" parameter (the same one already
493 present in the request) and the data for the conference object in the
494 "confInfo" parameter all returned in the "confResponse" message.
495 This example also adds the issuing user to the conference upon
496 creation with the "method" attribute in the element of
497 set to "dial out".
499 The specific data for the conference object is returned in the
500 "confResponse" message in the "confInfo" parameter. This allows the
501 client (with the appropriate authorization) to manipulate these data
502 and add additional participants to the conference, as well as change
503 the data during the conference. In addition, the client may
504 distribute the conferencing information to other participants
505 allowing them to join, the details of which are provided in
506 additional flows. Please notice that, according to the CCMP
507 specification, the return of the new conference data in the
508 "confInfo" parameter is not mandatory: if the "confInfo" parameter of
509 the successful confResponse/create is not included in the response, a
510 subsequent confRequest/retrieve of the returned "confObjID" can be
511 triggered to provide the requesting client with the detailed
512 conference description.
514 Clients that are not XCON-aware can join the conference using a
515 specific signaling interface such as SIP [RFC3261] (using the
516 signaling interface to the conference focus as described in
517 [RFC4579]), or other supported signaling protocols, being XCON
518 agnostic with respect to them. However, these details are not shown
519 in the message flows. The message flows in this document identify
520 the point in the message flows at which this signaling occurs via the
521 lower case letter items (i.e., (a)...(x)) along with the appropriate
522 text for the processing done by the conferencing server.
524 As previously described, this example also shows how the conferencing
525 system may make use of other standard protocol components for
526 complete functionality. An example of that is the MEDIACTRL
527 specification, which allows the conferencing system to configure
528 conference mixes, IVR dialogs and all sort of media-related
529 interactions an application like this may need. In order to provide
530 the reader with some insight on these interactions, the conferencing
531 system in this example also configures and starts a mixer via
532 MEDIACTRL as soon as the conference is created (transactions A1 and
533 A2), and attaches clients to it when necessary (e.g., when CMCC1
534 joins the conference by means of SIP signaling, its media channels
535 are attached to the Media Server using MEDIACTRL in B1/B2). Note,
536 that the MEDIACTRL interfaces are NOT shown in the remaining call
537 flows in this document, but rather follow the same annotation as with
538 the SIP signaling such that (b) correlates with the A1 and A2
539 transactions and (d) correlates with the B1 and B2 transactions.
541 CMCC1 CMCC2 CMCCx ConfS MS
542 | | | | |
543 |(1)confRequest(confUserID, create) | |
544 |-------------------------------------->| |
545 | | (a)Create +---| |
546 | | |Conf | | |
547 | | |Object | | |
548 | | |& IDs +-->| |
549 | | | | A1. CONTROL |
550 | | | |+++++++++++>>|
551 | | | |(create conf)|--+ (b)
552 | | | | | | create
553 | | | | | | conf and
554 | | | | A2. 200 OK |<-+ its ID
555 | | | |<<+++++++++++|
556 | | | |(confid=Y) |
557 |(2)confResponse(confUserID,confObjID, | |
558 | create, 200, success, | |
559 | version, confInfo) | |
560 |<--------------------------------------| |
561 | | | | |
562 | | (c) Focus +---| |
563 | | sets up | | |
564 | | signaling | | |
565 | | to CMCC1 +-->| |
566 | | | | |
567 | | | | B1. CONTROL |
568 | | | |+++++++++++>>|
569 | | | | (join CMCC1 |
570 | | | | <->confY) |
571 | | | | |
572 | | | | |--+(d) join
573 | | | | | | CMCC1 &
574 | | | | B2.200 OK |<-+ conf Y
575 | | | |<<+++++++++++|
576 | | | | |
577 |<<#################################################>>|
578 | Now the CMCC1 is mixed in the conference |
579 |<<#################################################>>|
580 | | | | |
581 |******CMCC1 may then manipulate conference data *****|
582 |****** and add addt'l users, etc. | *****|
583 ' ' ' ' '
584 ' ' ' ' '
585 ' ' ' ' '
586 Figure 3: Create Basic Conference - Complete flow
588 1. confRequest/create message (Alice creates a default conference)
590
591
595
598 xcon-userid:Alice@example.com
599 create
600
601
602
604 2. confResponse/create message ("success", created conference
605 object returned)
607
608
612
615 xcon-userid:Alice@example.com
616 xcon:8977794@example.com
617 create
618 200
619 success
620 1
621
622
623
624
625 Default conference initiated by Alice
626
627
628
629
630 xcon:8977794@example.com
632
633
634 Conference XCON-URI
635
636
637
638 10
639
640
641
642 audio
643
644
645
646
647 false
648
649
650 allow
651
652
654
655
656
657
658
659
661 Figure 4: Create Basic Conference Detailed Messaging
663 5.2. Conference Creation using Blueprints
665 The previous example showed the creation of a new conference using
666 default values. This means the client provided no information about
667 how she wanted the conference to be created. The XCON framework (and
668 CCMP as a consequence) allows for the implementation of templates.
669 These templates are called "conference blueprints", and are basically
670 conference objects with pre-defined settings. This means that a
671 client might get a list of blueprints, choose the one that more fits
672 his needs, and use the chosen blueprint to create a new conference.
674 This section Figure 5 provides an example of one client, "Alice",
675 discovering the conference blueprints available for a particular
676 conferencing system and creating a conference based on the desired
677 blueprint. In particular, Alice is interested in those blueprints
678 suitable to represent a "video-conference", i.e., a conference in
679 which both audio and video are available, so she makes use of the
680 filter mechanism provided by CCMP to make a selective blueprints
681 retrieve request. This results in three distinct CCMP transactions.
683 CMCC "Alice" ConfS
684 | |
685 | (1) blueprintsRequest |
686 | (confUserID,xpathFilter) |
687 |------------------------------>|
688 | |
689 | (2) blueprintsResponse |
690 | (confUserID, |
691 | 200, success, |
692 | blueprintsInfo) |
693 | |
694 |<------------------------------|
695 | |
696 |--+ |
697 | | choose preferred |
698 | | blueprint from the |
699 | | list (blueprintName) |
700 |<-+ |
701 | |
702 | (3) blueprintRequest |
703 | (confUserID,confObjID, |
704 | retrieve) |
705 |------------------------------>|
706 | |
707 | 4) blueprintResponse |
708 | (confUserID,confObjID,|
709 | retrieve, 200, |
710 | success, confInfo) |
711 |<------------------------------|
712 | |
713 | (5) confRequest(confUserID, |
714 | confObjID,create) |
715 |------------------------------>|
716 | |
717 | (a)Create +---|
718 | Conf | |
719 | Object | |
720 | & IDs +-->|
721 | |--+ (b) MS
722 | | | creates
723 | | | conf and
724 | |<-+ its ID
725 | | (confid=Y)
726 |(6) confResponse |
727 | (confUserID, confObjID*, |
728 | create, 200, success) |
729 |<------------------------------|
730 | |
731 | |
732 | |
733 . .
734 . .
736 Figure 5: Client Creation of Conference using Blueprints
738 1. Alice first sends a "blueprintsRequest" message to the
739 conferencing system identified by the conference server discovery
740 process. This request contains the "confUserID" of the user
741 issuing the request (Alice's XCON-USERID) and the "xpathFilter"
742 parameter by which Alice specifies she desires to obtain only
743 blueprints providing support for both audio and video: for this
744 purpose, the xpath query contained in this field is: "/
745 conference-info[conference-description/available-media/entry/
746 type='audio' and conference-description/available-media/entry/
747 type='video'"] . Upon receipt of the "blueprintsRequest", the
748 conferencing system would first ensure, on the basis of the
749 "confUserID" parameter, that Alice has the appropriate authority
750 based on system policies to receive the requested kind of
751 blueprints supported by that system.
753 2. All blueprints that Alice is authorized to use are returned in a
754 "blueprintsResponse" message in the "blueprintsInfo" element.
756 3. Upon receipt of the "blueprintsResponse" containing the
757 blueprints, Alice determines which blueprint to use for the
758 conference to be created. Alice sends a "blueprintRequest"
759 message to get the specific blueprint as identified by the
760 "confObjID".
762 4. The conferencing system returns the "confInfo" associated with
763 the specific blueprint as identified by the "confObjID" in the
764 "blueprintResponse" message.
766 5. Alice finally sends a "confRequest" with a "create" operation to
767 the conferencing system to create a conference reservation
768 cloning the chosen blueprint. This is achieved by writing the
769 blueprint's XCON-URI in the "confObjID" parameter.
771 6. Upon receipt of the "confRequest" message with a "create"
772 operation, the conferencing system uses the received blueprint to
773 clone a conference, allocating a new XCON-URI (again called
774 "confObjID*" in the example). The conferencing server then sends
775 a "confResponse" message including the new "confObjID*"
776 associated with the newly created conference instance. Upon
777 receipt of the "confResponse" message, Alice can now add other
778 users to the conference.
780 1. blueprintsRequest message (Alice requires the list of the
781 available blueprints with video support)
783
784
787
789 xcon-userid:Alice@example.com
790
791 /conference-info[conference-description/
792 available-media/entry/type='audio'
793 and
794 conference-description/available-media/entry/type='video']
795
796
797
798
800 2. blueprintsResponse message (the server provides a
801 descriptions of the available blueprints
802 fitting Alice's request)
804
805
809
812 xcon-userid:Alice@example.com
813 200
814 success
815
816
817
818 xcon:VideoRoom@example.com
819 VideoRoom
820 Video Room:
821 conference room with public access,
822 where both audio and video are available,
823 4 users can talk and be seen at the same time,
824 and the floor requests are automatically accepted.
825
826
827
828 xcon:VideoConference1@example.com
829 VideoConference1
830 Public Video Conference: conference
831 where both audio and video are available,
832 only one user can talk
833
834
835
836
837
838
840 3. blueprintRequest/retrieve message (Alice wants the
841 "VideoRoom" blueprint)
843
844
848
850 xcon-userid:Alice@example.com
851 xcon:VideoRoom@example.com
852 retrieve
853
854
855
857 4. blueprintResponse/retrieve message ("VideoRoom"
858 conference object returned)
860
861
865
867 xcon-userid:Alice@example.com
868 xcon:VideoRoom@example.com
869 retrieve
870 200
871 success
872
873
874
875 VideoRoom
876 4
877
878
879 audio
880
881
882 video
883
884
885
886
887 allow
888
889
890 confirm
891
892
893
894 audioLabel
895
896
897 videoLabel
898
899
900
901
902
903
904
906 5. confRequest/create message (Alice clones the "VideoRoom" blueprint)
907
908
912
915 xcon-userid:Alice@example.com
916 xcon:VideoRoom@example.com
917 create
918
919
920
922 6. confResponse/create message (cloned conference
923 object returned)
925
926
930
933 xcon-userid:Alice@example.com
934 xcon:8977794@example.com
935 create
936 200
937 success
938 1
939
940
941
942
943 New conference by Alice cloned from VideoRoom
944
945
946
947
948 xcon:8977794@example.com
949
950
951 conference xcon-uri
952
953
954 8601
956
957
958
959 10
960
961
962 audio
963
964
965 video
966
967
968
969
970 allow
971
972
973
974 confirm
975
976
977 11
978
979
980 12
981
982
983
984
985
986
987
989 Figure 6: Create Conference (Blueprint) Detailed Messaging
991 5.3. Conference Creation using User-Provided Conference Information
993 A conference can also be created by the client sending a
994 "confRequest" message with the "create" operation, along with the
995 desired data in the form of the "confInfo" parameter for the
996 conference to be created. The request also includes the "confUserID"
997 of the requesting entity.
999 This approach allows for a client (in this example Alice) to
1000 completely describe what the conference object should look like,
1001 without relying on defaults or blueprints: e.g., which media should
1002 be available, the topic, the users allowed to join, any scheduling-
1003 related information and so on. This can be done by providing in the
1004 creation request a full conference object for the server to parse.
1006 This "confInfo" parameter must comply with the Data Model
1007 specification. This means that the "entity" attribute is mandatory,
1008 and cannot be missing in the document. However, in this example the
1009 client is actually requesting the creation of a new conference, which
1010 doesn't exist yet, so the "entity" attribute is unknown. As
1011 discussed in Section 4.1, the CCMP protocol allows for the use of a
1012 wildcard placeholder. This placeholder
1013 ("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure
1014 the "confInfo" element is compliant with the Data Model, and would
1015 subsequently be replaced by the conferencing system with the actual
1016 value. Thus, when the conferencing system actually creates the
1017 conference, a valid "entity" value is created for it as well, which
1018 takes the place of the wildcard value when the actual conference
1019 object provided by the client is populated.
1021 To give a flavor of what could be added to the conference object, we
1022 assume Alice is also interested in providing scheduling-related
1023 information. So, in this example, Alice also specifies by the
1024 element included in the "confInfo" that the
1025 conference she wants to create has to occur on a certain date
1026 spanning from a certain start time to a certain stop time and has to
1027 be replicated weekly.
1029 Moreover, Alice indicates by means of the that
1030 at the start time Bob, Carol and herself have to be called by the
1031 conferencing system to join the conference (in fact, for each
1032 corresponding to one of the above-mentioned clients, the
1033 "method" attribute is set to "dial-out").
1035 Once Alice has prepared the "confInfo" element and sent it as part of
1036 her request to the server, if the conferencing system can support
1037 that specific type of conference (capabilities, etc.), then the
1038 request results in the creation of a conference. We assume the
1039 request has been successful, and as a consequence XCON-URI in the
1040 form of the "confObjID" parameter and the XCON-USERID in the form of
1041 the "confUserID" parameter (again, the same as the requesting entity)
1042 are returned in the "confResponse" message.
1044 In this example, the created conference object is not returned in the
1045 successful "confResponse" in the "confInfo" parameter. Nevertheless,
1046 Alice could still retrieve the actual conference object by issuing a
1047 "confRequest" with a "retrieve" operation on the returned
1048 "confObjID". Such a request would show how, as described at the
1049 beginning of this section, the "entity" attribute of the conference
1050 object in "confInfo" is replaced with the actual information (i.e.,
1051 "xcon:6845432@example.com").
1053 Alice Bob Carol ConfS
1054 | | | |
1055 | | | |
1056 |(1)confRequest(confUserID, | |
1057 | create, confInfo) | |
1058 | | | |
1059 |-------------------------------------->|
1060 | | | |
1061 | | (a)Create +---|
1062 | | |Conf | |
1063 | | |Object | |
1064 | | |& IDs +-->|
1065 | | | |--+ (b) MS
1066 | | | | | creates
1067 | | | | | conf and
1068 | | | |<-+ its ID
1069 | | | | (confid=Y)
1070 |(2)confResponse(confUserID,| |
1071 | confObjID, create, | |
1072 | 200, success, version) |
1073 |<--------------------------------------|
1074 | | | |
1075 ===========================================
1076 ... ... ... ...
1077 ========== START TIME OCCURS ==============
1078 | | (c) Focus +---|
1079 | | sets up | |
1080 | | signaling | |
1081 | | to Alice +-->|
1082 | | | |
1083 | | | |--+(d) MS joins
1084 | | | | | Alice &
1085 | | | |<-+ conf Y
1086 | | | |
1087 | | | |
1088 |<<###################################>>|
1089 | Alice is mixed in the conference |
1090 |<<###################################>>|
1091 | | | |
1092 | | (e)Focus +---|
1093 | | sets up | |
1094 | | signaling | |
1095 | | to Bob | |
1096 | | | +-->|
1097 | | | |
1098 | | | |--+(f)MS joins
1099 | | | | | Bob &
1100 | | | |<-+ conf Y
1101 | | | |
1102 | |<<###################>>|
1103 | | Bob is mixed too |
1104 | |<<###################>>|
1105 | | | |
1106 | | (g )Focus +---|
1107 | | sets up | |
1108 | | signaling | |
1109 | | to Carol | |
1110 | | CMCCx +-->|
1111 | | | |
1112 | | | |--+(h)MS joins
1113 | | | | | CMCCx &
1114 | | | |<-+ conf Y
1115 | | | |
1116 | | |<<#######>>|
1117 | | |Carol mixed|
1118 | | |<<#######>>|
1119 | | | |
1120 | | | |
1121 | | | |
1122 |<***All parties connected to conf Y***>|
1123 | | | |
1124 | | | |
1125 " " " "
1126 " " " "
1127 " " " "
1129 Figure 7: Create Basic Conference from user provided conference-info
1131 1. confRequest/create message (Alice proposes a conference object
1132 to be created)
1134
1135
1139
1142 xcon-userid:Alice@example.com
1143 create
1144
1145
1146
1147
1148 Dial-out conference initiated by Alice
1149
1150 10
1151
1152
1153 audio
1154
1155
1156
1157
1158
1159 BEGIN:VCALENDAR
1160 VERSION:2.0
1161 PRODID:-//Mozilla.org/NONSGML
1162 Mozilla Calendar V1.0//EN
1163 BEGIN:VEVENT
1164 DTSTAMP: 20100127T140728Z
1165 UID: 20100127T140728Z-345FDA-alice@example.com
1166 ORGANIZER:MAILTO:alice@example.com
1167 DTSTART:20100127T143000Z
1168 RRULE:FREQ=WEEKLY
1169 DTEND: 20100127T163000Z
1170 END:VEVENT
1171 END:VCALENDAR
1172
1173
1175 2010-01-27T14:29:00Z
1176
1177
1179 2010-01-27T16:31:00Z
1180
1181
1182 2010-01-27T15:30:00Z
1183
1184
1185
1186
1187
1188 allow
1189
1190
1192
1194
1196
1197
1198
1199
1200
1201
1203 2. confResponse/create message (200, "success")
1205
1206
1210
1213 xcon-userid:Alice@example.com
1214 xcon:6845432@example.com
1215 create
1216 200
1217 success
1218 1
1219
1220
1221
1223 Figure 8: Create Basic Conference Detailed Messaging
1225 5.4. Cloning an Existing Conference
1227 A client can also create another conference by cloning an existing
1228 conference, such as an active conference or conference reservation.
1229 This approach can be seen as a logical extension of the creation of a
1230 new conference using a blueprint: the difference is that, instead of
1231 cloning the pre-defined settings listed in a blueprint, the settings
1232 of an existing conference would be cloned.
1234 In this example, the client sends a "confRequest" message with the
1235 "create" operation, along with the "confUserID" and a specific
1236 "confObjID", from which a new conference is to be created by cloning
1237 an existing conference.
1239 An example of how a client can create a conference based on a
1240 blueprint is provided in Section 5.2. The manner by which a client
1241 in this example might learn about a conference reservation or active
1242 conferences is similar to the first step in the blueprint example,
1243 with the exception of querying for different types of conference
1244 objects supported by the specific conferencing system. For example,
1245 in this example, the client clones a conference reservation (i.e., an
1246 inactive conference).
1248 If the conferencing system can support a new instance of the specific
1249 type of conference (capabilities, etc.), then the request results in
1250 the creation of a conference, with an XCON-URI in the form of a new
1251 value in the "confObjID" parameter to reflect the newly cloned
1252 conference object returned in the "confResponse" message.
1254 Alice ConfS
1255 | |
1256 |(1)confRequest(confUserID, |
1257 | confObjID, create) |
1258 |------------------------------>|
1259 | (a)Create +---|
1260 | Conf | |
1261 | Object | |
1262 | & IDs +-->|
1263 | |--+ (b) MS
1264 | | | creates
1265 | | | conf and
1266 | |<-+ its ID
1267 | | (confid=Y)
1268 | |
1269 |(2)confResponse(confUserID, |
1270 | confObjID*,create, |
1271 | 200, success, |
1272 | version, confInfo) |
1273 | |
1274 |<------------------------------|
1275 | |
1277 Figure 9: Create Basic Conference - Clone
1279 1. Alice, a conferencing system client, sends a confRequest message
1280 to clone a conference based on an existing conference
1281 reservation. Alice indicates this conference should be cloned
1282 from the specified parent conference represented by the
1283 "confObjID" in the request.
1285 2. Upon receipt of the confRequest message containing a "create"
1286 operation and "confObjID", the conferencing system ensures that
1287 the "confObjID" received is valid. The conferencing system
1288 determines the appropriate read/write access of any users to be
1289 added to a conference based on this "confObjID" (using
1290 membership, roles, etc.). The conferencing system uses the
1291 received "confObjID" to clone a conference reservation. The
1292 conferencing system also reserves or allocates a new "confObjID"
1293 (called "confObjID*" in Figure 9) to be used for the cloned
1294 conference object. This new identifier is of course different
1295 from the one associated with the conference to be cloned, since
1296 it represents a different conference object. Any subsequent
1297 protocol requests from any of the members of the conference must
1298 use this new identifier. The conferencing system maintains the
1299 mapping between this conference ID and the parent conference
1300 object ID associated with the reservation through the conference
1301 instance, and this mapping is explicitly addressed through the
1302 "cloning-parent" element of the "conference-description" in the
1303 new conference object.
1305 1. confRequest/create message (Alice clones an existing conference)
1307
1308
1312
1315 xcon-userid:Alice@example.com
1316 xcon:6845432@example.com
1317 create
1318
1319
1320
1322 2. confResponse/create message (created conference
1323 object returned)
1325
1326
1330
1333 xcon-userid:Alice@example.com
1334 xcon:8977794@example.com
1335 create
1336 200
1337 success
1338 1
1339
1340
1341
1342
1343 New conference by Alice cloned from 6845432
1344
1345 10
1346
1347
1348 audio
1349
1350
1351
1352 xcon:6845432@example.com
1353
1354
1355
1356 allow
1357
1358
1360
1362
1364
1365
1366
1367
1368 confirm
1369
1370
1371 11
1372
1373
1374
1375
1376
1377
1378
1380 Figure 10: Create Basic Conference (Clone) Detailed Messaging
1382 6. Conference Users Scenarios and Examples
1384 Section 5 showed examples describing the several different ways a
1385 conference might be created using CCMP. This section focuses on
1386 user-related scenarios, i.e., typical scenarios that may occur during
1387 the lifetime of a conference, like adding new users and handling
1388 their media. The following scenarios are based on those documented
1389 in the XCON framework. The examples assume that a conference has
1390 already been correctly established, with media, if applicable, per
1391 one of the examples in Section 5.
1393 6.1. Adding a Party
1395 In this example, Alice wants to add Bob to an established conference.
1396 In the following example we assume Bob is a new user of the system,
1397 which means Alice also needs to provide some details about him. In
1398 fact, the case of Bob already present as a user in the conferencing
1399 system is much easier to address, and will be discussed later on.
1401 "Alice" "Bob"
1402 CMCC1 CMCC2 CMCCx ConfS
1403 | | | |
1404 |(1) userRequest(confUserID,| |
1405 | confObjID, create, | |
1406 | userInfo) | | |
1407 |-------------------------------------->|
1408 | | | |
1409 | | (a) Create +---|
1410 | | | Bob | |
1411 | | | as a | |
1412 | | | user +-->|
1413 | | | |
1414 |(2) userResponse(confUserID, confObjID |
1415 | create, 200, success, userInfo) |
1416 |<--------------------------------------|
1417 | | | |
1418 | | | (b) Focus |
1419 | | | sets up |
1420 | | | signaling |
1421 | | | to Bob |
1422 | |<----------------------|
1423 | | | |
1424 | | | (c) Notify|
1425 | | | ("Bob just|
1426 | | | joined") |
1427 | | |<----------|
1428 | | | |
1429 ' ' ' '
1430 ' ' ' '
1431 ' ' ' '
1433 Figure 11: Client Manipulation of Conference - Add a party
1435 1. Alice sends a userRequest message with an operation of "create"
1436 to add Bob to the specific conference as identified by the
1437 "confObjID". The "create" operation also makes sure that Bob is
1438 created as a user in the whole conferencing system. This is done
1439 by adding in the request a "userInfo" element describing Bob as a
1440 user. This is needed in order to let the conferencing system be
1441 aware of Bob's characteristics. In case Bob was already a
1442 registered user, Alice would just have referenced him through his
1443 XCON-USERID in the "entity" attribute of the "userInfo" field,
1444 without providing additional data. In fact, that data
1445 (including, for instance, Bob's SIP-URI to be used subsequently
1446 for dial-out) would be obtained by referencing the extant
1447 registration. The conference server ensures that Alice has the
1448 appropriate authority based on the policies associated with that
1449 specific conference object to perform the operation. As
1450 mentioned before, a new Conference User Identifier is created for
1451 Bob, and the "userInfo" is used to update the conference object
1452 accordingly. As already seen in Section 5.3, a placeholder
1453 wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
1454 messages below) is used for the "entity" attribute of the
1455 "userInfo" element, to be replaced by the actual XCON-USERID
1456 later on;
1458 2. Bob is successfully added to the conference object, and an XCON-
1459 USERID is allocated for him ("xcon-userid:Bob@example.com"); this
1460 identifier is reported in the response as part of the "entity"
1461 element of the returned "userInfo";
1463 3. In the presented example, the call signaling to add Bob to the
1464 conference is instigated through the Focus as well. As noted
1465 previously, this is implementation specific. In fact, a
1466 conferencing system may accomplish different actions after the
1467 user creation, just as it may do nothing at all. Among the
1468 possible actions, for instance, Bob may be added as a
1469 element to the element, whose joining
1470 "method" may be either "dial-in" or "dial-out". Besides, out-of-
1471 band notification mechanisms may be involved as well, e.g., to
1472 notify Bob via mail of the new conference, including details as
1473 the date, password, expected participants and so on (see
1474 Section 4.3).
1476 Once Bob has been successfully added to the specified conference,
1477 per updates to the state, and depending upon the policies, other
1478 participants (including Bob himself) may be notified of the
1479 addition of Bob to the conference via the Conference Notification
1480 Service in use.
1482 1. userRequest/create message (Alice adds Bob)
1484
1485
1488
1490 xcon-userid:Alice@example.com
1491 xcon:8977878@example.com
1492 create
1493
1494
1495 Bob
1496
1497
1498 mailto:bob.depippis@example.com
1499 Bob's email
1500
1501
1502
1503 Bob's laptop
1504
1505
1506
1507
1508
1510 2. userResponse/create message (a new XCON-USERID is
1511 created for Bob and he is added to the conference)
1513
1514
1517
1519 xcon-userid:Alice@example.com
1520 xcon:8977878@example.com
1521 create
1522 200
1523 success
1524 10
1525
1526
1527 Bob
1528
1529
1530 mailto:bob.depippis@example.com
1531 Bob's email
1532
1533
1534
1535 Bob's laptop
1536
1537
1538
1539
1540
1541 Figure 12: Add Party Message Details
1543 6.2. Muting a Party
1545 This section provides an example of the muting of a party in an
1546 active conference. We assume that the user to mute has already been
1547 added to the conference. The document only addresses muting and not
1548 unmuting, since the latter would involve an almost identical CCMP
1549 message flow anyway. However, if any external floor control is
1550 involved, whether a particular conference client can actually mute/
1551 unmute itself, must be considered by the conferencing system.
1553 Please notice that interaction between CCMP and floor control
1554 should be carefully considered. In fact, handling CCMP- and BFCP-
1555 based media control has to be considered as multiple layers: i.e.,
1556 a participant may have the BFCP floor granted, but be muted by
1557 means of CCMP. If so, he would still be muted in the conference,
1558 and would only be unmuted if both the protocols allowed for this.
1560 Figure 13 provides an example of one client, "Alice", impacting the
1561 media state of another client, "Bob". This example assumes an
1562 established conference. In this example, Alice, whose role is
1563 "moderator" of the conference, wants to mute Bob on a medium-size
1564 multi-party conference, as his device is not muted (and he's
1565 obviously not listening to the call) and background noise in his
1566 office environment is disruptive to the conference. BFCP floor
1567 control is assumed not to be involved.
1569 Muting can be accomplished using the "mute" control in the conference
1570 object, in which case the conference server must update the settings
1571 associated with the user's media streams. Muting/unmuting can also
1572 be accomplished by directly updating the conference object with
1573 modified settings related to the target user's media streams, which
1574 is the approach shown in this example. Specifically, Bob's
1575 "userInfo" is updated by modifying its audio information
1576 (e.g., setting it to "recvonly" in case of muting), identified by the
1577 right media id.
1579 "Alice" "Bob"
1580 CMCC1 CMCC2 CMCCx ConfS MS
1581 | | | | |
1582 |(1) userRequest(subject, | | |
1583 | confUserID,confObjID, | | |
1584 | update,userInfo) | | |
1585 | | | | |
1586 |--------------------------------------->| |
1587 | | | | Mute Bob |
1588 | | | |----------------->|
1589 | | | | 200 OK |
1590 | | | |<-----------------|
1591 | | | | |
1592 | |<====== XXX Bob excluded from mix XXX ====>|
1593 | | | | |
1594 | | (a) Update +---| |
1595 | | Bob in | | |
1596 | | Data Model | | |
1597 | | (muted) +-->| |
1598 | | | | |
1599 | (2)userResponse(confUserID,confObjID, | |
1600 | update,200,success,version) | |
1601 |<---------------------------------------| |
1602 | | | | |
1603 | | | (b) Notify | |
1604 | | | ("Bob is | |
1605 | | | muted") | |
1606 | | |<-----------| |
1607 | | | | |
1608 ' ' ' ' '
1609 ' ' ' ' '
1610 ' ' ' ' '
1612 Figure 13: Client Manipulation of Conference - Mute a party
1614 1. Alice sends a userRequest message with an "update" operation and
1615 the userInfo with the "status" field in the "media" element for
1616 Bob's set to "revconly". In order to authenticate
1617 herself, Alice provides in the "subject" request parameter her
1618 registration credentials (i.e., username and password). The
1619 "subject" parameter is an optional one: its use can be systematic
1620 whenever the conferencing server envisages to authenticate each
1621 requestor. In such cases, if the client does not provide the
1622 required authentication information, the conferencing server
1623 answers with a CCMP "authenticationRequired" response message,
1624 indicating that the request cannot be processed without including
1625 the proper "subject" parameter. The Conference Server ensures
1626 that Alice has the appropriate authority based on the policies
1627 associated with that specific conference object to perform the
1628 operation. It recognizes that Alice is allowed to request the
1629 specified modification, since she is moderator of the target
1630 conference, and updates the "userInfo" in the conference object
1631 reflecting that Bob's media is not to be mixed with the
1632 conference media. If the Conference Server relies on a remote
1633 Media Server for its multimedia functionality, it subsequently
1634 changes Bob's media profile accordingly by means of the related
1635 protocol interaction with the MS. An example describing a
1636 possible way of dealing with such a situation using the Media
1637 Server Control architecture is described in
1638 [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
1639 Transactions (2)".
1641 2. A userResponse message with a "200" response-code ("success") is
1642 then sent to Alice. Depending upon the policies, the conference
1643 server may notify other participants (including Bob) of this
1644 update via any Conference Notification Service that may be in
1645 use.
1647 1. userRequest/update message (Alice mutes Bob)
1649
1650
1653
1655
1656 Alice83
1657 13011983
1658
1659 xcon-userid:Alice@example.com
1660 xcon:8977878@example.com
1661 update
1662
1663
1664
1665
1666 123
1667 recvonly
1668
1669
1670
1671
1672
1673
1675 2. userResponse/update message (Bob has been muted)
1677
1678
1681
1683 xcon-userid:Alice@example.com
1684 xcon:8977878@example.com
1685 update
1686 200
1687 success
1688 7
1689
1690
1691
1692 Figure 14: Mute Message Details
1694 6.3. Conference Announcements and Recordings
1696 This section deals with features that are typically required in a
1697 conferencing system, such as public announcements (e.g., to notify
1698 vocally that a new user joined a conference) and name recording.
1699 While this is not strictly CCMP-related (the CCMP signaling is
1700 actually the same as the one seen in Section 6.1) it is an
1701 interesting scenario to address to see how several components of an
1702 XCON-compliant architecture interact with each other to make it
1703 happen.
1705 In this example, as shown in Figure 15 Alice is joining Bob's
1706 conference that requires that she first enters a pass code. After
1707 successfully entering the pass code, an announcement prompts Alice to
1708 speak her name so it can be recorded. When Alice is added to the
1709 active conference, the recording is played back to all the existing
1710 participants. A very similar example is presented in Figure 33 of
1711 [I-D.ietf-mediactrl-call-flows].
1713 CMCC "Alice" ConfS MS
1714 | | |
1715 |(1)userRequest(confObjID, | |
1716 | create,userInfo) | |
1717 |--------------------------->| |
1718 | |--+ Alice is |
1719 | | | new in the |
1720 | |<-+ system (create |
1721 | | confUserID) |
1722 | ConfS handles +--| |
1723 | SIP signaling | | |
1724 | (Alice<->ConfS<->MS) +->| |
1725 | | |
1726 | |--+ A password is |
1727 | | | required for |
1728 | |<-+ that conference |
1729 | | |
1730 | | Request IVR menu (PIN) |
1731 | |--------------------------->|
1732 | | |
1733 |<========= MS gets PIN from Alice through DTMF =========>|
1734 | | |
1735 | | Provided PIN is... |
1736 | |<---------------------------|
1737 | Check +--| |
1738 | PIN | | |
1739 | +->| |
1740 | |--+ Alice must |
1741 | | | record her |
1742 | |<-+ name |
1743 | | |
1744 | | Request name recording |
1745 | |--------------------------->|
1746 | | |
1747 |<========= MS records Alice's audio RTP (name) =========>|
1748 | | |
1749 | | Audio recording |
1750 | |<---------------------------|
1751 | Complete +--| |
1752 | creation | | |
1753 | of Alice +->| |
1754 | | |
1755 | | |
1756 | (2)userResponse(confUserID,| |
1757 | confObjID,create,200,| |
1758 | success,version) | |
1759 |<---------------------------| |
1760 | | |
1761 Figure 15: Recording and Announcements
1763 1. Upon receipt of the userRequest from Alice to be added to Bob's
1764 conference, the conferencing system determines that a password is
1765 required for this specific conference. Thus an announcement
1766 asking Alice to enter the password is sent back. This may be
1767 achieved by means of typical IVR functionality. Once Alice
1768 enters the password, it is validated against the policies
1769 associated with Bob's active conference. The conferencing system
1770 then connects to a server which prompts and records Alice's name.
1771 The conferencing system must also determine whether Alice is
1772 already a user of this conferencing system or whether she is a
1773 new user. In this case, Alice is a new user for this
1774 conferencing system, so a Conference User Identifier (i.e., an
1775 XCON-USERID) is created for Alice. Based upon the contact
1776 information provided by Alice, the call signaling to add Alice to
1777 the conference is instigated through the Focus.
1779 2. The conference server sends Alice a userResponse message which
1780 includes the "confUserID" assigned by the conferencing system to
1781 her. This would allow Alice to later perform operations on the
1782 conference (if she were to have the appropriate policies),
1783 including registering for event notifications associated with the
1784 conference. Once the call signaling indicates that Alice has
1785 been successfully added to the specific conference, per updates
1786 to the state, and depending upon the policies, other participants
1787 (e.g., Bob) are notified of the addition of Alice to the
1788 conference via the conference notification service and an
1789 announcement is provided to all the participants indicating that
1790 Alice has joined the conference.
1792 1. userRequest/create message (A new conferencing system client,
1793 Alice, enters Bob's conference)
1795
1796
1800
1802 xcon:bobConf@example.com
1803 create
1804
1805
1806
1807
1808
1809 mailto:Alice83@example.com
1810
1811 email
1812
1813
1814
1815
1816
1817
1818
1820 2. userResponse/create (Alice provided with a new xcon-userid
1821 and added to the conference)
1823
1824
1828
1830 xcon-userid:Alice@example.com
1831 xcon:bobConf@example.com
1832 create
1833 200
1834 success
1835 5
1836
1837
1838
1839 Figure 16: Announcement Messaging Details
1841 6.4. Monitoring for DTMF
1843 Conferencing systems often also need the capability to monitor for
1844 DTMF from each individual participant. This would typically be used
1845 to enter the identifier and/or access code for joining a specific
1846 conference. This feature is often also exploited to achieve
1847 interaction between participants and the conference system for non-
1848 XCON-aware user agents (e.g., using DTMF tones to get muted/unmuted).
1850 An example of DTMF monitoring, within the context of the framework
1851 elements, is shown in Figure 15. The mediactrl architecture/
1852 protocols can be used by the conferencing system for all the DTMF
1853 interactions. Examples for DTMF interception in conference instances
1854 are presented in [I-D.ietf-mediactrl-call-flows].
1856 6.5. Entering a password-protected conference
1858 Some conferences may require a password to be provided by a user who
1859 wants to manipulate the conference objects (e.g., join, update,
1860 delete) via CCMP. In this case, a password would be included in the
1861 element related to the conference XCON-URI in
1862 the appropriate entry and must be then included in
1863 the "conference-password" field in the CCMP request addressed to a
1864 specific conference.
1866 In the following example, Alice, a conferencing system client,
1867 attempts to join a password-protected conference.
1869 1. Alice sends a userRequest message with a "create" operation to
1870 add herself in the conference with XCON-URI
1871 "xcon:8977777@example.com" (written in the "confObjID"
1872 parameter). Alice provides her XCON-USERID via the "confUserID"
1873 field of the userRequest and leaves out the "userInfo" one
1874 (first-party join). In this first attempt, she doesn't insert
1875 any password parameter.
1877 2. Upon receipt the userRequest/create message, the conferencing
1878 server detects that the indicated conference is not joinable
1879 without providing the appropriate pass code. A userResponse
1880 message with "423" response-code ("conference password required")
1881 is returned to Alice to indicate that her join has been refused
1882 and that she has to resend her request including the appropriate
1883 conference password in order to participate.
1885 3. After getting the pass code through out-of-band mechanisms, Alice
1886 provides it in the proper "password" request field of a new
1887 userRequest/create message and sends the updated request back to
1888 the server.
1890 4. The conferencing server checks the provided password and then
1891 adds Alice to the protected conference. After that, a
1892 userResponse with a "200" response-code ("success") is sent to
1893 Alice.
1895 1. userRequest/create message (Alice tries to enter the conference
1896 without providing the password)
1898
1899
1903
1905 xcon-userid:Alice@example.com
1906 xcon:8977794@example.com
1907 create
1908
1909
1910
1912 2. userResponse/create message (423, "conference password required")
1914
1915
1919
1921 xcon-userid:Alice@example.com
1922 xcon:8977794@example.com
1923 create
1924 423
1925 conference password required
1926
1927
1928
1930 3. userRequest/create message (Alice provides the password)
1932
1933
1937
1939 xcon-userid:Alice@example.com
1940 xcon:8977794@example.com
1941 create
1942 8601
1943
1944
1945
1947 4. userResponse/create message
1948 (Alice has been added to the conference)
1950
1951
1955
1957 xcon-userid:Alice@example.com
1958 xcon:8977794@example.com
1959 create
1960 200
1961 success
1962 10
1963
1964
1965
1967 Figure 17: Password-protected conference join messages details
1969 7. Sidebars Scenarios and Examples
1971 While creating conferences and manipulating users and their media are
1972 sufficient for many scenarios, there may be cases when a more complex
1973 management is needed.
1975 In fact, a feature typically required in conferencing systems is the
1976 ability to create sidebars. A sidebar is basically a child
1977 conference that usually includes a subset of the participants of the
1978 parent conference, and a subset of its media as well. Sidebars are
1979 typically required whenever some of the participants in a conference
1980 want a private discussion, without interfering with the main
1981 conference.
1983 This section deals with some typical scenarios using a sidebar, like
1984 whispering, private messages and coaching scenarios. The first
1985 subsections present some examples of how a generic sidebar can be
1986 created, configured and managed.
1988 7.1. Internal Sidebar
1990 Figure 18 provides an example of one client, "Alice", involved in an
1991 active conference with "Bob" and "Carol". Alice wants to create a
1992 sidebar to have a side discussion with Bob while still viewing the
1993 video associated with the main conference. Alternatively, the audio
1994 from the main conference could be maintained at a reduced volume.
1995 Alice initiates the sidebar by sending a request to the conferencing
1996 system to create a conference reservation based upon the active
1997 conference object. Alice and Bob would remain on the roster of the
1998 main conference, such that other participants could be aware of their
1999 participation in the main conference, while an internal-sidebar
2000 conference is occurring. Besides, Bob decides that he is not
2001 interested in still receiving the conference audio in background (not
2002 even at a lower volume as Alice configured) and so modifies the
2003 sidebar in order to make that stream inactive for him.
2005 Alice Bob ConfS
2006 | | |
2007 |(1) sidebarByValRequest(confUserID, |
2008 | confObjID,create) |
2009 |--------------------------------------------->|
2010 | | |
2011 | | (a) Create +---|
2012 | | sidebar-by-val | |
2013 | | (new conf obj | |
2014 | | cloned from +-->|
2015 | | confObjID) | Sidebar now has
2016 | | | id confObjID*
2017 |(2) sidebarByValResponse(confUserID, | (parent mapping
2018 | (confObjID*,create,200,success, | conf<->sidebar)
2019 | version,sidebarByValInfo) |
2020 |<---------------------------------------------|
2021 | | |
2022 |(3) sidebarByValRequest |
2023 | (confUserID, confObjID*, |
2024 | update,sidebarByValInfo) |
2025 |--------------------------------------------->|
2026 | | |
2027 | | (b) Update +---|
2028 | | sidebar-by-val | |
2029 | | (media, users | |
2030 | | etc.) +-->|
2031 | | | Sidebar is
2032 | | | modified
2033 |(4) sidebarByValResponse(confUserID, |
2034 | confObjID*, update, |
2035 | 200, success, version) |
2036 |<---------------------------------------------|
2037 | | |
2038 | |(5) userRequest |
2039 | | (confUserID', |
2040 | | confObjID*, |
2041 | | update,userInfo)|
2042 | |---------------------->|
2043 | | |
2044 | | (c) Update +---|
2045 | | user settings | |
2046 | | (Bob's media) | |
2047 | | +-->|
2048 | | | Sidebar is modified
2049 | | | (original audio
2050 | | | inactive for Bob)
2051 | |(6) userResponse |
2052 | | (confUserID', |
2053 | | confObjID*, |
2054 | | update, 200, |
2055 | | success,version) |
2056 | |<----------------------|
2057 | | |
2058 " " "
2059 " " "
2060 " " "
2062 Figure 18: Client Creation of a Sidebar Conference
2064 1. Upon receipt of CCMP sidebarByValRequest message to create a new
2065 sidebar-conference based upon the confObjID received in the
2066 request, the conferencing system uses the confObjID to clone a
2067 conference reservation for the sidebar. The sidebar reservation
2068 is NOT independent of the active conference (i.e., parent). The
2069 conferencing system also allocates a new XCON-URI for that
2070 sidebar to be used for any subsequent protocol requests from any
2071 of the members of the conference. The new sidebar identifier
2072 ("confObjID*" in Figure 18) is returned in the response message
2073 confObjID parameter.
2075 2. The relationship information is provided in the
2076 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the
2078 main/parent conference is provided below as well to show how the
2079 cloning process for the creation of the sidebar could take place.
2081 3. Upon receipt of the sidebarByValResponse message to reserve the
2082 conference, Alice can now create an active conference using that
2083 reservation, or create additional reservations based upon the
2084 existing reservations. In this example, Alice wants only Bob to
2085 be involved in the sidebar, thus she manipulates the membership
2086 so that only the two of them appear in the
2087 section. Alice also wants both audio and video from the original
2088 conference to be available in the sidebar. For what concerns the
2089 media belonging to the sidebar itself, Alice wants the audio to
2090 be restricted to the participants in the sidebar (that is, Bob
2091 and herself). Additionally, Alice manipulates the media values
2092 to receive the audio from the main conference at a reduced
2093 volume, so that the communication between her and Bob isn't
2094 affected. Alice sends a sidebarByValRequest message with an
2095 operation of "update" along with the "sidebarByValInfo"
2096 containing the aforementioned sidebar modifications.
2098 4. Upon receipt of the sidebarByValRequest to update the sidebar
2099 reservation, the conference server ensures that Alice has the
2100 appropriate authority based on the policies associated with that
2101 specific conference object to perform the operation. The
2102 conference server must also validate the updated information in
2103 the reservation, ensuring that a member like Bob is already a
2104 user of this conference server. Once the data for the confObjID
2105 is updated, the conference server sends a sidebarByValResponse to
2106 Alice. Depending upon the policies, the initiator of the request
2107 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may
2108 be notified of his addition to the sidebar via the conference
2109 notification service.
2111 5. At this point, Bob sends a userRequest message to the conference
2112 server with an operation of "update" to completely disable the
2113 background audio from the parent conference, since it prevents
2114 him from understanding what Alice says in the sidebar.
2116 6. Notice that Bob's request only changes the media perspective for
2117 Bob. Alice keeps on receiving both the audio from Bob and the
2118 background from the parent conference. This request may be
2119 relayed by the conference server to the Media Server handling the
2120 mixing, if present. Upon completion of the change, the
2121 conference server sends a "userResponse" message to Bob.
2122 Depending upon the policies, the initiator of the request (i.e.,
2123 Bob) and the participants in the sidebar (i.e., Alice) may be
2124 notified of this change via the conference notification service.
2126 The following conference object represents the conference in which
2127 the sidebar is to be created. It will be used by the conferencing
2128 system to create the new conference object associated with the
2129 sidebar.
2131
2132
2137
2138 MAIN CONFERENCE
2139
2140
2141 sip:8977878@example.com
2142 conference sip uri
2143
2144
2145
2146
2147 main conference audio
2148 audio
2149 sendrecv
2150
2151
2152 main conference video
2153 video
2154 sendrecv
2155
2156 single-view
2157
2158
2159
2160
2161
2162 true
2163
2164
2165
2166 Alice
2167
2168
2169 123
2170 sendrecv
2171
2172
2173 456
2174 sendrecv
2175
2176
2177
2178
2179 Bob
2180
2181
2182 123
2183 sendrecv
2184
2185
2186 456
2187 sendrecv
2188
2189
2190
2191
2192 Carol
2193
2194
2195 123
2196 sendrecv
2197
2198
2199 456
2200 sendrecv
2201
2202
2203
2204
2205
2207 Figure 19: Conference with Alice, Bob and Carol
2209 The sidebar creation happens through a cloning of the parent
2210 conference. Once the sidebar is created, an "update" makes sure that
2211 the sidebar is customized as needed. The following protocol dump
2212 makes the process clearer.
2214 1. sidebarByValRequest/create message (Alice creates an
2215 internal sidebar)
2217
2218
2221
2223 xcon-userid:Alice@example.com
2224 xcon:8977878@example.com
2225 create
2226
2227
2228
2230 2. sidebarByValResponse/create message (sidebar returned)
2232
2233
2237
2239 xcon-userid:Alice@example.com
2240 xcon:8974545@example.com
2241 create
2242 200
2243 success
2244 1
2245
2246
2247
2248
2249 SIDEBAR CONFERENCE registered by Alice
2250
2251
2252
2253
2254 main conference audio
2255
2256 audio
2257 sendrecv
2258
2259
2260
2261 main conference video
2262
2263 video
2264 sendrecv
2265
2266
2267
2268
2269 false
2270
2271
2272
2273
2275
2277
2279
2280
2281 xcon:8977878@example.com
2282
2283
2284
2285
2286
2287
2289 3. sidebarByValRequest/update message (Alice updates the
2290 created sidebar)
2292
2293
2297
2299 xcon-userid:Alice@example.com
2300 xcon:8974545@example.com
2301 update
2302
2303
2304
2305
2306 private sidebar Alice - Bob
2308
2309
2310
2311
2312 main conference audio
2313
2314 audio
2315 recvonly
2316
2317 -60
2318
2319
2320
2321
2322 main conference video
2323
2324 video
2325 recvonly
2326
2327
2328
2329 sidebar audio
2330
2331 audio
2332 sendrecv
2333
2334
2335
2336 sidebar video
2337
2338 video
2339 sendrecv
2340
2341
2342
2343
2344
2345
2347
2349
2350
2351
2352
2353
2354
2355 4. sidebarByValResponse/update message (sidebar's
2356 updates accepted)
2358
2359
2363
2365 xcon-userid:Alice@example.com
2366 xcon:8974545@example.com
2367 update
2368 200
2369 success
2370 2
2371
2372
2373
2375 5. userRequest/update message (Bob updates his media)
2377
2378
2382
2384 xcon-userid:Bob@example.com
2385 xcon:8974545@example.com
2386 update
2387
2388
2389
2390
2391
2392 main conference audio
2393
2394 123
2395 inactive
2396
2397
2398
2399
2400
2401
2402 6. userResponse/update message (Bob's preferences are set)
2404
2405
2408
2410 xcon-userid:Bob@example.com
2411 xcon:8974545@example.com
2412 update
2413 200
2414 success
2415 3
2416
2417
2418
2420 Figure 20: Internal Sidebar Messaging Details
2422 7.2. External Sidebar
2424 Figure 21 provides an example of a different approach towards
2425 sidebar. In this scenario, one client, "Alice", is involved in an
2426 active conference with "Bob", "Carol", "David" and "Ethel". Alice
2427 gets an important text message via a whisper from Bob that a critical
2428 customer needs to talk to Alice, Bob and Ethel. Alice creates a
2429 sidebar to have a side discussion with the customer "Fred" including
2430 the participants in the current conference with the exception of
2431 Carol and David, who remain in the active conference. The difference
2432 from the previous scenario is that Fred is not part of the parent
2433 conference: this means that different policies might be involved,
2434 considering that Fred may access information coming from the parent
2435 conference, in case the sidebar was configured accordingly. For this
2436 reason, in this scenario we assume that Alice disables all the media
2437 from the original (parent) conference within the sidebar. This means
2438 that, while in the previous example Alice and Bob still heard the
2439 audio from the main conference in background, this time no background
2440 is made available. Alice initiates the sidebar by sending a request
2441 to the conferencing system to create a conference reservation based
2442 upon the active conference object. Alice, Bob and Ethel would remain
2443 on the roster of the main conference in a hold state. Whether or not
2444 the hold state of these participants is visible to other participants
2445 depends upon the individual and local policy. However, providing the
2446 hold state allows the participants in the main conference to see that
2447 others in the conference are busy. Note, that a separate conference
2448 could have been created by Alice to allow Bob and Ethel to talk to
2449 Fred. However, creating a sidebar has somewhat of an advantage by
2450 allowing the conference to be created using some of the same settings
2451 (e.g., role, floor control, etc.) that Bob and Ethel had in the main
2452 conference and it would allow for updates such that the media could
2453 be updated, for example, to provide audio from the main conference.
2455 Alice Bob ConfS
2456 | | |
2457 |(1) sidebarByRefRequest(confUserID, |
2458 | confObjID, create) |
2459 |--------------------------------------------->|
2460 | | |
2461 | | (a) Create +---|
2462 | | sidebar-by-ref | |
2463 | | (new conf obj | |
2464 | | cloned from +-->|
2465 | | confObjID) | Sidebar now has
2466 | | | id confObjID*
2467 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2468 | confObjID*,create,200,success, | conf<->sidebar)
2469 | version,sidebarByRefInfo) |
2470 |<---------------------------------------------|
2471 | | |
2472 |(3) sidebarByRefRequest(confUserID, |
2473 | confObjID*,update,sidebarByRefInfo) |
2474 |--------------------------------------------->|
2475 | | |
2476 | | (b) Create +---|
2477 | | new user for | |
2478 | | Fred | |
2479 | | +-->|
2480 | | |
2481 | | (c) Update +---|
2482 | | sidebar-by-ref | |
2483 | | (media, users | |
2484 | | policy, etc.) +-->|
2485 | | | Sidebar is modified:
2486 | | | no media from the
2487 | | | parent conference is
2488 | | | available to anyone
2489 |(4) sidebarByRefResponse(confUserID, |
2490 | confObjID*, update, |
2491 | 200, success, version) |
2492 |<---------------------------------------------|
2493 | | |
2494 | | Notify (Fred |
2495 | | added to |
2496 | | sidebar users) |
2497 | |<----------------------|
2498 | | |
2499 " " "
2500 " " "
2501 " " "
2502 Figure 21: Client Creation of an External Sidebar
2504 1. Upon receipt of the "sidebarByRefRequest" message to create a new
2505 sidebar conference, based upon the active conference specified by
2506 "confObjID" in the request, the conferencing system uses that
2507 active conference to clone a conference reservation for the
2508 sidebar. The sidebar reservation is NOT independent of the
2509 active conference (i.e., parent). The conferencing system, as
2510 before, allocates a conference ID (confObjID*) to be used for any
2511 subsequent protocol requests toward the sidebar reservation. The
2512 mapping between the sidebar conference ID and the one associated
2513 with the main conference is maintained by the conferencing system
2514 and it is gathered from the c element in the
2515 sidebar conference object.
2517 2. Upon receipt of the "sidebarByRefResponse" message, which
2518 acknowledges the successful creation of the sidebar object, Alice
2519 decides that only Bob and Ethel, along with the new participant
2520 Fred are to be involved in the sidebar. Thus she manipulates the
2521 membership accordingly. Alice also sets the media in the
2522 "conference-info" such that the participants in the sidebar don't
2523 receive any media from the main conference. All these settings
2524 are provided to the conferencing system by means of a new
2525 "sidebarByRefRequest" message, with an "update" operation.
2527 3. Alice sends the aforementioned "sidebarByRefRequest" to update
2528 the information in the reservation and to create an active
2529 conference. Upon receipt of the "sidebarByRefRequest" with an
2530 operation of "update", the conferencing system ensures that Alice
2531 has the appropriate authority based on the policies associated
2532 with that specific conference object to perform the operation.
2533 The conferencing system also validates the updated information in
2534 the reservation. Since Fred is a new user for this conferencing
2535 system, a conference user identifier is created for Fred.
2536 Specifically, Fred is added to the conference by only providing
2537 his SIP URI. Based upon the contact information provided for
2538 Fred by Alice, the call signaling to add Fred to the conference
2539 may be instigated through the Focus (e.g., if Fred had a "dial-
2540 out" method set as the target for him) at the actual activation
2541 of the sidebar.
2543 4. The conference server sends a "sidebarByRefResponse" message and,
2544 depending upon the policies, the initiator of the request (i.e.,
2545 Alice) and the participants in the sidebar (i.e., Bob and Ethel)
2546 may be notified of his addition to the sidebar via the conference
2547 notification service.
2549 1. sidebarByRefRequest/create message (Alice creates an
2550 external sidebar)
2552
2553
2556
2558 xcon-userid:Alice@example.com
2559 xcon:8977878@example.com
2560 create
2561
2562
2563
2565 2. sidebarByRefResponse/create message (created
2566 sidebar returned)
2568
2569
2573
2575 xcon-userid:Alice@example.com
2576 xcon:8971212@example.com
2577 create
2578 200
2579 success
2580 1
2581
2582
2583
2584
2585 SIDEBAR CONFERENCE registered by Alice
2586
2587
2588
2589
2590 main conference audio
2591
2592 audio
2593 sendrecv
2595
2596
2597
2598 main conference video
2599
2600 video
2601 sendrecv
2602
2603
2604
2605
2606 false
2607
2608
2609
2610
2612
2614
2616
2618
2620
2621
2622 xcon:8977878@example.com
2623
2624
2625
2626
2627
2628
2630 3. sidebarByRefRequest/update message (Alice updates the sidebar)
2632
2636
2638 xcon-userid:Alice@example.com
2639 xcon:8971212@example.com
2640 update
2641
2642
2643
2644
2645 sidebar with Alice, Bob, Ethel and Fred
2646
2647
2648
2649
2650 main conference audio
2651
2652 audio
2653 inactive
2654
2655
2656
2657 main conference video
2658
2659 video
2660 inactive
2661
2662
2663
2664 sidebar audio
2665
2666 audio
2667 sendrecv
2668
2669
2670
2671 sidebar video
2672
2673 video
2674 sendrecv
2675
2676
2677 single-view
2678
2679
2680
2681
2682
2683
2684 false
2685
2686
2687
2688
2690
2692
2694
2695
2696
2697
2698
2699
2701 4. sidebarByRefResponse/update message (sidebar updated)
2703
2707
2709 xcon-userid:Alice@example.com
2710 xcon:8971212@example.com
2711 update
2712 200
2713 success
2714 2
2715
2716
2717
2719 Figure 22: External Sidebar Messaging Details
2721 7.3. Private Messages
2723 The case of private messages can be handled as a sidebar with just
2724 two participants, similarly to the example in Section 7.1. Unlike
2725 the previous example, rather than using audio within the sidebar,
2726 Alice could just add an additional text based media stream to the
2727 sidebar in order to convey her textual messages to Bob, while still
2728 viewing and listening to the main conference.
2730 In this scenario, Alice requests to the conferencing system the
2731 creation of a private chat room within the main conference context
2732 (presented in Figure 19) in which the involved participants are just
2733 Bob and herself. This can be achieved through the following CCMP
2734 transaction (Figure 23).
2736 1. Alice forwards a sidebarByValRequest/create to the Conferencing
2737 Control Server with the main conference XCON-URI in the
2738 "confObjID" parameter and the desired sidebar conference object
2739 in the "sidebarByValInfo" field. In this way, a sidebar creation
2740 using user-provided conference information is requested to the
2741 conferencing system. Please note that, unlike the previous
2742 sidebar examples, in this case a completely new conference object
2743 to describe the sidebar is provided: there is no cloning
2744 involved, while the "confObjID" still enforces the parent-child
2745 relationship between the main conference and the to-be-created
2746 sidebar.
2748 2. The Conference Control Server, after checking Alice's rights and
2749 validating the conference-object carried in the request, creates
2750 the required sidebar-by-val conference and a new XCON-URI for it.
2751 Instead of cloning the main conference object, as shown in
2752 Section 7.1 and Section 7.2, the sidebar is created on the basis
2753 of the user provided conference information. However, the parent
2754 relationship between the main conference and the newly created
2755 sidebar is still maintained by the conferencing system (as a
2756 consequence of the chosen CCMP request message type - the
2757 sidebarByVal one) and it is reflected by the
2758 element in the "sidebarByValInfo" element returned in the
2759 sidebarByValResponse message. Please notice that, according to
2760 the CCMP specification, the return of the created sidebar data in
2761 this kind of "success" response is not mandatory.
2763 1. sidebarByValRequest/create message (Alice creates a private
2764 chat room between Bob and herself)
2766
2767
2771
2773 xcon-userid:Alice@example.com
2774 xcon:8977878@example.com
2775 create
2776
2777
2778
2779
2780 private textual sidebar alice - bob
2781
2782
2783
2784
2785 main conference audio
2786
2787 audio
2788 recvonly
2789
2790
2791
2792 main conference video
2793
2794 video
2795 recvonly
2796
2797
2798
2799 sidebar text
2800
2801 text
2802 sendrecv
2803
2804
2805
2806
2807
2808
2810
2812
2813
2814
2815
2816
2817
2819 2. sidebarByValResponse/create message (sidebar returned)
2821
2822
2826
2828 xcon-userid:Alice@example.com
2829 xcon:8974545@example.com
2830 create
2831 200
2832 success
2833 1
2834
2835
2836
2837
2838 private textual sidebar alice - bob
2839
2840
2841
2842
2843 main conference audio
2844
2845 audio
2846 recvonly
2847
2848
2849
2850 main conference video
2851
2852 video
2853 recvonly
2854
2855
2856
2857 sidebar text
2858
2859 text
2860 sendrecv
2861
2862
2863
2864 xcon:8977878@example.com
2865
2866
2867
2868
2869
2871
2873
2874
2875
2876
2877
2879
2881 Figure 23: Sidebar for Private Messages scenario
2883 7.4. Observing and Coaching
2885 Observing and Coaching is one of the most interesting sidebars-
2886 related scenarios. In fact, it highlights two different interactions
2887 that have to be properly coordinated.
2889 An example of observing and coaching is shown in figure Figure 25.
2890 In this example, call center agent Bob is involved in a conference
2891 with customer Carol. Since Bob is a new agent and Alice sees that he
2892 has been on the call with Carol for longer than normal, she decides
2893 to observe the call and coach Bob as necessary. Of course the
2894 conferencing system must make sure that the customer Carol is not
2895 aware of the presence of the coach Alice. This makes the use of a
2896 sidebar necessary for the success of the scenario.
2898 Consider the following as the conference document associated with the
2899 video conference involving Bob (the call agent) and Carol (the
2900 customer) (Figure 24):
2902
2903
2908
2909
2910 CUSTOMER SERVICE conference
2911
2912
2913
2914 sip:8978383@example.com
2915 conference sip uri
2916
2917
2918
2919
2920 service audio
2921 audio
2922 sendrecv
2923
2924
2925 service video
2926 video
2927 sendrecv
2928
2929 single-view
2930
2931
2932
2933
2934
2935 true
2936
2937
2938
2939 Bob - call agent
2940
2941
2942 123
2943 sendrecv
2944
2945
2946 456
2947 sendrecv
2948
2949
2950
2951
2952 Carol - customer
2953
2954
2955 123
2956 sendrecv
2957
2958
2959 456
2960 sendrecv
2961
2962
2963
2964
2965
2967 Figure 24: A call-center conference object example
2969 Alice Bob ConfS
2970 | | |
2971 |(1) sidebarByRefRequest(confUserID, |
2972 | confObjID, create) |
2973 |--------------------------------------------->|
2974 | | |
2975 | | (a) Create +---|
2976 | | sidebar-by-ref | |
2977 | | (new conf obj | |
2978 | | cloned from +-->|
2979 | | confObjID) | Sidebar now has
2980 | | | id confObjID*
2981 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2982 | confObjID*,create,200,success, | conf<->sidebar)
2983 | version,sidebarByRefInfo) |
2984 |<---------------------------------------------|
2985 | | |
2986 |(3) sidebarByRefRequest(confUserID, |
2987 | confObjID*,update,sidebarByRefInfo) |
2988 |--------------------------------------------->|
2989 | | |
2990 | | (b) Update +---|
2991 | | sidebar-by-val | |
2992 | | (media, users | |
2993 | | policy, etc.) +-->|
2994 | | | Sidebar is modified:
2995 | | | unilateral sidebar
2996 | | | audio, Carol excluded
2997 | | | from the sidebar
2998 |(4) sidebarByRefResponse(confUserID, |
2999 | confObjID*, update, |
3000 | 200, success, version) |
3001 |<---------------------------------------------|
3002 | | |
3003 | | Notify (Bob |
3004 | | he's been added to |
3005 | | sidebar users) |
3006 | |<----------------------|
3007 | | |
3008 " " "
3009 " " "
3010 " " "
3012 Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
3014 1. Upon receipt of the sidbarByRefRequest/create from Alice to
3015 "create" a new sidebar conference from the confObjID received in
3016 the request, the conferencing system uses the received active
3017 conference to clone a conference reservation for the sidebar.
3018 The conferencing system also allocates a conference ID to be used
3019 for any subsequent protocol requests from any of the members of
3020 the conference. The conferencing system maintains the mapping
3021 between this conference ID and the confObjID associated with the
3022 sidebar reservation through the conference instance. The
3023 conference server sends a sidebarByRefResponse message with the
3024 new confObjID and relevant sidebarByRefInfo.
3026 2. Upon receipt of the sidebarByRefResponse message, Alice
3027 manipulates the data received in the sidebarByRefInfo in the
3028 response. Alice wants only Bob to be involved in the sidebar,
3029 thus she updates the to include only Bob and
3030 herself. Alice also wants the audio to be received by herself
3031 and Bob from the original conference, but wants any outgoing
3032 audio from herself to be restricted to the participants in the
3033 sidebar, whereas Bob's outgoing audio should go to the main
3034 conference, so that both Alice and the customer Carol hear the
3035 same audio from Bob. Alice sends a sidebarByRefRequest message
3036 with an "update" operation including the updated sidebar
3037 information.
3039 3. Upon receipt of the sidebarByRefRequest message with an "update"
3040 operation, the conferencing system ensures that Alice has the
3041 appropriate authority based on the policies associated with that
3042 specific conference object to perform the operation. In order to
3043 request the insertion of a further media stream in the sidebar
3044 (i.e., in this example an audio stream from Alice to Bob), the
3045 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label"
3047 attribute of that new entry is filled with a dummy value
3048 "AUTO_GENERATE_1", but it will contain the real server-generated
3049 media stream identifier when the media stream is effectively
3050 allocated on the server side. Similarly, the mandatory "id"
3051 attribute in element referring to the new sidebar audio
3052 stream under both Alice's and Bob's contains a
3053 wildcard value, respectively "AUTO_GENERATE_2" and
3054 "AUTO_GENERATE_3": those values will be replaced with the
3055 appropriated server-generated identifiers upon the creation of
3056 the referred media stream. We are assuming the conferencing
3057 control server is able to recognize those dummy values as place-
3058 holders.
3060 4. After validating the data, the conference server sends a
3061 sidebarByRefResponse message. Based upon the contact information
3062 provided for Bob by Alice, the call signaling to add Bob to the
3063 sidebar with the appropriate media characteristics is instigated
3064 through the Focus. Bob is notified of his addition to the
3065 sidebar via the conference notification service, thus he is aware
3066 that Alice, the supervisor, is available for coaching him through
3067 this call.
3069 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
3071
3072
3075
3077 xcon-userid:alice@example.com
3078 xcon:8978383@example.com
3079 create
3080
3081
3082
3084 2. sidebarByRefResponse/create message (sidebar created)
3086
3087
3091
3093 xcon-userid:alice@example.com
3094 xcon:8971313@example.com
3095 create
3096 200
3097 Success
3098 1
3099
3100
3101
3102
3103 SIDEBAR CONFERENCE registered by alice
3104
3105
3106
3107
3108 main conference audio
3109
3110 audio
3111 sendrecv
3112
3113
3114
3115 main conference video
3116
3117 video
3118 sendrecv
3119
3120
3121
3122 xcon:8971313@example.com
3123
3124
3125
3126 false
3127
3128
3129
3130
3132
3134
3136
3137
3138
3139
3140
3141
3143 3. sidebarByRefRequest/update message (Alice introduces unilateral
3144 sidebar audio and excludes Carol from the sidebar)
3146
3150
3152 xcon-userid:alice@example.com
3153 xcon:8971313@example.com
3154 update
3155
3156
3157
3158
3159 Coaching sidebar Alice and Bob
3160
3161
3162
3163
3164 Alice-to-Bob audio
3165
3166 audio
3167 sendrecv
3168
3169
3170
3171
3172 false
3173
3174
3175
3176
3177
3178 AUTO_GENERATE_1
3179 sendonly
3180
3181
3182
3183
3184
3185
3186 AUTO_GENERATE_1
3187 recvonly
3188
3189
3190
3191
3192
3194
3196
3197
3198
3199
3200
3201
3203 4. sidebarByRefRequest/update message (updates accepted)
3205
3206
3210
3212 xcon-userid:alice@example.com
3213 xcon:8971313@example.com
3214 update
3215 200
3216 success
3217 2
3218
3219
3220
3222 Figure 26: Coaching and Observing Messaging details
3224 8. Removing Participants and Deleting Conferences
3226 The following scenarios detail the basic operations associated with
3227 removing participants from conferences and entirely deleting
3228 conferences. The examples assume that a conference has already been
3229 correctly established, with media, if applicable, per one of the
3230 examples in Section 5.
3232 8.1. Removing a Party
3234 Figure 27 provides an example of a client, "Alice", removing another
3235 participant, "Bob", from a conference. This example assumes an
3236 established conference with Alice, Bob, "Claire" and "Duck". In this
3237 example, Alice wants to remove Bob from the conference so that the
3238 group can continue in the same conference without Bob's
3239 participation.
3241 Alice Bob Claire ConfS
3242 | | | |
3243 |(1) userRequest(confUserID,| |
3244 | confObjID, delete,| |
3245 | userInfo) | |
3246 |-------------------------------------->|
3247 | | | |
3248 | | | (a) Focus |
3249 | | | tears down|
3250 | | | signaling |
3251 | | | to Bob |
3252 | |<----------------------|
3253 | | |
3254 | | (b)Deletes+---|
3255 | | | Bob | |
3256 | | | as a | |
3257 | | | user +-->|
3258 | | | in |
3259 | | | confObj |
3260 | | | |
3261 |(2) userResponse(confUserID,confObjID, |
3262 | delete,200,success,version) |
3263 |<--------------------------------------|
3264 | | | |
3265 | | | |
3266 | | | (c) Notify|
3267 | | | ("Bob just|
3268 | | | left") |
3269 | | |<----------|
3270 | | | |
3271 ' ' ' '
3272 ' ' ' '
3273 ' ' ' '
3275 Figure 27: Client Manipulation of Conference - Remove a party
3277 1. Alice sends a userRequest message, with a "delete" operation.
3278 The conference server ensures that Alice has the appropriate
3279 authority based on the policies associated with that specific
3280 conference object to perform the operation.
3282 2. Based upon the contact and media information in the conference
3283 object for Bob in the "userInfo" element, the conferencing system
3284 starts the process to remove Bob (e.g., the call signaling to
3285 remove Bob from the conference is instigated through the Focus).
3286 The conference server updates the data in the conference object,
3287 thus removing Bob from the list. After updating the
3288 data, the conference server sends a userResponse message to
3289 Alice. Depending upon the policies, other participants (e.g.,
3290 "Claire") may be notified of the removal of Bob from the
3291 conference via the Conference Notification Service.
3293 1. userRequest/delete message (Alice deletes Bob):
3295
3296
3300
3302 xcon-userid:Alice@example.com
3303 xcon:8977794@example.com
3304 delete
3305
3306
3307
3308
3309
3311 2. userResponse/delete message (Bob has been deleted)
3313
3314
3318
3320 xcon-userid:Alice@example.com
3321 xcon:8977794@example.com
3322 delete
3323 200
3324 success
3325 17
3326
3327
3328
3330 Figure 28: Removing a Participant Messaging Details
3332 8.2. Deleting a Conference
3334 In this section, an example of a successful conference deletion is
3335 provided (Figure 29).
3337 Alice ConfS
3338 | |
3339 |(1)confRequest(confUserID, |
3340 | confObjID, delete) |
3341 |------------------------------>|
3342 | (a)Delete +---|
3343 | Conf | |
3344 | Object | |
3345 | +-->|
3346 | |--+ (b) MS
3347 | | | removes related
3348 | | | mixer instances and
3349 | |<-+ their participants
3350 | | (SIP signaling as well)
3351 | |
3352 |(2)confResponse(confUserID, |
3353 | confObjID,delete,200, |
3354 | success) |
3355 | |
3356 |<------------------------------|
3357 | |
3359 Figure 29: Deleting a conference
3361 1. The conferencing system client "Alice" sends a confRequest
3362 message with a "delete" operation to be performed on the
3363 conference identified by the XCON-URI carried in the "confObjID"
3364 parameter. The conference server, on the basis of the
3365 "confUserID" included in the receipt request, ensures that Alice
3366 has the appropriate authority to fulfill the operation.
3368 2. After validating Alice's rights, the conferencing server
3369 instigates the process to delete the conference object,
3370 disconnecting participants and removing associated resources such
3371 as mixer instances. Then, the conference server returns a
3372 confResponse message to Alice with "200" as "response-code" and
3373 the deleted conference XCON-URI in the "confObjID" field.
3375 1. confRequest/delete message (Alice deletes a conference)
3377
3378
3382
3384 xcon-userid:Alice@example.com
3385 xcon:8977794@example.com
3386 delete
3387
3388
3389
3391 2. confResponse/delete message (200, "success")
3393
3394
3398
3400 xcon-userid:Alice@example.com
3401 xcon:8977794@example.com
3402 delete
3403 200
3404 success
3405
3406
3407
3409 Figure 30: Deleting a Conference Messaging Details
3411 9. IANA Considerations
3413 This document has no IANA considerations.
3415 10. Security Considerations
3417 The security considerations applicable to the implementation of these
3418 call flows are documented in the XCON Framework, with additional
3419 security considerations documented in the CCMP document. Statements
3420 with regards to the necessary security are discussed in particular
3421 flows, however, this is for informational purposes only. The
3422 implementor is encouraged to carefully consider the security
3423 requirements in the normative documents.
3425 11. Acknowledgements
3427 The detailed content for this document is derived from the prototype
3428 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
3429 their colleagues at the University of Napoli.
3431 12. Informative References
3433 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
3434 Centralized Conferencing", RFC 5239, June 2008.
3436 [I-D.ietf-xcon-ccmp]
3437 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
3438 "Centralized Conferencing Manipulation Protocol",
3439 draft-ietf-xcon-ccmp-13 (work in progress), May 2011.
3441 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
3442 A., Peterson, J., Sparks, R., Handley, M., and E.
3443 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
3444 June 2002.
3446 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
3447 (SIP) Call Control - Conferencing for User Agents",
3448 BCP 119, RFC 4579, August 2006.
3450 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
3451 RFC 4597, August 2006.
3453 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
3454 Control Protocol (BFCP)", RFC 4582, November 2006.
3456 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
3457 Initiation Protocol (SIP) Event Package for Conference
3458 State", RFC 4575, August 2006.
3460 [I-D.ietf-xcon-event-package]
3461 Camarillo, G., Srinivasan, S., Even, R., and J.
3462 Urpalainen, "Conference Event Package Data Format
3463 Extension for Centralized Conferencing (XCON)",
3464 draft-ietf-xcon-event-package-01 (work in progress),
3465 September 2008.
3467 [I-D.ietf-xcon-common-data-model]
3468 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
3469 "Conference Information Data Model for Centralized
3470 Conferencing (XCON)", draft-ietf-xcon-common-data-model-31
3471 (work in progress), June 2011.
3473 [I-D.ietf-mediactrl-call-flows]
3474 Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
3475 "Media Control Channel Framework (CFW) Call Flow
3476 Examples", draft-ietf-mediactrl-call-flows-07 (work in
3477 progress), July 2011.
3479 [RFC5567] Melanchuk, T., "An Architectural Framework for Media
3480 Server Control", RFC 5567, June 2009.
3482 [I-D.ietf-mediactrl-mixer-control-package]
3483 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
3484 Control Package for the Media Control Channel Framework",
3485 draft-ietf-mediactrl-mixer-control-package-14 (work in
3486 progress), January 2011.
3488 Authors' Addresses
3490 Mary Barnes
3491 Polycom
3492 TX
3493 USA
3495 Email: mary.ietf.barnes@gmail.com
3497 Lorenzo Miniero
3498 Meetecho
3499 Via Carlo Poerio 89/a
3500 Napoli 80121
3501 Italy
3503 Email: lorenzo@meetecho.com
3504 Roberta Presta
3505 University of Napoli
3506 Via Claudio 21
3507 Napoli 80125
3508 Italy
3510 Email: roberta.presta@unina.it
3512 Simon Pietro Romano
3513 University of Napoli
3514 Via Claudio 21
3515 Napoli 80125
3516 Italy
3518 Email: spromano@unina.it