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