idnits 2.17.1 draft-ietf-xcon-examples-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-09 -- 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-19 == Outdated reference: A later version (-13) exists of draft-ietf-mediactrl-call-flows-04 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-11 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Polycom 4 Intended status: Informational L. Miniero 5 Expires: January 13, 2011 Meetecho 6 R. Presta 7 S P. Romano 8 University of Napoli 9 July 12, 2010 11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 12 draft-ietf-xcon-examples-06 14 Abstract 16 This document provides detailed call flows for the scenarios 17 documented in the Centralized Conferencing (XCON) Framework and the 18 XCON Scenarios. The call flows document the use of the interface 19 between a conference control client and a conference control server 20 using the Centralized Conferencing Manipulation Protocol (CCMP). The 21 objective is to provide a base reference for both protocol 22 researchers and developers. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 13, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 5 63 4.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 6 64 4.3. Conference Notifications . . . . . . . . . . . . . . . . . 10 65 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 14 66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 14 67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 19 68 5.3. Conference Creation using User-Provided Conference 69 Information . . . . . . . . . . . . . . . . . . . . . . . 26 70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 31 71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 35 72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 35 73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 39 74 6.3. Conference Announcements and Recordings . . . . . . . . . 42 75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45 76 6.5. Entering a password-protected conference . . . . . . . . . 46 77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 48 78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 49 79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 58 80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 65 81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 69 82 8. Removing Participants and Deleting Conferences . . . . . . . . 77 83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 77 84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 80 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 82 87 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 82 88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 84 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 84 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 84 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 94 1. Introduction 96 This document provides detailed call flows for the scenarios 97 documented in the Framework for Centralized Conferencing (XCON 98 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON 99 scenarios describe a broad range of use cases taking advantage of the 100 advanced conferencing capabilities provided by a system realization 101 of the XCON framework. The call flows document the use of the 102 interface between a conference control client and a conference 103 control server using the Centralized Conferencing Manipulation 104 Protocol (CCMP)[I-D.ietf-xcon-ccmp]. 106 Due to the broad range of functionality provided by the XCON 107 Framework and the flexibility of the CCMP messaging, these call flows 108 should not be considered inclusive of all the functionality that can 109 provided by the XCON Framework and protocol implementations. These 110 flows represent a sample to provide an overview of the feature rich 111 capabilities of the XCON framework and CCMP messaging for protocol 112 developers, software developers and researchers. 114 2. Terminology 116 This document uses the same terminology as found in the Media Control 117 Architectural Framework [RFC5567] and Media Control Channel Framework 118 Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the 119 following terms and abbreviations used in the call flows. Also, note 120 that the term "call flows" is used in a very generic sense in this 121 document since the media is not limited to voice. The calls 122 supported by the XCON framework and CCMP can consist of media such as 123 text, voice and video, including multiple media types in a single 124 active conference. 126 Conference and Media Control Client (CMCC): as defined in the XCON 127 Framework. In the flows in this document, the CMCC is logically 128 equivalent to the use of UAC as the client notation in the media 129 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC 130 differs from a generic Media Client in being an XCON-aware entity, 131 thus being able to also issue CCMP requests. 133 Conferencing Server (ConfS): In this document, the term 134 "Conferencing Server" is used interchangeably with the term 135 "Application Server" (AS) as used in the Media Control 136 Architectural Framework [RFC5567]. A Conferencing Server is 137 intended to be able to act as a Conference Control Server, as 138 defined in the XCON framework, i.e. it is able to handle CCMP 139 requests and issue CCMP responses. 141 Media Server (MS): as defined in the Media Control Architectural 142 Framework [RFC5567]. 144 3. Overview 146 This document provides a sampling of detailed call flows that can be 147 implemented based on a system realization of the XCON framework 148 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is 149 intended to be a simple guide for the use of the Conference Control 150 Protocol between the Conferencing Server and the Conference Control 151 Client. The objective is to provide an informational base reference 152 for protocol developers, software developers and researchers. 154 This document focuses on the interaction between the Conference (and 155 Media) Control Client and the Conferencing System, specifically the 156 Conferencing Server. The scenarios are based on those described in 157 the XCON framework, many of which are based on the advanced 158 conferencing capabilities described in the XCON scenarios. 159 Additional scenarios have been added to provide examples of other 160 real life scenarios that are anticipated to be supported by the 161 framework. With the exception of an initial example with media 162 control messaging, the examples do not include the details for the 163 media control [I-D.ietf-mediactrl-mixer-control-package], call 164 signaling or binary floor control [RFC4582] protocols. This document 165 references the scenarios in the Media Control call flows 166 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing 167 [RFC4579] and binary floor control protocol documents. 169 The rest of this document is organized as follows. Section 4 170 presents an overview on CCMP, together with some implementation- 171 related details and related matters like HTTP transport and 172 notifications. Section 5 presents the reader with examples showing 173 the different approaches CCMP provides to create a new conference. 174 Section 6 more generally addresses the different user-related 175 manipulations that can be achieved by means of CCMP, by presenting a 176 number of interesting scenarios. Section 7 addresses the several 177 scenarios that may involve the use of sidebars. Section 8 shows how 178 CCMP can be used to remove conferences and users from the system. 179 Finally, IANA considerations are discussed in Section 9, while 180 Section 10 provides a few details for what concerns the Security 181 Considerations when it comes to implementing CCMP. 183 4. Working with CCMP 185 This section aims at being a brief introduction to how the 186 Centralized Conferencing Manipulation Protocol (CCMP) 188 [I-D.ietf-xcon-ccmp] works and how it can be transported across a 189 network. Some words will be spent to describe a typical CCMP 190 interaction, by focusing on relevant aspects of the client-server 191 communication. Please notice that this section is by no means to be 192 considered as a replacement for the CCMP document, which remains a 193 mandatory read before approaching the following sections. It is just 194 conceived to help the reader take the first steps toward the actual 195 protocol interactions. 197 First of all, some lines will be devoted to the protocol by itself in 198 Section 4.1, together with some recommendations from an 199 implementation point of view. In Section 4.2, instead, an effective 200 CCMP interaction will be presented by exploiting HTTP as a transport. 201 Finally, a few words will be spent on notifications in Section 4.3. 203 Once done with these preliminary steps, some actual flows will be 204 presented and described in detail in the sections to follow. 206 4.1. CCMP and the Data Model 208 CCMP is an XML-based protocol. It has been designed as a request/ 209 response protocol. Besides, it is completely stateless, which means 210 implementations can safely handle transactions independently from 211 each other. 213 The protocol allows for the manipulation of conference objects and 214 related users. By manipulation it is implied, as the document 215 specifies, that a Conferencing Client (briefly CMCC in all the 216 following sections) can create, update and remove basically 217 everything that is related to the objects handled by a conferencing 218 system. This is reflected in the allowed operations (retrieve, 219 create, update, delete) and the specified request types (ranging from 220 the manipulation of blueprints and conferences to users and 221 sidebars). For instance, CCMP provides ways to: 223 o retrieve the list of registered and/or active conferences in the 224 system; 226 o create new conferences by exploiting to several different 227 approaches; 229 o add/remove users to/from a conference; 231 o update a conference with respect to all of its aspects; 233 and so on. 235 It is worthwile to note that, while CCMP acts as the means to 236 manipulate conference objects, its specification does not define 237 these objects as well. In fact, a separate document has been written 238 to specify how a conference object and all its components have to be 239 constructed: the Conference Information Data Model for Centralized 240 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP, 241 according to the request type and the related operation, carries 242 pieces of conference objects (or any object as a whole) according to 243 the aforementioned specification. This means that any implementation 244 aiming at being compliant with CCMP has to make sure that the 245 transported objects are completely compliant with the Data Model 246 specification and coherent with the constraints defined therein. To 247 make this clearer, there are elements that are mandatory in a 248 conference object: issuing a syntactically correct CCMP request that 249 carries a wrong conference object is doomed to result in a failure. 250 For this reason, it is suggested that the interested implementors 251 take special care in carefully checking the Data Model handlers as 252 well in order to avoid potential mistakes. 254 Of course, there are cases where a mandatory element in the Data 255 Model cannot be assigned in a conference object by a CCMP user. For 256 instance, a CMCC may be requesting the direct creation of a new 257 conference: in this case, a conference object assumes an 'entity' 258 element uniquely identifying the conference to be in place. Anyway, 259 the CMCC has no way to know a priori what the entity will be like, 260 considering it will only be generated by the ConfS after the request. 261 For scenarios like this one, the CCMP specification envisages the use 262 of a dedicated placeholder wildcard to make the conference object 263 compliant with the Data Model: the wildcard would then be replaced by 264 the ConfS with the right value. 266 4.2. Using HTTP as a transport 268 CCMP requests and responses can be transported from a client to a 269 server and viceversa through several ways, being the protocol 270 specification agnostic with respect to the transport in use. 271 Nevertheless, in [I-D.ietf-xcon-ccmp], more focus is given on HTTP as 272 a solution for this transport matter, and a whole chapter is devoted 273 in the document to how HTTP can be used for it. The following lines 274 will provide a brief explanation, from a more practical point of 275 view, of how HTTP might be exploited to carry CCMP messages. In this 276 document, however, all the call flows herein presented will just show 277 the CCMP interactions, without talking about how the messages could 278 have gone across the network. 280 In case HTTP is used as a transport, the specification is very clear 281 with respect to how the interaction has to occur. Specifically, a 282 CMCC is assumed to send his request as part of an HTTP POST message, 283 and the ConfS would reply by means of an HTTP 200 message. In both 284 cases, the HTTP messages would have the CCMP messages as payload, 285 which would be reflected in the Content-Type message (application/ 286 ccmp+xml). Figure 1 presents a ladder diagram of such interaction, 287 which is followed by a dump of the exchanged HTTP messages for 288 further analysis: 290 CMCC ConfS 291 | | 292 | 1. HTTP POST (CCMP request) | 293 |--------------------------------------------->| 294 | | 295 | |--+ Parse request, 296 | | | update object 297 | |<-+ and reply 298 | | 299 | 2. 200 OK (CCMP response) | 300 |<---------------------------------------------| 301 | | 302 |--+ Parse response and | 303 | | update local copy | 304 |<-+ of conference object | 305 | | 306 . . 307 . . 309 Figure 1: CCMP on HTTP 311 As it can be seen in the protocol dump in the following lines, the 312 CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve' 313 operation) towards the Conferencing Server (ConfS). The request has 314 been carried as payload of an HTTP POST (message 1.) towards a 315 previously known location. The mandatory 'Host' header has been 316 specified, and the 'Content-Type' header has been correctly set as 317 well (application/ccmp+xml). 319 The ConfS, in turn, has handled the request and replied accordingly. 320 The response (a blueprintResponse with a successful response code) 321 has been carried as payload of an HTTP 200 OK (message 2.). As 322 before, the 'Content-Type' header has been correctly set 323 (application/ccmp+xml). 325 1. CMCC -> ConfS (HTTP POST, CCMP request) 326 ------------------------------------------ 327 POST /Xcon/Ccmp HTTP/1.1 328 Content-Length: 657 329 Content-Type: application/ccmp+xml 330 Host: example.com:8080 331 Connection: Keep-Alive 332 User-Agent: Apache-HttpClient/4.0.1 (java 1.5) 334 335 339 341 xcon-userid:Alice@example.com 342 xcon:AudioRoom@example.com 343 retrieve 344 345 346 348 2. CMCC <- ConfS (200 to POST, CCMP response) 349 --------------------------------------------- 350 HTTP/1.1 200 OK 351 X-Powered-By: Servlet/2.5 352 Server: Sun GlassFish Communications Server 1.5 353 Content-Type: application/ccmp+xml;charset=ISO-8859-1 354 Content-Length: 1652 355 Date: Thu, 04 Feb 2010 14:47:56 GMT 357 358 362 365 xcon-userid:Alice@example.com 366 xcon:AudioRoom@example.com 367 retrieve 368 200 369 success 370 371 372 373 AudioRoom 374 2 375 376 377 378 audio 379 380 381 382 383 allow 384 385 386 confirm 387 388 389 390 391 392 393 394 395 397 Just for the sake of completeness, a few words will be spent about 398 the occurred CCMP interaction as well. In fact, despite the 399 simplicity of the request, this flow already provides some relevant 400 information on how CCMP messages are built. Specifically, both the 401 request and the response share a subset of the message: 403 o confUserID: this element, provided by the CMCC, refers to the 404 requester by means of his XCON-USERID; except in a few scenarios 405 (presented in the following sections) this element must always 406 contain a valid value; 408 o confObjID: this element refers to the target conference object, 409 according to the request in place; 411 o operation: this element specifies the operation the CMCC wants to 412 perform according to the specific request type. 414 Besides those elements, the CMCC (let's say Alice, whose 'confUserID' 415 is 'xcon-userid:Alice@example.com') has also provided an additional 416 element, 'blueprintRequest'. The name of that element varies 417 according to the request type the CMCC is interested into. In this 418 specific scenario, the CMCC was interested in acquiring details 419 concerning a specific blueprint (identified by its XCON-URI 420 'xcon:AudioRoom@example.com', as reflected in the provided 421 'confObjID' target element), and so the request consisted in an empty 422 'blueprintRequest' element. As it will be clearer in the following 423 sections, different request types may require different elements and, 424 as a consequence, different content. 426 Considering the request was a 'blueprintRequest', the ConfS has 427 replied with a 'blueprintResponse' element. This element includes a 428 complete dump of the conference object (compliant with the Data 429 Model) describing the requested blueprint. 431 This section won't delve in additional details for what concerns this 432 interaction. It is just worth noticing that this was the example of 433 the simplest CCMP communication that could take place between a CMCC 434 and a ConfS, a blueprintRequest: this scenario will be described in 435 more detail in Section 5.2. 437 4.3. Conference Notifications 439 The XCON framework [RFC5239] presents several different possible 440 protocol interactions between a conferencing server and a 441 conferencing client. One of those interactions is generically called 442 "Notification Protocol", implementing a notification service for all 443 clients interested in being informed by the server whenever something 444 relevant happens in a conference. While at first glance it may 445 appear that such a functionality should belong to a conference 446 control protocol, such feature has been specifically marked as out of 447 scope in CCMP. As a consequence, CCMP has been conceived as a 448 request/answer protocol, and in fact no ways to provide notifications 449 to clients have been introduced in the specification. 451 Nevertheless, the CCMP document by itself has a brief section 452 presenting some typical ways notifications might be managed. This 453 example document does not foster one rather than another, and all the 454 flows will always generically present a notification being involved, 455 when it seems appropriate, but not providing any info on how the 456 notification itself has been sent to the interested clients. Anyway, 457 this section will briefly introduce some of the most typical ways a 458 notification service could be implemented and integrated with the 459 functionality provided by CCMP. It is by no means to be intended as 460 a complete list of solutions: the aim of this section is to provide 461 an overview of some of the possible solutions, together with 462 indications on how they may be integrated into a CCMP-based platform. 464 The first approach that comes to mind is of course the XCON Event 465 Package [I-D.ietf-xcon-event-package]. This specification extends 466 the SIP Event Package for Conference State [RFC4575] and allows for 467 the notification of conference notifications by means of the NOTIFY/ 468 SUBSCRIBE mechanisms of SIP. Specifically, any SIP client who 469 subscribed for notifications related to a specific conference would 470 receive notifications via SIP describing all the changes to the 471 document. An example ladder diagram is presented in Figure 2: in 472 this figure, we assume a CMCC has updated a conference object, and 473 the update is notified to a previously subscribed SIP client. 475 CMCC ConfS UAC 476 | | | 477 | | 1. SIP SUBSCRIBE | 478 | |<--------------------------| 479 | Handle +--| | 480 | new | | | 481 | subscription +->| 2. SIP 200 OK | 482 | |-------------------------->| 483 | | | 484 . . . 485 . . . 486 | | | 487 | 3. CCMP (add user) | | 488 |---------------------->| | 489 | |--+ Add user | 490 | | | to conf. | 491 | |<-+ object | 492 | 4. CCMP (success) | | 493 |<----------------------| | 494 | | 5. SIP NOTIFY (changes) | 495 | |-------------------------->| 496 | | 6. SIP 200 OK | 497 | |<--------------------------| 498 | | | 499 . . . 500 . . . 502 Figure 2: XCON Event Package: SIP notifications 504 While simple and effective, this solution has a drawback: it assumes 505 that all clients to be notified have a SIP stack. In fact, the 506 approach relies on the SIP SUBSCRIBE/NOTIFY mechanism. This means 507 that a client without a SIP stack would be unable to receive 508 notifications, in case no other means were available. Of course this 509 is not a desired situation in a framework as XCON which has been 510 conceived as being signalling protocol-agnostic. 512 Considering CCMP is going to be probably most often deployed on HTTP, 513 another way to achieve notifications might be by exploiting some sort 514 of HTTP callbacks, as suggested in the CCMP specification itself. 515 This would allow to overcome the previous limitation, since both the 516 CMCC and the ConfS would already have an HTTP stack to make use of. 517 Using this approach, an interested web client might provide the 518 Conferencing System with an URL to contact whenever updates are 519 available: the update could be part of the notification message 520 itself, or it could be only implicitly referenced by the 521 notification. At the same time, alternative notification means could 522 be exploited, e.g. by taking advantage of functionality provided by 523 other protocols such as XMPP. Figure 3 shows an example of different 524 subscriptions which accordingly trigger notifications after the same 525 relevant event happens. 527 CMCC ConfS Sub1 Sub2 528 | | | | 529 | | 1. Register callback | | 530 | |<--------------------------| | 531 | Handle +--| | | 532 | new HTTP | | | | 533 | subscription +->| 2. Acknlowledge | | 534 | |-------------------------->| | 535 | | | | 536 | | 3. XMPP subscription | 537 | |<---------------------------------------| 538 | Handle +--| | | 539 | new XMPP | | | | 540 | subscription +->| 4. XMPP confirm subscription | 541 | |--------------------------------------->| 542 | | | | 543 . . . . 544 . . . . 545 | | | | 546 | 5. CCMP (add user) | | | 547 |-------------------->| | | 548 | |--+ Add user | | 549 | | | to conf. | | 550 | |<-+ object | | 551 | 6. CCMP (success) | | | 552 |<--------------------| | | 553 | | 7. HTTP POST (changes) | | 554 | |-------------------------->| | 555 | | 8. HTTP 200 OK | | 556 | |<--------------------------| | 557 | | | | 558 | | 9. XMPP notification | | 559 | |--------------------------------------->| 560 | | | | 561 . . . . 562 . . . . 564 Figure 3: Alternative means for notifications 566 That said, there are actually many other ways to achieve 567 notifications in a conferencing system. A conferencing system may 568 rely on several other solutions than the ones presented as periodic 569 checks of a well known URL by interested clients, long polls, BOSH- 570 based communications, Atom/RSS feeds and the like. 572 5. Conference Creation 574 This section starts the sequence of call flows of typical XCON- 575 related scenarios provided in this document. Specifically, it 576 provides details associated with the various ways in which a 577 conference can be created using CCMP and the XCON framework 578 constructs. As previously mentioned, the details of the media 579 control, call signaling and floor control protocols, where 580 applicable, are annotated in the flows without showing all the 581 details. This also applies to CCMP, whose flows are related to the 582 protocol alone, hiding any detail concerning the transport that may 583 have been used (e.g. HTTP). However, for clarification purposes, 584 the first example Section 5.1 provides the details of the media 585 control messaging along with an example of the standard annotation 586 used throughout the remainder of this document. In subsequent flows, 587 only this annotation (identified by lower case letters) is included 588 and the reader is encouraged to refer to the call flows in the 589 relevant documents for details about the other protocols. The 590 annotations for the call signaling are on the left side of the 591 conferencing server vertical bar and those for the media control 592 messaging are on the right side. 594 5.1. Basic Conference Creation 596 The simplest manner in which a conference can be created is 597 accomplished by the client sending a "confRequest" message with the 598 "create" operation as the only parameter to the conference server, 599 together with the "confUserID" associated with the requesting client 600 itself. This results in the creation of a default conference, with 601 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID 602 in the form of the "confUserID" parameter (the same already present 603 in the request) and the data for the conference object in the 604 "confInfo" parameter all returned in the "confResponse" message. 605 According to the implementation of the framework, this example may 606 also add the issuing user to the conference upon creation (e.g., 607 "method" attribute in the element of 608 may be set to "dial out" for this client, based on the particular 609 conferencing systems default). This is exactly the case depicted in 610 the figure, which is presented to enrich the scenario. 612 The specific data for the conference object are returned in the 613 "confResponse" message in the "confInfo" parameter. This allows the 614 client (with the appropriate authorization) to manipulate these data 615 and add additional participants to the conference, as well as change 616 the data during the conference. In addition, the client may 617 distribute the conferencing information to other participants 618 allowing them to join, the details of which are provided in 619 additional flows. Please notice that, according to the CCMP 620 specification, the return of the new conference data in the 621 "confInfo" parameter is not mandatory: if the "confInfo" parameter of 622 the successful confResponse/create is void, a following confRequest/ 623 retrieve of the returned "confObjID" can be triggered to provide the 624 requesting client with the detailed conference description. 626 Clients that are not XCON-aware can join the conference using a 627 specific signaling interface such as SIP [RFC3261] (using the 628 signaling interface to the conference focus as described in 629 [RFC4579]), or other supported signaling protocols, being XCON 630 agnostic with respect to them. However, these details are not shown 631 in the message flows. The message flows in this document identify 632 the point in the message flows at which this signaling occurs via the 633 lower case letter items (i.e., (a)...(x)) along with the appropriate 634 text for the processing done by the conferencing server. 636 As anticipated at the beginning of this section, this example also 637 shows how the conferencing system may make use of other standard 638 components to make available its functionality. An example of that 639 is the MEDIACTRL specification, which allows the conferencing system 640 to configure conference mixes, IVR dialogs and all sort of media- 641 related interactions an application like this may need. So, just to 642 provide the reader with some insight on these interactions, the 643 conferencing system also configures and starts a mixer via MEDIACTRL 644 as soon as the conference is created (transactions A1 and A2), and 645 attaches clients to it when necessary (e.g. when CMCC1 joins the 646 conference by means of SIP signaling, its media channels are attached 647 to the Media Server using MEDIACTRL in B1/B2). 649 CMCC1 CMCC2 CMCCx ConfS MS 650 | | | | | 651 |(1)confRequest(confUserID, create) | | 652 |-------------------------------------->| | 653 | | (a)Create +---| | 654 | | |Conf | | | 655 | | |Object | | | 656 | | |& IDs +-->| | 657 | | | | A1. CONTROL | 658 | | | |+++++++++++>>| 659 | | | |(create conf)|--+ (b) 660 | | | | | | create 661 | | | | | | conf and 662 | | | | A2. 200 OK |<-+ its ID 663 | | | |<<+++++++++++| 664 | | | |(confid=Y) | 665 |(2)confResponse(confUserID,confObjID, | | 666 | create, 200, success, | | 667 | version, confInfo) | | 668 |<--------------------------------------| | 669 | | | | | 670 | | (c) Focus +---| | 671 | | sets up | | | 672 | | signaling | | | 673 | | to CMCC1 +-->| | 674 | | | | | 675 | | | | B1. CONTROL | 676 | | | |+++++++++++>>| 677 | | | | (join CMCC1 | 678 | | | | <->confY) | 679 | | | | | 680 | | | | |--+(d) join 681 | | | | | | CMCC1 & 682 | | | | B2.200 OK |<-+ conf Y 683 | | | |<<+++++++++++| 684 | | | | | 685 |<<#################################################>>| 686 | Now the CMCC1 is mixed in the conference | 687 |<<#################################################>>| 688 | | | | | 689 |******CMCC1 may then manipulate conference data *****| 690 |****** and add addt'l users, etc. | *****| 691 ' ' ' ' ' 692 ' ' ' ' ' 693 ' ' ' ' ' 694 Figure 4: Create Basic Conference - Complete flow 696 "Alice" "Bob" 697 CMCC1 CMCC2 CMCCx ConfS 698 | | | | 699 |(1)confRequest(confUserID, create) | 700 |-------------------------------------->| 701 | | | | 702 | | (a)Create +---| 703 | | |Conf | | 704 | | |Object | | 705 | | |& IDs +-->| 706 | | | |--+ (b) MS 707 | | | | | creates 708 | | | | | conf and 709 | | | |<-+ its ID 710 | | | | (confid=Y) 711 |(2)confResponse(confUserID, confObjID | 712 | create, 200, success, | 713 | version, confInfo) | 714 | | | | 715 |<--------------------------------------| 716 | | | | 717 | | | | 718 | | (c) Focus +---| 719 | | sets up | | 720 | | signaling | | 721 | | to CMCC1 +-->| 722 | | | | 723 | | | |--+(d) MS joins 724 | | | | | CMCC1 & 725 | | | |<-+ conf Y 726 |<<###################################>>| 727 | CMCC1 is mixed in the conference | 728 |<<###################################>>| 729 | | | | 730 |**CMCC1 then manipulates conference****| 731 |** data and add addt'l users, etc. ***| 732 ' ' ' ' 733 ' ' ' ' 734 ' ' ' ' 735 - 737 Figure 5: Create Basic Conference - Annotated Flow 739 1. confRequest/create message (Alice creates a default conference) 741 742 746 749 xcon-userid:Alice@example.com 750 create 751 752 753 755 2. confResponse/create message ("success", created conference 756 object returned) 758 759 763 766 xcon-userid:Alice@example.com 767 xcon:8977794@example.com 768 create 769 200 770 success 771 1 772 773 774 775 776 Default conference initiated by Alice 777 778 779 780 781 xcon:8977794@example.com 782 783 784 Conference XCON-URI 785 787 788 789 10 790 791 792 793 audio 794 795 796 797 false 798 799 800 801 allow 802 803 805 806 807 808 809 810 812 Figure 6: Create Basic Conference (Annotated) Detailed Messaging 814 5.2. Conference Creation using Blueprints 816 The previous example showed the creation of a new conference using 817 default values. This means the client provided no information about 818 how she wanted the conference to be like. Anyway, the XCON framework 819 (and CCMP as a consequence) allows for the exploitation of templates. 820 These templates are called "conference blueprints", and are basically 821 conference objects with pre-defined settings. This means that a 822 client might get one of these blueprints, choose the one that more 823 fits his needs, and use the chosen blueprint to create a new 824 conference. 826 This section addresses exactly this scenario, and Figure 7 provides 827 an example of one client, "Alice", discovering the conference 828 blueprints available for a particular conferencing system and 829 creating a conference based on the desired blueprint. In particular, 830 Alice is interested in those blueprints suitable to represent a 831 "video-conference", i.e. a conference in which both audio and video 832 are available, so she exploits the filter mechanism envisioned by 833 CCMP to make a selective blueprints retrieve request. This results 834 in three distinct CCMP transactions. 836 CMCC "Alice" ConfS 837 | | 838 | (1) blueprintsRequest | 839 | (confUserID,xpathFilter) | 840 |------------------------------>| 841 | | 842 | (2) blueprintsResponse | 843 | (confUserID, | 844 | 200, success, | 845 | blueprintsInfo) | 846 | | 847 |<------------------------------| 848 | | 849 |--+ | 850 | | choose preferred | 851 | | blueprint from the | 852 | | list (blueprintName) | 853 |<-+ | 854 | | 855 | (3) blueprintRequest | 856 | (confUserID,confObjID, | 857 | retrieve) | 858 |------------------------------>| 859 | | 860 | 4) blueprintResponse | 861 | (confUserID,confObjID,| 862 | retrieve, 200, | 863 | success, confInfo) | 864 |<------------------------------| 865 | | 866 | (5) confRequest(confUserID, | 867 | confObjID,create) | 868 |------------------------------>| 869 | | 870 | (a)Create +---| 871 | Conf | | 872 | Object | | 873 | & IDs +-->| 874 | |--+ (b) MS 875 | | | creates 876 | | | conf and 877 | |<-+ its ID 878 | | (confid=Y) 879 |(6) confResponse | 880 | (confUserID, confObjID*, | 881 | create, 200, success) | 882 |<------------------------------| 883 | | 884 | | 885 | | 886 . . 887 . . 889 Figure 7: Client Creation of Conference using Blueprints 891 1. Alice first sends a "blueprintsRequest" message to the 892 conferencing system identified by the conference server discovery 893 process. This request contains the "confUserID" of the user 894 issuing the request (Alice's XCON-USERID) and the "xpathFilter" 895 parameter by which Alice specifies she desires to obtain only 896 blueprints providing support for both audio and video: for this 897 purpose, the xpath query contained in this field is: "/ 898 conference-info[conference-description/available-media/entry/ 899 type='audio' and conference-description/available-media/entry/ 900 type='video'"] . Upon receipt of the "blueprintsRequest", the 901 conferencing system would first control, on the basis of the 902 "confUserID" parameter, that Alice has the appropriate authority 903 based on system policies to receive the requested kind of 904 blueprints supported by that system. 906 2. All blueprints that Alice is authorized to use are returned in a 907 "blueprintsResponse" message in the "blueprintsInfo" element. 909 3. Upon receipt of the "blueprintsResponse" containing the 910 blueprints, Alice determines which blueprint to use for the 911 conference to be created. Alice sends a "blueprintRequest" 912 message to get the specific blueprint as identified by the 913 "confObjID". 915 4. The conferencing system returns the "confInfo" associated with 916 the specific blueprint as identified by the "confObjID" in the 917 "blueprintResponse" message. 919 5. Alice finally sends a "confRequest" with a "create" operation to 920 the conferencing system to create a conference reservation 921 cloning the chosen blueprint. This is achieved by writing the 922 blueprint's XCON-URI in the "confObjID" parameter. 924 6. Upon receipt of the "confRequest" message with a "create" 925 operation, the conferencing system uses the received blueprint to 926 clone a conference, allocating a new XCON-URI (again called 927 "confObjID*" in the example). The conferencing server then sends 928 a "confResponse" message including the new "confObjID*" 929 associated with the newly created conference instance. Upon 930 receipt of the "confResponse" message, Alice can now add other 931 users to the conference . 933 1. blueprintsRequest message (Alice requires the list of the 934 available blueprints with video support) 936 937 941 944 xcon-userid:Alice@example.com 945 946 /conference-info 947 [conference-description/ 948 available-media/entry/type='audio' and 949 conference-description/available-media/ 950 entry/type='video'] 951 952 953 954 956 2. blueprintsResponse message (the server provides a 957 descriptions of the available blueprints 958 fitting Alice's request) 960 961 965 968 xcon-userid:Alice@example.com 969 200 970 success 971 972 973 974 xcon:VideoRoom@example.com 975 VideoRoom 976 Video Room: 977 conference room with public access, 978 where both audio and video are available, 979 4 users can talk and be seen at the same time, 980 and the floor requests are automatically accepted. 981 982 983 984 xcon:VideoConference1@example.com 985 986 VideoConference1 987 988 Public Video Conference: conference 989 where both audio and video are available, 990 only one user can talk 991 992 993 994 995 996 998 3. blueprintRequest/retrieve message (Alice wants the 999 "VideoRoom" blueprint) 1001 1002 1006 1009 xcon-userid:Alice@example.com 1010 xcon:VideoRoom@example.com 1011 retrieve 1012 1013 1015 1017 4. blueprintResponse/retrieve message ("VideoRoom" 1018 conference object returned) 1020 1021 1025 1028 xcon-userid:Alice@example.com 1029 xcon:VideoRoom@example.com 1030 retrieve 1031 200 1032 success 1033 1034 1035 1036 VideoRoom 1037 4 1038 1039 1040 audio 1041 1042 1043 video 1044 1045 1046 1047 1048 allow 1049 1050 1051 confirm 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1063 5. confRequest/create message (Alice clones the "VideoRoom" blueprint) 1065 1066 1070 1073 xcon-userid:Alice@example.com 1074 xcon:VideoRoom@example.com 1075 create 1076 1077 1078 1080 6. confResponse/create message (cloned conference 1081 object returned) 1083 1084 1088 1091 xcon-userid:Alice@example.com 1092 xcon:8977794@example.com 1093 create 1094 200 1095 success 1096 1 1097 1098 1099 1100 1101 New conference by Alice cloned from VideoRoom 1102 1103 1104 1105 1106 xcon:8977794@example.com 1107 1108 1109 conference xcon-uri 1111 1112 1113 8601 1114 1115 1116 1117 10 1118 1119 1120 1121 audio 1122 1123 1124 video 1125 1126 1127 1128 1129 allow 1130 1131 1132 1133 confirm 1134 1135 1136 1137 1138 1139 1140 1141 1142 1144 Figure 8: Create Conference (Blueprint) Detailed Messaging 1146 5.3. Conference Creation using User-Provided Conference Information 1148 A conference can also be created by the client sending a 1149 "confRequest" message with the "create" operation, along with the 1150 desired data in the form of the "confInfo" parameter for the 1151 conference to be created. The request also includes the "confUserID" 1152 of the requesting entity. 1154 This approach allows for a client (in this example Alice) to 1155 completely describe how the conference object should look like, 1156 without just relying on defaults or blueprints: i.e. which media 1157 should be available, which should be the topic, the users allowed to 1158 join, any scheduling-related information and so on. This can be 1159 done, as anticipated, by providing in the creation request a full 1160 conference object for the server to parse. 1162 This "confInfo" parameter must comply of course with the Data Model 1163 specification. This means that its "entity" attribute is mandatory, 1164 and cannot be missing in the document. Nevertheless, considering in 1165 this example the client is actually requesting the creation of a new 1166 conference, which doesn't exist yet, this "entity" attribute cannot 1167 be set to a valid value. This is related to an issue already 1168 anticipated in Section 4.1. To cope with this, the CCMP protocol 1169 fosters the use of a wildcard placeholder: this placeholder 1170 ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim 1171 of making the "confInfo" element compliant with the Data Model, and 1172 would subsequently be replaced by the conferencing system with the 1173 actual value. This means that, as soon as the conferencing system 1174 actually creates the conference, a valid "entity" value is created 1175 for it as well, which would take the place of the wildcard when 1176 completing the actual conference object provided by the client. 1178 To give a flavour of what could be added to the conference object, we 1179 assume Alice is also interested in providing scheduling-related 1180 information. So, in this example, Alice also specifies by the 1181 element included in the "confInfo" that the 1182 conference she wants to create has to occur on a certain date 1183 spanning from a certain start time to a certain stop time and has to 1184 be replicated weekly. 1186 Moreover, Alice indicates by means of the that 1187 at the start time Bob, Carol and herself have to be called by the 1188 conferencing system to join the conference (in fact, for each 1189 corresponding to one of the above-mentioned clients, the 1190 "method" attribute is set to "dial-out"). 1192 Once Alice has prepared the "confInfo" element and sent it as part of 1193 her request to the server, if the conferencing system can support 1194 that specific type of conference (capabilities, etc.), then the 1195 request results in the creation of a conference. We assume the 1196 request has been successful, and as a consequence XCON-URI in the 1197 form of the "confObjID" parameter and the XCON-USERID in the form of 1198 the "confUserID" parameter (again, the same as the requesting entity) 1199 are returned in the "confResponse" message. 1201 In this example, we choose not to return the created conference 1202 object in the successful "confResponse" in the "confInfo" parameter. 1203 Nevertheless, Alice could still retrieve the actual conference object 1204 by issuing a "confRequest" with a "retrieve" operation on the 1205 returned "confObjID". Such a request would show how, as we 1206 anticipated at the beginning of this section, the "entity" attribute 1207 of the conference object in "confInfo" is replaced with the actual 1208 information (i.e. "xcon:6845432@example.com"). 1210 Alice Bob Carol ConfS 1211 | | | | 1212 | | | | 1213 |(1)confRequest(confUserID, | | 1214 | create, confInfo) | | 1215 | | | | 1216 |-------------------------------------->| 1217 | | | | 1218 | | (a)Create +---| 1219 | | |Conf | | 1220 | | |Object | | 1221 | | |& IDs +-->| 1222 | | | |--+ (b) MS 1223 | | | | | creates 1224 | | | | | conf and 1225 | | | |<-+ its ID 1226 | | | | (confid=Y) 1227 |(2)confResponse(confUserID,| | 1228 | confObjID, create, | | 1229 | 200, success, version) | 1230 |<--------------------------------------| 1231 | | | | 1232 =========================================== 1233 ... ... ... ... 1234 ========== START TIME OCCURS ============== 1235 | | (c) Focus +---| 1236 | | sets up | | 1237 | | signaling | | 1238 | | to Alice +-->| 1239 | | | | 1240 | | | |--+(d) MS joins 1241 | | | | | Alice & 1242 | | | |<-+ conf Y 1243 | | | | 1244 | | | | 1245 |<<###################################>>| 1246 | Alice is mixed in the conference | 1247 |<<###################################>>| 1248 | | | | 1249 | | (e)Focus +---| 1250 | | sets up | | 1251 | | signaling | | 1252 | | to Bob | | 1253 | | | +-->| 1254 | | | | 1255 | | | |--+(f)MS joins 1256 | | | | | Bob & 1257 | | | |<-+ conf Y 1258 | | | | 1259 | |<<###################>>| 1260 | | Bob is mixed too | 1261 | |<<###################>>| 1262 | | | | 1263 | | (g )Focus +---| 1264 | | sets up | | 1265 | | signaling | | 1266 | | to Carol | | 1267 | | CMCCx +-->| 1268 | | | | 1269 | | | |--+(h)MS joins 1270 | | | | | CMCCx & 1271 | | | |<-+ conf Y 1272 | | | | 1273 | | |<<#######>>| 1274 | | |Carol mixed| 1275 | | |<<#######>>| 1276 | | | | 1277 | | | | 1278 | | | | 1279 |<***All parties connected to conf Y***>| 1280 | | | | 1281 | | | | 1282 " " " " 1283 " " " " 1284 " " " " 1286 Figure 9: Create Basic Conference from user provided conference-info 1288 1. confRequest/create message (Alice proposes a conference object 1289 to be created) 1291 1292 1297 1300 xcon-userid:Alice@example.com 1301 create 1302 1303 1304 1305 1306 Dial-out conference initiated by Alice 1307 1308 10 1309 1310 1311 1312 audio 1313 1314 1315 1316 1317 1318 BEGIN:VCALENDAR 1319 VERSION:2.0 1320 PRODID:-//Mozilla.org/NONSGML 1321 Mozilla Calendar V1.0//EN 1322 BEGIN:VEVENT 1323 DTSTAMP: 20100127T140728Z 1324 UID: 20100127T140728Z-345FDA-alice@example.com 1325 ORGANIZER:MAILTO:alice@example.com 1326 DTSTART:20100127T143000Z 1327 RRULE:FREQ=WEEKLY 1328 DTEND: 20100127T163000Z 1329 END:VEVENT 1330 END:VCALENDAR 1331 1332 1334 2010-01-27T14:29:00Z 1335 1336 1338 2010-01-27T16:31:00Z 1339 1340 1341 2010-01-27T15:30:00Z 1342 1343 1344 1346 1347 1348 allow 1349 1350 1352 1354 1356 1357 1358 1359 1360 1361 1363 2. confResponse/create message (200, "success") 1365 1366 1370 1373 xcon-userid:Alice@example.com 1374 xcon:6845432@example.com 1375 create 1376 200 1377 success 1378 1 1379 1380 1382 Figure 10: Create Basic Conference Detailed Messaging 1384 5.4. Cloning an Existing Conference 1386 A client can also create another conference by cloning an existing 1387 conference, such as an active conference or conference reservation. 1388 This approach can be seen as a logical extension of the creation of a 1389 new conference using a blueprint: the difference is that, instead of 1390 cloning the pre-defined settings listed in a blueprint, the settings 1391 of an existing conference would be cloned. 1393 In this example, the client sends a "confRequest" message with the 1394 "create" operation, along with the "confUserID" and a specific 1395 "confObjID", from which a new conference is to be created by cloning 1396 an existing conference. 1398 An example of how a client can create a conference based on a 1399 blueprint is provided in Section 5.2. The manner by which a client 1400 in this example might learn about a conference reservation or active 1401 conferences is similar to the first step in the blueprint example, 1402 with the exception of querying for different types of conference 1403 objects supported by the specific conferencing system. For example, 1404 in this example, the client clones a conference reservation (i.e., an 1405 inactive conference). 1407 If the conferencing system can support a new instance of the specific 1408 type of conference (capabilities, etc.), then the request results in 1409 the creation of a conference, with an XCON-URI in the form of a new 1410 value in the "confObjID" parameter to reflect the newly cloned 1411 conference object returned in the "confResponse" message. 1413 Alice ConfS 1414 | | 1415 |(1)confRequest(confUserID, | 1416 | confObjID, create) | 1417 |------------------------------>| 1418 | (a)Create +---| 1419 | Conf | | 1420 | Object | | 1421 | & IDs +-->| 1422 | |--+ (b) MS 1423 | | | creates 1424 | | | conf and 1425 | |<-+ its ID 1426 | | (confid=Y) 1427 | | 1428 |(2)confResponse(confUserID, | 1429 | confObjID*,create, | 1430 | 200, success, | 1431 | version, confInfo) | 1432 | | 1433 |<------------------------------| 1434 | | 1435 Figure 11: Create Basic Conference - Clone 1437 1. Alice, a conferencing system client, sends a confRequest message 1438 to clone a conference based on an existing conference 1439 reservation. Alice indicates this conference should be cloned 1440 from the specified parent conference represented by the 1441 "confObjID" in the request. 1443 2. Upon receipt of the confRequest message containing a "create" 1444 operation and "confObjID", the conferencing system ensures that 1445 the "confObjID" received is valid. The conferencing system 1446 determines the appropriate read/write access of any users to be 1447 added to a conference based on this "confObjID" (using 1448 membership, roles, etc.). The conferencing system uses the 1449 received "confObjID" to clone a conference reservation. The 1450 conferencing system also reserves or allocates a new "confObjID" 1451 (called "confObjID*" in Figure 11) to be used for the cloned 1452 conference object. This new identifier is of course different 1453 from the one associated with the conference to be cloned, since 1454 it represents a different conference object. Any subsequent 1455 protocol requests from any of the members of the conference must 1456 use this new identifier. The conferencing system maintains the 1457 mapping between this conference ID and the parent conference 1458 object ID associated with the reservation through the conference 1459 instance, and this mapping is explicitly addressed through the 1460 "cloning-parent" element of the "conference-description" in the 1461 new conference object. 1463 1. confRequest/create message (Alice clones an existing conference) 1465 1466 1470 1473 xcon-userid:Alice@example.com 1474 xcon:6845432@example.com 1475 create 1476 1477 1479 2. confResponse/create message (created conference 1480 object returned) 1482 1483 1487 1490 xcon-userid:Alice@example.com 1491 xcon:8977794@example.com 1492 create 1493 200 1494 success 1495 1 1496 1497 1498 1499 1500 New conference by Alice cloned from 6845432 1501 1502 1503 xcon:6845432@example.com 1504 1505 10 1506 1507 1508 1509 audio 1510 1511 1512 1513 1514 allow 1515 1516 1518 1520 1522 1523 1524 1525 1526 confirm 1528 1529 1530 1531 1532 1533 1534 1535 1537 Figure 12: Create Basic Conference (Clone) Detailed Messaging 1539 6. Conference Users Scenarios and Examples 1541 Section 5 showed examples describing the several different ways a 1542 conference might be created using CCMP. This section instead focuses 1543 on user-related scenarios, i.e. typical scenarios that may occur 1544 during the lifetime of a conference, like adding new users and 1545 handling their media. The following scenarios are based on those 1546 documented in the XCON framework. The examples assume that a 1547 conference has already been correctly established, with media, if 1548 applicable, per one of the examples in Section 5. 1550 6.1. Adding a Party 1552 In this example, Alice wants to add Bob to an established conference. 1553 In the following example we assume Bob is a new user of the system, 1554 which means Alice also needs to provide some details about him. In 1555 fact, the case of Bob already present as a user in the conferencing 1556 system is much easier to address, and will be discussed later on. 1558 "Alice" "Bob" 1559 CMCC1 CMCC2 CMCCx ConfS 1560 | | | | 1561 |(1) userRequest(confUserID,| | 1562 | confObjID, create, | | 1563 | userInfo) | | | 1564 |-------------------------------------->| 1565 | | | | 1566 | | (a) Create +---| 1567 | | | Bob | | 1568 | | | as a | | 1569 | | | user +-->| 1570 | | | | 1571 |(2) userResponse(confUserID, confObjID | 1572 | create, 200, success, userInfo) | 1573 |<--------------------------------------| 1574 | | | | 1575 | | | (b) Focus | 1576 | | | sets up | 1577 | | | signaling | 1578 | | | to Bob | 1579 | |<----------------------| 1580 | | | | 1581 | | | (c) Notify| 1582 | | | ("Bob just| 1583 | | | joined") | 1584 | | |<----------| 1585 | | | | 1586 ' ' ' ' 1587 ' ' ' ' 1588 ' ' ' ' 1590 Figure 13: Client Manipulation of Conference - Add a party 1592 1. Alice sends a userRequest message with an operation of "create" 1593 to add Bob to the specific conference as identified by the 1594 "confObjID". The "create" operation also makes sure that Bob is 1595 created as a user in the whole conferencing system. This is done 1596 by adding in the request a "userInfo" element describing Bob as a 1597 user. This is needed in order to let the conferencing system be 1598 aware of Bob's characteristics. In case Bob was already a 1599 registered user, Alice would just have referenced him through his 1600 XCON-USERID in the "entity" attribute of the "userInfo" field, 1601 without providing additional data. In fact, that data 1602 (including, for instance, Bob's SIP-URI to be used subsequently 1603 for dial-out) would be obtained by referencing the extant 1604 registration. The conference server ensures that Alice has the 1605 appropriate authority based on the policies associated with that 1606 specific conference object to perform the operation. As 1607 mentioned before, a new Conference User Identifier is created for 1608 Bob, and the "userInfo" is used to update the conference object 1609 accordingly. As already seen in Section 5.3, a placeholder 1610 wildcard ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP 1611 messages below) is used for the "entity" attribute of the 1612 "userInfo" element, to be replaced by the actual XCON-USERID 1613 later on; 1615 2. Bob is successfully added to the conference object, and an XCON- 1616 USERID is allocated for him ("xcon-userid:Bob@example.com"); this 1617 identifier is reported in the response as part of the "entity" 1618 element of the returned "userInfo"; 1620 3. In the presented example, the call signaling to add Bob to the 1621 conference is instigated through the Focus as well. We again 1622 remind that this is implementation specific. In fact, a 1623 conferencing system may accomplish different actions after the 1624 user creation, just as it may do nothing at all. Among the 1625 possible actions, for instance, Bob may be added as a 1626 element to the element, whose joining 1627 "method" may be either "dial-in" or "dial-out". Besides, out-of- 1628 band notification mechanisms may be involved as well, e.g. to 1629 notify Bob via mail of the new conference, including details as 1630 the date, password, expected participants and so on (see 1631 Section 4.3). 1633 To conclude the overview on this scenario, once Bob has been 1634 successfully added to the specified conference, per updates to the 1635 state, and depending upon the policies, other participants 1636 (including Bob himself) may be notified of the addition of Bob to 1637 the conference via the Conference Notification Service in use. 1639 1. userRequest/create message (Alice adds Bob) 1641 1642 1646 1649 xcon-userid:Alice@example.com 1650 xcon:8977878@example.com 1651 create 1652 1653 1654 Bob 1655 1656 1657 mailto:bob.depippis@example.com 1658 1659 Bob's email 1660 1661 1662 1663 1664 Bob's laptop 1665 1666 1667 1668 1669 1670 1672 2. userResponse/create message (a new XCON-USERID is 1673 created for Bob and he is added to the conference) 1675 1676 1680 1683 xcon-userid:Alice@example.com 1684 xcon:8977878@example.com 1685 create 1686 200 1687 success 1688 10 1689 1690 1691 Bob 1692 1693 1694 mailto:bob.depippis@example.com 1695 1696 Bob's email 1697 1699 1700 1701 1702 Bob's laptop 1703 1704 1705 1706 1707 1708 1710 Figure 14: Add Party Message Details 1712 6.2. Muting a Party 1714 This section provides an example of the muting of a party in an 1715 active conference. We assume that the user to mute has already been 1716 added to the conference. The document only addresses muting and not 1717 unmuting as well, since it would involve an almost identical CCMP 1718 message flow anyway. Although, in case that any external floor 1719 control is involved, whether or not a particular conference client 1720 can actually mute/unmute itself must be considered by the 1721 conferencing system. 1723 Please notice that interaction between CCMP and floor control 1724 should be carefully considered. In fact, handling CCMP- and BFCP- 1725 based media control has to be considered as multiple layers: i.e., 1726 a participant may have the BFCP floor granted, but be muted by 1727 means of CCMP. If so, he would still be muted in the conference, 1728 and would only be unmuted if both the protocols allowed for this. 1730 Figure 15 provides an example of one client, "Alice", impacting the 1731 media state of another client, "Bob". This example assumes an 1732 established conference. In this example, Alice, whose role is 1733 "moderator" of the conference, wants to mute Bob on a medium-size 1734 multi-party conference, as his device is not muted (and he's 1735 obviously not listening to the call) and background noise in his 1736 office environment is disruptive to the conference. BFCP floor 1737 control is assumed not to be involved. 1739 From a protocol point of view, muting/unmuting an user basically 1740 consists in updating the conference object by modifying the settings 1741 related to the target user's media streams. Specifically, Bob's 1742 "userInfo" must be updated by modifying its audio 1743 information (e.g. setting it to "recvonly" in case of muting), 1744 identified by the right media id. 1746 "Alice" "Bob" 1747 CMCC1 CMCC2 CMCCx ConfS MS 1748 | | | | | 1749 |(1) userRequest(subject, | | | 1750 | confUserID,confObjID, | | | 1751 | update,userInfo) | | | 1752 | | | | | 1753 |--------------------------------------->| | 1754 | | | | Mute Bob | 1755 | | | |----------------->| 1756 | | | | 200 OK | 1757 | | | |<-----------------| 1758 | | | | | 1759 | |<====== XXX Bob excluded from mix XXX ====>| 1760 | | | | | 1761 | | (a) Update +---| | 1762 | | Bob in | | | 1763 | | Data Model | | | 1764 | | (muted) +-->| | 1765 | | | | | 1766 | (2)userResponse(confUserID,confObjID, | | 1767 | update,200,success,version) | | 1768 |<---------------------------------------| | 1769 | | | | | 1770 | | | (b) Notify | | 1771 | | | ("Bob is | | 1772 | | | muted") | | 1773 | | |<-----------| | 1774 | | | | | 1775 ' ' ' ' ' 1776 ' ' ' ' ' 1777 ' ' ' ' ' 1779 Figure 15: Client Manipulation of Conference - Mute a party 1781 1. Alice sends a userRequest message with an "update" operation and 1782 the userInfo with the "status" field in the "media" element for 1783 Bob's set to "revconly". In order to authenticate 1784 herself, Alice provides in the "subject" request parameter her 1785 registration credentials (i.e. username and password). The 1786 "subject" parameter is an optional one: its use can be systematic 1787 whenever the conferencing server envisages to authenticate each 1788 requestor. In such cases, if the client does not provide the 1789 required authentication information, the conferencing server 1790 answers with a CCMP "authenticationRequired" response message, 1791 indicating that the request cannot be processed without including 1792 the proper "subject" parameter. The Conference Server ensures 1793 that Alice has the appropriate authority based on the policies 1794 associated with that specific conference object to perform the 1795 operation. It recognizes that Alice is allowed to request the 1796 specified modification, since she is moderator of the target 1797 conference, and updates the "userInfo" in the conference object 1798 reflecting that Bob's media is not to be mixed with the 1799 conference media. In case the Conference Server relies on a 1800 remote Media Server for its multimedia functionality, it 1801 subsequently changes Bob's media profile accordingly by means of 1802 the related protocol interaction with the MS to enforce the 1803 decision. An example describing a possible way of dealing with 1804 such a situation using the Media Server Control architecture is 1805 described in [I-D.ietf-mediactrl-call-flows], at "Simple 1806 Bridging: Framework Transactions (2)". 1808 2. A userResponse message with a "200" response-code ("success") is 1809 then sent to Alice. Depending upon the policies, the conference 1810 server may notify other participants (including Bob) of this 1811 update via any Conference Notification Service that may be in 1812 use. 1814 1. userRequest/update message (Alice mutes Bob) 1816 1817 1821 1824 1825 Alice83 1826 13011983 1827 1828 xcon-userid:Alice@example.com 1829 xcon:8977878@example.com 1830 update 1831 1832 1833 1834 1835 123 1836 recvonly 1837 1839 1840 1841 1842 1843 1844 1846 2. userResponse/update message (Bob has been muted) 1848 1849 1853 1856 xcon-userid:Alice@example.com 1857 xcon:8977878@example.com 1858 update 1859 200 1860 success 1861 7 1862 1863 1864 1866 Figure 16: Mute Message Details 1868 6.3. Conference Announcements and Recordings 1870 This section deals with features that are typically required in a 1871 conferencing system, that are public announcements (e.g. to notify 1872 vocally that a new user joined a conference) and name recording. 1873 While this is not strictly CCMP-related (the CCMP signaling is 1874 actually the same as the one seen in Section 6.1) it is an 1875 interesting scenario to address to see how the several components of 1876 an XCON-compliant architecture interact with each other to make it 1877 happen. 1879 In this example, as shown in Figure 17 Alice is joining Bob's 1880 conference that requires that she first enters a pass code. After 1881 successfully entering the pass code, an announcement prompts Alice to 1882 speak her name so it can be recorded. When Alice is added to the 1883 active conference, the recording is played back to all the existing 1884 participants. A very similar example is presented in Figure 33 of 1885 [I-D.ietf-mediactrl-call-flows]. 1887 CMCC "Alice" ConfS MS 1888 | | | 1889 |(1)userRequest(confObjID, | | 1890 | create,userInfo) | | 1891 |--------------------------->| | 1892 | |--+ Alice is | 1893 | | | new in the | 1894 | |<-+ system (create | 1895 | | confUserID) | 1896 | ConfS handles +--| | 1897 | SIP signaling | | | 1898 | (Alice<->ConfS<->MS) +->| | 1899 | | | 1900 | |--+ A password is | 1901 | | | required for | 1902 | |<-+ that conference | 1903 | | | 1904 | | Request IVR menu (PIN) | 1905 | |--------------------------->| 1906 | | | 1907 |<========= MS gets PIN from Alice through DTMF =========>| 1908 | | | 1909 | | Provided PIN is... | 1910 | |<---------------------------| 1911 | Check +--| | 1912 | PIN | | | 1913 | +->| | 1914 | |--+ Alice must | 1915 | | | record her | 1916 | |<-+ name | 1917 | | | 1918 | | Request name recording | 1919 | |--------------------------->| 1920 | | | 1921 |<========= MS records Alice's audio RTP (name) =========>| 1922 | | | 1923 | | Audio recording | 1924 | |<---------------------------| 1925 | Complete +--| | 1926 | creation | | | 1927 | of Alice +->| | 1928 | | | 1929 | | | 1930 | (2)userResponse(confUserID,| | 1931 | confObjID,create,200,| | 1932 | success,version) | | 1933 |<---------------------------| | 1934 | | | 1935 Figure 17: Recording and Announcements 1937 1. Upon receipt of the userRequest from Alice to be added to Bob's 1938 conference, the conferencing system determines that a password is 1939 required for this specific conference. Thus an announcement 1940 asking Alice to enter the password is sent back. This may be 1941 achieved by means of typical IVR functionality. Once Alice 1942 enters the password, it is validated against the policies 1943 associated with Bob's active conference. The conferencing system 1944 then connects to a server which prompts and records Alice's name. 1945 The conferencing system must also determine whether Alice is 1946 already a user of this conferencing system or whether she is a 1947 new user. In this case, Alice is a new user for this 1948 conferencing system, so a Conference User Identifier (i. e. an 1949 XCON-USERID) is created for Alice. Based upon the contact 1950 information provided by Alice, the call signaling to add Alice to 1951 the conference is instigated through the Focus. 1953 2. The conference server sends Alice a userResponse message which 1954 includes the "confUserID" assigned by the conferencing system to 1955 her. This would allow Alice to later perform operations on the 1956 conference (if she were to have the appropriate policies), 1957 including registering for event notifications associated with the 1958 conference. Once the call signaling indicates that Alice has 1959 been successfully added to the specific conference, per updates 1960 to the state, and depending upon the policies, other participants 1961 (e.g., Bob) are notified of the addition of Alice to the 1962 conference via the conference notification service and an 1963 announcement is provided to all the participants indicating that 1964 Alice has joined the conference. 1966 1. userRequest/create message (A new conferencing system client, 1967 Alice, enters Bob's conference) 1969 1970 1974 1977 xcon:bobConf@example.com 1978 create 1979 1980 1981 1982 1983 1984 mailto:Alice83@example.com 1985 1986 email 1987 1988 1989 1990 1991 1992 1993 1995 2. userResponse/create (Alice provided with a new xcon-userid 1996 and added to the conference) 1998 1999 2003 2006 xcon-userid:Alice@example.com 2007 xcon:bobConf@example.com 2008 create 2009 200 2010 success 2011 5 2012 2013 2014 2016 Figure 18: Announcement Messaging Details 2018 6.4. Monitoring for DTMF 2020 Conferencing systems often also need the capability to monitor for 2021 DTMF from each individual participant. This would typically be used 2022 to enter the identifier and/or access code for joining a specific 2023 conference. This feature is often also exploited to achieve 2024 interaction between participants and the conference system for non- 2025 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted). 2027 An example of DTMF monitoring, within the context of the framework 2028 elements, is shown in Figure 17. A typical way for the conferencing 2029 system to be aware of all the DTMF interactions within the context of 2030 conferences it is responsible for, is making use of the MEDIACTRL 2031 architecture for what regards media manipulation. Examples in that 2032 sense (specifically for what concerns DTMF interception in conference 2033 instances) are presented in [I-D.ietf-mediactrl-call-flows]. 2035 6.5. Entering a password-protected conference 2037 Some conferences may envision a password to be provided by a user who 2038 wants to manipulate the relative conference objects (e.g. join, 2039 update, delete) via CCMP. Such a password would be included in the 2040 element related to the conference XCON-URI in 2041 the appropriate entry and must be then included in 2042 the apposite "conference-password" field in the CCMP request 2043 addressed to that conference. 2045 In the following CCMP transactions, it is depicted a scenario in 2046 which Alice, a conferencing system client, attempts to join a 2047 password-protected conference. 2049 1. Alice sends a userRequest message with a "create" operation to 2050 add herself in the conference with XCON-URI 2051 "xcon:8977777@example.com" (written in the "confObjID" 2052 parameter). Alice provides her XCON-USERID via the "confUserID" 2053 field of the userRequest and leaves out the "userInfo" one 2054 (first-party join). In this first attempt, she doesn't insert 2055 any password parameter. 2057 2. Upon receipt the userRequest/create message, the conferencing 2058 server detects that the indicated conference is not joinable 2059 without providing the relative pass code. Then a userResponse 2060 message with "423" response-code ("conference password 2061 required")is returned to Alice to indicate that her join has been 2062 refused and that she has to recast her request including the 2063 appropriate conference password in order to participate. 2065 3. After getting the pass code through out-of-band mechanisms, Alice 2066 provides it in the proper "password" request field of a new 2067 userRequest/create message and sends the updated request back to 2068 the server. 2070 4. The conferencing server checks the provided password and then 2071 adds Alice to the protected conference. After that, a 2072 userResponse with a "200" response-code ("success") is sent to 2073 Alice. 2075 1. userRequest/create message (Alice tries to enter the conference 2076 without providing the password) 2078 2079 2083 2086 xcon-userid:Alice@example.com 2087 xcon:8977794@example.com 2088 create 2089 2090 2091 2093 2. userResponse/create message (423, "conference password required") 2095 2096 2100 2103 xcon-userid:Alice@example.com 2104 xcon:8977794@example.com 2105 create 2106 423 2107 2108 conference password required 2109 2110 2111 2112 2114 3. userRequest/create message (Alice provides the password) 2115 2116 2120 2123 xcon-userid:Alice@example.com 2124 xcon:8977794@example.com 2125 create 2126 8601 2127 2128 2129 2131 4. userResponse/create message 2132 (Alice has been added to the conference) 2134 2135 2139 2142 xcon-userid:Alice@example.com 2143 xcon:8977794@example.com 2144 create 2145 200 2146 success 2147 10 2148 2149 2150 2152 Figure 19: Password-protected conference join messages details 2154 7. Sidebars Scenarios and Examples 2156 While creating conferences and manipulating users and their media may 2157 be considered enough for many scenarios, there may be cases when a 2158 more complex management is needed. 2160 In fact, a feature typically required in conferencing systems is the 2161 ability to create sidebars. A sidebar is basically a child 2162 conference that usually includes a subset of the participants of the 2163 parent conference, and a subset of its media as well. Sidebars are 2164 typically required whenever some of the participants in a conference 2165 want to discuss privately about something, without interfering with 2166 the main conference. 2168 This section deals with some scenarios that typically envisage the 2169 use of a sidebar, like whispering, private messages and coaching 2170 scenarios. The first subsections, anyway, present some examples of 2171 how a generic sidebar can be created, configured and managed. 2173 7.1. Internal Sidebar 2175 Figure 20 provides an example of one client, "Alice", involved in an 2176 active conference with "Bob" and "Carol". Alice wants to create a 2177 sidebar to have a side discussion with Bob while still viewing the 2178 video associated with the main conference. Alternatively, the audio 2179 from the main conference could be maintained at a reduced volume. 2180 Alice initiates the sidebar by sending a request to the conferencing 2181 system to create a conference reservation based upon the active 2182 conference object. Alice and Bob would remain on the roster of the 2183 main conference, such that other participants could be aware of their 2184 participation in the main conference, while an internal-sidebar 2185 conference is occurring. Besides, Bob decides that he is not 2186 interested in still receiving the conference audio in background (not 2187 even at a lower volume as Alice configured) and so modifies the 2188 sidebar in order to make that stream inactive for him. 2190 Alice Bob ConfS 2191 | | | 2192 |(1) sidebarByValRequest(confUserID, | 2193 | confObjID,create) | 2194 |--------------------------------------------->| 2195 | | | 2196 | | (a) Create +---| 2197 | | sidebar-by-val | | 2198 | | (new conf obj | | 2199 | | cloned from +-->| 2200 | | confObjID) | Sidebar now has 2201 | | | id confObjID* 2202 |(2) sidebarByValResponse(confUserID, | (parent mapping 2203 | (confObjID*,create,200,success, | conf<->sidebar) 2204 | version,sidebarByValInfo) | 2205 |<---------------------------------------------| 2206 | | | 2207 |(3) sidebarByValRequest | 2208 | (confUserID, confObjID*, | 2209 | update,sidebarByValInfo) | 2210 |--------------------------------------------->| 2211 | | | 2212 | | (b) Update +---| 2213 | | sidebar-by-val | | 2214 | | (media, users | | 2215 | | etc.) +-->| 2216 | | | Sidebar is 2217 | | | modified 2218 |(4) sidebarByValResponse(confUserID, | 2219 | confObjID*, update, | 2220 | 200, success, version) | 2221 |<---------------------------------------------| 2222 | | | 2223 | |(5) userRequest | 2224 | | (confUserID', | 2225 | | confObjID*, | 2226 | | update,userInfo)| 2227 | |---------------------->| 2228 | | | 2229 | | (c) Update +---| 2230 | | user settings | | 2231 | | (Bob's media) | | 2232 | | +-->| 2233 | | | Sidebar is modified 2234 | | | (original audio 2235 | | | inactive for Bob) 2236 | |(6) userResponse | 2237 | | (confUserID', | 2238 | | confObjID*, | 2239 | | update, 200, | 2240 | | success,version) | 2241 | |<----------------------| 2242 | | | 2243 " " " 2244 " " " 2245 " " " 2247 Figure 20: Client Creation of a Sidebar Conference 2249 1. Upon receipt of CCMP sidebarByValRequest message to create a new 2250 sidebar-conference based upon the confObjID received in the 2251 request, the conferencing system uses the confObjID to clone a 2252 conference reservation for the sidebar. The sidebar reservation 2253 is NOT independent of the active conference (i.e., parent). The 2254 conferencing system also allocates a new XCON-URI for that 2255 sidebar to be used for any subsequent protocol requests from any 2256 of the members of the conference. The new sidebar identifier 2257 ("confObjID*" in Figure 20) is returned in the response message 2258 confObjID parameter. 2260 2. The relationship information is provided in the 2261 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the 2263 main/parent conference is provided below as well to show how the 2264 cloning process for the creation of the sidebar could take place. 2266 3. Upon receipt of the sidebarByValResponse message to reserve the 2267 conference, Alice can now create an active conference using that 2268 reservation, or create additional reservations based upon the 2269 existing reservations. In this example, Alice wants only Bob to 2270 be involved in the sidebar, thus she manipulates the membership 2271 so that only the two of them appear in the 2272 section. Alice also wants both audio and video from the original 2273 conference to be available in the sidebar. For what concerns the 2274 media belonging to the sidebar itself, Alice wants the audio to 2275 be restricted to the participants in the sidebar (that is, Bob 2276 and herself). Additionally, Alice manipulates the media values 2277 to receive the audio from the main conference at a reduced 2278 volume, so that the communication between her and Bob isn't 2279 affected. Alice sends a sidebarByValRequest message with an 2280 operation of "update" along with the "sidebarByValInfo" 2281 containing the aforementioned sidebar modifications. 2283 4. Upon receipt of the sidebarByValRequest to update the sidebar 2284 reservation, the conference server ensures that Alice has the 2285 appropriate authority based on the policies associated with that 2286 specific conference object to perform the operation. The 2287 conference server must also validate the updated information in 2288 the reservation, ensuring that a member like Bob is already a 2289 user of this conference server. Once the data for the confObjID 2290 is updated, the conference server sends a sidebarByValResponse to 2291 Alice. Depending upon the policies, the initiator of the request 2292 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may 2293 be notified of his addition to the sidebar via the conference 2294 notification service. 2296 5. At this point, Bob sends a userRequest message to the conference 2297 server with an operation of "update" to completely disable the 2298 background audio from the parent conference, since it prevents 2299 him from understanding what Alice says in the sidebar. 2301 6. Notice that Bob's request only changes the media perspective for 2302 Bob. Alice keeps on receiving both the audio from Bob and the 2303 background from the parent conference. This request may be 2304 relayed by the conference server to the Media Server handling the 2305 mixing, if present. Upon completion of the change, the 2306 conference server sends a "userResponse" message to Bob. 2307 Depending upon the policies, the initiator of the request (i.e., 2308 Bob) and the participants in the sidebar (i.e., Alice) may be 2309 notified of this change via the conference notification service. 2311 That said, let's consider the following conference object: 2313 2314 2319 2320 MAIN CONFERENCE 2321 2322 2323 sip:8977878@example.com 2324 conference sip uri 2325 2326 2327 2328 2329 main conference audio 2330 audio 2331 sendrecv 2332 2333 2334 main conference video 2335 video 2336 sendrecv 2337 2338 single-view 2339 2340 2341 2342 2343 2344 true 2345 2346 2347 2348 Alice 2349 2350 2351 123 2352 sendrecv 2353 2354 2355 456 2356 sendrecv 2357 2358 2359 2360 2361 Bob 2362 2363 2364 123 2365 sendrecv 2366 2367 2368 456 2369 sendrecv 2370 2371 2372 2373 2374 Carol 2375 2376 2377 123 2378 sendrecv 2379 2380 2381 456 2382 sendrecv 2383 2384 2385 2386 2387 2389 Figure 21: Conference with Alice, Bob and Carol 2391 This is the representation of the conference the sidebar is going to 2392 be created in. As such, it will be used by the conferencing system 2393 in order to create the new conference object associated with the 2394 sidebar. In fact, the sidebar creation happens through a cloning of 2395 the parent conference. Once the sidebar is created, an "update" 2396 makes sure that the sidebar is customized as needed. The following 2397 protocol dump makes the process clearer. 2399 1. sidebarByValRequest/create message (Alice creates an 2400 internal sidebar) 2402 2403 2407 2410 xcon-userid:Alice@example.com 2411 xcon:8977878@example.com 2412 create 2413 2414 2415 2417 2. sidebarByValResponse/create message (sidebar returned) 2419 2420 2424 2427 xcon-userid:Alice@example.com 2428 xcon:8974545@example.com 2429 create 2430 200 2431 success 2432 1 2433 2434 2435 2436 2437 SIDEBAR CONFERENCE registered by Alice 2438 2439 2440 xcon:8977878@example.com 2441 2442 2443 2444 2445 main conference audio 2446 2447 audio 2448 sendrecv 2449 2450 2451 2452 main conference video 2453 2454 video 2455 sendrecv 2456 2457 2458 2459 2460 false 2461 2462 2463 2464 2466 2468 2470 2471 2472 2473 2474 2475 2477 3. sidebarByValRequest/update message (Alice updates the 2478 created sidebar) 2480 2481 2485 2488 xcon-userid:Alice@example.com 2489 xcon:8974545@example.com 2490 update 2491 2492 2493 2494 2495 private sidebar Alice - Bob 2496 2497 2498 2499 2500 main conference audio 2501 2502 audio 2503 recvonly 2504 2505 -60 2506 2507 2508 2509 2510 main conference video 2511 2512 video 2513 recvonly 2514 2515 2516 2517 sidebar audio 2518 2519 audio 2520 sendrecv 2521 2522 2523 2524 sidebar video 2525 2526 video 2527 sendrecv 2528 2529 2530 2531 2532 2533 2535 2537 2538 2539 2540 2541 2542 2544 4. sidebarByValResponse/update message (sidebar's 2545 updates accepted) 2547 2548 2552 2555 xcon-userid:Alice@example.com 2556 xcon:8974545@example.com 2557 update 2558 200 2559 success 2560 2 2561 2562 2563 2565 5. userRequest/update message (Bob updates his media) 2567 2568 2572 2575 xcon-userid:Bob@example.com 2576 xcon:8974545@example.com 2577 update 2578 2579 2580 2581 2582 2583 main conference audio 2584 2585 123 2586 inactive 2587 2588 2589 2590 2591 2592 2594 6. userResponse/update message (Bob's preferences setted) 2596 2597 2601 2604 xcon-userid:Bob@example.com 2605 xcon:8974545@example.com 2606 update 2607 200 2608 success 2609 3 2610 2611 2612 2614 Figure 22: Internal Sidebar Messaging Details 2616 7.2. External Sidebar 2618 Figure 23 provides an example of a different approach towards 2619 sidebar. In this scenario, one client, "Alice", is involved in an 2620 active conference with "Bob", "Carol", "David" and "Ethel". Alice 2621 gets an important text message via a whisper from Bob that a critical 2622 customer needs to talk to Alice, Bob and Ethel. Alice creates a 2623 sidebar to have a side discussion with the customer "Fred" including 2624 the participants in the current conference with the exception of 2625 Carol and David, who remain in the active conference. The difference 2626 from the previous scenario is that Fred is not part of the parent 2627 conference: this means that different policies might be involved, 2628 considering that Fred may access information coming from the parent 2629 conference, in case the sidebar was configured accordingly. For this 2630 reason, in this scenario we assume that Alice disables all the media 2631 from the original (parent) conference within the sidebar. This means 2632 that, while in the previous example Alice and Bob still heard the 2633 audio from the main conference in background, this time no background 2634 is made available. Alice initiates the sidebar by sending a request 2635 to the conferencing system to create a conference reservation based 2636 upon the active conference object. Alice, Bob and Ethel would remain 2637 on the roster of the main conference in a hold state. Whether or not 2638 the hold state of these participants is visible to other participants 2639 depends upon the individual and local policy. 2641 Alice Bob ConfS 2642 | | | 2643 |(1) sidebarByRefRequest(confUserID, | 2644 | confObjID, create) | 2645 |--------------------------------------------->| 2646 | | | 2647 | | (a) Create +---| 2648 | | sidebar-by-ref | | 2649 | | (new conf obj | | 2650 | | cloned from +-->| 2651 | | confObjID) | Sidebar now has 2652 | | | id confObjID* 2653 |(2) sidebarByRefResponse(confUserID, | (parent mapping 2654 | confObjID*,create,200,success, | conf<->sidebar) 2655 | version,sidebarByRefInfo) | 2656 |<---------------------------------------------| 2657 | | | 2658 |(3) sidebarByRefRequest(confUserID, | 2659 | confObjID*,update,sidebarByRefInfo) | 2660 |--------------------------------------------->| 2661 | | | 2662 | | (b) Create +---| 2663 | | new user for | | 2664 | | Fred | | 2665 | | +-->| 2666 | | | 2667 | | (c) Update +---| 2668 | | sidebar-by-ref | | 2669 | | (media, users | | 2670 | | policy, etc.) +-->| 2671 | | | Sidebar is modified: 2672 | | | no media from the 2673 | | | parent conference is 2674 | | | available to anyone 2675 |(4) sidebarByRefResponse(confUserID, | 2676 | confObjID*, update, | 2677 | 200, success, version) | 2678 |<---------------------------------------------| 2679 | | | 2680 | | Notify (Fred | 2681 | | added to | 2682 | | sidebar users) | 2683 | |<----------------------| 2684 | | | 2685 " " " 2686 " " " 2687 " " " 2688 Figure 23: Client Creation of an External Sidebar 2690 1. Upon receipt of the "sidebarByRefRequest" message to create a new 2691 sidebar conference, based upon the active conference specified by 2692 "confObjID" in the request, the conferencing system uses that 2693 active conference to clone a conference reservation for the 2694 sidebar. The sidebar reservation is NOT independent of the 2695 active conference (i.e., parent). The conferencing system, as 2696 before, allocates a conference ID (confObjID*) to be used for any 2697 subsequent protocol requests toward the sidebar reservation. The 2698 mapping between the sidebar conference ID and the one associated 2699 with the main conference is mantained by the conferencing system 2700 and it is gathered from the c element in the 2701 sidebar conference object. 2703 2. Upon receipt of the "sidebarByRefResponse" message, which 2704 acknowledges the successful creation of the sidebar object, Alice 2705 decides that only Bob and Ethel, along with the new participant 2706 Fred are to be involved in the sidebar. Thus she manipulates the 2707 membership accordingly. Alice also sets the media in the 2708 "conference-info" such that the participants in the sidebar don't 2709 receive any media from the main conference. All these settings 2710 are provided to the conferencing system by means of a new 2711 "sidebarByRefRequest" message, with an "update" operation. 2713 3. Alice sends the aforementioned "sidebarByRefRequest" to update 2714 the information in the reservation and to create an active 2715 conference. Upon receipt of the "sidebarByRefRequest" with an 2716 operation of "update", the conferencing system ensures that Alice 2717 has the appropriate authority based on the policies associated 2718 with that specific conference object to perform the operation. 2719 The conferencing system also validates the updated information in 2720 the reservation. Since Fred is a new user for this conferencing 2721 system, a conference user identifier is created for Fred. 2722 Specifically, Fred is added to the conference by only providing 2723 his SIP URI. Based upon the contact information provided for 2724 Fred by Alice, the call signaling to add Fred to the conference 2725 may be instigated through the Focus (e.g. if Fred had a "dial- 2726 out" method set as the target for him) at the actual activation 2727 of the sidebar. 2729 4. The conference server sends a "sidebarByRefResponse" message and, 2730 depending upon the policies, the initiator of the request (i.e., 2731 Alice) and the participants in the sidebar (i.e., Bob and Ethel) 2732 may be notified of his addition to the sidebar via the conference 2733 notification service. 2735 1. sidebarByRefRequest/create message (Alice creates an 2736 external sidebar) 2738 2739 2743 2746 xcon-userid:Alice@example.com 2747 xcon:8977878@example.com 2748 create 2749 2750 2751 2753 2. sidebarByRefResponse/create message (created 2754 sidebar returned) 2756 2757 2761 2764 xcon-userid:Alice@example.com 2765 xcon:8971212@example.com 2766 create 2767 200 2768 success 2769 1 2770 2771 2772 2773 2774 SIDEBAR CONFERENCE registered by Alice 2775 2776 2777 xcon:8977878@example.com 2778 2779 2780 2781 2782 main conference audio 2783 2784 audio 2785 sendrecv 2786 2787 2788 2789 main conference video 2790 2791 video 2792 sendrecv 2793 2794 2795 2796 2797 false 2798 2799 2800 2801 2803 2805 2807 2809 2811 2812 2813 2814 2815 2816 2818 3. sidebarByRefRequest/update message (Alice updates the sidebar) 2820 2824 2827 xcon-userid:Alice@example.com 2828 xcon:8971212@example.com 2829 update 2830 2831 2832 2833 2834 sidebar with Alice, Bob, Ethel & Fred 2835 2836 2837 2838 2839 main conference audio 2840 2841 audio 2842 inactive 2843 2844 2845 2846 main conference video 2847 2848 video 2849 inactive 2850 2851 2852 2853 sidebar audio 2854 2855 audio 2856 sendrecv 2857 2858 2859 2860 sidebar video 2861 2862 video 2863 sendrecv 2864 2865 2866 single-view 2867 2868 2869 2870 2871 2872 2873 false 2874 2875 2876 2877 2879 2881 2883 2884 2885 2886 2887 2888 2890 4. sidebarByRefResponse/update message (sidebar updated) 2892 2896 2899 xcon-userid:Alice@example.com 2900 xcon:8971212@example.com 2901 update 2902 200 2903 success 2904 2 2905 2906 2907 2909 Figure 24: External Sidebar Messaging Details 2911 7.3. Private Messages 2913 The case of private messages can be handled as a sidebar with just 2914 two participants, similarly to the example in Section 7.1. Unlike 2915 the previous example, rather than using audio within the sidebar, 2916 Alice could just add an additional text based media stream to the 2917 sidebar in order to convey her textual messages to Bob, while still 2918 viewing and listening to the main conference. 2920 In this scenario, Alice requests to the conferencing system the 2921 creation of a private chat room within the main conference context 2922 (presented in Figure 21) in which the involved partecipants are just 2923 Bob and herself. This can be achieved through the following CCMP 2924 transaction (Figure 25). 2926 1. Alice forwards a sidebarByValRequest/create to the Conferencing 2927 Control Server with the main conference XCON-URI in the 2928 "confObjID" parameter and the desired sidebar conference object 2929 in the "sidebarByValInfo" field. In this way, a sidebar creation 2930 using user-provided conference information is requested to the 2931 conferencing system. Please note that, unlike the previous 2932 sidebar examples, in this case a comnpletely new conference 2933 object to describe the sidebar is provided: there is no cloning 2934 involved, while the "confObjID" still enforces the parent-child 2935 relationship between the main conference and the to-be-created 2936 sidebar. 2938 2. The Conference Control Server, after checking Alice's rights and 2939 validating the conference-object carried in the request, creates 2940 the required sidebar-by-val conference and a new XCON-URI for it. 2941 Instead of cloning the main conference object, as envisioned in 2942 Section 7.1 and Section 7.2, the sidebar is created on the basis 2943 of the user provided conference information (as anticipated 2944 before). However, the parent relationship between the main 2945 conference and the newly created sidebar is still mantained by 2946 the conferencing system (as a consequence of the chosen CCMP 2947 request message type - the sidebarByVal one) and it is reflected 2948 by the element in the "sidebarByValInfo" element 2949 returned in the sidebarByValResponse message. Please notice 2950 that, according to the CCMP specification, the return of the 2951 created sidebar data in this kind of "success" response is not 2952 mandatory. 2954 1. sidebarByValRequest/create message (Alice creates a private 2955 chat room between Bob and herself) 2957 2958 2962 2965 xcon-userid:Alice@example.com 2966 xcon:8977878@example.com 2967 create 2968 2969 2970 2971 2972 private textual sidebar alice - bob 2973 2974 2975 2976 2977 main conference audio 2978 2979 audio 2980 recvonly 2981 2982 2983 2984 main conference video 2985 2986 video 2987 recvonly 2988 2989 2990 2991 sidebar text 2992 2993 text 2994 sendrecv 2995 2996 2997 2998 2999 3000 3002 3004 3005 3006 3007 3008 3009 3011 2. sidebarByValResponse/create message (sidebar returned) 3013 3014 3018 3021 xcon-userid:Alice@example.com 3022 xcon:8974545@example.com 3023 create 3024 200 3025 success 3026 1 3027 3028 3029 3030 3031 private textual sidebar alice - bob 3032 3033 3034 xcon:8977878@example.com 3035 3036 3037 3038 3039 main conference audio 3040 3041 audio 3042 recvonly 3043 3044 3045 3046 main conference video 3047 3048 video 3049 recvonly 3050 3051 3052 3053 sidebar text 3054 3055 text 3056 sendrecv 3057 3058 3059 3060 3061 3062 3064 3066 3067 3068 3069 3070 3071 3073 Figure 25: Sidebar for Private Messages scenario 3075 7.4. Observing and Coaching 3077 Observing and Coaching is one of the most interesting sidebars- 3078 related scenarios. In fact, it envisages two different interactions 3079 that have to be properly coordinated. 3081 An example of observing and coaching is shown in figure Figure 27. 3082 In this example, call center agent Bob is involved in a conference 3083 with customer Carol. Since Bob is a new agent and Alice sees that he 3084 has been on the call with Carol for longer than normal, she decides 3085 to observe the call and coach Bob as necessary. Of course the 3086 conferencing system must make sure that the customer Carol is not 3087 aware of the presence of the coach Alice. This makes the use of a 3088 sidebar necessary for the success of the scenario. 3090 Consider the following as the conference document associated with the 3091 video conference involving Bob (the call agent) and Carol (the 3092 customer) (Figure 26): 3094 3095 3100 3101 3102 CUSTOMER SERVICE conference 3103 3104 3105 3106 sip:8978383@example.com 3107 conference sip uri 3108 3109 3110 3111 3112 service audio 3113 audio 3114 sendrecv 3115 3116 3117 service video 3118 video 3119 sendrecv 3120 3121 single-view 3122 3123 3124 3125 3126 3127 true 3128 3129 3130 3131 Bob - call agent 3132 3133 3134 123 3135 sendrecv 3136 3137 3138 456 3139 sendrecv 3140 3141 3142 3143 3144 Carol - customer 3145 3146 3147 123 3148 sendrecv 3149 3150 3151 456 3152 sendrecv 3153 3155 3156 3157 3158 3160 Figure 26: A call-center conference object example 3162 Alice Bob ConfS 3163 | | | 3164 |(1) sidebarByRefRequest(confUserID, | 3165 | confObjID, create) | 3166 |--------------------------------------------->| 3167 | | | 3168 | | (a) Create +---| 3169 | | sidebar-by-ref | | 3170 | | (new conf obj | | 3171 | | cloned from +-->| 3172 | | confObjID) | Sidebar now has 3173 | | | id confObjID* 3174 |(2) sidebarByRefResponse(confUserID, | (parent mapping 3175 | confObjID*,create,200,success, | conf<->sidebar) 3176 | version,sidebarByRefInfo) | 3177 |<---------------------------------------------| 3178 | | | 3179 |(3) sidebarByRefRequest(confUserID, | 3180 | confObjID*,update,sidebarByRefInfo) | 3181 |--------------------------------------------->| 3182 | | | 3183 | | (b) Update +---| 3184 | | sidebar-by-val | | 3185 | | (media, users | | 3186 | | policy, etc.) +-->| 3187 | | | Sidebar is modified: 3188 | | | unilateral sidebar 3189 | | | audio, Carol excluded 3190 | | | from the sidebar 3191 |(4) sidebarByRefResponse(confUserID, | 3192 | confObjID*, update, | 3193 | 200, success, version) | 3194 |<---------------------------------------------| 3195 | | | 3196 | | Notify (Bob | 3197 | | he's been added to | 3198 | | sidebar users) | 3199 | |<----------------------| 3200 | | | 3201 " " " 3202 " " " 3203 " " " 3205 Figure 27: Supervisor Creating a Sidebar for Observing/Coaching 3207 1. Upon receipt of the sidbarByRefRequest/create from Alice to 3208 "create" a new sidebar conference from the confObjID received in 3209 the request, the conferencing system uses the received active 3210 conference to clone a conference reservation for the sidebar. 3211 The conferencing system also allocates a conference ID to be used 3212 for any subsequent protocol requests from any of the members of 3213 the conference. The conferencing system maintains the mapping 3214 between this conference ID and the confObjID associated with the 3215 sidebar reservation through the conference instance. The 3216 conference server sends a sidebarByRefResponse message with the 3217 new confObjID and relevant sidebarByRefInfo. 3219 2. Upon receipt of the sidebarByRefResponse message, Alice 3220 manipulates the data received in the sidebarByRefInfo in the 3221 response. Alice wants only Bob to be involved in the sidebar, 3222 thus she updates the to include only Bob and 3223 herself. Alice also wants the audio to be received by herself 3224 and Bob from the original conference, but wants any outgoing 3225 audio from herself to be restricted to the participants in the 3226 sidebar, whereas Bob's outgoing audio should go to the main 3227 conference, so that both Alice and the customer Carol hear the 3228 same audio from Bob. Alice sends a sidebarByRefRequest message 3229 with an "update" operation including the updated sidebar 3230 information. 3232 3. Upon receipt of the sidebarByRefRequest message with an "update" 3233 operation, the conferencing system ensures that Alice has the 3234 appropriate authority based on the policies associated with that 3235 specific conference object to perform the operation. In order to 3236 request the insertion of a further media stream in the sidebar 3237 (i.e. in this example an audio stream from Alice to Bob), the 3238 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label" 3240 attribute of that new entry is filled with a dummy value 3241 "AUTO_GENERATE_1", but it will contain the real server-generated 3242 media stream identifier when the media stream is effectively 3243 allocated on the server side. Similarly, the mandatory "id" 3244 attribute in element referring to the new sidebar audio 3245 stream under both Alice's and Bob's contains a 3246 wildcard value, respectively "AUTO_GENERATED_2" and 3247 "AUTO_GENERATED_3": those values will be replaced with the 3248 appropriated server-generated identifiers upon the creation of 3249 the referred media stream. We are assuming the conferencing 3250 control server is able to recognize those dummy values as place- 3251 holders. 3253 4. After validating the data, the conference server sends a 3254 sidebarByRefResponse message. Based upon the contact information 3255 provided for Bob by Alice, the call signaling to add Bob to the 3256 sidebar with the appropriate media characteristics is instigated 3257 through the Focus. Bob is notified of his addition to the 3258 sidebar via the conference notification service, thus he is aware 3259 that Alice, the supervisor, is available for coaching him through 3260 this call. 3262 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar) 3264 3265 3269 3272 xcon-userid:Alice@example.com 3273 xcon:8978383@example.com 3274 create 3275 3276 3277 3279 2. sidebarByRefResponse/create message (sidebar created) 3281 3282 3286 3289 xcon-userid:alice@example.com 3290 xcon:8971313@example.com 3291 create 3292 200 3293 success 3294 1 3295 3296 3297 3298 3299 SIDEBAR CONFERENCE registered by alice 3300 3301 3302 xcon:8971313@example.com 3303 3304 3305 3306 3307 main conference audio 3308 3309 audio 3310 sendrecv 3311 3312 3313 3314 main conference video 3315 3316 video 3317 sendrecv 3318 3319 3320 3321 3322 false 3323 3324 3325 3326 3328 3330 3332 3333 3334 3335 3336 3337 3339 3. sidebarByRefRequest/update message (Alice introduces unilateral 3340 sidebar audio and excludes Carol from the sidebar) 3342 3346 3349 xcon-userid:alice@example.com 3350 xcon:8971313@example.com 3351 update 3352 3353 3354 3355 3356 Coaching sidebar Alice and Bob 3357 3358 3359 3360 3361 Alice-to-Bob audio 3362 3363 audio 3364 sendrecv 3365 3366 3367 3368 3369 false 3370 3371 3372 3373 3375 3377 3378 3380 3381 AUTO_GENERATE_1 3382 sendonly 3383 3384 3385 3386 3388 3389 AUTO_GENERATE_1 3390 recvonly 3391 3392 3393 3394 3395 3396 3398 3399 3401 4. sidebarByRefRequest/update message (updates accepted) 3403 3404 3408 3411 xcon-userid:alice@example.com 3412 xcon:8971313@example.com 3413 update 3414 200 3415 success 3416 2 3417 3418 3419 3421 Figure 28: Coaching and Observing Messaging details 3423 8. Removing Participants and Deleting Conferences 3425 The following scenarios detail the basic operations associated with 3426 removing participants from conferences and entirely deleting 3427 conferences. The examples assume that a conference has already been 3428 correctly established, with media, if applicable, per one of the 3429 examples in Section 5. 3431 8.1. Removing a Party 3433 Figure 29 provides an example of a client, "Alice", removing another 3434 participant, "Bob", from a conference. This example assumes an 3435 established conference with Alice, Bob, "Claire" and "Duck". In this 3436 example, Alice wants to remove Bob from the conference so that the 3437 group can continue in the same conference without Bob's 3438 participation. 3440 Alice Bob Claire ConfS 3441 | | | | 3442 |(1) userRequest(confUserID,| | 3443 | confObjID, delete,| | 3444 | userInfo) | | 3445 |-------------------------------------->| 3446 | | | | 3447 | | | (a) Focus | 3448 | | | tears down| 3449 | | | signaling | 3450 | | | to Bob | 3451 | |<----------------------| 3452 | | | 3453 | | (b)Deletes+---| 3454 | | | Bob | | 3455 | | | as a | | 3456 | | | user +-->| 3457 | | | in | 3458 | | | confObj | 3459 | | | | 3460 |(2) userResponse(confUserID,confObjID, | 3461 | delete,200,success,version) | 3462 |<--------------------------------------| 3463 | | | | 3464 | | | | 3465 | | | (c) Notify| 3466 | | | ("Bob just| 3467 | | | left") | 3468 | | |<----------| 3469 | | | | 3470 ' ' ' ' 3471 ' ' ' ' 3472 ' ' ' ' 3474 Figure 29: Client Manipulation of Conference - Remove a party 3476 1. Alice sends a userRequest message, with a "delete" operation. 3477 The conference server ensures that Alice has the appropriate 3478 authority based on the policies associated with that specific 3479 conference object to perform the operation. 3481 2. Based upon the contact and media information in the conference 3482 object for Bob in the "userInfo" element, the conferencing system 3483 starts the process to remove Bob (e.g., the call signaling to 3484 remove Bob from the conference is instigated through the Focus). 3485 The conference server updates the data in the conference object, 3486 thus removing Bob from the list. After updating the 3487 data, the conference server sends a userResponse message to 3488 Alice. Depending upon the policies, other participants (e.g. 3489 "Claire") may be notified of the removal of Bob from the 3490 conference via the Conference Notification Service. 3492 1. userRequest/delete message (Alice deletes Bob): 3494 3495 3499 3502 xcon-userid:Alice@example.com 3503 xcon:8977794@example.com 3504 delete 3505 3506 3507 3508 3509 3511 2. userResponse/delete message (Bob has been deleted) 3513 3514 3518 3521 xcon-userid:Alice@example.com 3522 xcon:8977794@example.com 3523 delete 3524 200 3525 success 3526 17 3527 3528 3529 3530 Figure 30: Removing a Participant Messaging Details 3532 8.2. Deleting a Conference 3534 In this section, an example of a successful conference deletion is 3535 provided (Figure 31). 3537 Alice ConfS 3538 | | 3539 |(1)confRequest(confUserID, | 3540 | confObjID, delete) | 3541 |------------------------------>| 3542 | (a)Delete +---| 3543 | Conf | | 3544 | Object | | 3545 | +-->| 3546 | |--+ (b) MS 3547 | | | removes related 3548 | | | mixer instances and 3549 | |<-+ their participants 3550 | | (SIP signaling as well) 3551 | | 3552 |(2)confResponse(confUserID, | 3553 | confObjID,delete,200, | 3554 | success) | 3555 | | 3556 |<------------------------------| 3557 | | 3559 Figure 31: Deleting a conference 3561 1. The conferencing system client "Alice" sends a confRequest 3562 message with a "delete" operation to be performed on the 3563 conference identified by the XCON-URI carried in the "confObjID" 3564 parameter. The conference server, on the basis of the 3565 "confUserID" included in the receipt request, ensures that Alice 3566 has the appropriate authority to fulfill the operation. 3568 2. After validating Alice's rights, the conferencing server 3569 instigates the process to delete the conference object, 3570 disconnetting participants and removing associated resources such 3571 as mixer instances. Then, the conference server returns a 3572 confResponse message to Alice with "200" as "response-code" and 3573 the deleted conference XCON-URI in the "confObjID" field. 3575 1. confRequest/delete message (Alice deletes a conference) 3577 3578 3582 3585 xcon-userid:Alice@example.com 3586 xcon:8977794@example.com 3587 delete 3588 3589 3590 3592 2. confResponse/delete message (200, "success") 3594 3595 3599 3602 xcon-userid:Alice@example.com 3603 xcon:8977794@example.com 3604 delete 3605 200 3606 success 3607 3608 3609 3611 Figure 32: Deleting a Conference Messaging Details 3613 9. IANA Considerations 3615 This document has no IANA considerations. 3617 10. Security Considerations 3619 The security considerations applicable to the implementation of these 3620 call flows is documented in the XCON Framework, with additional 3621 security considerations documented in the CCMP document. Where 3622 applicable, statements with regards to the necessary security are 3623 discussed in particular flows, however, since this is only an 3624 informational document, readers are strongly recommended to carefully 3625 consider the security considerations defined in the XCON Framework 3626 and the CCMP document. 3628 11. Change Summary 3630 NOTE TO THE RFC-EDITOR: Please remove this section prior to 3631 publication as an RFC. 3633 The following are the major changes between the 02 and the 03 3634 versions of the draft: 3636 o updated the call flows in order to take into account the changes 3637 on CCMP; 3639 o added a completely new introductory section, addressing the 3640 protocol in general, the data model constraints, transport-related 3641 information, and notifications in a practical way; 3643 o reorganized the chapters, grouping user-related scenarios in an 3644 users section, and doing the same for sidebars; 3646 o added more verbose text to almost every section of the document; 3648 The following are the major changes between the 01 and the 02 3649 versions of the draft: 3651 o updated the call flows in order to take into account the new 3652 versioning mechanism of the CCMP; 3654 o clarified, per agreement in Stockholm, that cloning from a 3655 blueprint does not need a cloning-parent to be made available in 3656 the response; 3658 o clarified that BFCP and CCMP-based media control are neither in 3659 conflict nor one the wrapper of the other; they act at different 3660 levels, and when both are involved, it is required that both grant 3661 a resource before it can be used by an interested participant; 3663 o changed all the domains involved in the flows to make them 3664 compliant with [RFC2606]; 3666 o clarified that a successful creation of a new conference object 3667 may or may not contain the whole confInfo object in the response; 3668 in case it doesn't, a retrieve of the updated object can be 3669 achieved by issuing a confRequest/retrieve; 3671 o clarified that the scenario in Section 6.3 only involves CCMP in 3672 adding the user to a conference; this includes requiring the use 3673 of a password only in adding the user to the conference object; 3674 the actual request for PIN/Password when joining thw conference is 3675 handled by means of out-of-band mechanisms (in this case at the 3676 media level, with the help of the MEDIACTRL framework); 3678 o added and corrected Sidebars-related scenarios; 3680 o added flows for some previously missing scenarios: Private 3681 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a 3682 Conference; 3684 o 3686 The following are the major changes between the 00 and the 01 3687 versions of the draft: 3689 o Updates to reflect change of CCMP to HTTP transport model. 3691 The following are the major changes between the individual 01 version 3692 to the WG 00: 3694 o Updates to reflect most recent version of CCMP, including 3695 parameter names, etc. 3697 o Added protocol details to many of the examples. 3699 o Editorial: Simplifying intro, terms, etc. 3701 12. Acknowledgements 3703 The detailed content for this document is derived from the prototype 3704 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and 3705 their colleagues at the University of Napoli. 3707 13. References 3709 13.1. Normative References 3711 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3712 Centralized Conferencing", RFC 5239, June 2008. 3714 [I-D.ietf-xcon-ccmp] 3715 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3716 "Centralized Conferencing Manipulation Protocol", 3717 draft-ietf-xcon-ccmp-09 (work in progress), July 2010. 3719 13.2. Informative References 3721 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 3722 Names", BCP 32, RFC 2606, June 1999. 3724 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3725 A., Peterson, J., Sparks, R., Handley, M., and E. 3726 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3727 June 2002. 3729 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3730 (SIP) Call Control - Conferencing for User Agents", 3731 BCP 119, RFC 4579, August 2006. 3733 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 3734 RFC 4597, August 2006. 3736 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 3737 Control Protocol (BFCP)", RFC 4582, November 2006. 3739 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 3740 Initiation Protocol (SIP) Event Package for Conference 3741 State", RFC 4575, August 2006. 3743 [I-D.ietf-xcon-event-package] 3744 Camarillo, G., Srinivasan, S., Even, R., and J. 3745 Urpalainen, "Conference Event Package Data Format 3746 Extension for Centralized Conferencing (XCON)", 3747 draft-ietf-xcon-event-package-01 (work in progress), 3748 September 2008. 3750 [I-D.ietf-xcon-common-data-model] 3751 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3752 "Conference Information Data Model for Centralized 3753 Conferencing (XCON)", draft-ietf-xcon-common-data-model-19 3754 (work in progress), May 2010. 3756 [I-D.ietf-mediactrl-call-flows] 3757 Amirante, A., Castaldi, T., Miniero, L., and S. Romano, 3758 "Media Control Channel Framework (CFW) Call Flow 3759 Examples", draft-ietf-mediactrl-call-flows-04 (work in 3760 progress), May 2010. 3762 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 3763 Server Control", RFC 5567, June 2009. 3765 [I-D.ietf-mediactrl-mixer-control-package] 3766 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 3767 Control Package for the Media Control Channel Framework", 3768 draft-ietf-mediactrl-mixer-control-package-11 (work in 3769 progress), February 2010. 3771 Authors' Addresses 3773 Mary Barnes 3774 Polycom 3775 TX 3776 US 3778 Email: mary.ietf.barnes@gmail.com 3780 Lorenzo Miniero 3781 Meetecho 3782 Via Carlo Poerio 89/a 3783 Napoli 80121 3784 Italy 3786 Email: lorenzo@meetecho.com 3787 Roberta Presta 3788 University of Napoli 3789 Via Claudio 21 3790 Napoli 80125 3791 Italy 3793 Email: roberta.presta@unina.it 3795 Simon Pietro Romano 3796 University of Napoli 3797 Via Claudio 21 3798 Napoli 80125 3799 Italy 3801 Email: spromano@unina.it