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