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