idnits 2.17.1 draft-ietf-xcon-examples-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2010) is 5119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 3605, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-xcon-session-chat' is defined on line 3669, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-06 -- 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-18 == Outdated reference: A later version (-13) exists of draft-ietf-mediactrl-call-flows-03 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-11 == Outdated reference: A later version (-08) exists of draft-boulton-xcon-session-chat-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Informational L. Miniero 5 Expires: October 16, 2010 Meetecho 6 R. Presta 7 S P. Romano 8 University of Napoli 9 April 14, 2010 11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 12 draft-ietf-xcon-examples-04 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 October 16, 2010. 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 . . . . . . . . . . . . . . . . . . . . . 13 66 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 13 67 5.2. Conference Creation using Blueprints . . . . . . . . . . . 18 68 5.3. Conference Creation using User-Provided Conference 69 Information . . . . . . . . . . . . . . . . . . . . . . . 25 70 5.4. Cloning an Existing Conference . . . . . . . . . . . . . . 30 71 6. Conference Users Scenarios and Examples . . . . . . . . . . . 33 72 6.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 34 73 6.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 37 74 6.3. Conference Announcements and Recordings . . . . . . . . . 41 75 6.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45 76 6.5. Entering a password-protected conference . . . . . . . . . 45 77 7. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 47 78 7.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 48 79 7.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 57 80 7.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 63 81 7.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 67 82 8. Removing Participants and Deleting Conferences . . . . . . . . 74 83 8.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 74 84 8.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 77 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 87 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 79 88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 81 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 94 1. Introduction 96 This document provides detailed call flows for the scenarios 97 documented in the Framework for Centralized Conferencing (XCON 98 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON 99 scenarios describe a broad range of use cases taking advantage of the 100 advanced conferencing capabilities provided by a system realization 101 of the XCON framework. The call flows document the use of the 102 interface between a conference control client and a conference 103 control server using the Centralized Conferencing Manipulation 104 Protocol (CCMP)[I-D.ietf-xcon-ccmp]. 106 Due to the broad range of functionality provided by the XCON 107 Framework and the flexibility of the CCMP messaging, these call flows 108 should not be considered inclusive of all the functionality that can 109 provided by the XCON Framework and protocol implementations. These 110 flows represent a sample to provide an overview of the feature rich 111 capabilities of the XCON framework and CCMP messaging for protocol 112 developers, software developers and researchers. 114 2. Terminology 116 This document uses the same terminology as found in the Media Control 117 Architectural Framework [RFC5567] and Media Control Channel Framework 118 Call Flow Examples [I-D.ietf-mediactrl-call-flows], with the 119 following terms and abbreviations used in the call flows. Also, note 120 that the term "call flows" is used in a very generic sense in this 121 document since the media is not limited to voice. The calls 122 supported by the XCON framework and CCMP can consist of media such as 123 text, voice and video, including multiple media types in a single 124 active conference. 126 Conference and Media Control Client (CMCC): as defined in the XCON 127 Framework. In the flows in this document, the CMCC is logically 128 equivalent to the use of UAC as the client notation in the media 129 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC 130 differs from a generic Media Client in being an XCON-aware entity, 131 thus being able to also issue CCMP requests. 133 Conferencing Server (ConfS): In this document, the "Conferencing 134 Server" term is used interchangeably with the term Application 135 Server (AS) as used in the Media Control Architectural Framework 136 [RFC5567]. A Conferencing Server is intended to be able to act as 137 a Conference Control Server, as defined in the XCON framework, 138 i.e. it is able to handle CCMP requests and issue CCMP responses. 140 Media Server (MS): as defined in the Media Control Architectural 141 Framework [RFC5567]. 143 3. Overview 145 This document provides a sampling of detailed call flows that can be 146 implemented based on a system realization of the XCON framework 147 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is 148 intended to be a simple guide for the use of the Conference Control 149 Protocol between the Conferencing Server and the Conference Control 150 Client. The objective is to provide an informational base reference 151 for protocol developers, software developers and researchers. 153 This document focuses on the interaction between the Conference (and 154 Media) Control Client and the Conferencing System, specifically the 155 Conferencing Server. The scenarios are based on those described in 156 the XCON framework, many of which are based on the advanced 157 conferencing capabilities described in the XCON scenarios. 158 Additional scenarios have been added to provide examples of other 159 real life scenarios that are anticipated to be supported by the 160 framework. With the exception of an initial example with media 161 control messaging, the examples do not include the details for the 162 media control [I-D.ietf-mediactrl-mixer-control-package], call 163 signaling or binary floor control [RFC4582] protocols. This document 164 references the scenarios in the Media Control call flows 165 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing 166 [RFC4579] and binary floor control protocol documents. 168 The rest of this document is organized as follows. Section 4 169 presents an overview on CCMP, together with some implementation- 170 related details and related matters like HTTP transport and 171 notifications. Section 5 presents the reader with examples showing 172 the different approaches CCMP provides to create a new conference. 173 Section 6 more generally addresses the different user-related 174 manipulations that can be achieved by means of CCMP, by presenting a 175 number of interesting scenarios. Section 7 addresses the several 176 scenarios that may involve the use of sidebars. Section 8 shows how 177 CCMP can be used to remove conferences and users from the system. 178 Finally, IANA considerations are discussed in Section 9 while 179 Section 10 provides a few details for what concerns the Security 180 Considerations when it comes to implementing CCMP. 182 4. Working with CCMP 184 This section aims at being a brief introduction to how the 185 Centralized Conferencing Manipulation Protocol (CCMP) 187 [I-D.ietf-xcon-ccmp] works and how it can be transported across a 188 network. Some words will be spent to describe a typical CCMP 189 interaction, by focusing on relevant aspects of the client-server 190 communication. Please notice that this section is by no means to be 191 considered as a replacement for the CCMP document, which remains a 192 mandatory read before approaching the following sections. It is just 193 conceived to help the reader take the first steps toward the actual 194 protocol interactions. 196 First of all, some lines will be devoted to the protocol by itself in 197 Section 4.1, together with some recommendations from an 198 implementation point of view. In Section 4.2, instead, an effective 199 CCMP interaction will be presented by exploiting HTTP as a transport. 200 Finally, a few words will be spent on notifications in Section 4.3. 202 Once done with these preliminary steps, some actual flows will be 203 presented and described in detail in the sections to follow. 205 4.1. CCMP and the Data Model 207 CCMP is an XML-based protocol. It has been designed as a request/ 208 response protocol. Besides, it is completely stateless, which means 209 implementations can safely handle transactions independently from 210 each other. 212 The protocol allows for the manipulation of conference objects and 213 related users. By manipulation it is implied, as the document 214 specifies, that a Conferencing Client (briefly CMCC in all the 215 following sections) can create, update and remove basically 216 everything that is related to the objects handled by a conferencing 217 system. This is reflected in the allowed operations (retrieve, 218 create, update, delete) and the specified request types (ranging from 219 the manipulation of blueprints and conferences to users and 220 sidebars). For instance, CCMP provides ways to: 222 o retrieve the list of registered and/or active conferences in the 223 system; 225 o create new conferences by exploiting to several different 226 approaches; 228 o add/remove users to/from a conference; 230 o update a conference with respect to all of its aspects; 232 and so on. 234 It is worthwile to note that, while CCMP acts as the means to 235 manipulate conference objects, its specification does not define 236 these objects as well. In fact, a separate document has been written 237 to specify how a conference object and all its components have to be 238 constructed: the Conference Information Data Model for Centralized 239 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP, 240 according to the request type and the related operation, carries 241 pieces of conference objects (or any object as a whole) according to 242 the aforementioned specification. This means that any implementation 243 aiming at being compliant with CCMP has to make sure that the 244 transported objects are completely compliant with the Data Model 245 specification and coherent with the constraints defined therein. To 246 make this clearer, there are elements that are mandatory in a 247 conference object: issuing a syntactically correct CCMP request that 248 carries a wrong conference object is doomed to result in a failure. 249 For this reason, it is suggested that the interested implementors 250 take special care in carefully checking the Data Model handlers as 251 well in order to avoid potential mistakes. 253 Of course, there are cases where a mandatory element in the Data 254 Model cannot be assigned in a conference object by a CCMP user. For 255 instance, a CMCC may be requesting the direct creation of a new 256 conference: in this case, a conference object assumes an 'entity' 257 element uniquely identifying the conference to be in place. Anyway, 258 the CMCC has no way to a priori know what the entity will be like, 259 considering it will only be generated by the ConfS after the request. 260 For scenarios like this one, the CCMP specification envisages the use 261 of a dedicated placeholder wildcard to make the conference object 262 compliant with the Data Model: the wildcard would then be replaced by 263 the ConfS with the right value. 265 4.2. Using HTTP as a transport 267 CCMP requests and responses can be transported from a client to a 268 server and viceversa through several ways, being the protocol 269 specification agnostic with respect to the transport in use. In 270 [I-D.ietf-xcon-ccmp], focus is given on HTTP as a solution for this 271 transport matter, and a whole chapter is devoted in the document to 272 how HTTP can be used for it. The following lines will provide a 273 brief explanation, from a more practical point of view, of how HTTP 274 might be exploited to carry CCMP messages. In this document, 275 however, all the call flows herein presented will just show the CCMP 276 interactions, without talking about how the messages could have gone 277 across the network. 279 In case HTTP is used as a transport, the specification is very clear 280 with respect to how the interaction has to occur. Specifically, a 281 CMCC is assumed to send his request as part of an HTTP POST message, 282 and the ConfS would reply by means of an HTTP 200 message. In both 283 cases, the HTTP messages would have the CCMP messages as payload, 284 which would be reflected in the Content-Type message. Figure 1 285 presents a ladder diagram of such interaction, which is followed by a 286 dump of the exchanged HTTP messages for further analysis: 288 CMCC ConfS 289 | | 290 | 1. HTTP POST (CCMP request) | 291 |--------------------------------------------->| 292 | | 293 | |--+ Parse request, 294 | | | update object 295 | |<-+ and reply 296 | | 297 | 2. 200 OK (CCMP response) | 298 |<---------------------------------------------| 299 | | 300 |--+ Parse response and | 301 | | update local copy | 302 |<-+ of conference object | 303 | | 304 . . 305 . . 307 Figure 1: CCMP on HTTP 309 As it can be seen in the protocol dump in the following lines, the 310 CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve' 311 operation) towards the Conferencing Server (ConfS). The request has 312 been carried as payload of an HTTP POST (message 1.) towards a 313 previously known location. The mandatory 'Host' header has been 314 specified, and the 'Content-Type' header has been correctly set as 315 well (application/ccmp+xml). 317 The ConfS, in turn, has handled the request and replied accordingly. 318 The response (a blueprintResponse with a 'success' response code) has 319 been carried as payload of an HTTP 200 OK (message 2.). As before, 320 the 'Content-Type' header has been correctly set (application/ 321 ccmp+xml). 323 1. CMCC -> ConfS (HTTP POST, CCMP request) 324 ------------------------------------------ 325 POST /Xcon/Ccmp HTTP/1.1 326 Content-Length: 657 327 Content-Type: application/ccmp+xml 328 Host: example.com:8080 329 Connection: Keep-Alive 330 User-Agent: Apache-HttpClient/4.0.1 (java 1.5) 332 333 337 339 xcon-userid:Alice@example.com 340 xcon:AudioRoom@example.com 341 retrieve 342 343 344 346 2. CMCC <- ConfS (200 to POST, CCMP response) 347 --------------------------------------------- 348 HTTP/1.1 200 OK 349 X-Powered-By: Servlet/2.5 350 Server: Sun GlassFish Communications Server 1.5 351 Content-Type: application/ccmp+xml;charset=ISO-8859-1 352 Content-Length: 1652 353 Date: Thu, 04 Feb 2010 14:47:56 GMT 355 356 360 362 xcon-userid:Alice@example.com 363 xcon:AudioRoom@example.com 364 retrieve 365 success 366 367 368 369 AudioRoom 370 2 371 372 373 audio 374 375 376 377 378 allow 379 380 381 confirm 382 383 384 385 386 387 388 389 390 392 Just for the sake of completeness, a few words will be spent about 393 the occurred CCMP interaction as well. In fact, despite the 394 simplicity of the request, this flow already provides some relevant 395 information on how CCMP messages are built. Specifically, both the 396 request and the response share a subset of the message: 398 o confUserID: this element, provided by the CMCC, refers to the 399 requester by means of his XCON-USERID; except in a few scenarios 400 (presented in the following sections) this element must always 401 contain a valid value; 403 o confObjID: this element refers to the target conference object, 404 according to the request in place; 406 o operation: this element specifies the operation the CMCC wants to 407 perform according to the specific request type. 409 Besides those elements, the CMCC (in this case Alice, since the 410 'confUserID' has been set to 'xcon-userid:Alice@example.com') has 411 also provided an additional element, 'blueprintRequest'. The name of 412 that element varies according to the request type the CMCC is 413 interested into. In this specific scenario, the CMCC was interested 414 in acquiring details concerning a specific blueprint (identified by 415 its XCON-URI 'xcon:AudioRoom@example.com', as reflected in the 416 provided 'confObjID' target element), and so the request consisted in 417 an empty 'blueprintRequest' element. As it will be clearer in the 418 following sections, different request types may require different 419 elements, and as a consequence different content. 421 Considering the request was a 'blueprintRequest', the ConfS has 422 replied with a 'blueprintResponse' element. This element includes a 423 complete dump of the conference object (compliant with the Data 424 Model) describing the requested blueprint, together with an element 425 addressing the result of the client's request (response- 426 code=success). 428 This section won't delve in additional details for what concerns this 429 interaction. It is just worth noticing that this was the example of 430 the simplest CCMP communication that could take place between a CMCC 431 and a ConfS, a blueprintRequest: this scenario will be described in 432 more detail in Section 5.2. 434 4.3. Conference Notifications 436 [RFC5239] presents several different possible protocol interactions 437 between a conferencing server and a conferencing client. One of 438 those interactions is generically called "Notification Protocol", 439 implementing a notification service for all clients interested in 440 being informed by the server whenever something relevant happens in a 441 conference. While at first glance it may appear that such a 442 functionality should belong to a conference control protocol, such 443 feature has been specifically marked as out of scope in CCMP. As a 444 consequence, CCMP has been conceived as a request/answer protocol, 445 and in fact no ways to provide notifications to clients have been 446 introduced in the specification. 448 Nevertheless, the CCMP document by itself has a brief section 449 presenting some typical ways notifications might be managed. This 450 example document does not foster one rather than another, and all the 451 flows will always generically present a notification being involved, 452 when it seems appropriate, but not providing any info on how the 453 notification itself has been sent to the interested clients. Anyway, 454 this section will briefly introduce some of the most typical ways a 455 notification service could be implemented and integrated with the 456 functionality provided by CCMP. It is by no means to be intended as 457 a complete list of solutions: the aim of this section is to provide 458 an overview of some of the possible solutions, together with 459 indications on how they may be integrated into a CCMP-based platform. 461 The first approach that comes to mind is of course the XCON Event 462 Package [I-D.ietf-xcon-event-package]. This specification extends 463 the SIP Event Package for Conference State [RFC4575] and allows for 464 the notification of conference notifications by means of the NOTIFY/ 465 SUBSCRIBE mechanisms of SIP. Specifically, any SIP client who 466 subscribed for notifications related to a specific conference would 467 receive notifications via SIP describing all the changes to the 468 document. An example ladder diagram is presented in Figure 2: in 469 this figure, we assume a CMCC has updated a conference object, and 470 the update is notified to a previously subscribed SIP client. 472 CMCC ConfS UAC 473 | | | 474 | | 1. SIP SUBSCRIBE | 475 | |<--------------------------| 476 | Handle +--| | 477 | new | | | 478 | subscription +->| 2. SIP 200 OK | 479 | |-------------------------->| 480 | | | 481 . . . 482 . . . 483 | | | 484 | 3. CCMP (add user) | | 485 |---------------------->| | 486 | |--+ Add user | 487 | | | to conf. | 488 | |<-+ object | 489 | 4. CCMP (success) | | 490 |<----------------------| | 491 | | 5. SIP NOTIFY (changes) | 492 | |-------------------------->| 493 | | 6. SIP 200 OK | 494 | |<--------------------------| 495 | | | 496 . . . 497 . . . 499 Figure 2: XCON Event Package: SIP notifications 501 Considering CCMP is going to be probably most often deployed on HTTP, 502 another way to achieve notifications might be by exploiting some sort 503 of HTTP callbacks, as suggested in the CCMP specification itself. 504 This would allow to overcome the previous limitation, since both the 505 CMCC and the ConfS would already have an HTTP stack to make use of. 506 Using this approach, an interested web client might provide the 507 Conferencing System with an URL to contact whenever updates are 508 available: the update could be part of the notification message 509 itself, or it could be only implicitly referenced by the 510 notification. At the same time, alternative notification means could 511 be exploited, e.g. by taking advantage of functionality provided by 512 other protocols such as XMPP. Figure 3 shows an example of different 513 subscriptions which accordingly trigger notifications after the same 514 relevant event happens. 516 CMCC ConfS Sub1 Sub2 517 | | | | 518 | | 1. Register callback | | 519 | |<--------------------------| | 520 | Handle +--| | | 521 | new HTTP | | | | 522 | subscription +->| 2. Acknlowledge | | 523 | |-------------------------->| | 524 | | | | 525 | | 3. XMPP subscription | 526 | |<---------------------------------------| 527 | Handle +--| | | 528 | new XMPP | | | | 529 | subscription +->| 4. XMPP confirm subscription | 530 | |--------------------------------------->| 531 | | | | 532 . . . . 533 . . . . 534 | | | | 535 | 5. CCMP (add user) | | | 536 |-------------------->| | | 537 | |--+ Add user | | 538 | | | to conf. | | 539 | |<-+ object | | 540 | 6. CCMP (success) | | | 541 |<--------------------| | | 542 | | 7. HTTP POST (changes) | | 543 | |-------------------------->| | 544 | | 8. HTTP 200 OK | | 545 | |<--------------------------| | 546 | | | | 547 | | 9. XMPP notification | | 548 | |--------------------------------------->| 549 | | | | 550 . . . . 551 . . . . 553 Figure 3: Alternative means for notifications 555 That said, there are actually many other ways to achieve 556 notifications in a conferencing system. A conferencing system may 557 rely on several other solutions than the ones presented as periodic 558 checks of a well known URL by interested clients, long polls, BOSH- 559 based communications, Atom/RSS feeds and the like. 561 5. Conference Creation 563 This section starts the sequence of call flows of typical XCON- 564 related scenarios provided in this document. Specifically, it 565 provides details associated with the various ways in which a 566 conference can be created using CCMP and the XCON framework 567 constructs. As previously mentioned the details of the media 568 control, call signaling and floor control protocols, where 569 applicable, are annotated in the flows without showing all the 570 details. This also applies to CCMP, whose flows are related to the 571 protocol alone, hiding any detail concerning the transport that may 572 have been used (e.g. HTTP). However, for clarification purposes, 573 the first example Section 5.1 provides the details of the media 574 control messaging along with an example of the standard annotation 575 used throughout the remainder of this document. In subsequent flows, 576 only this annotation (identified by lower case letters) is included 577 and the reader is encouraged to refer to the call flows in the 578 relevant documents for details about the other protocols. The 579 annotations for the call signaling are on the left side of the 580 conferencing server vertical bar and those for the media control 581 messaging are on the right side. 583 5.1. Basic Conference Creation 585 The simplest manner in which a conference can be created is 586 accomplished by the client sending a "confRequest" message with the 587 "create" operation as the only parameter to the conference server, 588 together with the "confUserID" associated with the requesting client 589 itself. This results in the creation of a default conference, with 590 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID 591 in the form of the "confUserID" parameter (the same already present 592 in the request) and the data for the conference object in the 593 "confInfo" parameter all returned in the "confResponse" message. 594 According to the implementation of the framework, this example may 595 also add the user that invoked the conference upon creation to the 596 conference object (e.g., "method" attribute in the "target" element 597 of "allowed-users-list" may be set to "dial out" for this client 598 based on the particular conferencing systems default). This is 599 exactly the case depicted in the figure, which is presented to enrich 600 the scenario. 602 The specific data for the conference object are returned in the 603 "confResponse" message in the "confInfo" parameter. This allows the 604 client (with the appropriate authorization) to manipulate these data 605 and add additional participants to the conference, as well as change 606 the data during the conference. In addition, the client may 607 distribute the conferencing information to other participants 608 allowing them to join, the details of which are provided in 609 additional flows. Please notice that, according to the CCMP 610 specification, the return of the new conference data in the 611 "confInfo" parameter is not mandatory: if the "confInfo" parameter of 612 the successful confResponse/create is void, a following confRequest/ 613 retrieve of the returned "confObjID" can be triggered to provide the 614 requesting client with the detailed conference description. 616 Clients that are not XCON-aware can join the conference using a 617 specific signaling interface such as SIP [RFC3261] or other supported 618 signaling protocols (being XCON agnostic with respect to them), using 619 the signaling interface to the conference focus as described in 620 [RFC4579]. However, these details are not shown in the message 621 flows. The message flows in this document identify the point in the 622 message flows at which this signaling occurs via the lower case 623 letter items (i.e., (a)...(x)) along with the appropriate text for 624 the processing done by the conferencing server. 626 As anticipated at the beginning of this section, this example also 627 shows how the conferencing system may make use of other standard 628 components to make available its functionality. An example of that 629 is the MEDIACTRL specification, which allows the conferencing system 630 to configure conference mixes, IVR dialogs and all sort of media- 631 related interactions an application like this may need. So, just to 632 provide the reader with some insight on these interactions, the 633 conferencing system also configures and starts a mixer via MEDIACTRL 634 as soon as the conference is created (transactions A1 and A2), and 635 attaches clients to it when necessary (e.g. when CMCC1 joins the 636 conference by means of SIP signaling, its media channels are attached 637 to the Media Server using MEDIACTRL in B1/B2). 639 CMCC1 CMCC2 CMCCx ConfS MS 640 | | | | | 641 |(1)confRequest(confUserID, create) | | 642 |-------------------------------------->| | 643 | | (a)Create +---| | 644 | | |Conf | | | 645 | | |Object | | | 646 | | |& IDs +-->| | 647 | | | | A1. CONTROL | 648 | | | |+++++++++++>>| 649 | | | |(create conf)|--+ (b) 650 | | | | | | create 651 | | | | | | conf and 652 | | | | A2. 200 OK |<-+ its ID 653 | | | |<<+++++++++++| 654 | | | |(confid=Y) | 655 |(2)confResponse(confUserID,confObjID, | | 656 | create, success, | | 657 | version, confInfo) | | 658 |<--------------------------------------| | 659 | | | | | 660 | | (c) Focus +---| | 661 | | sets up | | | 662 | | signaling | | | 663 | | to CMCC1 +-->| | 664 | | | | | 665 | | | | B1. CONTROL | 666 | | | |+++++++++++>>| 667 | | | | (join CMCC1 | 668 | | | | <->confY) | 669 | | | | | 670 | | | | |--+(d) join 671 | | | | | | CMCC1 & 672 | | | | B2.200 OK |<-+ conf Y 673 | | | |<<+++++++++++| 674 | | | | | 675 |<<#################################################>>| 676 | Now the CMCC1 is mixed in the conference | 677 |<<#################################################>>| 678 | | | | | 679 |******CMCC1 may then manipulate conference data *****| 680 |****** and add addt'l users, etc. | *****| 681 ' ' ' ' ' 682 ' ' ' ' ' 683 ' ' ' ' ' 684 Figure 4: Create Basic Conference - Complete flow 686 "Alice" "Bob" 687 CMCC1 CMCC2 CMCCx ConfS 688 | | | | 689 |(1)confRequest(confUserID, create) | 690 |-------------------------------------->| 691 | | | | 692 | | (a)Create +---| 693 | | |Conf | | 694 | | |Object | | 695 | | |& IDs +-->| 696 | | | |--+ (b) MS 697 | | | | | creates 698 | | | | | conf and 699 | | | |<-+ its ID 700 | | | | (confid=Y) 701 |(2)confResponse(confUserID, confObjID | 702 | create, success, | 703 | version, confInfo) | 704 | | | | 705 |<--------------------------------------| 706 | | | | 707 | | | | 708 | | (c) Focus +---| 709 | | sets up | | 710 | | signaling | | 711 | | to CMCC1 +-->| 712 | | | | 713 | | | |--+(d) MS joins 714 | | | | | CMCC1 & 715 | | | |<-+ conf Y 716 |<<###################################>>| 717 | CMCC1 is mixed in the conference | 718 |<<###################################>>| 719 | | | | 720 |**CMCC1 then manipulates conference****| 721 |** data and add addt'l users, etc. ***| 722 ' ' ' ' 723 ' ' ' ' 724 ' ' ' ' 725 - 727 Figure 5: Create Basic Conference - Annotated Flow 729 1. confRequest/create message (Alice creates a default conference) 731 732 736 739 xcon-userid:Alice@example.com 740 create 741 742 744 2. confResponse/create message ("success", created conference 745 object returned) 747 748 752 755 xcon-userid:Alice@example.com 756 xcon:8977794@example.com 757 create 758 success 759 1 760 761 762 763 764 Default conference initiated by Alice 765 766 767 768 769 xcon:8977794@example.com 770 771 772 Conference XCON-URI 773 774 775 776 10 777 778 779 audio 780 781 782 783 false 784 785 786 787 allow 788 789 791 792 793 794 795 796 798 Figure 6: Create Basic Conference (Annotated) Detailed Messaging 800 5.2. Conference Creation using Blueprints 802 The previous example showed the creation of a new conference using 803 default values. This means the client provided no information about 804 how she wanted the conference to be like. Anyway, the XCON framework 805 (and CCMP as a consequence) allows for the exploitation of templates. 806 These templates are called "conference blueprints", and are basically 807 conference objects with pre-defined settings except for the actual 808 identifiers. This means that a client might get one of these 809 blueprints, choose the one that more fits his needs, and use the 810 chosen blueprint to create a new conference. 812 This section addresses exactly this scenario, and Figure 7 provides 813 an example of one client, "Alice", discovering the conference 814 blueprints available for a particular conferencing system and 815 creating a conference based on the desired blueprint. In particular, 816 Alice is interested in those blueprints suitable to represent a 817 "video-conference", i.e. a conference in which both audio and video 818 are available, so she exploits the filter mechanism envisioned by 819 CCMP to make a selective blueprints retrieve request. This results 820 in three distinct CCMP transactions. 822 CMCC "Alice" ConfS 823 | | 824 | (1) blueprintsRequest | 825 | (confUserID,xpathFilter) | 826 |------------------------------>| 827 | | 828 | (2) blueprintsResponse | 829 | (confUserID, success, | 830 | blueprintsInfo) | 831 |<------------------------------| 832 | | 833 |--+ | 834 | | choose preferred | 835 | | blueprint from the | 836 | | list (blueprintName) | 837 |<-+ | 838 | | 839 | (3) blueprintRequest | 840 | (confUserID,confObjID, | 841 | retrieve) | 842 |------------------------------>| 843 | | 844 | 4) blueprintResponse | 845 | (confUserID,confObjID,| 846 | retrieve,confInfo) | 847 |<------------------------------| 848 | | 849 | (5) confRequest(confUserID, | 850 | confObjID,create) | 851 |------------------------------>| 852 | | 853 | (a)Create +---| 854 | Conf | | 855 | Object | | 856 | & IDs +-->| 857 | |--+ (b) MS 858 | | | creates 859 | | | conf and 860 | |<-+ its ID 861 | | (confid=Y) 862 |(6) confResponse | 863 | (confUserID, confObjID*, | 864 | create, success) | 865 |<------------------------------| 866 | | 867 | | 868 | | 869 . . 871 . . 873 Figure 7: Client Creation of Conference using Blueprints 875 1. Alice first sends a "blueprintsRequest" message to the 876 conferencing system identified by the conference server discovery 877 process. This request contains the "confUserID" of the user 878 issuing the request (Alice's XCON-USERID) and the "xpathFilter" 879 parameter by which Alice specifies she desires to obtain only 880 blueprints providing support for both audio and video: for this 881 purpose, the xpath query contained in this field is: "/ 882 conference-info[conference-description/available-media/entry/ 883 type='audio' and conference-description/available-media/entry/ 884 type='video'"] . Upon receipt of the "blueprintsRequest", the 885 conferencing system would first control, on the basis of the 886 "confUserID" parameter, that Alice has the appropriate authority 887 based on system policies to receive the requested kind of 888 blueprints supported by that system. 890 2. All blueprints that Alice is authorized to use are returned in a 891 "blueprintsResponse" message in the "blueprintsInfo" element. 893 3. Upon receipt of the "blueprintsResponse" containing the 894 blueprints, Alice determines which blueprint to use for the 895 conference to be created. Alice sends a "blueprintRequest" 896 message to get the specific blueprint as identified by the 897 "confObjID". 899 4. The conferencing system returns the "confInfo" associated with 900 the specific blueprint as identified by the "confObjID" in the 901 "blueprintResponse" message. 903 5. Alice finally sends a "confRequest" with a "create" operation to 904 the conferencing system to create a conference reservation 905 cloning the chosen blueprint. This is achieved by writing the 906 blueprint's XCON-URI in the "confObjID" parameter. 908 6. Upon receipt of the "confRequest" message with a "create" 909 operation, the conferencing system uses the received blueprint to 910 clone a conference, allocating a new XCON-URI (again called 911 "confObjID*" in the example). The conferencing server then sends 912 a "confResponse" message including the new "confObjID*" 913 associated with the newly created conference instance. Upon 914 receipt of the "confResponse" message, Alice can now add other 915 users to the conference . 917 1. blueprintsRequest message (Alice requires the list of the 918 available blueprints with video support) 920 921 924 926 xcon-userid:Alice@example.com 927 928 /conference-info[conference-description/ 929 available-media/entry/type='audio' and 930 conference-description/available-media/entry/type='video'] 931 932 933 934 936 2. blueprintsResponse message (the server provides a descriptions of 937 the available blueprints fitting Alice's request) 939 940 944 947 xcon-userid:Alice@example.com 948 success 949 950 951 952 xcon:VideoRoom@example.com 953 VideoRoom 954 Video Room: 955 conference room with public access, 956 where both audio and video are available, 957 4 users can talk and be seen at the same time, 958 and the floor requests are automatically accepted. 959 960 961 962 xcon:VideoConference1@example.com 963 VideoConference1 964 Public Video Conference: conference 965 where both audio and video are available, 966 only one user can talk 967 968 969 970 971 972 974 3. blueprintRequest/retrieve message (Alice wants the 975 "VideoRoom" blueprint) 977 978 982 984 xcon-userid:Alice@example.com 985 xcon:VideoRoom@example.com 986 retrieve 987 988 989 991 4. blueprintResponse/retrieve message ("success", "VideoRoom" 992 conference object returned) 994 995 999 1001 xcon-userid:Alice@example.com 1002 xcon:VideoRoom@example.com 1003 retrieve 1004 success 1005 1006 1007 1008 VideoRoom 1009 4 1010 1011 1012 audio 1013 1014 1015 video 1016 1017 1018 1019 1020 allow 1021 1022 1023 confirm 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1035 5. confRequest/create message (Alice clones the "VideoRoom" blueprint) 1037 1038 1042 1045 xcon-userid:Alice@example.com 1046 xcon:VideoRoom@example.com 1047 create 1048 1049 1050 1052 6. confResponse/create message ("success", cloned conference 1053 object returned) 1055 1056 1060 1063 xcon-userid:Alice@example.com 1064 xcon:8977794@example.com 1065 create 1066 success 1067 1 1068 1069 1070 1071 1072 New conference by Alice cloned from VideoRoom 1073 1074 1075 1076 1077 xcon:8977794@example.com 1078 1079 1080 conference xcon-uri 1081 1082 1083 8601 1084 1085 1086 1087 10 1088 1089 1090 audio 1091 1092 1093 video 1094 1095 1096 1097 1098 allow 1099 1100 1101 1102 confirm 1103 1104 1105 1106 1108 1109 1110 1111 1112 1114 Figure 8: Create Conference (Blueprint) Detailed Messaging 1116 5.3. Conference Creation using User-Provided Conference Information 1118 A conference can also be created by the client sending a 1119 "confRequest" message with the "create" operation, along with the 1120 desired data in the form of the "confInfo" parameter for the 1121 conference to be created. The request also includes the "confUserID" 1122 of the requesting entity. 1124 This approach allows for a client (in this example Alice) to 1125 completely describe how the conference object should look like, 1126 without just relying on defaults or blueprints: i.e. which media 1127 should be available, whish should be the topic, the users allowed to 1128 join, any scheduling-related information and so on. This can be 1129 done, as anticipated, by providing in the creation request a full 1130 conference object for the server to parse. 1132 This "confInfo" parameter must comply of course with the Data Model 1133 specification. This means that its "entity" attribute is mandatory, 1134 and cannot be missing in the document. Nevertheless, considering in 1135 this example the client is actually requesting the creation of a new 1136 conference, which doesn't exist yet, this "entity" attribute cannot 1137 be set to a valid value. This is related to an issue already 1138 anticipated in Section 4.1. To cope with this, the CCMP protocol 1139 fosters the use of a wildcard placeholder: this placeholder 1140 ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim 1141 of making the "confInfo" element compliant with the Data Model, and 1142 would subsequently be replaced by the conferencing system with the 1143 actual value. This means that, as soon as the conferencing system 1144 actually creates the conference, a valid "entity" value is created 1145 for it as well, which would take the place of the wildcard when 1146 completing the actual conference object provided by the client. 1148 To give a flavour of what could be added to the conference object, we 1149 assume Alice is also interested in providing scheduling-related 1150 information. So, in this example, Alice also specifies by the 1151 element included in the "confInfo" that the 1152 conference she wants to create has to occur on a certain date from a 1153 certain start time to a certain stop time and has to be replicated 1154 weekly. 1156 Once Alice has prepared the "confInfo" element and sent it as part of 1157 her request to the server, if the conferencing system can support 1158 that specific type of conference (capabilities, etc.), then the 1159 request results in the creation of a conference. We assume the 1160 request has been successful, and as a consequence XCON-URI in the 1161 form of the "confObjID" parameter and the XCON-USERID in the form of 1162 the "confUserID" parameter (again, the same as the requesting entity) 1163 are returned in the "confResponse" message. 1165 In this example, we choose not to return the created conference 1166 object in the successful "confResponse" in the "confInfo" parameter. 1167 Nevertheless, Alice could still retrieve the actual conference object 1168 by issuing a "confRequest" with a "retrieve" operation on the 1169 returned "confObjID". Such a request would show how, as we 1170 anticipated at the beginning of this section, the "entity" attribute 1171 of the conference object in "confInfo" is replaced with the actual 1172 information (i.e. "xcon:6845432@example.com"). 1174 Just for the sake of completeness and to provide the reader with some 1175 insight about how the CCMP conferencing server might interact with 1176 other related components, this example also assumes that the 1177 conference is activated upon creation: i.e., the "method" attribute 1178 is set to "dial out" for this client based on the particular 1179 conferencing systems default. This results (as shown in the ladder 1180 diagram) in Alice, Bob and Carol being called by the conferencing 1181 system. Just as before, this is not to be considered mandatory, 1182 since it depends on the implementation choices of the framework. 1184 Alice Bob Carol ConfS 1185 | | | | 1186 | | | | 1187 |(1)confRequest(confUserID, | | 1188 | create, confInfo) | | 1189 | | | | 1190 |-------------------------------------->| 1191 | | | | 1192 | | (a)Create +---| 1193 | | |Conf | | 1194 | | |Object | | 1195 | | |& IDs +-->| 1196 | | | |--+ (b) MS 1197 | | | | | creates 1198 | | | | | conf and 1199 | | | |<-+ its ID 1200 | | | | (confid=Y) 1201 |(2)confResponse(confUserID | | 1202 | confObjID, create, | | 1203 | success, version) | | 1204 |<--------------------------------------| 1205 | | | | 1206 | | (c) Focus +---| 1207 | | sets up | | 1208 | | signaling | | 1209 | | to Alice +-->| 1210 | | | | 1211 | | | |--+(d) MS joins 1212 | | | | | Alice & 1213 | | | |<-+ conf Y 1214 | | | | 1215 | | | | 1216 |<<###################################>>| 1217 | Alice is mixed in the conference | 1218 |<<###################################>>| 1219 | | | | 1220 | | (e)Focus +---| 1221 | | sets up | | 1222 | | signaling | | 1223 | | to Bob | | 1224 | | | +-->| 1225 | | | | 1226 | | | |--+(f)MS joins 1227 | | | | | Bob & 1228 | | | |<-+ conf Y 1229 | | | | 1230 | |<<###################>>| 1231 | | Bob is mixed too | 1232 | |<<###################>>| 1233 | | | | 1234 | | (g )Focus +---| 1235 | | sets up | | 1236 | | signaling | | 1237 | | to Carol | | 1238 | | CMCCx +-->| 1239 | | | | 1240 | | | |--+(h)MS joins 1241 | | | | | CMCCx & 1242 | | | |<-+ conf Y 1243 | | | | 1244 | | |<<#######>>| 1245 | | |Carol mixed| 1246 | | |<<#######>>| 1247 | | | | 1248 | | | | 1249 | | | | 1250 |<***All parties connected to conf Y***>| 1251 | | | | 1252 | | | | 1253 " " " " 1254 " " " " 1255 " " " " 1257 Figure 9: Create Basic Conference from user provided conference-info 1259 1. confRequest/create message (Alice proposes a conference object 1260 to be created - direct creation) 1262 1263 1267 1270 xcon-userid:Alice@example.com 1271 create 1272 1273 1274 1275 1276 Dial-out conference initiated by Alice 1277 1278 10 1279 1280 1281 audio 1282 1283 1284 1285 1286 1287 BEGIN:VCALENDAR 1288 VERSION:2.0 1289 PRODID:-//Mozilla.org/NONSGML \ 1290 Mozilla Calendar V1.0//EN 1291 BEGIN:VEVENT 1292 DTSTAMP: 20100127T140728Z 1293 UID: 20100127T140728Z-345FDA-alice@example.com 1294 ORGANIZER:MAILTO:alice@example.com 1295 DTSTART:20100127T143000Z 1296 RRULE:FREQ=WEEKLY 1297 DTEND: 20100127T163000Z 1298 END:VEVENT 1299 END:VCALENDAR 1300 1301 1303 2010-01-27T14:29:00Z 1304 1305 1307 2010-01-27T16:31:00Z 1308 1309 2010-01-27T15:30:00Z 1310 1311 1312 1313 1314 1315 allow 1316 1317 1319 1321 1323 1324 1325 1326 1327 1328 1330 2. confResponse/create message ("success") 1332 1333 1337 1340 xcon-userid:Alice@example.com 1341 xcon:6845432@example.com 1342 create 1343 success 1344 1 1345 1346 1348 Figure 10: Create Basic Conference Detailed Messaging 1350 5.4. Cloning an Existing Conference 1352 A client can also create another conference by cloning an existing 1353 conference, such as an active conference or conference reservation. 1354 This approach can be seen as a logical extension of the creation of a 1355 new conference using a blueprint: the difference is that, instead of 1356 cloning the pre-defined settings listed in a blueprint, the settings 1357 of an existing conference would be cloned. 1359 In this example, the client sends a "confRequest" message with the 1360 "create" operation, along with the "confUserID" and a specific 1361 "confObjID", from which a new conference is to be created by cloning 1362 an existing conference. 1364 An example of how a client can create a conference based on a 1365 blueprint is provided in Section 5.2. The manner by which a client 1366 in this example might learn about a conference reservation or active 1367 conferences is similar to the first step in the blueprint example, 1368 with the exception of specifying querying for different types of 1369 conference objects supported by the specific conferencing system. 1370 For example, in this example, the client clones a conference 1371 reservation (i.e., an inactive conference). 1373 If the conferencing system can support a new instance of the specific 1374 type of conference (capabilities, etc.), then the request results in 1375 the creation of a conference, with an XCON-URI in the form of a new 1376 value in the "confObjID" parameter to reflect the newly cloned 1377 conference object returned in the "confResponse" message. 1379 Alice ConfS 1380 | | 1381 |(1)confRequest(confUserID, | 1382 | confObjID, create) | 1383 |------------------------------>| 1384 | (a)Create +---| 1385 | Conf | | 1386 | Object | | 1387 | & IDs +-->| 1388 | |--+ (b) MS 1389 | | | creates 1390 | | | conf and 1391 | |<-+ its ID 1392 | | (confid=Y) 1393 | | 1394 |(2)confResponse(confUserID, | 1395 | confObjID*,create, | 1396 | success, version, | 1397 | confInfo) | 1398 | | 1399 |<------------------------------| 1400 | | 1402 Figure 11: Create Basic Conference - Clone 1404 1. Alice, a conferencing system client, sends a confRequest message 1405 to clone a conference based on an existing conference 1406 reservation. Alice indicates this conference should be cloned 1407 from the specified parent conference represented by the 1408 "confObjID" in the request. 1410 2. Upon receipt of the confRequest message containing a "create" 1411 operation and "confObjID", the conferencing system ensures that 1412 the "confObjID" received is valid. The conferencing system 1413 determines the appropriate read/write access of any users to be 1414 added to a conference based on this "confObjID" (using 1415 membership, roles, etc.). The conferencing system uses the 1416 received "confObjID" to clone a conference reservation. The 1417 conferencing system also reserves or allocates a new "confObjID" 1418 (called "confObjID*" in Figure 11) to be used for the cloned 1419 conference object. This new identifier is of course different 1420 from the one associated with the conference to be cloned, since 1421 it represents a different conference object. Any subsequent 1422 protocol requests from any of the members of the conference must 1423 use this new identifier. The conferencing system maintains the 1424 mapping between this conference ID and the parent conference 1425 object ID associated with the reservation through the conference 1426 instance, and this mapping is explicitly addressed through the 1427 "cloning-parent" element of the "conference-description" in the 1428 new conference object. 1430 1. confRequest/create message 1432 1433 1437 1440 xcon-userid:Alice@example.com 1441 xcon:6845432@example.com 1442 create 1443 1444 1446 2. confResponse/create message ("success", created conference 1447 object returned) 1449 1450 1454 1457 xcon-userid:Alice@example.com 1458 xcon:8977794@example.com 1459 create 1460 success 1461 1 1462 1463 1464 1465 1466 New conference by Alice cloned from 6845432 1468 1469 1470 xcon:6845432@example.com 1471 1472 10 1473 1474 1475 audio 1476 1477 1478 1479 1480 allow 1481 1482 1484 1486 1488 1489 1490 1491 1492 confirm 1493 1494 1495 1496 1497 1498 1499 1500 1502 Figure 12: Create Basic Conference (Clone) Detailed Messaging 1504 6. Conference Users Scenarios and Examples 1506 Section 5 showed examples describing the several different ways a 1507 conference might be created using CCMP. This section instead focuses 1508 on user-related scenarios, i.e. typical scenarios that may occur 1509 during the lifetime of a conference, like adding new users and 1510 handling their media. The following scenarios are based on those 1511 documented in the XCON framework. The examples assume that a 1512 conference has already been correctly established, with media, if 1513 applicable, per one of the examples in Section 5. 1515 6.1. Adding a Party 1517 In this example, Alice wants to add Bob to an established conference. 1518 In the following example we assume Bob is a new user of the system, 1519 which means Alice also needs to provide some details about him. In 1520 fact, the case of Bob already present as a user in the conferencing 1521 system is much easier to address, and will be discussed later on. 1523 "Alice" "Bob" 1524 CMCC1 CMCC2 CMCCx ConfS 1525 | | | | 1526 |(1) userRequest(confUserID,| | 1527 | confObjID, create, | | 1528 | userInfo) | | | 1529 |-------------------------------------->| 1530 | | | | 1531 | | (a) Create +---| 1532 | | | Bob | | 1533 | | | as a | | 1534 | | | user +-->| 1535 | | | | 1536 |(2) userResponse(confUserID,confObjID | 1537 | create,success,userInfo) | 1538 |<--------------------------------------| 1539 | | | | 1540 | | | (b) Focus | 1541 | | | sets up | 1542 | | | signaling | 1543 | | | to Bob | 1544 | |<----------------------| 1545 | | | | 1546 | | | (c) Notify| 1547 | | | ("Bob just| 1548 | | | joined") | 1549 | | |<----------| 1550 | | | | 1551 ' ' ' ' 1552 ' ' ' ' 1553 ' ' ' ' 1555 Figure 13: Client Manipulation of Conference - Add a party 1557 1. Alice sends a userRequest message with an operation of "create" 1558 to add Bob to the specific conference as identified by the 1559 "confObjID". The "create" operation also makes sure that Bob is 1560 created as a user in the whole conferencing system. This is done 1561 by adding a "userInfo" element describing Bob as a user. This is 1562 needed in order to let the conferencing system be aware of Bob's 1563 characteristics. In case Bob was already a registered user, 1564 Alice would just have referenced him through his XCON-USERID in 1565 the "entity" attribute of the "userInfo" field, without providing 1566 additional data. In fact, that data (including, for instance, 1567 Bob's SIP-URI to be used subsequently for dial-out) would be 1568 obtained by referencing the extant registration. The conference 1569 server ensures that Alice has the appropriate authority based on 1570 the policies associated with that specific conference object to 1571 perform the operation. As mentioned before, a new Conference 1572 User Identifier is created for Bob, and the "userInfo" is used to 1573 update the conference object accordingly. As already seen in 1574 Section 5.3, a placeholder wildcard 1575 ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages 1576 below) is used for the "entity" attribute of the "userInfo" 1577 element, to be replaced by the actual XCON-USERID later on; 1579 2. Bob is successfully added to the conference object, and an XCON- 1580 USERID is allocated for him ("xcon-userid:Bob@example.com"); this 1581 identifier is reported in the response as part of the "entity" 1582 element of the returned "userInfo"; 1584 3. In the presented example, the call signaling to add Bob to the 1585 conference is instigated through the Focus as well. We again 1586 remind that this is implementation specific. In fact, a 1587 conferencing system may accomplish different actions after the 1588 user creation, just as it may do nothing at all. Among the 1589 possible actions, for instance Bob may be added as a 1590 element to the element, whose joining 1591 "method" may be either "dial-in" or "dial-out". Besides, out-of- 1592 band notification mechanisms may be involved as well, e.g. to 1593 notify Bob via mail of the new conference, including details as 1594 the date, password, expected participants and so on (see 1595 Section 4.3). 1597 To conclude the overview on this scenario, once Bob has been 1598 successfully added to the specified conference, per updates to the 1599 state, and depending upon the policies, other participants 1600 (including Bob himself) may be notified of the addition of Bob to 1601 the conference via the Conference Notification Service in use. 1603 1. userRequest/create message (Alice adds Bob) 1605 1606 1609 1611 xcon-userid:Alice@example.com 1612 xcon:8977878@example.com 1613 create 1614 1615 1616 Bob 1617 1618 1619 mailto:bob.depippis@example.com 1620 Bob's email 1621 1622 1623 1624 Bob's laptop 1625 1626 1627 1628 1629 1631 2. userResponse/create message ("success": a new XCON-USERID is 1632 created for Bob and he is added to the conference) 1634 1635 1638 1640 xcon-userid:Alice@example.com 1641 xcon:8977878@example.com 1642 create 1643 success 1644 10 1645 1646 1647 Bob 1648 1649 1650 mailto:bob.depippis@example.com 1651 Bob's email 1652 1653 1654 1655 Bob's laptop 1656 1657 1658 1659 1660 1662 Figure 14: Add Party Message Details 1664 6.2. Muting a Party 1666 This section provides an example of the muting of a party in an 1667 active conference. We assume that the user to mute has already been 1668 added to the conference. The document only addresses muting, since 1669 unmuting would involve an almost identical CCMP message flow. 1671 Please notice that interaction between CCMP and an ad-hoc designed 1672 floor control solution like BFCP should be carefully considered. 1673 Indeed, CCMP- and BFCP-based media control can be viewed as two 1674 alternative and potentially interfering solutions for what 1675 concerns floor control actions. As an example, a participant may 1676 have the BFCP floor granted, but be muted by means of CCMP; if so, 1677 he would still be muted in the conference and would only be 1678 unmuted if both protocols allowed for this. In general, the 1679 interaction between these potentially conflicting protocols falls 1680 in the wider scope of policy control at the overall system's level 1681 and is not the subject of this document. 1683 Figure 15 provides an example of one client, "Alice", impacting the 1684 media state of another client, "Bob". This example assumes an 1685 established conference. In this example, Alice, whose role is 1686 "moderator" of the conference, wants to mute Bob on a medium-size 1687 multi-party conference, as his device is not muted (and he's 1688 obviously not listening to the call) and background noise in his 1689 office environment is disruptive to the conference. BFCP floor 1690 control is assumed not to be involved. 1692 From a protocol point of view, muting/unmuting an user basically 1693 consists in updating the conference object by modifying the settings 1694 related to the target user's media streams. Specifically, Bob's 1695 "userInfo" must be updated by modifying its audio 1696 information (e.g. setting it to "recvonly" in case of muting), 1697 identified by the right media id. 1699 "Alice" "Bob" 1700 CMCC1 CMCC2 CMCCx ConfS MS 1701 | | | | | 1702 |(1) userRequest(subject, | | | 1703 | confUserID,confObjID, | | | 1704 | update,userInfo) | | | 1705 | | | | | 1706 |--------------------------------------->| | 1707 | | | | Mute Bob | 1708 | | | |----------------->| 1709 | | | | 200 OK | 1710 | | | |<-----------------| 1711 | | | | | 1712 | |<====== XXX Bob excluded from mix XXX ====>| 1713 | | | | | 1714 | | (a) Update +---| | 1715 | | Bob in | | | 1716 | | Data Model | | | 1717 | | (muted) +-->| | 1718 | | | | | 1719 | (2)userResponse(confUserID,confObjID, | | 1720 | update,success,version) | | 1721 |<---------------------------------------| | 1722 | | | | | 1723 | | | (b) Notify | | 1724 | | | ("Bob is | | 1725 | | | muted") | | 1726 | | |<-----------| | 1727 | | | | | 1728 ' ' ' ' ' 1729 ' ' ' ' ' 1730 ' ' ' ' ' 1732 Figure 15: Client Manipulation of Conference - Mute a party 1734 1. Alice sends a userRequest message with an "update" operation and 1735 the userInfo with the "status" field in the "media" element for 1736 Bob's set to "revconly". In order to authenticate 1737 herself, Alice provides in the "subject" request parameter her 1738 registration credentials (i.e. username and password). The 1739 "subject" parameter is an optional one: its use can be systematic 1740 whenever the conferencing server envisages to authenticate each 1741 requestor. In such cases, if the client does not provide the 1742 required authentication information, the conferencing server 1743 answers with a CCMP "authenticationRequired" response message, 1744 indicating that the request cannot be processed without including 1745 the proper "subject" parameter. The Conference Server ensures 1746 that Alice has the appropriate authority based on the policies 1747 associated with that specific conference object to perform the 1748 operation. It recognizes that Alice is allowed to request the 1749 specified modification, since she is moderator of the target 1750 conference, and updates the "userInfo" in the conference object 1751 reflecting that Bob's media is not to be mixed with the 1752 conference media. In case the Conference Server relies on a 1753 remote Media Server for its multimedia functionality, it 1754 subsequently changes Bob's media profile accordingly by means of 1755 the related protocol interaction with the MS to enforce the 1756 decision. An example describing a possible way of dealing with 1757 such a situation using the Media Server Control architecture is 1758 described in [I-D.ietf-mediactrl-call-flows], at "Simple 1759 Bridging: Framework Transactions (2)". 1761 2. A userResponse message with a response-code of "success" is then 1762 sent to Alice. Depending upon the policies, the conference 1763 server may notify other participants (including Bob) of this 1764 update via any Conference Notification Service that may be in 1765 use. 1767 1. userRequest/update message (Alice mutes Bob) 1769 1770 1773 1775 1776 Alice83 1777 13011983 1778 1779 xcon-userid:Alice@example.com 1780 xcon:8977878@example.com 1781 update 1782 1783 1784 1785 1786 123 1787 recvonly 1788 1789 1790 1791 1792 1793 1795 2. userResponse/update message ("success") 1797 1798 1801 1803 xcon-userid:Alice@example.com 1804 xcon:8977878@example.com 1805 update 1806 success 1807 7 1808 1809 1810 1812 Figure 16: Mute Message Details 1814 6.3. Conference Announcements and Recordings 1816 This section deals with features that are typically required in a 1817 conferencing system, that are public announcements (e.g. to notify 1818 vocally that a new user joined a conference) and name recording. 1819 While this is not strictly CCMP-related (the CCMP signaling is 1820 actually the same as the one seen in Section 6.1) it is an 1821 interesting scenario to address to see how the several components of 1822 an XCON-compliant architecture interact with each other to make it 1823 happen. 1825 In this example, as shown in Figure 17 Alice is joining Bob's 1826 conference that requires that she first enters a pass code. After 1827 successfully entering the pass code, an announcement prompts Alice to 1828 speak her name so it can be recorded. When Alice is added to the 1829 active conference, the recording is played back to all the existing 1830 participants. A very similar example is presented in Figure 33 of 1831 [I-D.ietf-mediactrl-call-flows]. 1833 CMCC "Alice" ConfS MS 1834 | | | 1835 |(1)userRequest(confObjID, | | 1836 | create,userInfo) | | 1837 |--------------------------->| | 1838 | |--+ Alice is | 1839 | | | new in the | 1840 | |<-+ system (create | 1841 | | confUserID) | 1842 | ConfS handles +--| | 1843 | SIP signaling | | | 1844 | (Alice<->ConfS<->MS) +->| | 1845 | | | 1846 | |--+ A password is | 1847 | | | required for | 1848 | |<-+ that conference | 1849 | | | 1850 | | Request IVR menu (PIN) | 1851 | |--------------------------->| 1852 | | | 1853 |<========= MS gets PIN from Alice through DTMF =========>| 1854 | | | 1855 | | Provided PIN is... | 1856 | |<---------------------------| 1857 | Check +--| | 1858 | PIN | | | 1859 | +->| | 1860 | |--+ Alice must | 1861 | | | record her | 1862 | |<-+ name | 1863 | | | 1864 | | Request name recording | 1865 | |--------------------------->| 1866 | | | 1867 |<========= MS records Alice's audio RTP (name) =========>| 1868 | | | 1869 | | Audio recording | 1870 | |<---------------------------| 1871 | Complete +--| | 1872 | creation | | | 1873 | of Alice +->| | 1874 | | | 1875 | | | 1876 | (2)userResponse(confUserID,| | 1877 | confObjID, create, | | 1878 | success, version) | | 1879 |<---------------------------| | 1880 | | | 1881 Figure 17: Recording and Announcements 1883 1. Upon receipt of the userRequest from Alice to be added to Bob's 1884 conference, the conferencing system determines that a password is 1885 required for this specific conference. Thus an announcement 1886 asking Alice to enter the password is sent back. This may be 1887 achieved by means of typical IVR functionality. Once Alice 1888 enters the password, it is validated against the policies 1889 associated with Bob's active conference. The conferencing system 1890 then connects to a server which prompts and records Alice's name. 1891 The conferencing system must also determine whether Alice is 1892 already a user of this conferencing system or whether she is a 1893 new user. In this case, Alice is a new user for this 1894 conferencing system, so a Conference User Identifier (i. e. an 1895 XCON-USERID) is created for Alice. Based upon the contact 1896 information provided by Alice, the call signaling to add Alice to 1897 the conference is instigated through the Focus. 1899 2. The conference server sends Alice a userResponse message which 1900 includes the "confUserID" assigned by the conferencing system to 1901 her. This would allow Alice to later perform operations on the 1902 conference (if she were to have the appropriate policies), 1903 including registering for event notifications associated with the 1904 conference. Once the call signaling indicates that Alice has 1905 been successfully added to the specific conference, per updates 1906 to the state, and depending upon the policies, other participants 1907 (e.g., Bob) are notified of the addition of Alice to the 1908 conference via the conference notification service and an 1909 announcement is provided to all the participants indicating that 1910 Alice has joined the conference. 1912 1. userRequest/create message (Alice - a new conferencing system 1913 client - enters Bob's conference) 1915 1916 1920 1922 xcon:bobConf@example.com 1923 create 1924 1925 1926 1927 1928 1929 mailto:Alice83@example.com 1930 1931 email 1932 1933 1934 1935 1936 1937 1938 1940 2.userResponse/create ("success": Alice is provided with a new 1941 xcon-userid and is added to the conference) 1943 1944 1948 1950 xcon-userid:Alice@example.com 1951 xcon:bobConf@example.com 1952 create 1953 success 1954 5 1955 1956 1957 1958 Figure 18: Announcement Messaging Details 1960 6.4. Monitoring for DTMF 1962 Conferencing systems often also need the capability to monitor for 1963 DTMF from each individual participant. This would typically be used 1964 to enter the identifier and/or access code for joining a specific 1965 conference. This feature is often also exploited to achieve 1966 interaction between participants and the conference system for non- 1967 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted). 1969 An example of DTMF monitoring, within the context of the framework 1970 elements, is shown in Figure 17. A typical way for the conferencing 1971 system to be aware of all the DTMF interactions within the context of 1972 conferences it is responsible for, is making use of the MEDIACTRL 1973 architecture for what regards media manipulation. Examples in that 1974 sense (specifically for what concerns DTMF interception in conference 1975 instances) are presented in [I-D.ietf-mediactrl-call-flows]. 1977 6.5. Entering a password-protected conference 1979 Some conferences may envision a password to be provided by a user who 1980 wants to manipulate the relative conference objects (e.g. join, 1981 update, delete) via CCMP. Such a password would be included in the 1982 element related to the conference XCON-URI in 1983 the appropriate entry and must be then included in 1984 the apposite "conference-password" field in the CCMP request 1985 addressed to that conference. 1987 In the following CCMP transactions, it is depicted a scenario in 1988 which Alice, a conferencing system client, attempts to join a 1989 password-protected conference. 1991 1. Alice sends a userRequest message with a "create" operation to 1992 add herself in the conference with XCON-URI 1993 "xcon:8977777@example.com" (written in the "confObjID" 1994 parameter). Alice provides her XCON-USERID via the "confUserID" 1995 field of the userRequest and leaves out the "userInfo" one 1996 (first-party join). In this first attempt, she doesn't insert 1997 any password parameter. 1999 2. Upon receipt the userRequest/create message, the conferencing 2000 server detects that the indicated conference is not joinable 2001 without providing the relative pass code. Then a userResponse 2002 message with "confPasswordRequired" response-code is returned to 2003 Alice to indicate that her join has been refused and that she has 2004 to recast her request including the appropriate conference 2005 password in order to participate. 2007 3. After getting the pass code through out-of-band mechanisms, Alice 2008 provides it in the proper "password" request field of a new 2009 userRequest/create message and sends the updated request back to 2010 the server. 2012 4. The conferencing server checks the provided password and then 2013 adds Alice to the protected conference. After that, a 2014 userResponse with a "success" response-code is sent to Alice. 2016 1. userRequest/create message (Alice tries to enter the conference 2017 without providing the password) 2019 2020 2024 2026 xcon-userid:Alice@example.com 2027 xcon:8977794@example.com 2028 create 2029 2030 2031 2033 2. userResponse/create message ("passwordRequired") 2035 2036 2040 2042 xcon-userid:Alice@example.com 2043 xcon:8977794@example.com 2044 create 2045 confPasswordRequired 2046 2047 2048 2050 3. userRequest/create message (Alice provides the password) 2051 2052 2056 2058 xcon-userid:Alice@example.com 2059 xcon:8977794@example.com 2060 create 2061 8601 2062 2063 2064 2066 4. userResponse/create message ("success") 2068 2069 2073 2075 xcon-userid:Alice@example.com 2076 xcon:8977794@example.com 2077 create 2078 success 2079 10 2080 2081 2082 2084 Figure 19: Password-protected conference join messages details 2086 7. Sidebars Scenarios and Examples 2088 While creating conferences and manipulating users and their media may 2089 be considered enough for many scenarios, there may be cases when a 2090 more complex management is needed. 2092 In fact, a feature typically required in conferencing systems is the 2093 ability to create sidebars. A sidebar is basically a child 2094 conference that usually includes a subset of the participants of the 2095 parent conference, and a subset of its media as well. Sidebars are 2096 typically required whenever some of the participants in a conference 2097 want to discuss privately about something, without interfering with 2098 the main conference. 2100 This section deals with some scenarios that typically envisage the 2101 use of a sidebar, like whispering, private messages and coaching 2102 scenarios. The first subsections, anyway, present some examples of 2103 how a generic sidebar can be created, configured and managed. 2105 7.1. Internal Sidebar 2107 Figure 20 provides an example of one client, "Alice", involved in an 2108 active conference with "Bob" and "Carol". Alice wants to create a 2109 sidebar to have a side discussion with Bob while still viewing the 2110 video associated with the main conference. Alternatively, the audio 2111 from the main conference could be maintained at a reduced volume. 2112 Alice initiates the sidebar by sending a request to the conferencing 2113 system to create a conference reservation based upon the active 2114 conference object. Alice and Bob would remain on the roster of the 2115 main conference, such that other participants could be aware of their 2116 participation in the main conference, while an internal-sidebar 2117 conference is occurring. Besides, Bob decides that he is not 2118 interested in still receiving the conference audio in background (not 2119 even at a lower volume as Alice configured) and so modifies the 2120 sidebar in order to make that stream inactive for him. 2122 Alice Bob ConfS 2123 | | | 2124 |(1) sidebarByValRequest(confUserID, | 2125 | confObjID,create) | 2126 |--------------------------------------------->| 2127 | | | 2128 | | (a) Create +---| 2129 | | sidebar-by-val | | 2130 | | (new conf obj | | 2131 | | cloned from +-->| 2132 | | confObjID) | Sidebar now has 2133 | | | id confObjID* 2134 |(2) sidebarByValResponse(confUserID, | (parent mapping 2135 | (confObjID*, create, success, | conf<->sidebar) 2136 | version, sidebarByValInfo) | 2137 |<---------------------------------------------| 2138 | | | 2139 |(3) sidebarByValRequest | 2140 | (confUserID, confObjID*, | 2141 | update,sidebarByValInfo) | 2142 |--------------------------------------------->| 2143 | | | 2144 | | (b) Update +---| 2145 | | sidebar-by-val | | 2146 | | (media, users | | 2147 | | etc.) +-->| 2148 | | | Sidebar is 2149 | | | modified 2150 |(4) sidebarByValResponse(confUserID, | 2151 | confObjID*, update, | 2152 | success, version) | 2153 |<---------------------------------------------| 2154 | | | 2155 | |(5) userRequest | 2156 | | (confUserID', | 2157 | | confObjID*, | 2158 | | update,userInfo)| 2159 | |---------------------->| 2160 | | | 2161 | | (c) Update +---| 2162 | | user settings | | 2163 | | (Bob's media) | | 2164 | | +-->| 2165 | | | Sidebar is modified 2166 | | | (original audio 2167 | | | inactive for Bob) 2168 | |(6) userResponse | 2169 | | (confUserID', | 2170 | | confObjID*,update| 2171 | | success,version) | 2172 | |<----------------------| 2173 | | | 2174 " " " 2175 " " " 2176 " " " 2178 Figure 20: Client Creation of a Sidebar Conference 2180 1. Upon receipt of CCMP sidebarByValRequest message to create a new 2181 sidebar-conference based upon the confObjID received in the 2182 request, the conferencing system uses the confObjID to clone a 2183 conference reservation for the sidebar. The sidebar reservation 2184 is NOT independent of the active conference (i.e., parent). The 2185 conferencing system also allocates a new XCON-URI for that 2186 sidebar to be used for any subsequent protocol requests from any 2187 of the members of the conference. The new sidebar identifier 2188 ("confObjID*" in Figure 20) is returned in the response message 2189 confObjID parameter. 2191 2. The relationship information is provided in the 2192 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the 2194 main/parent conference is provided below as well to show how the 2195 cloning process for the creation of the sidebar could take place. 2197 3. Upon receipt of the sidebarByValResponse message to reserve the 2198 conference, Alice can now create an active conference using that 2199 reservation, or create additional reservations based upon the 2200 existing reservations. In this example, Alice wants only Bob to 2201 be involved in the sidebar, thus she manipulates the membership 2202 so that only the two of them appear in the 2203 section. Alice also wants both audio and video from the original 2204 conference to be available in the sidebar. For what concerns the 2205 media belonging to the sidebar itself, Alice wants the audio to 2206 be restricted to the participants in the sidebar (that is, Bob 2207 and herself). Additionally, Alice manipulates the media values 2208 to receive the audio from the main conference at a reduced 2209 volume, so that the communication between her and Bob isn't 2210 affected. Alice sends a sidebarByValRequest message with an 2211 operation of "update" along with the "sidebarByValInfo" 2212 containing the aforementioned sidebar modifications. 2214 4. Upon receipt of the sidebarByValRequest to update the sidebar 2215 reservation, the conference server ensures that Alice has the 2216 appropriate authority based on the policies associated with that 2217 specific conference object to perform the operation. The 2218 conference server must also validate the updated information in 2219 the reservation, ensuring that a member like Bob is already a 2220 user of this conference server. Once the data for the confObjID 2221 is updated, the conference server sends a sidebarByValResponse to 2222 Alice. Depending upon the policies, the initiator of the request 2223 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may 2224 be notified of his addition to the sidebar via the conference 2225 notification service. 2227 5. At this point, Bob sends a userRequest message to the conference 2228 server with an operation of "update" to completely disable the 2229 background audio from the parent conference, since it prevents 2230 him from understanding what Alice says in the sidebar. 2232 6. Notice that Bob's request only changes the media perspective for 2233 Bob. Alice keeps on receiving both the audio from Bob and the 2234 background from the parent conference. This request may be 2235 relayed by the conference server to the Media Server handling the 2236 mixing, if present. Upon completion of the change, the 2237 conference server sends a "userResponse" message to Bob. 2238 Depending upon the policies, the initiator of the request (i.e., 2239 Bob) and the participants in the sidebar (i.e., Alice) may be 2240 notified of this change via the conference notification service. 2242 That said, let's consider the following conference object: 2244 2245 2250 2251 MAIN CONFERENCE 2252 2253 2254 sip:8977878@example.com 2255 conference sip uri 2256 2257 2258 2259 2260 main conference audio 2261 audio 2262 sendrecv 2263 2264 2265 main conference video 2266 video 2267 sendrecv 2268 2269 single-view 2270 2271 2272 2273 2274 2275 true 2276 2277 2278 2279 Alice 2280 2281 2282 123 2283 sendrecv 2284 2285 2286 456 2287 sendrecv 2288 2289 2290 2291 2292 Bob 2293 2294 2295 123 2296 sendrecv 2297 2298 2299 456 2300 sendrecv 2301 2302 2303 2304 2305 Carol 2306 2307 2308 123 2309 sendrecv 2310 2311 2312 456 2313 sendrecv 2314 2315 2316 2317 2318 2320 Figure 21: Conference with Alice, Bob and Carol 2322 This is the representation of the conference the sidebar is going to 2323 be created in. As such, it will be used by the conferencing system 2324 in order to create the new conference object associated with the 2325 sidebar. In fact, the sidebar creation happens through a cloning of 2326 the parent conference. Once the sidebar is created, an "update" 2327 makes sure that the sidebar is customized as needed. The following 2328 protocol dump makes the process clearer. 2330 1. sidebarByValRequest/create message (Alice creates an 2331 internal sidebar) 2333 2334 2337 2339 xcon-userid:Alice@example.com 2340 xcon:8977878@example.com 2341 create 2342 2343 2344 2346 2. sidebarByValResponse/create message ("success", sidebar returned) 2348 2349 2353 2355 xcon-userid:Alice@example.com 2356 xcon:8974545@example.com 2357 create 2358 success 2359 1 2360 2361 2362 2363 2364 SIDEBAR CONFERENCE registered by Alice 2365 2366 2367 xcon:8977878@example.com 2368 2369 2370 2371 2372 main conference audio 2373 2374 audio 2375 sendrecv 2376 2377 2378 2379 main conference video 2380 2381 video 2382 sendrecv 2383 2384 2385 2386 2387 false 2388 2389 2390 2391 2393 2395 2397 2398 2399 2400 2401 2402 2404 3. sidebarByValRequest/update message (Alice updates the 2405 created sidebar) 2407 2408 2412 2414 xcon-userid:Alice@example.com 2415 xcon:8974545@example.com 2416 update 2417 2418 2419 2420 2421 private sidebar Alice - Bob 2422 2423 2424 2425 2426 main conference audio 2427 2428 audio 2429 recvonly 2430 2431 -60 2432 2433 2434 2435 2436 main conference video 2437 2438 video 2439 recvonly 2440 2441 2442 2443 sidebar audio 2444 2445 audio 2446 sendrecv 2447 2448 2449 2450 sidebar video 2451 2452 video 2453 sendrecv 2454 2455 2456 2457 2458 2459 2461 2463 2464 2465 2466 2467 2468 2470 4. sidebarByValResponse/update message ("success", sidebar's 2471 updates accepted) 2473 2474 2478 2480 xcon-userid:Alice@example.com 2481 xcon:8974545@example.com 2482 update 2483 success 2484 2 2485 2486 2487 2489 5. userRequest/update message (Bob updates his media) 2491 2492 2496 2498 xcon-userid:Bob@example.com 2499 xcon:8974545@example.com 2500 update 2501 2502 2503 2504 2505 2506 main conference audio 2507 2508 123 2509 inactive 2510 2511 2512 2513 2514 2515 2516 6. userResponse/update message ("success", Bob's preferences setted) 2518 2519 2522 2524 xcon-userid:Bob@example.com 2525 xcon:8974545@example.com 2526 update 2527 success 2528 3 2529 2530 2531 2533 Figure 22: Internal Sidebar Messaging Details 2535 7.2. External Sidebar 2537 Figure 23 provides an example of a different approach towards 2538 sidebar. In this scenario, one client, "Alice", is involved in an 2539 active conference with "Bob", "Carol", "David" and "Ethel". Alice 2540 gets an important text message via a whisper from Bob that a critical 2541 customer needs to talk to Alice, Bob and Ethel. Alice creates a 2542 sidebar to have a side discussion with the customer "Fred" including 2543 the participants in the current conference with the exception of 2544 Carol and David, who remain in the active conference. The difference 2545 from the previous scenario is that Fred is not part of the parent 2546 conference: this means that different policies might be involved, 2547 considering that Fred may access information coming from the parent 2548 conference, in case the sidebar was configured accordingly. For this 2549 reason, in this scenario we assume that Alice disables all the media 2550 from the original (parent) conference within the sidebar. This means 2551 that, while in the previous example Alice and Bob still heard the 2552 audio from the main conference in background, this time no background 2553 is made available. Alice initiates the sidebar by sending a request 2554 to the conferencing system to create a conference reservation based 2555 upon the active conference object. Alice, Bob and Ethel would remain 2556 on the roster of the main conference in a hold state. Whether or not 2557 the hold state of these participants is visible to other participants 2558 depends upon the individual and local policy. 2560 Alice Bob ConfS 2561 | | | 2562 |(1) sidebarByRefRequest(confUserID, | 2563 | confObjID, create) | 2564 |--------------------------------------------->| 2565 | | | 2566 | | (a) Create +---| 2567 | | sidebar-by-ref | | 2568 | | (new conf obj | | 2569 | | cloned from +-->| 2570 | | confObjID) | Sidebar now has 2571 | | | id confObjID* 2572 |(2) sidebarByRefResponse(confUserID, | (parent mapping 2573 | confObjID*, create, success, | conf<->sidebar) 2574 | version, sidebarByRefInfo) | 2575 |<---------------------------------------------| 2576 | | | 2577 |(3) sidebarByRefRequest(confUserID, | 2578 | confObjID*,update,sidebarByRefInfo) | 2579 |--------------------------------------------->| 2580 | | | 2581 | | (b) Create +---| 2582 | | new user for | | 2583 | | Fred | | 2584 | | +-->| 2585 | | | 2586 | | (c) Update +---| 2587 | | sidebar-by-ref | | 2588 | | (media, users | | 2589 | | policy, etc.) +-->| 2590 | | | Sidebar is modified: 2591 | | | no media from the 2592 | | | parent conference is 2593 | | | available to anyone 2594 |(4) sidebarByRefResponse(confUserID, | 2595 | confObjID*, update, | 2596 | success, version) | 2597 |<---------------------------------------------| 2598 | | | 2599 | | Notify (Fred | 2600 | | added to | 2601 | | sidebar users) | 2602 | |<----------------------| 2603 | | | 2604 " " " 2605 " " " 2606 " " " 2607 Figure 23: Client Creation of an External Sidebar 2609 1. Upon receipt of the "sidebarByRefRequest" message to create a new 2610 sidebar conference, based upon the active conference specified by 2611 "confObjID" in the request, the conferencing system uses that 2612 active conference to clone a conference reservation for the 2613 sidebar. The sidebar reservation is NOT independent of the 2614 active conference (i.e., parent). The conferencing system, as 2615 before, allocates a conference ID (confObjID*) to be used for any 2616 subsequent protocol requests toward the sidebar reservation. The 2617 mapping between the sidebar conference ID and the one associated 2618 with the main conference is mantained by the conferencing system 2619 and it is gathered from the c element in the 2620 sidebar conference object. 2622 2. Upon receipt of the "sidebarByRefResponse" message, which 2623 acknowledges the successful creation of the sidebar object, Alice 2624 decides that only Bob and Ethel, along with the new participant 2625 Fred are to be involved in the sidebar. Thus she manipulates the 2626 membership accordingly. Alice also sets the media in the 2627 "conference-info" such that the participants in the sidebar don't 2628 receive any media from the main conference. All these settings 2629 are provided to the conferencing system by means of a new 2630 "sidebarByRefRequest" message, with an "update" operation. 2632 3. Alice sends the aforementioned "sidebarByRefRequest" to update 2633 the information in the reservation and to create an active 2634 conference. Upon receipt of the "sidebarByRefRequest" with an 2635 operation of "update", the conferencing system ensures that Alice 2636 has the appropriate authority based on the policies associated 2637 with that specific conference object to perform the operation. 2638 The conferencing system also validates the updated information in 2639 the reservation. Since Fred is a new user for this conferencing 2640 system, a conference user identifier is created for Fred. 2641 Specifically, Fred is added to the conference by only providing 2642 his SIP URI. Based upon the contact information provided for 2643 Fred by Alice, the call signaling to add Fred to the conference 2644 may be instigated through the Focus (e.g. if Fred had a "dial- 2645 out" method set as the target for him) at the actual activation 2646 of the sidebar. 2648 4. The conference server sends a "sidebarByRefResponse" message and, 2649 depending upon the policies, the initiator of the request (i.e., 2650 Alice) and the participants in the sidebar (i.e., Bob and Ethel) 2651 may be notified of his addition to the sidebar via the conference 2652 notification service. 2654 1. sidebarByRefRequest/create message (Alice creates an 2655 external sidebar) 2657 2658 2661 2663 xcon-userid:Alice@example.com 2664 xcon:8977878@example.com 2665 create 2666 2667 2668 2670 2. sidebarByRefResponse/create message ("success", created 2671 sidebar returned) 2673 2674 2678 2680 xcon-userid:Alice@example.com 2681 xcon:8971212@example.com 2682 create 2683 success 2684 1 2685 2686 2687 2688 2689 SIDEBAR CONFERENCE registered by Alice 2690 2691 2692 xcon:8977878@example.com 2693 2694 2695 2696 2697 main conference audio 2698 2699 audio 2700 sendrecv 2701 2702 2703 2704 main conference video 2705 2706 video 2707 sendrecv 2708 2709 2710 2711 2712 false 2713 2714 2715 2716 2718 2720 2722 2724 2726 2727 2728 2729 2730 2731 2733 3. sidebarByRefRequest/update message (Alice updates the sidebar) 2735 2739 2741 xcon-userid:Alice@example.com 2742 xcon:8971212@example.com 2743 update 2744 2745 2746 2747 2748 sidebar with Alice, Bob, Ethel & Fred 2749 2750 2751 2752 2753 main conference audio 2754 2755 audio 2756 inactive 2757 2758 2759 2760 main conference video 2761 2762 video 2763 inactive 2764 2765 2766 2767 sidebar audio 2768 2769 audio 2770 sendrecv 2771 2772 2773 2774 sidebar video 2775 2776 video 2777 sendrecv 2778 2779 2780 single-view 2781 2782 2783 2784 2785 2786 2787 false 2788 2789 2790 2791 2793 2796 2798 2799 2800 2801 2802 2803 2805 4. sidebarByRefResponse/update message ("success", sidebar updated) 2807 2811 2813 xcon-userid:Alice@example.com 2814 xcon:8971212@example.com 2815 update 2816 success 2817 2 2818 2819 2820 2822 Figure 24: External Sidebar Messaging Details 2824 7.3. Private Messages 2826 The case of private messages can be handled as a sidebar with just 2827 two participants, similarly to the example in Section 7.1. Unlike 2828 the previous example, rather than using audio within the sidebar, 2829 Alice could just add an additional text based media stream to the 2830 sidebar in order to convey her textual messages to Bob, while still 2831 viewing and listening to the main conference. 2833 In this scenario, Alice requests to the conferencing system the 2834 creation of a private chat room within the main conference context 2835 (presented in Figure 21) in which the involved partecipants are just 2836 Bob and herself. This can be achieved through the following CCMP 2837 transaction (Figure 25). 2839 1. Alice forwards a sidebarByValRequest/create to the Conferencing 2840 Control Server with the main conference XCON-URI in the 2841 "confObjID" parameter and the desired sidebar conference object 2842 in the "sidebarByValInfo" field. In this way, a sidebar creation 2843 using user-provided conference information is requested to the 2844 conferencing system. Please note that, unlike the previous 2845 sidebar examples, in this case a comnpletely new conference 2846 object to describe the sidebar is provided: there is no cloning 2847 involved, while the "confObjID" still enforces the parent-child 2848 relationship between the main conference and the to-be-created 2849 sidebar. 2851 2. The Conference Control Server, after checking Alice's rights and 2852 validating the conference-object carried in the request, creates 2853 the required sidebar-by-val conference and a new XCON-URI for it. 2854 Instead of cloning the main conference object, as envisioned in 2855 Section 7.1 and Section 7.2, the sidebar is created on the basis 2856 of the user provided conference information (as anticipated 2857 before). However, the parent relationship between the main 2858 conference and the newly created sidebar is still mantained by 2859 the conferencing system (as a consequence of the chosen CCMP 2860 request message type - the sidebarByVal one) and it is reflected 2861 by the element in the "sidebarByValInfo" element 2862 returned in the sidebarByValResponse message. Please notice 2863 that, according to the CCMP specification, the return of the 2864 created sidebar data in this kind of "success" response is not 2865 mandatory. 2867 1. sidebarByValRequest/create message (Alice creates a private 2868 chat room between Bob and herself) 2870 2871 2875 2877 xcon-userid:Alice@example.com 2878 xcon:8977878@example.com 2879 create 2880 2881 2882 2883 2884 private textual sidebar alice - bob 2885 2886 2887 2888 2889 main conference audio 2890 2891 audio 2892 recvonly 2893 2894 2895 2896 main conference video 2897 2898 video 2899 recvonly 2900 2901 2902 2903 sidebar text 2904 2905 text 2906 sendrecv 2907 2908 2909 2910 2911 2912 2914 2916 2917 2918 2919 2920 2921 2923 2. sidebarByValResponse/create message ("success", sidebar returned) 2925 2926 2930 2932 xcon-userid:Alice@example.com 2933 xcon:8974545@example.com 2934 create 2935 success 2936 1 2937 2938 2939 2940 2941 private textual sidebar alice - bob 2942 2943 2944 xcon:8977878@example.com 2945 2946 2947 2948 2949 main conference audio 2950 2951 audio 2952 recvonly 2953 2954 2955 2956 main conference video 2957 2958 video 2959 recvonly 2960 2961 2962 2963 sidebar text 2964 2965 text 2966 sendrecv 2967 2968 2969 2970 2971 2972 2974 2976 2977 2978 2979 2980 2981 2982 Figure 25: Sidebar for Private Messages scenario 2984 7.4. Observing and Coaching 2986 Observing and Coaching is one of the most interesting sidebars- 2987 related scenarios. In fact, it envisages two different interactions 2988 that have to be properly coordinated. 2990 An example of observing and coaching is shown in figure Figure 27. 2991 In this example, call center agent Bob is involved in a conference 2992 with customer Carol. Since Bob is a new agent and Alice sees that he 2993 has been on the call with Carol for longer than normal, she decides 2994 to observe the call and coach Bob as necessary. Of course the 2995 conferencing system must make sure that the customer Carol is not 2996 aware of the presence of the coach Alice. This makes the use of a 2997 sidebar necessary for the success of the scenario. 2999 Consider the following as the conference document associated with the 3000 video conference involving Bob (the call agent) and Carol (the 3001 customer) (Figure 26): 3003 3004 3009 3010 3011 CUSTOMER SERVICE conference 3012 3013 3014 3015 sip:8978383@example.com 3016 conference sip uri 3017 3018 3019 3020 3021 service audio 3022 audio 3023 sendrecv 3024 3025 3026 service video 3027 video 3028 sendrecv 3029 3030 single-view 3031 3032 3033 3034 3035 3036 true 3037 3038 3039 3040 Bob - call agent 3041 3042 3043 123 3044 sendrecv 3045 3046 3047 456 3048 sendrecv 3049 3050 3051 3052 3053 Carol - customer 3054 3055 3056 123 3057 sendrecv 3058 3059 3060 456 3061 sendrecv 3062 3063 3064 3065 3066 3068 Figure 26: A call-center conference object example 3070 Alice Bob ConfS 3071 | | | 3072 |(1) sidebarByRefRequest(confUserID, | 3073 | confObjID, create) | 3074 |--------------------------------------------->| 3075 | | | 3076 | | (a) Create +---| 3077 | | sidebar-by-ref | | 3078 | | (new conf obj | | 3079 | | cloned from +-->| 3080 | | confObjID) | Sidebar now has 3081 | | | id confObjID* 3082 |(2) sidebarByRefResponse(confUserID, | (parent mapping 3083 | confObjID*, create, success, | conf<->sidebar) 3084 | version, sidebarByRefInfo) | 3085 |<---------------------------------------------| 3086 | | | 3087 |(3) sidebarByRefRequest(confUserID, | 3088 | confObjID*,update,sidebarByRefInfo) | 3089 |--------------------------------------------->| 3090 | | | 3091 | | (b) Update +---| 3092 | | sidebar-by-val | | 3093 | | (media, users | | 3094 | | policy, etc.) +-->| 3095 | | | Sidebar is modified: 3096 | | | unilateral sidebar 3097 | | | audio, Carol excluded 3098 | | | from the sidebar 3099 |(4) sidebarByRefResponse(confUserID, | 3100 | confObjID*, update, | 3101 | success, version) | 3102 |<---------------------------------------------| 3103 | | | 3104 | | Notify (Bob | 3105 | | he's been added to | 3106 | | sidebar users) | 3107 | |<----------------------| 3108 | | | 3109 " " " 3110 " " " 3111 " " " 3113 Figure 27: Supervisor Creating a Sidebar for Observing/Coaching 3115 1. Upon receipt of the sidbarByRefRequest/create from Alice to 3116 "create" a new sidebar conference from the confObjID received in 3117 the request, the conferencing system uses the received active 3118 conference to clone a conference reservation for the sidebar. 3119 The conferencing system also allocates a conference ID to be used 3120 for any subsequent protocol requests from any of the members of 3121 the conference. The conferencing system maintains the mapping 3122 between this conference ID and the confObjID associated with the 3123 sidebar reservation through the conference instance. The 3124 conference server sends a sidebarByRefResponse message with the 3125 new confObjID and relevant sidebarByRefInfo. 3127 2. Upon receipt of the sidebarByRefResponse message, Alice 3128 manipulates the data received in the sidebarByRefInfo in the 3129 response. Alice wants only Bob to be involved in the sidebar, 3130 thus she updates the to include only Bob and 3131 herself. Alice also wants the audio to be received by herself 3132 and Bob from the original conference, but wants any outgoing 3133 audio from herself to be restricted to the participants in the 3134 sidebar, whereas Bob's outgoing audio should go to the main 3135 conference, so that both Alice and the customer Carol hear the 3136 same audio from Bob. Alice sends a sidebarByRefRequest message 3137 with an "update" operation including the updated sidebar 3138 information. 3140 3. Upon receipt of the sidebarByRefRequest message with an "update" 3141 operation, the conferencing system ensures that Alice has the 3142 appropriate authority based on the policies associated with that 3143 specific conference object to perform the operation. In order to 3144 request the insertion of a further media stream in the sidebar 3145 (i.e. in this example an audio stream from Alice to Bob), the 3146 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label" 3148 attribute of that new entry is filled with a dummy value 3149 "AUTO_GENERATE_1", but it will contain the real server-generated 3150 media stream identifier when the media stream is effectively 3151 allocated on the server side. Similarly, the mandatory "id" 3152 attribute in element referring to the new sidebar audio 3153 stream under both Alice's and Bob's contains a 3154 wildcard value, respectively "AUTO_GENERATED_2" and 3155 "AUTO_GENERATED_3": those values will be replaced with the 3156 appropriated server-generated identifiers upon the creation of 3157 the referred media stream. We are assuming the conferencing 3158 control server is able to recognize those dummy values as place- 3159 holders. 3161 4. After validating the data, the conference server sends a 3162 sidebarByRefResponse message. Based upon the contact information 3163 provided for Bob by Alice, the call signaling to add Bob to the 3164 sidebar with the appropriate media characteristics is instigated 3165 through the Focus. Bob is notified of his addition to the 3166 sidebar via the conference notification service, thus he is aware 3167 that Alice, the supervisor, is available for coaching him through 3168 this call. 3170 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar) 3172 3173 3176 3178 xcon-userid:Alice@example.com 3179 xcon:8978383@example.com 3180 create 3181 3182 3183 3185 2. sidebarByRefResponse/create message ("success") 3187 3188 3192 3194 xcon-userid:alice@example.com 3195 xcon:8971313@example.com 3196 create 3197 success 3198 1 3199 3200 3201 3202 3203 SIDEBAR CONFERENCE registered by alice 3204 3205 3206 xcon:8971313@example.com 3207 3208 3209 3210 3211 main conference audio 3212 3213 audio 3214 sendrecv 3215 3216 3217 3218 main conference video 3219 3220 video 3221 sendrecv 3222 3223 3224 3225 3226 false 3227 3228 3229 3230 3232 3234 3236 3237 3238 3239 3240 3241 3243 3. sidebarByRefRequest/update message (Alice introduces unilateral 3244 sidebar audio and excludes Carol from the sidebar) 3246 3250 3252 xcon-userid:alice@example.com 3253 xcon:8971313@example.com 3254 update 3255 3256 3257 3258 3259 Coaching sidebar Alice and Bob 3260 3261 3262 3263 3264 Alice-to-Bob audio 3265 3266 audio 3267 sendrecv 3268 3269 3270 3271 3272 false 3273 3274 3275 3276 3278 3280 3281 3283 3284 AUTO_GENERATE_1 3285 sendonly 3286 3287 3288 3289 3291 3292 AUTO_GENERATE_1 3293 recvonly 3294 3295 3296 3297 3298 3299 3300 3301 3303 4. sidebarByRefRequest/update message ("success") 3304 3305 3309 3311 xcon-userid:alice@example.com 3312 xcon:8971313@example.com 3313 update 3314 success 3315 2 3316 3317 3318 3320 Figure 28: Coaching and Observing Messaging details 3322 8. Removing Participants and Deleting Conferences 3324 The following scenarios detail the basic operations associated with 3325 removing participants from conferences and entirely deleting 3326 conferences. The examples assume that a conference has already been 3327 correctly established, with media, if applicable, per one of the 3328 examples in Section 5. 3330 8.1. Removing a Party 3332 Figure 29 provides an example of a client, "Alice", removing another 3333 participant, "Bob", from a conference. This example assumes an 3334 established conference with Alice, Bob, "Claire" and "Duck". In this 3335 example, Alice wants to remove Bob from the conference so that the 3336 group can continue in the same conference without Bob's 3337 participation. 3339 Alice Bob Claire ConfS 3340 | | | | 3341 |(1) userRequest(confUserID,| | 3342 | confObjID, delete,| | 3343 | userInfo) | | 3344 |-------------------------------------->| 3345 | | | | 3346 | | | (a) Focus | 3347 | | | tears down| 3348 | | | signaling | 3349 | | | to Bob | 3350 | |<----------------------| 3351 | | | 3352 | | (b)Deletes+---| 3353 | | | Bob | | 3354 | | | as a | | 3355 | | | user +-->| 3356 | | | in | 3357 | | | confObj | 3358 | | | | 3359 |(2) userResponse(confUserID,confObjID, | 3360 | delete,success,version) | 3361 |<--------------------------------------| 3362 | | | | 3363 | | | | 3364 | | | (c) Notify| 3365 | | | ("Bob just| 3366 | | | left") | 3367 | | |<----------| 3368 | | | | 3369 ' ' ' ' 3370 ' ' ' ' 3371 ' ' ' ' 3373 Figure 29: Client Manipulation of Conference - Remove a party 3375 1. Alice sends a userRequest message, with a "delete" operation. 3376 The conference server ensures that Alice has the appropriate 3377 authority based on the policies associated with that specific 3378 conference object to perform the operation. 3380 2. Based upon the contact and media information in the conference 3381 object for Bob in the "userInfo" element, the conferencing system 3382 starts the process to remove Bob (e.g., the call signaling to 3383 remove Bob from the conference is instigated through the Focus). 3384 The conference server updates the data in the conference object, 3385 thus removing Bob from the list. After updating the 3386 data, the conference server sends a userResponse message to 3387 Alice. Depending upon the policies, other participants (e.g. 3388 "Claire") may be notified of the removal of Bob from the 3389 conference via the Conference Notification Service. 3391 1. userRequest/delete message (Alice deletes Bob): 3393 3394 3398 3400 xcon-userid:Alice@example.com 3401 xcon:8977794@example.com 3402 delete 3403 3404 3405 3406 3407 3409 2. userResponse/delete message ("success") 3411 3412 3416 3418 xcon-userid:Alice@example.com 3419 xcon:8977794@example.com 3420 delete 3421 success 3422 17 3423 3424 3425 3427 Figure 30: Removing a Participant Messaging Details 3429 8.2. Deleting a Conference 3431 In this section, an example of a successful conference deletion is 3432 provided (Figure 31). 3434 Alice ConfS 3435 | | 3436 |(1)confRequest(confUserID, | 3437 | confObjID, delete) | 3438 |------------------------------>| 3439 | (a)Delete +---| 3440 | Conf | | 3441 | Object | | 3442 | +-->| 3443 | |--+ (b) MS 3444 | | | removes related 3445 | | | mixer instances and 3446 | |<-+ their participants 3447 | | (SIP signaling as well) 3448 | | 3449 |(2)confResponse(confUserID, | 3450 | confObjID,delete, | 3451 | success) | 3452 | | 3453 |<------------------------------| 3454 | | 3456 Figure 31: Deleting a conference 3458 1. The conferencing system client "Alice" sends a confRequest 3459 message with a "delete" operation to be performed on the 3460 conference identified by the XCON-URI carried in the "confObjID" 3461 parameter. The conference server, on the basis of the 3462 "confUserID" included in the receipt request, ensures that Alice 3463 has the appropriate authority to fulfill the operation. 3465 2. After validating Alice's rights, the conferencing server 3466 instigates the process to delete the conference object, 3467 disconnetting participants and removing associated resources such 3468 as mixer instances. Then, the conference server returns a 3469 confResponse message to Alice with "success" as "response-code" 3470 and the deleted conference XCON-URI in the "confObjID" field. 3472 1. confRequest/delete message (Alice deletes a conference) 3474 3475 3479 3481 xcon-userid:Alice@example.com 3482 xcon:8977794@example.com 3483 delete 3484 3485 3486 3488 2. confResponse/delete message ("success") 3490 3491 3495 3497 xcon-userid:Alice@example.com 3498 xcon:8977794@example.com 3499 delete 3500 success 3501 3502 3503 3505 Figure 32: Deleting a Conference Messaging Details 3507 9. IANA Considerations 3509 This document has no IANA considerations. 3511 10. Security Considerations 3513 The security considerations applicable to the implementation of these 3514 call flows is documented in the XCON Framework, with additional 3515 security considerations documented in the CCMP document. Where 3516 applicable, statements with regards to the necessary security are 3517 discussed in particular flows, however, since this is only an 3518 informational document, readers are strongly recommended to carefully 3519 consider the security considerations defined in the XCON Framework 3520 and the CCMP document. 3522 11. Change Summary 3524 NOTE TO THE RFC-EDITOR: Please remove this section prior to 3525 publication as an RFC. 3527 The following are the major changes between the 02 and the 03 3528 versions of the draft: 3530 o updated the call flows in order to take into account the changes 3531 on CCMP; 3533 o added a completely new introductory section, addressing the 3534 protocol in general, the data model constraints, transport-related 3535 information, and notifications in a practical way; 3537 o reorganized the chapters, grouping user-related scenarios in an 3538 users section, and doing the same for sidebars; 3540 o added more verbose text to almost every section of the document; 3542 The following are the major changes between the 01 and the 02 3543 versions of the draft: 3545 o updated the call flows in order to take into account the new 3546 versioning mechanism of the CCMP; 3548 o clarified, per agreement in Stockholm, that cloning from a 3549 blueprint does not need a cloning-parent to be made available in 3550 the response; 3552 o clarified that BFCP and CCMP-based media control are neither in 3553 conflict nor one the wrapper of the other; they act at different 3554 levels, and when both are involved, it is required that both grant 3555 a resource before it can be used by an interested participant; 3557 o changed all the domains involved in the flows to make them 3558 compliant with [RFC2606]; 3560 o clarified that a successful creation of a new conference object 3561 may or may not contain the whole confInfo object in the response; 3562 in case it doesn't, a retrieve of the updated object can be 3563 achieved by issuing a confRequest/retrieve; 3565 o clarified that the scenario in Section 6.3 only involves CCMP in 3566 adding the user to a conference; this includes requiring the use 3567 of a password only in adding the user to the conference object; 3568 the actual request for PIN/Password when joining thw conference is 3569 handled by means of out-of-band mechanisms (in this case at the 3570 media level, with the help of the MEDIACTRL framework); 3572 o added and corrected Sidebars-related scenarios; 3574 o added flows for some previously missing scenarios: Private 3575 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a 3576 Conference; 3578 o 3580 The following are the major changes between the 00 and the 01 3581 versions of the draft: 3583 o Updates to reflect change of CCMP to HTTP transport model. 3585 The following are the major changes between the individual 01 version 3586 to the WG 00: 3588 o Updates to reflect most recent version of CCMP, including 3589 parameter names, etc. 3591 o Added protocol details to many of the examples. 3593 o Editorial: Simplifying intro, terms, etc. 3595 12. Acknowledgements 3597 The detailed content for this document is derived from the prototype 3598 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and 3599 their colleagues at the University of Napoli. 3601 13. References 3603 13.1. Normative References 3605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3606 Requirement Levels", BCP 14, RFC 2119, March 1997. 3608 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3609 Centralized Conferencing", RFC 5239, June 2008. 3611 [I-D.ietf-xcon-ccmp] 3612 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3613 "Centralized Conferencing Manipulation Protocol", 3614 draft-ietf-xcon-ccmp-06 (work in progress), February 2010. 3616 13.2. Informative References 3618 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 3619 Names", BCP 32, RFC 2606, June 1999. 3621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3622 A., Peterson, J., Sparks, R., Handley, M., and E. 3623 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3624 June 2002. 3626 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3627 (SIP) Call Control - Conferencing for User Agents", 3628 BCP 119, RFC 4579, August 2006. 3630 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 3631 RFC 4597, August 2006. 3633 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 3634 Control Protocol (BFCP)", RFC 4582, November 2006. 3636 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 3637 Initiation Protocol (SIP) Event Package for Conference 3638 State", RFC 4575, August 2006. 3640 [I-D.ietf-xcon-event-package] 3641 Camarillo, G., Srinivasan, S., Even, R., and J. 3643 Urpalainen, "Conference Event Package Data Format 3644 Extension for Centralized Conferencing (XCON)", 3645 draft-ietf-xcon-event-package-01 (work in progress), 3646 September 2008. 3648 [I-D.ietf-xcon-common-data-model] 3649 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3650 "Conference Information Data Model for Centralized 3651 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18 3652 (work in progress), February 2010. 3654 [I-D.ietf-mediactrl-call-flows] 3655 Amirante, A., Castaldi, T., Miniero, L., and S. Romano, 3656 "Media Control Channel Framework (CFW) Call Flow 3657 Examples", draft-ietf-mediactrl-call-flows-03 (work in 3658 progress), February 2010. 3660 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 3661 Server Control", RFC 5567, June 2009. 3663 [I-D.ietf-mediactrl-mixer-control-package] 3664 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 3665 Control Package for the Media Control Channel Framework", 3666 draft-ietf-mediactrl-mixer-control-package-11 (work in 3667 progress), February 2010. 3669 [I-D.boulton-xcon-session-chat] 3670 Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within 3671 a Centralized Conferencing (XCON) System", 3672 draft-boulton-xcon-session-chat-04 (work in progress), 3673 July 2009. 3675 Authors' Addresses 3677 Mary Barnes 3678 Nortel 3679 2201 Lakeside Blvd 3680 Richardson, TX 3682 Email: mary.barnes@nortel.com 3683 Lorenzo Miniero 3684 Meetecho 3685 Via Carlo Poerio 89/a 3686 Napoli 80121 3687 Italy 3689 Email: lorenzo@meetecho.com 3691 Roberta Presta 3692 University of Napoli 3693 Via Claudio 21 3694 Napoli 80125 3695 Italy 3697 Email: roberta.presta@unina.it 3699 Simon Pietro Romano 3700 University of Napoli 3701 Via Claudio 21 3702 Napoli 80125 3703 Italy 3705 Email: spromano@unina.it