idnits 2.17.1 draft-barnes-xcon-examples-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2009) is 5525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3264' is defined on line 1576, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 1580, but no explicit reference was found in the text == Unused Reference: 'RFC4574' is defined on line 1584, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1587, but no explicit reference was found in the text == Unused Reference: 'RFC5018' is defined on line 1601, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-event-package' is defined on line 1604, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-common-data-model' is defined on line 1611, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mediactrl-sip-control-framework' is defined on line 1629, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-mmusic-sdp-control-package-attribute' is defined on line 1635, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-ivr-control-package' is defined on line 1641, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-conference-control-package' is defined on line 1648, but no explicit reference was found in the text == Unused Reference: 'I-D.miniero-bfcp-control-package' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: 'RFC2810' is defined on line 1662, but no explicit reference was found in the text == Unused Reference: 'RFC3920' is defined on line 1665, but no explicit reference was found in the text == Unused Reference: 'RFC4353' is defined on line 1668, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 1672, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-simple-chat' is defined on line 1675, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-01 -- 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-12 == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-10 == Outdated reference: A later version (-07) exists of draft-boulton-mmusic-sdp-control-package-attribute-03 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-03 == Outdated reference: A later version (-08) exists of draft-boulton-xcon-session-chat-03 Summary: 1 error (**), 0 flaws (~~), 24 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Informational C. Boulton 5 Expires: September 11, 2009 NS-Technologies 6 L. Miniero 7 S P. Romano 8 University of Napoli 9 March 10, 2009 11 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 12 draft-barnes-xcon-examples-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 11, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document provides detailed call flows for the scenarios 51 documented in the Centralized Conferencing (XCON) Framework and the 52 XCON Scenarios. The call flows document the use of the interface 53 between a conference control client and a conference control server 54 using the Centralized Conferencing Manipulation Protocol (CCMP). The 55 objective is to provide a base reference for both protocol 56 researchers and developers. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Conference Creation . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Basic Conference Creation . . . . . . . . . . . . . . . . 6 66 5.2. Basic Conference Creation for a specific instance of 67 Conference Information . . . . . . . . . . . . . . . . . . 9 68 5.3. Basic Conference Creation - Cloning an existing 69 Conference . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.4. Conference Creation using Blueprints . . . . . . . . . . . 14 71 6. General Conference scenarios and examples . . . . . . . . . . 17 72 6.1. Conference Announcements and Recordings . . . . . . . . . 17 73 6.2. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 18 74 6.3. Adding a Party . . . . . . . . . . . . . . . . . . . . . . 19 75 6.4. Joining a Conference . . . . . . . . . . . . . . . . . . . 19 76 6.5. Muting a Party . . . . . . . . . . . . . . . . . . . . . . 20 77 6.6. Internal Sidebar . . . . . . . . . . . . . . . . . . . . . 21 78 6.7. External Sidebar . . . . . . . . . . . . . . . . . . . . . 23 79 6.8. Floor control using sidebars . . . . . . . . . . . . . . . 24 80 6.9. Whispering or Private Messages . . . . . . . . . . . . . . 25 81 6.10. Observing and Coaching . . . . . . . . . . . . . . . . . . 26 82 7. Removing participants and deleting conferences . . . . . . . . 28 83 7.1. Removing a Party . . . . . . . . . . . . . . . . . . . . . 28 84 7.2. Deleting a Conference . . . . . . . . . . . . . . . . . . 29 85 8. Additional Conference Scenarios and Examples . . . . . . . . . 29 86 8.1. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 8.1.1. Basic Chat Operations . . . . . . . . . . . . . . . . 30 88 8.1.2. Advanced Operations . . . . . . . . . . . . . . . . . 34 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 91 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 38 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 94 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38 95 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 98 1. Introduction 100 This document provides detailed call flows for the scenarios 101 documented in the Centralized Conferencing (XCON) Framework [RFC5239] 102 and the XCON Scenarios [RFC4597]. The XCON scenarios describe a 103 broad range of use cases taking advantage of the advanced 104 conferencing capabilities provided by a system realization of the 105 XCON framework. The call flows document the use of the interface 106 between a conference control client and a conference control server 107 using the Centralized Conferencing Manipulation Protocol 108 (CCMP)[I-D.ietf-xcon-ccmp]. 110 Due to the broad range of functionality provided by the XCON 111 Framework and the flexibility of the CCMP messaging, these call flows 112 should not be considered inclusive of all the functionality that can 113 provided by the XCON Framework and protocol implementations. These 114 flows represent a sample to provide an overview of the feature rich 115 capabilities of the XCON framework and CCMP messaging for protocol 116 developers, software developers and researchers. 118 2. Conventions 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 122 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 123 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 124 levels for compliant implementations. In this document, these key 125 words are used when describing normative functionality based on the 126 XCON Framework and CCMP. 128 Note that due to RFC formatting conventions, this document often 129 splits message details whose content would exceed 72 characters. A 130 backslash character marks where this line folding has taken place. 131 This backslash and its trailing CRLF and whitespace would not appear 132 in the actual protocol contents. 134 3. Terminology 136 This document uses the same terminology as found in the referenced 137 documents, with the following terms and abbreviations used in the 138 call flows. Also, note that the term "call flows" is used in a very 139 generic sense in this document since the media is not limited to 140 voice. The calls supported by the XCON framework and CCMP can 141 consist of media such as text, voice and video, including multiple 142 media types in a single active conference. 144 Conferencing and Media Client Client (CMCC): This client may be an 145 integral part of a User Agent Client (UAC) per [RFC3261]. In the 146 flows in this document, the CMCC is logically equivalent to the 147 use of UAC as the client notation in the media control call flows 148 [I-D.miniero-mediactrl-escs]. 150 Conferencing Server (ConfS): In this document, the conferencing 151 server is used interchangeably with the term Application Server 152 (AS) in the Media Control framework 153 [I-D.ietf-mediactrl-architecture] to simplify the call flows. 154 However, these need not be the same entities in an implementation. 156 Media Server (MS): Media Server. Per its definition in the Media 157 Control Architecture. 159 4. Overview 161 This document provides a sampling of detailed call flows that can be 162 implemented based on a system realization of [RFC5239] and 163 implementation of [I-D.ietf-xcon-ccmp]. This is intended to be a 164 simple guide on the use of the conference control protocol between 165 the Conference Server and the Conference Control Client. The 166 objective is to provide an information base reference for protocol 167 developers, software developers and researchers. 169 This document focuses on the interaction between the Conference (and 170 Media) Control Client and the Conferencing system, specifically the 171 Conference Server. The initial scenarios chosen are based on the 172 ones described in the XCON framework, many of which are based on the 173 advanced conferencing capabilities described in the XCON scenarios. 174 Additional scenarios have been added to provide examples of other 175 real life scenarios that are anticipated to be supported by the 176 framework and to document the conference control that complements the 177 Media Control Call Flows [I-D.miniero-mediactrl-escs] for 178 conferencing. 180 Rather than repeat the details associated with the media control, 181 this document references the media control call flow examples 182 [I-D.miniero-mediactrl-escs] by Figure title to aid the user in 183 finding the flows in that document. This approach was taken rather 184 than integrating the two documents due to dependencies in completing 185 working group items and because the messages for the two protocols 186 provide fairly discrete operations. In addition, the scenarios for 187 which floor control are used also do not include details of the 188 Binary Floor Control Protocol (BFCP) [RFC4582], but rather refer to 189 that document for further details for clients that also implement 190 BFCP for floor control. 192 5. Conference Creation 194 This section provides the details associated with the various ways in 195 which a conference can be created using CCMP and the XCON framework 196 constructs. As previously mentioned the details of the media control 197 and floor control protocols, where applicable, are annotated in the 198 flows without showing all the details. However, for clarification 199 purposes, the first example Section 5.1 provides the details of the 200 media control messaging along with an example of the standard 201 annotation used throughout the remainder of this document. In 202 subsequent flows, only this annotation (identified by lower case 203 letters) is included and the reader is encouraged to either refer 204 back to this first flow or to additional relevant flows in the media 205 control call flow document [I-D.miniero-mediactrl-escs] (e.g., for 206 IVR interactions, etc.). 208 The call signaling interactions for clients to join or be added to a 209 conference are also not shown, but rather annotated in a manner 210 similar to those for the media control messaging. The annotations 211 for the call signaling are on the left side of the conferencing 212 server vertical bar and those for the media control messaging are on 213 the right side. 215 The term conferencing server (ConfS) is shown in the diagrams in this 216 document as opposed to the more generic application server (AS) in 217 the media control flow document [I-D.miniero-mediactrl-escs]. Also, 218 note that the term conferencing and media control client (CMCC) in 219 these call flows may be an integral part of a User Agent Client (UAC) 220 per [RFC3261], which is the client notation used in the media control 221 call flow document. However, in the context of XCON, the 222 conferencing and media control client can be independent of the call 223 signaling client. 225 5.1. Basic Conference Creation 227 The simplest manner in which a conference can be created is 228 accomplished by the client sending a "confRequest" message with the 229 "create" operation as the only parameter to the conference server. 230 This results in the creation of a default conference, with an XCON- 231 URI in the form of the "confObjID" parameter, the XCON-UserID in the 232 form of the "confUserID" parameter and the data for the conference 233 object in the "confInfo" parameter all returned in the "confResponse" 234 message. This example also adds the user that invoked the conference 235 upon creation (i.e., "method" attribute is set to "dial out" for this 236 client based on the particular conferencing systems default), thus 237 the call signaling interactions to add the CMCC1 to the conference 238 are completed prior to returning the confResponse message. Note, 239 that depending upon the conferencing system, this default conference 240 could be specific to the client requesting the conference and thus 241 may be different for the initiator than other participants (e.g., IVR 242 interactions in this case which are not shown). The media 243 interactions are also handled just prior to sending the 244 "confResponse" message. 246 The specific data for the conference object is returned in the 247 "confResponse" message in the "confInfo" parameter. This allows the 248 client (with the appropriate authorization) to manipulate this data 249 and add additional participants to the conference, as well as change 250 the data during the conference. In addition, the client may 251 distribute the conferencing information to other participants 252 allowing them to join. The details of such are provided in 253 additional flows. 255 Clients that are not XCON-aware may join the conference using a 256 specific signaling interface such as SIP, using the signaling 257 interface to the conference focus as described in [RFC4579]. 258 However, these details are not shown in the message flows. The 259 message flows in this document identity the point in the message 260 flows at which this signaling occurs via the lower case letter items 261 (i.e., (a)...(x)) along with the appropriate text for the processing 262 done by the focus. 264 CMCC1 CMCC2 CMCCx CONFS MS 265 | | | | | 266 |1. confRequest | | | | 267 |-------------------------------------->| | 268 | | (a)Create +---| | 269 | | |Conf | | | 270 | | |Object | | | 271 | | |& IDs +-->| | 272 | | | | A1. CONTROL | 273 | | | |+++++++++++>>| 274 | | | |(create conf)|--+ (b) 275 | | | | | | create 276 | | | | | | conf and 277 | | | | A2. 200 OK |<-+ its ID 278 | | | |<<+++++++++++| 279 | | | |(confid=Y) | 280 |(2)confResponse(create,success, | | 281 |<--------------------------------------| | 282 | confObjID, confUserID | | 283 | conf-info) | | | 284 | | | | | 285 | | (c) Focus +---| | 286 | | sets up | | | 287 | | signaling | | | 288 | | to CMCC1 +-->| | 289 | | | | | 290 | | | | B1. CONTROL | 291 | | | |+++++++++++>>| 292 | | | | (join CMCC1 | 293 | | | | <->confY) | 294 | | | | | 295 | | | | |--+(d) join 296 | | | | | | CMCC1 & 297 | | | | B2.200 OK |<-+ conf Y 298 | | | |<<+++++++++++| 299 | | | | | 300 |<<#################################################>>| 301 | Now the CMCC1 is mixed in the conference | 302 |<<#################################################>>| 303 | | | | | 304 |******CMCC1 may then manipulate conference data *****| 305 |****** and add addt'l users, etc. | *****| 306 ' ' ' ' ' 307 ' ' ' ' ' 308 ' ' ' ' ' 309 Figure 1: Create Basic Conference - Complete flow 311 CMCC "Alice" CMCC "Bob" CMCCx CONFS 312 | | | | 313 |1. confRequest | | | 314 |-------------------------------------->| 315 | | | | 316 | | (a)Create +---| 317 | | |Conf | | 318 | | |Object | | 319 | | |& IDs +-->| 320 | | | |--+ (b) MS 321 | | | | | creates 322 | | | | | conf and 323 | | | |<-+ its ID 324 | | | | (confid=Y) 325 |(2)confResponse(create,success, | 326 |<--------------------------------------| 327 | confObjID, confUserID | 328 | confInfo) | | 329 | | | | 330 | | | | 332 Figure 2: Create Basic Conference - Annotated Flow 334 Note: CCMP Messaging details not available yet - will be pulled from 335 the prototype results. 337 Figure 3: Create Basic Conference (Annotated) Detailed Messaging 339 5.2. Basic Conference Creation for a specific instance of Conference 340 Information 342 A conference can also be created by the client sending a 343 "confRequest" message with the "create" operation, along with the 344 desired data in the form of the "confInfo" parameter for the 345 conference to be created. An example where this approach might be 346 applicable would be in the case where a conference user might need to 347 use a different conferencing system than is typically used (e.g., one 348 that is more geographically appropriate for some participants that 349 perhaps do not support advanced conferencing functionality). If the 350 specific conferencing system can support that specific type of 351 conference (capabilities, etc.), then the request results in the 352 creation of a conference. In this success case, an XCON-URI in the 353 form of the "confObjID" parameter and the XCON-UserID in the form of 354 the "confUserID" parameter are returned in the "confResponse" 355 message. The "confInfo" is not returned unless changes have been 356 made, in which case the "responseCode" is "modified". This example 357 also activates the conference upon creation, thus the call signaling 358 interactions to add the CMCC to the conference are completed prior to 359 returning the confResponse message. The media interactions handled 360 when the confResponse message is sent. 362 This example also activates the conference upon creation (i.e., 363 "method" attribute is set to "dial out" for this client based on the 364 particular conferencing systems default), thus the call signaling 365 interactions to add the CMCC to the conference are completed prior to 366 returning the confResponse message. Note, that depending upon the 367 conferencing system, this default conference could be specific to the 368 client requesting the conference and thus may be different for the 369 initiator than other participants (e.g., IVR interactions in this 370 case which are not shown. The media interactions are also handled 371 just prior to sending the "confResponse" message. 373 CMCC "Alice" CMCC "Bob" CMCCx CONFS 374 | | | | 375 |(1)confRequest | | | 376 |-------------------------------------->| 377 | (confInfo) | | 378 | | | | 379 | | (a)Create +---| 380 | | |Conf | | 381 | | |Object | | 382 | | |& IDs +-->| 383 |(2) confResponse | | 384 |<--------------------------------------| 385 | ( create,success, confObjID | 386 | confUserID, confInfo) | |--+ (b) MS 387 | | | | | creates 388 | | | | | conf and 389 | | | |<-+ its ID 390 | | | | (confid=Y) 391 | | (c) Focus +---| 392 | | sets up | | 393 | | signaling | | 394 | | to Alice +-->| 395 | | | | 396 | | | |--+(d) MS joins 397 | | | | | Alice & 398 | | | |<-+ conf Y 399 | | | | 400 | | | | 401 |<<###################################>>| 402 | Alice is mixed in the conference | 403 |<<###################################>>| 404 | | | | 405 | | (e)Focus +---| 406 | | sets up | | 407 | | signaling | | 408 | | to Bob | | 409 | | | +-->| 410 | | | | 411 | | | |--+(f)MS joins 412 | | | | | Bob & 413 | | | |<-+ conf Y 414 | | | | 415 | |<<###################>>| 416 | | Bob is mixed too | 417 | |<<###################>>| 418 | | | | 419 " " " " 420 " " " " 421 " " " " 422 | | (gx)Focus +---| 423 | | sets up | | 424 | | signaling | | 425 | | for all | | 426 | | CMCCx +-->| 427 | | | | 428 | | | |--+(hx)MS joins 429 | | | | | CMCCx & 430 | | | |<-+ conf Y 431 | | | | 432 | | |<<#######>>| 433 | | |CMCCx mixed| 434 | | |<<#######>>| 435 | | | | 436 | | | | 437 | | | | 438 |<***All parties connected to conf Y***>| 439 | | | | 440 | | | | 441 " " " " 442 " " " " 443 " " " " 445 Figure 4: Create Basic Conference from user provided conference-info 447 (CCMP Messaging details not available yet). 449 Figure 5: Create Basic Conference Detailed Messaging 451 5.3. Basic Conference Creation - Cloning an existing Conference 453 A client can also create another conference by cloning an existing 454 conference, such as an active conference or conference reseravation. 455 In this example, the client sends a "confRequest" message with the 456 "create" operation, along with a specific "confObjID", from which a 457 new conference is to be created by cloning an existing conference. 459 An example of how a client can create a conference based on a 460 blueprint is provided in Section 5.4. The manner by which a client 461 in this example might learn about a conference reservation or active 462 conferences is similar to the first step in the blueprint example, 463 with the exception of specifying querying for different types of 464 conference objects supported by the specific conferencing system. 465 For example, in this example, the client clones a conference 466 reservation, thus the client would include the appropriate 467 "confObjState" parameter. [Note: we don't currently have this 468 parmeter in the XML schema in CCMP, BUT this functionality is 469 documented in the text.] 471 If the conferencing system can support a new instance of the specific 472 type of conference(capabilities, etc.), then the request results in 473 the creation of a conference, with an XCON-URI in the form of a new 474 value in the "confObjID" parameter to reflect the newly cloned 475 conference object returned in the "confResponse" message. The 476 "confInfo" is not returned unless there had been changes, in which 477 case the "responseCode" is "modified". This example also activates 478 the conference upon creation, thus the call signaling interactions to 479 add the CMCC to the conference are completed prior to returning the 480 confResponse message. The media interactions handled when the 481 confResponse message is sent. 483 CMCC "Alice" ConfS 484 | | 485 |(1) confRequest (create, | 486 |------------------------------>|(a') Validate user 487 | confObjID, confUserId,child) | and confObjID 488 | |--+ 489 | | |(a) Create conf 490 | | | and ID 491 | | |(b) Setup call 492 | | | signaling and 493 | | | media interface 494 | | | to CMCC 495 | |<-+ 496 |(2) confRespons | 497 |<------------------------------| 498 | ( create, success, | 499 | confObjID, confUserID) |--+ 500 | | | (c) Join CMCC 501 | | | and media 502 | |<-+ 503 | | 504 . . 505 . . 507 Figure 6: Create Basic Conference - Clone 509 1. "Alice" sends a confRequest message to clone a conference based 510 on an existing conference reservation. "Alice" indicates this 511 conference should be a "child" of the parent conference represented 512 by the "confObjID" in the request. 514 2. Upon receipt of the confRequest message containing a "create" 515 operation and "confObjID", the conferencing system ensures that the 516 "confObjID" received is valid. The conferencing system determines 517 the appropriate read/write access of any users to be added to a 518 conference based on this "confObjID" (using membership, roles, etc.). 519 The conferencing system uses the received "confObjID" to clone a 520 conference reservation. The conferencing system also reserves or 521 allocates a new "confObjID" to be used for the cloned conference 522 object. Any subsequent protocol requests from any of the members of 523 the conference. The conferencing system maintains the mapping 524 between this conference ID and the parent conference object ID 525 associated with the reservation through the conference instance. 527 (CCMP Messaging details not available yet). 529 Figure 7: Create Basic Conference (Clone) Detailed Messaging 531 5.4. Conference Creation using Blueprints 533 Figure 8 provides an example of one client "Alice" determining the 534 conference blueprints available for a particular conferencing system 535 and creating a conference based on the desired blueprint. 537 CMCC "Alice" ConfS 538 | | 539 | (1) blueprintsRequest | 540 |------------------------------>| 541 | (confUserID) | 542 | | 543 | (2) blueprintsResponse | 544 |<------------------------------| 545 | (success, | 546 | blueprintsInfo) | 547 |--+ | 548 | | choose preferred | 549 | | blueprint from the | 550 | | list (blueprintName) | 551 |<-+ | 552 | | 553 | (3) blueprintRequest | 554 |------------------------------>| 555 | (blueprintInfo, confUserID) | 556 | | 557 | (4) blueprintResponse | 558 |<------------------------------| 559 | (success,confInfo | 560 | confInfo) | 561 | | 562 | (5) confRequest (create, | 563 |------------------------------>| 564 | confInfo) | 565 | |--+ 566 | | |(a)Create conf 567 | | | and ID 568 | |<-+ 569 |(6) confResponse | 570 |<------------------------------| 571 | (create,success, | 572 | confObjID, confUserID) | 573 | | 574 | | 575 | | 576 . . 577 . . 579 Figure 8: Client Creation of Conference using Blueprints 581 1. "Alice" first sends an "optionsRequest" message to the 582 conferencing system identified by the conference server discovery 583 process (details TBD). Upon receipt of the "optionsRequest", the 584 conferencing system would first authenticate "Alice" (and allocate a 585 conference user identifier, if necessary) and then ensure that 586 "Alice" has the appropriate authority based on system policies to 587 receive any blueprints supported by that system. Any blueprints that 588 "Alice" is authorized to use are returned in a "optionsResponse" 589 message in the "blueprints" attribute, along with the "confUserID" 590 parameter. 592 2. Upon receipt of the "optionsResponse" containing the blueprints, 593 "Alice" determines which blueprint to use for the conference to be 594 created. "Alice" creates a conference object based on the blueprint 595 (i.e., clones) and modifies applicable fields, such as membership 596 list and start time. 598 3. "Alice" then sends a "confRequest" with a "create" operation to 599 the conferencing system to create a conference reservation based upon 600 the updated blueprint, including the appropriate "blueprintName" and 601 associated "confObjID". 603 Note: This conference is created as independent of the parent 604 (blueprint), but there are no hard and fast requirements as to 605 whether conference from blueprints are always independent or whether 606 the conferences cloned from conference reservations or active 607 conferences are also children. The protocol is flexible enough to 608 allow all the variations, thus any limitations would be specific to a 609 conferencing system. 611 Upon receipt of the "confRequest" message with a "create" operation 612 and an "action" to "reserve" a conference based upon the blueprint in 613 the request, the conferencing system ensures that the blueprint 614 received is a valid blueprint (i.e. the values of the various field 615 are within range). [Note: we don't currently have this "action" 616 field defined for the "confRequest" message.] The conferencing 617 system determines the appropriate read/write access of any users to 618 be added to a conference based on this blueprint (using membership, 619 roles, etc.). The conferencing system uses the received blueprint to 620 clone a conference reservation. The conferencing system also 621 reserves or allocates a conference ID to be used for any subsequent 622 CCMP requests from any of the members of the conference. The 623 conferencing system maintains the mapping between this conference ID 624 and the "confObjID" associated with the reservation through the 625 conference instance. 627 4. The conferencing server then sends a "confResponse" message 628 including the "confObjID" associated with the reserved conference. 629 Upon receipt of the "confResponse" message, "Alice" can now create an 630 active conference using that reservation or create additional 631 reservations based upon the existing reservation. 633 5. In this example, "Alice" has reserved a meetme conference bridge. 634 Thus, "Alice" provides the conference information, including the 635 necessary "confObjID", to desired participants. Note, that this 636 interface is entirely outside the scope of the XCON framework, 637 protocols and this document. When the first participant, "Alice" in 638 this example, then requests to be added to the conference by sending 639 a "userRequest" .... 641 6. Upon receipt of the "userRequest" message, the conference is 642 activated and the focus is created. The focus is associated with the 643 "confObjID" received in the request. Any participants that have the 644 authority to manipulate the conference would receive the "confObjID" 645 in any responses. The conference server then sends "userResponse" 646 message.... 648 (CCMP Messaging details not available yet). 650 Figure 9: Create Conference (Blueprint) Detailed Messaging 652 6. General Conference scenarios and examples 654 The following scenarios are based on those documented in the XCON 655 framework. The examples assume that a conference has already been 656 correctly established, with media, if applicable, per one of the 657 examples in Section 5. 659 6.1. Conference Announcements and Recordings 661 In this example, as shown in Figure 10 "Alice" is joining "Bob"'s 662 conference that requires that she first enter a pass code. After 663 successfully entering the passcode, an announcement prompts "Alice to 664 speak her name so it can be recorded. When "Alice" is added to the 665 active conference, the recording is played back to all the existing 666 participants. 668 (Figure not available yet). 670 Figure 10: Recording and Announcements 672 1. Upon receipt of the userRequest from "Alice" to be added to 673 "Bob's" conference, the conferencing system maps the identifier 674 received in the request to the conference object representing "Bob's" 675 active conference. The conferencing system determines that a 676 password is required for this specific conference, thus an 677 announcement asking "Alice" to enter the password is provided to 678 "Alice". Once "Alice" enters the password, it is validated against 679 the policies associated with "Bob's" active conference. The 680 conferencing system then connects to a server which prompts and 681 records "Alice's" name. The conferencing system must also determine 682 whether "Alice" is already a user of this conferencing system or 683 whether she is a new user. 685 2. "Alice" is a new user for this conferencing system, so a 686 conference user identifier is created for "Alice". Based upon the 687 addressing information provided by "Alice", the call signaling to add 688 "Alice" to the conference is instigated through the Focus. In 689 addition, "Alice" is sent a userResponse message which includes the 690 "confUserID" assigned by the conferencing system for "Alice". This 691 would allow "Alice" to later perform operations on the conference (if 692 she were to have the appropriate policies), including registering for 693 event notifications associated with the conference. 695 3. Once the call signaling indicates that "Alice" has been 696 successfully added to the specific conference, per updates to the 697 state, and depending upon the policies, other participants (e.g., 698 "Bob") are notified of the addition of "Alice" to the conference via 699 the conference notification service and an announcement is provided 700 to all the participants indicating that "Alice" has joined the 701 conference. 703 (CCMP Messaging details not available yet). 705 Figure 11: Announcement Messaging Details 707 6.2. Monitoring for DTMF 709 The conferencing system also needs the capability to monitor for DTMF 710 from each individual participant. This would typically be used to 711 enter the identifier and/or access code for joining a specific 712 conference. 714 An example of DTMF monitoring, within the context of the framework 715 elements, is shown in Figure 10. 717 6.3. Adding a Party 719 Figure 12 provides an example of one client "Alice" impacting the 720 state of another client "Bob". This example assumes an established 721 conference. In this example, "Alice" wants to add "Bob" to the 722 conference. 724 To do. 726 Figure 12: Client Manipulation of Conference - Add a party 728 1. Upon receipt of the Conference Control Protocol request to "add" 729 a party ("Bob") in the specific conference as identified by the 730 conference object ID, the conferencing system ensures that "Alice" 731 has the appropriate authority based on the policies associated with 732 that specific conference object to perform the operation. The 733 conferencing system must also determine whether "Bob" is already a 734 user of this conferencing system or whether he is a new user. 736 2. If "Bob" is a new user for this conferencing system, a Conference 737 User Identifier is created for Bob. Based upon the addressing 738 information provided for "Bob" by "Alice", the call signaling to add 739 "Bob" to the conference is instigated through the Focus. 741 3. Once the call signaling indicates that "Bob" has been 742 successfully added to the specific conference, per updates to the 743 state, and depending upon the policies, other participants (including 744 "Bob") may be notified of the addition of "Bob" to the conference via 745 the Conference Notification Service. 747 (CCMP Messaging details not available yet). 749 Figure 13: Add Party Message Details 751 6.4. Joining a Conference 753 Figure 14 provides an example of one client "Duck" joining an active 754 conference with "Alice", "Bob" and "Claire" as participants. Using 755 SIP as a call control protocol such as SIP, "Duck" joins the 756 conference without using any CCMP messaging since the required 757 interactions are specific to the conferencing system via a trigger 758 from the focus upon receipt of the SIP message. The the conferencing 759 system does the following to join "Duck" to the active conference: 761 adds "Duck" as a user, authorizes "Duck" to join the conference, 762 modifies the appropriate conference data, and provides the 763 notifications to the participants that have registered for such. 765 To do. 767 Figure 14: Client Joining an Active Conference 769 1. Upon receipt of the SIP request to "join" a party ("Duck") to the 770 specific conference as identified by the Focus. The conferencing 771 system determines the appropriate conference object ID. The 772 conferencing system then determines whether "Bob" is already a user 773 of this conferencing system or whether he is a new user. If "Bob" is 774 a new user for this conferencing system, a Conference User Identifier 775 is created for Bob. Based upon the addressing information provided 776 for "Bob" by "Alice", the call signaling to add "Bob" to the 777 conference is instigated through the Focus. 779 2. Once the call signaling indicates that "Duck" has been 780 successfully added to the specific conference, per updates to the 781 state, and depending upon the policies, other participants (including 782 "Duck") may be notified of the addition of "Duck" to the conference 783 via the Conference Notification Service. 785 (CCMP Messaging details not available yet). 787 Figure 15: Join Message Details 789 6.5. Muting a Party 791 This section provides an example of the muting of a party in an 792 active conference. The unmuting would involve the identical CCMP 793 message flow. Although, in the case that floor control is involved, 794 whether or not a particular conference client can unmute themselves 795 must be considered by the conferencing system. 797 Figure 16 provides an example of one client "Alice" impacting the 798 media state of another client "Bob". This example assumes an 799 established conference. In this example, the client, "Alice" whose 800 Role is "moderator" of the conference, wants to mute "Bob" on a 801 medium-size multi-party conference, as his device is not muted (and 802 he's obviously not listening to the call) and background noise in his 803 office environment is disruptive to the conference. 805 (To be added). 807 Figure 16: Client Manipulation of Conference - Mute a party 809 1. Upon receipt of the Conference Control Protocol request to "mute" 810 a party ("Bob") in the specific conference as identified by the 811 conference object ID, the Conference Server ensures that "Alice" has 812 the appropriate authority based on the policies associated with that 813 specific conference object to perform the operation. "Bob"'s status 814 is marked as "recvonly" and the conference object is updated to 815 reflect that "Bob"s media is not to be "mixed" with the conference 816 media. In case the Conference Server relies on a remote Media Server 817 for its multimedia functionality, it subsequently changes "Bob"'s 818 media profile accordingly by means of the related protocol 819 interaction with the MS. An example describing a possible way of 820 dealing with such a situation using the Media Server Control 821 architecture is described in [I-D.miniero-mediactrl-escs], at "Simple 822 Bridging: Framework Transactions (2)". 824 2...x. Depending upon the policies, other participants (including 825 "Bob") may be notified of this change via the Conference Notification 826 Service. 828 (CCMP Messaging details not available yet). 830 Figure 17: Mute Message Details 832 6.6. Internal Sidebar 834 Figure 18 provides an example of one client "Alice" involved in 835 active conference with "Bob" and "Carol". "Alice" wants to create a 836 sidebar to have a side discussion with "Bob" while still viewing the 837 video associated with the main conference. Alternatively, the audio 838 from the main conference could be maintained at a reduced volume. 839 "Alice" initiates the sidebar by sending a request to the 840 conferencing system to create a conference reservation based upon the 841 active conference object. "Alice" and "Bob" would remain on the 842 roster of the main conference, such that other participants could be 843 aware of their participation in the main conference, while an 844 internal-sidebar conference is occurring. 846 (To be added). 848 Figure 18: Client Creation of a Sidebar Conference 850 1. Upon receipt of the Conference Control Protocol request to 851 "reserve" a new sidebar conference, based upon the active conference 852 received in the request, the conferencing system uses the received 853 active conference to clone a conference reservation for the sidebar. 854 The sidebar reservation is NOT independent of the active conference 855 (i.e., parent). The conferencing system also reserves or allocates a 856 conference ID to be used for any subsequent protocol requests from 857 any of the members of the conference. 859 2. Upon receipt of the conference control protocol response to 860 reserve the conference, "Alice" can now create an active conference 861 using that reservation or create additional reservations based upon 862 the existing reservations. In this example, "Alice" wants only "Bob" 863 to be involved in the sidebar, thus she manipulates the membership. 864 "Alice" also only wants the video from the original conference and 865 wants the audio to be restricted to the participants in the sidebar. 866 Alternatively, "Alice" could manipulate the media values to recieve 867 the audio from the main conference at a reduced volume. "Alice" 868 sends a conference control protocol request to update the information 869 in the reservation and to create an active conference. 871 3. Upon receipt of the conference control protocol request to update 872 the reservation and to create an active conference for the sidebar, 873 as identified by the conference object ID, the conferencing system 874 ensures that "Alice" has the appropriate authority based on the 875 policies associated with that specific conference object to perform 876 the operation. The conferencing system must also validate the 877 updated information in the reservation, ensuring that a member like 878 "Bob" is already a user of this conferencing system. 880 4...x. Depending upon the policies, the initiator of the request 881 (i.e., "Alice") and the participants in the sidebar (i.e., "Bob") may 882 be notified of his addition to the sidebar via the conference 883 notification service. 885 (CCMP Messaging details not available yet). 887 Figure 19: Internal Sidebar Messaging Details 889 6.7. External Sidebar 891 Figure 20 provides an example of one client "Alice" involved in an 892 active conference with "Bob", "Carol", "David" and "Ethel". "Alice" 893 gets an important text message via a whisper from "Bob" that a 894 critical customer needs to talk to "Alice", "Bob" and "Ethel". 895 "Alice" creates a sidebar to have a side discussion with the customer 896 "Fred" including the participants in the current conference with the 897 exception of "Carol" and "David", who remain in the active 898 conference. "Alice" initiates the sidebar by sending a request to 899 the conferencing system to create a conference reservation based upon 900 the active conference object. "Alice", "Bob" and "Ethel" would 901 remain on the roster of the main conference in a hold state. Whether 902 or not the hold state of these participants is visible to other 903 participants depends upon the individual and local policy. 905 (To be Detailed). 907 Figure 20: Client Creation of an External Sidebar 909 1. Upon receipt of the Conference Control Protocol request to 910 "reserve" a new sidebar conference, based upon the active conference 911 received in the request, the conferencing system uses the received 912 active conference to clone a conference reservation for the sidebar. 913 The sidebar reservation is NOT independent of the active conference 914 (i.e., parent). The conferencing system also reserves or allocates a 915 conference ID to be used for any subsequent protocol requests from 916 any of the members of the conference. The conferencing system 917 maintains the mapping between this conference ID and the conference 918 object ID associated with the sidebar reservation through the 919 conference instance. 921 2. Upon receipt of the conference control protocol response to 922 reserve the conference, "Alice" wants only "Bob" and "Ethel", along 923 with the new participant "Fred" to be involved in the sidebar, thus 924 she manipulates the membership. "Alice" sets the media in the 925 conference-info such that the participants in the sidebar don't 926 receive any media from the main conference. 928 3. "Alice" sends a conference control protocol request to update the 929 information in the reservation and to create an active conference. 931 4. Upon receipt of the conference control protocol request to update 932 the reservation and to create an active conference for the sidebar 933 the conferencing system ensures that "Alice" has the appropriate 934 authority based on the policies associated with that specific 935 conference object to perform the operation. The conferencing system 936 also validates the updated information in the reservation. Since 937 "Fred" is a new user for this conferencing system, a conference user 938 identifier is created for "Fred". Based upon the addressing 939 information provided for "Fred" by "Alice", the call signaling to add 940 "Fred" to the conference is instigated through the Focus. 942 5...x. Depending upon the policies, the initiator of the request 943 (i.e., "Alice") and the participants in the sidebar (i.e., "Bob" and 944 "Ethel") may be notified of his addition to the sidebar via the 945 conference notification service. 947 (CCMP Messaging details not available yet). 949 Figure 21: External Sidebar Messaging Details 951 6.8. Floor control using sidebars 953 Floor control with sidebars can be used to realize conferencing 954 scenario such as an analyst briefing. In this scenario, the 955 conference call has a panel of speakers who are allowed to talk in 956 the main conference. The other participants are the analysts, who 957 are not allowed to speak unless they have the floor. To request 958 access to the floor, they have to join a new sidebar with the 959 moderator and ask their question. The moderator can also whisper to 960 each analyst what their status/position in the floor control queue, 961 similar to the example in Figure 24. It should be noted that other 962 mechanisms which don't make use of sidebars could be used for floor 963 control such as those detailed in BFCP. [Editor's note: Should we 964 add detailed flows for BFCP to this document and show additional 965 floor control scenarios? 967 Figure 22 provides an example of the configuration involved for this 968 type of conference. As in the previous sidebar examples, there is 969 the main conference along with a sidebar. "Alice" and "Bob" are the 970 main participants in the conference, with "A1", "A2" and "A3" 971 representing the analysts. The sidebar remains active throughout the 972 conference, with the moderator, "Carol", serving as the chair. As 973 discussed previously, the sidebar conference is NOT independent of 974 the active conference (i.e., parent). The analysts are provided the 975 conference object ID associated with the active sidebar when they 976 join the main conference. The conferencing system also allocates a 977 conference ID to be used for any subsequent manipulations of the 978 sidebar conference. The conferencing system maintains the mapping 979 between this conference ID and the conference object ID associated 980 with the active sidebar conference through the conference instance. 981 The analysts are permanently muted while in the main conference. The 982 analysts are moved to the sidebar when they wish to speak. Only one 983 analyst is given the floor at a given time. All participants in the 984 main conference receive audio from the sidebar conference, as well as 985 audio provided by the panelists in the main conference. 987 (To Be added). 989 Figure 22: Floor Control with sidebars 991 1. "A1" wishes to ask a question, so he sends a Floor Request 992 message to the floor control server. 994 2. Upon receipt of the request, the floor control server notifies 995 the moderator, "Carol" of the active sidebar conference, whose 996 serving as the floor chair. 998 3. Since no other analysts have yet requested the floor, "Carol" 999 indicates to the floor control server that "A1" may be granted the 1000 floor. 1002 (CCMP Messaging details not available yet). 1004 Figure 23: Floor Control Messaging Details 1006 6.9. Whispering or Private Messages 1008 The case of private messages can be handled as a sidebar with just 1009 two participants, similar to the example in section Section 6.6, but 1010 rather than using audio within the sidebar, "Alice" could add an 1011 additional text based media stream to the sidebar. The other 1012 context, referred to as whisper, in this document refers to 1013 situations involving one time media targetted to specific user(s). 1014 An example of a whisper would be an announcement injected only to the 1015 conference chair or to a new participant joining a conference. 1017 Figure 24 provides an example of one user "Alice" whose chairing a 1018 fixed length conference with "Bob" and "Carol". The configuration is 1019 such that only the chair is providing a warning when there is only 10 1020 minutes left in the conference. At that time, "Alice" is moved into 1021 a sidebar created by the conferencing system and only "Alice" 1022 receives the announcement. 1024 (To Be completed). 1026 Figure 24: Whisper 1028 1. When the conferencing system determines that there is only 10 1029 minutes left in the conference which "Alice" is chairing, the 1030 conferencing system directly creates an active sidebar conference, 1031 based on the active conference associated with "Alice". This sidebar 1032 conference is NOT independent of the active conference (i.e., 1033 parent). The conferencing system also allocates a conference ID to 1034 be used for any subsequent manipulations of the sidebar conference. 1036 2. Immediately upon creation of the active sidebar conference, the 1037 announcement media is provided to "Alice". Depending upon the 1038 policies, Alice may be notified of her addition to the sidebar via 1039 the conference notification service. "Alice" continues to receive 1040 the media from the main conference. 1042 3. Upon completion of the announcement, "Alice" is removed from the 1043 siebar and the sidebar conference is deleted. 1045 4. "Alice" is notified of her removal from the sidebar via the 1046 conference notification service. 1048 (CCMP Messaging details not available yet). 1050 Figure 25: Whisper Messaging Details 1052 6.10. Observing and Coaching 1054 An example of observing and coaching is shown in figure Figure 26. 1055 In this example, call center agent "Bob" is involved in a conference 1056 with customer "Carol". Since "Bob" is a new agent and "Alice" sees 1057 that he has been on the call with "Carol" for longer than normal, she 1058 decides to observe the call and coach "Bob" as necessary. 1060 (Figure not available yet). 1062 Figure 26: Supervisor Creating a Sidebar for Observing/Coaching 1064 Upon receipt of the Conference Control Protocol request from "Alice" 1065 to "reserve" a new sidebar conference, based upon the active 1066 conference received in the request, the conferencing system uses the 1067 received active conference to clone a conference reservation for the 1068 sidebar. The conferencing system also reserves or allocates a 1069 conference ID to be used for any subsequent protocol requests from 1070 any of the members of the conference. The conferencing system 1071 maintains the mapping between this conference ID and the conference 1072 object ID associated with the sidebar reservation through the 1073 conference instance. 1075 Upon receipt of the conference control protocol response to reserve 1076 the conference, "Alice" can now create an active conference using 1077 that reservation or create additional reservations based upon the 1078 existing reservations. In this example, "Alice" wants only "Bob" to 1079 be involved in the sidebar, thus she manipulates the membership. 1080 "Alice" also wants the audio to be received by herself and "Bob" from 1081 the original conference, but wants any outgoing audio from herself to 1082 be restricted to the participants in the sidebar, whereas "Bob's" 1083 outgoing audio should go to the main conference, so that both "Alice" 1084 and the customer "Carol" hear the same audio from "Bob". "Alice" 1085 sends a conference control protocol request to update the information 1086 in the reservation and to create an active conference. 1088 Upon receipt of the conference control protocol request to update the 1089 reservation and to create an active conference for the sidebar, as 1090 identified by the conference object ID, the conferencing system 1091 ensures that "Alice" has the appropriate authority based on the 1092 policies associated with that specific conference object to perform 1093 the operation. Based upon the addressing information provided for 1094 "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with 1095 the appropriate media characteristics is instigated through the 1096 Focus. 1098 "Bob" is notified of his addition to the sidebar via the conference 1099 notification service, thus he is aware that "Alice" the supervisor is 1100 available for coaching him through this call. 1102 (CCMP Messaging details not available yet). 1104 Figure 27: Coaching and Observing Messaging details 1106 7. Removing participants and deleting conferences 1108 The following scenarios detail the basic operations associated with 1109 removing participants from conferences and entirely deleting 1110 conferences. The examples assume that a conference has already been 1111 correctly established, with media, if applicable, per one of the 1112 examples in Section 5. 1114 7.1. Removing a Party 1116 Figure 28 provides an example of one client "Alice" removing another 1117 participant "Bob" from a conference. This example assumes an 1118 established conference with "Alice", "Bob", "Claire" and "Duck". In 1119 this example, "Alice" wants to remove "Bob" from the conference so 1120 that the group can continue in the same conference without "Bob"'s 1121 participation. 1123 (Figure not available yet). 1125 Figure 28: Client Manipulation of Conference - Remove a party 1127 1. Upon receipt of the confUsersRequest message, with a "change" 1128 operation to remove "Bob" from the "allowed-users-list" for the 1129 conference identified by the "confObjID" in the request, the 1130 conferencing system ensures that "Alice" has the appropriate 1131 authority based on the policies associated with that specific 1132 conference object to perform the operation. 1134 2. Based upon the addressing and media information in the conference 1135 object for "Bob" in the "user" element, the conferencing system 1136 instigates the process to remove "Bob" (e.g., the call signaling to 1137 remove "Bob" from the conference is instigated through the Focus). 1138 In addition, the "conference-info" in the conference object is 1139 modified to remove "Bob" from the "users" list. 1141 3. Once the call signaling indicates that "Bob" has been 1142 successfully removed from the specific conference, per updates to the 1143 state, and depending upon the policies, other participants (including 1144 "Bob") may be notified of the removal of "Bob" from the conference 1145 via the Conference Notification Service. 1147 (CCMP Messaging details not available yet). 1149 Figure 29: Removing a Participant Messaging Details 1151 7.2. Deleting a Conference 1153 Details to be added. 1155 (Figure not available yet). 1157 Figure 30: Deleting a conference 1159 (Text description to be added). 1161 (CCMP Messaging details not available yet). 1163 Figure 31: Deleting a Conference Messaging Details 1165 8. Additional Conference Scenarios and Examples 1167 The following are additional scenarios making use of the XCON 1168 framework and associated protocols. In some cases, these examples 1169 make use of some of the building block scenarios detailed in the 1170 previous example sections, in which case the appropriate scenario is 1171 referenced rather than duplicating details. In addition, in cases 1172 where the scenarios make use of other protocols, as in the previous 1173 section, the appropriate reference in the form of a title to the 1174 specific flow in the appropriate protocol document is included. 1176 8.1. Chat 1178 The chat functionality described in this section of the document 1179 allows clients that use the XCON framework and protocols for other 1180 media types (e.g. voice/video) to utilize the same conference control 1181 mechanisms and conferencing system to establish, update and delete a 1182 conference instance associated with an Instant Messaging (IM) chat 1183 session, independent of the IM chat protocol. In some cases(e.g., 1184 Message Session Relay Protocol (MSRP) chat), this would provide 1185 additional capabilities, such as sidebars. This approach also allows 1186 the conferencing system to provide a natural interworking point for 1187 various IM protocols, the details of the interworking are outside the 1188 scope of this document. 1190 An IM client wishing to join a conference uses standardized 1191 centralized conferencing mechanisms for creating and joining a 1192 conference, as identified in the previous sections. The request to 1193 send an IM to an IM media session is specific to the IM protocol 1194 (e.g., MSRP SEND), just as there is specific media control messaging 1195 for other types of sessions. An IM client connecting to a 1196 conferencing system has a 1:1 relationship with the IM media 1197 signaling entity in the conferencing system. This relationship is 1198 referred to as an IM session. Further details of the correlation of 1199 the IM session identifiers with the XCON session identifiers is 1200 provided in [I-D.boulton-xcon-session-chat]. The IM media signaling 1201 entity is responsible for distribution of all the messages to the 1202 other participants. 1204 As with the other example conferences created, each IM session is 1205 logically associated with a specific conference. The conference 1206 itself has a specific identifier in the form of the XCON-URI, which 1207 is passed in the "confObjID" element in the CCMP messages. This 1208 provides the relevant association between IM session and a 1209 centralized conference. 1211 An IM client wishing to delete a chat room uses standardized 1212 mechanisms for deleting a conference instance, such as those detailed 1213 in Section 7.2. 1215 8.1.1. Basic Chat Operations 1217 This section provides details of the realization of the Multi-party 1218 IM (chat) within the context of the centralized conferencing 1219 framework. A brief discussion and diagrams are provided for 1220 creating, joining, and deleting a chat based conference. The 1221 discovery of chat rooms available on a specific conferencing system 1222 is inherent in the blueprint capability provided by the conferencing 1223 system. The objective of this section is to further illustrate the 1224 model, mechanisms and protocols presented in the previous sections 1225 and also serves to validate that the model, mechanisms and protocols 1226 are sufficient to support IM chat. 1228 It should be noted that not all entities impacted by the request are 1229 shown in the diagram (e.g., Focus), but rather the emphasis is on the 1230 new entities introduced by this centralized conferencing framework. 1232 8.1.1.1. Creating a Chat Room 1234 There are different ways to create a conference. A participant can 1235 create a conference using call signaling means only, such as SIP, as 1236 detailed in [RFC4579]. For a conferencing client to have more 1237 flexibility in defining the charaterisitics and capabilities of a 1238 chat based conference, a conferencing client would implement a 1239 conference control protocol client. By using a conference control 1240 protocol, the client can determine the capabilities of a conferencing 1241 system and its various resources. 1243 Figure 32 provides an example of one client "Alice" determining the 1244 conference blueprints available to support various types of chat 1245 rooms for a particular conferencing system and creating a chat based 1246 conference using the desired blueprint. 1248 Details to be added. 1250 Figure 32: Client Creation of Chat room 1252 Upon receipt of the Conference Control Protocol request for 1253 blueprints associated with chat rooms, the conferencing system would 1254 first authenticate "Alice" (and allocate a conference user 1255 identifier, if necessary) and then ensure that "Alice" has the 1256 appropriate authority based on system policies to receive any chat 1257 room based blueprints supported by that system. Any blueprints that 1258 "Alice" is authorized to use are returned in a response, along with 1259 the conference user ID. 1261 Upon receipt of the Conference Control Protocol response containing 1262 the blueprints, "Alice" determines which blueprint to use for the 1263 conference to be created. "Alice" creates a conference object based 1264 on the blueprint (i.e., clones) and modifies applicable fields, such 1265 as membership list, topic details, and start time. "Alice" then 1266 sends a request to the conferencing system to create a conference 1267 reservation based upon the updated blueprint. 1269 Upon receipt of the Conference Control Protocol request to "create" a 1270 conference based upon the blueprint in the request, the conferencing 1271 system ensures that the blueprint received is a valid blueprint (i.e. 1272 the values of the various field are within range). The conferencing 1273 system determines the appropriate read/write access of any users to 1274 be added to a conference based on this blueprint (using membership, 1275 roles, etc.). The conferencing system uses the received blueprint to 1276 clone a conference reservation. The conferencing system also 1277 reserves or allocates a conference ID to be used for any subsequent 1278 protocol requests from any of the members of the conference. The 1279 conferencing system maintains the mapping between this conference ID 1280 and the conference object ID associated with the reservation through 1281 the conference instance. 1283 Upon receipt of the conference control protocol response to reserve 1284 the conference, "Alice" now creates an active chat room using that 1285 reservation. "Alice" provides the conference information, including 1286 the necessary conference ID, to desired participants to allow them to 1287 join the chat room. "Alice" may also add other users to the chat 1288 room. When the first participant, including "Alice", requests to be 1289 added to the conference, an active conference and focus are created. 1290 The focus is associated with the conference ID received in the 1291 request. 1293 (CCMP Messaging details not available yet. 1294 Plan is to reference detailed flows in 1295 previous sections and add MSRP messaging 1296 in the example.) 1298 Figure 33: Chatroom Creation Messaging Details 1300 8.1.1.2. Joining a Chat Room 1302 A participant can join and leave the conference using call signaling 1303 means only, such as SIP. However, in order to perform richer 1304 conference control a user client can implement a conference control 1305 protocol client. By using a conference control protocol, the client 1306 can affect its own state and the state of other participants, 1307 depending upon policies, which may indirectly affect the state of any 1308 of the conference participants. 1310 In the example in section Section 8.1.1.1, "Alice" has reserved a 1311 chat room . "Alice" has also already joined the conference and made 1312 the chat room active. "Alice" can either add additional participants 1313 to the chat room or provide the conference information, including the 1314 necessary conference ID, to desired participants and allow them to 1315 request to join themselves. Any participants that have the authority 1316 to manipulate the conference would receive the conference object 1317 identifier of the active conference object in the response to their 1318 request to join. 1320 Figure 34 provides an example of "Bob" joining the chat room using 1321 the conference ID provided by "Alice" (e.g., in an IM). 1323 Details to be added. 1325 Figure 34: Joining a chat room 1327 Upon receipt of the Conference Control Protocol request to "add" a 1328 party ("Bob") in the specific conference as identified by the 1329 conference object ID, the conferencing system must determine whether 1330 "Bob" is already a user of this conferencing system or whether he is 1331 a new user. If "Bob" is a new user for this conferencing system, a 1332 Conference User Identifier is created for Bob. The conferencing 1333 system must also ensure that "Bob" has the appropriate authority 1334 based on the policies associated with that specific conference object 1335 to perform the operation. 1337 Once "Bob" has been successfully added to the chat room, a response 1338 is sent to "Bob". Depending upon the policies, other participants 1339 (including "Bob") may be notified of the addition of "Bob" to the 1340 conference via the Conference Notification Service. 1342 (CCMP Messaging details not available yet. 1343 Plan is to reference detailed flows in 1344 previous sections as appropriate and add MSRP messaging 1345 in the example.) 1347 Figure 35: Chatroom Join Messaging Details 1349 8.1.1.3. Deleting a Chat Room 1351 Depending upon the conferencing system policies and policies specific 1352 to the chat room, the creator of the chat would typically be the 1353 participant authorized to delete the chat room. 1355 In the example in section Section 8.1.1.1, "Alice" has created a chat 1356 room and provided the conference information, including the necessary 1357 conference ID, to desired participants and allow them to request to 1358 join themselves. "Bob" and others are participants in the chat. 1359 Figure 36 provides an example of "Alice" later deleting this same 1360 chat room. 1362 Details to be added. 1364 Figure 36: Deleting a chat room 1366 Upon receipt of the Conference Control Protocol request to "delete" 1367 the specific chat room as identified by the conference object ID, the 1368 conferencing system must determine whether "Alice" has the authority 1369 to delete this conference. Since "Alice" is the creator of the 1370 conference, the "delete" operation is performed, with the appropriate 1371 signaling sent to the participants, including a response to "Alice" 1372 indicating that the chat room has been deleted. 1374 One step in the deletion of the chat room may include notifitying the 1375 participants (including "Bob") that they have been removed via the 1376 Conference Notification Service. 1378 (CCMP Messaging details not available yet. 1379 Plan is to reference detailed flows in 1380 previous sections and add MSRP messaging 1381 in the example.) 1383 Figure 37: Chatroom Deletion Messaging Details 1385 8.1.2. Advanced Operations 1387 This section provides details of the realization of advanced chat 1388 features, such as sidebars and private messages, within the context 1389 of the centralized conferencing framework. As with Section 8.1.1, 1390 the objective of this section is to further illustrate the model, 1391 mechanisms and protocols presented in the previous sections and also 1392 serves to validate that the model, mechanisms and protocols are 1393 sufficient to support advance IM chat features. 1395 8.1.2.1. Text Sidebar 1397 The concept of a 'sidebar' in conferencing system is fully described 1398 in the Sidebar section and related subsections within the 1399 Conferencing Scenarios Realization section of the centralized 1400 conferencing framework document [RFC5239]. The creation, 1401 manipulation and deletion of sidebars for chat rooms follows the same 1402 principles. 1404 A conference object representing a sidebar is created by cloning the 1405 parent associated with the existing conference and updating any 1406 information specific to the sidebar. A sidebar conference object is 1407 implicitly linked to the parent conference object (i.e. it is not an 1408 independent object) and is associated with the parent conference 1409 object identifier. A conferencing system manages and enforces the 1410 parent and appropriate localized restrictions on the sidebar 1411 conference object (e.g., no members from outside the parent 1412 conference instance can join, sidebar conference can not exist if 1413 parent conference is terminated, etc.). 1415 Figure 38 provides an example of one client "Alice" involved in 1416 active chat room with "Bob" and "Carol". "Alice" wants to create a 1417 sidebar to have a side discussion with "Bob" while still receiving 1418 the session based messaging associated with the main chat room. 1419 Whether the text is interleaved with the main chat or whether a 1420 separate window is created for the sidebar is implementation 1421 specific. "Alice" initiates the sidebar by sending a request to the 1422 conferencing system to create a conference chat reservation based 1423 upon the active chat conference object. "Alice" and "Bob" would 1424 remain on the roster of the main conference, such that other 1425 participants could be aware of their participation in the main 1426 conference, while the text sidebar conference is occurring. 1428 Details to be added. 1430 Figure 38: Client Creation of a Sidebar Conference 1432 Upon receipt of the Conference Control Protocol request to "reserve" 1433 a new sidebar chat conference, based upon the active chat conference 1434 received in the request, the conferencing system uses the received 1435 active chat conference to clone a conference chat reservation for the 1436 sidebar. As discussed previously, the sidebar reservation is NOT 1437 independent of the active conference (i.e., parent). The 1438 conferencing system also reserves or allocates a conference ID to be 1439 used for any subsequent protocol requests from any of the members of 1440 the conference. The conferencing system maintains the mapping 1441 between this conference ID and the conference object ID associated 1442 with the sidebar reservation through the conference instance. 1444 Upon receipt of the conference control protocol response to reserve 1445 the conference, "Alice" can now create an active chat conference 1446 using that reservation or create additional reservations based upon 1447 the existing reservations. In this example, "Alice" wants only "Bob" 1448 to be involved in the sidebar, thus she manipulates the membership. 1449 "Alice" also only wants the text from the original conference, but 1450 wants the text within the sidebar to be restricted to the 1451 participants in the sidebar. "Alice" sends a conference control 1452 protocol request to update the information in the reservation and to 1453 create an active conference. 1455 Upon receipt of the conference control protocol request to update the 1456 reservation and to create an active chat conference for the sidebar, 1457 as identified by the conference object ID, the conferencing system 1458 ensures that "Alice" has the appropriate authority based on the 1459 policies associated with that specific conference object to perform 1460 the operation. The conferencing system must also validate the 1461 updated information in the reservation, ensuring that a member like 1462 "Bob" is already a user of this conferencing system. 1464 Depending upon the policies, the initiator of the request (i.e., 1465 "Alice") and the participants in the sidebar (i.e., "Bob") may be 1466 notified of his addition to the sidebar via the conference 1467 notification service. 1469 (CCMP Messaging details not available yet. 1470 Plan is to reference detailed flows in 1471 previous sections.) 1473 Figure 39: Chatroom Sidebar Messaging Details 1475 8.1.2.2. Private Message 1477 The case of private messages can be handled as a sidebar with just 1478 two participants, identical to the example in section 1479 Section 8.1.2.1. The other context, referred to as whisper, in this 1480 document refers to situations involving one time media targetted to 1481 specific user(s). An example of a whisper would be a text message 1482 injected only to the conference chair or to a new participant joining 1483 a conference. 1485 Figure 40 provides an example of one user "Alice" who's chairing a 1486 fixed length conference with "Bob" and "Carol". The configuration is 1487 such that only the chair is providing a warning when there is only 10 1488 minutes left in the conference. At that time, "Alice" is moved into 1489 a sidebar created by the conferencing system and only "Alice" 1490 receives that text message announcing the 10 minute warning. 1492 Details to be added. 1494 Figure 40: Whisper 1496 When the conferencing system determines that there is only 10 minutes 1497 left in the conference which "Alice" is chairing, rather than 1498 creating a reservation as was done for the sidebar in 1499 Section 8.1.2.1, the conferencing system directly creates an active 1500 chat sidebar conference, based on the active chat conference 1501 associated with "Alice". As discussed previously, the sidebar 1502 conference is NOT independent of the active conference (i.e., 1503 parent). The conferencing system also allocates a conference ID to 1504 be used for any subsequent manipulations of the sidebar chat 1505 conference. The conferencing system maintains the mapping between 1506 this conference ID and the conference object ID associated with the 1507 active sidebar conference through the conference instance. 1509 Immediately upon creation of the active chat sidebar conference, the 1510 text announcement is provided to "Alice". Depending upon the 1511 policies, Alice may be notified of her addition to the sidebar via 1512 the conference notification service. "Alice" continues to receive 1513 the text messages from the main conference. 1515 Upon delivery of the text announcement, "Alice" is removed from the 1516 sidebar and the sidebar conference is deleted. Depending upon the 1517 policies, "Alice" may be notified of her removal from the sidebar via 1518 the conference notification service. 1520 (CCMP Messaging details not available yet. 1521 Plan is to reference detailed flows in 1522 previous sections.) 1524 Figure 41: Chatroom Sidebar Messaging Details 1526 9. IANA Considerations 1528 This document has no IANA considerations. 1530 10. Security Considerations 1532 The security considerations applicable to the implementation of these 1533 call flows is documented in the XCON Framework, with additional 1534 security considerations documented in the CCMP document. Where 1535 applicable, statements with regards to the necessary security are 1536 discussed in particular flows, however, since this is only an 1537 informational document, readers are strongly recommended to carefully 1538 consider the security considerations defined in the XCON Framework 1539 and the CCMP document. 1541 11. Change Summary 1543 The following are the major changes between the 00 and the 01 1544 versions of the draft: 1546 o TBD based on WG feedback. 1548 12. Acknowledgements 1550 The detailed content for this document is derived from the prototype 1551 work of Lorenzo Miniero, Simon Pietro-Romano, Tobia Castaldi and 1552 their colleagues at the University of Napoli. 1554 13. References 1556 13.1. Normative References 1558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1559 Requirement Levels", BCP 14, RFC 2119, March 1997. 1561 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1562 Centralized Conferencing", RFC 5239, June 2008. 1564 [I-D.ietf-xcon-ccmp] 1565 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 1566 "Centralized Conferencing Manipulation Protocol", 1567 draft-ietf-xcon-ccmp-01 (work in progress), November 2008. 1569 13.2. Informative References 1571 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1572 A., Peterson, J., Sparks, R., Handley, M., and E. 1573 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1574 June 2002. 1576 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1577 with Session Description Protocol (SDP)", RFC 3264, 1578 June 2002. 1580 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1581 Jacobson, "RTP: A Transport Protocol for Real-Time 1582 Applications", STD 64, RFC 3550, July 2003. 1584 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1585 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1587 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1588 the Session Description Protocol (SDP)", RFC 4145, 1589 September 2005. 1591 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1592 (SIP) Call Control - Conferencing for User Agents", 1593 BCP 119, RFC 4579, August 2006. 1595 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 1596 RFC 4597, August 2006. 1598 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1599 Control Protocol (BFCP)", RFC 4582, November 2006. 1601 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 1602 Floor Control Protocol (BFCP)", RFC 5018, September 2007. 1604 [I-D.ietf-xcon-event-package] 1605 Camarillo, G., Srinivasan, S., Even, R., and J. 1606 Urpalainen, "Conference Event Package Data Format 1607 Extension for Centralized Conferencing (XCON)", 1608 draft-ietf-xcon-event-package-01 (work in progress), 1609 September 2008. 1611 [I-D.ietf-xcon-common-data-model] 1612 Novo, O., Camarillo, G., Morgan, D., Even, R., and J. 1613 Urpalainen, "Conference Information Data Model for 1614 Centralized Conferencing (XCON)", 1615 draft-ietf-xcon-common-data-model-12 (work in progress), 1616 October 2008. 1618 [I-D.miniero-mediactrl-escs] 1619 Amirante, A., Castaldi, T., Miniero, L., and S. Romano, 1620 "Media Control Channel Framework (CFW) Call Flow 1621 Examples", draft-miniero-mediactrl-escs-03 (work in 1622 progress), November 2008. 1624 [I-D.ietf-mediactrl-architecture] 1625 Melanchuk, T., "An Architectural Framework for Media 1626 Server Control", draft-ietf-mediactrl-architecture-04 1627 (work in progress), November 2008. 1629 [I-D.ietf-mediactrl-sip-control-framework] 1630 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1631 Control Channel Framework", 1632 draft-ietf-mediactrl-sip-control-framework-10 (work in 1633 progress), February 2009. 1635 [I-D.boulton-mmusic-sdp-control-package-attribute] 1636 Boulton, C., "A Session Description Protocol (SDP) Control 1637 Package Attribute", 1638 draft-boulton-mmusic-sdp-control-package-attribute-03 1639 (work in progress), August 2008. 1641 [I-D.boulton-ivr-control-package] 1642 Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic 1643 Interactive Voice Response (IVR) Control Package for the 1644 Media Control Channel Framework", 1645 draft-boulton-ivr-control-package-06 (work in progress), 1646 February 2008. 1648 [I-D.boulton-conference-control-package] 1649 Boulton, C., Melanchuk, T., McGlashan, S., and A. 1650 Shiratzky, "A Conference Control Package for the Media 1651 Control Channel Framework", 1652 draft-boulton-conference-control-package-04 (work in 1653 progress), February 2008. 1655 [I-D.miniero-bfcp-control-package] 1656 Miniero, L., Romano, S., Even, R., and S. McGlashan, "A 1657 Binary Floor Control Protocol (BFCP) Control Package for 1658 the Media Control Channel Framework", 1659 draft-miniero-bfcp-control-package-01 (work in progress), 1660 July 2008. 1662 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1663 April 2000. 1665 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1666 Protocol (XMPP): Core", RFC 3920, October 2004. 1668 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1669 Session Initiation Protocol (SIP)", RFC 4353, 1670 February 2006. 1672 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1673 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1675 [I-D.ietf-simple-chat] 1676 Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1677 party Chat Using the Message Session Relay Protocol 1678 (MSRP)", draft-ietf-simple-chat-03 (work in progress), 1679 October 2008. 1681 [I-D.boulton-xcon-session-chat] 1682 Boulton, C. and M. Barnes, "Chatrooms within a Centralized 1683 Conferencing (XCON) System", 1684 draft-boulton-xcon-session-chat-03 (work in progress), 1685 March 2009. 1687 Authors' Addresses 1689 Mary Barnes 1690 Nortel 1691 2201 Lakeside Blvd 1692 Richardson, TX 1694 Email: mary.barnes@nortel.com 1696 Chris Boulton 1697 NS-Technologies 1699 Email: chris@ns-technologies.com 1701 Lorenzo Miniero 1702 University of Napoli 1703 Via Claudio 21 1704 Napoli 80125 1705 Italy 1707 Email: lorenzo.miniero@unina.it 1709 Simon Pietro Romano 1710 University of Napoli 1711 Via Claudio 21 1712 Napoli 80125 1713 Italy 1715 Email: spromano@unina.it