idnits 2.17.1 draft-ietf-xcon-examples-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 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 (February 17, 2010) is 5183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.boulton-xcon-session-chat' is defined on line 3678, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-05 -- 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-16 == 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-10 == Outdated reference: A later version (-08) exists of draft-boulton-xcon-session-chat-04 Summary: 2 errors (**), 0 flaws (~~), 7 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: August 21, 2010 Meetecho 6 R. Presta 7 S P. Romano 8 University of Napoli 9 February 17, 2010 11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 12 draft-ietf-xcon-examples-03 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 to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 21, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Working with CCMP . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. CCMP and the Data Model . . . . . . . . . . . . . . . . . 6 69 5.2. Using HTTP as a transport . . . . . . . . . . . . . . . . 8 70 5.3. Conference Notifications . . . . . . . . . . . . . . . . . 11 71 6. Conference Creation . . . . . . . . . . . . . . . . . . . . . 15 72 6.1. Basic Conference Creation . . . . . . . . . . . . . . . . 15 73 6.2. Conference Creation using Blueprints . . . . . . . . . . . 20 74 6.3. Conference Creation using User-Provided Conference 75 Information . . . . . . . . . . . . . . . . . . . . . . . 27 76 6.4. Cloning an Existing Conference . . . . . . . . . . . . . . 32 77 7. Conference Users Scenarios and Examples . . . . . . . . . . . 35 78 7.1. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 36 79 7.2. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 39 80 7.3. Conference Announcements and Recordings . . . . . . . . . 43 81 7.4. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 47 82 7.5. Entering a password-protected conference . . . . . . . . . 47 83 8. Sidebars Scenarios and Examples . . . . . . . . . . . . . . . 49 84 8.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 50 85 8.2. External Sidebar . . . . . . . . . . . . . . . . . . . . . 59 86 8.3. Private Messages . . . . . . . . . . . . . . . . . . . . . 65 87 8.4. Observing and Coaching . . . . . . . . . . . . . . . . . . 69 88 9. Removing Participants and Deleting Conferences . . . . . . . . 76 89 9.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 76 90 9.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 79 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 93 12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 81 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 96 14.1. Normative References . . . . . . . . . . . . . . . . . . . 83 97 14.2. Informative References . . . . . . . . . . . . . . . . . . 83 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 100 1. Introduction 102 This document provides detailed call flows for the scenarios 103 documented in the Framework for Centralized Conferencing (XCON 104 Framework) [RFC5239] and the XCON Scenarios [RFC4597]. The XCON 105 scenarios describe a broad range of use cases taking advantage of the 106 advanced conferencing capabilities provided by a system realization 107 of the XCON framework. The call flows document the use of the 108 interface between a conference control client and a conference 109 control server using the Centralized Conferencing Manipulation 110 Protocol (CCMP)[I-D.ietf-xcon-ccmp]. 112 Due to the broad range of functionality provided by the XCON 113 Framework and the flexibility of the CCMP messaging, these call flows 114 should not be considered inclusive of all the functionality that can 115 provided by the XCON Framework and protocol implementations. These 116 flows represent a sample to provide an overview of the feature rich 117 capabilities of the XCON framework and CCMP messaging for protocol 118 developers, software developers and researchers. 120 2. Conventions 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 126 levels for compliant implementations. In this document, these key 127 words are used when describing normative functionality based on the 128 XCON Framework and CCMP. 130 Note that due to RFC formatting conventions, this document often 131 splits message details whose content would exceed 72 characters. A 132 backslash character marks where this line folding has taken place. 133 This backslash and its trailing CRLF and whitespace would not appear 134 in the actual protocol contents. 136 3. Terminology 138 This document uses the same terminology as found in the referenced 139 documents, with the following terms and abbreviations used in the 140 call flows. Also, note that the term "call flows" is used in a very 141 generic sense in this document since the media is not limited to 142 voice. The calls supported by the XCON framework and CCMP can 143 consist of media such as text, voice and video, including multiple 144 media types in a single active conference. 146 Conference and Media Control Client (CMCC): as defined in the XCON 147 Framework. In the flows in this document, the CMCC is logically 148 equivalent to the use of UAC as the client notation in the media 149 control call flows [I-D.ietf-mediactrl-call-flows]. A CMCC 150 differs from a generic Media Client in being an XCON-aware entity, 151 thus being able to also issue CCMP requests. 153 Conferencing Server (ConfS): In this document, the "Conferencing 154 Server" term is used interchangeably with the term Application 155 Server (AS) as used in the Media Control Architectural Framework 156 [RFC5567]. A Conferencing Server is intended to be able to act as 157 a Conference Control Server, as defined in the XCON framework, 158 i.e. it is able to handle CCMP requests and issue CCMP responses. 160 Media Server (MS): as defined in the Media Control Architectural 161 Framework [RFC5567]. 163 4. Overview 165 This document provides a sampling of detailed call flows that can be 166 implemented based on a system realization of the XCON framework 167 [RFC5239] and implementation of CCMP [I-D.ietf-xcon-ccmp]. This is 168 intended to be a simple guide for the use of the Conference Control 169 Protocol between the Conferencing Server and the Conference Control 170 Client. The objective is to provide an informational base reference 171 for protocol developers, software developers and researchers. 173 This document focuses on the interaction between the Conference (and 174 Media) Control Client and the Conferencing System, specifically the 175 Conferencing Server. The scenarios are based on those described in 176 the XCON framework, many of which are based on the advanced 177 conferencing capabilities described in the XCON scenarios. 178 Additional scenarios have been added to provide examples of other 179 real life scenarios that are anticipated to be supported by the 180 framework. With the exception of an initial example with media 181 control messaging, the examples do not include the details for the 182 media control [I-D.ietf-mediactrl-mixer-control-package], call 183 signaling or binary floor control [RFC4582] protocols. This document 184 references the scenarios in the Media Control call flows 185 [I-D.ietf-mediactrl-call-flows], SIP Call Control Conferencing 186 [RFC4579] and binary floor control protocol documents. 188 The rest of this document is organized as follows. Section 5 189 presents an overview on CCMP, together with some implementation- 190 related details and related matters like HTTP transport and 191 notifications. Section 6 presents the reader with examples showing 192 the different approaches CCMP provides to create a new conference. 193 Section 7 more generally addresses the different user-related 194 manipulations that can be achieved by means of CCMP, by presenting a 195 number of interesting scenarios. Section 8 addresses the several 196 scenarios that may involve the use of sidebars. Section 9 shows how 197 CCMP can be used to remove conferences and users from the system. 198 Finally, Section 11 provides a few details for what concerns the 199 Security Considerations when it comes to implementing CCMP. 201 5. Working with CCMP 203 This section aims at being a brief introduction to how the 204 Centralized Conferencing Manipulation Protocol (CCMP) 205 [I-D.ietf-xcon-ccmp] works and how it can be transported across a 206 network. Some words will be spent to describe a typical CCMP 207 interaction, by focusing on relevant aspects of the client-server 208 communication. Please notice that this section is by no means to be 209 considered as a replacement for the CCMP document, which remains a 210 mandatory read before approaching the following sections. It is just 211 conceived to help the reader take the first steps toward the actual 212 protocol interactions. 214 First of all, some lines will be devoted to the protocol by itself in 215 Section 5.1, together with some recommendations from an 216 implementation point of view. In Section 5.2, instead, an effective 217 CCMP interaction will be presented by exploiting HTTP as a transport. 218 Finally, a few words will be spent on notifications in Section 5.3. 220 Once done with these preliminary steps, some actual flows will be 221 presented and described in detail in the sections to follow. 223 5.1. CCMP and the Data Model 225 CCMP is an XML-based protocol. It has been designed as a request/ 226 response protocol. Besides, it is completely stateless, which means 227 implementations can safely handle transactions indipendently from 228 each other. 230 The protocol allows for the manipulation of conference objects and 231 related users. By manipulation it is implied, as the document 232 specifies, that a Conferencing Client (briefly CMCC in all the 233 following sections) can create, update and remove basically 234 everything that is related to the objects handled by a conferencing 235 system. This is reflected in the allowed operations (retrieve, 236 create, update, delete) and the specified request types (ranging from 237 the manipulation of blueprints and conferences to users and 238 sidebars). For instance, CCMP provides ways to: 240 o retrieve the list of registered and/or active conferences in the 241 system; 243 o create new conferences by exploiting to several different 244 approaches; 246 o add/remove users to/from a conference; 248 o update a conference with respect to all of its aspects; 250 and so on. 252 It is worthwile to note that, while CCMP acts as the means to 253 manipulate conference objects, its specification does not define 254 these objects as well. In fact, a separate document has been written 255 to specify how a conference object and all its components have to be 256 constructed: the Conference Information Data Model for Centralized 257 Conferencing (XCON) [I-D.ietf-xcon-common-data-model]. CCMP, 258 according to the request type and the related operation, carries 259 pieces of conference objects (or any object as a whole) according to 260 the aforementioned specification. This means that any implementation 261 aiming at being compliant with CCMP has to make sure that the 262 transported objects are completely compliant with the Data Model 263 specification and coherent with the constraints defined therein. To 264 make this clearer, there are elements that are mandatory in a 265 conference object: issuing a syntactically correct CCMP request that 266 carries a wrong conference object is doomed to result in a failure. 267 For this reason, it is suggested that the interested implementors 268 take special care in carefully checking the Data Model handlers as 269 well in order to avoid potential mistakes. 271 Of course, there are cases where a mandatory element in the Data 272 Model cannot be assigned in a conference object by a CCMP user. For 273 instance, a CMCC may be requesting the direct creation of a new 274 conference: in this case, a conference object assumes an 'entity' 275 element uniquely identifying the conference to be in place. Anyway, 276 the CMCC has no way to a priori know what the entity will be like, 277 considering it will only be generated by the ConfS after the request. 278 For scenarios like this one, the CCMP specification envisages the use 279 of a dedicated placeholder wildcard to make the conference object 280 compliant with the Data Model: the wildcard would then be replaced by 281 the ConfS with the right value. 283 5.2. Using HTTP as a transport 285 [I-D.ietf-xcon-ccmp] presents several ways by which CCMP requests and 286 responses can be transported from a client to a server and viceversa. 287 Nevertheless, more focus is given on HTTP as a solution for this 288 transport matter, and a whole chapter is devoted in the document to 289 how HTTP can be used for it. This document is agnostic with respect 290 to the transport in use: this means that all the call flows herein 291 presented will just show the CCMP interactions, without talking about 292 how the messages could have gone across the network. Nevertheless, 293 the following lines will provide a brief explanation, from a more 294 practical point of view, of how HTTP might be exploited to carry CCMP 295 messages. 297 In case HTTP is used as a transport, the specification is very clear 298 with respect to how the interaction has to occur. Specifically, a 299 CMCC is assumed to send his request as part of an HTTP POST message, 300 and the Server would reply by means of an HTTP 200 message. In both 301 cases, the HTTP messages would have the CCMP messages as payload, 302 which would be reflected in the Content-Type message. Figure 1 303 presents a ladder diagram of such interaction, which is followed by a 304 dump of the exchanged HTTP messages for further analysis: 306 CMCC ConfS 307 | | 308 | 1. HTTP POST (CCMP request) | 309 |--------------------------------------------->| 310 | | 311 | |--+ Parse request, 312 | | | update object 313 | |<-+ and reply 314 | | 315 | 2. 200 OK (CCMP response) | 316 |<---------------------------------------------| 317 | | 318 |--+ Parse response and | 319 | | update local copy | 320 |<-+ of conference object | 321 | | 322 . . 323 . . 325 Figure 1: CCMP on HTTP 327 As it can be seen in the protocol dump in the following lines, the 328 CMCC has issued a CCMP request (a blueprintRequest with a 'retrieve' 329 operation) towards the Conferencing Server (ConfS). The request has 330 been carried as payload of an HTTP POST (message 1.) towards a 331 previously known location. The mandatory 'Host' header has been 332 specified, and the 'Content-Type' header has been correctly set as 333 well (application/ccmp+xml). 335 The ConfS, in turn, has handled the request and replied accordingly. 336 The response (a blueprintResponse with a 'success' response code) has 337 been carried as payload of an HTTP 200 OK (message 2.). As before, 338 the 'Content-Type' header has been correctly set (application/ 339 ccmp+xml). 341 1. CMCC -> ConfS (HTTP POST, CCMP request) 342 ------------------------------------------ 343 POST /Xcon/Ccmp HTTP/1.1 344 Content-Length: 657 345 Content-Type: application/ccmp+xml 346 Host: example.com:8080 347 Connection: Keep-Alive 348 User-Agent: Apache-HttpClient/4.0.1 (java 1.5) 350 351 355 357 xcon-userid:Alice@example.com 358 xcon:AudioRoom@example.com 359 retrieve 360 361 362 364 2. CMCC <- ConfS (200 to POST, CCMP response) 365 --------------------------------------------- 366 HTTP/1.1 200 OK 367 X-Powered-By: Servlet/2.5 368 Server: Sun GlassFish Communications Server 1.5 369 Content-Type: application/ccmp+xml;charset=ISO-8859-1 370 Content-Length: 1652 371 Date: Thu, 04 Feb 2010 14:47:56 GMT 372 373 377 379 xcon-userid:Alice@example.com 380 xcon:AudioRoom@example.com 381 retrieve 382 success 383 384 385 386 AudioRoom 387 2 388 389 390 audio 391 392 393 394 395 allow 396 397 398 confirm 399 400 401 402 403 404 405 406 407 409 Just for the sake of completeness, a few words will be spent about 410 the occurred CCMP interaction as well. In fact, despite the 411 simplicity of the request, this flow already provides some relevant 412 information on how CCMP messages are built. Specifically, both the 413 request and the response share a subset of the message: 415 o confUserID: this element, provided by the CMCC, refers to the 416 requester by means of his XCON-USERID; except in a few scenarios 417 (presented in the following sections) this element must always 418 contain a valid value; 420 o confObjID: this element refers to the target conference object, 421 according to the request in place; 423 o operation: this element specifies the operation the CMCC wants to 424 perform according to the specific request type. 426 Besides those elements, the CMCC (in this case Alice, since the 427 'confUserID' has been set to 'xcon-userid:Alice@example.com') has 428 also provided an additional element, 'blueprintRequest'. The name of 429 that element varies according to the request type the CMCC is 430 interested into. In this specific scenario, the CMCC was interested 431 in acquiring details concerning a specific blueprint (identified by 432 its XCON-URI 'xcon:AudioRoom@example.com', as reflected in the 433 provided 'confObjID' target element), and so the request consisted in 434 an empty 'blueprintRequest' element. As it will be clearer in the 435 following sections, different request types may require different 436 elements, and as a consequence different content. 438 Considering the request was a 'blueprintRequest', the ConfS has 439 replied with a 'blueprintResponse' element. This element includes a 440 complete dump of the conference object (compliant with the Data 441 Model) describing the requested blueprint, together with an element 442 addressing the result of the client's request (response- 443 code=success). 445 This section won't delve in additional details for what concerns this 446 interaction. It is just worth noticing that this was the example of 447 the simplest CCMP communication that could take place between a CMCC 448 and a ConfS, a blueprintRequest: this scenario will be described in 449 more detail in Section 6.2. 451 5.3. Conference Notifications 453 [RFC5239] presents several different possible protocol interactions 454 between a conferencing server and a conferencing client. One of 455 those interactions is generically called "Notification Protocol", 456 implementing a notification service for all clients interested in 457 being informed by the server whenever something relevant happens in a 458 conference. While at first glance it may appear that such a 459 functionality should belong to a conference control protocol, such 460 feature has been specifically marked as out of scope in CCMP. As a 461 consequence, CCMP has been conceived as a request/answer protocol, 462 and in fact no ways to provide notifications to clients have been 463 introduced in the specification. 465 Nevertheless, the CCMP document by itself has a brief section 466 presenting some typical ways notifications might be managed. This 467 example document does not foster one rather than another, and all the 468 flows will always generically present a notification being involved, 469 when it seems appropriate, but not providing any info on how the 470 notification itself has been sent to the interested clients. Anyway, 471 this section will briefly introduce some of the most typical ways a 472 notification service could be implemented and integrated with the 473 functionality provided by CCMP. It is by no means to be intended as 474 a complete list of solutions: the aim of this section is to provide 475 an overview of some of the possible solutions, together with 476 indications on how they may be integrated into a CCMP-based platform. 478 The first approach that comes to mind is of course the XCON Event 479 Package [I-D.ietf-xcon-event-package]. This specification extends 480 the SIP Event Package for Conference State [RFC4575] and allows for 481 the notification of conference notifications by means of the NOTIFY/ 482 SUBSCRIBE mechanisms of SIP. Specifically, any SIP client who 483 subscribed for notifications related to a specific conference would 484 receive notifications via SIP describing all the changes to the 485 document. An example ladder diagram is presented in Figure 2: in 486 this figure, we assume a CMCC has updated a conference object, and 487 the update is notified to a previously subscribed SIP client. 489 CMCC ConfS UAC 490 | | | 491 | | 1. SIP SUBSCRIBE | 492 | |<--------------------------| 493 | Handle +--| | 494 | new | | | 495 | subscription +->| 2. SIP 200 OK | 496 | |-------------------------->| 497 | | | 498 . . . 499 . . . 500 | | | 501 | 3. CCMP (add user) | | 502 |---------------------->| | 503 | |--+ Add user | 504 | | | to conf. | 505 | |<-+ object | 506 | 4. CCMP (success) | | 507 |<----------------------| | 508 | | 5. SIP NOTIFY (changes) | 509 | |-------------------------->| 510 | | 6. SIP 200 OK | 511 | |<--------------------------| 512 | | | 513 . . . 514 . . . 516 Figure 2: XCON Event Package: SIP notifications 518 While simple and effective, this solution has a drawback: it assumes 519 that all clients to be notified have a SIP stack. In fact, the 520 approach relies on the SIP SUBSCRIBE/NOTIFY mechanism. This means 521 that a client without a SIP stack would be unable to receive 522 notifications, in case no other means were available. Of course this 523 is not a desired situation in a framework as XCON which has been 524 conceived as being protocol-agnostic. 526 Considering CCMP is going to be probably most often deployed on HTTP, 527 another way to achieve notifications might be by exploiting some sort 528 of HTTP callbacks, as suggested in the CCMP specification itself. 529 This would allow to overcome the previous limitation, since both the 530 CMCC and the ConfS would already have an HTTP stack to make use of. 531 Using this approach, an interested web client might provide the 532 Conferencing System with an URL to contact whenever updates are 533 available: the update could be part of the notification message 534 itself, or it could be only implicitly referenced by the 535 notification. At the same time, alternative notification means could 536 be exploited, e.g. by taking advantage of functionality provided by 537 other protocols as XMPP. Figure 3 shows an example of different 538 subscriptions which accordingly trigger notifications after the same 539 relevant event happens. 541 CMCC ConfS Sub1 Sub2 542 | | | | 543 | | 1. Register callback | | 544 | |<--------------------------| | 545 | Handle +--| | | 546 | new HTTP | | | | 547 | subscription +->| 2. Acknlowledge | | 548 | |-------------------------->| | 549 | | | | 550 | | 3. XMPP subscription | 551 | |<---------------------------------------| 552 | Handle +--| | | 553 | new XMPP | | | | 554 | subscription +->| 4. XMPP confirm subscription | 555 | |--------------------------------------->| 556 | | | | 557 . . . . 558 . . . . 559 | | | | 560 | 5. CCMP (add user) | | | 561 |-------------------->| | | 562 | |--+ Add user | | 563 | | | to conf. | | 564 | |<-+ object | | 565 | 6. CCMP (success) | | | 566 |<--------------------| | | 567 | | 7. HTTP POST (changes) | | 568 | |-------------------------->| | 569 | | 8. HTTP 200 OK | | 570 | |<--------------------------| | 571 | | | | 572 | | 9. XMPP notification | | 573 | |--------------------------------------->| 574 | | | | 575 . . . . 576 . . . . 578 Figure 3: Alternative means for notifications 580 That said, there are actually many other ways to achieve 581 notifications in a conferencing system. A conferencing system may 582 rely on several other solutions than the ones presented as periodic 583 checks of a well known URL by interested clients, long polls, BOSH- 584 based communications, Atom/RSS feeds and the like. 586 6. Conference Creation 588 This section starts the sequence of call flows of typical XCON- 589 related scenarios provided in this document. Specifically, it 590 provides details associated with the various ways in which a 591 conference can be created using CCMP and the XCON framework 592 constructs. As previously mentioned the details of the media 593 control, call signaling and floor control protocols, where 594 applicable, are annotated in the flows without showing all the 595 details. This also applies to CCMP, whose flows are related to the 596 protocol alone, hiding any detail concerning the transport that may 597 have been used (e.g. HTTP). However, for clarification purposes, 598 the first example Section 6.1 provides the details of the media 599 control messaging along with an example of the standard annotation 600 used throughout the remainder of this document. In subsequent flows, 601 only this annotation (identified by lower case letters) is included 602 and the reader is encouraged to refer to the call flows in the 603 relevant documents for details about the other protocols. The 604 annotations for the call signaling are on the left side of the 605 conferencing server vertical bar and those for the media control 606 messaging are on the right side. 608 6.1. Basic Conference Creation 610 The simplest manner in which a conference can be created is 611 accomplished by the client sending a "confRequest" message with the 612 "create" operation as the only parameter to the conference server, 613 together with the "confUserID" associated with the requesting client 614 itself. This results in the creation of a default conference, with 615 an XCON-URI in the form of the "confObjID" parameter, the XCON-USERID 616 in the form of the "confUserID" parameter (the same already present 617 in the request) and the data for the conference object in the 618 "confInfo" parameter all returned in the "confResponse" message. 619 According to the implementation of the framework, this example may 620 also add the user that invoked the conference upon creation to the 621 conference object (e.g., "method" attribute in the "target" element 622 of "allowed-users-list" may be set to "dial out" for this client 623 based on the particular conferencing systems default). This is 624 exactly the case depicted in the figure, which is presented to enrich 625 the scenario. 627 The specific data for the conference object are returned in the 628 "confResponse" message in the "confInfo" parameter. This allows the 629 client (with the appropriate authorization) to manipulate these data 630 and add additional participants to the conference, as well as change 631 the data during the conference. In addition, the client may 632 distribute the conferencing information to other participants 633 allowing them to join, the details of which are provided in 634 additional flows. Please notice that, according to the CCMP 635 specification, the return of the new conference data in the 636 "confInfo" parameter is not mandatory: if the "confInfo" parameter of 637 the successful confResponse/create is void, a following confRequest/ 638 retrieve of the returned "confObjID" can be triggered to provide the 639 requesting client with the detailed conference description. 641 Clients that are not XCON-aware can join the conference using a 642 specific signaling interface such as SIP [RFC3261] or other supported 643 signaling protocols (being XCON agnostic with respect to them), using 644 the signaling interface to the conference focus as described in 645 [RFC4579]. However, these details are not shown in the message 646 flows. The message flows in this document identify the point in the 647 message flows at which this signaling occurs via the lower case 648 letter items (i.e., (a)...(x)) along with the appropriate text for 649 the processing done by the conferencing server. 651 As anticipated at the beginning of this section, this example also 652 shows how the conferencing system may make use of other standard 653 components to make available its functionality. An example of that 654 is the MEDIACTRL specification, which allows the conferencing system 655 to configure conference mixes, IVR dialogs and all sort of media- 656 related interactions an application like this may need. So, just to 657 provide the reader with some insight on these interactions, the 658 conferencing system also configures and starts a mixer via MEDIACTRL 659 as soon as the conference is created (transactions A1 and A2), and 660 attaches clients to it when necessary (e.g. when CMCC1 joins the 661 conference by means of SIP signaling, its media channels are attached 662 to the Media Server using MEDIACTRL in B1/B2). 664 CMCC1 CMCC2 CMCCx ConfS MS 665 | | | | | 666 |(1)confRequest(confUserID, create) | | 667 |-------------------------------------->| | 668 | | (a)Create +---| | 669 | | |Conf | | | 670 | | |Object | | | 671 | | |& IDs +-->| | 672 | | | | A1. CONTROL | 673 | | | |+++++++++++>>| 674 | | | |(create conf)|--+ (b) 675 | | | | | | create 676 | | | | | | conf and 677 | | | | A2. 200 OK |<-+ its ID 678 | | | |<<+++++++++++| 679 | | | |(confid=Y) | 680 |(2)confResponse(confUserID,confObjID, | | 681 | create, success, | | 682 | version, confInfo) | | 683 |<--------------------------------------| | 684 | | | | | 685 | | (c) Focus +---| | 686 | | sets up | | | 687 | | signaling | | | 688 | | to CMCC1 +-->| | 689 | | | | | 690 | | | | B1. CONTROL | 691 | | | |+++++++++++>>| 692 | | | | (join CMCC1 | 693 | | | | <->confY) | 694 | | | | | 695 | | | | |--+(d) join 696 | | | | | | CMCC1 & 697 | | | | B2.200 OK |<-+ conf Y 698 | | | |<<+++++++++++| 699 | | | | | 700 |<<#################################################>>| 701 | Now the CMCC1 is mixed in the conference | 702 |<<#################################################>>| 703 | | | | | 704 |******CMCC1 may then manipulate conference data *****| 705 |****** and add addt'l users, etc. | *****| 706 ' ' ' ' ' 707 ' ' ' ' ' 708 ' ' ' ' ' 709 Figure 4: Create Basic Conference - Complete flow 711 "Alice" "Bob" 712 CMCC1 CMCC2 CMCCx ConfS 713 | | | | 714 |(1)confRequest(confUserID, create) | 715 |-------------------------------------->| 716 | | | | 717 | | (a)Create +---| 718 | | |Conf | | 719 | | |Object | | 720 | | |& IDs +-->| 721 | | | |--+ (b) MS 722 | | | | | creates 723 | | | | | conf and 724 | | | |<-+ its ID 725 | | | | (confid=Y) 726 |(2)confResponse(confUserID, confObjID | 727 | create, success, | 728 | version, confInfo) | 729 | | | | 730 |<--------------------------------------| 731 | | | | 732 | | | | 733 | | (c) Focus +---| 734 | | sets up | | 735 | | signaling | | 736 | | to CMCC1 +-->| 737 | | | | 738 | | | |--+(d) MS joins 739 | | | | | CMCC1 & 740 | | | |<-+ conf Y 741 |<<###################################>>| 742 | CMCC1 is mixed in the conference | 743 |<<###################################>>| 744 | | | | 745 |**CMCC1 then manipulates conference****| 746 |** data and add addt'l users, etc. ***| 747 ' ' ' ' 748 ' ' ' ' 749 ' ' ' ' 750 - 752 Figure 5: Create Basic Conference - Annotated Flow 754 1. confRequest/create message (Alice creates a default conference) 756 757 761 764 xcon-userid:Alice@example.com 765 create 766 767 769 2. confResponse/create message ("success", created conference 770 object returned) 772 773 777 780 xcon-userid:Alice@example.com 781 xcon:8977794@example.com 782 create 783 success 784 1 785 786 787 788 789 Default conference initiated by Alice 790 791 792 793 794 xcon:8977794@example.com 795 796 797 Conference XCON-URI 798 799 800 801 10 802 803 804 audio 805 806 807 808 false 809 810 811 812 allow 813 814 816 817 818 819 820 821 823 Figure 6: Create Basic Conference (Annotated) Detailed Messaging 825 6.2. Conference Creation using Blueprints 827 The previous example showed the creation of a new conference using 828 default values. This means the client provided no information about 829 how she wanted the conference to be like. Anyway, the XCON framework 830 (and CCMP as a consequence) allows for the exploitation of templates. 831 These templates are called "conference blueprints", and are basically 832 conference objects with pre-defined settings except for the actual 833 identifiers. This means that a client might get one of these 834 blueprints, choose the one that more fits his needs, and use the 835 chosen blueprint to create a new conference. 837 This section addresses exactly this scenario, and Figure 7 provides 838 an example of one client, "Alice", discovering the conference 839 blueprints available for a particular conferencing system and 840 creating a conference based on the desired blueprint. In particular, 841 Alice is interested in those blueprints suitable to represent a 842 "video-conference", i.e. a conference in which both audio and video 843 are available, so she exploits the filter mechanism envisioned by 844 CCMP to make a selective blueprints retrieve request. This results 845 in three distinct CCMP transactions. 847 CMCC "Alice" ConfS 848 | | 849 | (1) blueprintsRequest | 850 | (confUserID,xpathFilter) | 851 |------------------------------>| 852 | | 853 | (2) blueprintsResponse | 854 | (confUserID, success, | 855 | blueprintsInfo) | 856 |<------------------------------| 857 | | 858 |--+ | 859 | | choose preferred | 860 | | blueprint from the | 861 | | list (blueprintName) | 862 |<-+ | 863 | | 864 | (3) blueprintRequest | 865 | (confUserID,confObjID, | 866 | retrieve) | 867 |------------------------------>| 868 | | 869 | 4) blueprintResponse | 870 | (confUserID,confObjID,| 871 | retrieve,confInfo) | 872 |<------------------------------| 873 | | 874 | (5) confRequest(confUserID, | 875 | confObjID,create) | 876 |------------------------------>| 877 | | 878 | (a)Create +---| 879 | Conf | | 880 | Object | | 881 | & IDs +-->| 882 | |--+ (b) MS 883 | | | creates 884 | | | conf and 885 | |<-+ its ID 886 | | (confid=Y) 887 |(6) confResponse | 888 | (confUserID, confObjID*, | 889 | create, success) | 890 |<------------------------------| 891 | | 892 | | 893 | | 894 . . 896 . . 898 Figure 7: Client Creation of Conference using Blueprints 900 1. Alice first sends a "blueprintsRequest" message to the 901 conferencing system identified by the conference server discovery 902 process. This request contains the "confUserID" of the user 903 issuing the request (Alice's XCON-USERID) and the "xpathFilter" 904 parameter by which Alice specifies she desires to obtain only 905 blueprints providing support for both audio and video: for this 906 purpose, the xpath query contained in this field is: "/ 907 conference-info[conference-description/available-media/entry/ 908 type='audio' and conference-description/available-media/entry/ 909 type='video'"] . Upon receipt of the "blueprintsRequest", the 910 conferencing system would first authenticate Alice and then 911 ensure that Alice has the appropriate authority based on system 912 policies to receive the requested kind of blueprints supported by 913 that system. 915 2. All blueprints that Alice is authorized to use are returned in a 916 "blueprintsResponse" message in the "blueprintsInfo" element. 918 3. Upon receipt of the "blueprintsResponse" containing the 919 blueprints, Alice determines which blueprint to use for the 920 conference to be created. Alice sends a "blueprintRequest" 921 message to get the specific blueprint as identified by the 922 "confObjID". 924 4. The conferencing system returns the "confInfo" associated with 925 the specific blueprint as identified by the 'confObjID' in the 926 "blueprintResponse" message. 928 5. Alice finally sends a "confRequest" with a "create" operation to 929 the conferencing system to create a conference reservation 930 cloning the chosen blueprint. This is achieved by writing the 931 blueprint's XCON-URI in the "confObjID" parameter. 933 6. Upon receipt of the "confRequest" message with a "create" 934 operation, the conferencing system uses the received blueprint to 935 clone a conference, allocating a new XCON-URI (again called 936 "confObjID*" in the example). The conferencing server then sends 937 a "confResponse" message including the new "confObjID*" 938 associated with the newly created conference instance. Upon 939 receipt of the "confResponse" message, Alice can now add other 940 users to the conference . 942 1. blueprintsRequest message (Alice requires the list of the 943 available blueprints) 945 946 949 951 xcon-userid:Alice@example.com 952 953 /conference-info[ 954 conference-description/available-media/entry/type='audio' and 955 conference-description/available-media/entry/type='video'] 956 957 958 959 961 2. blueprintsResponse message (the server provides a descriptions of 962 the available blueprints) 964 965 969 972 xcon-userid:Alice@example.com 973 success 974 975 976 977 xcon:VideoRoom@example.com 978 VideoRoom 979 Video Room: 980 conference room with public access, 981 where both audio and video are available, 982 4 users can talk and be seen at the same time, 983 and the floor requests are automatically accepted. 984 985 986 987 xcon:VideoConference1@example.com 988 VideoConference1 989 Public Video Conference: conference 990 where both audio and video are available, 991 only one user can talk 992 993 994 995 996 997 999 3. blueprintRequest/retrieve message (Alice wants the 1000 "VideoRoom" blueprint) 1002 1003 1007 1009 xcon-userid:Alice@example.com 1010 xcon:VideoRoom@example.com 1011 retrieve 1012 1013 1014 1016 4. blueprintResponse/retrieve message ("success", "VideoRoom" 1017 conference object returned) 1019 1020 1024 1026 xcon-userid:Alice@example.com 1027 xcon:VideoRoom@example.com 1028 retrieve 1029 success 1030 1031 1032 1033 VideoRoom 1034 4 1035 1036 1037 audio 1038 1039 1040 video 1041 1042 1043 1044 1045 allow 1046 1047 1048 confirm 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1060 5. confRequest/create message (Alice clones the "AudioRoom" blueprint) 1062 1063 1067 1070 xcon-userid:Alice@example.com 1071 xcon:VideoRoom@example.com 1072 create 1073 1074 1075 1077 6. confResponse/create message ("success", cloned conference 1078 object returned) 1080 1081 1085 1088 xcon-userid:Alice@example.com 1089 xcon:8977794@example.com 1090 create 1091 success 1092 1 1093 1094 1095 1096 1097 New conference by Alice cloned from VideoRoom 1098 1099 1100 1101 1102 xcon:8977794@example.com 1103 1104 1105 conference xcon-uri 1106 1107 1108 8601 1109 1110 1111 1112 10 1113 1114 1115 audio 1116 1117 1118 video 1119 1120 1121 1122 1123 allow 1124 1125 1126 1127 confirm 1128 1129 1130 1131 1133 1134 1135 1136 1137 1139 Figure 8: Create Conference (Blueprint) Detailed Messaging 1141 6.3. Conference Creation using User-Provided Conference Information 1143 A conference can also be created by the client sending a 1144 "confRequest" message with the "create" operation, along with the 1145 desired data in the form of the "confInfo" parameter for the 1146 conference to be created. The request also includes the "confUserID" 1147 of the requesting entity. 1149 This approach allows for a client (in this example Alice) to 1150 completely describe how the conference object should look like, 1151 without just relying on defaults or blueprints: i.e. which media 1152 should be available, whish should be the topic, the users allowed to 1153 join, any scheduling-related information and so on. This can be 1154 done, as anticipated, by providing in the creation request a full 1155 conference object for the server to parse. 1157 This "confInfo" parameter must comply of course with the Data Model 1158 specification. This means that its "entity" attribute is mandatory, 1159 and cannot be missing in the document. Nevertheless, considering in 1160 this example the client is actually requesting the creation of a new 1161 conference, which doesn't exist yet, this "entity" attribute cannot 1162 be set to a valid value. This is related to an issue already 1163 anticipated in Section 5.1. To cope with this, the CCMP protocol 1164 fosters the use of a wildcard placeholder: this placeholder 1165 ("xcon:AUTO_GENERATE_1@example.com" in the example) has the only aim 1166 of making the "confInfo" element compliant with the Data Model, and 1167 would subsequently be replaced by the conferencing system with the 1168 actual value. This means that, as soon as the conferencing system 1169 actually creates the conference, a valid "entity" value is created 1170 for it as well, which would take the place of the wildcard when 1171 completing the actual conference object provided by the client. 1173 To give a flavour of what could be added to the conference object, we 1174 assume Alice is also interested in providing scheduling-related 1175 information. So, in this example, Alice also specifies by the 1176 element included in the "confInfo" that the 1177 conference she wants to create has to occur on a certain date from a 1178 certain start time to a certain stop time and has to be replicated 1179 weekly. 1181 Once Alice has prepared the "confInfo" element and sent it as part of 1182 her request to the server, if the conferencing system can support 1183 that specific type of conference (capabilities, etc.), then the 1184 request results in the creation of a conference. We assume the 1185 request has been successful, and as a consequence XCON-URI in the 1186 form of the "confObjID" parameter and the XCON-USERID in the form of 1187 the "confUserID" parameter (again, the same as the requesting entity) 1188 are returned in the "confResponse" message. 1190 In this example, we choose not to return the created conference 1191 object in the successful "confResponse" in the "confInfo" parameter. 1192 Nevertheless, Alice could still retrieve the actual conference object 1193 by issuing a "confRequest" with a "retrieve" operation on the 1194 returned "confObjID". Such a request would show how, as we 1195 anticipated at the beginning of this section, the "entity" attribute 1196 of the conference object in "confInfo" is replaced with the actual 1197 information (i.e. "xcon:6845432@example.com"). 1199 Just for the sake of completeness and to provide the reader with some 1200 insight about how the CCMP conferencing server might interact with 1201 other related components, this example also assumes that the 1202 conference is activated upon creation: i.e., the "method" attribute 1203 is set to "dial out" for this client based on the particular 1204 conferencing systems default. This results (as shown in the ladder 1205 diagram) in Alice, Bob and Carol being called by the conferencing 1206 system. Just as before, this is not to be considered mandatory, 1207 since it depends on the implementation choices of the framework. 1209 Alice Bob Carol ConfS 1210 | | | | 1211 | | | | 1212 |(1)confRequest(confUserID, | | 1213 | create, confInfo) | | 1214 | | | | 1215 |-------------------------------------->| 1216 | | | | 1217 | | (a)Create +---| 1218 | | |Conf | | 1219 | | |Object | | 1220 | | |& IDs +-->| 1221 | | | |--+ (b) MS 1222 | | | | | creates 1223 | | | | | conf and 1224 | | | |<-+ its ID 1225 | | | | (confid=Y) 1226 |(2)confResponse(confUserID | | 1227 | confObjID, create, | | 1228 | success, version) | | 1229 |<--------------------------------------| 1230 | | | | 1231 | | (c) Focus +---| 1232 | | sets up | | 1233 | | signaling | | 1234 | | to Alice +-->| 1235 | | | | 1236 | | | |--+(d) MS joins 1237 | | | | | Alice & 1238 | | | |<-+ conf Y 1239 | | | | 1240 | | | | 1241 |<<###################################>>| 1242 | Alice is mixed in the conference | 1243 |<<###################################>>| 1244 | | | | 1245 | | (e)Focus +---| 1246 | | sets up | | 1247 | | signaling | | 1248 | | to Bob | | 1249 | | | +-->| 1250 | | | | 1251 | | | |--+(f)MS joins 1252 | | | | | Bob & 1253 | | | |<-+ conf Y 1254 | | | | 1255 | |<<###################>>| 1256 | | Bob is mixed too | 1257 | |<<###################>>| 1258 | | | | 1259 | | (g )Focus +---| 1260 | | sets up | | 1261 | | signaling | | 1262 | | to Carol | | 1263 | | CMCCx +-->| 1264 | | | | 1265 | | | |--+(h)MS joins 1266 | | | | | CMCCx & 1267 | | | |<-+ conf Y 1268 | | | | 1269 | | |<<#######>>| 1270 | | |Carol mixed| 1271 | | |<<#######>>| 1272 | | | | 1273 | | | | 1274 | | | | 1275 |<***All parties connected to conf Y***>| 1276 | | | | 1277 | | | | 1278 " " " " 1279 " " " " 1280 " " " " 1282 Figure 9: Create Basic Conference from user provided conference-info 1284 1. confRequest/create message (Alice proposes a conference object 1285 to be created - direct creation) 1287 1288 1292 1295 xcon-userid:Alice@example.com 1296 create 1297 1298 1299 1300 1301 Dial-out conference initiated by Alice 1302 1303 10 1304 1305 1306 audio 1307 1308 1309 1310 1311 1312 BEGIN:VCALENDAR 1313 VERSION:2.0 1314 PRODID:-//Mozilla.org/NONSGML \ 1315 Mozilla Calendar V1.0//EN 1316 BEGIN:VEVENT 1317 DTSTAMP: 20100127T140728Z 1318 UID: 20100127T140728Z-345FDA-alice@example.com 1319 ORGANIZER:MAILTO:alice@example.com 1320 DTSTART:20100127T143000Z 1321 RRULE:FREQ=WEEKLY 1322 DTEND: 20100127T163000Z 1323 END:VEVENT 1324 END:VCALENDAR 1325 1326 1328 2010-01-27T14:29:00Z 1329 1330 1332 2010-01-27T16:31:00Z 1333 1334 2010-01-27T15:30:00Z 1335 1336 1337 1338 1339 1340 allow 1341 1342 1344 1346 1348 1349 1350 1351 1352 1353 1355 2. confResponse/create message ("success") 1357 1358 1362 1365 xcon-userid:Alice@example.com 1366 xcon:6845432@example.com 1367 create 1368 success 1369 1 1370 1371 1373 Figure 10: Create Basic Conference Detailed Messaging 1375 6.4. Cloning an Existing Conference 1377 A client can also create another conference by cloning an existing 1378 conference, such as an active conference or conference reservation. 1379 This approach can be seen as a logical extension of the creation of a 1380 new conference using a blueprint: the difference is that, instead of 1381 cloning the pre-defined settings listed in a blueprint, the settings 1382 of an existing conference would be cloned. 1384 In this example, the client sends a "confRequest" message with the 1385 "create" operation, along with the "confUserID" and a specific 1386 "confObjID", from which a new conference is to be created by cloning 1387 an existing conference. 1389 An example of how a client can create a conference based on a 1390 blueprint is provided in Section 6.2. The manner by which a client 1391 in this example might learn about a conference reservation or active 1392 conferences is similar to the first step in the blueprint example, 1393 with the exception of specifying querying for different types of 1394 conference objects supported by the specific conferencing system. 1395 For example, in this example, the client clones a conference 1396 reservation (i.e., an inactive conference). 1398 If the conferencing system can support a new instance of the specific 1399 type of conference (capabilities, etc.), then the request results in 1400 the creation of a conference, with an XCON-URI in the form of a new 1401 value in the "confObjID" parameter to reflect the newly cloned 1402 conference object returned in the "confResponse" message. 1404 Alice ConfS 1405 | | 1406 |(1)confRequest(confUserID, | 1407 | confObjID, create) | 1408 |------------------------------>| 1409 | (a)Create +---| 1410 | Conf | | 1411 | Object | | 1412 | & IDs +-->| 1413 | |--+ (b) MS 1414 | | | creates 1415 | | | conf and 1416 | |<-+ its ID 1417 | | (confid=Y) 1418 | | 1419 |(2)confResponse(confUserID, | 1420 | confObjID*,create, | 1421 | success, version, | 1422 | confInfo) | 1423 | | 1424 |<------------------------------| 1425 | | 1427 Figure 11: Create Basic Conference - Clone 1429 1. Alice, a conferencing system client, sends a confRequest message 1430 to clone a conference based on an existing conference 1431 reservation. Alice indicates this conference should be cloned 1432 from the specified parent conference represented by the 1433 "confObjID" in the request. 1435 2. Upon receipt of the confRequest message containing a "create" 1436 operation and "confObjID", the conferencing system ensures that 1437 the "confObjID" received is valid. The conferencing system 1438 determines the appropriate read/write access of any users to be 1439 added to a conference based on this "confObjID" (using 1440 membership, roles, etc.). The conferencing system uses the 1441 received "confObjID" to clone a conference reservation. The 1442 conferencing system also reserves or allocates a new "confObjID" 1443 (called "confObjID*" in Figure 11) to be used for the cloned 1444 conference object. This new identifier is of course different 1445 from the one associated with the conference to be cloned, since 1446 it represents a different conference object. Any subsequent 1447 protocol requests from any of the members of the conference must 1448 use this new identifier. The conferencing system maintains the 1449 mapping between this conference ID and the parent conference 1450 object ID associated with the reservation through the conference 1451 instance, and this mapping is explicitly addressed through the 1452 "cloning-parent" element of the "conference-description" in the 1453 new conference object. 1455 1. confRequest/create message 1457 1458 1462 1465 xcon-userid:Alice@example.com 1466 xcon:6845432@example.com 1467 create 1468 1469 1471 2. confResponse/create message ("success", created conference 1472 object returned) 1474 1475 1479 1482 xcon-userid:Alice@example.com 1483 xcon:8977794@example.com 1484 create 1485 success 1486 1 1487 1488 1489 1490 1491 New conference by Alice cloned from 6845432 1493 1494 1495 xcon:6845432@example.com 1496 1497 10 1498 1499 1500 audio 1501 1502 1503 1504 1505 allow 1506 1507 1509 1511 1513 1514 1515 1516 1517 confirm 1518 1519 1520 1521 1522 1523 1524 1525 1527 Figure 12: Create Basic Conference (Clone) Detailed Messaging 1529 7. Conference Users Scenarios and Examples 1531 Section 6 showed examples describing the several different ways a 1532 conference might be created using CCMP. This section instead focuses 1533 on user-related scenarios, i.e. typical scenarios that may occur 1534 during the lifetime of a conference, like adding new users and 1535 handling their media. The following scenarios are based on those 1536 documented in the XCON framework. The examples assume that a 1537 conference has already been correctly established, with media, if 1538 applicable, per one of the examples in Section 6. 1540 7.1. Adding a Party 1542 In this example, Alice wants to add Bob to an established conference. 1543 In the following example we assume Bob is a new user of the system, 1544 which means Alice also needs to provide some details about him. In 1545 fact, the case of Bob already present as a user in the conferencing 1546 system is much easier to address, and will be discussed later on. 1548 "Alice" "Bob" 1549 CMCC1 CMCC2 CMCCx ConfS 1550 | | | | 1551 |(1) userRequest(confUserID,| | 1552 | confObjID, create, | | 1553 | userInfo) | | | 1554 |-------------------------------------->| 1555 | | | | 1556 | | (a) Create +---| 1557 | | | Bob | | 1558 | | | as a | | 1559 | | | user +-->| 1560 | | | | 1561 |(2) userResponse(confUserID,confObjID | 1562 | create,success,userInfo) | 1563 |<--------------------------------------| 1564 | | | | 1565 | | | (b) Focus | 1566 | | | sets up | 1567 | | | signaling | 1568 | | | to Bob | 1569 | |<----------------------| 1570 | | | | 1571 | | | (c) Notify| 1572 | | | ("Bob just| 1573 | | | joined") | 1574 | | |<----------| 1575 | | | | 1576 ' ' ' ' 1577 ' ' ' ' 1578 ' ' ' ' 1580 Figure 13: Client Manipulation of Conference - Add a party 1582 1. Alice sends a userRequest message with an operation of "create" 1583 to add Bob to the specific conference as identified by the 1584 "confObjID". The "create" operation also makes sure that Bob is 1585 created as a user in the whole conferencing system. This is done 1586 by adding a "userInfo" element describing Bob as a user. This is 1587 needed in order to let the conferencing system be aware of Bob's 1588 characteristics. In case Bob was already a registered user, 1589 Alice would just have referenced him through his XCON-USERID in 1590 the "entity" attribute of the "userInfo" field, without providing 1591 additional data. In fact, that data (including, for instance, 1592 Bob's SIP-URI to be used subsequently for dial-out) would be 1593 obtained by referencing the extant registration. The conference 1594 server ensures that Alice has the appropriate authority based on 1595 the policies associated with that specific conference object to 1596 perform the operation. As mentioned before, a new Conference 1597 User Identifier is created for Bob, and the "userInfo" is used to 1598 update the conference object accordingly. As already seen in 1599 Section 6.3, a placeholder wildcard 1600 ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP messages 1601 below) is used for the "entity" attribute of the "userInfo" 1602 element, to be replaced by the actual XCON-USERID later on; 1604 2. Bob is successfully added to the conference object, and an XCON- 1605 USERID is allocated for him ("xcon-userid:Bob@example.com"); this 1606 identifier is reported in the response as part of the "entity" 1607 element of the returned "userInfo"; 1609 3. In the presented example, the call signaling to add Bob to the 1610 conference is instigated through the Focus as well. We again 1611 remind that this is implementation specific. In fact, a 1612 conferencing system may accomplish different actions after the 1613 user creation, just as it may do nothing at all. Among the 1614 possible actions, for instance Bob may be added as a 1615 element to the element, whose joining 1616 "method" may be either "dial-in" or "dial-out". Besides, out-of- 1617 band notification mechanisms may be involved as well, e.g. to 1618 notify Bob via mail of the new conference, including details as 1619 the date, password, expected participants and so on (see 1620 Section 5.3). 1622 To conclude the overview on this scenario, once Bob has been 1623 successfully added to the specified conference, per updates to the 1624 state, and depending upon the policies, other participants 1625 (including Bob himself) may be notified of the addition of Bob to 1626 the conference via the Conference Notification Service in use. 1628 1. userRequest/create message (Alice adds Bob) 1630 1631 1634 1636 xcon-userid:Alice@example.com 1637 xcon:8977878@example.com 1638 create 1639 1640 1641 Bob 1642 1643 1644 mailto:bob.depippis@example.com 1645 Bob's email 1646 1647 1648 1649 Bob's laptop 1650 1651 1652 1653 1654 1656 2. userResponse/create message ("success": a new XCON-USERID is 1657 created for Bob and he is added to the conference) 1659 1660 1663 1665 xcon-userid:Alice@example.com 1666 xcon:8977878@example.com 1667 create 1668 success 1669 10 1670 1671 1672 Bob 1673 1674 1675 mailto:bob.depippis@example.com 1676 Bob's email 1677 1678 1679 1680 Bob's laptop 1681 1682 1683 1684 1685 1687 Figure 14: Add Party Message Details 1689 7.2. Muting a Party 1691 This section provides an example of the muting of a party in an 1692 active conference. We assume that the user to mute has already been 1693 added to the conference. The document only addresses muting and not 1694 unmuting as well, since it would involve an almost identical CCMP 1695 message flow anyway. Although, in case that any external floor 1696 control is involved, whether or not a particular conference client 1697 can actually mute/unmute itself must be considered by the 1698 conferencing system. 1700 Please notice that interaction between CCMP and floor control 1701 should be carefully considered. In fact, handling CCMP- and BFCP- 1702 based media control has to be considered as multiple layers: i.e., 1703 a participant may have the BFCP floor granted, but be muted by 1704 means of CCMP. If so, he would still be muted in the conference, 1705 and would only be unmuted if both the protocols allowed for this. 1707 Figure 15 provides an example of one client, "Alice", impacting the 1708 media state of another client, "Bob". This example assumes an 1709 established conference. In this example, Alice, whose role is 1710 "moderator" of the conference, wants to mute Bob on a medium-size 1711 multi-party conference, as his device is not muted (and he's 1712 obviously not listening to the call) and background noise in his 1713 office environment is disruptive to the conference. BFCP floor 1714 control is assumed not to be involved. 1716 From a protocol point of view, muting/unmuting an user basically 1717 consists in updating the conference object by modifying the settings 1718 related to the target user's media streams. Specifically, Bob's 1719 "userInfo" must be updated by modifying its audio 1720 information (e.g. setting it to "recvonly" in case of muting), 1721 identified by the right media id. 1723 "Alice" "Bob" 1724 CMCC1 CMCC2 CMCCx ConfS MS 1725 | | | | | 1726 |(1) userRequest(confUserID,| | | 1727 | confObjID, update, | | | 1728 | userInfo) | | | | 1729 |--------------------------------------->| | 1730 | | | | Mute Bob | 1731 | | | |----------------->| 1732 | | | | 200 OK | 1733 | | | |<-----------------| 1734 | | | | | 1735 | |<====== XXX Bob excluded from mix XXX ====>| 1736 | | | | | 1737 | | (a) Update +---| | 1738 | | Bob in | | | 1739 | | Data Model | | | 1740 | | (muted) +-->| | 1741 | | | | | 1742 | (2)userResponse(confUserID,confObjID, | | 1743 | update,success,version) | | 1744 |<---------------------------------------| | 1745 | | | | | 1746 | | | (b) Notify | | 1747 | | | ("Bob is | | 1748 | | | muted") | | 1749 | | |<-----------| | 1750 | | | | | 1751 ' ' ' ' ' 1752 ' ' ' ' ' 1753 ' ' ' ' ' 1755 Figure 15: Client Manipulation of Conference - Mute a party 1757 1. Alice sends a userRequest message with an "update" operation and 1758 the userInfo with the "status" field in the "media" element for 1759 Bob set to "revconly". The Conference Server ensures that Alice 1760 has the appropriate authority based on the policies associated 1761 with that specific conference object to perform the operation and 1762 updates the "userInfo" in the conference object reflecting that 1763 Bob's media is not to be mixed with the conference media. In 1764 case the Conference Server relies on a remote Media Server for 1765 its multimedia functionality, it subsequently changes Bob's media 1766 profile accordingly by means of the related protocol interaction 1767 with the MS to enforce the decision. An example describing a 1768 possible way of dealing with such a situation using the Media 1769 Server Control architecture is described in 1771 [I-D.ietf-mediactrl-call-flows], at "Simple Bridging: Framework 1772 Transactions (2)". 1774 2. A userResponse message with a response-code of "success" is then 1775 sent to Alice. Depending upon the policies, the conference 1776 server may notify other participants (including Bob) of this 1777 update via any Conference Notification Service that may be in 1778 use. 1780 1. userRequest/update message (Alice mutes Bob) 1782 1783 1786 1788 xcon-userid:Alice@example.com 1789 xcon:8977878@example.com 1790 update 1791 1792 1793 1794 1795 123 1796 recvonly 1797 1798 1799 1800 1801 1802 1804 2. userResponse/update message ("success") 1806 1807 1810 1812 xcon-userid:Alice@example.com 1813 xcon:8977878@example.com 1814 update 1815 success 1816 7 1817 1818 1819 1821 Figure 16: Mute Message Details 1823 7.3. Conference Announcements and Recordings 1825 This section deals with features that are typically required in a 1826 conferencing system, that are public announcements (e.g. to notify 1827 vocally that a new user joined a conference) and name recording. 1828 While this is not strictly CCMP-related (the CCMP signaling is 1829 actually the same as the one seen in Section 7.1) it is an 1830 interesting scenario to address to see how the several components of 1831 an XCON-compliant architecture interact with each other to make it 1832 happen. 1834 In this example, as shown in Figure 17 Alice is joining Bob's 1835 conference that requires that she first enters a pass code. After 1836 successfully entering the pass code, an announcement prompts Alice to 1837 speak her name so it can be recorded. When Alice is added to the 1838 active conference, the recording is played back to all the existing 1839 participants. A very similar example is presented in Figure 33 of 1840 [I-D.ietf-mediactrl-call-flows]. 1842 CMCC "Alice" ConfS MS 1843 | | | 1844 |(1)userRequest(confObjID, | | 1845 | create,userInfo) | | 1846 |--------------------------->| | 1847 | |--+ Alice is | 1848 | | | new in the | 1849 | |<-+ system (create | 1850 | | confUserID) | 1851 | ConfS handles +--| | 1852 | SIP signaling | | | 1853 | (Alice<->ConfS<->MS) +->| | 1854 | | | 1855 | |--+ A password is | 1856 | | | required for | 1857 | |<-+ that conference | 1858 | | | 1859 | | Request IVR menu (PIN) | 1860 | |--------------------------->| 1861 | | | 1862 |<========= MS gets PIN from Alice through DTMF =========>| 1863 | | | 1864 | | Provided PIN is... | 1865 | |<---------------------------| 1866 | Check +--| | 1867 | PIN | | | 1868 | +->| | 1869 | |--+ Alice must | 1870 | | | record her | 1871 | |<-+ name | 1872 | | | 1873 | | Request name recording | 1874 | |--------------------------->| 1875 | | | 1876 |<========= MS records Alice's audio RTP (name) =========>| 1877 | | | 1878 | | Audio recording | 1879 | |<---------------------------| 1880 | Complete +--| | 1881 | creation | | | 1882 | of Alice +->| | 1883 | | | 1884 | | | 1885 | (2)userResponse(confUserID,| | 1886 | confObjID, create, | | 1887 | success, version) | | 1888 |<---------------------------| | 1889 | | | 1890 Figure 17: Recording and Announcements 1892 1. Upon receipt of the userRequest from Alice to be added to Bob's 1893 conference, the conferencing system determines that a password is 1894 required for this specific conference. Thus an announcement 1895 asking Alice to enter the password is sent back. This may be 1896 achieved by means of typical IVR functionality. Once Alice 1897 enters the password, it is validated against the policies 1898 associated with Bob's active conference. The conferencing system 1899 then connects to a server which prompts and records Alice's name. 1900 The conferencing system must also determine whether Alice is 1901 already a user of this conferencing system or whether she is a 1902 new user. In this case, Alice is a new user for this 1903 conferencing system, so a Conference User Identifier (i. e. an 1904 XCON-USERID) is created for Alice. Based upon the contact 1905 information provided by Alice, the call signaling to add Alice to 1906 the conference is instigated through the Focus. 1908 2. The conference server sends Alice a userResponse message which 1909 includes the "confUserID" assigned by the conferencing system to 1910 her. This would allow Alice to later perform operations on the 1911 conference (if she were to have the appropriate policies), 1912 including registering for event notifications associated with the 1913 conference. Once the call signaling indicates that Alice has 1914 been successfully added to the specific conference, per updates 1915 to the state, and depending upon the policies, other participants 1916 (e.g., Bob) are notified of the addition of Alice to the 1917 conference via the conference notification service and an 1918 announcement is provided to all the participants indicating that 1919 Alice has joined the conference. 1921 1. userRequest/create message (Alice - a new conferencing system 1922 client - enters Bob's conference) 1924 1925 1929 1931 xcon:bobConf@example.com 1932 create 1933 1934 1935 1936 1937 1938 mailto:Alice83@example.com 1939 1940 email 1941 1942 1943 1944 1945 1946 1947 1949 2.userResponse/create ("success": Alice is provided with a new 1950 xcon-userid and is added to the conference) 1952 1953 1957 1959 xcon-userid:Alice@example.com 1960 xcon:bobConf@example.com 1961 create 1962 success 1963 5 1964 1965 1966 1967 Figure 18: Announcement Messaging Details 1969 7.4. Monitoring for DTMF 1971 Conferencing systems often also need the capability to monitor for 1972 DTMF from each individual participant. This would typically be used 1973 to enter the identifier and/or access code for joining a specific 1974 conference. This feature is often also exploited to achieve 1975 interaction between participants and the conference system for non- 1976 XCON-aware user agents (e.g. using DTMF tones to get muted/unmuted). 1978 An example of DTMF monitoring, within the context of the framework 1979 elements, is shown in Figure 17. A typical way for the conferencing 1980 system to be aware of all the DTMF interactions within the context of 1981 conferences it is responsible for, is making use of the MEDIACTRL 1982 architecture for what regards media manipulation. Examples in that 1983 sense (specifically for what concerns DTMF interception in conference 1984 instances) are presented in [I-D.ietf-mediactrl-call-flows]. 1986 7.5. Entering a password-protected conference 1988 Some conferences may envision a password to be provided by a user who 1989 wants to manipulate the relative conference objects (e.g. join, 1990 update, delete) via CCMP. Such a password would be included in the 1991 element related to the conference XCON-URI in 1992 the appropriate entry and must be then included in 1993 the apposite "conference-password" field in the CCMP request 1994 addressed to that conference. 1996 In the following CCMP transactions, it is depicted a scenario in 1997 which Alice, a conferencing system client, attempts to join a 1998 password-protected conference. 2000 1. Alice sends a userRequest message with a "create" operation to 2001 add herself in the conference with XCON-URI 2002 "xcon:8977777@example.com" (written in the "confObjID" 2003 parameter). Alice provides her XCON-USERID via the "confUserID" 2004 field of the userRequest and leaves out the "userInfo" one 2005 (first-party join). In this first attempt, she doesn't insert 2006 any password parameter. 2008 2. Upon receipt the userRequest/create message, the conferencing 2009 server detects that the indicated conference is not joinable 2010 without providing the relative pass code. Then a userResponse 2011 message with "confPasswordRequired" response-code is returned to 2012 Alice to indicate that her join has been refused and that she has 2013 to recast her request including the appropriate conference 2014 password in order to participate. 2016 3. After getting the pass code through out-of-band mechanisms, Alice 2017 provides it in the proper "password" request field of a new 2018 userRequest/create message and sends the updated request back to 2019 the server. 2021 4. The conferencing server checks the provided password and then 2022 adds Alice to the protected conference. After that, a 2023 userResponse with a "success" response-code is sent to Alice. 2025 1. userRequest/create message (Alice tries to enter the conference 2026 without providing the password) 2028 2029 2033 2035 xcon-userid:Alice@example.com 2036 xcon:8977794@example.com 2037 create 2038 2039 2040 2042 2. userResponse/create message ("passwordRequired") 2044 2045 2049 2051 xcon-userid:Alice@example.com 2052 xcon:8977794@example.com 2053 create 2054 confPasswordRequired 2055 2056 2057 2059 3. userRequest/create message (Alice provides the password) 2060 2061 2065 2067 xcon-userid:Alice@example.com 2068 xcon:8977794@example.com 2069 create 2070 8601 2071 2072 2073 2075 4. userResponse/create message ("success") 2077 2078 2082 2084 xcon-userid:Alice@example.com 2085 xcon:8977794@example.com 2086 create 2087 success 2088 10 2089 2090 2091 2093 Figure 19: Password-protected conference join messages details 2095 8. Sidebars Scenarios and Examples 2097 While creating conferences and manipulating users and their media may 2098 be considered enough for many scenarios, there may be cases when a 2099 more complex management is needed. 2101 In fact, a feature typically required in conferencing systems is the 2102 ability to create sidebars. A sidebar is basically a child 2103 conference that usually includes a subset of the participants of the 2104 parent conference, and a subset of its media as well. Sidebars are 2105 typically required whenever some of the participants in a conference 2106 want to discuss privately about something, without interfering with 2107 the main conference. 2109 This section deals with some scenarios that typically envisage the 2110 use of a sidebar, like whispering, private messages and coaching 2111 scenarios. The first subsections, anyway, present some examples of 2112 how a generic sidebar can be created, configured and managed. 2114 8.1. Internal Sidebar 2116 Figure 20 provides an example of one client, "Alice", involved in an 2117 active conference with "Bob" and "Carol". Alice wants to create a 2118 sidebar to have a side discussion with Bob while still viewing the 2119 video associated with the main conference. Alternatively, the audio 2120 from the main conference could be maintained at a reduced volume. 2121 Alice initiates the sidebar by sending a request to the conferencing 2122 system to create a conference reservation based upon the active 2123 conference object. Alice and Bob would remain on the roster of the 2124 main conference, such that other participants could be aware of their 2125 participation in the main conference, while an internal-sidebar 2126 conference is occurring. Besides, Bob decides that he is not 2127 interested in still receiving the conference audio in background (not 2128 even at a lower volume as Alice configured) and so modifies the 2129 sidebar in order to make that stream inactive for him. 2131 Alice Bob ConfS 2132 | | | 2133 |(1) sidebarByValRequest(confUserID, | 2134 | confObjID,create) | 2135 |--------------------------------------------->| 2136 | | | 2137 | | (a) Create +---| 2138 | | sidebar-by-val | | 2139 | | (new conf obj | | 2140 | | cloned from +-->| 2141 | | confObjID) | Sidebar now has 2142 | | | id confObjID* 2143 |(2) sidebarByValResponse(confUserID, | (parent mapping 2144 | (confObjID*, create, success, | conf<->sidebar) 2145 | version, sidebarByValInfo) | 2146 |<---------------------------------------------| 2147 | | | 2148 |(3) sidebarByValRequest | 2149 | (confUserID, confObjID*, | 2150 | update,sidebarByValInfo) | 2151 |--------------------------------------------->| 2152 | | | 2153 | | (b) Update +---| 2154 | | sidebar-by-val | | 2155 | | (media, users | | 2156 | | etc.) +-->| 2157 | | | Sidebar is 2158 | | | modified 2159 |(4) sidebarByValResponse(confUserID, | 2160 | confObjID*, update, | 2161 | success, version) | 2162 |<---------------------------------------------| 2163 | | | 2164 | |(5) userRequest | 2165 | | (confUserID', | 2166 | | confObjID*, | 2167 | | update,userInfo)| 2168 | |---------------------->| 2169 | | | 2170 | | (c) Update +---| 2171 | | user settings | | 2172 | | (Bob's media) | | 2173 | | +-->| 2174 | | | Sidebar is modified 2175 | | | (original audio 2176 | | | inactive for Bob) 2177 | |(6) userResponse | 2178 | | (confUserID', | 2179 | | confObjID*,update| 2180 | | success,version) | 2181 | |<----------------------| 2182 | | | 2183 " " " 2184 " " " 2185 " " " 2187 Figure 20: Client Creation of a Sidebar Conference 2189 1. Upon receipt of CCMP sidebarByValRequest message to create a new 2190 sidebar-conference based upon the confObjID received in the 2191 request, the conferencing system uses the confObjID to clone a 2192 conference reservation for the sidebar. The sidebar reservation 2193 is NOT independent of the active conference (i.e., parent). The 2194 conferencing system also allocates a new XCON-URI for that 2195 sidebar to be used for any subsequent protocol requests from any 2196 of the members of the conference. The new sidebar identifier 2197 ("confObjID*" in Figure 20) is returned in the response message 2198 confObjID parameter. 2200 2. The relationship information is provided in the 2201 sidebarByValResponse message, specifically in the element. A dump of the complete representation of the 2203 main/parent conference is provided below as well to show how the 2204 cloning process for the creation of the sidebar could take place. 2206 3. Upon receipt of the sidebarByValResponse message to reserve the 2207 conference, Alice can now create an active conference using that 2208 reservation, or create additional reservations based upon the 2209 existing reservations. In this example, Alice wants only Bob to 2210 be involved in the sidebar, thus she manipulates the membership 2211 so that only the two of them appear in the 2212 section. Alice also wants both audio and video from the original 2213 conference to be available in the sidebar. For what concerns the 2214 media belonging to the sidebar itself, Alice wants the audio to 2215 be restricted to the participants in the sidebar (that is, Bob 2216 and herself). Additionally, Alice manipulates the media values 2217 to receive the audio from the main conference at a reduced 2218 volume, so that the communication between her and Bob isn't 2219 affected. Alice sends a sidebarByValRequest message with an 2220 operation of "update" along with the "sidebarByValInfo" 2221 containing the aforementioned sidebar modifications. 2223 4. Upon receipt of the sidebarByValRequest to update the sidebar 2224 reservation, the conference server ensures that Alice has the 2225 appropriate authority based on the policies associated with that 2226 specific conference object to perform the operation. The 2227 conference server must also validate the updated information in 2228 the reservation, ensuring that a member like Bob is already a 2229 user of this conference server. Once the data for the confObjID 2230 is updated, the conference server sends a sidebarByValResponse to 2231 Alice. Depending upon the policies, the initiator of the request 2232 (i.e., Alice) and the participants in the sidebar (i.e., Bob) may 2233 be notified of his addition to the sidebar via the conference 2234 notification service. 2236 5. At this point, Bob sends a userRequest message to the conference 2237 server with an operation of "update" to completely disable the 2238 background audio from the parent conference, since it prevents 2239 him from understanding what Alice says in the sidebar. 2241 6. Notice that Bob's request only changes the media perspective for 2242 Bob. Alice keeps on receiving both the audio from Bob and the 2243 background from the parent conference. This request may be 2244 relayed by the conference server to the Media Server handling the 2245 mixing, if present. Upon completion of the change, the 2246 conference server sends a "userResponse" message to Bob. 2247 Depending upon the policies, the initiator of the request (i.e., 2248 Bob) and the participants in the sidebar (i.e., Alice) may be 2249 notified of this change via the conference notification service. 2251 That said, let's consider the following conference object: 2253 2254 2259 2260 MAIN CONFERENCE 2261 2262 2263 sip:8977878@example.com 2264 conference sip uri 2265 2266 2267 2268 2269 main conference audio 2270 audio 2271 sendrecv 2272 2273 2274 main conference video 2275 video 2276 sendrecv 2277 2278 single-view 2279 2280 2281 2282 2283 2284 true 2285 2286 2287 2288 Alice 2289 2290 2291 123 2292 sendrecv 2293 2294 2295 456 2296 sendrecv 2297 2298 2299 2300 2301 Bob 2302 2303 2304 123 2305 sendrecv 2306 2307 2308 456 2309 sendrecv 2310 2311 2312 2313 2314 Carol 2315 2316 2317 123 2318 sendrecv 2319 2320 2321 456 2322 sendrecv 2323 2324 2325 2326 2327 2329 Figure 21: Conference with Alice, Bob and Carol 2331 This is the representation of the conference the sidebar is going to 2332 be created in. As such, it will be used by the conferencing system 2333 in order to create the new conference object associated with the 2334 sidebar. In fact, the sidebar creation happens through a cloning of 2335 the parent conference. Once the sidebar is created, an "update" 2336 makes sure that the sidebar is customized as needed. The following 2337 protocol dump makes the process clearer. 2339 1. sidebarByValRequest/create message (Alice creates an 2340 internal sidebar) 2342 2343 2346 2348 xcon-userid:Alice@example.com 2349 xcon:8977878@example.com 2350 create 2351 2352 2353 2355 2. sidebarByValResponse/create message ("success", sidebar returned) 2357 2358 2362 2364 xcon-userid:Alice@example.com 2365 xcon:8974545@example.com 2366 create 2367 success 2368 1 2369 2370 2371 2372 2373 SIDEBAR CONFERENCE registered by Alice 2374 2375 2376 xcon:8977878@example.com 2377 2378 2379 2380 2381 main conference audio 2382 2383 audio 2384 sendrecv 2385 2386 2387 2388 main conference video 2389 2390 video 2391 sendrecv 2392 2393 2394 2395 2396 false 2397 2398 2399 2400 2402 2404 2406 2407 2408 2409 2410 2411 2413 3. sidebarByValRequest/update message (Alice updates the 2414 created sidebar) 2416 2417 2421 2423 xcon-userid:Alice@example.com 2424 xcon:8974545@example.com 2425 update 2426 2427 2428 2429 2430 private sidebar Alice - Bob 2431 2432 2433 2434 2435 main conference audio 2436 2437 audio 2438 recvonly 2439 2440 -60 2441 2442 2443 2444 2445 main conference video 2446 2447 video 2448 recvonly 2449 2450 2451 2452 sidebar audio 2453 2454 audio 2455 sendrecv 2456 2457 2458 2459 sidebar video 2460 2461 video 2462 sendrecv 2463 2464 2465 2466 2467 2468 2470 2472 2473 2474 2475 2476 2477 2479 4. sidebarByValResponse/update message ("success", sidebar's 2480 updates accepted) 2482 2483 2487 2489 xcon-userid:Alice@example.com 2490 xcon:8974545@example.com 2491 update 2492 success 2493 2 2494 2495 2496 2498 5. userRequest/update message (Bob updates his media) 2500 2501 2505 2507 xcon-userid:Bob@example.com 2508 xcon:8974545@example.com 2509 update 2510 2511 2512 2513 2514 2515 main conference audio 2516 2517 123 2518 inactive 2519 2520 2521 2522 2523 2524 2525 6. userResponse/update message ("success", Bob's preferences setted) 2527 2528 2531 2533 xcon-userid:Bob@example.com 2534 xcon:8974545@example.com 2535 update 2536 success 2537 3 2538 2539 2540 2542 Figure 22: Internal Sidebar Messaging Details 2544 8.2. External Sidebar 2546 Figure 23 provides an example of a different approach towards 2547 sidebar. In this scenario, one client, "Alice", is involved in an 2548 active conference with "Bob", "Carol", "David" and "Ethel". Alice 2549 gets an important text message via a whisper from Bob that a critical 2550 customer needs to talk to Alice, Bob and Ethel. Alice creates a 2551 sidebar to have a side discussion with the customer "Fred" including 2552 the participants in the current conference with the exception of 2553 Carol and David, who remain in the active conference. The difference 2554 from the previous scenario is that Fred is not part of the parent 2555 conference: this means that different policies might be involved, 2556 considering that Fred may access information coming from the parent 2557 conference, in case the sidebar was configured accordingly. For this 2558 reason, in this scenario we assume that Alice disables all the media 2559 from the original (parent) conference within the sidebar. This means 2560 that, while in the previous example Alice and Bob still heard the 2561 audio from the main conference in background, this time no background 2562 is made available. Alice initiates the sidebar by sending a request 2563 to the conferencing system to create a conference reservation based 2564 upon the active conference object. Alice, Bob and Ethel would remain 2565 on the roster of the main conference in a hold state. Whether or not 2566 the hold state of these participants is visible to other participants 2567 depends upon the individual and local policy. 2569 Alice Bob ConfS 2570 | | | 2571 |(1) sidebarByRefRequest(confUserID, | 2572 | confObjID, create) | 2573 |--------------------------------------------->| 2574 | | | 2575 | | (a) Create +---| 2576 | | sidebar-by-ref | | 2577 | | (new conf obj | | 2578 | | cloned from +-->| 2579 | | confObjID) | Sidebar now has 2580 | | | id confObjID* 2581 |(2) sidebarByRefResponse(confUserID, | (parent mapping 2582 | confObjID*, create, success, | conf<->sidebar) 2583 | version, sidebarByRefInfo) | 2584 |<---------------------------------------------| 2585 | | | 2586 |(3) sidebarByRefRequest(confUserID, | 2587 | confObjID*,update,sidebarByRefInfo) | 2588 |--------------------------------------------->| 2589 | | | 2590 | | (b) Create +---| 2591 | | new user for | | 2592 | | Fred | | 2593 | | +-->| 2594 | | | 2595 | | (c) Update +---| 2596 | | sidebar-by-ref | | 2597 | | (media, users | | 2598 | | policy, etc.) +-->| 2599 | | | Sidebar is modified: 2600 | | | no media from the 2601 | | | parent conference is 2602 | | | available to anyone 2603 |(4) sidebarByRefResponse(confUserID, | 2604 | confObjID*, update, | 2605 | success, version) | 2606 |<---------------------------------------------| 2607 | | | 2608 | | Notify (Fred | 2609 | | added to | 2610 | | sidebar users) | 2611 | |<----------------------| 2612 | | | 2613 " " " 2614 " " " 2615 " " " 2616 Figure 23: Client Creation of an External Sidebar 2618 1. Upon receipt of the "sidebarByRefRequest" message to create a new 2619 sidebar conference, based upon the active conference specified by 2620 "confObjID" in the request, the conferencing system uses that 2621 active conference to clone a conference reservation for the 2622 sidebar. The sidebar reservation is NOT independent of the 2623 active conference (i.e., parent). The conferencing system, as 2624 before, allocates a conference ID (confObjID*) to be used for any 2625 subsequent protocol requests toward the sidebar reservation. The 2626 mapping between the sidebar conference ID and the one associated 2627 with the main conference is mantained by the conferencing system 2628 and it is gathered from the c element in the 2629 sidebar conference object. 2631 2. Upon receipt of the "sidebarByRefResponse" message, which 2632 acknowledges the successful creation of the sidebar object, Alice 2633 decides that only Bob and Ethel, along with the new participant 2634 Fred are to be involved in the sidebar. Thus she manipulates the 2635 membership accordingly. Alice also sets the media in the 2636 "conference-info" such that the participants in the sidebar don't 2637 receive any media from the main conference. All these settings 2638 are provided to the conferencing system by means of a new 2639 "sidebarByRefRequest" message, with an "update" operation. 2641 3. Alice sends the aforementioned "sidebarByRefRequest" to update 2642 the information in the reservation and to create an active 2643 conference. Upon receipt of the "sidebarByRefRequest" with an 2644 operation of "update", the conferencing system ensures that Alice 2645 has the appropriate authority based on the policies associated 2646 with that specific conference object to perform the operation. 2647 The conferencing system also validates the updated information in 2648 the reservation. Since Fred is a new user for this conferencing 2649 system, a conference user identifier is created for Fred. 2650 Specifically, Fred is added to the conference by only providing 2651 his SIP URI. Based upon the contact information provided for 2652 Fred by Alice, the call signaling to add Fred to the conference 2653 may be instigated through the Focus (e.g. if Fred had a "dial- 2654 out" method set as the target for him) at the actual activation 2655 of the sidebar. 2657 4. The conference server sends a "sidebarByRefResponse" message and, 2658 depending upon the policies, the initiator of the request (i.e., 2659 Alice) and the participants in the sidebar (i.e., Bob and Ethel) 2660 may be notified of his addition to the sidebar via the conference 2661 notification service. 2663 1. sidebarByRefRequest/create message (Alice creates an 2664 external sidebar) 2666 2667 2670 2672 xcon-userid:Alice@example.com 2673 xcon:8977878@example.com 2674 create 2675 2676 2677 2679 2. sidebarByRefResponse/create message ("success", created 2680 sidebar returned) 2682 2683 2687 2689 xcon-userid:Alice@example.com 2690 xcon:8971212@example.com 2691 create 2692 success 2693 1 2694 2695 2696 2697 2698 SIDEBAR CONFERENCE registered by Alice 2699 2700 2701 xcon:8977878@example.com 2702 2703 2704 2705 2706 main conference audio 2707 2708 audio 2709 sendrecv 2710 2711 2712 2713 main conference video 2714 2715 video 2716 sendrecv 2717 2718 2719 2720 2721 false 2722 2723 2724 2725 2727 2729 2731 2733 2735 2736 2737 2738 2739 2740 2742 3. sidebarByRefRequest/update message (Alice updates the sidebar) 2744 2748 2750 xcon-userid:Alice@example.com 2751 xcon:8971212@example.com 2752 update 2753 2754 2755 2756 2757 sidebar with Alice, Bob, Ethel & Fred 2758 2759 2760 2761 2762 main conference audio 2763 2764 audio 2765 inactive 2766 2767 2768 2769 main conference video 2770 2771 video 2772 inactive 2773 2774 2775 2776 sidebar audio 2777 2778 audio 2779 sendrecv 2780 2781 2782 2783 sidebar video 2784 2785 video 2786 sendrecv 2787 2788 2789 single-view 2790 2791 2792 2793 2794 2795 2796 false 2797 2798 2799 2800 2802 2805 2807 2808 2809 2810 2811 2812 2814 4. sidebarByRefResponse/update message ("success", sidebar updated) 2816 2820 2822 xcon-userid:Alice@example.com 2823 xcon:8971212@example.com 2824 update 2825 success 2826 2 2827 2828 2829 2831 Figure 24: External Sidebar Messaging Details 2833 8.3. Private Messages 2835 The case of private messages can be handled as a sidebar with just 2836 two participants, similarly to the example in Section 8.1. Unlike 2837 the previous example, rather than using audio within the sidebar, 2838 Alice could just add an additional text based media stream to the 2839 sidebar in order to convey her textual messages to Bob, while still 2840 viewing and listening to the main conference. 2842 In this scenario, Alice requests to the conferencing system the 2843 creation of a private chat room within the main conference context 2844 (presented in Figure 21) in which the involved partecipants are just 2845 Bob and herself. This can be achieved through the following CCMP 2846 transaction (Figure 25). 2848 1. Alice forwards a sidebarByValRequest/create to the Conferencing 2849 Control Server with the main conference XCON-URI in the 2850 "confObjID" parameter and the desired sidebar conference object 2851 in the "sidebarByValInfo" field. In this way, a sidebar creation 2852 using user-provided conference information is requested to the 2853 conferencing system. Please note that, unlike the previous 2854 sidebar examples, in this case a comnpletely new conference 2855 object to describe the sidebar is provided: there is no cloning 2856 involved, while the "confObjID" still enforces the parent-child 2857 relationship between the main conference and the to-be-created 2858 sidebar. 2860 2. The Conference Control Server, after checking Alice's rights and 2861 validating the conference-object carried in the request, creates 2862 the required sidebar-by-val conference and a new XCON-URI for it. 2863 Instead of cloning the main conference object, as envisioned in 2864 Section 8.1 and Section 8.2, the sidebar is created on the basis 2865 of the user provided conference information (as anticipated 2866 before). However, the parent relationship between the main 2867 conference and the newly created sidebar is still mantained by 2868 the conferencing system (as a consequence of the chosen CCMP 2869 request message type - the sidebarByVal one) and it is reflected 2870 by the element in the "sidebarByValInfo" element 2871 returned in the sidebarByValResponse message. Please notice 2872 that, according to the CCMP specification, the return of the 2873 created sidebar data in this kind of "success" response is not 2874 mandatory. 2876 1. sidebarByValRequest/create message (Alice creates a private 2877 chat room between Bob and herself) 2879 2880 2884 2886 xcon-userid:Alice@example.com 2887 xcon:8977878@example.com 2888 create 2889 2890 2891 2892 2893 private textual sidebar alice - bob 2894 2895 2896 2897 2898 main conference audio 2899 2900 audio 2901 recvonly 2902 2903 2904 2905 main conference video 2906 2907 video 2908 recvonly 2909 2910 2911 2912 sidebar text 2913 2914 text 2915 sendrecv 2916 2917 2918 2919 2920 2921 2923 2925 2926 2927 2928 2929 2930 2932 2. sidebarByValResponse/create message ("success", sidebar returned) 2934 2935 2939 2941 xcon-userid:Alice@example.com 2942 xcon:8974545@example.com 2943 create 2944 success 2945 1 2946 2947 2948 2949 2950 private textual sidebar alice - bob 2951 2952 2953 xcon:8977878@example.com 2954 2955 2956 2957 2958 main conference audio 2959 2960 audio 2961 recvonly 2962 2963 2964 2965 main conference video 2966 2967 video 2968 recvonly 2969 2970 2971 2972 sidebar text 2973 2974 text 2975 sendrecv 2976 2977 2978 2979 2980 2981 2983 2985 2986 2987 2988 2989 2990 2991 Figure 25: Sidebar for Private Messages scenario 2993 8.4. Observing and Coaching 2995 Observing and Coaching is one of the most interesting sidebars- 2996 related scenarios. In fact, it envisages two different interactions 2997 that have to be properly coordinated. 2999 An example of observing and coaching is shown in figure Figure 27. 3000 In this example, call center agent Bob is involved in a conference 3001 with customer Carol. Since Bob is a new agent and Alice sees that he 3002 has been on the call with Carol for longer than normal, she decides 3003 to observe the call and coach Bob as necessary. Of course the 3004 conferencing system must make sure that the customer Carol is not 3005 aware of the presence of the coach Alice. This makes the use of a 3006 sidebar necessary for the success of the scenario. 3008 Consider the following as the conference document associated with the 3009 video conference involving Bob (the call agent) and Carol (the 3010 customer) (Figure 26): 3012 3013 3018 3019 3020 CUSTOMER SERVICE conference 3021 3022 3023 3024 sip:8978383@example.com 3025 conference sip uri 3026 3027 3028 3029 3030 service audio 3031 audio 3032 sendrecv 3033 3034 3035 service video 3036 video 3037 sendrecv 3038 3039 single-view 3040 3041 3042 3043 3044 3045 true 3046 3047 3048 3049 Bob - call agent 3050 3051 3052 123 3053 sendrecv 3054 3055 3056 456 3057 sendrecv 3058 3059 3060 3061 3062 Carol - customer 3063 3064 3065 123 3066 sendrecv 3067 3068 3069 456 3070 sendrecv 3071 3072 3073 3074 3075 3077 Figure 26: A call-center conference object example 3079 Alice Bob ConfS 3080 | | | 3081 |(1) sidebarByRefRequest(confUserID, | 3082 | confObjID, create) | 3083 |--------------------------------------------->| 3084 | | | 3085 | | (a) Create +---| 3086 | | sidebar-by-ref | | 3087 | | (new conf obj | | 3088 | | cloned from +-->| 3089 | | confObjID) | Sidebar now has 3090 | | | id confObjID* 3091 |(2) sidebarByRefResponse(confUserID, | (parent mapping 3092 | confObjID*, create, success, | conf<->sidebar) 3093 | version, sidebarByRefInfo) | 3094 |<---------------------------------------------| 3095 | | | 3096 |(3) sidebarByRefRequest(confUserID, | 3097 | confObjID*,update,sidebarByRefInfo) | 3098 |--------------------------------------------->| 3099 | | | 3100 | | (b) Update +---| 3101 | | sidebar-by-val | | 3102 | | (media, users | | 3103 | | policy, etc.) +-->| 3104 | | | Sidebar is modified: 3105 | | | unilateral sidebar 3106 | | | audio, Carol excluded 3107 | | | from the sidebar 3108 |(4) sidebarByRefResponse(confUserID, | 3109 | confObjID*, update, | 3110 | success, version) | 3111 |<---------------------------------------------| 3112 | | | 3113 | | Notify (Bob | 3114 | | he's been added to | 3115 | | sidebar users) | 3116 | |<----------------------| 3117 | | | 3118 " " " 3119 " " " 3120 " " " 3122 Figure 27: Supervisor Creating a Sidebar for Observing/Coaching 3124 1. Upon receipt of the sidbarByRefRequest/create from Alice to 3125 "create" a new sidebar conference from the confObjID received in 3126 the request, the conferencing system uses the received active 3127 conference to clone a conference reservation for the sidebar. 3128 The conferencing system also allocates a conference ID to be used 3129 for any subsequent protocol requests from any of the members of 3130 the conference. The conferencing system maintains the mapping 3131 between this conference ID and the confObjID associated with the 3132 sidebar reservation through the conference instance. The 3133 conference server sends a sidebarByRefResponse message with the 3134 new confObjID and relevant sidebarByRefInfo. 3136 2. Upon receipt of the sidebarByRefResponse message, Alice 3137 manipulates the data received in the sidebarByRefInfo in the 3138 response. Alice wants only Bob to be involved in the sidebar, 3139 thus she updates the to include only Bob and 3140 herself. Alice also wants the audio to be received by herself 3141 and Bob from the original conference, but wants any outgoing 3142 audio from herself to be restricted to the participants in the 3143 sidebar, whereas Bob's outgoing audio should go to the main 3144 conference, so that both Alice and the customer Carol hear the 3145 same audio from Bob. Alice sends a sidebarByRefRequest message 3146 with an "update" operation including the updated sidebar 3147 information. 3149 3. Upon receipt of the sidebarByRefRequest message with an "update" 3150 operation, the conferencing system ensures that Alice has the 3151 appropriate authority based on the policies associated with that 3152 specific conference object to perform the operation. In order to 3153 request the insertion of a further media stream in the sidebar 3154 (i.e. in this example an audio stream from Alice to Bob), the 3155 requestor has to provide a new element in the field of the "sidebarByRefInfo". The mandatory "label" 3157 attribute of that new entry is filled with a dummy value 3158 "AUTO_GENERATE_1", but it will contain the real server-generated 3159 media stream identifier when the media stream is effectively 3160 allocated on the server side. Similarly, the mandatory "id" 3161 attribute in element referring to the new sidebar audio 3162 stream under both Alice's and Bob's contains a 3163 wildcard value, respectively "AUTO_GENERATE_2" and 3164 "AUTO_GENERATE_3": those values will be replaced with the 3165 appropriated server-generated identifiers upon the creation of 3166 the referred media stream. We are assuming the conferencing 3167 control server is able to recognize those dummy values as place- 3168 holders. 3170 4. After validating the data, the conference server sends a 3171 sidebarByRefResponse message. Based upon the contact information 3172 provided for Bob by Alice, the call signaling to add Bob to the 3173 sidebar with the appropriate media characteristics is instigated 3174 through the Focus. Bob is notified of his addition to the 3175 sidebar via the conference notification service, thus he is aware 3176 that Alice, the supervisor, is available for coaching him through 3177 this call. 3179 1. sidebarByRefRequest/create message (Alice as coach creates a sidebar) 3181 3182 3185 3187 xcon-userid:Alice@example.com 3188 xcon:8978383@example.com 3189 create 3190 3191 3192 3194 2. sidebarByRefResponse/create message ("success") 3196 3197 3201 3203 xcon-userid:alice@example.com 3204 xcon:8971313@example.com 3205 create 3206 success 3207 1 3208 3209 3210 3211 3212 SIDEBAR CONFERENCE registered by alice 3213 3214 3215 xcon:8971313@example.com 3216 3217 3218 3219 3220 main conference audio 3221 3222 audio 3223 sendrecv 3224 3225 3226 3227 main conference video 3228 3229 video 3230 sendrecv 3231 3232 3233 3234 3235 false 3236 3237 3238 3239 3241 3243 3245 3246 3247 3248 3249 3250 3252 3. sidebarByRefRequest/update message (Alice introduces unilateral 3253 sidebar audio and excludes Carol from the sidebar) 3255 3259 3261 xcon-userid:alice@example.com 3262 xcon:8971313@example.com 3263 update 3264 3265 3266 3267 3268 Coaching sidebar Alice and Bob 3269 3270 3271 3272 3273 Alice-to-Bob audio 3274 3275 audio 3276 sendrecv 3277 3278 3279 3280 3281 false 3282 3283 3284 3285 3287 3289 3290 3292 3293 AUTO_GENERATE_1 3294 sendonly 3295 3296 3297 3298 3300 3301 AUTO_GENERATE_1 3302 recvonly 3303 3304 3305 3306 3307 3308 3309 3310 3312 4. sidebarByRefRequest/update message ("success") 3313 3314 3318 3320 xcon-userid:alice@example.com 3321 xcon:8971313@example.com 3322 update 3323 success 3324 2 3325 3326 3327 3329 Figure 28: Coaching and Observing Messaging details 3331 9. Removing Participants and Deleting Conferences 3333 The following scenarios detail the basic operations associated with 3334 removing participants from conferences and entirely deleting 3335 conferences. The examples assume that a conference has already been 3336 correctly established, with media, if applicable, per one of the 3337 examples in Section 6. 3339 9.1. Removing a Party 3341 Figure 29 provides an example of a client, "Alice", removing another 3342 participant, "Bob", from a conference. This example assumes an 3343 established conference with Alice, Bob, "Claire" and "Duck". In this 3344 example, Alice wants to remove Bob from the conference so that the 3345 group can continue in the same conference without Bob's 3346 participation. 3348 Alice Bob Claire ConfS 3349 | | | | 3350 |(1) userRequest(confUserID,| | 3351 | confObjID, delete,| | 3352 | userInfo) | | 3353 |-------------------------------------->| 3354 | | | | 3355 | | | (a) Focus | 3356 | | | tears down| 3357 | | | signaling | 3358 | | | to Bob | 3359 | |<----------------------| 3360 | | | 3361 | | (b)Deletes+---| 3362 | | | Bob | | 3363 | | | as a | | 3364 | | | user +-->| 3365 | | | in | 3366 | | | confObj | 3367 | | | | 3368 |(2) userResponse(confUserID,confObjID, | 3369 | delete,success,version) | 3370 |<--------------------------------------| 3371 | | | | 3372 | | | | 3373 | | | (c) Notify| 3374 | | | ("Bob just| 3375 | | | left") | 3376 | | |<----------| 3377 | | | | 3378 ' ' ' ' 3379 ' ' ' ' 3380 ' ' ' ' 3382 Figure 29: Client Manipulation of Conference - Remove a party 3384 1. Alice sends a userRequest message, with a "delete" operation. 3385 The conference server ensures that Alice has the appropriate 3386 authority based on the policies associated with that specific 3387 conference object to perform the operation. 3389 2. Based upon the contact and media information in the conference 3390 object for Bob in the "userInfo" element, the conferencing system 3391 starts the process to remove Bob (e.g., the call signaling to 3392 remove Bob from the conference is instigated through the Focus). 3393 The conference server updates the data in the conference object, 3394 thus removing Bob from the list. After updating the 3395 data, the conference server sends a userResponse message to 3396 Alice. Depending upon the policies, other participants (e.g. 3397 "Claire") may be notified of the removal of Bob from the 3398 conference via the Conference Notification Service. 3400 1. userRequest/delete message (Alice deletes Bob): 3402 3403 3407 3409 xcon-userid:Alice@example.com 3410 xcon:8977794@example.com 3411 delete 3412 3413 3414 3415 3416 3418 2. userResponse/delete message ("success") 3420 3421 3425 3427 xcon-userid:Alice@example.com 3428 xcon:8977794@example.com 3429 delete 3430 success 3431 17 3432 3433 3434 3436 Figure 30: Removing a Participant Messaging Details 3438 9.2. Deleting a Conference 3440 In this section, an example of a successful conference deletion is 3441 provided (Figure 31). 3443 Alice ConfS 3444 | | 3445 |(1)confRequest(confUserID, | 3446 | confObjID, delete) | 3447 |------------------------------>| 3448 | (a)Delete +---| 3449 | Conf | | 3450 | Object | | 3451 | +-->| 3452 | |--+ (b) MS 3453 | | | removes related 3454 | | | mixer instances and 3455 | |<-+ their participants 3456 | | (SIP signaling as well) 3457 | | 3458 |(2)confResponse(confUserID, | 3459 | confObjID,delete, | 3460 | success) | 3461 | | 3462 |<------------------------------| 3463 | | 3465 Figure 31: Deleting a conference 3467 1. The conferencing system client "Alice" sends a confRequest 3468 message with a "delete" operation to be performed on the 3469 conference identified by the XCON-URI carried in the "confObjID" 3470 parameter. The conference server, on the basis of the 3471 "confUserID" included in the receipt request, ensures that Alice 3472 has the appropriate authority to fulfill the operation. 3474 2. After validating Alice's rights, the conferencing server 3475 instigates the process to delete the conference object, 3476 disconnetting participants and removing associated resources such 3477 as mixer instances. Then, the conference server returns a 3478 confResponse message to Alice with "success" as "response-code" 3479 and the deleted conference XCON-URI in the "confObjID" field. 3481 1. confRequest/delete message (Alice deletes a conference) 3483 3484 3488 3490 xcon-userid:Alice@example.com 3491 xcon:8977794@example.com 3492 delete 3493 3494 3495 3497 2. confResponse/delete message ("success") 3499 3500 3504 3506 xcon-userid:Alice@example.com 3507 xcon:8977794@example.com 3508 delete 3509 success 3510 3511 3512 3514 Figure 32: Deleting a Conference Messaging Details 3516 10. IANA Considerations 3518 This document has no IANA considerations. 3520 11. Security Considerations 3522 The security considerations applicable to the implementation of these 3523 call flows is documented in the XCON Framework, with additional 3524 security considerations documented in the CCMP document. Where 3525 applicable, statements with regards to the necessary security are 3526 discussed in particular flows, however, since this is only an 3527 informational document, readers are strongly recommended to carefully 3528 consider the security considerations defined in the XCON Framework 3529 and the CCMP document. 3531 12. Change Summary 3533 NOTE TO THE RFC-EDITOR: Please remove this section prior to 3534 publication as an RFC. 3536 The following are the major changes between the 02 and the 03 3537 versions of the draft: 3539 o updated the call flows in order to take into account the changes 3540 on CCMP; 3542 o added a completely new introductory section, addressing the 3543 protocol in general, the data model constraints, transport-related 3544 information, and notifications in a practical way; 3546 o reorganized the chapters, grouping user-related scenarios in an 3547 users section, and doing the same for sidebars; 3549 o added more verbose text to almost every section of the document; 3551 The following are the major changes between the 01 and the 02 3552 versions of the draft: 3554 o updated the call flows in order to take into account the new 3555 versioning mechanism of the CCMP; 3557 o clarified, per agreement in Stockholm, that cloning from a 3558 blueprint does not need a cloning-parent to be made available in 3559 the response; 3561 o clarified that BFCP and CCMP-based media control are neither in 3562 conflict nor one the wrapper of the other; they act at different 3563 levels, and when both are involved, it is required that both grant 3564 a resource before it can be used by an interested participant; 3566 o changed all the domains involved in the flows to make them 3567 compliant with [RFC2606]; 3569 o clarified that a successful creation of a new conference object 3570 may or may not contain the whole confInfo object in the response; 3571 in case it doesn't, a retrieve of the updated object can be 3572 achieved by issuing a confRequest/retrieve; 3574 o clarified that the scenario in Section 7.3 only involves CCMP in 3575 adding the user to a conference; this includes requiring the use 3576 of a password only in adding the user to the conference object; 3577 the actual request for PIN/Password when joining thw conference is 3578 handled by means of out-of-band mechanisms (in this case at the 3579 media level, with the help of the MEDIACTRL framework); 3581 o added and corrected Sidebars-related scenarios; 3583 o added flows for some previously missing scenarios: Private 3584 Message/Whisper, Coaching Scenario, Removing a Party, Deleting a 3585 Conference; 3587 o 3589 The following are the major changes between the 00 and the 01 3590 versions of the draft: 3592 o Updates to reflect change of CCMP to HTTP transport model. 3594 The following are the major changes between the individual 01 version 3595 to the WG 00: 3597 o Updates to reflect most recent version of CCMP, including 3598 parameter names, etc. 3600 o Added protocol details to many of the examples. 3602 o Editorial: Simplifying intro, terms, etc. 3604 13. Acknowledgements 3606 The detailed content for this document is derived from the prototype 3607 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and 3608 their colleagues at the University of Napoli. 3610 14. References 3612 14.1. Normative References 3614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3615 Requirement Levels", BCP 14, RFC 2119, March 1997. 3617 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3618 Centralized Conferencing", RFC 5239, June 2008. 3620 [I-D.ietf-xcon-ccmp] 3621 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3622 "Centralized Conferencing Manipulation Protocol", 3623 draft-ietf-xcon-ccmp-05 (work in progress), December 2009. 3625 14.2. Informative References 3627 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 3628 Names", BCP 32, RFC 2606, June 1999. 3630 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3631 A., Peterson, J., Sparks, R., Handley, M., and E. 3632 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3633 June 2002. 3635 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3636 (SIP) Call Control - Conferencing for User Agents", 3637 BCP 119, RFC 4579, August 2006. 3639 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 3640 RFC 4597, August 2006. 3642 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 3643 Control Protocol (BFCP)", RFC 4582, November 2006. 3645 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 3646 Initiation Protocol (SIP) Event Package for Conference 3647 State", RFC 4575, August 2006. 3649 [I-D.ietf-xcon-event-package] 3650 Camarillo, G., Srinivasan, S., Even, R., and J. 3652 Urpalainen, "Conference Event Package Data Format 3653 Extension for Centralized Conferencing (XCON)", 3654 draft-ietf-xcon-event-package-01 (work in progress), 3655 September 2008. 3657 [I-D.ietf-xcon-common-data-model] 3658 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3659 "Conference Information Data Model for Centralized 3660 Conferencing (XCON)", draft-ietf-xcon-common-data-model-16 3661 (work in progress), February 2010. 3663 [I-D.ietf-mediactrl-call-flows] 3664 Amirante, A., Castaldi, T., Miniero, L., and S. Romano, 3665 "Media Control Channel Framework (CFW) Call Flow 3666 Examples", draft-ietf-mediactrl-call-flows-03 (work in 3667 progress), February 2010. 3669 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 3670 Server Control", RFC 5567, June 2009. 3672 [I-D.ietf-mediactrl-mixer-control-package] 3673 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 3674 Control Package for the Media Control Channel Framework", 3675 draft-ietf-mediactrl-mixer-control-package-10 (work in 3676 progress), January 2010. 3678 [I-D.boulton-xcon-session-chat] 3679 Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within 3680 a Centralized Conferencing (XCON) System", 3681 draft-boulton-xcon-session-chat-04 (work in progress), 3682 July 2009. 3684 Authors' Addresses 3686 Mary Barnes 3687 Nortel 3688 2201 Lakeside Blvd 3689 Richardson, TX 3691 Email: mary.barnes@nortel.com 3692 Lorenzo Miniero 3693 Meetecho 3694 Via Carlo Poerio 89/a 3695 Napoli 80121 3696 Italy 3698 Email: lorenzo@meetecho.com 3700 Roberta Presta 3701 University of Napoli 3702 Via Claudio 21 3703 Napoli 80125 3704 Italy 3706 Email: roberta.presta@unina.it 3708 Simon Pietro Romano 3709 University of Napoli 3710 Via Claudio 21 3711 Napoli 80125 3712 Italy 3714 Email: spromano@unina.it