idnits 2.17.1
draft-ietf-xcon-examples-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 14, 2011) is 4813 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-15) exists of
draft-ietf-xcon-ccmp-11
-- 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-23
== Outdated reference: A later version (-13) exists of
draft-ietf-mediactrl-call-flows-05
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XCON Working Group M. Barnes
3 Internet-Draft Polycom
4 Intended status: Informational L. Miniero
5 Expires: August 18, 2011 Meetecho
6 R. Presta
7 S P. Romano
8 University of Napoli
9 February 14, 2011
11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
12 draft-ietf-xcon-examples-08
14 Abstract
16 This document provides detailed call flows for the scenarios
17 documented in the Centralized Conferencing (XCON) Framework and the
18 XCON Scenarios. The call flows document the use of the interface
19 between a conference control client and a conference control server
20 using the Centralized Conferencing Manipulation Protocol (CCMP). The
21 objective is to provide a base reference for both protocol
22 researchers and developers.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on August 18, 2011.
41 Copyright Notice
43 Copyright (c) 2011 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4
62 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5
63 4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6
64 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10
65 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 11
66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 12
67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 16
68 5.3. Conference Creation using User-Provided Conference
69 Information . . . . . . . . . . . . . . . . . . . . . . . 23
70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 28
71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 32
72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 32
73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 36
74 6.3. Conference Announcements and Recordings . . . . . . . . . 40
75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 44
76 6.5. Entering a password-protected conference . . . . . . . . . 44
77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 46
78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 47
79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 56
80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63
81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67
82 8. Removing Participants and Deleting Conferences . . . . . . . . 74
83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74
84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77
85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
87 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79
88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81
89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
91 13.2. Informative References . . . . . . . . . . . . . . . . . . 81
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
94 1. Introduction
96 This document provides detailed call flows for the scenarios
97 documented in the Framework for Centralized Conferencing (XCON
98 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON
99 scenarios describe a broad range of use cases taking advantage of the
100 advanced conferencing capabilities provided by a system realization
101 of the XCON framework. The call flows document the use of the
102 interface between a conference control client and a conference
103 control server using the Centralized Conferencing Manipulation
104 Protocol (CCMP)[I-D.ietf-xcon-ccmp].
106 Due to the broad range of functionality provided by the XCON
107 Framework and the flexibility of the CCMP messaging, these call flows
108 should not be considered inclusive of all the functionality that can
109 provided by the XCON Framework and protocol implementations. These
110 flows represent a sample to provide an overview of the feature rich
111 capabilities of the XCON framework and CCMP messaging for protocol
112 developers, software developers and researchers.
114 2. Terminology
116 This document uses the same terminology as found in the Media Control
117 Architectural Framework [RFC5567] and Media Control Channel Framework
118 Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the
119 following terms and abbreviations used in the call flows. Also, note
120 that the term "call flows" is used in a very generic sense in this
121 document since the media is not limited to voice. The calls
122 supported by the XCON framework and CCMP can consist of media such as
123 text, voice and video, including multiple media types in a single
124 active conference.
126 Conference and Media Control Client (CMCC): as defined in the XCON
127 Framework. In the flows in this document, the CMCC is logically
128 equivalent to the use of UAC as the client notation in the media
129 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC
130 differs from a generic Media Client in being an XCON-aware entity,
131 thus being able to also issue CCMP requests.
133 Conferencing Server (ConfS): In this document, the term
134 "Conferencing Server" is used interchangeably with the term
135 "Application Server" (AS) as used in the Media Control
136 Architectural Framework [RFC5567]. A Conferencing Server is
137 intended to be able to act as a Conference Control Server, as
138 defined in the XCON framework, i.e. it is able to handle CCMP
139 requests and issue CCMP responses.
141 Media Server (MS): as defined in the Media Control Architectural
142 Framework [RFC5567].
144 3. Overview
146 This document provides a sampling of detailed call flows that can be
147 implemented based on a system realization of the XCON framework
148 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is
149 intended to be a simple guide for the use of the Conference Control
150 Protocol between the Conferencing Server and the Conference Control
151 Client. The objective is to provide an informational base reference
152 for protocol developers, software developers and researchers.
154 This document focuses on the interaction between the Conference (and
155 Media) Control Client and the Conferencing System, specifically the
156 Conferencing Server. The scenarios are based on those described in
157 the XCON framework, many of which are based on the advanced
158 conferencing capabilities described in the XCON scenarios.
159 Additional scenarios have been added to provide examples of other
160 real life scenarios that are anticipated to be supported by the
161 framework. With the exception of an initial example with media
162 control messaging, the examples do not include the details for the
163 media control [I-D.ietf-mediactrl-mixer-control-package], call
164 signaling or binary floor control [RFC4582] protocols. This document
165 references the scenarios in the Media Control call flows
166 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing
167 [RFC4579] and binary floor control protocol documents.
169 The rest of this document is organized as follows. Section 4
170 presents an overview on CCMP, together with some implementation-
171 related details and related matters like HTTP transport and
172 notifications. Section 5 presents the reader with examples showing
173 the different approaches CCMP provides to create a new conference.
174 Section 6 more generally addresses the different user-related
175 manipulations that can be achieved by means of CCMP, by presenting a
176 number of interesting scenarios. Section 7 addresses the several
177 scenarios that may involve the use of sidebars. Section 8 shows how
178 CCMP can be used to remove conferences and users from the system.
179 Finally, Section 10 provides a few details for what concerns the
180 Security Considerations when it comes to implementing CCMP.
182 4. Working with CCMP
184 This section provides a brief introduction as to how the Centralized
185 Conferencing Manipulation Protocol (CCMP) [I-D.ietf-xcon-ccmp] works
186 and how it can be transported across a network. A typical CCMP
187 interaction focusing on relevant aspects of the client-server
188 communication is described. Please note that this section assumes
189 the reader has an understanding of and has read the CCMP document.
190 This section is intended to help the reader understand the actual
191 protocol interactions.
193 First a description of the protocol itself is provided Section 4.1,
194 including some implementation considerations. In Section 4.2, an
195 effective CCMP interaction is presented by exploiting HTTP as a
196 transport. Finally, notifications are described in Section 4.3.
198 The document then presents and describes some actual flows in detail
199 in the sections to follow.
201 4.1. CCMP and the Data Model
203 CCMP is an XML-based protocol. It has been designed as a request/
204 response protocol. It is completely stateless, which means
205 implementations can safely handle transactions independently from
206 each other.
208 The protocol allows for the manipulation of conference objects and
209 related users. This manipulation allows a Conferencing Client
210 (briefly CMCC in all the following sections) to create, update and
211 remove basically everything that is related to the objects handled by
212 a conferencing system. This is reflected in the allowed operations
213 (retrieve, create, update, delete) and the specified request types
214 (ranging from the manipulation of blueprints and conferences to users
215 and sidebars). For instance, CCMP provides ways to:
217 o retrieve the list of registered and/or active conferences in the
218 system;
220 o create new conferences by exploiting to several different
221 approaches;
223 o add/remove users to/from a conference;
225 o update a conference with respect to all of its aspects;
227 and so on.
229 While CCMP acts as the means to manipulate conference objects, CCMP
230 does not define these conference objects. A separate document
231 specifies how a conference object and all its components have to be
232 constructed: the Conference Information Data Model for Centralized
233 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP,
234 depending upon the request type and the related operation, carries
235 pieces of conference objects (or any object as a whole) according to
236 the aforementioned specification. This means that any implementation
237 aiming at being compliant with CCMP has to make sure that the
238 transported objects are completely compliant with the Data Model
239 specification and coherent with the constraints defined therein. To
240 make this clearer, there are elements that are mandatory in a
241 conference object: issuing a syntactically correct CCMP request that
242 carries a wrong conference object is doomed to result in a failure.
243 For this reason, it is suggested that the interested implementors
244 take special care in carefully checking the Data Model handlers as
245 well in order to avoid potential mistakes.
247 However, there are cases when a mandatory element in the Data Model
248 cannot be assigned in a conference object by a CCMP user. For
249 example, a CMCC may be requesting the direct creation of a new
250 conference: in this case, a conference object assumes an 'entity'
251 element uniquely identifying the conference to be in place. Thus,
252 the CMCC has no way to know a priori what the entity will be, since
253 it is generated by the ConfS after the request. For scenarios like
254 this one, the CCMP specification describes the use of a dedicated
255 placeholder wildcard (i.e., AUTO_GENERATE_X, where X is an integer)
256 to make the conference object compliant with the Data Model: the
257 wildcard would then be replaced by the ConfS with the right value.
259 4.2. Using HTTP as a transport
261 CCMP requests and responses can be transported from a client to a
262 server and viceversa in several ways, since the protocol
263 specification is agnostic with respect to the transport. However,
264 [I-D.ietf-xcon-ccmp] requires that implementations support HTTP. The
265 following provides a brief explanation, from a more practical point
266 of view, of how HTTP might be exploited to carry CCMP messages. In
267 this document, however, all the call flows presented just show the
268 CCMP interactions, without describing how the messages are
269 transported.
271 When HTTP is used as a transport, a CMCC sends his request as part of
272 an HTTP POST message, and the ConfS would reply with an HTTP 200
273 message. In both cases, the HTTP messages would have the CCMP
274 messages as payload, which would be reflected in the Content-Type
275 message (application/ccmp+xml). Figure 1 presents a ladder diagram
276 of such interaction, which is followed by a dump of the exchanged
277 HTTP messages for further analysis:
279 CMCC ConfS
280 | |
281 | 1. HTTP POST (CCMP request) |
282 |--------------------------------------------->|
283 | |
284 | |--+ Parse request,
285 | | | update object
286 | |<-+ and reply
287 | |
288 | 2. 200 OK (CCMP response) |
289 |<---------------------------------------------|
290 | |
291 |--+ Parse response and |
292 | | update local copy |
293 |<-+ of conference object |
294 | |
295 . .
296 . .
298 Figure 1: CCMP on HTTP
300 Per the protocol dump in the following lines, the CMCC has issued a
301 CCMP request (a blueprintRequest with a 'retrieve' operation) towards
302 the Conferencing Server (ConfS). The request has been carried as
303 payload of an HTTP POST (message 1.) towards a previously known
304 location. The mandatory 'Host' header has been specified, and the
305 'Content-Type' header has been correctly set as well (application/
306 ccmp+xml).
308 The ConfS, in turn, has handled the request and replied accordingly.
309 The response (a blueprintResponse with a successful response code)
310 has been carried as payload of an HTTP 200 OK (message 2.). As
311 before, the 'Content-Type' header has been correctly set
312 (application/ccmp+xml).
314 1. CMCC -> ConfS (HTTP POST, CCMP request)
315 ------------------------------------------
316 POST /Xcon/Ccmp HTTP/1.1
317 Content-Length: 657
318 Content-Type: application/ccmp+xml
319 Host: example.com:8080
320 Connection: Keep-Alive
321 User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
323
324
328
330 xcon-userid:Alice@example.com
331 xcon:AudioRoom@example.com
332 retrieve
333
334
335
337 2. CMCC <- ConfS (200 to POST, CCMP response)
338 ---------------------------------------------
339 HTTP/1.1 200 OK
340 X-Powered-By: Servlet/2.5
341 Server: Sun GlassFish Communications Server 1.5
342 Content-Type: application/ccmp+xml;charset=ISO-8859-1
343 Content-Length: 1652
344 Date: Thu, 04 Feb 2010 14:47:56 GMT
346
347
351
353 xcon-userid:Alice@example.com
354 xcon:AudioRoom@example.com
355 retrieve
356 200
357 success
358
359
360
361 AudioRoom
362 2
363
364
365 audio
366
367
368
369
370 allow
371
372
373 confirm
374
375
376
377
378
379
380
381
382
384 For completeness, the following provides some details of the CCMP
385 interaction. Despite the simplicity of the request, this flow
386 provides some relevant information on how CCMP messages are built.
387 Specifically, both the request and the response share a subset of the
388 message:
390 o confUserID: this element, provided by the CMCC, refers to the
391 requester by means of his XCON-USERID; except in a few scenarios
392 (presented in the following sections) this element must always
393 contain a valid value;
395 o confObjID: this element refers to the target conference object,
396 according to the request in place;
398 o operation: this element specifies the operation the CMCC wants to
399 perform according to the specific request type.
401 Besides those elements, the CMCC (let's say Alice, whose 'confUserID'
402 is 'xcon-userid:Alice@example.com') has also provided an additional
403 element, 'blueprintRequest'. The name of that element varies
404 according to the request type the CMCC is interested in. In this
405 specific scenario, the CMCC was interested in acquiring details
406 concerning a specific blueprint (identified by its XCON-URI
407 'xcon:AudioRoom@example.com', as reflected in the provided
408 'confObjID' target element), and so the request consisted in an empty
409 'blueprintRequest' element. It will be clearer in the following
410 sections that different request types may require different elements
411 and, as a consequence, different content.
413 Considering the request was a 'blueprintRequest', the ConfS has
414 replied with a 'blueprintResponse' element. This element includes a
415 complete dump of the conference object (compliant with the Data
416 Model) describing the requested blueprint.
418 Without providing additional details of this interaction, it is worth
419 noting that this was the example of the simplest CCMP communication
420 that could take place between a CMCC and a ConfS, a blueprintRequest:
421 this scenario will be described in more detail in Section 5.2.
423 4.3. Conference Notifications
425 The XCON framework [RFC5239] identifies several different possible
426 protocol interactions between a conferencing server and a
427 conferencing client. One of those interactions is generically called
428 "Notification Protocol" providing a mechanism for all clients
429 interested in being informed by the server whenever something
430 relevant happens in a conference. When SIP is used as the call
431 signaling protocol in a CCMP implementation, the XCON Event Package
432 [I-D.ietf-xcon-event-package], which extends the SIP Event Package
433 for Conference State [RFC4575] must be supported. A SIP client uses
434 the SIP SUBSCRIBE message for the XCON Event Package to subscribe to
435 notifications related to a specific conference. A SIP client would
436 receive notifications describing all the changes to the document via
437 SIP NOTIFY message. An example ladder diagram is presented in
438 Figure 2: in this figure, we assume a CMCC has updated a conference
439 object, and a previously subscribed SIP client is notified of the
440 update.
442 CMCC ConfS UAC
443 | | |
444 | | 1. SIP SUBSCRIBE |
445 | |<--------------------------|
446 | Handle +--| |
447 | new | | |
448 | subscription +->| 2. SIP 200 OK |
449 | |-------------------------->|
450 | | |
451 . . .
452 . . .
453 | | |
454 | 3. CCMP (add user) | |
455 |---------------------->| |
456 | |--+ Add user |
457 | | | to conf. |
458 | |<-+ object |
459 | 4. CCMP (success) | |
460 |<----------------------| |
461 | | 5. SIP NOTIFY (changes) |
462 | |-------------------------->|
463 | | 6. SIP 200 OK |
464 | |<--------------------------|
465 | | |
466 . . .
467 . . .
469 Figure 2: XCON Event Package: SIP notifications
471 The detailed flows in this document generically present a
472 notification, when appropriate, but do not include the SIP messaging
473 details.
475 5. Conference Creation
477 This section provides details associated with the various ways in
478 which a conference can be created using CCMP and the XCON framework
479 constructs. As previously mentioned, the details of the media
480 control, call signaling and floor control protocols, where
481 applicable, are annotated in the flows without showing all the
482 details. This also applies to CCMP, whose flows are related to the
483 protocol alone, hiding any detail concerning the transport that may
484 have been used (e.g. HTTP). However, for clarification purposes,
485 the first example Section 5.1 provides the details of the media
486 control messaging with the standard annotation used throughout the
487 remainder of this document. In subsequent flows, only this
488 annotation (identified by lower case letters) is included and the
489 reader is encouraged to refer to the call flows in the relevant
490 documents for details about the other protocols. The annotations for
491 the call signaling are on the left side of the conferencing server
492 vertical bar and those for the media control messaging are on the
493 right side.
495 5.1. Basic Conference Creation
497 The simplest manner in which a conference can be created is
498 accomplished by the client sending a "confRequest" message with the
499 "create" operation as the only parameter to the conference server,
500 together with the "confUserID" associated with the requesting client
501 itself. This results in the creation of a default conference, with
502 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID
503 in the form of the "confUserID" parameter (the same one already
504 present in the request) and the data for the conference object in the
505 "confInfo" parameter all returned in the "confResponse" message.
506 This example also adds the issuing user to the conference upon
507 creation with the "method" attribute in the element of
508 set to "dial out".
510 The specific data for the conference object is returned in the
511 "confResponse" message in the "confInfo" parameter. This allows the
512 client (with the appropriate authorization) to manipulate these data
513 and add additional participants to the conference, as well as change
514 the data during the conference. In addition, the client may
515 distribute the conferencing information to other participants
516 allowing them to join, the details of which are provided in
517 additional flows. Please notice that, according to the CCMP
518 specification, the return of the new conference data in the
519 "confInfo" parameter is not mandatory: if the "confInfo" parameter of
520 the successful confResponse/create is not included in the response, a
521 subsequent confRequest/retrieve of the returned "confObjID" can be
522 triggered to provide the requesting client with the detailed
523 conference description.
525 Clients that are not XCON-aware can join the conference using a
526 specific signaling interface such as SIP [RFC3261] (using the
527 signaling interface to the conference focus as described in
528 [RFC4579]), or other supported signaling protocols, being XCON
529 agnostic with respect to them. However, these details are not shown
530 in the message flows. The message flows in this document identify
531 the point in the message flows at which this signaling occurs via the
532 lower case letter items (i.e., (a)...(x)) along with the appropriate
533 text for the processing done by the conferencing server.
535 As previously described, this example also shows how the conferencing
536 system may make use of other standard protocol components for
537 complete functionality. An example of that is the MEDIACTRL
538 specification, which allows the conferencing system to configure
539 conference mixes, IVR dialogs and all sort of media-related
540 interactions an application like this may need. In order to provide
541 the reader with some insight on these interactions, the conferencing
542 system in this example also configures and starts a mixer via
543 MEDIACTRL as soon as the conference is created (transactions A1 and
544 A2), and attaches clients to it when necessary (e.g. when CMCC1 joins
545 the conference by means of SIP signaling, its media channels are
546 attached to the Media Server using MEDIACTRL in B1/B2). Note, that
547 the MEDIACTRL interfaces are NOT shown in the remaining call flows in
548 this document, but rather follow the same annotation as with the SIP
549 signaling such that (b) correlates with the A1 and A2 transactions
550 and (d) correlates with the B1 and B2 transactions.
552 CMCC1 CMCC2 CMCCx ConfS MS
553 | | | | |
554 |(1)confRequest(confUserID, create) | |
555 |-------------------------------------->| |
556 | | (a)Create +---| |
557 | | |Conf | | |
558 | | |Object | | |
559 | | |& IDs +-->| |
560 | | | | A1. CONTROL |
561 | | | |+++++++++++>>|
562 | | | |(create conf)|--+ (b)
563 | | | | | | create
564 | | | | | | conf and
565 | | | | A2. 200 OK |<-+ its ID
566 | | | |<<+++++++++++|
567 | | | |(confid=Y) |
568 |(2)confResponse(confUserID,confObjID, | |
569 | create, 200, success, | |
570 | version, confInfo) | |
571 |<--------------------------------------| |
572 | | | | |
573 | | (c) Focus +---| |
574 | | sets up | | |
575 | | signaling | | |
576 | | to CMCC1 +-->| |
577 | | | | |
578 | | | | B1. CONTROL |
579 | | | |+++++++++++>>|
580 | | | | (join CMCC1 |
581 | | | | <->confY) |
582 | | | | |
583 | | | | |--+(d) join
584 | | | | | | CMCC1 &
585 | | | | B2.200 OK |<-+ conf Y
586 | | | |<<+++++++++++|
587 | | | | |
588 |<<#################################################>>|
589 | Now the CMCC1 is mixed in the conference |
590 |<<#################################################>>|
591 | | | | |
592 |******CMCC1 may then manipulate conference data *****|
593 |****** and add addt'l users, etc. | *****|
594 ' ' ' ' '
595 ' ' ' ' '
596 ' ' ' ' '
597 Figure 3: Create Basic Conference - Complete flow
599 1. confRequest/create message (Alice creates a default conference)
601
602
606
609 xcon-userid:Alice@example.com
610 create
611
612
613
615 2. confResponse/create message ("success", created conference
616 object returned)
618
619
623
626 xcon-userid:Alice@example.com
627 xcon:8977794@example.com
628 create
629 200
630 success
631 1
632
633
634
635
636 Default conference initiated by Alice
637
638
639
640
641 xcon:8977794@example.com
643
644
645 Conference XCON-URI
646
647
648
649 10
650
651
652
653 audio
654
655
656
657
658 false
659
660
661 allow
662
663
665
666
667
668
669
670
672 Figure 4: Create Basic Conference Detailed Messaging
674 5.2. Conference Creation using Blueprints
676 The previous example showed the creation of a new conference using
677 default values. This means the client provided no information about
678 how she wanted the conference to be created. The XCON framework (and
679 CCMP as a consequence) allows for the implementation of templates.
680 These templates are called "conference blueprints", and are basically
681 conference objects with pre-defined settings. This means that a
682 client might get a list of blueprints, choose the one that more fits
683 his needs, and use the chosen blueprint to create a new conference.
685 This section Figure 5 provides an example of one client, "Alice",
686 discovering the conference blueprints available for a particular
687 conferencing system and creating a conference based on the desired
688 blueprint. In particular, Alice is interested in those blueprints
689 suitable to represent a "video-conference", i.e. a conference in
690 which both audio and video are available, so she makes use of the
691 filter mechanism provided by CCMP to make a selective blueprints
692 retrieve request. This results in three distinct CCMP transactions.
694 CMCC "Alice" ConfS
695 | |
696 | (1) blueprintsRequest |
697 | (confUserID,xpathFilter) |
698 |------------------------------>|
699 | |
700 | (2) blueprintsResponse |
701 | (confUserID, |
702 | 200, success, |
703 | blueprintsInfo) |
704 | |
705 |<------------------------------|
706 | |
707 |--+ |
708 | | choose preferred |
709 | | blueprint from the |
710 | | list (blueprintName) |
711 |<-+ |
712 | |
713 | (3) blueprintRequest |
714 | (confUserID,confObjID, |
715 | retrieve) |
716 |------------------------------>|
717 | |
718 | 4) blueprintResponse |
719 | (confUserID,confObjID,|
720 | retrieve, 200, |
721 | success, confInfo) |
722 |<------------------------------|
723 | |
724 | (5) confRequest(confUserID, |
725 | confObjID,create) |
726 |------------------------------>|
727 | |
728 | (a)Create +---|
729 | Conf | |
730 | Object | |
731 | & IDs +-->|
732 | |--+ (b) MS
733 | | | creates
734 | | | conf and
735 | |<-+ its ID
736 | | (confid=Y)
737 |(6) confResponse |
738 | (confUserID, confObjID*, |
739 | create, 200, success) |
740 |<------------------------------|
741 | |
742 | |
743 | |
744 . .
745 . .
747 Figure 5: Client Creation of Conference using Blueprints
749 1. Alice first sends a "blueprintsRequest" message to the
750 conferencing system identified by the conference server discovery
751 process. This request contains the "confUserID" of the user
752 issuing the request (Alice's XCON-USERID) and the "xpathFilter"
753 parameter by which Alice specifies she desires to obtain only
754 blueprints providing support for both audio and video: for this
755 purpose, the xpath query contained in this field is: "/
756 conference-info[conference-description/available-media/entry/
757 type='audio' and conference-description/available-media/entry/
758 type='video'"] . Upon receipt of the "blueprintsRequest", the
759 conferencing system would first ensure, on the basis of the
760 "confUserID" parameter, that Alice has the appropriate authority
761 based on system policies to receive the requested kind of
762 blueprints supported by that system.
764 2. All blueprints that Alice is authorized to use are returned in a
765 "blueprintsResponse" message in the "blueprintsInfo" element.
767 3. Upon receipt of the "blueprintsResponse" containing the
768 blueprints, Alice determines which blueprint to use for the
769 conference to be created. Alice sends a "blueprintRequest"
770 message to get the specific blueprint as identified by the
771 "confObjID".
773 4. The conferencing system returns the "confInfo" associated with
774 the specific blueprint as identified by the "confObjID" in the
775 "blueprintResponse" message.
777 5. Alice finally sends a "confRequest" with a "create" operation to
778 the conferencing system to create a conference reservation
779 cloning the chosen blueprint. This is achieved by writing the
780 blueprint's XCON-URI in the "confObjID" parameter.
782 6. Upon receipt of the "confRequest" message with a "create"
783 operation, the conferencing system uses the received blueprint to
784 clone a conference, allocating a new XCON-URI (again called
785 "confObjID*" in the example). The conferencing server then sends
786 a "confResponse" message including the new "confObjID*"
787 associated with the newly created conference instance. Upon
788 receipt of the "confResponse" message, Alice can now add other
789 users to the conference .
791 1. blueprintsRequest message (Alice requires the list of the
792 available blueprints with video support)
794
795
798
800 xcon-userid:Alice@example.com
801
802 /conference-info[conference-description/
803 available-media/entry/type='audio'
804 and
805 conference-description/available-media/entry/type='video']
806
807
808
809
811 2. blueprintsResponse message (the server provides a
812 descriptions of the available blueprints
813 fitting Alice's request)
815
816
820
823 xcon-userid:Alice@example.com
824 200
825 success
826
827
828
829 xcon:VideoRoom@example.com
830 VideoRoom
831 Video Room:
832 conference room with public access,
833 where both audio and video are available,
834 4 users can talk and be seen at the same time,
835 and the floor requests are automatically accepted.
836
837
838
839 xcon:VideoConference1@example.com
840 VideoConference1
841 Public Video Conference: conference
842 where both audio and video are available,
843 only one user can talk
844
845
846
847
848
849
851 3. blueprintRequest/retrieve message (Alice wants the
852 "VideoRoom" blueprint)
854
855
859
861 xcon-userid:Alice@example.com
862 xcon:VideoRoom@example.com
863 retrieve
864
865
866
868 4. blueprintResponse/retrieve message ("VideoRoom"
869 conference object returned)
871
872
876
878 xcon-userid:Alice@example.com
879 xcon:VideoRoom@example.com
880 retrieve
881 200
882 success
883
884
885
886 VideoRoom
887 4
888
889
890 audio
891
892
893 video
894
895
896
897
898 allow
899
900
901 confirm
902
903
904
905 audioLabel
906
907
908 videoLabel
909
910
911
912
913
914
915
917 5. confRequest/create message (Alice clones the "VideoRoom" blueprint)
918
919
923
926 xcon-userid:Alice@example.com
927 xcon:VideoRoom@example.com
928 create
929
930
931
933 6. confResponse/create message (cloned conference
934 object returned)
936
937
941
944 xcon-userid:Alice@example.com
945 xcon:8977794@example.com
946 create
947 200
948 success
949 1
950
951
952
953
954 New conference by Alice cloned from VideoRoom
955
956
957
958
959 xcon:8977794@example.com
960
961
962 conference xcon-uri
963
964
965 8601
967
968
969
970 10
971
972
973 audio
974
975
976 video
977
978
979
980
981 allow
982
983
984
985 confirm
986
987
988 11
989
990
991 12
992
993
994
995
996
997
998
1000 Figure 6: Create Conference (Blueprint) Detailed Messaging
1002 5.3. Conference Creation using User-Provided Conference Information
1004 A conference can also be created by the client sending a
1005 "confRequest" message with the "create" operation, along with the
1006 desired data in the form of the "confInfo" parameter for the
1007 conference to be created. The request also includes the "confUserID"
1008 of the requesting entity.
1010 This approach allows for a client (in this example Alice) to
1011 completely describe what the conference object should look like,
1012 without relying on defaults or blueprints: e.g, which media should be
1013 available, the topic, the users allowed to join, any scheduling-
1014 related information and so on. This can be done by providing in the
1015 creation request a full conference object for the server to parse.
1017 This "confInfo" parameter must comply with the Data Model
1018 specification. This means that the "entity" attribute is mandatory,
1019 and cannot be missing in the document. However, in this example the
1020 client is actually requesting the creation of a new conference, which
1021 doesn't exist yet, so the "entity" attribute is unknown. As
1022 discussed in Section 4.1, the CCMP protocol allows for the use of a
1023 wildcard placeholder. This placeholder
1024 ("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure
1025 the "confInfo" element is compliant with the Data Model, and would
1026 subsequently be replaced by the conferencing system with the actual
1027 value. Thus, when the conferencing system actually creates the
1028 conference, a valid "entity" value is created for it as well, which
1029 takes the place of the wildcard value when the actual conference
1030 object provided by the client is populated.
1032 To give a flavour of what could be added to the conference object, we
1033 assume Alice is also interested in providing scheduling-related
1034 information. So, in this example, Alice also specifies by the
1035 element included in the "confInfo" that the
1036 conference she wants to create has to occur on a certain date
1037 spanning from a certain start time to a certain stop time and has to
1038 be replicated weekly.
1040 Moreover, Alice indicates by means of the that
1041 at the start time Bob, Carol and herself have to be called by the
1042 conferencing system to join the conference (in fact, for each
1043 corresponding to one of the above-mentioned clients, the
1044 "method" attribute is set to "dial-out").
1046 Once Alice has prepared the "confInfo" element and sent it as part of
1047 her request to the server, if the conferencing system can support
1048 that specific type of conference (capabilities, etc.), then the
1049 request results in the creation of a conference. We assume the
1050 request has been successful, and as a consequence XCON-URI in the
1051 form of the "confObjID" parameter and the XCON-USERID in the form of
1052 the "confUserID" parameter (again, the same as the requesting entity)
1053 are returned in the "confResponse" message.
1055 In this example, the created conference object is not returned in the
1056 successful "confResponse" in the "confInfo" parameter. Nevertheless,
1057 Alice could still retrieve the actual conference object by issuing a
1058 "confRequest" with a "retrieve" operation on the returned
1059 "confObjID". Such a request would show how, as described at the
1060 beginning of this section, the "entity" attribute of the conference
1061 object in "confInfo" is replaced with the actual information (i.e.
1063 "xcon:6845432@example.com").
1065 Alice Bob Carol ConfS
1066 | | | |
1067 | | | |
1068 |(1)confRequest(confUserID, | |
1069 | create, confInfo) | |
1070 | | | |
1071 |-------------------------------------->|
1072 | | | |
1073 | | (a)Create +---|
1074 | | |Conf | |
1075 | | |Object | |
1076 | | |& IDs +-->|
1077 | | | |--+ (b) MS
1078 | | | | | creates
1079 | | | | | conf and
1080 | | | |<-+ its ID
1081 | | | | (confid=Y)
1082 |(2)confResponse(confUserID,| |
1083 | confObjID, create, | |
1084 | 200, success, version) |
1085 |<--------------------------------------|
1086 | | | |
1087 ===========================================
1088 ... ... ... ...
1089 ========== START TIME OCCURS ==============
1090 | | (c) Focus +---|
1091 | | sets up | |
1092 | | signaling | |
1093 | | to Alice +-->|
1094 | | | |
1095 | | | |--+(d) MS joins
1096 | | | | | Alice &
1097 | | | |<-+ conf Y
1098 | | | |
1099 | | | |
1100 |<<###################################>>|
1101 | Alice is mixed in the conference |
1102 |<<###################################>>|
1103 | | | |
1104 | | (e)Focus +---|
1105 | | sets up | |
1106 | | signaling | |
1107 | | to Bob | |
1108 | | | +-->|
1109 | | | |
1110 | | | |--+(f)MS joins
1111 | | | | | Bob &
1112 | | | |<-+ conf Y
1113 | | | |
1114 | |<<###################>>|
1115 | | Bob is mixed too |
1116 | |<<###################>>|
1117 | | | |
1118 | | (g )Focus +---|
1119 | | sets up | |
1120 | | signaling | |
1121 | | to Carol | |
1122 | | CMCCx +-->|
1123 | | | |
1124 | | | |--+(h)MS joins
1125 | | | | | CMCCx &
1126 | | | |<-+ conf Y
1127 | | | |
1128 | | |<<#######>>|
1129 | | |Carol mixed|
1130 | | |<<#######>>|
1131 | | | |
1132 | | | |
1133 | | | |
1134 |<***All parties connected to conf Y***>|
1135 | | | |
1136 | | | |
1137 " " " "
1138 " " " "
1139 " " " "
1141 Figure 7: Create Basic Conference from user provided conference-info
1143 1. confRequest/create message (Alice proposes a conference object
1144 to be created)
1146
1147
1151
1154 xcon-userid:Alice@example.com
1155 create
1156
1157
1158
1159
1160 Dial-out conference initiated by Alice
1161
1162 10
1163
1164
1165 audio
1166
1167
1168
1169
1170
1171 BEGIN:VCALENDAR
1172 VERSION:2.0
1173 PRODID:-//Mozilla.org/NONSGML
1174 Mozilla Calendar V1.0//EN
1175 BEGIN:VEVENT
1176 DTSTAMP: 20100127T140728Z
1177 UID: 20100127T140728Z-345FDA-alice@example.com
1178 ORGANIZER:MAILTO:alice@example.com
1179 DTSTART:20100127T143000Z
1180 RRULE:FREQ=WEEKLY
1181 DTEND: 20100127T163000Z
1182 END:VEVENT
1183 END:VCALENDAR
1184
1185
1187 2010-01-27T14:29:00Z
1188
1189
1191 2010-01-27T16:31:00Z
1192
1193
1194 2010-01-27T15:30:00Z
1195
1196
1197
1198
1199
1200 allow
1201
1202
1204
1206
1208
1209
1210
1211
1212
1213
1215 2. confResponse/create message (200, "success")
1217
1218
1222
1225 xcon-userid:Alice@example.com
1226 xcon:6845432@example.com
1227 create
1228 200
1229 success
1230 1
1231
1232
1233
1235 Figure 8: Create Basic Conference Detailed Messaging
1237 5.4. Cloning an Existing Conference
1239 A client can also create another conference by cloning an existing
1240 conference, such as an active conference or conference reservation.
1241 This approach can be seen as a logical extension of the creation of a
1242 new conference using a blueprint: the difference is that, instead of
1243 cloning the pre-defined settings listed in a blueprint, the settings
1244 of an existing conference would be cloned.
1246 In this example, the client sends a "confRequest" message with the
1247 "create" operation, along with the "confUserID" and a specific
1248 "confObjID", from which a new conference is to be created by cloning
1249 an existing conference.
1251 An example of how a client can create a conference based on a
1252 blueprint is provided in Section 5.2. The manner by which a client
1253 in this example might learn about a conference reservation or active
1254 conferences is similar to the first step in the blueprint example,
1255 with the exception of querying for different types of conference
1256 objects supported by the specific conferencing system. For example,
1257 in this example, the client clones a conference reservation (i.e., an
1258 inactive conference).
1260 If the conferencing system can support a new instance of the specific
1261 type of conference (capabilities, etc.), then the request results in
1262 the creation of a conference, with an XCON-URI in the form of a new
1263 value in the "confObjID" parameter to reflect the newly cloned
1264 conference object returned in the "confResponse" message.
1266 Alice ConfS
1267 | |
1268 |(1)confRequest(confUserID, |
1269 | confObjID, create) |
1270 |------------------------------>|
1271 | (a)Create +---|
1272 | Conf | |
1273 | Object | |
1274 | & IDs +-->|
1275 | |--+ (b) MS
1276 | | | creates
1277 | | | conf and
1278 | |<-+ its ID
1279 | | (confid=Y)
1280 | |
1281 |(2)confResponse(confUserID, |
1282 | confObjID*,create, |
1283 | 200, success, |
1284 | version, confInfo) |
1285 | |
1286 |<------------------------------|
1287 | |
1289 Figure 9: Create Basic Conference - Clone
1291 1. Alice, a conferencing system client, sends a confRequest message
1292 to clone a conference based on an existing conference
1293 reservation. Alice indicates this conference should be cloned
1294 from the specified parent conference represented by the
1295 "confObjID" in the request.
1297 2. Upon receipt of the confRequest message containing a "create"
1298 operation and "confObjID", the conferencing system ensures that
1299 the "confObjID" received is valid. The conferencing system
1300 determines the appropriate read/write access of any users to be
1301 added to a conference based on this "confObjID" (using
1302 membership, roles, etc.). The conferencing system uses the
1303 received "confObjID" to clone a conference reservation. The
1304 conferencing system also reserves or allocates a new "confObjID"
1305 (called "confObjID*" in Figure 9) to be used for the cloned
1306 conference object. This new identifier is of course different
1307 from the one associated with the conference to be cloned, since
1308 it represents a different conference object. Any subsequent
1309 protocol requests from any of the members of the conference must
1310 use this new identifier. The conferencing system maintains the
1311 mapping between this conference ID and the parent conference
1312 object ID associated with the reservation through the conference
1313 instance, and this mapping is explicitly addressed through the
1314 "cloning-parent" element of the "conference-description" in the
1315 new conference object.
1317 1. confRequest/create message (Alice clones an existing conference)
1319
1320
1324
1327 xcon-userid:Alice@example.com
1328 xcon:6845432@example.com
1329 create
1330
1331
1332
1334 2. confResponse/create message (created conference
1335 object returned)
1337
1338
1342
1345 xcon-userid:Alice@example.com
1346 xcon:8977794@example.com
1347 create
1348 200
1349 success
1350 1
1351
1352
1353
1354
1355 New conference by Alice cloned from 6845432
1356
1357 10
1358
1359
1360 audio
1361
1362
1363
1364 xcon:6845432@example.com
1365
1366
1367
1368 allow
1369
1370
1372
1374
1376
1377
1378
1379
1380 confirm
1381
1382
1383 11
1384
1385
1386
1387
1388
1389
1390
1392 Figure 10: Create Basic Conference (Clone) Detailed Messaging
1394 6. Conference Users Scenarios and Examples
1396 Section 5 showed examples describing the several different ways a
1397 conference might be created using CCMP. This section focuses on
1398 user-related scenarios, i.e. typical scenarios that may occur during
1399 the lifetime of a conference, like adding new users and handling
1400 their media. The following scenarios are based on those documented
1401 in the XCON framework. The examples assume that a conference has
1402 already been correctly established, with media, if applicable, per
1403 one of the examples in Section 5.
1405 6.1. Adding a Party
1407 In this example, Alice wants to add Bob to an established conference.
1408 In the following example we assume Bob is a new user of the system,
1409 which means Alice also needs to provide some details about him. In
1410 fact, the case of Bob already present as a user in the conferencing
1411 system is much easier to address, and will be discussed later on.
1413 "Alice" "Bob"
1414 CMCC1 CMCC2 CMCCx ConfS
1415 | | | |
1416 |(1) userRequest(confUserID,| |
1417 | confObjID, create, | |
1418 | userInfo) | | |
1419 |-------------------------------------->|
1420 | | | |
1421 | | (a) Create +---|
1422 | | | Bob | |
1423 | | | as a | |
1424 | | | user +-->|
1425 | | | |
1426 |(2) userResponse(confUserID, confObjID |
1427 | create, 200, success, userInfo) |
1428 |<--------------------------------------|
1429 | | | |
1430 | | | (b) Focus |
1431 | | | sets up |
1432 | | | signaling |
1433 | | | to Bob |
1434 | |<----------------------|
1435 | | | |
1436 | | | (c) Notify|
1437 | | | ("Bob just|
1438 | | | joined") |
1439 | | |<----------|
1440 | | | |
1441 ' ' ' '
1442 ' ' ' '
1443 ' ' ' '
1445 Figure 11: Client Manipulation of Conference - Add a party
1447 1. Alice sends a userRequest message with an operation of "create"
1448 to add Bob to the specific conference as identified by the
1449 "confObjID". The "create" operation also makes sure that Bob is
1450 created as a user in the whole conferencing system. This is done
1451 by adding in the request a "userInfo" element describing Bob as a
1452 user. This is needed in order to let the conferencing system be
1453 aware of Bob's characteristics. In case Bob was already a
1454 registered user, Alice would just have referenced him through his
1455 XCON-USERID in the "entity" attribute of the "userInfo" field,
1456 without providing additional data. In fact, that data
1457 (including, for instance, Bob's SIP-URI to be used subsequently
1458 for dial-out) would be obtained by referencing the extant
1459 registration. The conference server ensures that Alice has the
1460 appropriate authority based on the policies associated with that
1461 specific conference object to perform the operation. As
1462 mentioned before, a new Conference User Identifier is created for
1463 Bob, and the "userInfo" is used to update the conference object
1464 accordingly. As already seen in Section 5.3, a placeholder
1465 wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
1466 messages below) is used for the "entity" attribute of the
1467 "userInfo" element, to be replaced by the actual XCON-USERID
1468 later on;
1470 2. Bob is successfully added to the conference object, and an XCON-
1471 USERID is allocated for him ("xcon-userid:Bob@example.com"); this
1472 identifier is reported in the response as part of the "entity"
1473 element of the returned "userInfo";
1475 3. In the presented example, the call signaling to add Bob to the
1476 conference is instigated through the Focus as well. As noted
1477 previously, this is implementation specific. In fact, a
1478 conferencing system may accomplish different actions after the
1479 user creation, just as it may do nothing at all. Among the
1480 possible actions, for instance, Bob may be added as a
1481 element to the element, whose joining
1482 "method" may be either "dial-in" or "dial-out". Besides, out-of-
1483 band notification mechanisms may be involved as well, e.g. to
1484 notify Bob via mail of the new conference, including details as
1485 the date, password, expected participants and so on (see
1486 Section 4.3).
1488 Once Bob has been successfully added to the specified conference,
1489 per updates to the state, and depending upon the policies, other
1490 participants (including Bob himself) may be notified of the
1491 addition of Bob to the conference via the Conference Notification
1492 Service in use.
1494 1. userRequest/create message (Alice adds Bob)
1496
1497
1500
1502 xcon-userid:Alice@example.com
1503 xcon:8977878@example.com
1504 create
1505
1506
1507 Bob
1508
1509
1510 mailto:bob.depippis@example.com
1511 Bob's email
1512
1513
1514
1515 Bob's laptop
1516
1517
1518
1519
1520
1522 2. userResponse/create message (a new XCON-USERID is
1523 created for Bob and he is added to the conference)
1525
1526
1529
1531 xcon-userid:Alice@example.com
1532 xcon:8977878@example.com
1533 create
1534 200
1535 success
1536 10
1537
1538
1539 Bob
1540
1541
1542 mailto:bob.depippis@example.com
1543 Bob's email
1544
1545
1546
1547 Bob's laptop
1548
1549
1550
1551
1552
1553 Figure 12: Add Party Message Details
1555 6.2. Muting a Party
1557 This section provides an example of the muting of a party in an
1558 active conference. We assume that the user to mute has already been
1559 added to the conference. The document only addresses muting and not
1560 unmuting, since the latter would involve an almost identical CCMP
1561 message flow anyway. However, if any external floor control is
1562 involved, whether a particular conference client can actually mute/
1563 unmute itself, must be considered by the conferencing system.
1565 Please notice that interaction between CCMP and floor control
1566 should be carefully considered. In fact, handling CCMP- and BFCP-
1567 based media control has to be considered as multiple layers: i.e.,
1568 a participant may have the BFCP floor granted, but be muted by
1569 means of CCMP. If so, he would still be muted in the conference,
1570 and would only be unmuted if both the protocols allowed for this.
1572 Figure 13 provides an example of one client, "Alice", impacting the
1573 media state of another client, "Bob". This example assumes an
1574 established conference. In this example, Alice, whose role is
1575 "moderator" of the conference, wants to mute Bob on a medium-size
1576 multi-party conference, as his device is not muted (and he's
1577 obviously not listening to the call) and background noise in his
1578 office environment is disruptive to the conference. BFCP floor
1579 control is assumed not to be involved.
1581 Muting can be accomplished using the "mute" control in the conference
1582 object, in which case the conference server must update the settings
1583 associated with the user's media streams. Muting/unmuting can also
1584 be accomplished by directly updating the conference object with
1585 modified settings related to the target user's media streams, which
1586 is the approach shown in this example. Specifically, Bob's
1587 "userInfo" is updated by modifying its audio information
1588 (e.g. setting it to "recvonly" in case of muting), identified by the
1589 right media id.
1591 "Alice" "Bob"
1592 CMCC1 CMCC2 CMCCx ConfS MS
1593 | | | | |
1594 |(1) userRequest(subject, | | |
1595 | confUserID,confObjID, | | |
1596 | update,userInfo) | | |
1597 | | | | |
1598 |--------------------------------------->| |
1599 | | | | Mute Bob |
1600 | | | |----------------->|
1601 | | | | 200 OK |
1602 | | | |<-----------------|
1603 | | | | |
1604 | |<====== XXX Bob excluded from mix XXX ====>|
1605 | | | | |
1606 | | (a) Update +---| |
1607 | | Bob in | | |
1608 | | Data Model | | |
1609 | | (muted) +-->| |
1610 | | | | |
1611 | (2)userResponse(confUserID,confObjID, | |
1612 | update,200,success,version) | |
1613 |<---------------------------------------| |
1614 | | | | |
1615 | | | (b) Notify | |
1616 | | | ("Bob is | |
1617 | | | muted") | |
1618 | | |<-----------| |
1619 | | | | |
1620 ' ' ' ' '
1621 ' ' ' ' '
1622 ' ' ' ' '
1624 Figure 13: Client Manipulation of Conference - Mute a party
1626 1. Alice sends a userRequest message with an "update" operation and
1627 the userInfo with the "status" field in the "media" element for
1628 Bob's set to "revconly". In order to authenticate
1629 herself, Alice provides in the "subject" request parameter her
1630 registration credentials (i.e. username and password). The
1631 "subject" parameter is an optional one: its use can be systematic
1632 whenever the conferencing server envisages to authenticate each
1633 requestor. In such cases, if the client does not provide the
1634 required authentication information, the conferencing server
1635 answers with a CCMP "authenticationRequired" response message,
1636 indicating that the request cannot be processed without including
1637 the proper "subject" parameter. The Conference Server ensures
1638 that Alice has the appropriate authority based on the policies
1639 associated with that specific conference object to perform the
1640 operation. It recognizes that Alice is allowed to request the
1641 specified modification, since she is moderator of the target
1642 conference, and updates the "userInfo" in the conference object
1643 reflecting that Bob's media is not to be mixed with the
1644 conference media. If the Conference Server relies on a remote
1645 Media Server for its multimedia functionality, it subsequently
1646 changes Bob's media profile accordingly by means of the related
1647 protocol interaction with the MS. An example describing a
1648 possible way of dealing with such a situation using the Media
1649 Server Control architecture is described in
1650 [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework
1651 Transactions (2)".
1653 2. A userResponse message with a "200" response-code ("success") is
1654 then sent to Alice. Depending upon the policies, the conference
1655 server may notify other participants (including Bob) of this
1656 update via any Conference Notification Service that may be in
1657 use.
1659 1. userRequest/update message (Alice mutes Bob)
1661
1662
1665
1667
1668 Alice83
1669 13011983
1670
1671 xcon-userid:Alice@example.com
1672 xcon:8977878@example.com
1673 update
1674
1675
1676
1677
1678 123
1679 recvonly
1680
1681
1682
1683
1684
1685
1687 2. userResponse/update message (Bob has been muted)
1689
1690
1693
1695 xcon-userid:Alice@example.com
1696 xcon:8977878@example.com
1697 update
1698 200
1699 success
1700 7
1701
1702
1703
1704 Figure 14: Mute Message Details
1706 6.3. Conference Announcements and Recordings
1708 This section deals with features that are typically required in a
1709 conferencing system, such as public announcements (e.g. to notify
1710 vocally that a new user joined a conference) and name recording.
1711 While this is not strictly CCMP-related (the CCMP signaling is
1712 actually the same as the one seen in Section 6.1) it is an
1713 interesting scenario to address to see how several components of an
1714 XCON-compliant architecture interact with each other to make it
1715 happen.
1717 In this example, as shown in Figure 15 Alice is joining Bob's
1718 conference that requires that she first enters a pass code. After
1719 successfully entering the pass code, an announcement prompts Alice to
1720 speak her name so it can be recorded. When Alice is added to the
1721 active conference, the recording is played back to all the existing
1722 participants. A very similar example is presented in Figure 33 of
1723 [I-D.ietf-mediactrl-call-flows].
1725 CMCC "Alice" ConfS MS
1726 | | |
1727 |(1)userRequest(confObjID, | |
1728 | create,userInfo) | |
1729 |--------------------------->| |
1730 | |--+ Alice is |
1731 | | | new in the |
1732 | |<-+ system (create |
1733 | | confUserID) |
1734 | ConfS handles +--| |
1735 | SIP signaling | | |
1736 | (Alice<->ConfS<->MS) +->| |
1737 | | |
1738 | |--+ A password is |
1739 | | | required for |
1740 | |<-+ that conference |
1741 | | |
1742 | | Request IVR menu (PIN) |
1743 | |--------------------------->|
1744 | | |
1745 |<========= MS gets PIN from Alice through DTMF =========>|
1746 | | |
1747 | | Provided PIN is... |
1748 | |<---------------------------|
1749 | Check +--| |
1750 | PIN | | |
1751 | +->| |
1752 | |--+ Alice must |
1753 | | | record her |
1754 | |<-+ name |
1755 | | |
1756 | | Request name recording |
1757 | |--------------------------->|
1758 | | |
1759 |<========= MS records Alice's audio RTP (name) =========>|
1760 | | |
1761 | | Audio recording |
1762 | |<---------------------------|
1763 | Complete +--| |
1764 | creation | | |
1765 | of Alice +->| |
1766 | | |
1767 | | |
1768 | (2)userResponse(confUserID,| |
1769 | confObjID,create,200,| |
1770 | success,version) | |
1771 |<---------------------------| |
1772 | | |
1773 Figure 15: Recording and Announcements
1775 1. Upon receipt of the userRequest from Alice to be added to Bob's
1776 conference, the conferencing system determines that a password is
1777 required for this specific conference. Thus an announcement
1778 asking Alice to enter the password is sent back. This may be
1779 achieved by means of typical IVR functionality. Once Alice
1780 enters the password, it is validated against the policies
1781 associated with Bob's active conference. The conferencing system
1782 then connects to a server which prompts and records Alice's name.
1783 The conferencing system must also determine whether Alice is
1784 already a user of this conferencing system or whether she is a
1785 new user. In this case, Alice is a new user for this
1786 conferencing system, so a Conference User Identifier (i. e. an
1787 XCON-USERID) is created for Alice. Based upon the contact
1788 information provided by Alice, the call signaling to add Alice to
1789 the conference is instigated through the Focus.
1791 2. The conference server sends Alice a userResponse message which
1792 includes the "confUserID" assigned by the conferencing system to
1793 her. This would allow Alice to later perform operations on the
1794 conference (if she were to have the appropriate policies),
1795 including registering for event notifications associated with the
1796 conference. Once the call signaling indicates that Alice has
1797 been successfully added to the specific conference, per updates
1798 to the state, and depending upon the policies, other participants
1799 (e.g., Bob) are notified of the addition of Alice to the
1800 conference via the conference notification service and an
1801 announcement is provided to all the participants indicating that
1802 Alice has joined the conference.
1804 1. userRequest/create message (A new conferencing system client,
1805 Alice, enters Bob's conference)
1807
1808
1812
1814 xcon:bobConf@example.com
1815 create
1816
1817
1818
1819
1820
1821 mailto:Alice83@example.com
1822
1823 email
1824
1825
1826
1827
1828
1829
1830
1832 2. userResponse/create (Alice provided with a new xcon-userid
1833 and added to the conference)
1835
1836
1840
1842 xcon-userid:Alice@example.com
1843 xcon:bobConf@example.com
1844 create
1845 200
1846 success
1847 5
1848
1849
1850
1851 Figure 16: Announcement Messaging Details
1853 6.4. Monitoring for DTMF
1855 Conferencing systems often also need the capability to monitor for
1856 DTMF from each individual participant. This would typically be used
1857 to enter the identifier and/or access code for joining a specific
1858 conference. This feature is often also exploited to achieve
1859 interaction between participants and the conference system for non-
1860 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted).
1862 An example of DTMF monitoring, within the context of the framework
1863 elements, is shown in Figure 15. The mediactrl architecture/
1864 protocols can be used by the conferencing system for all the DTMF
1865 interactions. Examples for DTMF interception in conference instances
1866 are presented in [I-D.ietf-mediactrl-call-flows].
1868 6.5. Entering a password-protected conference
1870 Some conferences may require a password to be provided by a user who
1871 wants to manipulate the conference objects (e.g. join, update,
1872 delete) via CCMP. In this case, a password would be included in the
1873 element related to the conference XCON-URI in
1874 the appropriate entry and must be then included in
1875 the "conference-password" field in the CCMP request addressed to a
1876 specific conference.
1878 In the following example, Alice, a conferencing system client,
1879 attempts to join a password-protected conference.
1881 1. Alice sends a userRequest message with a "create" operation to
1882 add herself in the conference with XCON-URI
1883 "xcon:8977777@example.com" (written in the "confObjID"
1884 parameter). Alice provides her XCON-USERID via the "confUserID"
1885 field of the userRequest and leaves out the "userInfo" one
1886 (first-party join). In this first attempt, she doesn't insert
1887 any password parameter.
1889 2. Upon receipt the userRequest/create message, the conferencing
1890 server detects that the indicated conference is not joinable
1891 without providing the appropriate pass code. A userResponse
1892 message with "423" response-code ("conference password required")
1893 is returned to Alice to indicate that her join has been refused
1894 and that she has to resend her request including the appropriate
1895 conference password in order to participate.
1897 3. After getting the pass code through out-of-band mechanisms, Alice
1898 provides it in the proper "password" request field of a new
1899 userRequest/create message and sends the updated request back to
1900 the server.
1902 4. The conferencing server checks the provided password and then
1903 adds Alice to the protected conference. After that, a
1904 userResponse with a "200" response-code ("success") is sent to
1905 Alice.
1907 1. userRequest/create message (Alice tries to enter the conference
1908 without providing the password)
1910
1911
1915
1917 xcon-userid:Alice@example.com
1918 xcon:8977794@example.com
1919 create
1920
1921
1922
1924 2. userResponse/create message (423, "conference password required")
1926
1927
1931
1933 xcon-userid:Alice@example.com
1934 xcon:8977794@example.com
1935 create
1936 423
1937 conference password required
1938
1939
1940
1942 3. userRequest/create message (Alice provides the password)
1944
1945
1949
1951 xcon-userid:Alice@example.com
1952 xcon:8977794@example.com
1953 create
1954 8601
1955
1956
1957
1959 4. userResponse/create message
1960 (Alice has been added to the conference)
1962
1963
1967
1969 xcon-userid:Alice@example.com
1970 xcon:8977794@example.com
1971 create
1972 200
1973 success
1974 10
1975
1976
1977
1979 Figure 17: Password-protected conference join messages details
1981 7. Sidebars Scenarios and Examples
1983 While creating conferences and manipulating users and their media are
1984 sufficient for many scenarios, there may be cases when a more complex
1985 management is needed.
1987 In fact, a feature typically required in conferencing systems is the
1988 ability to create sidebars. A sidebar is basically a child
1989 conference that usually includes a subset of the participants of the
1990 parent conference, and a subset of its media as well. Sidebars are
1991 typically required whenever some of the participants in a conference
1992 want a private discussion, without interfering with the main
1993 conference.
1995 This section deals with some typical scenarios using a sidebar, like
1996 whispering, private messages and coaching scenarios. The first
1997 subsections present some examples of how a generic sidebar can be
1998 created, configured and managed.
2000 7.1. Internal Sidebar
2002 Figure 18 provides an example of one client, "Alice", involved in an
2003 active conference with "Bob" and "Carol". Alice wants to create a
2004 sidebar to have a side discussion with Bob while still viewing the
2005 video associated with the main conference. Alternatively, the audio
2006 from the main conference could be maintained at a reduced volume.
2007 Alice initiates the sidebar by sending a request to the conferencing
2008 system to create a conference reservation based upon the active
2009 conference object. Alice and Bob would remain on the roster of the
2010 main conference, such that other participants could be aware of their
2011 participation in the main conference, while an internal-sidebar
2012 conference is occurring. Besides, Bob decides that he is not
2013 interested in still receiving the conference audio in background (not
2014 even at a lower volume as Alice configured) and so modifies the
2015 sidebar in order to make that stream inactive for him.
2017 Alice Bob ConfS
2018 | | |
2019 |(1) sidebarByValRequest(confUserID, |
2020 | confObjID,create) |
2021 |--------------------------------------------->|
2022 | | |
2023 | | (a) Create +---|
2024 | | sidebar-by-val | |
2025 | | (new conf obj | |
2026 | | cloned from +-->|
2027 | | confObjID) | Sidebar now has
2028 | | | id confObjID*
2029 |(2) sidebarByValResponse(confUserID, | (parent mapping
2030 | (confObjID*,create,200,success, | conf<->sidebar)
2031 | version,sidebarByValInfo) |
2032 |<---------------------------------------------|
2033 | | |
2034 |(3) sidebarByValRequest |
2035 | (confUserID, confObjID*, |
2036 | update,sidebarByValInfo) |
2037 |--------------------------------------------->|
2038 | | |
2039 | | (b) Update +---|
2040 | | sidebar-by-val | |
2041 | | (media, users | |
2042 | | etc.) +-->|
2043 | | | Sidebar is
2044 | | | modified
2045 |(4) sidebarByValResponse(confUserID, |
2046 | confObjID*, update, |
2047 | 200, success, version) |
2048 |<---------------------------------------------|
2049 | | |
2050 | |(5) userRequest |
2051 | | (confUserID', |
2052 | | confObjID*, |
2053 | | update,userInfo)|
2054 | |---------------------->|
2055 | | |
2056 | | (c) Update +---|
2057 | | user settings | |
2058 | | (Bob's media) | |
2059 | | +-->|
2060 | | | Sidebar is modified
2061 | | | (original audio
2062 | | | inactive for Bob)
2063 | |(6) userResponse |
2064 | | (confUserID', |
2065 | | confObjID*, |
2066 | | update, 200, |
2067 | | success,version) |
2068 | |<----------------------|
2069 | | |
2070 " " "
2071 " " "
2072 " " "
2074 Figure 18: Client Creation of a Sidebar Conference
2076 1. Upon receipt of CCMP sidebarByValRequest message to create a new
2077 sidebar-conference based upon the confObjID received in the
2078 request, the conferencing system uses the confObjID to clone a
2079 conference reservation for the sidebar. The sidebar reservation
2080 is NOT independent of the active conference (i.e., parent). The
2081 conferencing system also allocates a new XCON-URI for that
2082 sidebar to be used for any subsequent protocol requests from any
2083 of the members of the conference. The new sidebar identifier
2084 ("confObjID*" in Figure 18) is returned in the response message
2085 confObjID parameter.
2087 2. The relationship information is provided in the
2088 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the
2090 main/parent conference is provided below as well to show how the
2091 cloning process for the creation of the sidebar could take place.
2093 3. Upon receipt of the sidebarByValResponse message to reserve the
2094 conference, Alice can now create an active conference using that
2095 reservation, or create additional reservations based upon the
2096 existing reservations. In this example, Alice wants only Bob to
2097 be involved in the sidebar, thus she manipulates the membership
2098 so that only the two of them appear in the
2099 section. Alice also wants both audio and video from the original
2100 conference to be available in the sidebar. For what concerns the
2101 media belonging to the sidebar itself, Alice wants the audio to
2102 be restricted to the participants in the sidebar (that is, Bob
2103 and herself). Additionally, Alice manipulates the media values
2104 to receive the audio from the main conference at a reduced
2105 volume, so that the communication between her and Bob isn't
2106 affected. Alice sends a sidebarByValRequest message with an
2107 operation of "update" along with the "sidebarByValInfo"
2108 containing the aforementioned sidebar modifications.
2110 4. Upon receipt of the sidebarByValRequest to update the sidebar
2111 reservation, the conference server ensures that Alice has the
2112 appropriate authority based on the policies associated with that
2113 specific conference object to perform the operation. The
2114 conference server must also validate the updated information in
2115 the reservation, ensuring that a member like Bob is already a
2116 user of this conference server. Once the data for the confObjID
2117 is updated, the conference server sends a sidebarByValResponse to
2118 Alice. Depending upon the policies, the initiator of the request
2119 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may
2120 be notified of his addition to the sidebar via the conference
2121 notification service.
2123 5. At this point, Bob sends a userRequest message to the conference
2124 server with an operation of "update" to completely disable the
2125 background audio from the parent conference, since it prevents
2126 him from understanding what Alice says in the sidebar.
2128 6. Notice that Bob's request only changes the media perspective for
2129 Bob. Alice keeps on receiving both the audio from Bob and the
2130 background from the parent conference. This request may be
2131 relayed by the conference server to the Media Server handling the
2132 mixing, if present. Upon completion of the change, the
2133 conference server sends a "userResponse" message to Bob.
2134 Depending upon the policies, the initiator of the request (i.e.,
2135 Bob) and the participants in the sidebar (i.e., Alice) may be
2136 notified of this change via the conference notification service.
2138 The following conference object represents the conference in which
2139 the sidebar is to be created. It will be used by the conferencing
2140 system to create the new conference object associated with the
2141 sidebar.
2143
2144
2149
2150 MAIN CONFERENCE
2151
2152
2153 sip:8977878@example.com
2154 conference sip uri
2155
2156
2157
2158
2159 main conference audio
2160 audio
2161 sendrecv
2162
2163
2164 main conference video
2165 video
2166 sendrecv
2167
2168 single-view
2169
2170
2171
2172
2173
2174 true
2175
2176
2177
2178 Alice
2179
2180
2181 123
2182 sendrecv
2183
2184
2185 456
2186 sendrecv
2187
2188
2189
2190
2191 Bob
2192
2193
2194 123
2195 sendrecv
2196
2197
2198 456
2199 sendrecv
2200
2201
2202
2203
2204 Carol
2205
2206
2207 123
2208 sendrecv
2209
2210
2211 456
2212 sendrecv
2213
2214
2215
2216
2217
2219 Figure 19: Conference with Alice, Bob and Carol
2221 The sidebar creation happens through a cloning of the parent
2222 conference. Once the sidebar is created, an "update" makes sure that
2223 the sidebar is customized as needed. The following protocol dump
2224 makes the process clearer.
2226 1. sidebarByValRequest/create message (Alice creates an
2227 internal sidebar)
2229
2230
2233
2235 xcon-userid:Alice@example.com
2236 xcon:8977878@example.com
2237 create
2238
2239
2240
2242 2. sidebarByValResponse/create message (sidebar returned)
2244
2245
2249
2251 xcon-userid:Alice@example.com
2252 xcon:8974545@example.com
2253 create
2254 200
2255 success
2256 1
2257
2258
2259
2260
2261 SIDEBAR CONFERENCE registered by Alice
2262
2263
2264
2265
2266 main conference audio
2267
2268 audio
2269 sendrecv
2270
2271
2272
2273 main conference video
2274
2275 video
2276 sendrecv
2277
2278
2279
2280
2281 false
2282
2283
2284
2285
2287
2289
2291
2292
2293 xcon:8977878@example.com
2294
2295
2296
2297
2298
2299
2301 3. sidebarByValRequest/update message (Alice updates the
2302 created sidebar)
2304
2305
2309
2311 xcon-userid:Alice@example.com
2312 xcon:8974545@example.com
2313 update
2314
2315
2316
2317
2318 private sidebar Alice - Bob
2320
2321
2322
2323
2324 main conference audio
2325
2326 audio
2327 recvonly
2328
2329 -60
2330
2331
2332
2333
2334 main conference video
2335
2336 video
2337 recvonly
2338
2339
2340
2341 sidebar audio
2342
2343 audio
2344 sendrecv
2345
2346
2347
2348 sidebar video
2349
2350 video
2351 sendrecv
2352
2353
2354
2355
2356
2357
2359
2361
2362
2363
2364
2365
2366
2367 4. sidebarByValResponse/update message (sidebar's
2368 updates accepted)
2370
2371
2375
2377 xcon-userid:Alice@example.com
2378 xcon:8974545@example.com
2379 update
2380 200
2381 success
2382 2
2383
2384
2385
2387 5. userRequest/update message (Bob updates his media)
2389
2390
2394
2396 xcon-userid:Bob@example.com
2397 xcon:8974545@example.com
2398 update
2399
2400
2401
2402
2403
2404 main conference audio
2405
2406 123
2407 inactive
2408
2409
2410
2411
2412
2413
2414 6. userResponse/update message (Bob's preferences are set)
2416
2417
2420
2422 xcon-userid:Bob@example.com
2423 xcon:8974545@example.com
2424 update
2425 200
2426 success
2427 3
2428
2429
2430
2432 Figure 20: Internal Sidebar Messaging Details
2434 7.2. External Sidebar
2436 Figure 21 provides an example of a different approach towards
2437 sidebar. In this scenario, one client, "Alice", is involved in an
2438 active conference with "Bob", "Carol", "David" and "Ethel". Alice
2439 gets an important text message via a whisper from Bob that a critical
2440 customer needs to talk to Alice, Bob and Ethel. Alice creates a
2441 sidebar to have a side discussion with the customer "Fred" including
2442 the participants in the current conference with the exception of
2443 Carol and David, who remain in the active conference. The difference
2444 from the previous scenario is that Fred is not part of the parent
2445 conference: this means that different policies might be involved,
2446 considering that Fred may access information coming from the parent
2447 conference, in case the sidebar was configured accordingly. For this
2448 reason, in this scenario we assume that Alice disables all the media
2449 from the original (parent) conference within the sidebar. This means
2450 that, while in the previous example Alice and Bob still heard the
2451 audio from the main conference in background, this time no background
2452 is made available. Alice initiates the sidebar by sending a request
2453 to the conferencing system to create a conference reservation based
2454 upon the active conference object. Alice, Bob and Ethel would remain
2455 on the roster of the main conference in a hold state. Whether or not
2456 the hold state of these participants is visible to other participants
2457 depends upon the individual and local policy. However, providing the
2458 hold state allows the participants in the main conference to see that
2459 others in the conference are busy. Note, that a separate conference
2460 could have been created by Alice to allow Bob and Ethel to talk to
2461 Fred. However, creating a sidebar has somewhat of an advantage by
2462 allowing the conference to be created using some of the same settings
2463 (e.g, role, floor control, etc.) that Bob and Ethel had in the main
2464 conference and it would allow for updates such that the media could
2465 be updated, for example, to provide audio from the main conference.
2467 Alice Bob ConfS
2468 | | |
2469 |(1) sidebarByRefRequest(confUserID, |
2470 | confObjID, create) |
2471 |--------------------------------------------->|
2472 | | |
2473 | | (a) Create +---|
2474 | | sidebar-by-ref | |
2475 | | (new conf obj | |
2476 | | cloned from +-->|
2477 | | confObjID) | Sidebar now has
2478 | | | id confObjID*
2479 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2480 | confObjID*,create,200,success, | conf<->sidebar)
2481 | version,sidebarByRefInfo) |
2482 |<---------------------------------------------|
2483 | | |
2484 |(3) sidebarByRefRequest(confUserID, |
2485 | confObjID*,update,sidebarByRefInfo) |
2486 |--------------------------------------------->|
2487 | | |
2488 | | (b) Create +---|
2489 | | new user for | |
2490 | | Fred | |
2491 | | +-->|
2492 | | |
2493 | | (c) Update +---|
2494 | | sidebar-by-ref | |
2495 | | (media, users | |
2496 | | policy, etc.) +-->|
2497 | | | Sidebar is modified:
2498 | | | no media from the
2499 | | | parent conference is
2500 | | | available to anyone
2501 |(4) sidebarByRefResponse(confUserID, |
2502 | confObjID*, update, |
2503 | 200, success, version) |
2504 |<---------------------------------------------|
2505 | | |
2506 | | Notify (Fred |
2507 | | added to |
2508 | | sidebar users) |
2509 | |<----------------------|
2510 | | |
2511 " " "
2512 " " "
2513 " " "
2514 Figure 21: Client Creation of an External Sidebar
2516 1. Upon receipt of the "sidebarByRefRequest" message to create a new
2517 sidebar conference, based upon the active conference specified by
2518 "confObjID" in the request, the conferencing system uses that
2519 active conference to clone a conference reservation for the
2520 sidebar. The sidebar reservation is NOT independent of the
2521 active conference (i.e., parent). The conferencing system, as
2522 before, allocates a conference ID (confObjID*) to be used for any
2523 subsequent protocol requests toward the sidebar reservation. The
2524 mapping between the sidebar conference ID and the one associated
2525 with the main conference is mantained by the conferencing system
2526 and it is gathered from the c element in the
2527 sidebar conference object.
2529 2. Upon receipt of the "sidebarByRefResponse" message, which
2530 acknowledges the successful creation of the sidebar object, Alice
2531 decides that only Bob and Ethel, along with the new participant
2532 Fred are to be involved in the sidebar. Thus she manipulates the
2533 membership accordingly. Alice also sets the media in the
2534 "conference-info" such that the participants in the sidebar don't
2535 receive any media from the main conference. All these settings
2536 are provided to the conferencing system by means of a new
2537 "sidebarByRefRequest" message, with an "update" operation.
2539 3. Alice sends the aforementioned "sidebarByRefRequest" to update
2540 the information in the reservation and to create an active
2541 conference. Upon receipt of the "sidebarByRefRequest" with an
2542 operation of "update", the conferencing system ensures that Alice
2543 has the appropriate authority based on the policies associated
2544 with that specific conference object to perform the operation.
2545 The conferencing system also validates the updated information in
2546 the reservation. Since Fred is a new user for this conferencing
2547 system, a conference user identifier is created for Fred.
2548 Specifically, Fred is added to the conference by only providing
2549 his SIP URI. Based upon the contact information provided for
2550 Fred by Alice, the call signaling to add Fred to the conference
2551 may be instigated through the Focus (e.g. if Fred had a "dial-
2552 out" method set as the target for him) at the actual activation
2553 of the sidebar.
2555 4. The conference server sends a "sidebarByRefResponse" message and,
2556 depending upon the policies, the initiator of the request (i.e.,
2557 Alice) and the participants in the sidebar (i.e., Bob and Ethel)
2558 may be notified of his addition to the sidebar via the conference
2559 notification service.
2561 1. sidebarByRefRequest/create message (Alice creates an
2562 external sidebar)
2564
2565
2568
2570 xcon-userid:Alice@example.com
2571 xcon:8977878@example.com
2572 create
2573
2574
2575
2577 2. sidebarByRefResponse/create message (created
2578 sidebar returned)
2580
2581
2585
2587 xcon-userid:Alice@example.com
2588 xcon:8971212@example.com
2589 create
2590 200
2591 success
2592 1
2593
2594
2595
2596
2597 SIDEBAR CONFERENCE registered by Alice
2598
2599
2600
2601
2602 main conference audio
2603
2604 audio
2605 sendrecv
2607
2608
2609
2610 main conference video
2611
2612 video
2613 sendrecv
2614
2615
2616
2617
2618 false
2619
2620
2621
2622
2624
2626
2628
2630
2632
2633
2634 xcon:8977878@example.com
2635
2636
2637
2638
2639
2640
2642 3. sidebarByRefRequest/update message (Alice updates the sidebar)
2644
2648
2650 xcon-userid:Alice@example.com
2651 xcon:8971212@example.com
2652 update
2653
2654
2655
2656
2657 sidebar with Alice, Bob, Ethel and Fred
2658
2659
2660
2661
2662 main conference audio
2663
2664 audio
2665 inactive
2666
2667
2668
2669 main conference video
2670
2671 video
2672 inactive
2673
2674
2675
2676 sidebar audio
2677
2678 audio
2679 sendrecv
2680
2681
2682
2683 sidebar video
2684
2685 video
2686 sendrecv
2687
2688
2689 single-view
2690
2691
2692
2693
2694
2695
2696 false
2697
2698
2699
2700
2702
2704
2706
2707
2708
2709
2710
2711
2713 4. sidebarByRefResponse/update message (sidebar updated)
2715
2719
2721 xcon-userid:Alice@example.com
2722 xcon:8971212@example.com
2723 update
2724 200
2725 success
2726 2
2727
2728
2729
2731 Figure 22: External Sidebar Messaging Details
2733 7.3. Private Messages
2735 The case of private messages can be handled as a sidebar with just
2736 two participants, similarly to the example in Section 7.1. Unlike
2737 the previous example, rather than using audio within the sidebar,
2738 Alice could just add an additional text based media stream to the
2739 sidebar in order to convey her textual messages to Bob, while still
2740 viewing and listening to the main conference.
2742 In this scenario, Alice requests to the conferencing system the
2743 creation of a private chat room within the main conference context
2744 (presented in Figure 19) in which the involved partecipants are just
2745 Bob and herself. This can be achieved through the following CCMP
2746 transaction (Figure 23).
2748 1. Alice forwards a sidebarByValRequest/create to the Conferencing
2749 Control Server with the main conference XCON-URI in the
2750 "confObjID" parameter and the desired sidebar conference object
2751 in the "sidebarByValInfo" field. In this way, a sidebar creation
2752 using user-provided conference information is requested to the
2753 conferencing system. Please note that, unlike the previous
2754 sidebar examples, in this case a comnpletely new conference
2755 object to describe the sidebar is provided: there is no cloning
2756 involved, while the "confObjID" still enforces the parent-child
2757 relationship between the main conference and the to-be-created
2758 sidebar.
2760 2. The Conference Control Server, after checking Alice's rights and
2761 validating the conference-object carried in the request, creates
2762 the required sidebar-by-val conference and a new XCON-URI for it.
2763 Instead of cloning the main conference object, as shown in
2764 Section 7.1 and Section 7.2, the sidebar is created on the basis
2765 of the user provided conference information. However, the parent
2766 relationship between the main conference and the newly created
2767 sidebar is still mantained by the conferencing system (as a
2768 consequence of the chosen CCMP request message type - the
2769 sidebarByVal one) and it is reflected by the
2770 element in the "sidebarByValInfo" element returned in the
2771 sidebarByValResponse message. Please notice that, according to
2772 the CCMP specification, the return of the created sidebar data in
2773 this kind of "success" response is not mandatory.
2775 1. sidebarByValRequest/create message (Alice creates a private
2776 chat room between Bob and herself)
2778
2779
2783
2785 xcon-userid:Alice@example.com
2786 xcon:8977878@example.com
2787 create
2788
2789
2790
2791
2792 private textual sidebar alice - bob
2793
2794
2795
2796
2797 main conference audio
2798
2799 audio
2800 recvonly
2801
2802
2803
2804 main conference video
2805
2806 video
2807 recvonly
2808
2809
2810
2811 sidebar text
2812
2813 text
2814 sendrecv
2815
2816
2817
2818
2819
2820
2822
2824
2825
2826
2827
2828
2829
2831 2. sidebarByValResponse/create message (sidebar returned)
2833
2834
2838
2840 xcon-userid:Alice@example.com
2841 xcon:8974545@example.com
2842 create
2843 200
2844 success
2845 1
2846
2847
2848
2849
2850 private textual sidebar alice - bob
2851
2852
2853
2854
2855 main conference audio
2856
2857 audio
2858 recvonly
2859
2860
2861
2862 main conference video
2863
2864 video
2865 recvonly
2866
2867
2868
2869 sidebar text
2870
2871 text
2872 sendrecv
2873
2874
2875
2876 xcon:8977878@example.com
2877
2878
2879
2880
2881
2883
2885
2886
2887
2888
2889
2891
2893 Figure 23: Sidebar for Private Messages scenario
2895 7.4. Observing and Coaching
2897 Observing and Coaching is one of the most interesting sidebars-
2898 related scenarios. In fact, it highlights two different interactions
2899 that have to be properly coordinated.
2901 An example of observing and coaching is shown in figure Figure 25.
2902 In this example, call center agent Bob is involved in a conference
2903 with customer Carol. Since Bob is a new agent and Alice sees that he
2904 has been on the call with Carol for longer than normal, she decides
2905 to observe the call and coach Bob as necessary. Of course the
2906 conferencing system must make sure that the customer Carol is not
2907 aware of the presence of the coach Alice. This makes the use of a
2908 sidebar necessary for the success of the scenario.
2910 Consider the following as the conference document associated with the
2911 video conference involving Bob (the call agent) and Carol (the
2912 customer) (Figure 24):
2914
2915
2920
2921
2922 CUSTOMER SERVICE conference
2923
2924
2925
2926 sip:8978383@example.com
2927 conference sip uri
2928
2929
2930
2931
2932 service audio
2933 audio
2934 sendrecv
2935
2936
2937 service video
2938 video
2939 sendrecv
2940
2941 single-view
2942
2943
2944
2945
2946
2947 true
2948
2949
2950
2951 Bob - call agent
2952
2953
2954 123
2955 sendrecv
2956
2957
2958 456
2959 sendrecv
2960
2961
2962
2963
2964 Carol - customer
2965
2966
2967 123
2968 sendrecv
2969
2970
2971 456
2972 sendrecv
2973
2974
2975
2976
2977
2979 Figure 24: A call-center conference object example
2981 Alice Bob ConfS
2982 | | |
2983 |(1) sidebarByRefRequest(confUserID, |
2984 | confObjID, create) |
2985 |--------------------------------------------->|
2986 | | |
2987 | | (a) Create +---|
2988 | | sidebar-by-ref | |
2989 | | (new conf obj | |
2990 | | cloned from +-->|
2991 | | confObjID) | Sidebar now has
2992 | | | id confObjID*
2993 |(2) sidebarByRefResponse(confUserID, | (parent mapping
2994 | confObjID*,create,200,success, | conf<->sidebar)
2995 | version,sidebarByRefInfo) |
2996 |<---------------------------------------------|
2997 | | |
2998 |(3) sidebarByRefRequest(confUserID, |
2999 | confObjID*,update,sidebarByRefInfo) |
3000 |--------------------------------------------->|
3001 | | |
3002 | | (b) Update +---|
3003 | | sidebar-by-val | |
3004 | | (media, users | |
3005 | | policy, etc.) +-->|
3006 | | | Sidebar is modified:
3007 | | | unilateral sidebar
3008 | | | audio, Carol excluded
3009 | | | from the sidebar
3010 |(4) sidebarByRefResponse(confUserID, |
3011 | confObjID*, update, |
3012 | 200, success, version) |
3013 |<---------------------------------------------|
3014 | | |
3015 | | Notify (Bob |
3016 | | he's been added to |
3017 | | sidebar users) |
3018 | |<----------------------|
3019 | | |
3020 " " "
3021 " " "
3022 " " "
3024 Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
3026 1. Upon receipt of the sidbarByRefRequest/create from Alice to
3027 "create" a new sidebar conference from the confObjID received in
3028 the request, the conferencing system uses the received active
3029 conference to clone a conference reservation for the sidebar.
3030 The conferencing system also allocates a conference ID to be used
3031 for any subsequent protocol requests from any of the members of
3032 the conference. The conferencing system maintains the mapping
3033 between this conference ID and the confObjID associated with the
3034 sidebar reservation through the conference instance. The
3035 conference server sends a sidebarByRefResponse message with the
3036 new confObjID and relevant sidebarByRefInfo.
3038 2. Upon receipt of the sidebarByRefResponse message, Alice
3039 manipulates the data received in the sidebarByRefInfo in the
3040 response. Alice wants only Bob to be involved in the sidebar,
3041 thus she updates the to include only Bob and
3042 herself. Alice also wants the audio to be received by herself
3043 and Bob from the original conference, but wants any outgoing
3044 audio from herself to be restricted to the participants in the
3045 sidebar, whereas Bob's outgoing audio should go to the main
3046 conference, so that both Alice and the customer Carol hear the
3047 same audio from Bob. Alice sends a sidebarByRefRequest message
3048 with an "update" operation including the updated sidebar
3049 information.
3051 3. Upon receipt of the sidebarByRefRequest message with an "update"
3052 operation, the conferencing system ensures that Alice has the
3053 appropriate authority based on the policies associated with that
3054 specific conference object to perform the operation. In order to
3055 request the insertion of a further media stream in the sidebar
3056 (i.e. in this example an audio stream from Alice to Bob), the
3057 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label"
3059 attribute of that new entry is filled with a dummy value
3060 "AUTO_GENERATE_1", but it will contain the real server-generated
3061 media stream identifier when the media stream is effectively
3062 allocated on the server side. Similarly, the mandatory "id"
3063 attribute in element referring to the new sidebar audio
3064 stream under both Alice's and Bob's contains a
3065 wildcard value, respectively "AUTO_GENERATE_2" and
3066 "AUTO_GENERATE_3": those values will be replaced with the
3067 appropriated server-generated identifiers upon the creation of
3068 the referred media stream. We are assuming the conferencing
3069 control server is able to recognize those dummy values as place-
3070 holders.
3072 4. After validating the data, the conference server sends a
3073 sidebarByRefResponse message. Based upon the contact information
3074 provided for Bob by Alice, the call signaling to add Bob to the
3075 sidebar with the appropriate media characteristics is instigated
3076 through the Focus. Bob is notified of his addition to the
3077 sidebar via the conference notification service, thus he is aware
3078 that Alice, the supervisor, is available for coaching him through
3079 this call.
3081 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
3083
3084
3087
3089 xcon-userid:Alice@example.com
3090 xcon:8978383@example.com
3091 create
3092
3093
3094
3096 2. sidebarByRefResponse/create message (sidebar created)
3098
3099
3103
3105 xcon-userid:alice@example.com
3106 xcon:8971313@example.com
3107 create
3108 200
3109 Success
3110 1
3111
3112
3113
3114
3115 SIDEBAR CONFERENCE registered by alice
3116
3117
3118
3119
3120 main conference audio
3121
3122 audio
3123 sendrecv
3124
3125
3126
3127 main conference video
3128
3129 video
3130 sendrecv
3131
3132
3133
3134 xcon:8971313@example.com
3135
3136
3137
3138 false
3139
3140
3141
3142
3144
3146
3148
3149
3150
3151
3152
3153
3155 3. sidebarByRefRequest/update message (Alice introduces unilateral
3156 sidebar audio and excludes Carol from the sidebar)
3158
3162
3164 xcon-userid:alice@example.com
3165 xcon:8971313@example.com
3166 update
3167
3168
3169
3170
3171 Coaching sidebar Alice and Bob
3172
3173
3174
3175
3176 Alice-to-Bob audio
3177
3178 audio
3179 sendrecv
3180
3181
3182
3183
3184 false
3185
3186
3187
3188
3189
3190 AUTO_GENERATE_1
3191 sendonly
3192
3193
3194
3195
3196
3197
3198 AUTO_GENERATE_1
3199 recvonly
3200
3201
3202
3203
3204
3206
3208
3209
3210
3211
3212
3213
3215 4. sidebarByRefRequest/update message (updates accepted)
3217
3218
3222
3224 xcon-userid:alice@example.com
3225 xcon:8971313@example.com
3226 update
3227 200
3228 success
3229 2
3230
3231
3232
3234 Figure 26: Coaching and Observing Messaging details
3236 8. Removing Participants and Deleting Conferences
3238 The following scenarios detail the basic operations associated with
3239 removing participants from conferences and entirely deleting
3240 conferences. The examples assume that a conference has already been
3241 correctly established, with media, if applicable, per one of the
3242 examples in Section 5.
3244 8.1. Removing a Party
3246 Figure 27 provides an example of a client, "Alice", removing another
3247 participant, "Bob", from a conference. This example assumes an
3248 established conference with Alice, Bob, "Claire" and "Duck". In this
3249 example, Alice wants to remove Bob from the conference so that the
3250 group can continue in the same conference without Bob's
3251 participation.
3253 Alice Bob Claire ConfS
3254 | | | |
3255 |(1) userRequest(confUserID,| |
3256 | confObjID, delete,| |
3257 | userInfo) | |
3258 |-------------------------------------->|
3259 | | | |
3260 | | | (a) Focus |
3261 | | | tears down|
3262 | | | signaling |
3263 | | | to Bob |
3264 | |<----------------------|
3265 | | |
3266 | | (b)Deletes+---|
3267 | | | Bob | |
3268 | | | as a | |
3269 | | | user +-->|
3270 | | | in |
3271 | | | confObj |
3272 | | | |
3273 |(2) userResponse(confUserID,confObjID, |
3274 | delete,200,success,version) |
3275 |<--------------------------------------|
3276 | | | |
3277 | | | |
3278 | | | (c) Notify|
3279 | | | ("Bob just|
3280 | | | left") |
3281 | | |<----------|
3282 | | | |
3283 ' ' ' '
3284 ' ' ' '
3285 ' ' ' '
3287 Figure 27: Client Manipulation of Conference - Remove a party
3289 1. Alice sends a userRequest message, with a "delete" operation.
3290 The conference server ensures that Alice has the appropriate
3291 authority based on the policies associated with that specific
3292 conference object to perform the operation.
3294 2. Based upon the contact and media information in the conference
3295 object for Bob in the "userInfo" element, the conferencing system
3296 starts the process to remove Bob (e.g., the call signaling to
3297 remove Bob from the conference is instigated through the Focus).
3298 The conference server updates the data in the conference object,
3299 thus removing Bob from the list. After updating the
3300 data, the conference server sends a userResponse message to
3301 Alice. Depending upon the policies, other participants (e.g.
3302 "Claire") may be notified of the removal of Bob from the
3303 conference via the Conference Notification Service.
3305 1. userRequest/delete message (Alice deletes Bob):
3307
3308
3312
3314 xcon-userid:Alice@example.com
3315 xcon:8977794@example.com
3316 delete
3317
3318
3319
3320
3321
3323 2. userResponse/delete message (Bob has been deleted)
3325
3326
3330
3332 xcon-userid:Alice@example.com
3333 xcon:8977794@example.com
3334 delete
3335 200
3336 success
3337 17
3338
3339
3340
3342 Figure 28: Removing a Participant Messaging Details
3344 8.2. Deleting a Conference
3346 In this section, an example of a successful conference deletion is
3347 provided (Figure 29).
3349 Alice ConfS
3350 | |
3351 |(1)confRequest(confUserID, |
3352 | confObjID, delete) |
3353 |------------------------------>|
3354 | (a)Delete +---|
3355 | Conf | |
3356 | Object | |
3357 | +-->|
3358 | |--+ (b) MS
3359 | | | removes related
3360 | | | mixer instances and
3361 | |<-+ their participants
3362 | | (SIP signaling as well)
3363 | |
3364 |(2)confResponse(confUserID, |
3365 | confObjID,delete,200, |
3366 | success) |
3367 | |
3368 |<------------------------------|
3369 | |
3371 Figure 29: Deleting a conference
3373 1. The conferencing system client "Alice" sends a confRequest
3374 message with a "delete" operation to be performed on the
3375 conference identified by the XCON-URI carried in the "confObjID"
3376 parameter. The conference server, on the basis of the
3377 "confUserID" included in the receipt request, ensures that Alice
3378 has the appropriate authority to fulfill the operation.
3380 2. After validating Alice's rights, the conferencing server
3381 instigates the process to delete the conference object,
3382 disconnetting participants and removing associated resources such
3383 as mixer instances. Then, the conference server returns a
3384 confResponse message to Alice with "200" as "response-code" and
3385 the deleted conference XCON-URI in the "confObjID" field.
3387 1. confRequest/delete message (Alice deletes a conference)
3389
3390
3394
3396 xcon-userid:Alice@example.com
3397 xcon:8977794@example.com
3398 delete
3399
3400
3401
3403 2. confResponse/delete message (200, "success")
3405
3406
3410
3412 xcon-userid:Alice@example.com
3413 xcon:8977794@example.com
3414 delete
3415 200
3416 success
3417
3418
3419
3421 Figure 30: Deleting a Conference Messaging Details
3423 9. IANA Considerations
3425 This document has no IANA considerations.
3427 10. Security Considerations
3429 The security considerations applicable to the implementation of these
3430 call flows are documented in the XCON Framework, with additional
3431 security considerations documented in the CCMP document. Statements
3432 with regards to the necessary security are discussed in particular
3433 flows, however, this is for informational purposes only. The
3434 implementor is encouraged to carefully consider the security
3435 requirements in the normative documents.
3437 11. Change Summary
3439 NOTE TO THE RFC-EDITOR: Please remove this section prior to
3440 publication as an RFC.
3442 The following are the major changes between the 02 and the 03
3443 versions of the draft:
3445 o updated the call flows in order to take into account the changes
3446 on CCMP;
3448 o added a completely new introductory section, addressing the
3449 protocol in general, the data model constraints, transport-related
3450 information, and notifications in a practical way;
3452 o reorganized the chapters, grouping user-related scenarios in an
3453 users section, and doing the same for sidebars;
3455 o added more verbose text to almost every section of the document;
3457 The following are the major changes between the 01 and the 02
3458 versions of the draft:
3460 o updated the call flows in order to take into account the new
3461 versioning mechanism of the CCMP;
3463 o clarified, per agreement in Stockholm, that cloning from a
3464 blueprint does not need a cloning-parent to be made available in
3465 the response;
3467 o clarified that BFCP and CCMP-based media control are neither in
3468 conflict nor one the wrapper of the other; they act at different
3469 levels, and when both are involved, it is required that both grant
3470 a resource before it can be used by an interested participant;
3472 o changed all the domains involved in the flows to make them
3473 compliant with [RFC2606];
3475 o clarified that a successful creation of a new conference object
3476 may or may not contain the whole confInfo object in the response;
3477 in case it doesn't, a retrieve of the updated object can be
3478 achieved by issuing a confRequest/retrieve;
3480 o clarified that the scenario in Section 6.3 only involves CCMP in
3481 adding the user to a conference; this includes requiring the use
3482 of a password only in adding the user to the conference object;
3483 the actual request for PIN/Password when joining thw conference is
3484 handled by means of out-of-band mechanisms (in this case at the
3485 media level, with the help of the MEDIACTRL framework);
3487 o added and corrected Sidebars-related scenarios;
3489 o added flows for some previously missing scenarios: Private
3490 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a
3491 Conference;
3493 o
3495 The following are the major changes between the 00 and the 01
3496 versions of the draft:
3498 o Updates to reflect change of CCMP to HTTP transport model.
3500 The following are the major changes between the individual 01 version
3501 to the WG 00:
3503 o Updates to reflect most recent version of CCMP, including
3504 parameter names, etc.
3506 o Added protocol details to many of the examples.
3508 o Editorial: Simplifying intro, terms, etc.
3510 12. Acknowledgements
3512 The detailed content for this document is derived from the prototype
3513 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and
3514 their colleagues at the University of Napoli.
3516 13. References
3518 13.1. Normative References
3520 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
3521 Centralized Conferencing", RFC 5239, June 2008.
3523 [I-D.ietf-xcon-ccmp]
3524 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
3525 "Centralized Conferencing Manipulation Protocol",
3526 draft-ietf-xcon-ccmp-11 (work in progress), October 2010.
3528 13.2. Informative References
3530 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
3531 Names", BCP 32, RFC 2606, June 1999.
3533 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
3534 A., Peterson, J., Sparks, R., Handley, M., and E.
3535 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
3536 June 2002.
3538 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
3539 (SIP) Call Control - Conferencing for User Agents",
3540 BCP 119, RFC 4579, August 2006.
3542 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
3543 RFC 4597, August 2006.
3545 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
3546 Control Protocol (BFCP)", RFC 4582, November 2006.
3548 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
3549 Initiation Protocol (SIP) Event Package for Conference
3550 State", RFC 4575, August 2006.
3552 [I-D.ietf-xcon-event-package]
3553 Camarillo, G., Srinivasan, S., Even, R., and J.
3554 Urpalainen, "Conference Event Package Data Format
3555 Extension for Centralized Conferencing (XCON)",
3556 draft-ietf-xcon-event-package-01 (work in progress),
3557 September 2008.
3559 [I-D.ietf-xcon-common-data-model]
3560 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
3561 "Conference Information Data Model for Centralized
3562 Conferencing (XCON)", draft-ietf-xcon-common-data-model-23
3563 (work in progress), February 2011.
3565 [I-D.ietf-mediactrl-call-flows]
3566 Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
3567 "Media Control Channel Framework (CFW) Call Flow
3568 Examples", draft-ietf-mediactrl-call-flows-05 (work in
3569 progress), October 2010.
3571 [RFC5567] Melanchuk, T., "An Architectural Framework for Media
3572 Server Control", RFC 5567, June 2009.
3574 [I-D.ietf-mediactrl-mixer-control-package]
3575 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
3576 Control Package for the Media Control Channel Framework",
3577 draft-ietf-mediactrl-mixer-control-package-14 (work in
3578 progress), January 2011.
3580 Authors' Addresses
3582 Mary Barnes
3583 Polycom
3584 TX
3585 US
3587 Email: mary.ietf.barnes@gmail.com
3589 Lorenzo Miniero
3590 Meetecho
3591 Via Carlo Poerio 89/a
3592 Napoli 80121
3593 Italy
3595 Email: lorenzo@meetecho.com
3596 Roberta Presta
3597 University of Napoli
3598 Via Claudio 21
3599 Napoli 80125
3600 Italy
3602 Email: roberta.presta@unina.it
3604 Simon Pietro Romano
3605 University of Napoli
3606 Via Claudio 21
3607 Napoli 80125
3608 Italy
3610 Email: spromano@unina.it