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