idnits 2.17.1 draft-ietf-xcon-examples-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-xcon-event-package' is defined on line 2808, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-common-data-model' is defined on line 2815, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-02 -- 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-13 == Outdated reference: A later version (-13) exists of draft-ietf-mediactrl-call-flows-00 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-07 == Outdated reference: A later version (-08) exists of draft-boulton-xcon-session-chat-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Informational C. Boulton 5 Expires: January 14, 2010 NS-Technologies 6 L. Miniero 7 Meetecho 8 R. Presta 9 S P. Romano 10 University of Napoli 11 July 13, 2009 13 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 14 draft-ietf-xcon-examples-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 14, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document provides detailed call flows for the scenarios 53 documented in the Centralized Conferencing (XCON) Framework and the 54 XCON Scenarios. The call flows document the use of the interface 55 between a conference control client and a conference control server 56 using the Centralized Conferencing Manipulation Protocol (CCMP). The 57 objective is to provide a base reference for both protocol 58 researchers and developers. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 6 68 5.2. Basic Conference Creation for a specific instance of 69 Conference Information . . . . . . . . . . . . . . . . . . 11 70 5.3. Basic Conference Creation - Cloning an existing 71 Conference . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.4. Conference Creation using Blueprints . . . . . . . . . . . 18 73 6. General Conference scenarios and examples . . . . . . . . . . 25 74 6.1. Conference Announcements and Recordings . . . . . . . . . 25 75 6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 28 76 6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 28 77 6.4. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 31 78 6.5. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 36 79 6.6. External Sidebar . . . . . . . . . . . . . . . . . . . . . 45 80 6.7. Floor control using sidebars . . . . . . . . . . . . . . . 51 81 6.8. Whispering or Private Messages . . . . . . . . . . . . . . 52 82 6.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 53 83 7. Removing participants and deleting conferences . . . . . . . . 54 84 7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 55 85 7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 56 86 8. Additional Conference Scenarios and Examples . . . . . . . . . 57 87 8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 88 8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 58 89 8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 62 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 92 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 65 93 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66 96 13.2. Informative References . . . . . . . . . . . . . . . . . . 66 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 100 1. Introduction 102 This document provides detailed call flows for the scenarios 103 documented in the Framework for Centralized Conferencing (XCON 104 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON 105 scenarios describe a broad range of use cases taking advantage of the 106 advanced conferencing capabilities provided by a system realization 107 of the XCON framework. The call flows document the use of the 108 interface between a conference control client and a conference 109 control server using the Centralized Conferencing Manipulation 110 Protocol (CCMP)[I-D.ietf-xcon-ccmp]. 112 Due to the broad range of functionality provided by the XCON 113 Framework and the flexibility of the CCMP messaging, these call flows 114 should not be considered inclusive of all the functionality that can 115 provided by the XCON Framework and protocol implementations. These 116 flows represent a sample to provide an overview of the feature rich 117 capabilities of the XCON framework and CCMP messaging for protocol 118 developers, software developers and researchers. 120 2. Conventions 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 126 levels for compliant implementations. In this document, these key 127 words are used when describing normative functionality based on the 128 XCON Framework and CCMP. 130 Note that due to RFC formatting conventions, this document often 131 splits message details whose content would exceed 72 characters. A 132 backslash character marks where this line folding has taken place. 133 This backslash and its trailing CRLF and whitespace would not appear 134 in the actual protocol contents. 136 3. Terminology 138 This document uses the same terminology as found in the referenced 139 documents, with the following terms and abbreviations used in the 140 call flows. Also, note that the term "call flows" is used in a very 141 generic sense in this document since the media is not limited to 142 voice. The calls supported by the XCON framework and CCMP can 143 consist of media such as text, voice and video, including multiple 144 media types in a single active conference. 146 Conferencing and Media Client Client (CMCC): As defined in the XCON 147 Framework. In the flows in this document, the CMCC is logically 148 equivalent to the use of UAC as the client notation in the media 149 control call flows [I-D.ietf-mediactrl-call-flows]. 151 Conferencing Server (ConfS): As defined in the XCON Framework. In 152 this document, the conferencing server is used interchangeably 153 with the term Application Server (AS) as used in the Media Control 154 Architectural Framework [RFC5567]. However, these need not be the 155 same entities in an implementation. 157 Media Server (MS): As defined in the Media Control Architectural 158 Framework [RFC5567]. 160 4. Overview 162 This document provides a sampling of detailed call flows that can be 163 implemented based on a system realization of [RFC5239] and 164 implementation of [I-D.ietf-xcon-ccmp]. This is intended to be a 165 simple guide on the use of the conference control protocol between 166 the Conference Server and the Conference Control Client. The 167 objective is to provide an informational base reference for protocol 168 developers, software developers and researchers. 170 This document focuses on the interaction between the Conference (and 171 Media) Control Client and the Conferencing system, specifically the 172 Conference Server. The scenarios are based on those described in the 173 XCON framework, many of which are based on the advanced conferencing 174 capabilities described in the XCON scenarios. Additional scenarios 175 have been added to provide examples of other real life scenarios that 176 are anticipated to be supported by the framework. With the exception 177 of an initial example with media control messaging, the examples do 178 not include the details for the media control 179 [I-D.ietf-mediactrl-mixer-control-package], call signaling or binary 180 floor control [RFC4582] protocols. This document references the 181 scenarios in the Media Control call flows 182 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing 183 [RFC4579] and binary floor control protocol documents. 185 5. Conference Creation 187 This section provides the details associated with the various ways in 188 which a conference can be created using CCMP and the XCON framework 189 constructs. As previously mentioned the details of the media 190 control, call signaling and floor control protocols, where 191 applicable, are annotated in the flows without showing all the 192 details. However, for clarification purposes, the first example 193 Section 5.1 provides the details of the media control messaging along 194 with an example of the standard annotation used throughout the 195 remainder of this document. In subsequent flows, only this 196 annotation (identified by lower case letters) is included and the 197 reader is encouraged to refer to the call flows in the relevant 198 documents for details for the other protocols. The annotations for 199 the call signaling are on the left side of the conferencing server 200 vertical bar and those for the media control messaging are on the 201 right side. 203 5.1. Basic Conference Creation 205 The simplest manner in which a conference can be created is 206 accomplished by the client sending a "confRequest" message with the 207 "create" operation as the only parameter to the conference server, 208 together with the "confUserID" associated with the requesting client 209 itself. This results in the creation of a default conference, with 210 an XCON-URI in the form of the "confObjID" parameter, the XCON-UserID 211 in the form of the "confUserID" parameter (the same already present 212 in the request) and the data for the conference object in the 213 "confInfo" parameter all returned in the "confResponse" message. 214 According to the implementation of the framework, this example may 215 also add the user that invoked the conference upon creation to the 216 conference object (e.g., "method" attribute in the "target" element 217 of "allowed-users-list" may be set to "dial out" for this client 218 based on the particular conferencing systems default). This is 219 exactly the case depicted in the figure, which is presented to enrich 220 the scenario. Note, that depending upon the conferencing system, 221 this default conference could be specific to the client requesting 222 the conference and thus may be different for the initiator than other 223 participants (e.g., IVR interactions in this case which are not 224 shown). 226 The specific data for the conference object is returned in the 227 "confResponse" message in the "confInfo" parameter. This allows the 228 client (with the appropriate authorization) to manipulate this data 229 and add additional participants to the conference, as well as change 230 the data during the conference. In addition, the client may 231 distribute the conferencing information to other participants 232 allowing them to join, the details of which are provided in 233 additional flows. 235 Clients that are not XCON-aware may join the conference using a 236 specific signaling interface such as SIP [RFC3261], using the 237 signaling interface to the conference focus as described in 239 [RFC4579]. However, these details are not shown in the message 240 flows. The message flows in this document identity the point in the 241 message flows at which this signaling occurs via the lower case 242 letter items (i.e., (a)...(x)) along with the appropriate text for 243 the processing done by the conferencing server. 245 CMCC1 CMCC2 CMCCx CONFS MS 246 | | | | | 247 |(1)confRequest(create, confUserID) | | 248 |-------------------------------------->| | 249 | | (a)Create +---| | 250 | | |Conf | | | 251 | | |Object | | | 252 | | |& IDs +-->| | 253 | | | | A1. CONTROL | 254 | | | |+++++++++++>>| 255 | | | |(create conf)|--+ (b) 256 | | | | | | create 257 | | | | | | conf and 258 | | | | A2. 200 OK |<-+ its ID 259 | | | |<<+++++++++++| 260 | | | |(confid=Y) | 261 |(2)confResponse(create, success, | | 262 | confObjID, confUserID | | 263 | confInfo) | | | 264 |<--------------------------------------| | 265 | | | | | 266 | | (c) Focus +---| | 267 | | sets up | | | 268 | | signaling | | | 269 | | to CMCC1 +-->| | 270 | | | | | 271 | | | | B1. CONTROL | 272 | | | |+++++++++++>>| 273 | | | | (join CMCC1 | 274 | | | | <->confY) | 275 | | | | | 276 | | | | |--+(d) join 277 | | | | | | CMCC1 & 278 | | | | B2.200 OK |<-+ conf Y 279 | | | |<<+++++++++++| 280 | | | | | 281 |<<#################################################>>| 282 | Now the CMCC1 is mixed in the conference | 283 |<<#################################################>>| 284 | | | | | 285 |******CMCC1 may then manipulate conference data *****| 286 |****** and add addt'l users, etc. | *****| 287 ' ' ' ' ' 288 ' ' ' ' ' 289 ' ' ' ' ' 290 Figure 1: Create Basic Conference - Complete flow 292 "Alice" "Bob" 293 CMCC1 CMCC2 CMCCx CONFS 294 | | | | 295 |(1)confRequest(create, confUserID) | 296 |-------------------------------------->| 297 | | | | 298 | | (a)Create +---| 299 | | |Conf | | 300 | | |Object | | 301 | | |& IDs +-->| 302 | | | |--+ (b) MS 303 | | | | | creates 304 | | | | | conf and 305 | | | |<-+ its ID 306 | | | | (confid=Y) 307 |(2)confResponse(create, success | 308 | confObjID, confUserID | 309 | confInfo) | | 310 |<--------------------------------------| 311 | | | | 312 | | | | 313 | | (c) Focus +---| 314 | | sets up | | 315 | | signaling | | 316 | | to CMCC1 +-->| 317 | | | | 318 | | | |--+(d) MS joins 319 | | | | | CMCC1 & 320 | | | |<-+ conf Y 321 |<<###################################>>| 322 | CMCC1 is mixed in the conference | 323 |<<###################################>>| 324 | | | | 325 |**CMCC1 then manipulates conference****| 326 |** data and add addt'l users, etc. ***| 327 ' ' ' ' 328 ' ' ' ' 329 ' ' ' ' 330 - 332 Figure 2: Create Basic Conference - Annotated Flow 334 1. confRequest message: 336 337 341 344 xcon-userid:alice@confSystem.com 345 create 346 347 349 2. confResponse message: 351 352 356 359 xcon:8977794@confSystem.com 360 xcon-userid:alice@confSystem.com 361 success 362 363 364 365 366 Default conference initiated by Alice 367 368 369 370 371 xcon:8977794@confSystem.com 372 373 374 Conference XCON-URI 375 376 377 378 10 379 380 381 audio 382 383 384 385 386 allow 387 388 390 391 392 393 394 395 397 Figure 3: Create Basic Conference (Annotated) Detailed Messaging 399 5.2. Basic Conference Creation for a specific instance of Conference 400 Information 402 A conference can also be created by the client sending a 403 "confRequest" message with the "create" operation, along with the 404 desired data in the form of the "confInfo" parameter for the 405 conference to be created. The request, as is the case of all CCMP 406 requests, also includes the "confUserID" of the requesting entity. 407 If the conferencing system can support that specific type of 408 conference (capabilities, etc.), then the request results in the 409 creation of a conference. In this success case, an XCON-URI in the 410 form of the "confObjID" parameter and the XCON-UserID in the form of 411 the "confUserID" parameter (again, the same as the requesting entity) 412 are returned in the "confResponse" message. The "confInfo" is not 413 returned unless changes have been made, in which case the 414 "responseCode" is "modified". 416 This example also activates the conference upon creation (i.e., 417 "method" attribute is set to "dial out" for this client based on the 418 particular conferencing systems default). Just as before, this is 419 not to be considered mandatory, since it depends on the 420 implementation choices of the framework. Note, that depending upon 421 the conferencing system, this default conference could be specific to 422 the client requesting the conference and thus may be different for 423 the initiator than other participants (e.g., IVR interactions in this 424 case which are not shown). 426 "Alice" "Bob" "Carol" CONFS 427 | | | | 428 |(1)confRequest | | | 429 | (create, confUserID, confInfo) | 430 |-------------------------------------->| 431 | | | | 432 | | (a)Create +---| 433 | | |Conf | | 434 | | |Object | | 435 | | |& IDs +-->| 436 | | | |--+ (b) MS 437 | | | | | creates 438 | | | | | conf and 439 | | | |<-+ its ID 440 | | | | (confid=Y) 441 |(2) confResponse | | 442 | (create, success, confObjID | 443 | confUserID)| | | 444 |<--------------------------------------| 445 | | | | 446 | | (c) Focus +---| 447 | | sets up | | 448 | | signaling | | 449 | | to Alice +-->| 450 | | | | 451 | | | |--+(d) MS joins 452 | | | | | Alice & 453 | | | |<-+ conf Y 454 | | | | 455 | | | | 456 |<<###################################>>| 457 | Alice is mixed in the conference | 458 |<<###################################>>| 459 | | | | 460 | | (e)Focus +---| 461 | | sets up | | 462 | | signaling | | 463 | | to Bob | | 464 | | | +-->| 465 | | | | 466 | | | |--+(f)MS joins 467 | | | | | Bob & 468 | | | |<-+ conf Y 469 | | | | 470 | |<<###################>>| 471 | | Bob is mixed too | 472 | |<<###################>>| 473 | | | | 474 | | (g )Focus +---| 475 | | sets up | | 476 | | signaling | | 477 | | to Carol | | 478 | | CMCCx +-->| 479 | | | | 480 | | | |--+(h)MS joins 481 | | | | | CMCCx & 482 | | | |<-+ conf Y 483 | | | | 484 | | |<<#######>>| 485 | | |Carol mixed| 486 | | |<<#######>>| 487 | | | | 488 | | | | 489 | | | | 490 |<***All parties connected to conf Y***>| 491 | | | | 492 | | | | 493 " " " " 494 " " " " 495 " " " " 497 Figure 4: Create Basic Conference from user provided conference-info 499 1. confRequest message: 501 502 506 509 xcon-userid:Alice 510 create 511 512 513 514 515 Dial-out conference initiated by Alice 516 517 518 519 520 xcon:8977794@confSystem.com 521 522 523 Conference XCON-URI 524 525 526 527 10 528 529 530 audio 531 532 533 534 535 allow 536 537 539 541 543 544 545 546 547 548 550 2. confResponse message: 552 553 557 560 xcon:6845432@confSystem.com 561 xcon-userid:Alice 562 success 563 564 565 Figure 5: Create Basic Conference Detailed Messaging 567 5.3. Basic Conference Creation - Cloning an existing Conference 569 A client can also create another conference by cloning an existing 570 conference, such as an active conference or conference reseravation. 571 In this example, the client sends a "confRequest" message with the 572 "create" operation, along with the "confUserID" and a specific 573 "confObjID", from which a new conference is to be created by cloning 574 an existing conference. 576 An example of how a client can create a conference based on a 577 blueprint is provided in Section 5.4. The manner by which a client 578 in this example might learn about a conference reservation or active 579 conferences is similar to the first step in the blueprint example, 580 with the exception of specifying querying for different types of 581 conference objects supported by the specific conferencing system. 582 For example, in this example, the client clones a conference 583 reservation (i.e., an inactive conference). 585 If the conferencing system can support a new instance of the specific 586 type of conference(capabilities, etc.), then the request results in 587 the creation of a conference, with an XCON-URI in the form of a new 588 value in the "confObjID" parameter to reflect the newly cloned 589 conference object returned in the "confResponse" message. The 590 "confInfo" is not returned unless there had been changes, in which 591 case the "responseCode" is "modified". 593 "Alice" ConfS 594 | | 595 |(1) confRequest (create, | 596 | confObjID, confUserId) | 597 |------------------------------>| 598 | (a)Create +---| 599 | Conf | | 600 | Object | | 601 | & IDs +-->| 602 | |--+ (b) MS 603 | | | creates 604 | | | conf and 605 | |<-+ its ID 606 | | (confid=Y) 607 | | 608 |(2) confResponse | 609 | ( create, success, | 610 | confObjID*, confUserID) | 611 |<------------------------------| 612 | | 614 Figure 6: Create Basic Conference - Clone 616 1. "Alice" sends a confRequest message to clone a conference based 617 on an existing conference reservation. "Alice" indicates this 618 conference should be cloned from the specified parent conference 619 represented by the "confObjID" in the request. 621 2. Upon receipt of the confRequest message containing a "create" 622 operation and "confObjID", the conferencing system ensures that 623 the "confObjID" received is valid. The conferencing system 624 determines the appropriate read/write access of any users to be 625 added to a conference based on this "confObjID" (using 626 membership, roles, etc.). The conferencing system uses the 627 received "confObjID" to clone a conference reservation. The 628 conferencing system also reserves or allocates a new "confObjID" 629 (called "confObjID*" in Figure 6) to be used for the cloned 630 conference object. This new identifier is of course different 631 from the one associated with the conference to be cloned, since 632 it represents a different conference object. Any subsequent 633 protocol requests from any of the members of the conference must 634 address this new identifier. The conferencing system maintains 635 the mapping between this conference ID and the parent conference 636 object ID associated with the reservation through the conference 637 instance, and this mapping is explicitly addressed through the 638 "cloning-parent" element of the "conference-description" in the 639 new conference object. 641 1. confRequest message: 643 644 648 651 xcon:6845432@confSystem.com 652 xcon-userid:Alice 653 create 654 655 657 2. confResponse message: 659 660 664 667 xcon:8977794@confSystem.com 668 xcon-userid:Alice 669 create 670 success 672 673 674 675 676 New conference by Alice cloned from 6845432 677 678 679 xcon:6845432@confSystem.com 680 681 682 683 684 xcon:8977794@confSystem.com 685 686 687 conference xcon-uri 688 689 690 8601 691 692 693 694 10 695 696 697 audio 698 699 700 701 702 allow 703 704 705 706 confirm 707 708 709 710 711 712 713 714 716 Figure 7: Create Basic Conference (Clone) Detailed Messaging 718 5.4. Conference Creation using Blueprints 720 Figure 8 provides an example of one client "Alice" determining the 721 conference blueprints available for a particular conferencing system 722 and creating a conference based on the desired blueprint. 724 CMCC "Alice" ConfS 725 | | 726 | (1) blueprintsRequest | 727 | (confUserID) | 728 |------------------------------>| 729 | | 730 | (2) blueprintsResponse | 731 | (confUserID, success, | 732 | blueprintsInfo) | 733 |<------------------------------| 734 | | 735 |--+ | 736 | | choose preferred | 737 | | blueprint from the | 738 | | list (blueprintName) | 739 |<-+ | 740 | | 741 | (3) blueprintRequest | 742 | (retrieve, confObjID, | 743 | confUserID) | 744 |------------------------------>| 745 | | 746 | (4) blueprintResponse | 747 | (success, confObjID,| 748 | confUserID,confInfo)| 749 |<------------------------------| 750 | | 751 | (5) confRequest (create, | 752 | confobjID) | 753 |------------------------------>| 754 | | 755 | (a)Create +---| 756 | Conf | | 757 | Object | | 758 | & IDs +-->| 759 | |--+ (b) MS 760 | | | creates 761 | | | conf and 762 | |<-+ its ID 763 | | (confid=Y) 764 |(6) confResponse | 765 | (create, success, | 766 | confObjID*, confUserID) | 767 |<------------------------------| 768 | | 769 | | 770 | | 771 . . 772 . . 774 Figure 8: Client Creation of Conference using Blueprints 776 1. "Alice" first sends a "blueprintsRequest" message to the 777 conferencing system identified by the conference server discovery 778 process. Upon receipt of the "blueprintsRequest", the 779 conferencing system would first authenticate "Alice" and then 780 ensure that "Alice" has the appropriate authority based on system 781 policies to receive any blueprints supported by that system. 783 2. Any blueprint that "Alice" is authorized to use are returned in a 784 "blueprintsResponse" message in the "blueprintsInfo" attribute. 786 3. Upon receipt of the "blueprintsResponse" containing the 787 blueprints, "Alice" determines which blueprint to use for the 788 conference to be created. "Alice" sends a "blueprintRequest" 789 message to get the specific blueprint as identified by the 790 "confObjID". 792 4. The conferencing system returns the "confInfo" associated with 793 the specific blueprint as identified by the 'confObjID' in the 794 "blueprintResponse" message. 796 5. "Alice" then sends a "confRequest" with a "create" operation to 797 the conferencing system to create a conference reservation, 798 including the appropriate "blueprintName" and associated 799 "confObjID". 801 6. Upon receipt of the "confRequest" message with a "create" 802 operation, the conferencing system uses the received blueprint to 803 clone a conference, allocating a new "confObjID" (again called 804 "confObjID* in the example). The conferencing server then sends 805 a "confResponse" message including the new "confObjID*" 806 associated with the newly created conference instance. Upon 807 receipt of the "confResponse" message, "Alice" can now add other 808 users to the conference . 810 [Editors' Note: unlike what happened when cloning an existing 811 conference as presented in the previous subsection, no "cloning- 812 parent" is set in the response to the cloning of a blueprint. Is 813 this a desired behaviour? Or is this implementation specific? 814 Should the Data Model clarify the behaviour for such an event?] 816 1. blueprintsRequest message: 818 819 822 824 xcon-userid:Alice 825 826 828 2. blueprintsResponse message: 830 831 835 838 xcon-userid:Alice 839 success 840 841 842 843 xcon:AudioRoom@confSystem.com 844 AudioRoom 845 Simple Room: 846 conference room with public access, 847 where only audio is available, more users 848 can talk at the same time 849 and the requests for the AudioFloor 850 are automatically accepted. 851 852 853 854 xcon:VideoRoom@confSystem.com 855 VideoRoom 856 Video Room: 857 conference room with public access, 858 where both audio and video are available, 859 8 users can talk and be seen at the same time, 860 and the floor requests are automatically accepted. 861 862 863 864 xcon:AudioConference1@confSystem.com 865 AudioConference1 866 Public Audio Conference: 867 conference with public access, 868 where only audio is available, 869 only one user can talk at the same time, 870 and the requests for the AudioFloor MUST 871 be accepted by a Chair. 872 873 874 875 xcon:VideoConference1@confSystem.com 876 VideoConference1 877 Public Video Conference: conference 878 where both audio and video are available, 879 only one user can talk 880 881 882 883 xcon:AudioConference2@confSystem.com 884 AudioConference2 885 Basic Audio Conference: 886 conference with private access, 887 where only audio is available, 888 only one user can talk at the same time, 889 and the requests for the AudioFloor MUST 890 be accepted by a Chair. 891 892 893 894 895 896 898 3. blueprintRequest message: 900 901 905 907 xcon:AudioRoom@confSystem.com 908 xcon-userid:Alice 909 retrieve 910 911 912 914 4. blueprintResponse message: 916 917 921 923 retrieve 924 xcon:AudioRoom@confSystem.com 925 xcon-userid:Alice 926 success 927 928 929 930 AudioRoom 931 2 932 933 934 audio 935 936 937 938 939 allow 940 941 942 confirm 943 944 945 946 947 948 949 950 951 953 5. confRequest message: 955 956 960 964 xcon:AudioRoom@confSystem.com 965 xcon-userid:Alice 966 create 967 968 969 971 6. confResponse message: 973 974 978 981 xcon:8977794@confSystem.com 982 xcon-userid:Alice 983 create 984 success 985 986 987 988 989 New conference by Alice cloned from AudioRoom 990 991 992 993 994 xcon:8977794@confSystem.com 995 996 997 conference xcon-uri 998 999 1000 8601 1001 1002 1003 1004 10 1005 1006 1007 audio 1008 1009 1010 1011 1012 allow 1013 1014 1015 1016 confirm 1017 1018 1019 1020 1021 1022 1023 1024 1026 Figure 9: Create Conference (Blueprint) Detailed Messaging 1028 6. General Conference scenarios and examples 1030 The following scenarios are based on those documented in the XCON 1031 framework. The examples assume that a conference has already been 1032 correctly established, with media, if applicable, per one of the 1033 examples in Section 5. 1035 6.1. Conference Announcements and Recordings 1037 In this example, as shown in Figure 10 "Alice" is joining "Bob"'s 1038 conference that requires that she first enter a pass code. After 1039 successfully entering the passcode, an announcement prompts "Alice to 1040 speak her name so it can be recorded. When "Alice" is added to the 1041 active conference, the recording is played back to all the existing 1042 participants. A very similar example is presented in Figure 33 of 1043 [I-D.ietf-mediactrl-call-flows]. 1045 CCMC "Alice" ConfS MS 1046 | | | 1047 |(1)userRequest (create, | | 1048 | confObjID, userInfo) | | 1049 |--------------------------->| | 1050 | |--+ Alice is | 1051 | | | new in the | 1052 | |<-+ system (create | 1053 | | confUserID) | 1054 | ConfS handles +--| | 1055 | SIP signaling | | | 1056 | (Alice<->ConfS<->MS) +->| | 1057 | | | 1058 | |--+ A password is | 1059 | | | required for | 1060 | |<-+ that conference | 1061 | | | 1062 | | Request IVR menu (PIN) | 1063 | |--------------------------->| 1064 | | | 1065 |<========= MS gets PIN from Alice through DTMF =========>| 1066 | | | 1067 | | Provided PIN is... | 1068 | |<---------------------------| 1069 | Check +--| | 1070 | PIN | | | 1071 | +->| | 1072 | |--+ Alice must | 1073 | | | record her | 1074 | |<-+ name | 1075 | | | 1076 | | Request name recording | 1077 | |--------------------------->| 1078 | | | 1079 |<========= MS records Alice's audio RTP (name) =========>| 1080 | | | 1081 | | Audio recording | 1082 | |<---------------------------| 1083 | Complete +--| | 1084 | creation | | | 1085 | of Alice +->| | 1086 | | | 1087 | (2) userResponse | | 1088 | (create, success | | 1089 | confObjID, confUserID) | 1090 |<---------------------------| | 1091 | | | 1092 Figure 10: Recording and Announcements 1094 1. Upon receipt of the userRequest from "Alice" to be added to 1095 "Bob's" conference (i.e., an "update" operation on "Bob's" 1096 conference object), the conferencing system determines that a 1097 password is required for this specific conference. Thus an 1098 announcement asking "Alice" to enter the password is provided to 1099 "Alice". This may be achieved by means of typical IVR 1100 fucntionality. Once "Alice" enters the password, it is validated 1101 against the policies associated with "Bob's" active conference. 1102 The conferencing system then connects to a server which prompts 1103 and records "Alice's" name. The conferencing system must also 1104 determine whether "Alice" is already a user of this conferencing 1105 system or whether she is a new user. In this case, "Alice" is a 1106 new user for this conferencing system, so a conference user 1107 identifier is created for "Alice". Based upon the addressing 1108 information provided by "Alice", the call signaling to add 1109 "Alice" to the conference is instigated through the Focus. 1111 2. The conference server sends "Alice" a userResponse message which 1112 includes the "confUserID" assigned by the conferencing system for 1113 "Alice". This would allow "Alice" to later perform operations on 1114 the conference (if she were to have the appropriate policies), 1115 including registering for event notifications associated with the 1116 conference. Once the call signaling indicates that "Alice" has 1117 been successfully added to the specific conference, per updates 1118 to the state, and depending upon the policies, other participants 1119 (e.g., "Bob") are notified of the addition of "Alice" to the 1120 conference via the conference notification service and an 1121 announcement is provided to all the participants indicating that 1122 "Alice" has joined the conference. 1124 [Editors' Note: this example showed the case of a private conference, 1125 where access required the knowledge of a password. In this case, 1126 access to the conference is handled by delegating the control of such 1127 value to the signaling/media. Nevertheless, the "password" value is 1128 present in CCMP requests as well, according to the latest 1129 specification. Should the presented flow make use of the CCMP 1130 password check alone, or is it ok to leave the signaling/media checks 1131 as well? What is the expected best common practice when dealing with 1132 such a scenario?] 1134 (CCMP Messaging details not available yet). 1136 Figure 11: Announcement Messaging Details 1138 6.2. Monitoring for DTMF 1140 The conferencing system also needs the capability to monitor for DTMF 1141 from each individual participant. This would typically be used to 1142 enter the identifier and/or access code for joining a specific 1143 conference. 1145 An example of DTMF monitoring, within the context of the framework 1146 elements, is shown in Figure 10. A typical way for the conferencing 1147 system to be aware of all the DTMF interactions within the context of 1148 conferences it is responsible for, is making use of the MEDIACTRL 1149 architecture for what regards media manipulation. Examples in that 1150 sense (specifically for what concerns DTMF interception in conference 1151 instances) are presented in [I-D.ietf-mediactrl-call-flows]. 1153 6.3. Adding a Party 1155 In this example, "Alice" wants to add "Bob" to an established 1156 conference. In the following example we assume "Bob" is a new user 1157 to the system, which means "Alice" also needs to provide details 1158 about him. In fact, the case of "Bob" already present as a user in 1159 the conferencing system is much easier to address, and will be 1160 discussed later on. 1162 "Alice" "Bob" 1163 CMCC1 CMCC2 CMCCx ConfS 1164 | | | | 1165 |(1) userRequest(create, | | 1166 | confObjID, confUserID, | | 1167 | userInfo) | | | 1168 |-------------------------------------->| 1169 | | | | 1170 | | (a) Create +---| 1171 | | | "Bob" | | 1172 | | | as a | | 1173 | | | user +-->| 1174 | | | | 1175 |(2) userResponse(create, success | 1176 | confObjID, confUserID | 1177 | userInfo) | | 1178 |<--------------------------------------| 1179 | | | | 1180 | | | (b) Focus | 1181 | | | sets up | 1182 | | | signaling | 1183 | | | to "Bob" | 1184 | |<----------------------| 1185 | | | | 1186 | | | (c) Notify| 1187 | | | ("Bob just| 1188 | | | joined") | 1189 | | |<----------| 1190 | | | | 1191 ' ' ' ' 1192 ' ' ' ' 1193 ' ' ' ' 1195 Figure 12: Client Manipulation of Conference - Add a party 1197 1. "Alice" sends a userRequest message with an operation of "create" 1198 to add "Bob" to the specific conference as identified by the 1199 confObjID. The "create" operation also makes sure that "Bob" is 1200 created as a user in the whole conferencing system. This is done 1201 by adding a "userInfo" element describing "Bob" as a user. This 1202 is needed in order to let the conferencing system be aware of 1203 "Bob"'s characteristics. In case Bob was already a registered 1204 user, "Alice" would just have referenced him through his XCON 1205 UserID, without providing the additional "userInfo". In fact, 1206 that information (including, for instance, "Bob"'s SIP URI to be 1207 used subsequently for dial-out) would be obtained by referencing 1208 the extant registration. The conference server ensures that 1209 "Alice" has the appropriate authority based on the policies 1210 associated with that specific conference object to perform the 1211 operation. As mentioned before, a new Conference User Identifier 1212 is created for Bob, and the "userInfo" is used to update the 1213 conference object accordingly. 1215 2. In the presented example, the call signaling to add "Bob" to the 1216 conference is instigated through the Focus as well. Please 1217 notice that this is implementation specific. In fact, a 1218 conferencing system may accomplish different actions after the 1219 user creation, just as it may do nothing at all. Among the 1220 possible actions, for instance "Bob" may be added as a "target" 1221 element to the "allowed-users-list" element, whose joining 1222 "method" may be either "dial-in" or "dial-out". Besides, out-of- 1223 band notification mechanisms may be involved as well, e.g. to 1224 notify "Bob" via mail of the new conference, including details as 1225 the date, password, expected participants and so on. 1227 (c) To conclude the overview on this scenario, once "Bob" has been 1228 successfully added to the specified conference, per updates to the 1229 state, and depending upon the policies, other participants 1230 (including "Bob" himself) may be notified of the addition of "Bob" 1231 to the conference via the Conference Notification Service. 1233 1. userRequest message: 1235 1236 1239 1241 xcon-userid:alice@confSystem.com 1242 xcon:8977878@confSystem.com 1243 create 1244 1245 1246 Bob 1247 1248 1249 mailto:bob.depippis@example.com 1250 Bob's email 1251 1252 1253 1254 Bob's laptop 1256 1257 1258 1259 1260 1262 2. userResponse message: 1264 1265 1268 1270 xcon-userid:alice@confSystem.com 1271 xcon:8977878@confSystem.com 1272 create 1273 success 1274 1275 1276 Bob 1277 1278 1279 mailto:bob.depippis@example.com 1280 Bob's email 1281 1282 1283 1284 Bob's laptop 1285 1286 1287 1288 1289 1291 Figure 13: Add Party Message Details 1293 6.4. Muting a Party 1295 This section provides an example of the muting of a party in an 1296 active conference. The unmuting would involve the identical CCMP 1297 message flow. Although, in the case that floor control is involved, 1298 whether or not a particular conference client can unmute itself must 1299 be considered by the conferencing system. 1301 [Editors' Note: The interaction between CCMP and floor control 1302 should be carefully considered. In fact, if floor control is 1303 achieved by means of BFCP [RFC4582], this means could conflict 1304 with the functionality provided by CCMP. A typical example would 1305 be Alice (the CCMP moderator) unmuting Bob by means of CCMP. Such 1306 approach would conflict with BFCP, considering that if a BFCP 1307 chair wants to subsequently revoke the floor from Bob, it cannot 1308 do it, since no FloorRequestID would be associated with the 1309 previous unmute achieved by Alice. Besides, unmuting via CCMP 1310 would bypass the Floor Control Server floor queues. How should we 1311 handle this? Should we envisage CCMP muting/unmuting as a wrapper 1312 to BFCP whenever floor control is involved? Another solution 1313 might be handling CCMP- and BFCP-based media control as multiple 1314 layers: i.e., a participant may have the BFCP floor granted, but 1315 be muted by means of CCMP. If so, he would still be muted in the 1316 conference, and would only be unmuted if both the protocols 1317 allowed for this.] 1319 Figure 14 provides an example of one client "Alice" impacting the 1320 media state of another client "Bob". This example assumes an 1321 established conference. In this example, the client, "Alice" whose 1322 Role is "moderator" of the conference, wants to mute "Bob" on a 1323 medium-size multi-party conference, as his device is not muted (and 1324 he's obviously not listening to the call) and background noise in his 1325 office environment is disruptive to the conference. BFCP floor 1326 control is assumed not to be involved. 1328 "Alice" "Bob" 1329 CMCC1 CMCC2 CMCCx ConfS MS 1330 | | | | | 1331 |(1) userRequest(update, | | | 1332 | confObjID, confUserID, | | | 1333 | userInfo) | | | | 1334 |------------------------------.-------->| | 1335 | | | | Mute Bob | 1336 | | | |----------------->| 1337 | | | | 200 OK | 1338 | | | |<-----------------| 1339 | | | | | 1340 | |<====== XXX Bob excluded from mix XXX ====>| 1341 | | | | | 1342 | | (a) Update +---| | 1343 | | Bob in | | | 1344 | | Data Model | | | 1345 | | (muted) +-->| | 1346 | | | | | 1347 |(2) userResponse(update, success | | 1348 | confObjID, confUserID) | | 1349 |<---------------------------------------| | 1350 | | | | | 1351 | | | (b) Notify | | 1352 | | | ("Bob is | | 1353 | | | muted") | | 1354 | | |<-----------| | 1355 | | | | | 1356 ' ' ' ' ' 1357 ' ' ' ' ' 1358 ' ' ' ' ' 1360 Figure 14: Client Manipulation of Conference - Mute a party 1362 1. Upon receipt of userRequest message with an update operation and 1363 the userInfo with the "status" field in the "media" element for 1364 "Bob" set to "revconly". The Conference Server ensures that 1365 "Alice" has the appropriate authority based on the policies 1366 associated with that specific conference object to perform the 1367 operation and updates the userInfo in the conference object 1368 reflect that "Bob"s media is not to be mixed with the conference 1369 media. In case the Conference Server relies on a remote Media 1370 Server for its multimedia functionality, it subsequently changes 1371 "Bob"'s media profile accordingly by means of the related 1372 protocol interaction with the MS. An example describing a 1373 possible way of dealing with such a situation using the Media 1374 Server Control architecture is described in 1376 [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework 1377 Transactions (2)". 1379 2. A userResponse message with a responseCode of "success" is then 1380 sent to "Alice". Depending upon the policies, tne conference 1381 server may notify other participants (including "Bob") of this 1382 update via the Conference Notification Service. 1384 1. userRequest message: 1386 1387 1390 1392 xcon-userid:alice@confSystem.com 1393 xcon:8977878@confSystem.com 1394 update 1395 1396 1397 1398 1399 123 1400 recvonly 1401 1402 1403 1404 1405 1406 1408 2. userResponse message: 1410 1411 1414 1416 xcon-userid:alice@confSystem.com 1417 xcon:8977878@confSystem.com 1418 update 1419 success 1420 1421 1422 1424 Figure 15: Mute Message Details 1426 6.5. Internal Sidebar 1428 Figure 16 provides an example of one client "Alice" involved in 1429 active conference with "Bob" and "Carol". "Alice" wants to create a 1430 sidebar to have a side discussion with "Bob" while still viewing the 1431 video associated with the main conference. Alternatively, the audio 1432 from the main conference could be maintained at a reduced volume. 1433 "Alice" initiates the sidebar by sending a request to the 1434 conferencing system to create a conference reservation based upon the 1435 active conference object. "Alice" and "Bob" would remain on the 1436 roster of the main conference, such that other participants could be 1437 aware of their participation in the main conference, while an 1438 internal-sidebar conference is occurring. Besides, "Bob" decides 1439 that he is not interested in still receiving the conference audio in 1440 background (not even at a lower volume as "Alice" configured) and so 1441 modifies the sidebar in order to make that stream inactive for him. 1443 "Alice" "Bob" ConfS 1444 | | | 1445 |(1) sidebarByValRequest | 1446 | (create, confUserID, | 1447 | confObjID) | | 1448 |--------------------------------------------->| 1449 | | | 1450 | | (a) Create +---| 1451 | | sidebar-by-val | | 1452 | | (new conf obj | | 1453 | | cloned from +-->| 1454 | | confObjID) | Sidebar now has 1455 | | | id confObjID* 1456 |(2) sidebarByValResponse | (parent mapping 1457 | (create, success, confObjID* | conf<->sidebar) 1458 | confUserID, sidebarByValInfo) | 1459 |<---------------------------------------------| 1460 | | | 1461 |(3) sidebarByValRequest | 1462 | (update, confUserID, | 1463 | confObjID*, sidebarByValInfo) | 1464 |--------------------------------------------->| 1465 | | | 1466 | | (b) Update +---| 1467 | | sidebar-by-val | | 1468 | | (media, users | | 1469 | | etc.) +-->| 1470 | | | Sidebar is 1471 | | | modified 1472 |(4) sidebarByValResponse | 1473 | (update, success, confObjID* | 1474 | confUserID) | | 1475 |<---------------------------------------------| 1476 | | | 1477 | |(5) userRequest | 1478 | | (update, confUserID',| 1479 | | confObjID*, | 1480 | | userInfo) | 1481 | |---------------------->| 1482 | | | 1483 | | (c) Update +---| 1484 | | user settings | | 1485 | | (Bob's media) | | 1486 | | +-->| 1487 | | | Sidebar is modified 1488 | | | (original audio 1489 | | | inactive for Bob) 1490 | |(6) userResponse | 1491 | | (update, success | 1492 | | confObjID*, | 1493 | | confUserID') | 1494 | |<----------------------| 1495 | | | 1496 " " " 1497 " " " 1498 " " " 1500 Figure 16: Client Creation of a Sidebar Conference 1502 1. Upon receipt of CCMP sidebarByValRequest message to "reserve" a 1503 new sidebar conference based upon the confObjID received in the 1504 request, the conferencing system uses the confObjID to clone a 1505 conference reservation for the sidebar. The sidebar reservation 1506 is NOT independent of the active conference (i.e., parent). The 1507 conferencing system also reserves or allocates a new confObjID to 1508 be used for any subsequent protocol requests from any of the 1509 members of the conference. 1511 2. The relationship information is provided in the 1512 sidebarByValResponse message, specifically in the "sidebar- 1513 parent" element. A dump of the complete representation of the 1514 main/parent conference is provided below as well to show how the 1515 cloning process for the creation of the sidebar could take place. 1517 3. Upon receipt of the sidebarByValResponse message to reserve the 1518 conference, "Alice" can now create an active conference using 1519 that reservation, or create additional reservations based upon 1520 the existing reservations. In this example, "Alice" wants only 1521 "Bob" to be involved in the sidebar, thus she manipulates the 1522 membership so that only the two of them appear in the "allowed- 1523 users-list" section. "Alice" also wants both audio and the video 1524 from the original conference to be available in the sidebar. For 1525 what concerns the media belonging to the sidebar itself, "Alice" 1526 wants the audio to be restricted to the participants in the 1527 sidebar (that is, her and "Bob"). Additionally, "Alice" 1528 manipulates the media values to recieve the audio from the main 1529 conference at a reduced volume, so that the communication between 1530 her and "Bob" isn't affected. "Alice" sends a 1531 sidebarByValRequest message with an operation of "update" along 1532 with the sidebarByValInfo in the reservation, to create an active 1533 conference. 1535 4. Upon receipt of the sidebarByValRequest to update the reservation 1536 to create an active conference for the sidebar, as identified by 1537 the sidebar conference object ID, the conference server ensures 1538 that "Alice" has the appropriate authority based on the policies 1539 associated with that specific conference object to perform the 1540 operation. The conference server must also validate the updated 1541 information in the reservation, ensuring that a member like "Bob" 1542 is already a user of this conference server. Once the data for 1543 the confObjID is updated, the conference server sends a 1544 sidebarByValResponse to "Alice". Depending upon the policies, 1545 the initiator of the request (i.e., "Alice") and the participants 1546 in the sidebar (i.e., "Bob") may be notified of his addition to 1547 the sidebar via the conference notification service. 1549 5. At this point, "Bob" sends a userRequest message to the 1550 conference server with an operation of "update" to completely 1551 disable the background audio from the parent conference, since it 1552 prevents him from understanding what "Alice" says in the sidebar. 1554 6. Notice that "Bob's" request only changes the media perspective 1555 for "Bob". "Alice" keeps on receiving both the audio from "Bob" 1556 and the background from the parent conference. This request may 1557 be relayed by the conference server to the Media Server handling 1558 the mixing, if present. Upon completion of the change, the 1559 conference server sends a "userResponse" message to "Bob". 1560 Depending upon the policies, the initiator of the request (i.e., 1561 "Bob") and the participants in the sidebar (i.e., "Alice") may be 1562 notified of this change via the conference notification service. 1564 That said, let's consider the following conference object: 1566 1567 1572 1573 MAIN CONFERENCE 1574 1575 1576 sip:8977878@confSystem.com 1577 conference sip uri 1578 1579 1580 1581 1582 main conference audio 1583 audio 1584 sendrecv 1585 1586 1587 main conference video 1588 video 1589 sendrecv 1590 1591 single-view 1592 1593 1594 1595 1596 1597 true 1598 1599 1600 1601 Alice 1602 1603 1604 123 1605 sendrecv 1606 1607 1608 456 1609 sendrecv 1610 1611 1612 1613 1614 Bob 1615 1616 1617 123 1618 sendrecv 1619 1620 1621 456 1622 sendrecv 1623 1624 1625 1626 1627 Carol 1628 1629 1630 123 1631 sendrecv 1632 1633 1634 456 1635 sendrecv 1636 1637 1638 1639 1640 1642 This is the representation of the conference the sidebar is going to 1643 be created in. As such, it will be used by the conferencing system 1644 in order to create the new conference object associated with the 1645 sidebar. In fact, the sidebar creation happens through a cloning of 1646 the parent conference. Once the sidebar is created, an "update" 1647 makes sure that the sidebar is customized as needed. The following 1648 protocol dump makes the process clearer. 1650 1. sidebarByValRequest (create) 1652 1653 1656 1658 xcon-userid:alice@confSystem.com 1659 xcon:8977878@confSystem.com 1660 create 1661 1662 1663 1665 2. sidebarByValResponse (create success) 1667 1668 1672 1674 xcon-userid:alice@confSystem.com 1675 xcon:8974545@confSystem.com 1676 success 1677 1678 1679 1680 1681 SIDEBAR CONFERENCE registered by alice 1682 1683 1684 xcon:8977878@confSystem.com 1685 1686 1687 1688 1689 main conference audio 1690 1691 audio 1692 sendrecv 1693 1694 1695 1696 main conference video 1697 1698 video 1699 sendrecv 1700 1701 1702 1703 1704 false 1705 1706 1707 1708 1710 1712 1714 1715 1716 1717 1718 1719 1721 3. sidebarByValRequest (update) 1723 1724 1728 1730 xcon-userid:alice@confSystem.com 1731 xcon:8974545@confSystem.com 1732 update 1733 1734 1735 1736 1737 private sidebar alice - bob 1738 1739 1740 1741 1742 main conference audio 1743 1744 audio 1745 recvonly 1746 1747 -60 1748 1749 1750 1751 1752 main conference video 1754 1755 video 1756 recvonly 1757 1758 1759 1760 sidebar audio 1761 1762 audio 1763 sendrecv 1764 1765 1766 1767 sidebar video 1768 1769 video 1770 sendrecv 1771 1772 1773 1774 1775 1776 1778 1780 1781 1782 1783 1784 1785 1787 4. sidebarByValResponse (update success) 1788 1789 1793 1795 xcon-userid:alice@confSystem.com 1796 xcon:8974545@confSystem.com 1797 update 1798 success 1799 1800 1802 1804 5. userRequest (Bob's media) 1805 1806 1810 1812 xcon-userid:bob@confSystem.com 1813 xcon:8974545@confSystem.com 1814 update 1815 1816 1817 1818 1819 1820 main conference audio 1821 1822 123 1823 inactive 1824 1825 1826 1827 1828 1829 1831 6. userResponse (update success) 1832 1833 1836 1838 xcon-userid:bob@confSystem.com 1839 xcon:8974545@confSystem.com 1840 update 1841 success 1842 1843 1844 1846 Figure 17: Internal Sidebar Messaging Details 1848 6.6. External Sidebar 1850 Figure 18 provides an example of a different approach towards 1851 sidebar. In this scenario, one client, "Alice", is involved in an 1852 active conference with "Bob", "Carol", "David" and "Ethel". "Alice" 1853 gets an important text message via a whisper from "Bob" that a 1854 critical customer needs to talk to "Alice", "Bob" and "Ethel". 1855 "Alice" creates a sidebar to have a side discussion with the customer 1856 "Fred" including the participants in the current conference with the 1857 exception of "Carol" and "David", who remain in the active 1858 conference. The difference from the previous scenario is that "Fred" 1859 is not part of the parent conference: this means that different 1860 policies might be involved, considering that "Fred" may access 1861 information coming from the parent conference, in case the sidebar 1862 was configured accordingly. For this reason, in this scenario we 1863 assume that "Alice" disables all the media from the original (parent) 1864 conference within the sidebar. This means that, while in the 1865 previous example "Alice" and "Bob" still heard the audio from the 1866 main conference in background, this time no background is made 1867 available. "Alice" initiates the sidebar by sending a request to the 1868 conferencing system to create a conference reservation based upon the 1869 active conference object. "Alice", "Bob" and "Ethel" would remain on 1870 the roster of the main conference in a hold state. Whether or not 1871 the hold state of these participants is visible to other participants 1872 depends upon the individual and local policy. 1874 "Alice" "Bob" ConfS 1875 | | | 1876 |(1) sidebarByRefRequest | 1877 | (create, confUserID, | 1878 | confObjID) | | 1879 |--------------------------------------------->| 1880 | | | 1881 | | (a) Create +---| 1882 | | sidebar-by-ref | | 1883 | | (new conf obj | | 1884 | | cloned from +-->| 1885 | | confObjID) | Sidebar now has 1886 | | | id confObjID* 1887 |(2) sidebarByRefResponse | (parent mapping 1888 | (create, success, confObjID* | conf<->sidebar) 1889 | confUserID, sidebarByRefInfo) | 1890 |<---------------------------------------------| 1891 | | | 1892 |(3) sidebarByRefRequest | 1893 | (update, confUserID, | 1894 | confObjID*, sidebarByRefInfo) | 1895 |--------------------------------------------->| 1896 | | | 1897 | | (b) Create +---| 1898 | | new user for | | 1899 | | "Fred" | | 1900 | | +-->| 1901 | | | 1902 | | (c) Update +---| 1903 | | sidebar-by-val | | 1904 | | (media, users | | 1905 | | policy, etc.) +-->| 1906 | | | Sidebar is modified: 1907 | | | no media from the 1908 | | | parent conference is 1909 | | | available to anyone 1910 |(4) sidebarByRefResponse | 1911 | (update, success, confObjID* | 1912 | confUserID) | | 1913 |<---------------------------------------------| 1914 | | | 1915 | | Notify ("Fred" | 1916 | | added to | 1917 | | sidebar users) | 1918 | |<----------------------| 1919 | | | 1920 " " " 1921 " " " 1922 " " " 1924 Figure 18: Client Creation of an External Sidebar 1926 1. Upon receipt of the "sidebarByRefRequest" message to create a new 1927 sidebar conference, based upon the active conference specified by 1928 "confObjID" in the request, the conferencing system uses the 1929 received active conference to clone a conference reservation for 1930 the sidebar. The sidebar reservation is NOT independent of the 1931 active conference (i.e., parent). The conferencing system as 1932 before reserves or allocates a conference ID (confObjID*) to be 1933 used for any subsequent protocol requests from any of the members 1934 of the conference. The conferencing system maintains the mapping 1935 between this conference ID and the conference object ID 1936 associated with the sidebar reservation through the conference 1937 instance. Just as before, this mapping is mantained in "sidebar- 1938 parent". 1940 2. Upon receipt of the "sidebarByRefResponse" message, which 1941 acknowledges the successful creation of the sidebar object, 1942 "Alice" decides that only "Bob" and "Ethel", along with the new 1943 participant "Fred" are to be involved in the sidebar. Thus she 1944 manipulates the membership accordingly. "Alice" also sets the 1945 media in the "conference-info" such that the participants in the 1946 sidebar don't receive any media from the main conference. All 1947 these settings are provided to the conferencing system by means 1948 of a new "sidebarByRefRequest" message, with an "update" 1949 operation. 1951 3. "Alice" sends the aforementioned "sidebarByRefRequest" to update 1952 the information in the reservation and to create an active 1953 conference. Upon receipt of the "sidebarByRefRequest" with an 1954 operation of "update", the conferencing system ensures that 1955 "Alice" has the appropriate authority based on the policies 1956 associated with that specific conference object to perform the 1957 operation. The conferencing system also validates the updated 1958 information in the reservation. Since "Fred" is a new user for 1959 this conferencing system, a conference user identifier is created 1960 for "Fred". Specifically, "Fred" is added to the conference by 1961 only providing his SIP URI. Based upon the addressing 1962 information provided for "Fred" by "Alice", the call signaling to 1963 add "Fred" to the conference may be instigated through the Focus 1964 (e.g. if "Fred" had a "dial-out" method set as the target for 1965 him) at the actual activation of the sidebar. 1967 4. The conference server sends a "sidebarByRefResponse" message and, 1968 depending upon the policies, the initiator of the request (i.e., 1969 "Alice") and the participants in the sidebar (i.e., "Bob" and 1970 "Ethel") may be notified of his addition to the sidebar via the 1971 conference notification service. 1973 1. sidebarByRefRequest (create) 1975 1976 1979 1981 xcon-userid:alice@confSystem.com 1982 xcon:8977878@confSystem.com 1983 create 1984 1985 1987 1989 2. sidebarByRefResponse (create success) 1991 1992 1996 1998 xcon-userid:alice@confSystem.com 1999 xcon:8971212@confSystem.com 2000 success 2001 2002 2003 2004 2005 SIDEBAR CONFERENCE registered by alice 2006 2007 2008 xcon:8977878@confSystem.com 2009 2010 2011 2012 2013 main conference audio 2014 2015 audio 2016 sendrecv 2017 2018 2019 2020 main conference video 2021 2022 video 2023 sendrecv 2024 2025 2026 2027 2028 false 2029 2030 2031 2032 2034 2036 2038 2040 2042 2043 2044 2045 2046 2047 2049 3. sidebarByRefRequest (update) 2051 2055 2057 xcon-userid:alice@confSystem.com 2058 xcon:8971212@confSystem.com 2059 update 2060 2061 2062 2063 2064 sidebar alice, bob, ethel & fred 2065 2066 2067 2068 2069 main conference audio 2070 2071 audio 2072 inactive 2073 2074 2075 2076 main conference video 2077 2078 video 2079 inactive 2080 2081 2082 2083 sidebar audio 2084 2085 audio 2086 sendrecv 2087 2088 2089 2090 sidebar video 2091 2092 video 2093 sendrecv 2094 2095 2096 single-view 2097 2098 2099 2100 2101 2102 2103 false 2104 2105 2106 2107 2109 2111 2113 2114 2115 2116 2117 2118 2120 4. sidebarByRefResponse (update success) 2122 2126 2128 xcon-userid:alice@confSystem.com 2129 xcon:8971212@confSystem.com 2130 update 2131 success 2132 2133 2134 2136 Figure 19: External Sidebar Messaging Details 2138 6.7. Floor control using sidebars 2140 Floor control with sidebars can be used to realize conferencing 2141 scenario such as an analyst briefing. In this scenario, the 2142 conference call has a panel of speakers who are allowed to talk in 2143 the main conference. The other participants are the analysts, who 2144 are not allowed to speak unless they have the floor. To request 2145 access to the floor, they have to join a new sidebar with the 2146 moderator and ask their question. The moderator can also whisper to 2147 each analyst what their status/position in the floor control queue, 2148 similar to the example in Figure 22. It should be noted that other 2149 mechanisms which don't make use of sidebars could be used for floor 2150 control such as those detailed in BFCP. 2152 Figure 20 provides an example of the configuration involved for this 2153 type of conference. As in the previous sidebar examples, there is 2154 the main conference along with a sidebar. "Alice" and "Bob" are the 2155 main participants in the conference, with "A1", "A2" and "A3" 2156 representing the analysts. The sidebar remains active throughout the 2157 conference, with the moderator, "Carol", serving as the chair. As 2158 discussed previously, the sidebar conference is NOT independent of 2159 the active conference (i.e., parent). The analysts are provided the 2160 conference object ID associated with the active sidebar when they 2161 join the main conference. The conferencing system also allocates a 2162 conference ID to be used for any subsequent manipulations of the 2163 sidebar conference. The conferencing system maintains the mapping 2164 between this conference ID and the conference object ID associated 2165 with the active sidebar conference through the conference instance. 2166 The analysts are permanently muted while in the main conference. The 2167 analysts are moved to the sidebar when they wish to speak. Only one 2168 analyst is given the floor at a given time. All participants in the 2169 main conference receive audio from the sidebar conference, as well as 2170 audio provided by the panelists in the main conference. 2172 (To Be added). 2174 Figure 20: Floor Control with sidebars 2176 1. "A1" wishes to ask a question, so he sends a Floor Request 2177 message to the floor control server. 2179 2. Upon receipt of the request, the floor control server notifies 2180 the moderator, "Carol" of the active sidebar conference, whose 2181 serving as the floor chair. 2183 3. Since no other analysts have yet requested the floor, "Carol" 2184 indicates to the floor control server that "A1" may be granted 2185 the floor. 2187 (CCMP Messaging details not available yet). 2189 Figure 21: Floor Control Messaging Details 2191 6.8. Whispering or Private Messages 2193 The case of private messages can be handled as a sidebar with just 2194 two participants, similar to the example in section Section 6.5, but 2195 rather than using audio within the sidebar, "Alice" could add an 2196 additional text based media stream to the sidebar. The other 2197 context, referred to as whisper, in this document refers to 2198 situations involving one time media targetted to specific user(s). 2199 An example of a whisper would be an announcement injected only to the 2200 conference chair or to a new participant joining a conference. 2202 Figure 22 provides an example of one user "Alice" whose chairing a 2203 fixed length conference with "Bob" and "Carol". The configuration is 2204 such that only the chair is providing a warning when there is only 10 2205 minutes left in the conference. At that time, "Alice" is moved into 2206 a sidebar created by the conferencing system and only "Alice" 2207 receives the announcement. 2209 (To Be completed). 2211 Figure 22: Whisper 2213 1. When the conferencing system determines that there is only 10 2214 minutes left in the conference which "Alice" is chairing, the 2215 conferencing system directly creates an active sidebar 2216 conference, based on the active conference associated with 2217 "Alice". This sidebar conference is NOT independent of the 2218 active conference (i.e., parent). The conferencing system also 2219 allocates a conference ID to be used for any subsequent 2220 manipulations of the sidebar conference. 2222 2. Immediately upon creation of the active sidebar conference, the 2223 announcement media is provided to "Alice". Depending upon the 2224 policies, Alice may be notified of her addition to the sidebar 2225 via the conference notification service. "Alice" continues to 2226 receive the media from the main conference. 2228 3. Upon completion of the announcement, "Alice" is removed from the 2229 siebar and the sidebar conference is deleted. 2231 4. "Alice" is notified of her removal from the sidebar via the 2232 conference notification service. 2234 (CCMP Messaging details not available yet). 2236 Figure 23: Whisper Messaging Details 2238 6.9. Observing and Coaching 2240 An example of observing and coaching is shown in figure Figure 24. 2241 In this example, call center agent "Bob" is involved in a conference 2242 with customer "Carol". Since "Bob" is a new agent and "Alice" sees 2243 that he has been on the call with "Carol" for longer than normal, she 2244 decides to observe the call and coach "Bob" as necessary. 2246 (Figure not available yet). 2248 Figure 24: Supervisor Creating a Sidebar for Observing/Coaching 2250 1. Upon receipt of the confRequest from "Alice" to "create" a new 2251 sidebar conference from the confObjID received in the request, 2252 the conferencing system uses the received active conference to 2253 clone a conference reservation for the sidebar. The conferencing 2254 system also allocates a conference ID to be used for any 2255 subsequent protocol requests from any of the members of the 2256 conference. The conferencing system maintains the mapping 2257 between this conference ID and the confObjID associated with the 2258 sidebar reservation through the conference instance. The 2259 conference server sends a confResponse message with the new 2260 confObjID and relevant confInfo. 2262 2. Upon receipt of the confResponse message, "Alice" manipulates the 2263 data received in the confInfo in the response. "Alice" wants 2264 only "Bob" to be involved in the sidebar, thus she updates the 2265 "allowed-users-list" to include only "Bob". "Alice" also wants 2266 the audio to be received by herself and "Bob" from the original 2267 conference, but wants any outgoing audio from herself to be 2268 restricted to the participants in the sidebar, whereas "Bob's" 2269 outgoing audio should go to the main conference, so that both 2270 "Alice" and the customer "Carol" hear the same audio from "Bob". 2271 "Alice" sends a confRequest message with an "update" operation 2272 including the updated conference information. 2274 3. Upon receipt of the confRequest message with an "update" 2275 operation, the conferencing system ensures that "Alice" has the 2276 appropriate authority based on the policies associated with that 2277 specific conference object to perform the operation. 2279 4. After validating the data, the conference server sends a 2280 confResponse message. Based upon the addressing information 2281 provided for "Bob" by "Alice", the call signaling to add "Bob" to 2282 the sidebar with the appropriate media characteristics is 2283 instigated through the Focus. "Bob" is notified of his addition 2284 to the sidebar via the conference notification service, thus he 2285 is aware that "Alice" the supervisor is available for coaching 2286 him through this call. 2288 (CCMP Messaging details not available yet). 2290 Figure 25: Coaching and Observing Messaging details 2292 7. Removing participants and deleting conferences 2294 The following scenarios detail the basic operations associated with 2295 removing participants from conferences and entirely deleting 2296 conferences. The examples assume that a conference has already been 2297 correctly established, with media, if applicable, per one of the 2298 examples in Section 5. 2300 7.1. Removing a Party 2302 Figure 26 provides an example of one client "Alice" removing another 2303 participant "Bob" from a conference. This example assumes an 2304 established conference with "Alice", "Bob", "Claire" and "Duck". In 2305 this example, "Alice" wants to remove "Bob" from the conference so 2306 that the group can continue in the same conference without "Bob"'s 2307 participation. 2309 "Alice" "Bob" "Claire" ConfS 2310 | | | | 2311 |(1) userRequest(delete, | | 2312 | confObjID, confUserID, | | 2313 | userInfo) | | | 2314 |-------------------------------------->| 2315 | | | | 2316 | | | (a) Focus | 2317 | | | tears down| 2318 | | | signaling | 2319 | | | to "Bob" | 2320 | |<----------------------| 2321 | | | 2322 | | (b)Deletes+---| 2323 | | | "Bob" | | 2324 | | | as a | | 2325 | | | user +-->| 2326 | | | in | 2327 | | | confObj | 2328 | | | | 2329 |(2) userResponse(delete, success | 2330 | confObjID) | | 2331 | | | | 2332 |<--------------------------------------| 2333 | | | | 2334 | | | | 2335 | | | (c) Notify| 2336 | | | ("Bob just| 2337 | | | left") | 2338 | | |<----------| 2339 | | | | 2340 ' ' ' ' 2341 ' ' ' ' 2342 ' ' ' ' 2343 Figure 26: Client Manipulation of Conference - Remove a party 2345 1. "Alice" sends a userRequest message, with a "delete" operation. 2346 The conference server ensures that "Alice" has the appropriate 2347 authority based on the policies associated with that specific 2348 conference object to perform the operation. 2350 2. Based upon the addressing and media information in the conference 2351 object for "Bob" in the "user" element, the conference instigates 2352 the process to remove "Bob" (e.g., the call signaling to remove 2353 "Bob" from the conference is instigated through the Focus). The 2354 conference server updates the data in the conference object, thus 2355 removing "Bob" from the "users" list. After updating the data, 2356 the conference server sends a userResponse message to "Alice". 2357 Depending upon the policies, other participants (e.g. "Claire") 2358 may be notified of the removal of "Bob" from the conference via 2359 the Conference Notification Service. 2361 (CCMP Messaging details not available yet). 2363 Figure 27: Removing a Participant Messaging Details 2365 7.2. Deleting a Conference 2367 Details to be added. 2369 (Figure not available yet). 2371 Figure 28: Deleting a conference 2373 (Text description to be added). 2375 (CCMP Messaging details not available yet). 2377 Figure 29: Deleting a Conference Messaging Details 2379 8. Additional Conference Scenarios and Examples 2381 The following are additional scenarios making use of the XCON 2382 framework and associated protocols. In some cases, these examples 2383 make use of some of the building block scenarios detailed in the 2384 previous example sections, in which case the appropriate scenario is 2385 referenced rather than duplicating details. In addition, in cases 2386 where the scenarios make use of other protocols, as in the previous 2387 section, the appropriate reference in the form of a title to the 2388 specific flow in the appropriate protocol document is included. 2390 8.1. Chat 2392 The chat functionality described in this section of the document 2393 allows clients that use the XCON framework and protocols for other 2394 media types (e.g. voice/video) to utilize the same conference control 2395 mechanisms and conferencing system to establish, update and delete a 2396 conference instance associated with an Instant Messaging (IM) chat 2397 session, independent of the IM chat protocol. In some cases(e.g., 2398 Message Session Relay Protocol (MSRP) chat), this would provide 2399 additional capabilities, such as sidebars. This approach also allows 2400 the conferencing system to provide a natural interworking point for 2401 various IM protocols, the details of the interworking are outside the 2402 scope of this document. 2404 An IM client wishing to join a conference uses standardized 2405 centralized conferencing mechanisms for creating and joining a 2406 conference, as identified in the previous sections. The request to 2407 send an IM to an IM media session is specific to the IM protocol 2408 (e.g., MSRP SEND), just as there is specific media control messaging 2409 for other types of sessions. An IM client connecting to a 2410 conferencing system has a 1:1 relationship with the IM media 2411 signaling entity in the conferencing system. This relationship is 2412 referred to as an IM session. Further details of the correlation of 2413 the IM session identifiers with the XCON session identifiers is 2414 provided in [I-D.boulton-xcon-session-chat]. The IM media signaling 2415 entity is responsible for distribution of all the messages to the 2416 other participants. 2418 As with the other example conferences created, each IM session is 2419 logically associated with a specific conference. The conference 2420 itself has a specific identifier in the form of the XCON-URI, which 2421 is passed in the "confObjID" element in the CCMP messages. This 2422 provides the relevant association between IM session and a 2423 centralized conference. 2425 An IM client wishing to delete a chat room uses standardized 2426 mechanisms for deleting a conference instance, such as those detailed 2427 in Section 7.2. 2429 8.1.1. Basic Chat Operations 2431 This section provides details of the realization of the Multi-party 2432 IM (chat) within the context of the centralized conferencing 2433 framework. A brief discussion and diagrams are provided for 2434 creating, joining, and deleting a chat based conference. The 2435 discovery of chat rooms available on a specific conferencing system 2436 is inherent in the blueprint capability provided by the conferencing 2437 system. The objective of this section is to further illustrate the 2438 model, mechanisms and protocols presented in the previous sections 2439 and also serves to validate that the model, mechanisms and protocols 2440 are sufficient to support IM chat. 2442 It should be noted that not all entities impacted by the request are 2443 shown in the diagram (e.g., Focus), but rather the emphasis is on the 2444 new entities introduced by this centralized conferencing framework. 2446 8.1.1.1. Creating a Chat Room 2448 There are different ways to create a conference. A participant can 2449 create a conference using call signaling means only, such as SIP, as 2450 detailed in [RFC4579]. For a conferencing client to have more 2451 flexibility in defining the charaterisitics and capabilities of a 2452 chat based conference, a conferencing client would implement a 2453 conference control protocol client. By using a conference control 2454 protocol, the client can determine the capabilities of a conferencing 2455 system and its various resources. 2457 Figure 30 provides an example of one client "Alice" determining the 2458 conference blueprints available to support various types of chat 2459 rooms for a particular conferencing system and creating a chat based 2460 conference using the desired blueprint. 2462 Details to be added. 2464 Figure 30: Client Creation of Chat room 2466 Upon receipt of the Conference Control Protocol request for 2467 blueprints associated with chat rooms, the conferencing system would 2468 first authenticate "Alice" (and allocate a conference user 2469 identifier, if necessary) and then ensure that "Alice" has the 2470 appropriate authority based on system policies to receive any chat 2471 room based blueprints supported by that system. Any blueprints that 2472 "Alice" is authorized to use are returned in a response, along with 2473 the conference user ID. 2475 Upon receipt of the Conference Control Protocol response containing 2476 the blueprints, "Alice" determines which blueprint to use for the 2477 conference to be created. "Alice" creates a conference object based 2478 on the blueprint (i.e., clones) and modifies applicable fields, such 2479 as membership list, topic details, and start time. "Alice" then 2480 sends a request to the conferencing system to create a conference 2481 reservation based upon the updated blueprint. 2483 Upon receipt of the Conference Control Protocol request to "create" a 2484 conference based upon the blueprint in the request, the conferencing 2485 system ensures that the blueprint received is a valid blueprint (i.e. 2486 the values of the various field are within range). The conferencing 2487 system determines the appropriate read/write access of any users to 2488 be added to a conference based on this blueprint (using membership, 2489 roles, etc.). The conferencing system uses the received blueprint to 2490 clone a conference reservation. The conferencing system also 2491 reserves or allocates a conference ID to be used for any subsequent 2492 protocol requests from any of the members of the conference. The 2493 conferencing system maintains the mapping between this conference ID 2494 and the conference object ID associated with the reservation through 2495 the conference instance. 2497 Upon receipt of the conference control protocol response to reserve 2498 the conference, "Alice" now creates an active chat room using that 2499 reservation. "Alice" provides the conference information, including 2500 the necessary conference ID, to desired participants to allow them to 2501 join the chat room. "Alice" may also add other users to the chat 2502 room. When the first participant, including "Alice", requests to be 2503 added to the conference, an active conference and focus are created. 2504 The focus is associated with the conference ID received in the 2505 request. 2507 (CCMP Messaging details not available yet. 2508 Plan is to reference detailed flows in 2509 previous sections 2510 in the example.) 2512 Figure 31: Chatroom Creation Messaging Details 2514 8.1.1.2. Joining a Chat Room 2516 A participant can join and leave the conference using call signaling 2517 means only, such as SIP. However, in order to perform richer 2518 conference control a user client can implement a conference control 2519 protocol client. By using a conference control protocol, the client 2520 can affect its own state and the state of other participants, 2521 depending upon policies, which may indirectly affect the state of any 2522 of the conference participants. 2524 In the example in section Section 8.1.1.1, "Alice" has reserved a 2525 chat room . "Alice" has also already joined the conference and made 2526 the chat room active. "Alice" can either add additional participants 2527 to the chat room or provide the conference information, including the 2528 necessary conference ID, to desired participants and allow them to 2529 request to join themselves. Any participants that have the authority 2530 to manipulate the conference would receive the conference object 2531 identifier of the active conference object in the response to their 2532 request to join. 2534 Figure 32 provides an example of "Bob" joining the chat room using 2535 the conference ID provided by "Alice" (e.g., in an IM). 2537 Details to be added. 2539 Figure 32: Joining a chat room 2541 Upon receipt of the Conference Control Protocol request to "add" a 2542 party ("Bob") in the specific conference as identified by the 2543 conference object ID, the conferencing system must determine whether 2544 "Bob" is already a user of this conferencing system or whether he is 2545 a new user. If "Bob" is a new user for this conferencing system, a 2546 Conference User Identifier is created for Bob. The conferencing 2547 system must also ensure that "Bob" has the appropriate authority 2548 based on the policies associated with that specific conference object 2549 to perform the operation. 2551 Once "Bob" has been successfully added to the chat room, a response 2552 is sent to "Bob". Depending upon the policies, other participants 2553 (including "Bob") may be notified of the addition of "Bob" to the 2554 conference via the Conference Notification Service. 2556 (CCMP Messaging details not available yet. 2557 Plan is to reference detailed flows in 2558 previous sections as appropriate 2559 in the example.) 2561 Figure 33: Chatroom Join Messaging Details 2563 8.1.1.3. Deleting a Chat Room 2565 Depending upon the conferencing system policies and policies specific 2566 to the chat room, the creator of the chat would typically be the 2567 participant authorized to delete the chat room. 2569 In the example in section Section 8.1.1.1, "Alice" has created a chat 2570 room and provided the conference information, including the necessary 2571 conference ID, to desired participants and allow them to request to 2572 join themselves. "Bob" and others are participants in the chat. 2573 Figure 34 provides an example of "Alice" later deleting this same 2574 chat room. 2576 Details to be added. 2578 Figure 34: Deleting a chat room 2580 Upon receipt of the Conference Control Protocol request to "delete" 2581 the specific chat room as identified by the conference object ID, the 2582 conferencing system must determine whether "Alice" has the authority 2583 to delete this conference. Since "Alice" is the creator of the 2584 conference, the "delete" operation is performed, with the appropriate 2585 signaling sent to the participants, including a response to "Alice" 2586 indicating that the chat room has been deleted. 2588 One step in the deletion of the chat room may include notifitying the 2589 participants (including "Bob") that they have been removed via the 2590 Conference Notification Service. 2592 (CCMP Messaging details not available yet. 2593 Plan is to reference detailed flows in 2594 previous sections .) 2596 Figure 35: Chatroom Deletion Messaging Details 2598 8.1.2. Advanced Operations 2600 This section provides details of the realization of advanced chat 2601 features, such as sidebars and private messages, within the context 2602 of the centralized conferencing framework. As with Section 8.1.1, 2603 the objective of this section is to further illustrate the model, 2604 mechanisms and protocols presented in the previous sections and also 2605 serves to validate that the model, mechanisms and protocols are 2606 sufficient to support advance IM chat features. 2608 8.1.2.1. Text Sidebar 2610 The concept of a 'sidebar' in conferencing system is fully described 2611 in the Sidebar section and related subsections within the 2612 Conferencing Scenarios Realization section of the centralized 2613 conferencing framework document [RFC5239]. The creation, 2614 manipulation and deletion of sidebars for chat rooms follows the same 2615 principles. 2617 A conference object representing a sidebar is created by cloning the 2618 parent associated with the existing conference and updating any 2619 information specific to the sidebar. A sidebar conference object is 2620 implicitly linked to the parent conference object (i.e. it is not an 2621 independent object) and is associated with the parent conference 2622 object identifier. A conferencing system manages and enforces the 2623 parent and appropriate localized restrictions on the sidebar 2624 conference object (e.g., no members from outside the parent 2625 conference instance can join, sidebar conference can not exist if 2626 parent conference is terminated, etc.). 2628 Figure 36 provides an example of one client "Alice" involved in 2629 active chat room with "Bob" and "Carol". "Alice" wants to create a 2630 sidebar to have a side discussion with "Bob" while still receiving 2631 the session based messaging associated with the main chat room. 2632 Whether the text is interleaved with the main chat or whether a 2633 separate window is created for the sidebar is implementation 2634 specific. "Alice" initiates the sidebar by sending a request to the 2635 conferencing system to create a conference chat reservation based 2636 upon the active chat conference object. "Alice" and "Bob" would 2637 remain on the roster of the main conference, such that other 2638 participants could be aware of their participation in the main 2639 conference, while the text sidebar conference is occurring. 2641 Details to be added. 2643 Figure 36: Client Creation of a Sidebar Conference 2645 Upon receipt of the Conference Control Protocol request to "reserve" 2646 a new sidebar chat conference, based upon the active chat conference 2647 received in the request, the conferencing system uses the received 2648 active chat conference to clone a conference chat reservation for the 2649 sidebar. As discussed previously, the sidebar reservation is NOT 2650 independent of the active conference (i.e., parent). The 2651 conferencing system also reserves or allocates a conference ID to be 2652 used for any subsequent protocol requests from any of the members of 2653 the conference. The conferencing system maintains the mapping 2654 between this conference ID and the conference object ID associated 2655 with the sidebar reservation through the conference instance. 2657 Upon receipt of the conference control protocol response to reserve 2658 the conference, "Alice" can now create an active chat conference 2659 using that reservation or create additional reservations based upon 2660 the existing reservations. In this example, "Alice" wants only "Bob" 2661 to be involved in the sidebar, thus she manipulates the membership. 2662 "Alice" also only wants the text from the original conference, but 2663 wants the text within the sidebar to be restricted to the 2664 participants in the sidebar. "Alice" sends a conference control 2665 protocol request to update the information in the reservation and to 2666 create an active conference. 2668 Upon receipt of the conference control protocol request to update the 2669 reservation and to create an active chat conference for the sidebar, 2670 as identified by the conference object ID, the conferencing system 2671 ensures that "Alice" has the appropriate authority based on the 2672 policies associated with that specific conference object to perform 2673 the operation. The conferencing system must also validate the 2674 updated information in the reservation, ensuring that a member like 2675 "Bob" is already a user of this conferencing system. 2677 Depending upon the policies, the initiator of the request (i.e., 2678 "Alice") and the participants in the sidebar (i.e., "Bob") may be 2679 notified of his addition to the sidebar via the conference 2680 notification service. 2682 Details to be added. 2684 Figure 37: Chatroom Sidebar Messaging Details 2686 8.1.2.2. Private Message 2688 The case of private messages can be handled as a sidebar with just 2689 two participants, identical to the example in section 2690 Section 8.1.2.1. The other context, referred to as whisper, in this 2691 document refers to situations involving one time media targetted to 2692 specific user(s). An example of a whisper would be a text message 2693 injected only to the conference chair or to a new participant joining 2694 a conference. 2696 Figure 38 provides an example of one user "Alice" who's chairing a 2697 fixed length conference with "Bob" and "Carol". The configuration is 2698 such that only the chair is providing a warning when there is only 10 2699 minutes left in the conference. At that time, "Alice" is moved into 2700 a sidebar created by the conferencing system and only "Alice" 2701 receives that text message announcing the 10 minute warning. 2703 Details to be added. 2705 Figure 38: Whisper 2707 When the conferencing system determines that there is only 10 minutes 2708 left in the conference which "Alice" is chairing, rather than 2709 creating a reservation as was done for the sidebar in 2710 Section 8.1.2.1, the conferencing system directly creates an active 2711 chat sidebar conference, based on the active chat conference 2712 associated with "Alice". As discussed previously, the sidebar 2713 conference is NOT independent of the active conference (i.e., 2714 parent). The conferencing system also allocates a conference ID to 2715 be used for any subsequent manipulations of the sidebar chat 2716 conference. The conferencing system maintains the mapping between 2717 this conference ID and the conference object ID associated with the 2718 active sidebar conference through the conference instance. 2720 Immediately upon creation of the active chat sidebar conference, the 2721 text announcement is provided to "Alice". Depending upon the 2722 policies, Alice may be notified of her addition to the sidebar via 2723 the conference notification service. "Alice" continues to receive 2724 the text messages from the main conference. 2726 Upon delivery of the text announcement, "Alice" is removed from the 2727 sidebar and the sidebar conference is deleted. Depending upon the 2728 policies, "Alice" may be notified of her removal from the sidebar via 2729 the conference notification service. 2731 Details to be added. 2733 Figure 39: Chatroom Sidebar Messaging Details 2735 9. IANA Considerations 2737 This document has no IANA considerations. 2739 10. Security Considerations 2741 The security considerations applicable to the implementation of these 2742 call flows is documented in the XCON Framework, with additional 2743 security considerations documented in the CCMP document. Where 2744 applicable, statements with regards to the necessary security are 2745 discussed in particular flows, however, since this is only an 2746 informational document, readers are strongly recommended to carefully 2747 consider the security considerations defined in the XCON Framework 2748 and the CCMP document. 2750 11. Change Summary 2752 NOTE TO THE RFC-Editor: Please remove this section prior to 2753 publication as an RFC. 2755 The following are the major changes between the individual 01 version 2756 to the WG 00: 2758 o Updates to reflect most recent version of CCMP, including 2759 parameter names, etc. 2761 o Added protocol details to many of the examples. 2763 o Editorial: Simplifying intro, terms, etc. 2765 The following are the major changes between the 00 and the 01 2766 versions of the draft: 2768 o Updates to reflect change of CCMP to HTTP transport model. 2770 12. Acknowledgements 2772 The detailed content for this document is derived from the prototype 2773 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and 2774 their colleagues at the University of Napoli. 2776 13. References 2778 13.1. Normative References 2780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2781 Requirement Levels", BCP 14, RFC 2119, March 1997. 2783 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 2784 Centralized Conferencing", RFC 5239, June 2008. 2786 [I-D.ietf-xcon-ccmp] 2787 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 2788 "Centralized Conferencing Manipulation Protocol", 2789 draft-ietf-xcon-ccmp-02 (work in progress), March 2009. 2791 13.2. Informative References 2793 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2794 A., Peterson, J., Sparks, R., Handley, M., and E. 2795 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2796 June 2002. 2798 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2799 (SIP) Call Control - Conferencing for User Agents", 2800 BCP 119, RFC 4579, August 2006. 2802 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 2803 RFC 4597, August 2006. 2805 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 2806 Control Protocol (BFCP)", RFC 4582, November 2006. 2808 [I-D.ietf-xcon-event-package] 2809 Camarillo, G., Srinivasan, S., Even, R., and J. 2810 Urpalainen, "Conference Event Package Data Format 2811 Extension for Centralized Conferencing (XCON)", 2812 draft-ietf-xcon-event-package-01 (work in progress), 2813 September 2008. 2815 [I-D.ietf-xcon-common-data-model] 2816 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 2817 "Conference Information Data Model for Centralized 2818 Conferencing (XCON)", draft-ietf-xcon-common-data-model-13 2819 (work in progress), April 2009. 2821 [I-D.ietf-mediactrl-call-flows] 2822 Amirante, A., Castaldi, T., Miniero, L., and S. Romano, 2823 "Media Control Channel Framework (CFW) Call Flow 2824 Examples", draft-ietf-mediactrl-call-flows-00 (work in 2825 progress), March 2009. 2827 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 2828 Server Control", RFC 5567, June 2009. 2830 [I-D.ietf-mediactrl-mixer-control-package] 2831 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 2832 Control Package for the Media Control Channel Framework", 2833 draft-ietf-mediactrl-mixer-control-package-07 (work in 2834 progress), May 2009. 2836 [I-D.boulton-xcon-session-chat] 2837 Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within 2838 a Centralized Conferencing (XCON) System", 2839 draft-boulton-xcon-session-chat-04 (work in progress), 2840 July 2009. 2842 Authors' Addresses 2844 Mary Barnes 2845 Nortel 2846 2201 Lakeside Blvd 2847 Richardson, TX 2849 Email: mary.barnes@nortel.com 2851 Chris Boulton 2852 NS-Technologies 2854 Email: chris@ns-technologies.com 2855 Lorenzo Miniero 2856 Meetecho 2857 Via Carlo Poerio 89/a 2858 Napoli 80121 2859 Italy 2861 Email: lminiero@meetecho.com 2863 Roberta Presta 2864 University of Napoli 2865 Via Claudio 21 2866 Napoli 80125 2867 Italy 2869 Email: roberta.presta@unina.it 2871 Simon Pietro Romano 2872 University of Napoli 2873 Via Claudio 21 2874 Napoli 80125 2875 Italy 2877 Email: spromano@unina.it