idnits 2.17.1
draft-ietf-xcon-examples-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
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 seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (July 13, 2009) is 5401 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.ietf-xcon-event-package' is defined on line 2808,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-xcon-common-data-model' is defined on line
2815, but no explicit reference was found in the text
== Outdated reference: A later version (-15) exists of
draft-ietf-xcon-ccmp-02
-- Obsolete informational reference (is this intentional?): RFC 4582
(Obsoleted by RFC 8855)
== Outdated reference: A later version (-32) exists of
draft-ietf-xcon-common-data-model-13
== Outdated reference: A later version (-13) exists of
draft-ietf-mediactrl-call-flows-00
== Outdated reference: A later version (-14) exists of
draft-ietf-mediactrl-mixer-control-package-07
== Outdated reference: A later version (-08) exists of
draft-boulton-xcon-session-chat-04
Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XCON Working Group M. Barnes
3 Internet-Draft Nortel
4 Intended status: Informational C. Boulton
5 Expires: January 14, 2010 NS-Technologies
6 L. Miniero
7 Meetecho
8 R. Presta
9 S P. Romano
10 University of Napoli
11 July 13, 2009
13 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
14 draft-ietf-xcon-examples-01.txt
16 Status of this Memo
18 This Internet-Draft is submitted to IETF in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on January 14, 2010.
39 Copyright Notice
41 Copyright (c) 2009 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents in effect on the date of
46 publication of this document (http://trustee.ietf.org/license-info).
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document.
50 Abstract
52 This document provides detailed call flows for the scenarios
53 documented in the Centralized Conferencing (XCON) Framework and the
54 XCON Scenarios. The call flows document the use of the interface
55 between a conference control client and a conference control server
56 using the Centralized Conferencing Manipulation Protocol (CCMP). The
57 objective is to provide a base reference for both protocol
58 researchers and developers.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
66 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 5
67 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 6
68 5.2. Basic Conference Creation for a specific instance of
69 Conference Information . . . . . . . . . . . . . . . . . . 11
70 5.3. Basic Conference Creation - Cloning an existing
71 Conference . . . . . . . . . . . . . . . . . . . . . . . . 15
72 5.4. Conference Creation using Blueprints . . . . . . . . . . . 18
73 6. General Conference scenarios and examples . . . . . . . . . . 25
74 6.1. Conference Announcements and Recordings . . . . . . . . . 25
75 6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 28
76 6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 28
77 6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 31
78 6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 36
79 6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 45
80 6.7. Floor control using sidebars . . . . . . . . . . . . . . . 51
81 6.8. Whispering or Private Messages . . . . . . . . . . . . . . 52
82 6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 53
83 7. Removing participants and deleting conferences . . . . . . . . 54
84 7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 55
85 7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 56
86 8. Additional Conference Scenarios and Examples . . . . . . . . . 57
87 8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
88 8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 58
89 8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 62
90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
92 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 65
93 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
96 13.2. Informative References . . . . . . . . . . . . . . . . . . 66
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
100 1. Introduction
102 This document provides detailed call flows for the scenarios
103 documented in the Framework for Centralized Conferencing (XCON
104 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
105 scenarios describe a broad range of use cases taking advantage of the
106 advanced conferencing capabilities provided by a system realization
107 of the XCON framework. The call flows document the use of the
108 interface between a conference control client and a conference
109 control server using the Centralized Conferencing Manipulation
110 Protocol (CCMP)[I-D.ietf-xcon-ccmp].
112 Due to the broad range of functionality provided by the XCON
113 Framework and the flexibility of the CCMP messaging, these call flows
114 should not be considered inclusive of all the functionality that can
115 provided by the XCON Framework and protocol implementations. These
116 flows represent a sample to provide an overview of the feature rich
117 capabilities of the XCON framework and CCMP messaging for protocol
118 developers, software developers and researchers.
120 2. Conventions
122 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
125 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
126 levels for compliant implementations. In this document, these key
127 words are used when describing normative functionality based on the
128 XCON Framework and CCMP.
130 Note that due to RFC formatting conventions, this document often
131 splits message details whose content would exceed 72 characters. A
132 backslash character marks where this line folding has taken place.
133 This backslash and its trailing CRLF and whitespace would not appear
134 in the actual protocol contents.
136 3. Terminology
138 This document uses the same terminology as found in the referenced
139 documents, with the following terms and abbreviations used in the
140 call flows. Also, note that the term "call flows" is used in a very
141 generic sense in this document since the media is not limited to
142 voice. The calls supported by the XCON framework and CCMP can
143 consist of media such as text, voice and video, including multiple
144 media types in a single active conference.
146 Conferencing and Media Client Client (CMCC): As defined in the XCON
147 Framework. In the flows in this document, the CMCC is logically
148 equivalent to the use of UAC as the client notation in the media
149 control call flows [I-D.ietf-mediactrl-call-flows].
151 Conferencing Server (ConfS): As defined in the XCON Framework. In
152 this document, the conferencing server is used interchangeably
153 with the term Application Server (AS) as used in the Media Control
154 Architectural Framework [RFC5567]. However, these need not be the
155 same entities in an implementation.
157 Media Server (MS): As defined in the Media Control Architectural
158 Framework [RFC5567].
160 4. Overview
162 This document provides a sampling of detailed call flows that can be
163 implemented based on a system realization of [RFC5239] and
164 implementation of [I-D.ietf-xcon-ccmp]. This is intended to be a
165 simple guide on the use of the conference control protocol between
166 the Conference Server and the Conference Control Client. The
167 objective is to provide an informational base reference for protocol
168 developers, software developers and researchers.
170 This document focuses on the interaction between the Conference (and
171 Media) Control Client and the Conferencing system, specifically the
172 Conference Server. The scenarios are based on those described in the
173 XCON framework, many of which are based on the advanced conferencing
174 capabilities described in the XCON scenarios. Additional scenarios
175 have been added to provide examples of other real life scenarios that
176 are anticipated to be supported by the framework. With the exception
177 of an initial example with media control messaging, the examples do
178 not include the details for the media control
179 [I-D.ietf-mediactrl-mixer-control-package], call signaling or binary
180 floor control [RFC4582] protocols. This document references the
181 scenarios in the Media Control call flows
182 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
183 [RFC4579] and binary floor control protocol documents.
185 5. Conference Creation
187 This section provides the details associated with the various ways in
188 which a conference can be created using CCMP and the XCON framework
189 constructs. As previously mentioned the details of the media
190 control, call signaling and floor control protocols, where
191 applicable, are annotated in the flows without showing all the
192 details. However, for clarification purposes, the first example
193 Section 5.1 provides the details of the media control messaging along
194 with an example of the standard annotation used throughout the
195 remainder of this document. In subsequent flows, only this
196 annotation (identified by lower case letters) is included and the
197 reader is encouraged to refer to the call flows in the relevant
198 documents for details for the other protocols. The annotations for
199 the call signaling are on the left side of the conferencing server
200 vertical bar and those for the media control messaging are on the
201 right side.
203 5.1. Basic Conference Creation
205 The simplest manner in which a conference can be created is
206 accomplished by the client sending a "confRequest" message with the
207 "create" operation as the only parameter to the conference server,
208 together with the "confUserID" associated with the requesting client
209 itself. This results in the creation of a default conference, with
210 an XCON-URI in the form of the "confObjID" parameter, the XCON-UserID
211 in the form of the "confUserID" parameter (the same already present
212 in the request) and the data for the conference object in the
213 "confInfo" parameter all returned in the "confResponse" message.
214 According to the implementation of the framework, this example may
215 also add the user that invoked the conference upon creation to the
216 conference object (e.g., "method" attribute in the "target" element
217 of "allowed-users-list" may be set to "dial out" for this client
218 based on the particular conferencing systems default). This is
219 exactly the case depicted in the figure, which is presented to enrich
220 the scenario. Note, that depending upon the conferencing system,
221 this default conference could be specific to the client requesting
222 the conference and thus may be different for the initiator than other
223 participants (e.g., IVR interactions in this case which are not
224 shown).
226 The specific data for the conference object is returned in the
227 "confResponse" message in the "confInfo" parameter. This allows the
228 client (with the appropriate authorization) to manipulate this data
229 and add additional participants to the conference, as well as change
230 the data during the conference. In addition, the client may
231 distribute the conferencing information to other participants
232 allowing them to join, the details of which are provided in
233 additional flows.
235 Clients that are not XCON-aware may join the conference using a
236 specific signaling interface such as SIP [RFC3261], using the
237 signaling interface to the conference focus as described in
239 [RFC4579]. However, these details are not shown in the message
240 flows. The message flows in this document identity the point in the
241 message flows at which this signaling occurs via the lower case
242 letter items (i.e., (a)...(x)) along with the appropriate text for
243 the processing done by the conferencing server.
245 CMCC1 CMCC2 CMCCx CONFS MS
246 | | | | |
247 |(1)confRequest(create, confUserID) | |
248 |-------------------------------------->| |
249 | | (a)Create +---| |
250 | | |Conf | | |
251 | | |Object | | |
252 | | |& IDs +-->| |
253 | | | | A1. CONTROL |
254 | | | |+++++++++++>>|
255 | | | |(create conf)|--+ (b)
256 | | | | | | create
257 | | | | | | conf and
258 | | | | A2. 200 OK |<-+ its ID
259 | | | |<<+++++++++++|
260 | | | |(confid=Y) |
261 |(2)confResponse(create, success, | |
262 | confObjID, confUserID | |
263 | confInfo) | | |
264 |<--------------------------------------| |
265 | | | | |
266 | | (c) Focus +---| |
267 | | sets up | | |
268 | | signaling | | |
269 | | to CMCC1 +-->| |
270 | | | | |
271 | | | | B1. CONTROL |
272 | | | |+++++++++++>>|
273 | | | | (join CMCC1 |
274 | | | | <->confY) |
275 | | | | |
276 | | | | |--+(d) join
277 | | | | | | CMCC1 &
278 | | | | B2.200 OK |<-+ conf Y
279 | | | |<<+++++++++++|
280 | | | | |
281 |<<#################################################>>|
282 | Now the CMCC1 is mixed in the conference |
283 |<<#################################################>>|
284 | | | | |
285 |******CMCC1 may then manipulate conference data *****|
286 |****** and add addt'l users, etc. | *****|
287 ' ' ' ' '
288 ' ' ' ' '
289 ' ' ' ' '
290 Figure 1: Create Basic Conference - Complete flow
292 "Alice" "Bob"
293 CMCC1 CMCC2 CMCCx CONFS
294 | | | |
295 |(1)confRequest(create, confUserID) |
296 |-------------------------------------->|
297 | | | |
298 | | (a)Create +---|
299 | | |Conf | |
300 | | |Object | |
301 | | |& IDs +-->|
302 | | | |--+ (b) MS
303 | | | | | creates
304 | | | | | conf and
305 | | | |<-+ its ID
306 | | | | (confid=Y)
307 |(2)confResponse(create, success |
308 | confObjID, confUserID |
309 | confInfo) | |
310 |<--------------------------------------|
311 | | | |
312 | | | |
313 | | (c) Focus +---|
314 | | sets up | |
315 | | signaling | |
316 | | to CMCC1 +-->|
317 | | | |
318 | | | |--+(d) MS joins
319 | | | | | CMCC1 &
320 | | | |<-+ conf Y
321 |<<###################################>>|
322 | CMCC1 is mixed in the conference |
323 |<<###################################>>|
324 | | | |
325 |**CMCC1 then manipulates conference****|
326 |** data and add addt'l users, etc. ***|
327 ' ' ' '
328 ' ' ' '
329 ' ' ' '
330 -
332 Figure 2: Create Basic Conference - Annotated Flow
334 1. confRequest message:
336
337
341
344 xcon-userid:alice@confSystem.com
345 create
346
347
349 2. confResponse message:
351
352
356
359 xcon:8977794@confSystem.com
360 xcon-userid:alice@confSystem.com
361 success
362
363
364
365
366 Default conference initiated by Alice
367
368
369
370
371 xcon:8977794@confSystem.com
372
373
374 Conference XCON-URI
375
376
377
378 10
379
380
381 audio
382
383
384
385
386 allow
387
388
390
391
392
393
394
395
397 Figure 3: Create Basic Conference (Annotated) Detailed Messaging
399 5.2. Basic Conference Creation for a specific instance of Conference
400 Information
402 A conference can also be created by the client sending a
403 "confRequest" message with the "create" operation, along with the
404 desired data in the form of the "confInfo" parameter for the
405 conference to be created. The request, as is the case of all CCMP
406 requests, also includes the "confUserID" of the requesting entity.
407 If the conferencing system can support that specific type of
408 conference (capabilities, etc.), then the request results in the
409 creation of a conference. In this success case, an XCON-URI in the
410 form of the "confObjID" parameter and the XCON-UserID in the form of
411 the "confUserID" parameter (again, the same as the requesting entity)
412 are returned in the "confResponse" message. The "confInfo" is not
413 returned unless changes have been made, in which case the
414 "responseCode" is "modified".
416 This example also activates the conference upon creation (i.e.,
417 "method" attribute is set to "dial out" for this client based on the
418 particular conferencing systems default). Just as before, this is
419 not to be considered mandatory, since it depends on the
420 implementation choices of the framework. Note, that depending upon
421 the conferencing system, this default conference could be specific to
422 the client requesting the conference and thus may be different for
423 the initiator than other participants (e.g., IVR interactions in this
424 case which are not shown).
426 "Alice" "Bob" "Carol" CONFS
427 | | | |
428 |(1)confRequest | | |
429 | (create, confUserID, confInfo) |
430 |-------------------------------------->|
431 | | | |
432 | | (a)Create +---|
433 | | |Conf | |
434 | | |Object | |
435 | | |& IDs +-->|
436 | | | |--+ (b) MS
437 | | | | | creates
438 | | | | | conf and
439 | | | |<-+ its ID
440 | | | | (confid=Y)
441 |(2) confResponse | |
442 | (create, success, confObjID |
443 | confUserID)| | |
444 |<--------------------------------------|
445 | | | |
446 | | (c) Focus +---|
447 | | sets up | |
448 | | signaling | |
449 | | to Alice +-->|
450 | | | |
451 | | | |--+(d) MS joins
452 | | | | | Alice &
453 | | | |<-+ conf Y
454 | | | |
455 | | | |
456 |<<###################################>>|
457 | Alice is mixed in the conference |
458 |<<###################################>>|
459 | | | |
460 | | (e)Focus +---|
461 | | sets up | |
462 | | signaling | |
463 | | to Bob | |
464 | | | +-->|
465 | | | |
466 | | | |--+(f)MS joins
467 | | | | | Bob &
468 | | | |<-+ conf Y
469 | | | |
470 | |<<###################>>|
471 | | Bob is mixed too |
472 | |<<###################>>|
473 | | | |
474 | | (g )Focus +---|
475 | | sets up | |
476 | | signaling | |
477 | | to Carol | |
478 | | CMCCx +-->|
479 | | | |
480 | | | |--+(h)MS joins
481 | | | | | CMCCx &
482 | | | |<-+ conf Y
483 | | | |
484 | | |<<#######>>|
485 | | |Carol mixed|
486 | | |<<#######>>|
487 | | | |
488 | | | |
489 | | | |
490 |<***All parties connected to conf Y***>|
491 | | | |
492 | | | |
493 " " " "
494 " " " "
495 " " " "
497 Figure 4: Create Basic Conference from user provided conference-info
499 1. confRequest message:
501
502
506
509 xcon-userid:Alice
510 create
511
512
513
514
515 Dial-out conference initiated by Alice
516
517
518
519
520 xcon:8977794@confSystem.com
521
522
523 Conference XCON-URI
524
525
526
527 10
528
529
530 audio
531
532
533
534
535 allow
536
537
539
541
543
544
545
546
547
548
550 2. confResponse message:
552
553
557
560 xcon:6845432@confSystem.com
561 xcon-userid:Alice
562 success
563
564
565 Figure 5: Create Basic Conference Detailed Messaging
567 5.3. Basic Conference Creation - Cloning an existing Conference
569 A client can also create another conference by cloning an existing
570 conference, such as an active conference or conference reseravation.
571 In this example, the client sends a "confRequest" message with the
572 "create" operation, along with the "confUserID" and a specific
573 "confObjID", from which a new conference is to be created by cloning
574 an existing conference.
576 An example of how a client can create a conference based on a
577 blueprint is provided in Section 5.4. The manner by which a client
578 in this example might learn about a conference reservation or active
579 conferences is similar to the first step in the blueprint example,
580 with the exception of specifying querying for different types of
581 conference objects supported by the specific conferencing system.
582 For example, in this example, the client clones a conference
583 reservation (i.e., an inactive conference).
585 If the conferencing system can support a new instance of the specific
586 type of conference(capabilities, etc.), then the request results in
587 the creation of a conference, with an XCON-URI in the form of a new
588 value in the "confObjID" parameter to reflect the newly cloned
589 conference object returned in the "confResponse" message. The
590 "confInfo" is not returned unless there had been changes, in which
591 case the "responseCode" is "modified".
593 "Alice" ConfS
594 | |
595 |(1) confRequest (create, |
596 | confObjID, confUserId) |
597 |------------------------------>|
598 | (a)Create +---|
599 | Conf | |
600 | Object | |
601 | & IDs +-->|
602 | |--+ (b) MS
603 | | | creates
604 | | | conf and
605 | |<-+ its ID
606 | | (confid=Y)
607 | |
608 |(2) confResponse |
609 | ( create, success, |
610 | confObjID*, confUserID) |
611 |<------------------------------|
612 | |
614 Figure 6: Create Basic Conference - Clone
616 1. "Alice" sends a confRequest message to clone a conference based
617 on an existing conference reservation. "Alice" indicates this
618 conference should be cloned from the specified parent conference
619 represented by the "confObjID" in the request.
621 2. Upon receipt of the confRequest message containing a "create"
622 operation and "confObjID", the conferencing system ensures that
623 the "confObjID" received is valid. The conferencing system
624 determines the appropriate read/write access of any users to be
625 added to a conference based on this "confObjID" (using
626 membership, roles, etc.). The conferencing system uses the
627 received "confObjID" to clone a conference reservation. The
628 conferencing system also reserves or allocates a new "confObjID"
629 (called "confObjID*" in Figure 6) to be used for the cloned
630 conference object. This new identifier is of course different
631 from the one associated with the conference to be cloned, since
632 it represents a different conference object. Any subsequent
633 protocol requests from any of the members of the conference must
634 address this new identifier. The conferencing system maintains
635 the mapping between this conference ID and the parent conference
636 object ID associated with the reservation through the conference
637 instance, and this mapping is explicitly addressed through the
638 "cloning-parent" element of the "conference-description" in the
639 new conference object.
641 1. confRequest message:
643
644
648
651 xcon:6845432@confSystem.com
652 xcon-userid:Alice
653 create
654
655
657 2. confResponse message:
659
660
664
667 xcon:8977794@confSystem.com
668 xcon-userid:Alice
669 create
670 success
672
673
674
675
676 New conference by Alice cloned from 6845432
677
678
679 xcon:6845432@confSystem.com
680
681
682
683
684 xcon:8977794@confSystem.com
685
686
687 conference xcon-uri
688
689
690 8601
691
692
693
694 10
695
696
697 audio
698
699
700
701
702 allow
703
704
705
706 confirm
707
708
709
710
711
712
713
714
716 Figure 7: Create Basic Conference (Clone) Detailed Messaging
718 5.4. Conference Creation using Blueprints
720 Figure 8 provides an example of one client "Alice" determining the
721 conference blueprints available for a particular conferencing system
722 and creating a conference based on the desired blueprint.
724 CMCC "Alice" ConfS
725 | |
726 | (1) blueprintsRequest |
727 | (confUserID) |
728 |------------------------------>|
729 | |
730 | (2) blueprintsResponse |
731 | (confUserID, success, |
732 | blueprintsInfo) |
733 |<------------------------------|
734 | |
735 |--+ |
736 | | choose preferred |
737 | | blueprint from the |
738 | | list (blueprintName) |
739 |<-+ |
740 | |
741 | (3) blueprintRequest |
742 | (retrieve, confObjID, |
743 | confUserID) |
744 |------------------------------>|
745 | |
746 | (4) blueprintResponse |
747 | (success, confObjID,|
748 | confUserID,confInfo)|
749 |<------------------------------|
750 | |
751 | (5) confRequest (create, |
752 | confobjID) |
753 |------------------------------>|
754 | |
755 | (a)Create +---|
756 | Conf | |
757 | Object | |
758 | & IDs +-->|
759 | |--+ (b) MS
760 | | | creates
761 | | | conf and
762 | |<-+ its ID
763 | | (confid=Y)
764 |(6) confResponse |
765 | (create, success, |
766 | confObjID*, confUserID) |
767 |<------------------------------|
768 | |
769 | |
770 | |
771 . .
772 . .
774 Figure 8: Client Creation of Conference using Blueprints
776 1. "Alice" first sends a "blueprintsRequest" message to the
777 conferencing system identified by the conference server discovery
778 process. Upon receipt of the "blueprintsRequest", the
779 conferencing system would first authenticate "Alice" and then
780 ensure that "Alice" has the appropriate authority based on system
781 policies to receive any blueprints supported by that system.
783 2. Any blueprint that "Alice" is authorized to use are returned in a
784 "blueprintsResponse" message in the "blueprintsInfo" attribute.
786 3. Upon receipt of the "blueprintsResponse" containing the
787 blueprints, "Alice" determines which blueprint to use for the
788 conference to be created. "Alice" sends a "blueprintRequest"
789 message to get the specific blueprint as identified by the
790 "confObjID".
792 4. The conferencing system returns the "confInfo" associated with
793 the specific blueprint as identified by the 'confObjID' in the
794 "blueprintResponse" message.
796 5. "Alice" then sends a "confRequest" with a "create" operation to
797 the conferencing system to create a conference reservation,
798 including the appropriate "blueprintName" and associated
799 "confObjID".
801 6. Upon receipt of the "confRequest" message with a "create"
802 operation, the conferencing system uses the received blueprint to
803 clone a conference, allocating a new "confObjID" (again called
804 "confObjID* in the example). The conferencing server then sends
805 a "confResponse" message including the new "confObjID*"
806 associated with the newly created conference instance. Upon
807 receipt of the "confResponse" message, "Alice" can now add other
808 users to the conference .
810 [Editors' Note: unlike what happened when cloning an existing
811 conference as presented in the previous subsection, no "cloning-
812 parent" is set in the response to the cloning of a blueprint. Is
813 this a desired behaviour? Or is this implementation specific?
814 Should the Data Model clarify the behaviour for such an event?]
816 1. blueprintsRequest message:
818
819
822
824 xcon-userid:Alice
825
826
828 2. blueprintsResponse message:
830
831
835
838 xcon-userid:Alice
839 success
840
841
842
843 xcon:AudioRoom@confSystem.com
844 AudioRoom
845 Simple Room:
846 conference room with public access,
847 where only audio is available, more users
848 can talk at the same time
849 and the requests for the AudioFloor
850 are automatically accepted.
851
852
853
854 xcon:VideoRoom@confSystem.com
855 VideoRoom
856 Video Room:
857 conference room with public access,
858 where both audio and video are available,
859 8 users can talk and be seen at the same time,
860 and the floor requests are automatically accepted.
861
862
863
864 xcon:AudioConference1@confSystem.com
865 AudioConference1
866 Public Audio Conference:
867 conference with public access,
868 where only audio is available,
869 only one user can talk at the same time,
870 and the requests for the AudioFloor MUST
871 be accepted by a Chair.
872
873
874
875 xcon:VideoConference1@confSystem.com
876 VideoConference1
877 Public Video Conference: conference
878 where both audio and video are available,
879 only one user can talk
880
881
882
883 xcon:AudioConference2@confSystem.com
884 AudioConference2
885 Basic Audio Conference:
886 conference with private access,
887 where only audio is available,
888 only one user can talk at the same time,
889 and the requests for the AudioFloor MUST
890 be accepted by a Chair.
891
892
893
894
895
896
898 3. blueprintRequest message:
900
901
905
907 xcon:AudioRoom@confSystem.com
908 xcon-userid:Alice
909 retrieve
910
911
912
914 4. blueprintResponse message:
916
917
921
923 retrieve
924 xcon:AudioRoom@confSystem.com
925 xcon-userid:Alice
926 success
927
928
929
930 AudioRoom
931 2
932
933
934 audio
935
936
937
938
939 allow
940
941
942 confirm
943
944
945
946
947
948
949
950
951
953 5. confRequest message:
955
956
960
964 xcon:AudioRoom@confSystem.com
965 xcon-userid:Alice
966 create
967
968
969
971 6. confResponse message:
973
974
978
981 xcon:8977794@confSystem.com
982 xcon-userid:Alice
983 create
984 success
985
986
987
988
989 New conference by Alice cloned from AudioRoom
990
991
992
993
994 xcon:8977794@confSystem.com
995
996
997 conference xcon-uri
998
999
1000 8601
1001
1002
1003
1004 10
1005
1006
1007 audio
1008
1009
1010
1011
1012 allow
1013
1014
1015
1016 confirm
1017
1018
1019
1020
1021
1022
1023
1024
1026 Figure 9: Create Conference (Blueprint) Detailed Messaging
1028 6. General Conference scenarios and examples
1030 The following scenarios are based on those documented in the XCON
1031 framework. The examples assume that a conference has already been
1032 correctly established, with media, if applicable, per one of the
1033 examples in Section 5.
1035 6.1. Conference Announcements and Recordings
1037 In this example, as shown in Figure 10 "Alice" is joining "Bob"'s
1038 conference that requires that she first enter a pass code. After
1039 successfully entering the passcode, an announcement prompts "Alice to
1040 speak her name so it can be recorded. When "Alice" is added to the
1041 active conference, the recording is played back to all the existing
1042 participants. A very similar example is presented in Figure 33 of
1043 [I-D.ietf-mediactrl-call-flows].
1045 CCMC "Alice" ConfS MS
1046 | | |
1047 |(1)userRequest (create, | |
1048 | confObjID, userInfo) | |
1049 |--------------------------->| |
1050 | |--+ Alice is |
1051 | | | new in the |
1052 | |<-+ system (create |
1053 | | confUserID) |
1054 | ConfS handles +--| |
1055 | SIP signaling | | |
1056 | (Alice<->ConfS<->MS) +->| |
1057 | | |
1058 | |--+ A password is |
1059 | | | required for |
1060 | |<-+ that conference |
1061 | | |
1062 | | Request IVR menu (PIN) |
1063 | |--------------------------->|
1064 | | |
1065 |<========= MS gets PIN from Alice through DTMF =========>|
1066 | | |
1067 | | Provided PIN is... |
1068 | |<---------------------------|
1069 | Check +--| |
1070 | PIN | | |
1071 | +->| |
1072 | |--+ Alice must |
1073 | | | record her |
1074 | |<-+ name |
1075 | | |
1076 | | Request name recording |
1077 | |--------------------------->|
1078 | | |
1079 |<========= MS records Alice's audio RTP (name) =========>|
1080 | | |
1081 | | Audio recording |
1082 | |<---------------------------|
1083 | Complete +--| |
1084 | creation | | |
1085 | of Alice +->| |
1086 | | |
1087 | (2) userResponse | |
1088 | (create, success | |
1089 | confObjID, confUserID) |
1090 |<---------------------------| |
1091 | | |
1092 Figure 10: Recording and Announcements
1094 1. Upon receipt of the userRequest from "Alice" to be added to
1095 "Bob's" conference (i.e., an "update" operation on "Bob's"
1096 conference object), the conferencing system determines that a
1097 password is required for this specific conference. Thus an
1098 announcement asking "Alice" to enter the password is provided to
1099 "Alice". This may be achieved by means of typical IVR
1100 fucntionality. Once "Alice" enters the password, it is validated
1101 against the policies associated with "Bob's" active conference.
1102 The conferencing system then connects to a server which prompts
1103 and records "Alice's" name. The conferencing system must also
1104 determine whether "Alice" is already a user of this conferencing
1105 system or whether she is a new user. In this case, "Alice" is a
1106 new user for this conferencing system, so a conference user
1107 identifier is created for "Alice". Based upon the addressing
1108 information provided by "Alice", the call signaling to add
1109 "Alice" to the conference is instigated through the Focus.
1111 2. The conference server sends "Alice" a userResponse message which
1112 includes the "confUserID" assigned by the conferencing system for
1113 "Alice". This would allow "Alice" to later perform operations on
1114 the conference (if she were to have the appropriate policies),
1115 including registering for event notifications associated with the
1116 conference. Once the call signaling indicates that "Alice" has
1117 been successfully added to the specific conference, per updates
1118 to the state, and depending upon the policies, other participants
1119 (e.g., "Bob") are notified of the addition of "Alice" to the
1120 conference via the conference notification service and an
1121 announcement is provided to all the participants indicating that
1122 "Alice" has joined the conference.
1124 [Editors' Note: this example showed the case of a private conference,
1125 where access required the knowledge of a password. In this case,
1126 access to the conference is handled by delegating the control of such
1127 value to the signaling/media. Nevertheless, the "password" value is
1128 present in CCMP requests as well, according to the latest
1129 specification. Should the presented flow make use of the CCMP
1130 password check alone, or is it ok to leave the signaling/media checks
1131 as well? What is the expected best common practice when dealing with
1132 such a scenario?]
1134 (CCMP Messaging details not available yet).
1136 Figure 11: Announcement Messaging Details
1138 6.2. Monitoring for DTMF
1140 The conferencing system also needs the capability to monitor for DTMF
1141 from each individual participant. This would typically be used to
1142 enter the identifier and/or access code for joining a specific
1143 conference.
1145 An example of DTMF monitoring, within the context of the framework
1146 elements, is shown in Figure 10. A typical way for the conferencing
1147 system to be aware of all the DTMF interactions within the context of
1148 conferences it is responsible for, is making use of the MEDIACTRL
1149 architecture for what regards media manipulation. Examples in that
1150 sense (specifically for what concerns DTMF interception in conference
1151 instances) are presented in [I-D.ietf-mediactrl-call-flows].
1153 6.3. Adding a Party
1155 In this example, "Alice" wants to add "Bob" to an established
1156 conference. In the following example we assume "Bob" is a new user
1157 to the system, which means "Alice" also needs to provide details
1158 about him. In fact, the case of "Bob" already present as a user in
1159 the conferencing system is much easier to address, and will be
1160 discussed later on.
1162 "Alice" "Bob"
1163 CMCC1 CMCC2 CMCCx ConfS
1164 | | | |
1165 |(1) userRequest(create, | |
1166 | confObjID, confUserID, | |
1167 | userInfo) | | |
1168 |-------------------------------------->|
1169 | | | |
1170 | | (a) Create +---|
1171 | | | "Bob" | |
1172 | | | as a | |
1173 | | | user +-->|
1174 | | | |
1175 |(2) userResponse(create, success |
1176 | confObjID, confUserID |
1177 | userInfo) | |
1178 |<--------------------------------------|
1179 | | | |
1180 | | | (b) Focus |
1181 | | | sets up |
1182 | | | signaling |
1183 | | | to "Bob" |
1184 | |<----------------------|
1185 | | | |
1186 | | | (c) Notify|
1187 | | | ("Bob just|
1188 | | | joined") |
1189 | | |<----------|
1190 | | | |
1191 ' ' ' '
1192 ' ' ' '
1193 ' ' ' '
1195 Figure 12: Client Manipulation of Conference - Add a party
1197 1. "Alice" sends a userRequest message with an operation of "create"
1198 to add "Bob" to the specific conference as identified by the
1199 confObjID. The "create" operation also makes sure that "Bob" is
1200 created as a user in the whole conferencing system. This is done
1201 by adding a "userInfo" element describing "Bob" as a user. This
1202 is needed in order to let the conferencing system be aware of
1203 "Bob"'s characteristics. In case Bob was already a registered
1204 user, "Alice" would just have referenced him through his XCON
1205 UserID, without providing the additional "userInfo". In fact,
1206 that information (including, for instance, "Bob"'s SIP URI to be
1207 used subsequently for dial-out) would be obtained by referencing
1208 the extant registration. The conference server ensures that
1209 "Alice" has the appropriate authority based on the policies
1210 associated with that specific conference object to perform the
1211 operation. As mentioned before, a new Conference User Identifier
1212 is created for Bob, and the "userInfo" is used to update the
1213 conference object accordingly.
1215 2. In the presented example, the call signaling to add "Bob" to the
1216 conference is instigated through the Focus as well. Please
1217 notice that this is implementation specific. In fact, a
1218 conferencing system may accomplish different actions after the
1219 user creation, just as it may do nothing at all. Among the
1220 possible actions, for instance "Bob" may be added as a "target"
1221 element to the "allowed-users-list" element, whose joining
1222 "method" may be either "dial-in" or "dial-out". Besides, out-of-
1223 band notification mechanisms may be involved as well, e.g. to
1224 notify "Bob" via mail of the new conference, including details as
1225 the date, password, expected participants and so on.
1227 (c) To conclude the overview on this scenario, once "Bob" has been
1228 successfully added to the specified conference, per updates to the
1229 state, and depending upon the policies, other participants
1230 (including "Bob" himself) may be notified of the addition of "Bob"
1231 to the conference via the Conference Notification Service.
1233 1. userRequest message:
1235
1236
1239
1241 xcon-userid:alice@confSystem.com
1242 xcon:8977878@confSystem.com
1243 create
1244
1245
1246 Bob
1247
1248
1249 mailto:bob.depippis@example.com
1250 Bob's email
1251
1252
1253
1254 Bob's laptop
1256
1257
1258
1259
1260
1262 2. userResponse message:
1264
1265
1268
1270 xcon-userid:alice@confSystem.com
1271 xcon:8977878@confSystem.com
1272 create
1273 success
1274
1275
1276 Bob
1277
1278
1279 mailto:bob.depippis@example.com
1280 Bob's email
1281
1282
1283
1284 Bob's laptop
1285
1286
1287
1288
1289
1291 Figure 13: Add Party Message Details
1293 6.4. Muting a Party
1295 This section provides an example of the muting of a party in an
1296 active conference. The unmuting would involve the identical CCMP
1297 message flow. Although, in the case that floor control is involved,
1298 whether or not a particular conference client can unmute itself must
1299 be considered by the conferencing system.
1301 [Editors' Note: The interaction between CCMP and floor control
1302 should be carefully considered. In fact, if floor control is
1303 achieved by means of BFCP [RFC4582], this means could conflict
1304 with the functionality provided by CCMP. A typical example would
1305 be Alice (the CCMP moderator) unmuting Bob by means of CCMP. Such
1306 approach would conflict with BFCP, considering that if a BFCP
1307 chair wants to subsequently revoke the floor from Bob, it cannot
1308 do it, since no FloorRequestID would be associated with the
1309 previous unmute achieved by Alice. Besides, unmuting via CCMP
1310 would bypass the Floor Control Server floor queues. How should we
1311 handle this? Should we envisage CCMP muting/unmuting as a wrapper
1312 to BFCP whenever floor control is involved? Another solution
1313 might be handling CCMP- and BFCP-based media control as multiple
1314 layers: i.e., a participant may have the BFCP floor granted, but
1315 be muted by means of CCMP. If so, he would still be muted in the
1316 conference, and would only be unmuted if both the protocols
1317 allowed for this.]
1319 Figure 14 provides an example of one client "Alice" impacting the
1320 media state of another client "Bob". This example assumes an
1321 established conference. In this example, the client, "Alice" whose
1322 Role is "moderator" of the conference, wants to mute "Bob" on a
1323 medium-size multi-party conference, as his device is not muted (and
1324 he's obviously not listening to the call) and background noise in his
1325 office environment is disruptive to the conference. BFCP floor
1326 control is assumed not to be involved.
1328 "Alice" "Bob"
1329 CMCC1 CMCC2 CMCCx ConfS MS
1330 | | | | |
1331 |(1) userRequest(update, | | |
1332 | confObjID, confUserID, | | |
1333 | userInfo) | | | |
1334 |------------------------------.-------->| |
1335 | | | | Mute Bob |
1336 | | | |----------------->|
1337 | | | | 200 OK |
1338 | | | |<-----------------|
1339 | | | | |
1340 | |<====== XXX Bob excluded from mix XXX ====>|
1341 | | | | |
1342 | | (a) Update +---| |
1343 | | Bob in | | |
1344 | | Data Model | | |
1345 | | (muted) +-->| |
1346 | | | | |
1347 |(2) userResponse(update, success | |
1348 | confObjID, confUserID) | |
1349 |<---------------------------------------| |
1350 | | | | |
1351 | | | (b) Notify | |
1352 | | | ("Bob is | |
1353 | | | muted") | |
1354 | | |<-----------| |
1355 | | | | |
1356 ' ' ' ' '
1357 ' ' ' ' '
1358 ' ' ' ' '
1360 Figure 14: Client Manipulation of Conference - Mute a party
1362 1. Upon receipt of userRequest message with an update operation and
1363 the userInfo with the "status" field in the "media" element for
1364 "Bob" set to "revconly". The Conference Server ensures that
1365 "Alice" has the appropriate authority based on the policies
1366 associated with that specific conference object to perform the
1367 operation and updates the userInfo in the conference object
1368 reflect that "Bob"s media is not to be mixed with the conference
1369 media. In case the Conference Server relies on a remote Media
1370 Server for its multimedia functionality, it subsequently changes
1371 "Bob"'s media profile accordingly by means of the related
1372 protocol interaction with the MS. An example describing a
1373 possible way of dealing with such a situation using the Media
1374 Server Control architecture is described in
1376 [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
1377 Transactions (2)".
1379 2. A userResponse message with a responseCode of "success" is then
1380 sent to "Alice". Depending upon the policies, tne conference
1381 server may notify other participants (including "Bob") of this
1382 update via the Conference Notification Service.
1384 1. userRequest message:
1386
1387
1390
1392 xcon-userid:alice@confSystem.com
1393 xcon:8977878@confSystem.com
1394 update
1395
1396
1397
1398
1399 123
1400 recvonly
1401
1402
1403
1404
1405
1406
1408 2. userResponse message:
1410
1411
1414
1416 xcon-userid:alice@confSystem.com
1417 xcon:8977878@confSystem.com
1418 update
1419 success
1420
1421
1422
1424 Figure 15: Mute Message Details
1426 6.5. Internal Sidebar
1428 Figure 16 provides an example of one client "Alice" involved in
1429 active conference with "Bob" and "Carol". "Alice" wants to create a
1430 sidebar to have a side discussion with "Bob" while still viewing the
1431 video associated with the main conference. Alternatively, the audio
1432 from the main conference could be maintained at a reduced volume.
1433 "Alice" initiates the sidebar by sending a request to the
1434 conferencing system to create a conference reservation based upon the
1435 active conference object. "Alice" and "Bob" would remain on the
1436 roster of the main conference, such that other participants could be
1437 aware of their participation in the main conference, while an
1438 internal-sidebar conference is occurring. Besides, "Bob" decides
1439 that he is not interested in still receiving the conference audio in
1440 background (not even at a lower volume as "Alice" configured) and so
1441 modifies the sidebar in order to make that stream inactive for him.
1443 "Alice" "Bob" ConfS
1444 | | |
1445 |(1) sidebarByValRequest |
1446 | (create, confUserID, |
1447 | confObjID) | |
1448 |--------------------------------------------->|
1449 | | |
1450 | | (a) Create +---|
1451 | | sidebar-by-val | |
1452 | | (new conf obj | |
1453 | | cloned from +-->|
1454 | | confObjID) | Sidebar now has
1455 | | | id confObjID*
1456 |(2) sidebarByValResponse | (parent mapping
1457 | (create, success, confObjID* | conf<->sidebar)
1458 | confUserID, sidebarByValInfo) |
1459 |<---------------------------------------------|
1460 | | |
1461 |(3) sidebarByValRequest |
1462 | (update, confUserID, |
1463 | confObjID*, sidebarByValInfo) |
1464 |--------------------------------------------->|
1465 | | |
1466 | | (b) Update +---|
1467 | | sidebar-by-val | |
1468 | | (media, users | |
1469 | | etc.) +-->|
1470 | | | Sidebar is
1471 | | | modified
1472 |(4) sidebarByValResponse |
1473 | (update, success, confObjID* |
1474 | confUserID) | |
1475 |<---------------------------------------------|
1476 | | |
1477 | |(5) userRequest |
1478 | | (update, confUserID',|
1479 | | confObjID*, |
1480 | | userInfo) |
1481 | |---------------------->|
1482 | | |
1483 | | (c) Update +---|
1484 | | user settings | |
1485 | | (Bob's media) | |
1486 | | +-->|
1487 | | | Sidebar is modified
1488 | | | (original audio
1489 | | | inactive for Bob)
1490 | |(6) userResponse |
1491 | | (update, success |
1492 | | confObjID*, |
1493 | | confUserID') |
1494 | |<----------------------|
1495 | | |
1496 " " "
1497 " " "
1498 " " "
1500 Figure 16: Client Creation of a Sidebar Conference
1502 1. Upon receipt of CCMP sidebarByValRequest message to "reserve" a
1503 new sidebar conference based upon the confObjID received in the
1504 request, the conferencing system uses the confObjID to clone a
1505 conference reservation for the sidebar. The sidebar reservation
1506 is NOT independent of the active conference (i.e., parent). The
1507 conferencing system also reserves or allocates a new confObjID to
1508 be used for any subsequent protocol requests from any of the
1509 members of the conference.
1511 2. The relationship information is provided in the
1512 sidebarByValResponse message, specifically in the "sidebar-
1513 parent" element. A dump of the complete representation of the
1514 main/parent conference is provided below as well to show how the
1515 cloning process for the creation of the sidebar could take place.
1517 3. Upon receipt of the sidebarByValResponse message to reserve the
1518 conference, "Alice" can now create an active conference using
1519 that reservation, or create additional reservations based upon
1520 the existing reservations. In this example, "Alice" wants only
1521 "Bob" to be involved in the sidebar, thus she manipulates the
1522 membership so that only the two of them appear in the "allowed-
1523 users-list" section. "Alice" also wants both audio and the video
1524 from the original conference to be available in the sidebar. For
1525 what concerns the media belonging to the sidebar itself, "Alice"
1526 wants the audio to be restricted to the participants in the
1527 sidebar (that is, her and "Bob"). Additionally, "Alice"
1528 manipulates the media values to recieve the audio from the main
1529 conference at a reduced volume, so that the communication between
1530 her and "Bob" isn't affected. "Alice" sends a
1531 sidebarByValRequest message with an operation of "update" along
1532 with the sidebarByValInfo in the reservation, to create an active
1533 conference.
1535 4. Upon receipt of the sidebarByValRequest to update the reservation
1536 to create an active conference for the sidebar, as identified by
1537 the sidebar conference object ID, the conference server ensures
1538 that "Alice" has the appropriate authority based on the policies
1539 associated with that specific conference object to perform the
1540 operation. The conference server must also validate the updated
1541 information in the reservation, ensuring that a member like "Bob"
1542 is already a user of this conference server. Once the data for
1543 the confObjID is updated, the conference server sends a
1544 sidebarByValResponse to "Alice". Depending upon the policies,
1545 the initiator of the request (i.e., "Alice") and the participants
1546 in the sidebar (i.e., "Bob") may be notified of his addition to
1547 the sidebar via the conference notification service.
1549 5. At this point, "Bob" sends a userRequest message to the
1550 conference server with an operation of "update" to completely
1551 disable the background audio from the parent conference, since it
1552 prevents him from understanding what "Alice" says in the sidebar.
1554 6. Notice that "Bob's" request only changes the media perspective
1555 for "Bob". "Alice" keeps on receiving both the audio from "Bob"
1556 and the background from the parent conference. This request may
1557 be relayed by the conference server to the Media Server handling
1558 the mixing, if present. Upon completion of the change, the
1559 conference server sends a "userResponse" message to "Bob".
1560 Depending upon the policies, the initiator of the request (i.e.,
1561 "Bob") and the participants in the sidebar (i.e., "Alice") may be
1562 notified of this change via the conference notification service.
1564 That said, let's consider the following conference object:
1566
1567
1572
1573 MAIN CONFERENCE
1574
1575
1576 sip:8977878@confSystem.com
1577 conference sip uri
1578
1579
1580
1581
1582 main conference audio
1583 audio
1584 sendrecv
1585
1586
1587 main conference video
1588 video
1589 sendrecv
1590
1591 single-view
1592
1593
1594
1595
1596
1597 true
1598
1599
1600
1601 Alice
1602
1603
1604 123
1605 sendrecv
1606
1607
1608 456
1609 sendrecv
1610
1611
1612
1613
1614 Bob
1615
1616
1617 123
1618 sendrecv
1619
1620
1621 456
1622 sendrecv
1623
1624
1625
1626
1627 Carol
1628
1629
1630 123
1631 sendrecv
1632
1633
1634 456
1635 sendrecv
1636
1637
1638
1639
1640
1642 This is the representation of the conference the sidebar is going to
1643 be created in. As such, it will be used by the conferencing system
1644 in order to create the new conference object associated with the
1645 sidebar. In fact, the sidebar creation happens through a cloning of
1646 the parent conference. Once the sidebar is created, an "update"
1647 makes sure that the sidebar is customized as needed. The following
1648 protocol dump makes the process clearer.
1650 1. sidebarByValRequest (create)
1652
1653
1656
1658 xcon-userid:alice@confSystem.com
1659 xcon:8977878@confSystem.com
1660 create
1661
1662
1663
1665 2. sidebarByValResponse (create success)
1667
1668
1672
1674 xcon-userid:alice@confSystem.com
1675 xcon:8974545@confSystem.com
1676 success
1677
1678
1679
1680
1681 SIDEBAR CONFERENCE registered by alice
1682
1683
1684 xcon:8977878@confSystem.com
1685
1686
1687
1688
1689 main conference audio
1690
1691 audio
1692 sendrecv
1693
1694
1695
1696 main conference video
1697
1698 video
1699 sendrecv
1700
1701
1702
1703
1704 false
1705
1706
1707
1708
1710
1712
1714
1715
1716
1717
1718
1719
1721 3. sidebarByValRequest (update)
1723
1724
1728
1730 xcon-userid:alice@confSystem.com
1731 xcon:8974545@confSystem.com
1732 update
1733
1734
1735
1736
1737 private sidebar alice - bob
1738
1739
1740
1741
1742 main conference audio
1743
1744 audio
1745 recvonly
1746
1747 -60
1748
1749
1750
1751
1752 main conference video
1754
1755 video
1756 recvonly
1757
1758
1759
1760 sidebar audio
1761
1762 audio
1763 sendrecv
1764
1765
1766
1767 sidebar video
1768
1769 video
1770 sendrecv
1771
1772
1773
1774
1775
1776
1778
1780
1781
1782
1783
1784
1785
1787 4. sidebarByValResponse (update success)
1788
1789
1793
1795 xcon-userid:alice@confSystem.com
1796 xcon:8974545@confSystem.com
1797 update
1798 success
1799
1800
1802
1804 5. userRequest (Bob's media)
1805
1806
1810
1812 xcon-userid:bob@confSystem.com
1813 xcon:8974545@confSystem.com
1814 update
1815
1816
1817
1818
1819
1820 main conference audio
1821
1822 123
1823 inactive
1824
1825
1826
1827
1828
1829
1831 6. userResponse (update success)
1832
1833
1836
1838 xcon-userid:bob@confSystem.com
1839 xcon:8974545@confSystem.com
1840 update
1841 success
1842
1843
1844
1846 Figure 17: Internal Sidebar Messaging Details
1848 6.6. External Sidebar
1850 Figure 18 provides an example of a different approach towards
1851 sidebar. In this scenario, one client, "Alice", is involved in an
1852 active conference with "Bob", "Carol", "David" and "Ethel". "Alice"
1853 gets an important text message via a whisper from "Bob" that a
1854 critical customer needs to talk to "Alice", "Bob" and "Ethel".
1855 "Alice" creates a sidebar to have a side discussion with the customer
1856 "Fred" including the participants in the current conference with the
1857 exception of "Carol" and "David", who remain in the active
1858 conference. The difference from the previous scenario is that "Fred"
1859 is not part of the parent conference: this means that different
1860 policies might be involved, considering that "Fred" may access
1861 information coming from the parent conference, in case the sidebar
1862 was configured accordingly. For this reason, in this scenario we
1863 assume that "Alice" disables all the media from the original (parent)
1864 conference within the sidebar. This means that, while in the
1865 previous example "Alice" and "Bob" still heard the audio from the
1866 main conference in background, this time no background is made
1867 available. "Alice" initiates the sidebar by sending a request to the
1868 conferencing system to create a conference reservation based upon the
1869 active conference object. "Alice", "Bob" and "Ethel" would remain on
1870 the roster of the main conference in a hold state. Whether or not
1871 the hold state of these participants is visible to other participants
1872 depends upon the individual and local policy.
1874 "Alice" "Bob" ConfS
1875 | | |
1876 |(1) sidebarByRefRequest |
1877 | (create, confUserID, |
1878 | confObjID) | |
1879 |--------------------------------------------->|
1880 | | |
1881 | | (a) Create +---|
1882 | | sidebar-by-ref | |
1883 | | (new conf obj | |
1884 | | cloned from +-->|
1885 | | confObjID) | Sidebar now has
1886 | | | id confObjID*
1887 |(2) sidebarByRefResponse | (parent mapping
1888 | (create, success, confObjID* | conf<->sidebar)
1889 | confUserID, sidebarByRefInfo) |
1890 |<---------------------------------------------|
1891 | | |
1892 |(3) sidebarByRefRequest |
1893 | (update, confUserID, |
1894 | confObjID*, sidebarByRefInfo) |
1895 |--------------------------------------------->|
1896 | | |
1897 | | (b) Create +---|
1898 | | new user for | |
1899 | | "Fred" | |
1900 | | +-->|
1901 | | |
1902 | | (c) Update +---|
1903 | | sidebar-by-val | |
1904 | | (media, users | |
1905 | | policy, etc.) +-->|
1906 | | | Sidebar is modified:
1907 | | | no media from the
1908 | | | parent conference is
1909 | | | available to anyone
1910 |(4) sidebarByRefResponse |
1911 | (update, success, confObjID* |
1912 | confUserID) | |
1913 |<---------------------------------------------|
1914 | | |
1915 | | Notify ("Fred" |
1916 | | added to |
1917 | | sidebar users) |
1918 | |<----------------------|
1919 | | |
1920 " " "
1921 " " "
1922 " " "
1924 Figure 18: Client Creation of an External Sidebar
1926 1. Upon receipt of the "sidebarByRefRequest" message to create a new
1927 sidebar conference, based upon the active conference specified by
1928 "confObjID" in the request, the conferencing system uses the
1929 received active conference to clone a conference reservation for
1930 the sidebar. The sidebar reservation is NOT independent of the
1931 active conference (i.e., parent). The conferencing system as
1932 before reserves or allocates a conference ID (confObjID*) to be
1933 used for any subsequent protocol requests from any of the members
1934 of the conference. The conferencing system maintains the mapping
1935 between this conference ID and the conference object ID
1936 associated with the sidebar reservation through the conference
1937 instance. Just as before, this mapping is mantained in "sidebar-
1938 parent".
1940 2. Upon receipt of the "sidebarByRefResponse" message, which
1941 acknowledges the successful creation of the sidebar object,
1942 "Alice" decides that only "Bob" and "Ethel", along with the new
1943 participant "Fred" are to be involved in the sidebar. Thus she
1944 manipulates the membership accordingly. "Alice" also sets the
1945 media in the "conference-info" such that the participants in the
1946 sidebar don't receive any media from the main conference. All
1947 these settings are provided to the conferencing system by means
1948 of a new "sidebarByRefRequest" message, with an "update"
1949 operation.
1951 3. "Alice" sends the aforementioned "sidebarByRefRequest" to update
1952 the information in the reservation and to create an active
1953 conference. Upon receipt of the "sidebarByRefRequest" with an
1954 operation of "update", the conferencing system ensures that
1955 "Alice" has the appropriate authority based on the policies
1956 associated with that specific conference object to perform the
1957 operation. The conferencing system also validates the updated
1958 information in the reservation. Since "Fred" is a new user for
1959 this conferencing system, a conference user identifier is created
1960 for "Fred". Specifically, "Fred" is added to the conference by
1961 only providing his SIP URI. Based upon the addressing
1962 information provided for "Fred" by "Alice", the call signaling to
1963 add "Fred" to the conference may be instigated through the Focus
1964 (e.g. if "Fred" had a "dial-out" method set as the target for
1965 him) at the actual activation of the sidebar.
1967 4. The conference server sends a "sidebarByRefResponse" message and,
1968 depending upon the policies, the initiator of the request (i.e.,
1969 "Alice") and the participants in the sidebar (i.e., "Bob" and
1970 "Ethel") may be notified of his addition to the sidebar via the
1971 conference notification service.
1973 1. sidebarByRefRequest (create)
1975
1976
1979
1981 xcon-userid:alice@confSystem.com
1982 xcon:8977878@confSystem.com
1983 create
1984
1985
1987
1989 2. sidebarByRefResponse (create success)
1991
1992
1996
1998 xcon-userid:alice@confSystem.com
1999 xcon:8971212@confSystem.com
2000 success
2001
2002
2003
2004
2005 SIDEBAR CONFERENCE registered by alice
2006
2007
2008 xcon:8977878@confSystem.com
2009
2010
2011
2012
2013 main conference audio
2014
2015 audio
2016 sendrecv
2017
2018
2019
2020 main conference video
2021
2022 video
2023 sendrecv
2024
2025
2026
2027
2028 false
2029
2030
2031
2032
2034
2036
2038
2040
2042
2043
2044
2045
2046
2047
2049 3. sidebarByRefRequest (update)
2051
2055
2057 xcon-userid:alice@confSystem.com
2058 xcon:8971212@confSystem.com
2059 update
2060
2061
2062
2063
2064 sidebar alice, bob, ethel & fred
2065
2066
2067
2068
2069 main conference audio
2070
2071 audio
2072 inactive
2073
2074
2075
2076 main conference video
2077
2078 video
2079 inactive
2080
2081
2082
2083 sidebar audio
2084
2085 audio
2086 sendrecv
2087
2088
2089
2090 sidebar video
2091
2092 video
2093 sendrecv
2094
2095
2096 single-view
2097
2098
2099
2100
2101
2102
2103 false
2104
2105
2106
2107
2109
2111
2113
2114
2115
2116
2117
2118
2120 4. sidebarByRefResponse (update success)
2122
2126
2128 xcon-userid:alice@confSystem.com
2129 xcon:8971212@confSystem.com
2130 update
2131 success
2132
2133
2134
2136 Figure 19: External Sidebar Messaging Details
2138 6.7. Floor control using sidebars
2140 Floor control with sidebars can be used to realize conferencing
2141 scenario such as an analyst briefing. In this scenario, the
2142 conference call has a panel of speakers who are allowed to talk in
2143 the main conference. The other participants are the analysts, who
2144 are not allowed to speak unless they have the floor. To request
2145 access to the floor, they have to join a new sidebar with the
2146 moderator and ask their question. The moderator can also whisper to
2147 each analyst what their status/position in the floor control queue,
2148 similar to the example in Figure 22. It should be noted that other
2149 mechanisms which don't make use of sidebars could be used for floor
2150 control such as those detailed in BFCP.
2152 Figure 20 provides an example of the configuration involved for this
2153 type of conference. As in the previous sidebar examples, there is
2154 the main conference along with a sidebar. "Alice" and "Bob" are the
2155 main participants in the conference, with "A1", "A2" and "A3"
2156 representing the analysts. The sidebar remains active throughout the
2157 conference, with the moderator, "Carol", serving as the chair. As
2158 discussed previously, the sidebar conference is NOT independent of
2159 the active conference (i.e., parent). The analysts are provided the
2160 conference object ID associated with the active sidebar when they
2161 join the main conference. The conferencing system also allocates a
2162 conference ID to be used for any subsequent manipulations of the
2163 sidebar conference. The conferencing system maintains the mapping
2164 between this conference ID and the conference object ID associated
2165 with the active sidebar conference through the conference instance.
2166 The analysts are permanently muted while in the main conference. The
2167 analysts are moved to the sidebar when they wish to speak. Only one
2168 analyst is given the floor at a given time. All participants in the
2169 main conference receive audio from the sidebar conference, as well as
2170 audio provided by the panelists in the main conference.
2172 (To Be added).
2174 Figure 20: Floor Control with sidebars
2176 1. "A1" wishes to ask a question, so he sends a Floor Request
2177 message to the floor control server.
2179 2. Upon receipt of the request, the floor control server notifies
2180 the moderator, "Carol" of the active sidebar conference, whose
2181 serving as the floor chair.
2183 3. Since no other analysts have yet requested the floor, "Carol"
2184 indicates to the floor control server that "A1" may be granted
2185 the floor.
2187 (CCMP Messaging details not available yet).
2189 Figure 21: Floor Control Messaging Details
2191 6.8. Whispering or Private Messages
2193 The case of private messages can be handled as a sidebar with just
2194 two participants, similar to the example in section Section 6.5, but
2195 rather than using audio within the sidebar, "Alice" could add an
2196 additional text based media stream to the sidebar. The other
2197 context, referred to as whisper, in this document refers to
2198 situations involving one time media targetted to specific user(s).
2199 An example of a whisper would be an announcement injected only to the
2200 conference chair or to a new participant joining a conference.
2202 Figure 22 provides an example of one user "Alice" whose chairing a
2203 fixed length conference with "Bob" and "Carol". The configuration is
2204 such that only the chair is providing a warning when there is only 10
2205 minutes left in the conference. At that time, "Alice" is moved into
2206 a sidebar created by the conferencing system and only "Alice"
2207 receives the announcement.
2209 (To Be completed).
2211 Figure 22: Whisper
2213 1. When the conferencing system determines that there is only 10
2214 minutes left in the conference which "Alice" is chairing, the
2215 conferencing system directly creates an active sidebar
2216 conference, based on the active conference associated with
2217 "Alice". This sidebar conference is NOT independent of the
2218 active conference (i.e., parent). The conferencing system also
2219 allocates a conference ID to be used for any subsequent
2220 manipulations of the sidebar conference.
2222 2. Immediately upon creation of the active sidebar conference, the
2223 announcement media is provided to "Alice". Depending upon the
2224 policies, Alice may be notified of her addition to the sidebar
2225 via the conference notification service. "Alice" continues to
2226 receive the media from the main conference.
2228 3. Upon completion of the announcement, "Alice" is removed from the
2229 siebar and the sidebar conference is deleted.
2231 4. "Alice" is notified of her removal from the sidebar via the
2232 conference notification service.
2234 (CCMP Messaging details not available yet).
2236 Figure 23: Whisper Messaging Details
2238 6.9. Observing and Coaching
2240 An example of observing and coaching is shown in figure Figure 24.
2241 In this example, call center agent "Bob" is involved in a conference
2242 with customer "Carol". Since "Bob" is a new agent and "Alice" sees
2243 that he has been on the call with "Carol" for longer than normal, she
2244 decides to observe the call and coach "Bob" as necessary.
2246 (Figure not available yet).
2248 Figure 24: Supervisor Creating a Sidebar for Observing/Coaching
2250 1. Upon receipt of the confRequest from "Alice" to "create" a new
2251 sidebar conference from the confObjID received in the request,
2252 the conferencing system uses the received active conference to
2253 clone a conference reservation for the sidebar. The conferencing
2254 system also allocates a conference ID to be used for any
2255 subsequent protocol requests from any of the members of the
2256 conference. The conferencing system maintains the mapping
2257 between this conference ID and the confObjID associated with the
2258 sidebar reservation through the conference instance. The
2259 conference server sends a confResponse message with the new
2260 confObjID and relevant confInfo.
2262 2. Upon receipt of the confResponse message, "Alice" manipulates the
2263 data received in the confInfo in the response. "Alice" wants
2264 only "Bob" to be involved in the sidebar, thus she updates the
2265 "allowed-users-list" to include only "Bob". "Alice" also wants
2266 the audio to be received by herself and "Bob" from the original
2267 conference, but wants any outgoing audio from herself to be
2268 restricted to the participants in the sidebar, whereas "Bob's"
2269 outgoing audio should go to the main conference, so that both
2270 "Alice" and the customer "Carol" hear the same audio from "Bob".
2271 "Alice" sends a confRequest message with an "update" operation
2272 including the updated conference information.
2274 3. Upon receipt of the confRequest message with an "update"
2275 operation, the conferencing system ensures that "Alice" has the
2276 appropriate authority based on the policies associated with that
2277 specific conference object to perform the operation.
2279 4. After validating the data, the conference server sends a
2280 confResponse message. Based upon the addressing information
2281 provided for "Bob" by "Alice", the call signaling to add "Bob" to
2282 the sidebar with the appropriate media characteristics is
2283 instigated through the Focus. "Bob" is notified of his addition
2284 to the sidebar via the conference notification service, thus he
2285 is aware that "Alice" the supervisor is available for coaching
2286 him through this call.
2288 (CCMP Messaging details not available yet).
2290 Figure 25: Coaching and Observing Messaging details
2292 7. Removing participants and deleting conferences
2294 The following scenarios detail the basic operations associated with
2295 removing participants from conferences and entirely deleting
2296 conferences. The examples assume that a conference has already been
2297 correctly established, with media, if applicable, per one of the
2298 examples in Section 5.
2300 7.1. Removing a Party
2302 Figure 26 provides an example of one client "Alice" removing another
2303 participant "Bob" from a conference. This example assumes an
2304 established conference with "Alice", "Bob", "Claire" and "Duck". In
2305 this example, "Alice" wants to remove "Bob" from the conference so
2306 that the group can continue in the same conference without "Bob"'s
2307 participation.
2309 "Alice" "Bob" "Claire" ConfS
2310 | | | |
2311 |(1) userRequest(delete, | |
2312 | confObjID, confUserID, | |
2313 | userInfo) | | |
2314 |-------------------------------------->|
2315 | | | |
2316 | | | (a) Focus |
2317 | | | tears down|
2318 | | | signaling |
2319 | | | to "Bob" |
2320 | |<----------------------|
2321 | | |
2322 | | (b)Deletes+---|
2323 | | | "Bob" | |
2324 | | | as a | |
2325 | | | user +-->|
2326 | | | in |
2327 | | | confObj |
2328 | | | |
2329 |(2) userResponse(delete, success |
2330 | confObjID) | |
2331 | | | |
2332 |<--------------------------------------|
2333 | | | |
2334 | | | |
2335 | | | (c) Notify|
2336 | | | ("Bob just|
2337 | | | left") |
2338 | | |<----------|
2339 | | | |
2340 ' ' ' '
2341 ' ' ' '
2342 ' ' ' '
2343 Figure 26: Client Manipulation of Conference - Remove a party
2345 1. "Alice" sends a userRequest message, with a "delete" operation.
2346 The conference server ensures that "Alice" has the appropriate
2347 authority based on the policies associated with that specific
2348 conference object to perform the operation.
2350 2. Based upon the addressing and media information in the conference
2351 object for "Bob" in the "user" element, the conference instigates
2352 the process to remove "Bob" (e.g., the call signaling to remove
2353 "Bob" from the conference is instigated through the Focus). The
2354 conference server updates the data in the conference object, thus
2355 removing "Bob" from the "users" list. After updating the data,
2356 the conference server sends a userResponse message to "Alice".
2357 Depending upon the policies, other participants (e.g. "Claire")
2358 may be notified of the removal of "Bob" from the conference via
2359 the Conference Notification Service.
2361 (CCMP Messaging details not available yet).
2363 Figure 27: Removing a Participant Messaging Details
2365 7.2. Deleting a Conference
2367 Details to be added.
2369 (Figure not available yet).
2371 Figure 28: Deleting a conference
2373 (Text description to be added).
2375 (CCMP Messaging details not available yet).
2377 Figure 29: Deleting a Conference Messaging Details
2379 8. Additional Conference Scenarios and Examples
2381 The following are additional scenarios making use of the XCON
2382 framework and associated protocols. In some cases, these examples
2383 make use of some of the building block scenarios detailed in the
2384 previous example sections, in which case the appropriate scenario is
2385 referenced rather than duplicating details. In addition, in cases
2386 where the scenarios make use of other protocols, as in the previous
2387 section, the appropriate reference in the form of a title to the
2388 specific flow in the appropriate protocol document is included.
2390 8.1. Chat
2392 The chat functionality described in this section of the document
2393 allows clients that use the XCON framework and protocols for other
2394 media types (e.g. voice/video) to utilize the same conference control
2395 mechanisms and conferencing system to establish, update and delete a
2396 conference instance associated with an Instant Messaging (IM) chat
2397 session, independent of the IM chat protocol. In some cases(e.g.,
2398 Message Session Relay Protocol (MSRP) chat), this would provide
2399 additional capabilities, such as sidebars. This approach also allows
2400 the conferencing system to provide a natural interworking point for
2401 various IM protocols, the details of the interworking are outside the
2402 scope of this document.
2404 An IM client wishing to join a conference uses standardized
2405 centralized conferencing mechanisms for creating and joining a
2406 conference, as identified in the previous sections. The request to
2407 send an IM to an IM media session is specific to the IM protocol
2408 (e.g., MSRP SEND), just as there is specific media control messaging
2409 for other types of sessions. An IM client connecting to a
2410 conferencing system has a 1:1 relationship with the IM media
2411 signaling entity in the conferencing system. This relationship is
2412 referred to as an IM session. Further details of the correlation of
2413 the IM session identifiers with the XCON session identifiers is
2414 provided in [I-D.boulton-xcon-session-chat]. The IM media signaling
2415 entity is responsible for distribution of all the messages to the
2416 other participants.
2418 As with the other example conferences created, each IM session is
2419 logically associated with a specific conference. The conference
2420 itself has a specific identifier in the form of the XCON-URI, which
2421 is passed in the "confObjID" element in the CCMP messages. This
2422 provides the relevant association between IM session and a
2423 centralized conference.
2425 An IM client wishing to delete a chat room uses standardized
2426 mechanisms for deleting a conference instance, such as those detailed
2427 in Section 7.2.
2429 8.1.1. Basic Chat Operations
2431 This section provides details of the realization of the Multi-party
2432 IM (chat) within the context of the centralized conferencing
2433 framework. A brief discussion and diagrams are provided for
2434 creating, joining, and deleting a chat based conference. The
2435 discovery of chat rooms available on a specific conferencing system
2436 is inherent in the blueprint capability provided by the conferencing
2437 system. The objective of this section is to further illustrate the
2438 model, mechanisms and protocols presented in the previous sections
2439 and also serves to validate that the model, mechanisms and protocols
2440 are sufficient to support IM chat.
2442 It should be noted that not all entities impacted by the request are
2443 shown in the diagram (e.g., Focus), but rather the emphasis is on the
2444 new entities introduced by this centralized conferencing framework.
2446 8.1.1.1. Creating a Chat Room
2448 There are different ways to create a conference. A participant can
2449 create a conference using call signaling means only, such as SIP, as
2450 detailed in [RFC4579]. For a conferencing client to have more
2451 flexibility in defining the charaterisitics and capabilities of a
2452 chat based conference, a conferencing client would implement a
2453 conference control protocol client. By using a conference control
2454 protocol, the client can determine the capabilities of a conferencing
2455 system and its various resources.
2457 Figure 30 provides an example of one client "Alice" determining the
2458 conference blueprints available to support various types of chat
2459 rooms for a particular conferencing system and creating a chat based
2460 conference using the desired blueprint.
2462 Details to be added.
2464 Figure 30: Client Creation of Chat room
2466 Upon receipt of the Conference Control Protocol request for
2467 blueprints associated with chat rooms, the conferencing system would
2468 first authenticate "Alice" (and allocate a conference user
2469 identifier, if necessary) and then ensure that "Alice" has the
2470 appropriate authority based on system policies to receive any chat
2471 room based blueprints supported by that system. Any blueprints that
2472 "Alice" is authorized to use are returned in a response, along with
2473 the conference user ID.
2475 Upon receipt of the Conference Control Protocol response containing
2476 the blueprints, "Alice" determines which blueprint to use for the
2477 conference to be created. "Alice" creates a conference object based
2478 on the blueprint (i.e., clones) and modifies applicable fields, such
2479 as membership list, topic details, and start time. "Alice" then
2480 sends a request to the conferencing system to create a conference
2481 reservation based upon the updated blueprint.
2483 Upon receipt of the Conference Control Protocol request to "create" a
2484 conference based upon the blueprint in the request, the conferencing
2485 system ensures that the blueprint received is a valid blueprint (i.e.
2486 the values of the various field are within range). The conferencing
2487 system determines the appropriate read/write access of any users to
2488 be added to a conference based on this blueprint (using membership,
2489 roles, etc.). The conferencing system uses the received blueprint to
2490 clone a conference reservation. The conferencing system also
2491 reserves or allocates a conference ID to be used for any subsequent
2492 protocol requests from any of the members of the conference. The
2493 conferencing system maintains the mapping between this conference ID
2494 and the conference object ID associated with the reservation through
2495 the conference instance.
2497 Upon receipt of the conference control protocol response to reserve
2498 the conference, "Alice" now creates an active chat room using that
2499 reservation. "Alice" provides the conference information, including
2500 the necessary conference ID, to desired participants to allow them to
2501 join the chat room. "Alice" may also add other users to the chat
2502 room. When the first participant, including "Alice", requests to be
2503 added to the conference, an active conference and focus are created.
2504 The focus is associated with the conference ID received in the
2505 request.
2507 (CCMP Messaging details not available yet.
2508 Plan is to reference detailed flows in
2509 previous sections
2510 in the example.)
2512 Figure 31: Chatroom Creation Messaging Details
2514 8.1.1.2. Joining a Chat Room
2516 A participant can join and leave the conference using call signaling
2517 means only, such as SIP. However, in order to perform richer
2518 conference control a user client can implement a conference control
2519 protocol client. By using a conference control protocol, the client
2520 can affect its own state and the state of other participants,
2521 depending upon policies, which may indirectly affect the state of any
2522 of the conference participants.
2524 In the example in section Section 8.1.1.1, "Alice" has reserved a
2525 chat room . "Alice" has also already joined the conference and made
2526 the chat room active. "Alice" can either add additional participants
2527 to the chat room or provide the conference information, including the
2528 necessary conference ID, to desired participants and allow them to
2529 request to join themselves. Any participants that have the authority
2530 to manipulate the conference would receive the conference object
2531 identifier of the active conference object in the response to their
2532 request to join.
2534 Figure 32 provides an example of "Bob" joining the chat room using
2535 the conference ID provided by "Alice" (e.g., in an IM).
2537 Details to be added.
2539 Figure 32: Joining a chat room
2541 Upon receipt of the Conference Control Protocol request to "add" a
2542 party ("Bob") in the specific conference as identified by the
2543 conference object ID, the conferencing system must determine whether
2544 "Bob" is already a user of this conferencing system or whether he is
2545 a new user. If "Bob" is a new user for this conferencing system, a
2546 Conference User Identifier is created for Bob. The conferencing
2547 system must also ensure that "Bob" has the appropriate authority
2548 based on the policies associated with that specific conference object
2549 to perform the operation.
2551 Once "Bob" has been successfully added to the chat room, a response
2552 is sent to "Bob". Depending upon the policies, other participants
2553 (including "Bob") may be notified of the addition of "Bob" to the
2554 conference via the Conference Notification Service.
2556 (CCMP Messaging details not available yet.
2557 Plan is to reference detailed flows in
2558 previous sections as appropriate
2559 in the example.)
2561 Figure 33: Chatroom Join Messaging Details
2563 8.1.1.3. Deleting a Chat Room
2565 Depending upon the conferencing system policies and policies specific
2566 to the chat room, the creator of the chat would typically be the
2567 participant authorized to delete the chat room.
2569 In the example in section Section 8.1.1.1, "Alice" has created a chat
2570 room and provided the conference information, including the necessary
2571 conference ID, to desired participants and allow them to request to
2572 join themselves. "Bob" and others are participants in the chat.
2573 Figure 34 provides an example of "Alice" later deleting this same
2574 chat room.
2576 Details to be added.
2578 Figure 34: Deleting a chat room
2580 Upon receipt of the Conference Control Protocol request to "delete"
2581 the specific chat room as identified by the conference object ID, the
2582 conferencing system must determine whether "Alice" has the authority
2583 to delete this conference. Since "Alice" is the creator of the
2584 conference, the "delete" operation is performed, with the appropriate
2585 signaling sent to the participants, including a response to "Alice"
2586 indicating that the chat room has been deleted.
2588 One step in the deletion of the chat room may include notifitying the
2589 participants (including "Bob") that they have been removed via the
2590 Conference Notification Service.
2592 (CCMP Messaging details not available yet.
2593 Plan is to reference detailed flows in
2594 previous sections .)
2596 Figure 35: Chatroom Deletion Messaging Details
2598 8.1.2. Advanced Operations
2600 This section provides details of the realization of advanced chat
2601 features, such as sidebars and private messages, within the context
2602 of the centralized conferencing framework. As with Section 8.1.1,
2603 the objective of this section is to further illustrate the model,
2604 mechanisms and protocols presented in the previous sections and also
2605 serves to validate that the model, mechanisms and protocols are
2606 sufficient to support advance IM chat features.
2608 8.1.2.1. Text Sidebar
2610 The concept of a 'sidebar' in conferencing system is fully described
2611 in the Sidebar section and related subsections within the
2612 Conferencing Scenarios Realization section of the centralized
2613 conferencing framework document [RFC5239]. The creation,
2614 manipulation and deletion of sidebars for chat rooms follows the same
2615 principles.
2617 A conference object representing a sidebar is created by cloning the
2618 parent associated with the existing conference and updating any
2619 information specific to the sidebar. A sidebar conference object is
2620 implicitly linked to the parent conference object (i.e. it is not an
2621 independent object) and is associated with the parent conference
2622 object identifier. A conferencing system manages and enforces the
2623 parent and appropriate localized restrictions on the sidebar
2624 conference object (e.g., no members from outside the parent
2625 conference instance can join, sidebar conference can not exist if
2626 parent conference is terminated, etc.).
2628 Figure 36 provides an example of one client "Alice" involved in
2629 active chat room with "Bob" and "Carol". "Alice" wants to create a
2630 sidebar to have a side discussion with "Bob" while still receiving
2631 the session based messaging associated with the main chat room.
2632 Whether the text is interleaved with the main chat or whether a
2633 separate window is created for the sidebar is implementation
2634 specific. "Alice" initiates the sidebar by sending a request to the
2635 conferencing system to create a conference chat reservation based
2636 upon the active chat conference object. "Alice" and "Bob" would
2637 remain on the roster of the main conference, such that other
2638 participants could be aware of their participation in the main
2639 conference, while the text sidebar conference is occurring.
2641 Details to be added.
2643 Figure 36: Client Creation of a Sidebar Conference
2645 Upon receipt of the Conference Control Protocol request to "reserve"
2646 a new sidebar chat conference, based upon the active chat conference
2647 received in the request, the conferencing system uses the received
2648 active chat conference to clone a conference chat reservation for the
2649 sidebar. As discussed previously, the sidebar reservation is NOT
2650 independent of the active conference (i.e., parent). The
2651 conferencing system also reserves or allocates a conference ID to be
2652 used for any subsequent protocol requests from any of the members of
2653 the conference. The conferencing system maintains the mapping
2654 between this conference ID and the conference object ID associated
2655 with the sidebar reservation through the conference instance.
2657 Upon receipt of the conference control protocol response to reserve
2658 the conference, "Alice" can now create an active chat conference
2659 using that reservation or create additional reservations based upon
2660 the existing reservations. In this example, "Alice" wants only "Bob"
2661 to be involved in the sidebar, thus she manipulates the membership.
2662 "Alice" also only wants the text from the original conference, but
2663 wants the text within the sidebar to be restricted to the
2664 participants in the sidebar. "Alice" sends a conference control
2665 protocol request to update the information in the reservation and to
2666 create an active conference.
2668 Upon receipt of the conference control protocol request to update the
2669 reservation and to create an active chat conference for the sidebar,
2670 as identified by the conference object ID, the conferencing system
2671 ensures that "Alice" has the appropriate authority based on the
2672 policies associated with that specific conference object to perform
2673 the operation. The conferencing system must also validate the
2674 updated information in the reservation, ensuring that a member like
2675 "Bob" is already a user of this conferencing system.
2677 Depending upon the policies, the initiator of the request (i.e.,
2678 "Alice") and the participants in the sidebar (i.e., "Bob") may be
2679 notified of his addition to the sidebar via the conference
2680 notification service.
2682 Details to be added.
2684 Figure 37: Chatroom Sidebar Messaging Details
2686 8.1.2.2. Private Message
2688 The case of private messages can be handled as a sidebar with just
2689 two participants, identical to the example in section
2690 Section 8.1.2.1. The other context, referred to as whisper, in this
2691 document refers to situations involving one time media targetted to
2692 specific user(s). An example of a whisper would be a text message
2693 injected only to the conference chair or to a new participant joining
2694 a conference.
2696 Figure 38 provides an example of one user "Alice" who's chairing a
2697 fixed length conference with "Bob" and "Carol". The configuration is
2698 such that only the chair is providing a warning when there is only 10
2699 minutes left in the conference. At that time, "Alice" is moved into
2700 a sidebar created by the conferencing system and only "Alice"
2701 receives that text message announcing the 10 minute warning.
2703 Details to be added.
2705 Figure 38: Whisper
2707 When the conferencing system determines that there is only 10 minutes
2708 left in the conference which "Alice" is chairing, rather than
2709 creating a reservation as was done for the sidebar in
2710 Section 8.1.2.1, the conferencing system directly creates an active
2711 chat sidebar conference, based on the active chat conference
2712 associated with "Alice". As discussed previously, the sidebar
2713 conference is NOT independent of the active conference (i.e.,
2714 parent). The conferencing system also allocates a conference ID to
2715 be used for any subsequent manipulations of the sidebar chat
2716 conference. The conferencing system maintains the mapping between
2717 this conference ID and the conference object ID associated with the
2718 active sidebar conference through the conference instance.
2720 Immediately upon creation of the active chat sidebar conference, the
2721 text announcement is provided to "Alice". Depending upon the
2722 policies, Alice may be notified of her addition to the sidebar via
2723 the conference notification service. "Alice" continues to receive
2724 the text messages from the main conference.
2726 Upon delivery of the text announcement, "Alice" is removed from the
2727 sidebar and the sidebar conference is deleted. Depending upon the
2728 policies, "Alice" may be notified of her removal from the sidebar via
2729 the conference notification service.
2731 Details to be added.
2733 Figure 39: Chatroom Sidebar Messaging Details
2735 9. IANA Considerations
2737 This document has no IANA considerations.
2739 10. Security Considerations
2741 The security considerations applicable to the implementation of these
2742 call flows is documented in the XCON Framework, with additional
2743 security considerations documented in the CCMP document. Where
2744 applicable, statements with regards to the necessary security are
2745 discussed in particular flows, however, since this is only an
2746 informational document, readers are strongly recommended to carefully
2747 consider the security considerations defined in the XCON Framework
2748 and the CCMP document.
2750 11. Change Summary
2752 NOTE TO THE RFC-Editor: Please remove this section prior to
2753 publication as an RFC.
2755 The following are the major changes between the individual 01 version
2756 to the WG 00:
2758 o Updates to reflect most recent version of CCMP, including
2759 parameter names, etc.
2761 o Added protocol details to many of the examples.
2763 o Editorial: Simplifying intro, terms, etc.
2765 The following are the major changes between the 00 and the 01
2766 versions of the draft:
2768 o Updates to reflect change of CCMP to HTTP transport model.
2770 12. Acknowledgements
2772 The detailed content for this document is derived from the prototype
2773 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
2774 their colleagues at the University of Napoli.
2776 13. References
2778 13.1. Normative References
2780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2781 Requirement Levels", BCP 14, RFC 2119, March 1997.
2783 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
2784 Centralized Conferencing", RFC 5239, June 2008.
2786 [I-D.ietf-xcon-ccmp]
2787 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
2788 "Centralized Conferencing Manipulation Protocol",
2789 draft-ietf-xcon-ccmp-02 (work in progress), March 2009.
2791 13.2. Informative References
2793 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2794 A., Peterson, J., Sparks, R., Handley, M., and E.
2795 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2796 June 2002.
2798 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
2799 (SIP) Call Control - Conferencing for User Agents",
2800 BCP 119, RFC 4579, August 2006.
2802 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
2803 RFC 4597, August 2006.
2805 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
2806 Control Protocol (BFCP)", RFC 4582, November 2006.
2808 [I-D.ietf-xcon-event-package]
2809 Camarillo, G., Srinivasan, S., Even, R., and J.
2810 Urpalainen, "Conference Event Package Data Format
2811 Extension for Centralized Conferencing (XCON)",
2812 draft-ietf-xcon-event-package-01 (work in progress),
2813 September 2008.
2815 [I-D.ietf-xcon-common-data-model]
2816 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
2817 "Conference Information Data Model for Centralized
2818 Conferencing (XCON)", draft-ietf-xcon-common-data-model-13
2819 (work in progress), April 2009.
2821 [I-D.ietf-mediactrl-call-flows]
2822 Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
2823 "Media Control Channel Framework (CFW) Call Flow
2824 Examples", draft-ietf-mediactrl-call-flows-00 (work in
2825 progress), March 2009.
2827 [RFC5567] Melanchuk, T., "An Architectural Framework for Media
2828 Server Control", RFC 5567, June 2009.
2830 [I-D.ietf-mediactrl-mixer-control-package]
2831 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
2832 Control Package for the Media Control Channel Framework",
2833 draft-ietf-mediactrl-mixer-control-package-07 (work in
2834 progress), May 2009.
2836 [I-D.boulton-xcon-session-chat]
2837 Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
2838 a Centralized Conferencing (XCON) System",
2839 draft-boulton-xcon-session-chat-04 (work in progress),
2840 July 2009.
2842 Authors' Addresses
2844 Mary Barnes
2845 Nortel
2846 2201 Lakeside Blvd
2847 Richardson, TX
2849 Email: mary.barnes@nortel.com
2851 Chris Boulton
2852 NS-Technologies
2854 Email: chris@ns-technologies.com
2855 Lorenzo Miniero
2856 Meetecho
2857 Via Carlo Poerio 89/a
2858 Napoli 80121
2859 Italy
2861 Email: lminiero@meetecho.com
2863 Roberta Presta
2864 University of Napoli
2865 Via Claudio 21
2866 Napoli 80125
2867 Italy
2869 Email: roberta.presta@unina.it
2871 Simon Pietro Romano
2872 University of Napoli
2873 Via Claudio 21
2874 Napoli 80125
2875 Italy
2877 Email: spromano@unina.it