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