idnits 2.17.1 draft-ietf-xcon-framework-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2692. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2100: '...onfidential information MUST support a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 14, 2007) is 6185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '1') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '6') (Obsoleted by RFC 5545) -- Obsolete informational reference (is this intentional?): RFC 4582 (ref. '13') (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 4583 (ref. '15') (Obsoleted by RFC 8856) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 12 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: November 15, 2007 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 May 14, 2007 10 A Framework for Centralized Conferencing 11 draft-ietf-xcon-framework-08 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 15, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines the framework for Centralized Conferencing. 45 The framework allows participants using various call signaling 46 protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in 47 a centralized unicast conference. The Centralized Conferencing 48 Framework defines logical entities and naming conventions, along with 49 a high level conferencing data model. The framework also outlines a 50 set of conferencing protocols, which are complementary to the call 51 signaling protocols, for building advanced conferencing applications. 52 The framework binds all the defined components together for the 53 benefit of builders of conferencing systems. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10 61 4.1. Conference Information . . . . . . . . . . . . . . . . . . 12 62 4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12 63 5. Centralized Conferencing Constructs and Identifiers . . . . . 13 64 5.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13 65 5.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 66 5.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 67 5.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 68 6. Conferencing System Realization . . . . . . . . . . . . . . . 16 69 6.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17 70 6.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 20 71 6.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21 72 6.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23 73 7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 74 7.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 75 7.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 76 7.3. Conference Control Protocol . . . . . . . . . . . . . . . 26 77 7.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26 78 8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28 79 8.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28 80 8.2. Participant Manipulations . . . . . . . . . . . . . . . . 30 81 8.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32 82 8.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33 83 8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35 84 8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37 85 8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40 86 8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42 87 8.7. Conference Announcements and Recordings . . . . . . . . . 44 88 8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46 89 8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46 90 9. Relationships between SIPPING and Centralized Conferencing 91 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 93 10.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 51 94 10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52 95 10.3. Floor Control Server Authentication . . . . . . . . . . . 52 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 98 13. Changes since last Version . . . . . . . . . . . . . . . . . . 53 99 14. Informative References . . . . . . . . . . . . . . . . . . . . 60 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 101 Intellectual Property and Copyright Statements . . . . . . . . . . 63 103 1. Introduction 105 This document defines the framework for Centralized Conferencing. 106 The framework allows participants using various call signaling 107 protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in 108 a centralized unicast conference. Other than references to general 109 functionality (e.g., establishment and teardown), details of these 110 call signaling protocols are outside the scope of this document. 112 The Centralized Conferencing Framework defines logical entities and 113 naming conventions, along with a high level conferencing data model. 114 The framework also outlines a set of conferencing protocols, which 115 are complementary to the call signaling protocols, for building 116 advanced conferencing applications. 118 The Centralized Conferencing Framework is compatible with the 119 functional model presented in the SIPPING Conferencing Framework [8]. 120 Section 9 of this document discusses the relationship between the 121 Centralized Conferencing Framework and the SIPPING Conferencing 122 framework, in the context of the Centralized Conferencing model 123 presented in this document. 125 2. Terminology 127 This Centralized Conferencing Framework document generalizes, when 128 appropriate, the SIPPING Conferencing Framework [8] terminology and 129 introduces new concepts, as listed below. Further details and 130 clarification of the new terms and concepts are provided in the 131 subsequent sections of this document. 133 Active conference: The term active conference refers to a conference 134 object that has been created and activated via the allocation of 135 its identifiers (e.g., conference object identifier and conference 136 identifier) and the associated focus. An active conference is 137 created based on either a system default conference blueprint or a 138 specific conference reservation. 139 Call Signaling protocol: The call signaling protocol is used between 140 a participant and a focus. In this context, the term "call" means 141 a channel or session used for media streams. 142 Conference information: The conference information includes 143 definitions for basic conference features, such as conference 144 identifiers, membership, signaling, capabilities and media types, 145 applicable to a wide range of conferencing applications. The 146 conference information also includes the media and application 147 specific data for enhanced conferencing features or capabilities, 148 such as media mixers. The conference information is the data type 149 (i.e., the XML schema) for a conference object. 151 Conference blueprint: A conference blueprint is a static conference 152 object within a conferencing system, which describes a typical 153 conference setting supported by the system. A conference 154 blueprint is the basis for creation of dynamic conference objects. 155 A system may maintain multiple blueprints. Each blueprint is 156 comprised of the initial values and ranges for the elements in the 157 object, conformant to the data schemas for the conference 158 information. 159 Conference control protocol (CCP): A conference control protocol 160 provides the interface for data manipulation and state retrieval 161 for the centralized conferencing data, represented by the 162 conference object. 163 Conference factory: A conference factory is a logical entity that 164 generates unique URI(s) to identify and represent a conference 165 focus. 166 Conference identifier (ID): A conference identifier is a call 167 signaling protocol-specific URI that identifies a conference focus 168 and its associated conference instance. 169 Conference instance: A conference instance refers to an internal 170 implementation of a specific conference, represented as a set of 171 logical conference objects and associated identifiers. 172 Conference object: A conference object represents a conference at a 173 certain stage (e.g., description upon conference creation, 174 reservation, activation, etc.), which a conferencing system 175 maintains in order to describe the system capabilities and to 176 provide access to the services available for each object 177 independently. The conference object schema is based on the 178 conference information. 179 Conference object identifier (ID): A conference object identifier is 180 a URI which uniquely identifies a conference object and is used by 181 a conference control protocol to access and modify the conference 182 information. 183 Conference policies: Conference policies collectively refers to a 184 set of rights, permissions and limitations pertaining to 185 operations being performed on a certain conference object. 186 Conference reservation: A conference reservation is a conference 187 object, which is created from either a system default or client 188 selected blueprint. 189 Conference state: The conference state reflects the state of a 190 conference instance and is represented using a specific, well- 191 defined schema. 192 Conferencing system: Conferencing system refers to a conferencing 193 solution based on the data model discussed in this framework 194 document and built using the protocol specifications referenced in 195 this framework document. 197 Conference user identifier (ID): A unique identifier for a user 198 within the scope of a conferencing system. A user may have 199 multiple conference user identifiers within a conferencing system 200 (e.g., to represent different roles). 201 Floor: Floor refers to a set of data or resources associated with a 202 conference instance, for which a conference participant, or group 203 of participants, is granted temporary access. 204 Floor chair: A floor chair is a floor control protocol compliant 205 client, either a human participant or automated entity, who is 206 authorized to manage access to one floor and can grant, deny or 207 revoke access. The floor chair does not have to be a participant 208 in the conference instance. 209 Focus: A focus is a logical entity that maintains the call 210 signalling interface with each participating client and the 211 conference object representing the active state. As such, the 212 focus acts as an endpoint for each of the supported signaling 213 protocols and is responsible for all primary conference membership 214 operations (e.g., join, leave, update the conference instance) and 215 for media negotiation/maintenance between a conference participant 216 and the focus. 217 Media graph: The media graph is the logical representation of the 218 flow of media for a conference. 219 Media mixer: A media mixer is the logical entity with the capability 220 to combine media inputs of the same type, transcode the media and 221 distribute the result(s) to a single or multiple outputs. In this 222 context, the term "media" means any type of data being delivered 223 over the network using appropriate transport means, such as RTP/ 224 RTCP (defined in RFC 3550[5]) or Message Session Relay Protocol 225 (defined in [17]). 226 Role: A role provides the context for the set of conference 227 operations that a participant can perform. A default role (e.g., 228 standard conference participant) will always exist, providing a 229 user with a set of basic conference operations. Based on system 230 specific authentication and authorization, a user may take on 231 alternate roles, such as conference moderator, allowing access to 232 a wider set of conference operations. 233 Sidebar: A sidebar is a separate Conference instance that only 234 exists within the context of a parent conference instance. The 235 objective of a sidebar is to be able to provide additional or 236 alternate media only to specific participants. 237 Whisper: A whisper involves a one-time media input to a specific 238 participant(s) within a specific conference instance, accomplished 239 using a sidebar. An example of a whisper would be an announcement 240 injected only to the conference chair or to a new participant 241 joining a conference. 243 3. Overview 245 A centralized conference is an association of endpoints, called 246 conference participants, with a central endpoint, called a conference 247 Focus. The Focus has direct peer relationships with the participants 248 by maintaining a separate call signaling interface with each. 249 Consequently, in this centralized conferencing model, the call 250 signaling graph is always a star. 252 The most basic conference supported in this model would be an ad-hoc 253 unmanaged conference, which would not necessarily require any of the 254 functionality defined within this framework. For example, it could 255 be supported using basic SIP signaling functionality with a 256 participant serving as the Focus; the SIPPING Conferencing Framework 257 [8] together with the SIP Call Control Conferencing for User Agents 258 [12] documents address these types of scenarios. 260 In addition to the basic features, however, a conferencing system 261 supporting the centralized conferencing model proposed in this 262 framework document can offer richer functionality, by including 263 dedicated conferencing applications with explicitly defined 264 capabilities, reserved recurring conferences, along with providing 265 the standard protocols for managing and controlling the different 266 attributes of these conferences. 268 The core requirements for centralized conferencing are outlined in 269 [7]. These requirements are applicable for conferencing systems 270 using various call signaling protocols, including SIP. Additional 271 conferencing requirements are provided in [10], and [11]. 273 The centralizing conferencing system proposed by this framework is 274 built around a fundamental concept of a conference object. A 275 conference object provides the data representation of a conference 276 during each of the various stages of a conference (e.g., creation, 277 reservation, active, completed, etc.). A conference object is 278 accessed via the logical functional elements, with whom a 279 conferencing client interfaces, using the various protocols 280 identified in Figure 1. The functional elements defined for a 281 conferencing system described by the framework are a Conference 282 Control Server, Floor Control Server, any number of Foci and a 283 Notification Service. A Conference Control Protocol (CCP) provides 284 the interface between a conference and media control client and the 285 conference control server. A floor control protocol (e.g., BFCP) 286 provides the interface between a floor control client and the floor 287 control server. A call signaling protocol (e.g., SIP, H.323, PSTN, 288 etc.) provides the interface between a call signaling client and a 289 Focus. A notification protocol (e.g. SIP Notify) provides the 290 interface between the conferencing client and the Notification 291 Service. 293 A conferencing system can support a subset of the conferencing 294 functions depicted in the conferencing system logical decomposition 295 in Figure 1 and described in this document. However, there are some 296 essential components that would typically be used by most other 297 advanced functions, such as the Notification Service. For example, 298 the notification service is used to correlate information, such as 299 list of participants with their media streams, between the various 300 other components. 302 .................................................................... 303 . Conferencing System . 304 . . 305 . +-----------------------------------------------------+ . 306 . | C o n f e r e n c e o b j e c t | . 307 . +-+---------------------------------------------------+ | . 308 . | C o n f e r e n c e o b j e c t | | . 309 . +-+---------------------------------------------------+ | | . 310 . | C o n f e r e n c e o b j e c t | | | . 311 . | | | | . 312 . | | |-+ . 313 . | |-+ . 314 . +-----------------------------------------------------+ . 315 . ^ ^ ^ | . 316 . | | | | . 317 . v v v v . 318 . +-------------------+ +--------------+ +-------+ +------------+ . 319 . | Conference Control| | Floor Control| |Foci | |Notification| . 320 . | Server | | Server | | | |Service | . 321 . +-------------------+ +--------------+ +-------+ +------------+ . 322 . ^ ^ ^ | . 323 ..............|.................|...........|..........|............ 324 | | | | 325 |Conference |Binary |Call |Notification 326 |Control |Floor |Signaling |Protocol 327 |Protocol |Control |Protocol | 328 | |Protocol | | 329 | | | | 330 ..............|.................|...........|..........|............ 331 . V V V V . 332 . +----------------+ +------------+ +----------+ +------------+ . 333 . | Conference | | Floor | | Call | |Notification| . 334 . | and Media | | Control | | Signaling| | Client | . 335 . | Control | | Client | | Client | | | . 336 . | Client | | | | | | | . 337 . +----------------+ +------------+ +----------+ +------------+ . 338 . . 339 . Conferencing Client . 340 .................................................................... 342 Figure 1: Conferencing System Logical Decomposition. 344 The media graph of a conference can be centralized, decentralized, or 345 any combination of both and potentially differ per media type. In 346 the centralized case, the media sessions are established between a 347 media mixer controlled by the focus and each one of the participants. 348 In the decentralized (i.e., distributed) case, the media graph is a 349 multicast or multi-unicast mesh among the participants. 350 Consequently, the media processing (e.g., mixing) can be controlled 351 either by the focus alone or by the participants. The concepts in 352 this framework document clearly map to a centralized media model. 353 The concepts can also apply to the decentralized media case, however, 354 the details of such are left for future study. 356 Section 4 of this document provides more details on the conference 357 object. Section 5 provides an overview of the identifiers necessary 358 to address and manage the conference objects, instances and users 359 associated with a conferencing system. Section 6 of this document 360 describes how a conferencing system is logically built using the 361 defined high level data model and how the conference objects are 362 maintained. Section 7 describes the fundamental conferencing 363 mechanisms and provides a high level overview of the protocols. 364 Section 8 then provides realizations of various conferencing 365 scenarios, detailing the manipulation of the conference objects using 366 the defined protocols. Section 9 of this document summarizes the 367 relationship between this Centralized Conferencing Framework and the 368 SIPPING Conferencing Framework. 370 4. Centralized Conferencing Data 372 The centralized conference data is logically represented by the 373 conference object. A conference object is of type 'Conference 374 information type', as illustrated in Figure 2. The conference 375 information type is extensible. 377 +------------------------------------------------------+ 378 | C o n f e r e n c e o b j e c t | 379 | | 380 | +--------------------------------------------------+ | 381 | | Conference information type | | 382 | | | | 383 | | +----------------------------------------------+ | | 384 | | | Conference description (times, duration) | | | 385 | | +----------------------------------------------+ | | 386 | | +----------------------------------------------+ | | 387 | | | Membership (roles, capacity, names) | | | 388 | | +----------------------------------------------+ | | 389 | | +----------------------------------------------+ | | 390 | | | Signaling (protocol, direction, status) | | | 391 | | +----------------------------------------------+ | | 392 | | +----------------------------------------------+ | | 393 | | | Floor information | | | 394 | | +----------------------------------------------+ | | 395 | | +----------------------------------------------+ | | 396 | | | Sidebars, Etc. | | | 397 | | +----------------------------------------------+ | | 398 | | +----------------------------------------------+ | | 399 | | | Mixer algorithm, inputs, and outputs | | | 400 | | +----------------------------------------------+ | | 401 | | +----------------------------------------------+ | | 402 | | | Floor controls | | | 403 | | +----------------------------------------------+ | | 404 | | +----------------------------------------------+ | | 405 | | | Etc. | | | 406 | | +----------------------------------------------+ | | 407 | +--------------------------------------------------+ | 408 +------------------------------------------------------+ 410 Figure 2: Conference Object Type Decomposition. 412 In a system based on this conferencing framework, the same conference 413 object type is used for representation of a conference during 414 different stages of a conference, such as expressing conferencing 415 system capabilities, reserving conferencing resources or reflecting 416 the state of ongoing conferences. Section 6 describes the usage 417 semantics of the conference objects. The exact XML schema of the 418 conference object, including the organization of the conference 419 information is detailed in a separate document [16]. 421 Along with the basic data model as defined in [16], the realization 422 of this framework requires a policy infrastructure. The policies 423 required by this framework to manage and control access to the data 424 include local, system level boundaries associated with specific data 425 elements, such as the membership, and by the ranges and limitations 426 of other data elements. Additional policy considerations for a 427 system realization based on this data model are discussed in 428 Section 4.2. 430 4.1. Conference Information 432 There is a core set of data in the conference information that is 433 utilized in any conference, independent of the specific conference 434 media nature (e.g., the mixing algorithms performed, the advanced 435 floor control applied, etc.). This core set of data in the 436 conference information contains the definitions representing the 437 conference object capabilities, membership, roles, call signaling and 438 media status relevant to different stages of the conference life- 439 cycle. This core set of conference information may be represented 440 using the conference-type as defined in [9]. Typically, participants 441 with read-only access to the conference information would be 442 interested in this core set of conference information only. 444 In order to support more complex media manipulations and enhanced 445 conferencing features the conference information, as reflected by the 446 data model defined in [16], contains additional data beyond that 447 defined in [9]. The information defined in [16] provides specific 448 media mixing details, available floor controls and other data 449 necessary to support enhanced conferencing features. This 450 information allows authorized clients to manipulate the mixer's 451 behavior via the focus, with the resultant distribution of the media 452 to all or individual participants. By doing so, a client can change 453 its own state and/or state of other participants in the conference. 455 New centralized conferencing specifications can extend the basic 456 conference-type as defined in [16] and introduce additional data 457 elements to be used within the conference information type. 459 4.2. Conference policies 461 Conference policies collectively refers to a set of rights, 462 permissions and limitations pertaining to operations being performed 463 on a certain conference object. 465 The set of rights describes the read/write access privileges for the 466 conference object as a whole. This access would usually be granted 467 and defined in terms of giving the read-only or read-write access to 468 clients with certain roles in the conference. Managing this access 469 would require a conferencing system have access to basic policy 470 information to make the decisions, but doesn't necessarily require an 471 explicit representation in the policy model. As such, for this 472 framework document, the policies represented by the set of rights are 473 reflected in the system realization (Section 6). 475 The permissions and limits require explicit policy mechanisms and are 476 outside the scope of the data model [16] and this framework document. 478 5. Centralized Conferencing Constructs and Identifiers 480 This section provides details of the identifiers associated with the 481 centralized conferencing framework constructs and the identifiers 482 necessary to address and manage the clients associated with a 483 conferencing system. An overview of the allocation, characteristics 484 and functional role of the identifiers is provided. 486 5.1. Conference Identifier 488 The conference identifier (conference ID) is a call signaling 489 protocol-specific URI that identifies a specific conference focus and 490 its associated conference instance. A conference factory is one 491 method for generating a unique conference ID, to identify and address 492 a conference focus, using a call signaling interface. Details on the 493 use of a conference factory for SIP signaling can be found in [12]. 494 The conference identifier can also be obtained using the conference 495 control protocol or other, including proprietary, out-of-band 496 mechanisms. 498 5.2. Conference Object 500 A Conference object provides the logical representation of a 501 conference instance in a certain stage, such as a conference 502 blueprint representing a conferencing system's capabilities, the data 503 representing a conference reservation, and the conference state 504 during an active conference. Each conference object is independently 505 addressable through the conference control protocol interface 506 [Section 7.3]. 508 Figure 3 illustrates the relationships between the conference 509 identifier, the focus and the conference object ID within the context 510 of a logical conference instance, with the conference object 511 corresponding to an active conference. 513 A conference object representing a conference in the active state can 514 have multiple call signaling conference identifiers; for example, for 515 each call signaling protocol supported. There is a one-to-one 516 mapping between an active conference object and a conference focus. 517 The focus is addressed by explicitly associating unique conference 518 IDs for each signaling protocol supported by the active conference 519 object. 521 .................................................................... 522 . Conference Instance . 523 . . 524 . . 525 . +---------------------------------------------------+ . 526 . | Conference Object Identifier | . 527 . | | . 528 . | | . 529 . +---------------------------------------------------+ . 530 . ^ ^ . 531 . | | . 532 . v | . 533 . ................................................... | . 534 . . Focus . | . 535 . . . | . 536 . . +----------------------------------+ . | . 537 . . |Conference Identifier (Protocol Y)| . | . 538 . . +------------------------------------+ | . | . 539 . . | Conference Identifier (PSTN) | | . | . 540 . . +--------------------------------------+ |-+ . | . 541 . . | Conference Identifier (SIP) | |^ . | . 542 . . | |-+| . | . 543 . . | |^ | . | . 544 . . +--------------------------------------+| | . | . 545 . ............^...............................|.|.... | . 546 . | | | | . 547 ................|...............................|.|......|.......... 548 | | | | 549 |SIP | | |Conference 550 | PSTN | |Y |Control 551 | | | |Protocol 552 | +---------------+ | | 553 | | | | 554 | | | | 555 v v v v 556 +----------------+ +--------------+ +---------------+ 557 | Conferencing | | Conferencing | | Conference | 558 | Client | | Client | | Client | 559 | 1 | | 2 | | X | 560 +----------------+ +--------------+ +---------------+ 562 Figure 3: Identifier Relationships for an Active Conference. 564 5.2.1. Conference Object Identifier 566 In order to make each conference object externally accessible, the 567 conferencing system allocates a unique URI per distinct conference 568 object in the system. The conference object identifier is created 569 both by the conferencing system based on internal actions as well as 570 based on specific conference protocol requests. A conferencing 571 system will allocate a conferencing object identifier for every 572 conference blueprint, for every conference reservation and for every 573 active conference. The distribution of the conference object 574 identifier depends upon the specific use case and includes a variety 575 of mechanisms, such as the through the conference control protocol 576 mechanism, the data model and conference package or out of band 577 mechanisms such as E-Mail. 579 When a user wishes to create or join a conference and the user does 580 not have the conference object identifier for the specific 581 conference, more general signaling mechanisms apply, such that a user 582 may have a pre-configured conference object identifier to access the 583 conferencing system or other signaling protocols may be used and the 584 conferencing system maps those to a specific conference object 585 identifier. Once a conference is established, a conference object 586 identifier is required for the user to manipulate any of the 587 conferencing data or take advantage of any of the advanced 588 conferencing features. The same notion applies to users joining a 589 conference using other signaling protocols. They are able to 590 initially join a conference using any of the other signaling 591 protocols supported by the specific conferencing system, but the 592 conference object identifer must be used to manipulate any of the 593 conferencing data or take advantage of any of the advanced 594 conferencing features. As mentioned previously, the mechanism by 595 which the user learns of the conference object identifier varies and 596 could be via the conference control protocol, using the data model 597 and conference package or entirely out of band such as E-Mail or a 598 web interface. 600 The conference object identifier logically maps to other protocol 601 specific identifiers associated with the conference instance, such as 602 the BFCP 'confid'. The conference object identifier is defined in 603 [16]. 605 5.3. Conference User Identifier 607 Each user within a conferencing system is allocated a unique 608 conference user identifier. The user identifier is used in 609 association with the conference object identifier to uniquely 610 identify a user within the scope of conferencing system. There is 611 also a requirement for identifying conferencing system users who may 612 not be participating in a conference instance. Examples of these 613 users would be a non participating 'Floor Control Chair' or 'Media 614 Policy Controller'. The conference user identifier is required in 615 conference control protocol requests to uniquely determine who is 616 issuing commands, so that appropriate policies can be applied to the 617 requested command. 619 A typical mode for distributing the user identifer is out of band 620 during conferencing client configuration, thus the mechanism is 621 outside the scope of the centralized conferencing framework and 622 protocols. However, a conferencing system must also be capable of 623 allocating and distributing a user identifier during the first 624 signaling interaction with the conferencing system, such as an 625 initial request for blueprints or adding a new user to an existing 626 conference using the conference control protocol. When a user joins 627 a conference using a signaling specific protocol, such as SIP for a 628 dial-in conference, a conference user identifier must be assigned if 629 one is not already associated with that user. While this conference 630 user identifier isn't required for the participant to join the 631 conference, it is required to be allocated and assigned by the 632 conferencing system such that it is available for use for any 633 subsequent conference control protocol operations and/or 634 notifications associated with that conference. For example, the 635 conference user identifer would be sent in any notifications that may 636 be sent to existing participants, such as the moderator, when this 637 user joins. 639 The conference user identifier is logically associated with the other 640 user identifiers assigned to the conferencing client for other 641 protocol interfaces, such as an authenticated SIP user. The 642 conference user identifier is defined in [16]. 644 6. Conferencing System Realization 646 Implementations based on this centralized conferencing framework can 647 range from systems supporting ad-hoc conferences, with default 648 behavior only, to sophisticated systems with the ability to schedule 649 recurring conferences, each with distinct characteristics, being 650 integrated with external resource reservation tools, and providing 651 snapshots of the conference information at any of the stages of the 652 conference life-cycle. 654 A conference object is the logical representation of a conference 655 instance at a certain stage, such as capabilities description upon 656 conference creation, reservation, activation, etc., which a 657 conferencing system maintains in order to describe the system 658 capabilities and to provide access to the available services provided 659 by the conferencing system. Consequently, this centralized 660 conferencing framework does not mandate the actual usage of the 661 conference object, but rather defines the general cloning tree 662 concept and the mechanisms required for its realization, as described 663 in detail in Section 6.1. 665 Adhoc and advanced conferencing examples are provided in Section 6.2 666 and Section 6.3, with the latter providing additional description of 667 the Conference Object in terms of the stages of a conference, to 668 support scheduled and other advanced conference capabilities. The 669 scheduling of a conference based on these concepts and mechanisms is 670 then detailed in Section 6.4 672 As discussed in Section 4.2, the overall policy in terms of 673 permissions and limitations is outside the scope of this framework 674 document. The policies applicable to the conference object as a 675 whole in terms of read/write access would require a conferencing 676 system have access to basic policy information to make the decisions. 677 In the examples in this section, the policies are shown logically 678 associated with the conference objects to emphasize the general 679 requirement for policy functionality necessary for the realization of 680 this framework. 682 6.1. Cloning Tree 684 The concept defined in this section is a logical representation only, 685 as it is reflected through the centralized conferencing mechanisms: 686 the URIs and the protocols. Of course, the actual system realization 687 can differ from the presented model. The intent is to illustrate the 688 role of the logical elements in providing an interface to the data, 689 based on conferencing system and conferencing client actions, and 690 describe the resultant protocol implications. 692 Any conference object in a conferencing system is created by either 693 being explicitly cloned from an existing parent object or being 694 implicitly cloned from a default system conference blueprint. A 695 conference blueprint is a static conference object used to describe a 696 typical conference setting supported by the system. Each system can 697 maintain multiple blueprints, typically each describing a different 698 conferencing type using the conference information format. This 699 document uses the "cloning" metaphor instead of the "inheritance" 700 metaphor because it more closely fits the idea of object replication, 701 rather than a data type re-usage and extension concept. 703 The cloning operation needs to specify whether the link between the 704 parent and the child needs to be maintained in the system or not. If 705 no link between the parent and the child exists, the objects become 706 independent and are not impacted by any operations on the parent 707 object nor subject to any limitations of the parent object. 709 Once the new object is created, it can be addressed by a unique 710 conference object URI assigned by the system, as described in 711 Section 5.2.1. By default, the newly created object contains all the 712 data existing in the parent object. The newly created object can 713 expand the data it contains, within the schema types supported by the 714 parent. It can also restrict the read/write access to its objects. 715 However, unless the object is independent, it cannot modify the 716 access restrictions imposed by the parent object. 718 Any piece of data in the child object can be independently accessed 719 and, by default, can be independently modified without affecting the 720 parent data. 722 Unless the object is independent, the parent object can enforce a 723 different policy by marking certain data elements as "parent 724 enforceable". The values of these data elements can not be changed 725 by directly accessing the child object; neither can they be expanded 726 in the child object alone. 728 Figure 4 illustrates an example of a conference (Parent B), which is 729 created independent of its Parent (Parent A). Parent B creates two 730 child objects, Child 1 and Child 2. Any of the data elements of 731 Parent B can be modified (i.e. there are no "parent enforceable" data 732 elements) and depending upon the element, the changes will be 733 reflected in Child 1 and Child 2 , whereas changes to Parent A will 734 not impact the data elements of Parent B. Any "parent enforceable" 735 data elements as defined by Parent B cannot be modified in the child 736 objects. 738 +---+-----------------------+ 739 | p | | 740 | o | P A R E N T A | 741 | l | | 742 | i | C O N F E R E N C E | 743 | c | | 744 | i | O B J E C T | 745 | e | | 746 +-s-+-----------------------+ 747 | 748 \| / 749 \/ INDEPENDENT 750 /\ 751 /| \ 752 V 753 +---+-----------------------+ 754 | p | | 755 | o | P A R E N T B | 756 | l | | 757 | i | C O N F E R E N C E | 758 | c | | 759 | i | O B J E C T | 760 | e | | 761 +-s-+-----------------------+ 762 | | 763 | | 764 | --------------------------- 765 | | 766 V V 767 +---+-----------------------+ +---+-----------------------+ 768 | p | | | p | | 769 | o | C H I L D 1 | | o | C H I L D 2 | 770 | i | | | l | | 771 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 772 | i | | | c | | 773 | c | O B J E C T | | i | O B J E C T | 774 | i | | | e | | 775 +-s-+-----------------------+ +-s-+-----------------------+ 777 Figure 4: The Cloning Tree. 779 Using the defined cloning model and its tools, the following sections 780 show examples of how different systems based on this framework can be 781 realized. 783 6.2. Ad-hoc Example 785 Figure 5 illustrates how an ad-hoc conference can be created and 786 managed in a conferencing system. A client can create a conference 787 by establishing a call signaling channel with a conference factory as 788 specified in Section 5.1. The conference factory can internally 789 select one of the system supported conference blueprints based on the 790 requesting client privileges and the media lines included in the SDP 791 body. 793 The selected blueprint with its default values is copied by the 794 server into a newly created conference object, referred to as an 795 'Active Conference'. At this point the conference object becomes 796 independent from its blueprint. A new conference object identifier, 797 a new conference identifier and a new focus are allocated by the 798 server. 800 During the conference lifetime, an authorized client can manipulate 801 the conference object, such as adding participants, using the 802 Conference Control Protocol. 804 +---+-----------------------+ 805 | p | | 806 | o | System Default | 807 | l | | 808 | i | Conference | 809 | c | | 810 | i | Blueprint | 811 | e | | 812 +-s-+-----------------------+ 813 | 814 \| / 815 \/ 816 /\ 817 /| \ 818 V 819 +---+-----------------------+ 820 | p | | 821 | o | Active | 822 | l | | 823 | i | Conference | 824 | c | | 825 | i | | 826 | e | | 827 +-s-+-----------------------+ 828 Figure 5: Conference Ad-hoc Creation and Lifetime. 830 6.3. Advanced Example 832 Figure 6 illustrates how a recurring conference can be specified 833 according to system capabilities, scheduled, reserved, and managed in 834 a conferencing system. A client would first query a conferencing 835 system for its capabilities. This can be done by requesting a list 836 of the conference blueprints the system supports. Each blueprint 837 contains a specific combination of capabilities and limitations of 838 the conference server in terms of supported media types (e.g., audio, 839 video, text, or combinations of these), participant roles, maximum 840 number of participants of each role, availability of floor control, 841 controls available for participants, availability and type of 842 sidebars, the definitions and names of media streams, etc. 844 The selected blueprint with its default values is cloned by the 845 client into a newly created conference object, referred to as a 846 conference reservation, that specifies the resources needed from the 847 system for this conference instance. At this point the conference 848 reservation becomes independent from its blueprint. The client can 849 also change the default values, within the system ranges, and add 850 additional information, such as the list of participants and the 851 conference start time, to the conference reservation. 853 At this point the client can ask the conference server to create new 854 conference reservations by attaching the conference reservation to 855 the request. As a result, the server can allocate the needed 856 resources, create the additional conference objects for the child 857 conference reservations and allocate the conference object 858 identifiers for all - the original conference reservation and for 859 each child conference reservation. 861 From this point on, any authorized client is able to access and 862 modify each of the conference objects independently. By default, 863 changes to an individual child conference reservation will affect 864 neither the parent conference reservation, from which it was created, 865 nor its siblings. 867 On the other hand, some of the conference sub-objects, such as the 868 maximum number of participants and the participants list, can be 869 defined by the system as parent enforceable. As a result, these 870 objects can be modified by accessing the parent conference 871 reservation only. The changes to these objects can be applied 872 automatically to each of the child reservations, subject to local 873 policy. 875 +---+-----------------------+ 876 | p | | 877 | o | Selected | 878 | l | | 879 | i | Conference | 880 | c | | 881 | i | Blueprint | 882 | e | | 883 +-s-+-----------------------+ 884 | 885 \| / 886 \/ 887 /\ 888 /| \ 889 V 890 +---+-----------------------+ 891 | p | | 892 | o | Conference | 893 | l | | 894 | i | Reservation | 895 | c | | 896 | i | | 897 | e | | 898 +-s-+-----------------------+ 899 | | | 900 | | | 901 | | | 902 | | | 903 +---|--|--V-----------------+ 904 +-+---|--V------------------+ | 905 +-+-+---V-------------------+ | | 906 | p | | | | 907 | o | Child Conference | | | 908 | l | | | | 909 | i | Reservation | | | 910 | c | | | | 911 | i | | |-+ 912 | e | |-+ 913 +-s-+-----------------------+ 915 Figure 6: Advanced Conference Definition, Creation, and Lifetime. 917 When the time comes to schedule the conference reservation, either 918 via the system determination that the 'start' time has been reached 919 or via client invocation, an active conference is cloned based on the 920 conference reservation. As in the adhoc example, the active 921 conference is independent from the parent and changes to the 922 conference reservation will not impact the active conference. Any 923 desired changes must be targeted towards the active conference. An 924 example of this interaction is shown in Section 8.1 926 6.4. Scheduling a conference 928 The capability to schedule conferences forms an important part of the 929 conferencing system solution. An individual conference reservation 930 typically has a specified 'start' and 'end' time, with the times 931 being specified relative to a single specified 'fixed' time (e.g., 932 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 933 considerations. In most advanced conferencing solutions it is 934 possible to not only schedule an individual occurrence of a 935 conference reservation, but also schedule a series of related 936 conferences (e.g., a weekly meeting that starts on Thursday at 09.00 937 GMT). 939 To be able to achieve such functionality, a conferencing system needs 940 to be able to appropriately schedule and maintain conference 941 reservations that form part of a recurring conference. The mechanism 942 proposed in this document makes use of the 'Internet Calendaring and 943 Scheduling Core Object' specification defined in RFC2445[6] in union 944 with the concepts introduced in Section 4 for the purpose of 945 achieving advanced conference scheduling capability. 947 Figure 7 illustrates a simplified view of a client interacting with a 948 conferencing system. The client is using the Conference Control 949 Protocol to add a new conference reservation to the conferencing 950 system by interfacing with the conference control server. A CCP 951 request contains a valid conference reservation and reference by 952 value to an 'iCal' object which contains scheduling information about 953 the conference (e.g., start time, end time). 955 +--------------+ +-------Conferencing System-----------------+ 956 | Generic ICAL | | | 957 | Resource | | ..Conference Instance.... | 958 +--------------+ | . . +-----------+| 959 ^ ^ | . +-------------------+ . | Conference|| 960 | | | . |Conference Objects |<--| Control || 961 | ----------------->. +-------------------+ . | Server || 962 | | . . +-----------+| 963 | | ......................... ^ | 964 | | ^ | | 965 +-----|--------------+ | | | 966 | v | | | 967 | +--------------+ | | | 968 | | Resource |<------------------+ | | 969 | | Scheduler | | | 970 | +--------------+ | | 971 | | | 972 +---------------------------------------------------------|------+ 973 | 974 | 975 +-Request-+ 976 | | 977 +----+ | 978 |ICAL| | 979 +----+----+ 980 | 981 | 982 | 983 Conference Control| 984 Protocol | 985 | 986 +-------------+ 987 | Conferencing| 988 | Client | 989 +-------------+ 991 Figure 7: Resource Scheduling 993 A CCP request to create a new conference reservation is validated, 994 including the associated iCal object, and the resultant conference 995 reservation is created. The conference reservation is uniquely 996 represented within the conferencing system by a conference object 997 identifier (e.g., xcon:hd87928374) as introduced in Section 5.2.1 and 998 defined in [16]. This unique URI is returned to the client and can 999 be used to reference the conference reservation, if any future 1000 manipulations are required (e.g., alter start time), using a CCP 1001 request. 1003 The previous example explains how a client creates a basic conference 1004 reservation using an iCal reference in association with a conference 1005 control protocol. Figure 7 can also be applied when explaining how a 1006 series of conferences are scheduled in the system. The description 1007 is almost identical with the exception that the iCal definition that 1008 is included in a CCP request represents a series of recurring 1009 conference instances (e.g., conference start time, end time, occur 1010 weekly). The conferencing system will treat this request the same as 1011 the first example. The CCP request will be validated, along with the 1012 associated iCal object, and the conference reservation is created. 1013 The conference reservation and its conference object ID created for 1014 this example represent the entire series of recurring conference 1015 instances rather than a single Conference. If the client uses the 1016 conference object ID provided and a CCP request to adjust the 1017 conference reservation, every conference instance in the series will 1018 be altered. This includes all future occurrences, such as a 1019 conference scheduled as an infinite series, subject to the 1020 limitations of the available calendaring interface. 1022 A conferencing system that supports the scheduling of a series of 1023 conference instances should also be able to support manipulation 1024 within a specific range of the series. A good example is a 1025 conference reservation that has been scheduled to occur every Monday 1026 at 09.00 GMT. For the next three weeks only, the meeting has been 1027 altered to occur at 10.00 GMT in an alternative venue. With Figure 7 1028 in mind, the client will construct a CCP request whose purpose is to 1029 modify the existing conference reservation for the recurring 1030 conference instance. The client will include the conference object 1031 ID provided by the conferencing system to explicitly reference the 1032 conference reservation within the conferencing system. A CCP request 1033 will contain all the required changes to the conference reservation 1034 (e.g., change of venue). 1036 The conferencing system matches the incoming CCP request to the 1037 existing conference reservation but identifies that the associated 1038 iCal object only refers to a range of the existing series. The 1039 conferencing system creates a child, by cloning the original 1040 conference reservation, to represent the altered conference instances 1041 within the series. The cloned child object is not independent of the 1042 original parent object, thus preventing any potential conflicts in 1043 scheduling (e.g., a change to the whole series 'start time'). The 1044 cloned conference reservation, representing the altered series of 1045 conference instances, has its own associated conference object ID 1046 which is returned to the client using a CCP response. This 1047 conference object ID is then used by the client to make any future 1048 alterations on the newly defined sub-series. This process can be 1049 repeated any number of times as the newly returned conference object 1050 ID representing an altered (cloned) series of conference instances, 1051 can itself be manipulated using a CCP request for the newly created 1052 conference object ID . This provides a flexible approach to the 1053 scheduling of recurring conference instances. 1055 7. Conferencing Mechanisms 1057 7.1. Call Signaling 1059 The focus is the central component of the conference. Participants 1060 interface with the focus using an appropriate call signaling protocol 1061 (CSP). Participants request to establish or join a conference using 1062 the CSP. After checking the applicable policies, a focus then either 1063 accepts the request, sends a progress indication related to the 1064 status of the request (e.g., for a parked call while awaiting 1065 moderator approval to join) or rejects that request using the call 1066 signaling interface. 1068 During an active conference, a Conference Control Protocol can be 1069 used to affect the conference state. For example, CCP requests to 1070 add and delete participants are communicated to the focus and checked 1071 against the conference policies. If approved, the participants are 1072 added or deleted using the call signaling to/from the focus. 1074 7.2. Notifications 1076 A conferencing system is responsible for implementing a Conference 1077 Notification Service. The Conference Notification Service provides 1078 updates about the conference instance state to authorized parties, 1079 including participants. A model for notifications using SIP is 1080 defined in [4] with the specifics to support conferencing defined in 1081 [9]. 1083 The conference user identifier and associated role are used by the 1084 conferencing system to filter the notifications such that they 1085 contain only information that is allowed to be sent to that user. 1087 7.3. Conference Control Protocol 1089 The conference control protocol provides for data manipulation and 1090 state retrieval for the centralized conferencing data, represented by 1091 the conference object. The details of the conference control 1092 protocol are provided in separate documents. 1094 7.4. Floor Control 1096 A floor control protocol allows an authorized client to manage access 1097 to a specific floor and to grant, deny or revoke access of other 1098 conference users to that floor. Floor control is not a mandatory 1099 mechanism for a conferencing system implementation but provides 1100 advanced media input control features for conference users. A 1101 mechanism for floor control within a conferencing system is defined 1102 in the Binary Floor Control Protocol specification [13]. 1104 Within this framework, a client supporting floor control needs to 1105 obtain information for connecting to a floor control server to enable 1106 it to issue floor requests. This connection information can be 1107 retrieved using information provided by mechanisms such as 1108 negotiation using the SDP[1] offer/answer[3] exchange on the 1109 signaling interface with the focus. Section 10.3 provides a 1110 discussion of client authentication of a floor control server. 1112 As well as the client to the floor control server connection 1113 information, a client wishing to interact with a floor control server 1114 requires access to additional information. This information 1115 associates floor control interactions with the appropriate floor 1116 instance. Once a connection has been established and authenticated 1117 (see [13] for authentication details), a specific floor control 1118 message requires detailed information to uniquely identify a 1119 conference, a user and a floor. 1121 The conference is uniquely identifed by the conference object ID per 1122 Section 5.2.1. This conference object ID must be included in all 1123 floor control messages. When the SDP model is used as described in 1124 [15] this identifier maps to the 'confid' SDP attribute. 1126 Each authorized user associated with a conference object is uniquely 1127 represented by a conference user ID per Section 5.3. This conference 1128 user ID must be included in all floor control messages. When using 1129 SDP offer/answer exchange to negotiate a Floor control connection 1130 with the focus using the call signaling protocol, the unique 1131 conference user identifier is contained in the 'userid' SDP 1132 attribute, as defined in [15] 1134 A media session within a conferencing system can have any number of 1135 floors (0 or more) that are represented by the conference identifier. 1136 When using SDP offer/answer exchange to negotiate a floor control 1137 connection with the focus using the call signaling interface, the 1138 unique conference identifier is contained in the 'floorid' SDP 1139 attribute, as defined in [15] e.g., a=floorid:1 m-stream:10 . Each 1140 'floorid' attribute, representing a unique floor, has an 'm-stream' 1141 tag containing one or more identifiers. The identifiers represent 1142 individual SDP media sessions (as defined using 'm=' from SDP) using 1143 the SDP 'Label' attribute as defined in [14]. 1145 8. Conferencing Scenario Realizations 1147 This section addresses how advanced conferencing scenarios, many of 1148 which have been described in [11], are realized using this 1149 centralized conferencing framework. The objective of this section is 1150 to further illustrate the model, mechanisms and protocols presented 1151 in the previous sections and also serves to validate that the model, 1152 mechanisms and protocols are sufficient to support advanced 1153 conferencing scenarios. 1155 The scenarios provide a high level primitive view of the necessary 1156 operations and general logic flow. The details shown in the 1157 scenarios are for illustrative purposes only and don't necessarily 1158 reflect the actual structure of the conference control protocol 1159 messages nor the detailed data, including states, which are defined 1160 in separate documents. It should be noted that not all entities 1161 impacted by the request are shown in the diagram (e.g., Focus), but 1162 rather the emphasis is on the new entities introduced by this 1163 centralized conferencing framework. 1165 8.1. Conference Creation 1167 There are different ways to create a conference. A participant can 1168 create a conference using call signaling means only, such as SIP and 1169 detailed in [12]. For a conferencing client to have more flexibility 1170 in defining the charaterisitics and capabilities of a conference, a 1171 conferencing client would implement a conference control protocol 1172 client. By using a conference control protocol, the client can 1173 determine the capabilities of a conferencing system and its various 1174 resources. 1176 Figure 8 provides an example of one client "Alice" determining the 1177 conference blueprints available for a particular conferencing system 1178 and creating a conference based on the desired blueprint. 1180 +--------------------------------+ 1181 | Conferencing System | 1182 "Alice" | +------------+| 1183 +--------+ | | || 1184 | |CCP Request | +-----------+ | || 1185 | Client |-------------------------->|Conference | |Conference || 1186 | |<--------------------------|Control |~~~>|Blueprint(s)|| 1187 +--------+CCP Response | | 1191 "Alice" | 1192 +--------+ | | 1193 | |CCP Request |Conference | |Conference || 1196 | | confUserID> | |Control |~~~>|BlueprintA || 1197 | |<--------------------------|Server | | || 1198 | |CCP Response | | | +------------+| 1199 +--------+ | | | /|\ | 1201 | | | V | 1202 | | | +------------+| 1203 | | |~~~>|Conference || 1204 | | | |Reservation || 1205 | +-----------+ +------------+| 1206 "Alice" | | | 1207 +--------+ | | | 1208 | |CCP Request |Conference | |Active || 1211 | | confID,confUserID> | |Control |~~~>|Conference || 1212 | |<--------------------------|Server | | || 1213 | |CCP Response | | | +------------+| 1214 +--------+ | +-----------+ | 1216 +--------------------------------+ 1218 Figure 8: Client Creation of Conference using Blueprints 1220 Upon receipt of the Conference Control Protocol request for 1221 blueprints, the conferencing system would first authenticate "Alice" 1222 (and allocate a conference user identifier, if necessary) and then 1223 ensure that "Alice" has the appropriate authority based on system 1224 policies to receive any blueprints supported by that system. Any 1225 blueprints that "Alice" is authorized to use are returned in a 1226 response, along with the conference user ID. 1228 Upon receipt of the Conference Control Protocol response containing 1229 the blueprints, "Alice" determines which blueprint to use for the 1230 conference to be created. "Alice" creates a conference object based 1231 on the blueprint (i.e., clones) and modifies applicable fields, such 1232 as membership list and start time. "Alice" then sends a request to 1233 the conferencing system to create a conference reservation based upon 1234 the updated blueprint. 1236 Upon receipt of the Conference Control Protocol request to "reserve" 1237 a conference based upon the blueprint in the request, the 1238 conferencing system ensures that the blueprint received is a valid 1239 blueprint (i.e. the values of the various field are within range). 1240 The conferencing system determines the appropriate read/write access 1241 of any users to be added to a conference based on this blueprint 1242 (using membership, roles, etc.). The conferencing system uses the 1243 received blueprint to clone a conference reservation. The 1244 conferencing system also reserves or allocates a conference ID to be 1245 used for any subsequent protocol requests from any of the members of 1246 the conference. The conferencing system maintains the mapping 1247 between this conference ID and the conference object ID associated 1248 with the reservation through the conference instance. 1250 Upon receipt of the conference control protocol response to reserve 1251 the conference, "Alice" can now create an active conference using 1252 that reservation or create additional reservations based upon the 1253 existing reservations. In this example, "Alice" has reserved a 1254 meetme conference bridge. Thus, "Alice" provides the conference 1255 information, including the necessary conference ID, to desired 1256 participants. When the first participant, including "Alice", 1257 requests to be added to the conference, an active conference and 1258 focus are created. The focus is associated with the conference ID 1259 received in the request. Any participants that have the authority to 1260 manipulate the conference would receive the conference object 1261 identifier of the active conference object in the response. 1263 8.2. Participant Manipulations 1265 There are different ways to affect a participant state in a 1266 conference. A participant can join and leave the conference using 1267 call signaling means only, such as SIP. This kind of operation is 1268 called "1st party signaling" and does not affect the state of other 1269 participants in the conference. 1271 Limited operations for controlling other conference participants (a 1272 so called "3rd party control") through the Focus, using call 1273 signaling only, may also be available for some signaling protocols. 1274 For example, "Conferencing for SIP User Agents" [12] shows how SIP 1275 with REFER can be used to achieve this functionality. 1277 In order to perform richer conference control a user client needs to 1278 implement a conference control protocol client. By using a 1279 conference control protocol, the client can affect its own state, 1280 state of other participants, and state of various resources (such as 1281 media mixers) which may indirectly affect the state of any of the 1282 conference participants. 1284 Figure 9 provides an example of one client "Alice" impacting the 1285 state of another client "Bob". This example assumes an established 1286 conference. In this example, "Alice" wants to add "Bob" to the 1287 conference. 1289 +--------------------------------+ 1290 | Conferencing System | 1291 "Alice" | +---------+--+| 1292 +--------+ | |policies | || 1293 | |CCP Request < | +-----------+ +---------+ || 1294 | Client |-------------------------->|Conference | | Active || 1295 | | Conference Object ID, | |Control |~~~>|Conference || 1296 +--------+ Add, "Bob" > | |Server | | || 1297 | +-----------+ +-------+ || 1298 | |"Alice"| || 1299 "Carol" | ' ' '| 1300 +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| 1301 | |<-------------------------|Notification|<~~~| || 1302 | Client |. . ||Service | +-------+ || 1303 +--------+--+ . || | |"Bob" | || 1304 | |<----------------------| | +-------+----+| 1305 | Client |NOTIFY <"Bob"="added">|+------------+ | 1306 +--------+ +--------------------------------+ 1307 "Bob" 1309 Figure 9: Client Manipulation of Conference - Add a party 1311 Upon receipt of the Conference Control Protocol request to "add" a 1312 party ("Bob") in the specific conference as identified by the 1313 conference object ID, the conferencing system ensures that "Alice" 1314 has the appropriate authority based on the policies associated with 1315 that specific conference object to perform the operation. The 1316 conferencing system must also determine whether "Bob" is already a 1317 user of this conferencing system or whether he is a new user. 1319 If "Bob" is a new user for this conferencing system, a Conference 1320 User Identifier is created for Bob. Based upon the addressing 1321 information provided for "Bob" by "Alice", the call signaling to add 1322 "Bob" to the conference is instigated through the Focus. 1324 Once the call signaling indicates that "Bob" has been successfully 1325 added to the specific conference, per updates to the state, and 1326 depending upon the policies, other participants (including "Bob") may 1327 be notified of the addition of "Bob" to the conference via the 1328 Conference Notification Service. 1330 8.3. Media Manipulations 1332 There are different ways to manipulate the media in a conference. A 1333 participant can change its own media streams by, for example, sending 1334 re-INVITE with new SDP content using SIP only. This kind of 1335 operation is called "1st party signaling" and they do not affect the 1336 state of other participants in the conference. 1338 In order to perform richer conference control a user client needs to 1339 implement a conference control protocol client. By using a 1340 conference control protocol, the client can manipulate the state of 1341 various resources, such as media mixers, which may indirectly affect 1342 the state of any of the conference participants. 1344 Figure 10 provides an example of one client "Alice" impacting the 1345 media state of another client "Bob". This example assumes an 1346 established conference. In this example, the client, "Alice" whose 1347 Role is "moderator" of the conference, wants to mute "Bob" on a 1348 medium-size multi-party conference, as his device is not muted (and 1349 he's obviously not listening to the call) and background noise in his 1350 office environment is disruptive to the conference. 1352 +--------------------------------+ 1353 | Conferencing System | 1354 "Alice" | +---------+--+| 1355 +--------+ | |policies | || 1356 | |CCP Request < | +-----------+ +---------+ || 1357 | Client |-------------------------->|Conference | |Active || 1358 | | Conference Object ID, | |Control |~~~>|Conference || 1359 +--------+ Mute, "Bob" > | |Server | | || 1360 | +-----------+ +-------+ || 1361 | |"Alice"| || 1362 "Carol" | ' ' '| 1363 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1364 | |<-------------------------|Notification|<~~~| || 1365 | Client |. . ||Service | +-------+ || 1366 +--------+--+ . || | |"Bob" | || 1367 | |<----------------------| | +-------+----+| 1368 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1369 +--------+ +--------------------------------+ 1370 "Bob" 1372 Figure 10: Client Manipulation of Conference - Mute a party 1374 Upon receipt of the Conference Control Protocol request to "mute" a 1375 party ("Bob") in the specific conference as identified by the 1376 conference object ID, the Conference Server ensures that "Alice" has 1377 the appropriate authority based on the policies associated with that 1378 specific conference object to perform the operation. "Bob's" status 1379 is marked as "recvonly" and the conference object is updated to 1380 reflect that "Bob's" media is not to be "mixed" with the conference 1381 media. 1383 Depending upon the policies, other participants (including "Bob") may 1384 be notified of this change via the Conference Notification Service. 1386 8.4. Sidebar Manipulations 1388 A sidebar can be viewed as a separate Conference instance that only 1389 exists within the context of a parent conference instance. Although 1390 viewed as an independent conference instance, it can not exist 1391 without a parent. A sidebar is created using the same mechanisms 1392 employed for a standard conference as described in Section 6.1. 1394 A conference object representing a sidebar is created by cloning the 1395 parent associated with the existing conference and updating any 1396 information specific to the sidebar. A sidebar conference object is 1397 implicitly linked to the parent conference object (i.e. it is not an 1398 independent object) and is associated with the parent conference 1399 object identifier as shown in Figure 11. A conferencing system 1400 manages and enforces the parent and appropriate localized 1401 restrictions on the sidebar conference object (e.g., no members from 1402 outside the parent conference instance can join, sidebar conference 1403 can not exist if parent conference is terminated, etc.). 1405 +--------------+ 1406 | Conference | 1407 | Object | 1408 | Identifier | 1409 +--------------+ 1410 | 1411 | 1412 | 1413 +---------------------+---------------------+ 1414 | | | 1415 +-------+-------+ +-------+-------+ +-------+-------+ 1416 | Sidebar | | Sidebar | | Sidebar | 1417 | Conference | | Conference | | Conference | 1418 | Object | | Object | | Object | 1419 | Identifier | | Identifier | | Identifier | 1420 +-------+-------+ +-------+-------+ +---------------+ 1422 Figure 11: Conference Object Mapping. 1424 Figure 11 illustrates the relationship between a conference object 1425 and associated Sidebar conference objects within a conferencing 1426 system. Each Sidebar conference object has a unique conference 1427 object Identifier as described in Section 5.2.1. The main conference 1428 object identifier acts as a top level identifier for associated 1429 sidebars. 1431 A sidebar conference object Identifier follows many of the concepts 1432 outlined in the cloning tree model described in Section 6.1. A 1433 Sidebar conference object contains a subset of members from the 1434 original Conference object. Properties of the sidebar conference 1435 object can be manipulated by a Conference Control Protocol using the 1436 unique conference object identifier for the sidebar. It is also 1437 possible for the top level conference object to enforce policy on the 1438 sidebar object (similar to parent enforceable as discussed in 1439 Section 6.1). 1441 8.4.1. Internal Sidebar 1443 Figure 12 provides an example of one client "Alice" involved in 1444 active conference with "Bob" and "Carol". "Alice" wants to create a 1445 sidebar to have a side discussion with "Bob" while still viewing the 1446 video associated with the main conference. Alternatively, the audio 1447 from the main conference could be maintained at a reduced volume. 1448 "Alice" initiates the sidebar by sending a request to the 1449 conferencing system to create a conference reservation based upon the 1450 active conference object. "Alice" and "Bob" would remain on the 1451 roster of the main conference, such that other participants could be 1452 aware of their participation in the main conference, while an 1453 internal-sidebar conference is occurring. 1455 +--------------------------------+ 1456 | Conferencing System | 1457 | +---------+--+| 1458 | |policies | || 1459 | +---------+ || 1460 | |Active || 1461 | |Conference || 1462 "Alice" | +-------+ || 1463 +--------+ | |"Alice"| || 1464 | |CCP Req |Conference | +-------+ || 1467 | | confUserID> | |Control |~~~>|"Carol"| || 1468 | |<--------------------------|Server | +-------+----+| 1469 | |CCP Response | | | | | 1470 +--------+ | | | V | 1472 | | | +---------+--+| 1473 | | | |policies | || 1474 | | |~~~>+---------+ || 1475 | | | | || 1476 | +-----------+ | || 1477 "Alice" | | Sidebar || 1478 +--------+ | | Reservation|| 1479 | |CCP Request | |~~~>| || 1482 | | confID,confUserID, | | | +------------+| 1483 | | video=parent, | | | | | 1484 | | audio=sidebar> | |Conference | | | 1485 | | | |Control | V | 1486 | | | |Server | +---------+--+| 1487 | |CCP Response | | | |policies | || 1488 | | | | | |Sidebar || 1491 | | | |Conference || 1492 | +-----------+ +-------+ || 1493 | |"Alice"| || 1494 "Bob" | | | || 1495 +--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ || 1496 | |<-------------------------|Notification|<~~~| | || 1497 | Client | ||Service | |"Bob" | || 1498 +--------+ || | +-------+----+| 1499 |+------------+ | 1500 +--------------------------------+ 1502 Figure 12: Client Creation of a Sidebar Conference 1504 Upon receipt of the Conference Control Protocol request to "reserve" 1505 a new sidebar conference, based upon the active conference received 1506 in the request, the conferencing system uses the received active 1507 conference to clone a conference reservation for the sidebar. As 1508 discussed previously, the sidebar reservation is NOT independent of 1509 the active conference (i.e., parent). The conferencing system also 1510 reserves or allocates a conference ID to be used for any subsequent 1511 protocol requests from any of the members of the conference. The 1512 conferencing system maintains the mapping between this conference ID 1513 and the conference object ID associated with the sidebar reservation 1514 through the conference instance. 1516 Upon receipt of the conference control protocol response to reserve 1517 the conference, "Alice" can now create an active conference using 1518 that reservation or create additional reservations based upon the 1519 existing reservations. In this example, "Alice" wants only "Bob" to 1520 be involved in the sidebar, thus she manipulates the membership. 1521 "Alice" also only wants the video from the original conference and 1522 wants the audio to be restricted to the participants in the sidebar. 1523 Alternatively, "Alice" could manipulate the media values to recieve 1524 the audio from the main conference at a reduced volume. "Alice" 1525 sends a conference control protocol request to update the information 1526 in the reservation and to create an active conference. 1528 Upon receipt of the conference control protocol request to update the 1529 reservation and to create an active conference for the sidebar, as 1530 identified by the conference object ID, the conferencing system 1531 ensures that "Alice" has the appropriate authority based on the 1532 policies associated with that specific conference object to perform 1533 the operation. The conferencing system must also validate the 1534 updated information in the reservation, ensuring that a member like 1535 "Bob" is already a user of this conferencing system. 1537 Depending upon the policies, the initiator of the request (i.e., 1538 "Alice") and the participants in the sidebar (i.e., "Bob") may be 1539 notified of his addition to the sidebar via the conference 1540 notification service. 1542 8.4.2. External Sidebar 1544 Figure 13 provides an example of one client "Alice" involved in an 1545 active conference with "Bob", "Carol", "David" and "Ethel". "Alice" 1546 gets an important text message via a whisper from "Bob" that a 1547 critical customer needs to talk to "Alice", "Bob" and "Ethel". 1548 "Alice" creates a sidebar to have a side discussion with the customer 1549 "Fred" including the participants in the current conference with the 1550 exception of "Carol" and "David", who remain in the active 1551 conference. "Alice" initiates the sidebar by sending a request to 1552 the conferencing system to create a conference reservation based upon 1553 the active conference object. "Alice", "Bob" and "Ethel" would 1554 remain on the roster of the main conference in a hold state. Whether 1555 or not the hold state of these participants is visible to other 1556 participants depends upon the individual and local policy. 1558 +--------------------------------+ 1559 | Conferencing System | 1560 | +---------+--+| 1561 | |policies | || 1562 | +---------+ || 1563 | |Active || 1564 | |Conference || 1565 "Alice" | +-------+ || 1566 +--------+ | |"Alice"| || 1567 | |CCP Req |Conference | +-------+ || 1570 | | confUserID> | |Control |~~~>|"Carol"| || 1571 | |<--------------------------|Server | +-------+ || 1572 | |CCP Response | | | |"David"| || 1573 +--------+ | | | |"Ethel"| || 1575 | | | +-------+----+| 1576 | | | | | 1577 | | | V | 1578 | | | +---------+--+| 1579 | | | |policies | || 1580 | | |~~~>+---------+ || 1581 | +-----------+ | || 1582 "Alice" | | Sidebar || 1583 +--------+ | | Reservation|| 1584 | |CCP Request | |~~~>| || 1587 | | confID,confUserID, | | | +------------+| 1588 | | video=sidebar, | | | | | 1589 | | audio=sidebar> | |Conference | | | 1590 | | | |Control | V | 1591 | | | |Server | +---------+--+| 1592 | |CCP Response | | | |policies | || 1593 | | | | | |Sidebar || 1596 | | | |Conference || 1597 | +-----------+ +-------+ || 1598 | |"Alice"| || 1599 "Bob" | +-------+ || 1600 +--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | || 1601 | Client |<-------------------------|Notification|<~~~+-------+ || 1602 +--------+ "Ethel"=added, ||Service | |"Ethel"| || 1603 "Fred"=added,> || | +-------+ || 1604 "Ethel" +---| | |"Fred" | || 1605 +--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+| 1606 | Client | <--------------------+ +--------------------------------+ 1607 +--------+ "Ethel"=added,"Fred"=added,> 1609 Figure 13: Client Creation of an External Sidebar 1611 Upon receipt of the Conference Control Protocol request to "reserve" 1612 a new sidebar conference, based upon the active conference received 1613 in the request, the conferencing system uses the received active 1614 conference to clone a conference reservation for the sidebar. As 1615 discussed previously, the sidebar reservation is NOT independent of 1616 the active conference (i.e., parent). The conferencing system also 1617 reserves or allocates a conference ID to be used for any subsequent 1618 protocol requests from any of the members of the conference. The 1619 conferencing system maintains the mapping between this conference ID 1620 and the conference object ID associated with the sidebar reservation 1621 through the conference instance. 1623 Upon receipt of the conference control protocol response to reserve 1624 the conference, "Alice" can now create an active conference using 1625 that reservation or create additional reservations based upon the 1626 existing reservations. In this example, "Alice" wants only "Bob" and 1627 "Ethel", along with the new participant "Fred" to be involved in the 1628 sidebar, thus she manipulates the membership. "Alice" sets the media 1629 such that the participants in the sidebar don't receive any media 1630 from the main conference. "Alice" sends a conference control 1631 protocol request to update the information in the reservation and to 1632 create an active conference. 1634 Upon receipt of the conference control protocol request to update the 1635 reservation and to create an active conference for the sidebar, as 1636 identified by the conference object ID, the conferencing system 1637 ensures that "Alice" has the appropriate authority based on the 1638 policies associated with that specific conference object to perform 1639 the operation. The conferencing system must also validate the 1640 updated information in the reservation, ensuring whether members like 1641 "Fred" are already a user of this conferencing system or whether he 1642 is a new user. Since "Fred" is a new user for this conferencing 1643 system, a conference user identifier is created for "Fred". Based 1644 upon the addressing information provided for "Fred" by "Alice", the 1645 call signaling to add "Fred" to the conference is instigated through 1646 the Focus. 1648 Depending upon the policies, the initiator of the request (i.e., 1649 "Alice") and the participants in the sidebar (i.e., "Bob" and 1650 "Ethel") may be notified of his addition to the sidebar via the 1651 conference notification service. 1653 8.5. Floor control using sidebars 1655 Floor control with sidebars can be used to realize conferencing 1656 scenario such as an analyst briefing. In this scenario, the 1657 conference call has a panel of speakers who are allowed to talk in 1658 the main conference. The other participants are the analysts, who 1659 are not allowed to speak unless they have the floor. To request 1660 access to the floor, they have to join a new sidebar with the 1661 moderator and ask their question. The moderator can also whisper to 1662 each analyst what their status/position in the floor control queue, 1663 similar to the example in Figure 15 1665 Figure 14 provides an example of the configuration involved for this 1666 type of conference. As in the previous sidebar examples, there is 1667 the main conference along with a sidebar. "Alice" and "Bob" are the 1668 main participants in the conference, with "A1", "A2" and "A3" 1669 representing the analysts. The sidebar remains active throughout the 1670 conference, with the moderator, "Carol", serving as the chair. As 1671 discussed previously, the sidebar conference is NOT independent of 1672 the active conference (i.e., parent). The analysts are provided the 1673 conference object ID associated with the active sidebar when they 1674 join the main conference. The conferencing system also allocates a 1675 conference ID to be used for any subsequent manipulations of the 1676 sidebar conference. The conferencing system maintains the mapping 1677 between this conference ID and the conference object ID associated 1678 with the active sidebar conference through the conference instance. 1679 The analysts are permanently muted while in the main conference. The 1680 analysts are moved to the sidebar when they wish to speak. Only one 1681 analyst is given the floor at a given time. All participants in the 1682 main conference receive audio from the sidebar conference, as well as 1683 audio provided by the panelists in the main conference. 1685 +--------------------------------+ 1686 | Conferencing System | 1687 | +---------+--+| 1688 | |policies | || 1689 | +---------+ || 1690 | |Active || 1691 | |Conference || 1692 | +-------+ || 1693 | |"Alice"| || 1694 | +-------+ || 1695 | +-----------+ |"Bob" | || 1696 | |Conference | +-------+ || 1697 | |Control |~~~>|"A1" | || 1698 | |Server | +-------+ || 1699 | | | |"A2" | || 1700 | | | +-------+ || 1701 | | | |"A3" | || 1702 | | | +-------+----+| 1703 | | | | | 1704 | | | V | 1705 | | | +---------+--+| 1706 | | | |policies | || 1707 | | |~~~>+---------+ || 1708 | | | |Active || 1709 | +-----------+ |Sidebar || 1710 "A1" | |Conference || 1711 +--------+ Floor Request <"A1", |+------------+ +-------+ || 1712 | |------------------------->|Floor Ctrl | |"Carol"| || 1713 |Client | activeSideConfObjID,||Server |~~~>| | || 1714 +--------+ confID > || | +-------+----+| 1715 |+------------+ | | 1716 | V | 1717 | +---------+--+| 1718 | |policies | || 1719 | +---------+ || 1720 | |Active || 1721 | |Sidebar || 1722 "A1" | |Conference || 1723 +--------+ Floor Granted <"A1", |+------------+ +-------+ || 1724 | |<-------------------------|Floor Ctrl |<~~~|"Carol"| || 1725 | Client | activeSideConfObjID,||Server | +-------+ || 1726 +--------+ confID > || | |"A1" | || 1727 |+------------+ +-------+----+| 1728 +--------------------------------+ 1730 Figure 14: Floor Control with sidebars 1732 When "A1" wishes to ask a question, he sends a Floor Request message 1733 to the floor control server. Upon receipt of the request, the floor 1734 control server notifies the moderator, "Carol" of the active sidebar 1735 conference, whose serving as the floor chair. Note, that this 1736 signaling flow is not shown in the diagram. Since no other analysts 1737 have yet requested the floor, "Carol" indicates to the floor control 1738 server that "A1" may be granted the floor. 1740 8.6. Whispering or Private Messages 1742 The case of private messages can be handled as a sidebar with just 1743 two participants, similar to the example in section Section 8.4.1, 1744 but rather than using audio within the sidebar, "Alice" could add an 1745 additional text based media stream to the sidebar. The other 1746 context, referred to as whisper, in this document refers to 1747 situations involving one time media targetted to specific user(s). 1748 An example of a whisper would be an announcement injected only to the 1749 conference chair or to a new participant joining a conference. 1751 Figure 15 provides an example of one user "Alice" whose chairing a 1752 fixed length conference with "Bob" and "Carol". The configuration is 1753 such that only the chair is providing a warning when there is only 10 1754 minutes left in the conference. At that time, "Alice" is moved into 1755 a sidebar created by the conferencing system and only "Alice" 1756 receives the announcement. 1758 +--------------------------------+ 1759 | Conferencing System | 1760 | +---------+--+| 1761 | |policies | || 1762 | +---------+ || 1763 | |Active || 1764 | |Conference || 1765 | +-------+ || 1766 | |"Alice"| || 1767 | +-------+ || 1768 | +-----------+ |"Bob" | || 1769 | |Conference | +-------+ || 1770 | |Control |~~~>|"Carol"| || 1771 | |Server | +-------+----+| 1772 | | | | | 1773 | | | | | 1774 | | | V | 1775 | | | +---------+--+| 1776 | | | |policies | || 1777 | | |~~~>+---------+ || 1778 | | | | || 1779 | +-----------+ |Sidebar || 1780 "Alice" | |Conference || 1781 +--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ || 1782 | |<-------------------------|Notification| | | || 1783 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1784 +--------+ confID > || | +-------+----+| 1785 |+------------+ | 1786 ~~~Announcement provided to "Alice"~~~ 1787 | +-----------+ | 1788 | |Conference | | 1789 | |Control | | 1790 | |Server | | 1791 | | | | 1792 | | | \---------+--/| 1793 | | | |\ /|| 1794 | | |~~~>+ \ / || 1795 | | | | \ / || 1796 | +-----------+ |Sid\bar / || 1797 "Alice" | |Conf\re/ce || 1798 +--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ || 1799 | |<-------------------------|Notification|<~~~| /\| || 1800 | Client | activeSideConfObjID,||Service | |"Ali/ce\ || 1801 +--------+ confID > || | +---/---+\---+| 1802 |+------------+ / \ | 1803 +--------------------------------+ 1805 Figure 15: Whisper 1807 When the conferencing system determines that there is only 10 minutes 1808 left in the conference which "Alice" is chairing, rather than 1809 creating a reservation as was done for the sidebar in Section 8.4.1, 1810 the conferencing system directly creates an active sidebar 1811 conference, based on the active conference associated with "Alice". 1812 As discussed previously, the sidebar conference is NOT independent of 1813 the active conference (i.e., parent). The conferencing system also 1814 allocates a conference ID to be used for any subsequent manipulations 1815 of the sidebar conference. The conferencing system maintains the 1816 mapping between this conference ID and the conference object ID 1817 associated with the active sidebar conference through the conference 1818 instance. 1820 Immediately upon creation of the active sidebar conference, the 1821 announcement media is provided to "Alice". Depending upon the 1822 policies, Alice may be notified of her addition to the sidebar via 1823 the conference notification service. "Alice" continues to receive 1824 the media from the main conference. 1826 Upon completion of the announcement, "Alice" is removed from the 1827 siebar and the sidebar conference is deleted. Depending upon the 1828 policies, "Alice" may be notified of her removal from the sidebar via 1829 the conference notification service. 1831 8.7. Conference Announcements and Recordings 1833 Each participant can require a different type of announcement and/or 1834 recording service from the system. For example, "Alice", the 1835 conference chair, could be listening to a roll call while "Bob" may 1836 be using a telephony user interface to create a sidebar. Some 1837 announcements would apply to all the participants such as "This 1838 conference will end in 10 minutes". Recording is often required to 1839 capture the names of participants as they join a conference, 1840 typically after the participant has entered an access code as 1841 discussed in Section 8.8. These recorded names are then announced to 1842 all the participants as the new participant is added to the active 1843 conference. 1845 An example of a conferencing recording and announcement , along with 1846 collecting the DTMF, within the context of this framework, is shown 1847 in Figure 16. 1849 +--------------------------------+ 1850 | Conferencing System | 1851 "Alice" | +-----------+ | 1852 +--------+ | |Conference | | 1853 | |CCP Request < | |Control | | 1854 | Client |--------------------------->| |Server | | 1855 | |Bob's Conference ID, | | | | 1856 +--------+ Join > | | | | 1857 | | | | 1858 | ~ ~ | 1859 ~~~Announcement provided to "Alice"~~~ 1860 ~~~ Digits collected from "Alice"~~~ 1861 | ~ ~ +---------+--+| 1862 | | |~~~>|policies | || 1863 | | | +---------+ || 1864 | | | |Active || 1865 | | | |Conference || 1866 | | | +-------+ || 1867 | | | |"Bob" | || 1868 | | | +-------+ || 1869 | | | |"Carol"| || 1870 | | | +-------+----+| 1871 | ~ ~ | 1872 ~~~Announcement provided to "Alice"~~~ 1873 ~~~ Alice records her name ~~~ 1874 | ~ ~ +---------+--+| 1875 | | | |policies | || 1876 | | | +---------+ || 1877 | | |~~~>|Active || 1878 | +-----------+ |Conference || 1879 | +-------+ || 1880 | |"Bob" | || 1881 "Bob " | +-------+ || 1882 +--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| || 1883 | |<-------------------------|Notification| +-------+ || 1884 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1885 +--------+ confID > || | +-------+----+| 1886 |+------------+ | 1887 ~~~Announcement provided to All Parties~~~ 1888 | | 1889 +--------------------------------+ 1891 Figure 16: Recording and Announcements 1893 Upon receipt of the Conference Control Protocol request from "Alice" 1894 to join "Bob's" conference, the conferencing system maps the 1895 identifier received in the request to the conference object 1896 representing "Bob's" active conference. The conferencing system 1897 determines that a password is required for this specific conference, 1898 thus an announcement asking "Alice" to enter the password is provided 1899 to "Alice". Once "Alice" enters the password, it is validated 1900 against the policies associated with "Bob's" active conference. The 1901 conferencing system then connects to a server which prompts and 1902 records "Alice's" name. The conferencing system must also determine 1903 whether "Alice" is already a user of this conferencing system or 1904 whether she is a new user. 1906 If "Alice" is a new user for this conferencing system, a conference 1907 user identifier is created for "Alice". Based upon the addressing 1908 information provided by "Alice", the call signaling to add "Alice" to 1909 the conference is instigated through the Focus. 1911 Once the call signaling indicates that "Alice" has been successfully 1912 added to the specific conference, per updates to the state, and 1913 depending upon the policies, other participants (e.g., "Bob") are 1914 notified of the addition of "Alice" to the conference via the 1915 conference notification service and an announcement is provided to 1916 all the participants indicating that "Alice" has joined the 1917 conference. 1919 8.8. Monitoring for DTMF 1921 The conferencing system also needs the capability to monitor for DTMF 1922 from each individual participant. This would typically be used to 1923 enter the identifier and/or access code for joining a specific 1924 conference. 1926 An example of DTMF monitoring, within the context of the framework 1927 elements, is shown in Figure 16. 1929 8.9. Observing and Coaching 1931 The capability to observe a conference allows a participant with the 1932 appropriate authority to listen to the conference, typically without 1933 being an active participant and often as a hidden participant. When 1934 such a capability is available on a conferencing system, there is 1935 often an announcement provided to each participant as they join the 1936 conference indicating the call may be monitored. This capability is 1937 useful in the context of conferences which might be experiencing 1938 technical difficulties, thus allowing a technician to listen in to 1939 evaluate the type of problem. 1941 This capability could also apply to call center applications as it 1942 provides a mechanism for a supervisor to observe how the agent is 1943 handling a particular call with a customer. This scenario can be 1944 handled by a supervisor adding themselves to the existing active 1945 conference, with a listen only audio media path. Whether the agent 1946 is aware of when the supervisor joins the call should be 1947 configurable. 1949 Taking the supervisor capability one step further introduces a 1950 scenario whereby the agent can hear the supervisor, as well as the 1951 customer. The customer can still only hear the agent. This scenario 1952 would involve the creation of a sidebar involving the agent and the 1953 supervisor. Both the agent and supervisor receive the audio from the 1954 main conference. When the agent speaks, it is heard by the customer 1955 in the main conference. When the supervisor speaks, it is heard only 1956 by the agent in the sidebar conference. 1958 An example of observing and coaching is shown in figure Figure 17. 1959 In this example, call center agent "Bob" is involved in a conference 1960 with customer "Carol". Since "Bob" is a new agent and "Alice" sees 1961 that he has been on the call with "Carol" for longer than normal, she 1962 decides to observe the call and coach "Bob" as necessary. 1964 +--------------------------------+ 1965 | Conferencing System | 1966 | +---------+--+| 1967 | |policies | || 1968 | +---------+ || 1969 | |Active || 1970 | |Conference || 1971 "Alice" | | || 1972 +--------+ | | || 1973 | |CCP Req |Conference | +-------+ || 1976 | | confUserID> | |Control |~~~>|"Carol"| || 1977 | |<--------------------------|Server | +-------+----+| 1978 | |CCP Response | | | | | 1979 +--------+ | | | V | 1981 | | | +---------+--+| 1982 | | | |policies | || 1983 | | |~~~>+---------+ || 1984 | | | | || 1985 | +-----------+ | || 1986 "Alice" | | Sidebar || 1987 +--------+ | | Reservation|| 1988 | |CCP Request | |~~~>| || 1991 | | confID,confUserID> | | | +------------+| 1992 | | | | | | | 1993 | | | |Conference | | | 1994 | | | |Control | V | 1995 | | | |Server | +---------+--+| 1996 | |CCP Response | | | |policies | || 1997 | | | | | |Sidebar || 2000 | | | |Conference || 2001 | +-----------+ +-------+ || 2002 | |"Alice"| || 2003 "Bob" | | | || 2004 +--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ || 2005 | |<-------------------------|Notification|<~~~| | || 2006 | Client | "chair"="Alice" ||Service | |"Bob" | || 2007 +--------+ || | +-------+----+| 2008 |+------------+ | 2009 +--------------------------------+ 2011 Figure 17: Supervisor Creating a Sidebar for Observing/Coaching 2013 Upon receipt of the Conference Control Protocol request from "Alice" 2014 to "reserve" a new sidebar conference, based upon the active 2015 conference received in the request, the conferencing system uses the 2016 received active conference to clone a conference reservation for the 2017 sidebar. The conferencing system also reserves or allocates a 2018 conference ID to be used for any subsequent protocol requests from 2019 any of the members of the conference. The conferencing system 2020 maintains the mapping between this conference ID and the conference 2021 object ID associated with the sidebar reservation through the 2022 conference instance. 2024 Upon receipt of the conference control protocol response to reserve 2025 the conference, "Alice" can now create an active conference using 2026 that reservation or create additional reservations based upon the 2027 existing reservations. In this example, "Alice" wants only "Bob" to 2028 be involved in the sidebar, thus she manipulates the membership. 2029 "Alice" also wants the audio to be received by herself and "Bob" from 2030 the original conference, but wants any outgoing audio from herself to 2031 be restricted to the participants in the sidebar, whereas "Bob's" 2032 outgoing audio should go to the main conference, so that both "Alice" 2033 and the customer "Carol" hear the same audio from "Bob". "Alice" 2034 sends a conference control protocol request to update the information 2035 in the reservation and to create an active conference. 2037 Upon receipt of the conference control protocol request to update the 2038 reservation and to create an active conference for the sidebar, as 2039 identified by the conference object ID, the conferencing system 2040 ensures that "Alice" has the appropriate authority based on the 2041 policies associated with that specific conference object to perform 2042 the operation. Based upon the addressing information provided for 2043 "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with 2044 the appropriate media characteristics is instigated through the 2045 Focus. 2047 "Bob" is notified of his addition to the sidebar via the conference 2048 notification service, thus he is aware that "Alice" the supervisor is 2049 available for coaching him through this call. 2051 9. Relationships between SIPPING and Centralized Conferencing 2052 Frameworks 2054 The SIPPING Conferencing Framework [8] provides an overview of a wide 2055 range of centralized conferencing solutions known today in the 2056 conferencing industry. The document introduces a terminology and 2057 logical entities in order to systemize the overview and to show the 2058 common core of many of these systems. The logical entities and the 2059 listed scenarios in the SIPPING Conferencing Framework are being used 2060 to illustrate how SIP [2] can be used as a signaling means in these 2061 conferencing systems. SIPPING Conferencing Framework does not define 2062 new conference control protocols to be used by the general 2063 conferencing system. It uses only basic SIP [2], the SIP 2064 Conferencing for User Agents [12], and the SIPPING Conference Package 2065 [9] for basic SIP conferencing realization. 2067 This centralized conferencing framework document defines a particular 2068 centralized conferencing system and the logical entities implementing 2069 it. It also defines a particular data model and refers to the set of 2070 protocols (beyond call signaling means) being defined by the XCON WG 2071 to be used among the logical entities for implementing advanced 2072 conferencing features. The purpose of the XCON working group and 2073 this framework is to achieve interoperability between the logical 2074 entities from different vendors for controlling different aspects of 2075 advanced conferencing applications. 2077 The logical entities defined in the two frameworks are not intended 2078 to be mapped one-to-one. The two frameworks differ in the 2079 interpretation of the internal conferencing system decomposition and 2080 the corresponding operations. Nevertheless, the basic SIP [2], the 2081 SIP Conferencing for User Agents [12], and the SIPPING Conference 2082 Package [9] are fully compatible with both Framework documents. 2084 10. Security Considerations 2086 There are a wide variety of potential attacks related to 2087 conferencing, due to the natural involvement of multiple endpoints 2088 and the many, often user-invoked, capabilities provided by the 2089 conferencing system. Examples of attacks include the following: an 2090 endpoint attempting to listen to conferences in which it is not 2091 authorized to participate, an endpoint attempting to disconnect or 2092 mute other users, and theft of service, by an endpoint, in attempting 2093 to create conferences it is not allowed to create. 2095 There are several issues surrounding security of this conferencing 2096 framework. One set of issues involves securing the actual protocols 2097 and the associated authorization mechanisms. This first set of 2098 issues should be addressed in the specifications specific to the 2099 protocols described in Section 7. The protocols used for 2100 manipulation and retrieval of confidential information MUST support a 2101 confidentiality and integrity mechanism. Similar requirements apply 2102 for the floor control protocols. Section 10.3 discusses an approach 2103 for client authentication of a floor control server. 2105 There are also security issues associated with the authorization to 2106 perform actions on the conferencing system to invoke specific 2107 capabilities. Section 4.2 discusses the policies associated with the 2108 conference object to ensure that only authorized entities are able to 2109 manipulate the data to access the capabilities. The final set of 2110 issues involves the privacy and security of the identity of a user in 2111 the conference, which is discussed in Section 10.2 2113 10.1. Authorization 2115 Many policy authorization decisions are based on the identity of the 2116 user or the role that a user may have. There are several ways that a 2117 user might authenticate its identity to the system. The conferencing 2118 system may know about specific users and assign passwords to the 2119 users. The users may also be authenticated by knowing a particular 2120 conference ID and a PIN for it. Sometimes, a PIN is not required and 2121 the conference ID is used as a shared secret. The call signaling 2122 means can provide a trusted form of the user identity or it might 2123 just provide a hint of the possible identity and the user still needs 2124 to provide some authentication to prove it has the identity that was 2125 provided as a hint in the call signaling. This may be in the form of 2126 an IVR system or other means. The goal for the conferencing system 2127 is to figure out a user identity and a role for any attempt to send a 2128 request to the conferencing system. 2130 When a conferencing system presents the identity of authorized users, 2131 it may choose to provide information about the way the identity was 2132 proven or verified by the system. A user may also come as a 2133 completely unauthenticated user into the system - this fact needs 2134 also be communicated to interested parties. 2136 When guest users interact with the system, it is often in the context 2137 of a particular conference. In this case, the user may provide a PIN 2138 or a password that is specific to the conferences and authenticates 2139 the user to take on a certain role in that conference. The guest 2140 user can then perform actions that are allowed to any user with that 2141 role. 2143 The term password is used to mean the usual, that is to say a 2144 reasonable sized, in number of bits, hard to predict shared secret. 2145 Today users often have passwords with more than 30 bits of randomness 2146 in them. PIN is a special password case - a shared secret that is 2147 only numeric and often contains a fairly small number of bits (often 2148 as few as 10 bits). When conferencing systems are used for audio on 2149 the PSTN, there is often a need to authenticate using a PIN. 2150 Typically if the user fails to provide the correct PIN a few times in 2151 a row, the PSTN call is disconnected. The rate of making the calls 2152 and getting to the point to enter a PIN makes it fairly hard to do an 2153 exhaustive search of the PIN space even for 4 digit PINs. When using 2154 a high speed interface to connect to a conferencing system, it is 2155 often possible to do thousands of attempts per second and the PIN 2156 space could quickly be searched. Because of this, it is not 2157 appropriate to use PINs for authorization on any of the interfaces 2158 that provide fast queries or many simultaneous queries. 2160 10.2. Security and Privacy of Identity 2162 This conferencing system has an idea of the identity of a user but 2163 this does not mean it can reveal this identity to other users, due to 2164 privacy considerations. Users can select various options for 2165 revealing their identity to other users. A user can be "hidden" such 2166 that other users can not see they are participants in the conference, 2167 or they can be "anonymous" such that users can see that another user 2168 is there, but not see the identity of the user, or they can be 2169 "public" where other users can see their identity. If there are 2170 multiple "anonymous" users, other parties will be able to see them as 2171 independent "anonymous" parties and will be able to tell how many 2172 "anonymous" parties are in the conference. Note, that the visibility 2173 to other participants is dependent on their roles. For example, 2174 users' visibility (including "anonymous" and "hidden") may be 2175 displayed to the moderator or administrator, subject to a 2176 conferencing system's local policies. "Hidden" status is often used 2177 by automated or machine participants of a conference (e.g., call 2178 recording) and is also used in many call center situations. 2180 10.3. Floor Control Server Authentication 2182 Clients can authenticate a floor control server using the TLS 2183 certificates. Requests submitted on a successfully created 2184 connection between the client and floor control server may 2185 additionally require digest authentication within the BFCP protocol 2186 to authenticate the floor control client to the server. For this to 2187 take place, a shared secret needs to be exchanged between the floor 2188 control client/server entities. This can be achieved out of band 2189 using a mechanism such as the 'k=' SDP attribute. The shared secret 2190 can also be exchanged using un-specified 'out of band' mechanisms. 2191 When using Digest authentication of floor control client messages the 2192 exchange of an active 'Nonce' is also required. This can be achieved 2193 using a BFCP request response interaction as defined in BFCP (A 2194 request is submitted without a Nonce TLV and the server generates an 2195 error response with either an Error Code 7 (DIGEST TLV Required) or 6 2196 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 2197 can also be obtained 'out of band' using information provided in the 2198 offer/answer exchange. As with the other SDP Floor attributes 2199 referenced in this section and defined in [15], the 'nonce' attribute 2200 can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. 2202 11. IANA Considerations 2204 This is an informational draft, with no IANA considerations required. 2206 12. Acknowledgements 2208 This document is a result of architectural discussions among IETF 2209 XCON working group participants. The authors would like to thank 2210 Henning Schulzrinne for the "Conference Object Tree" proposal and 2211 general feedback, Cullen Jennings for providing input for the 2212 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 2213 Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan 2214 Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and 2215 Gonzalo Camarillo for their reviews and constructive input. 2217 13. Changes since last Version 2219 NOTE TO THE RFC-Editor: Please remove this section prior to 2220 publication as an RFC. 2222 Changes from WG 07 to 08 (post-WGLC comments, reflecting IETF-68 2223 discussions on policy): 2225 1) added Intended Status as Informational. 2227 2) Removed data model from Title and clarified reference to data 2228 model in this document as "high level data model". Renamed section 5 2229 from "Centralized Conferencing Data Model" to "Centralized 2230 Conferencing Data". 2232 3) Deleted Conventions section with reference to 2119. 2234 4) Moved terminology to just after intro, before overview. 2236 5) Changed "Common Conference Information" to "Conference 2237 Information". 2239 6) Removed references to policies as an integral part of data model: 2240 updated text discussing policies in section 5 and section 5.2, with 2241 section 7 text changed to be consistent with the updated text in 2242 section 5 and 5.2. 2244 7) Removal of references to individual conference-URI and Userid 2245 documents, bringing some background back into the framework, since 2246 those identifiers are defined in the data model. 2248 8) Miscellaneous editorial nits. 2250 Changes from WG 06 to 07 (WGLC comments): 2252 1) Section 4: Added definition for Conference User Identifier, 2253 including concept of a single user having multiple identifiers. 2255 2) Section 9: Clarified text to indicate that details of message 2256 flows are illustrative and exact states, etc. will be defined by the 2257 detailed data model, etc. 2259 3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster 2260 of main conference while in sidebar.Clarified text that Bob must 2261 already be a user of the conferencing system for internal sidebar 2262 scenario. 2264 4) Section 9.4.1/9.4.2: Clarified text in last paragraph to indicated 2265 that notifications may also go to the initial requestor. 2267 5) Section 9.5: Clarified text to explicitly state that sidebar 2268 participants also receive the audio from the main conference. 2270 6) Fixed Editorial nits including updating references to published 2271 RFC numbers and miscellaneous typos. 2273 Changes from WG 05 to 06: 2275 1) Section 9.4.2: Added a statement that whether the hold state is 2276 visible to other participants is subject to user and local policy. 2278 2) Fixed Editorial nits including updating references to published 2279 RFC numbers, adding references for userid and uri definitions, 2280 removing unused references, fixing names in detailed scenarios 2281 (section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as 2282 moderator), aligning with data model (section 9.5: "allowed to join" 2283 list -> "allowed-users-list") and miscellaneous typos. 2285 Changes from WG 04 to 05: 2287 1) Removed all references to "Conference Template": 2289 Section 4: 2291 - Updated "Common Conference Information" definition, merging details 2292 from "Conference Template" definition, which was removed. 2294 - In definition of "conference blueprint" 2295 - In definition of "conference object" 2297 - Removed definition of "Registered conference document" 2299 Section 5: 2301 - 1st paragraph. Reworded. 2303 - Figure2: added "boxes" for all the data listed in the Conference 2304 Template type in the diagram. 2306 - Paragraph following Figure 2. Reworded. 2308 Section 5.1/5.2: Merged 5.2 into section 5.1 and reworded 2309 appropriately. 2311 Section 7.1: Second paragraph, 3rd sentence. 2313 Section 7.3: 2315 - Second paragraph, 2nd and 3rd sentences. Deleted. Remaining 2316 sentence merged with 1st paragraph 2318 - Third paragraph. Deleted. 2320 Section 8.4, 1st paragraph. Removed Editor's note containing 2321 reference to alternative proposal for floor control using templates. 2323 Section 9.3, 1st paragraph after Figure 10. 2325 2) Section 4: 2327 - Sidebar. Clarified definition. 2329 - Whisper. Added definition. 2331 3) Section 5, last paragraph, added reference to 2332 draft-ietf-xcon-common-data-model. 2334 4) Section 8.3. Deleted Editor's note. Deleted subsections 2335 containing details of separate protocol proposals. 2337 5) Section 9.4. Sidebar. Added another example - an external 2338 sidebar (i.e. one involving a participant not in the main conference 2339 and with no media from the main conference). 2341 6) New section 9.5. Floor control with sidebars. 2343 7) Section 9.5 (new 9.6) Whisper. Added more detail and an example 2344 diagram. 2346 8) Section 9.8. (new 9.9) Observing a Conference. Added more details 2347 to example, including concept of coaching and added a corresponding 2348 diagram. 2350 9) Removed Appendix A and Appendix B and updated references to these. 2351 The content will be in separate documents (references TBD). 2353 10) Updated references. Changed drafts to RFCs as appropriate and 2354 removed unused references. 2356 Changes from WG 03 to 04: 2358 - Editorial nits and clarifications. 2360 - Section 4. Template: Removed reference to "user interface 2361 abstractions". 2363 - Section 5.2. Conference Template: deleted references to user 2364 interface abstraction (1st paragraph, last phrase and 4th paragraph). 2366 - Section 9.6. Conference Announcements and Recording: text 2367 expanded. Moved discussion of DTMF to a new section. 2369 - Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), 2370 with some initial text. 2372 Changes from WG 02 to 03: 2374 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 2376 - Added definition for Sidebar. 2378 - Section 5.2 Added text indicating that adding new elements or 2379 modifying elements requires the definition of a new template. (per 2380 DP4.2 conclusion). 2382 - Section 7.3. Added text reiterating that the blueprint comprises 2383 both the common conference information and a template (per DP4/4.1 2384 discussions. 2386 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 2387 blueprint is common conference information + one template and that 2388 multiple templates is FFS. 2390 - Section 8.3 - Updated Conference Control Protocol section to 2391 include the protocols on the table for WG discussion as of 31 Dec 2392 2005 deadline. 2394 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 2396 - Section 9.5 - Whisper - Added some text, reflecting past WG 2397 discussions. Basic definition and further details/example still 2398 needed. 2400 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 2401 Further details/example still needed. 2403 Changes from WG 01 to 02: 2405 - Editorial nits -i.e. consistent terminology, capatilization, etc. 2407 - Revamped abstract and introduction 2409 - Global removal of XCON as a qualifier (we had previously done this 2410 in a previous version with all the identifiers). 2412 - Global change of "call control signalling" to "call signaling" 2414 - Moved the terminology section after the Overview section: 2416 - - Modified the definitions to be more concise and per some of 2417 Henning's recommendations. 2419 - - Added definitions for blueprint and conference reservation. 2421 - Clarified the definition of policy and added more explicit text as 2422 to how policy is accomplished via the data model and system 2423 realization (section 4.3 and 6.1) 2425 - Removed the Editor's note/text in section 4 about the options for 2426 the schema; added a reference to a TBD schema document. 2428 - Section 5: 2430 - - clarified the identifiers. Kept the logical definition as 2431 "identifiers", although most will be realized as URIs. 2433 - - deleted the section on conference instance. 2435 - - removed the term "umbrella" from sections conference User and 2436 conference object identifier sections 2438 - - moved alot of detail from Conference User Identifier and 2439 conference Object Identifier sections into appendices, and added 2440 additional detail, that will become the basis for separate documents. 2442 - In section 6: 2444 - - added a bit of explanation as to the intent of the cloning tree 2445 model - it's not implementation binding, but rather to illustrate the 2446 data model and context for the protocol interactions. 2448 - - removed the term copying altogether. Cloning is the model and 2449 the idea is that the cloned object contains data indentical to the 2450 parent when it was created (whether it gets "copied" or whatever from 2451 the parent is an implementation issue). 2453 - - introduce the blueprint concept in section 6.1 prior to its 2454 implied usage in 6.2 and 6.3. 2456 - - removed the usage of the term occurrence (which is just a child 2457 reservation). 2459 - Removed security related details from Floor Control section and 2460 moved those to the security section. As a result removed most of the 2461 editorial notes from the front of the Floor control section and 2462 integrated the remaining ones inline into that section, where the 2463 resolution should be documented. 2465 - Section 8: 2467 - - Added new example 8.1 - conference creation 2469 - - Added a placeholder for a more detailed example to the sidebar 2470 section to show a sidebar which has some media specifically 2471 associated with the sidebar (i.e. audio), yet still use the main 2472 conference for other media (visual presentation). 2474 - Section 11: As a result of adding additional information to the 2475 security section, divided this section into subsections for clarity. 2477 Changes from WG 00 to 01:: 2479 - Section 2 (Conventions and Terminology). Slight modifications to 2480 definitions of Call (control) signaling, Conference Identifier, 2481 Conference Instance, Conference Object. 2483 - Section 2 (Conventions and Terminology).Renaming of term 2484 "Registered Template Definition" to "Registered Conference Document" 2485 (per agreement at interim meeting). 2487 - Section 3 (Next to the last paragraph on the media model). 2488 Clarified the text such that it doesn't read that the focus performs 2489 media mixing. Changed "focus" to "media mixer controlled by the 2490 focus" in the 2nd sentence and "performed" to "controlled" in the 2491 4th. 2493 - Section 5. Rearranged the sub-sections a bit for better flow. 2494 First describe the Conference ID, then the Conference Instance, 2495 followed by the Conference Object, with the Conference Object 2496 Identifier described in a subsection of the Conference Object 2497 section. Added a diagram showing the relationship between Conference 2498 Identifier/Focus and Conference Object Identifier, within the context 2499 of a Conference Instance to the Conference Object section. 2501 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 2502 apply to independent objects (and non-independent). 2504 - Section 6.3 (Advanced Example). Added additional text with regards 2505 to future conferences, introducing the concept of infinite series 2506 (which would be limited by calendaring interface). 2508 - Section 7.3 (Conference Control Protocol). Updated to include 2509 reference to SOAP option. 2511 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 2512 about the XCON FW constructs used. 2514 Changes from individual 02 to WG 00: 2516 - few minor editorial changes 2518 - Section 2. Removed second sentence of definition of Conference ID, 2519 as that's now included/described in context in new Identifier 2520 section. 2522 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 2523 Protocol" (per Keith's comment to be more explicit). 2525 - Section 4.1. Identifiers. Moved this to a new section ( 2526 Section 5). 2528 - New section for Identifiers ( Section 5), thus all section 2529 references beyond 4 are incremented in the new version. 2531 - Section 4. Since section 4.1 was removed, section 4.2 became the 2532 body text for section 4. 2534 - Section 4.2. Added "Floor Information" to Figure 2 as part of 2535 Common Conference Information, also added "Floor Control" to 2536 Conference Template (per text and Cullen's draft). 2538 - Section 4.5. Conference policies. Reworded to not introduce new 2539 terms, but use the general terms identified in the 1st paragraph. 2541 - Section 5.2. Removed "Instance" from "Active Conference Instance" 2542 in Figure 4. 2544 - Section 5.3. Added text clarifying that templates are retrieved 2545 from server (not central repository) (per DP3 conclusion). 2547 - Section 5.4. Added text that there is a single time and that the 2548 times are all relative the one time (per DP1 conclusion). 2550 - Section 5.4. Added text clarifying that changes to a series impact 2551 "all future occurrences (per DP1 discussion/conclusion). 2553 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 2554 as the CCP. 2556 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 2557 Condensed the text only slightly, but added explicit references to 2558 new identifier section. 2560 - Section 6.4.1 Moved to new Identifier section ( Section 5) 2562 - Section 7.1 - moved example to 7.2. Included a new (more 2563 appropriate example) in 7.1, although this may be too basic. 2565 - Section 7.3 - added some proposed text for Sidebars. 2567 14. Informative References 2569 [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2570 Description Protocol", RFC 4566, July 2006. 2572 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2573 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2574 Session Initiation Protocol", RFC 3261, June 2002. 2576 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2577 Session Description Protocol (SDP)", RFC 3264, June 2002. 2579 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2580 Notification", RFC 3265, June 2002. 2582 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2583 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2584 RFC 3550, July 2003. 2586 [6] Dawson, F. and Stenerson, D., "Internet Calendaring and 2587 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2588 November 1998. 2590 [7] Levin, O. and R. Even, "High-Level Requirements for Tightly 2591 Coupled SIP Conferencing", RFC 4245, November 2005. 2593 [8] Rosenberg, J., "A Framework for Conferencing with the Session 2594 Initiation Protocol (SIP)", RFC 4353, February 2006. 2596 [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2597 Initiation Protocol (SIP) Event Package for Conference State", 2598 RFC 4575, August 2006. 2600 [10] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 2601 "Requirements for Floor Control Protocols", RFC 4376, 2602 February 2006. 2604 [11] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, 2605 August 2006. 2607 [12] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2608 Call Control - Conferencing for User Agents", BCP 119, 2609 RFC 4579, August 2006. 2611 [13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 2612 Protocol (BFCP)", RFC 4582, November 2006. 2614 [14] Levin, O. and G. Camarillo, "The Session Description Protocol 2615 (SDP) Label Attribute", RFC 4574, August 2006. 2617 [15] Camarillo, G., "Session Description Protocol (SDP) Format for 2618 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 2619 November 2006. 2621 [16] Novo, O., "Conference Information Data Model for Centralized 2622 Conferencing (XCON)", draft-ietf-xcon-common-data-model-05 2623 (work in progress), April 2007. 2625 [17] Campbell, B., "The Message Session Relay Protocol", 2626 draft-ietf-simple-message-sessions-19 (work in progress), 2627 February 2007. 2629 Authors' Addresses 2631 Mary Barnes 2632 Nortel 2633 2201 Lakeside Blvd 2634 Richardson, TX 2636 Email: mary.barnes@nortel.com 2638 Chris Boulton 2639 Ubiquity Software Corporation 2640 Building 3 2641 Wern Fawr Lane 2642 St Mellons 2643 Cardiff, South Wales CF3 5EA 2645 Email: cboulton@ubiquitysoftware.com 2647 Orit Levin 2648 Microsoft Corporation 2649 One Microsoft Way 2650 Redmond, WA 98052 2652 Email: oritl@microsoft.com 2654 Full Copyright Statement 2656 Copyright (C) The IETF Trust (2007). 2658 This document is subject to the rights, licenses and restrictions 2659 contained in BCP 78, and except as set forth therein, the authors 2660 retain all their rights. 2662 This document and the information contained herein are provided on an 2663 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2664 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2665 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2666 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2667 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2668 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2670 Intellectual Property 2672 The IETF takes no position regarding the validity or scope of any 2673 Intellectual Property Rights or other rights that might be claimed to 2674 pertain to the implementation or use of the technology described in 2675 this document or the extent to which any license under such rights 2676 might or might not be available; nor does it represent that it has 2677 made any independent effort to identify any such rights. Information 2678 on the procedures with respect to rights in RFC documents can be 2679 found in BCP 78 and BCP 79. 2681 Copies of IPR disclosures made to the IETF Secretariat and any 2682 assurances of licenses to be made available, or the result of an 2683 attempt made to obtain a general license or permission for the use of 2684 such proprietary rights by implementers or users of this 2685 specification can be obtained from the IETF on-line IPR repository at 2686 http://www.ietf.org/ipr. 2688 The IETF invites any interested party to bring to its attention any 2689 copyrights, patents or patent applications, or other proprietary 2690 rights that may cover technology that may be required to implement 2691 this standard. Please address the information to the IETF at 2692 ietf-ipr@ietf.org. 2694 Acknowledgment 2696 Funding for the RFC Editor function is provided by the IETF 2697 Administrative Support Activity (IASA).