idnits 2.17.1 draft-ietf-xcon-framework-10.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 2721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2745. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 9, 2007) is 6013 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- 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-06 Summary: 1 error (**), 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: Standards Track C. Boulton 5 Expires: May 12, 2008 Avaya 6 O. Levin 7 Microsoft Corporation 8 November 9, 2007 10 A Framework for Centralized Conferencing 11 draft-ietf-xcon-framework-10 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 May 12, 2008. 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, Q.931 or ISUP, to exchange 47 media in a centralized unicast conference. The Centralized 48 Conferencing Framework defines logical entities and naming 49 conventions. The framework also outlines a set of conferencing 50 protocols, which are complementary to the call signaling protocols, 51 for building advanced conferencing applications. The framework binds 52 all the defined components together for the benefit of builders of 53 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 SIP and Centralized Conferencing 91 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 93 10.1. User Authentication and 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 . . . . . . . . . . . . . . . . . . . . 61 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 101 Intellectual Property and Copyright Statements . . . . . . . . . . 64 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, Q.931 or ISUP, to exchange 108 media in a centralized unicast conference. Other than references to 109 general functionality (e.g., establishment and teardown), details of 110 these call signaling protocols are outside the scope of this 111 document. 113 The Centralized Conferencing Framework defines logical entities and 114 naming conventions. The framework also outlines a set of 115 conferencing protocols, which are complementary to the call signaling 116 protocols, for building advanced conferencing applications. 118 The Centralized Conferencing Framework is compatible with the 119 functional model presented in the SIP Conferencing Framework [8]. 120 Section 9 of this document discusses the relationship between the 121 Centralized Conferencing Framework and the SIP 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 SIP 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 blueprint: A conference blueprint is a static conference 143 object within a conferencing system, which describes a typical 144 conference setting supported by the system. A conference 145 blueprint is the basis for creation of dynamic conference objects. 146 A system may maintain multiple blueprints. Each blueprint is 147 comprised of the initial values and ranges for the elements in the 148 object, conformant to the data schemas for the conference 149 information. 151 Conference control protocol (CCP): A conference control protocol 152 provides the interface for data manipulation and state retrieval 153 for the centralized conferencing data, represented by the 154 conference object. 155 Conference factory: A conference factory is a logical entity that 156 generates unique URI(s) to identify and represent a conference 157 focus. 158 Conference identifier (ID): A conference identifier is a call 159 signaling protocol-specific URI that identifies a conference focus 160 and its associated conference instance. 161 Conference information: The conference information includes 162 definitions for basic conference features, such as conference 163 identifiers, membership, signaling, capabilities and media types, 164 applicable to a wide range of conferencing applications. The 165 conference information also includes the media and application 166 specific data for enhanced conferencing features or capabilities, 167 such as media mixers. The conference information is the data type 168 (i.e., the XML schema) for a conference object. 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 signaling 210 interface with each participating client and the conference object 211 representing the active state. As such, the focus acts as an 212 endpoint for each of the supported signaling protocols and is 213 responsible for all primary conference membership operations 214 (e.g., join, leave, update the conference instance) and for media 215 negotiation/maintenance between a conference participant and the 216 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 SIP Conferencing Framework [8] 257 together with the SIP Call Control Conferencing for User Agents [12] 258 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 centralized 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, Jabber, 288 Q.931, ISUP, etc.) provides the interface between a call signaling 289 client and a Focus. A notification protocol (e.g. SIP Notify [4]) 290 provides the interface between the conferencing client and the 291 Notification 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 SIP 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 the SIP conference event 441 package [9]. Typically, participants with read-only access to the 442 conference information would be interested in this core set of 443 conference information only. 445 In order to support more complex media manipulations and enhanced 446 conferencing features, the conference information, as defined in the 447 data model [16], contains additional data beyond that defined in the 448 SIP conference event package [9]. The information defined in the 449 data model [16] provides specific media mixing details, available 450 floor controls and other data necessary to support enhanced 451 conferencing features. This information allows authorized clients to 452 manipulate the mixer's behavior via the focus, with the resultant 453 distribution of the media to all or individual participants. By 454 doing so, a client can change its own state and/or the state of other 455 participants in the conference. 457 New centralized conferencing specifications can extend the basic 458 conference-type as defined in the data model [16] and introduce 459 additional data elements to be used within the conference information 460 type. 462 4.2. Conference policies 464 Conference policies collectively refers to a set of rights, 465 permissions and limitations pertaining to operations being performed 466 on a certain conference object. 468 The set of rights describes the read/write access privileges for the 469 conference object as a whole. This access would usually be granted 470 and defined in terms of giving the read-only or read-write access to 471 clients with certain roles in the conference. Managing this access 472 would require a conferencing system have access to basic policy 473 information to make the decisions, but doesn't necessarily require an 474 explicit representation in the policy model. As such, for this 475 framework document, the policies represented by the set of rights are 476 reflected in the system realization (Section 6). 478 The permissions and limits require explicit policy mechanisms and are 479 outside the scope of the data model [16] and this framework document. 481 5. Centralized Conferencing Constructs and Identifiers 483 This section provides details of the identifiers associated with the 484 centralized conferencing framework constructs and the identifiers 485 necessary to address and manage the clients associated with a 486 conferencing system. An overview of the allocation, characteristics 487 and functional role of the identifiers is provided. 489 5.1. Conference Identifier 491 The conference identifier (conference ID) is a call signaling 492 protocol-specific URI that identifies a specific conference focus and 493 its associated conference instance. A conference factory is one 494 method for generating a unique conference ID, to identify and address 495 a conference focus, using a call signaling interface. Details on the 496 use of a conference factory for SIP signaling can be found in [12]. 497 The conference identifier can also be obtained using the conference 498 control protocol or other, including proprietary, out-of-band 499 mechanisms. 501 5.2. Conference Object 503 A Conference object provides the logical representation of a 504 conference instance in a certain stage, such as a conference 505 blueprint representing a conferencing system's capabilities, the data 506 representing a conference reservation, and the conference state 507 during an active conference. Each conference object is independently 508 addressable through the conference control protocol interface 509 [Section 7.3]. 511 Figure 3 illustrates the relationships between the conference 512 identifier, the focus and the conference object ID within the context 513 of a logical conference instance, with the conference object 514 corresponding to an active conference. 516 A conference object representing a conference in the active state can 517 have multiple call signaling conference identifiers; for example, one 518 for each call signaling protocol supported. There is a one-to-one 519 mapping between an active conference object and a conference focus. 520 The focus is addressed by explicitly associating unique conference 521 IDs for each signaling protocol supported by the active conference 522 object. 524 .................................................................... 525 . Conference Instance . 526 . . 527 . . 528 . +---------------------------------------------------+ . 529 . | Conference Object Identifier | . 530 . | | . 531 . | | . 532 . +---------------------------------------------------+ . 533 . ^ ^ . 534 . | | . 535 . v | . 536 . ................................................... | . 537 . . Focus . | . 538 . . . | . 539 . . +----------------------------------+ . | . 540 . . |Conference Identifier (Protocol Y)| . | . 541 . . +------------------------------------+ | . | . 542 . . | Conference Identifier (ISUP) | | . | . 543 . . +--------------------------------------+ |-+ . | . 544 . . | Conference Identifier (SIP) | |^ . | . 545 . . | |-+| . | . 546 . . | |^ | . | . 547 . . +--------------------------------------+| | . | . 548 . ............^...............................|.|.... | . 549 . | | | | . 550 ................|...............................|.|......|.......... 551 | | | | 552 |SIP | | |Conference 553 | ISUP | |Y |Control 554 | | | |Protocol 555 | +---------------+ | | 556 | | | | 557 | | | | 558 v v v v 559 +----------------+ +--------------+ +---------------+ 560 | Conferencing | | Conferencing | | Conference | 561 | Client | | Client | | Client | 562 | 1 | | 2 | | X | 563 +----------------+ +--------------+ +---------------+ 565 Figure 3: Identifier Relationships for an Active Conference. 567 5.2.1. Conference Object Identifier 569 In order to make each conference object externally accessible, the 570 conferencing system allocates a unique URI per distinct conference 571 object in the system. A conferencing system will allocate a 572 conferencing object identifier for every conference blueprint, for 573 every conference reservation and for every active conference. The 574 distribution of the conference object identifier depends upon the 575 specific use case and includes a variety of mechanisms, such as the 576 through the conference control protocol mechanism, the data model and 577 conference package or out of band 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 identifier 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 identifier 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 identifier would be sent in any notifications that 636 may be sent to existing participants, such as the moderator, when 637 this 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 the child is not impacted by any operations on the 707 parent 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 | l | | | l | | 771 | i | C O N F E R E N C E | | i | C O N F E R E N C E | 772 | c | | | c | | 773 | i | O B J E C T | | i | O B J E C T | 774 | e | | | 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, by performing operations such as adding 802 participants, using the 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 SIP and Centralized Conferencing Frameworks 2053 The SIP Conferencing Framework [8] provides an overview of a wide 2054 range of centralized conferencing solutions known today in the 2055 conferencing industry. The document introduces a terminology and 2056 logical entities in order to systemize the overview and to show the 2057 common core of many of these systems. The logical entities and the 2058 listed scenarios in the SIP Conferencing Framework are used to 2059 illustrate how SIP [2] can be used as a signaling means in these 2060 conferencing systems. The SIP Conferencing Framework does not define 2061 new conference control protocols to be used by the general 2062 conferencing system. It uses only basic SIP [2], the SIP 2063 Conferencing for User Agents [12], and the SIP Conference Package [9] 2064 for basic SIP conferencing realization. 2066 This centralized conferencing framework document defines a particular 2067 centralized conferencing system and the logical entities implementing 2068 it. It also defines a particular data model and refers to the set of 2069 protocols (beyond call signaling means) to be used among the logical 2070 entities for implementing advanced conferencing features. The 2071 purpose of the XCON working group and this framework is to achieve 2072 interoperability between the logical entities from different vendors 2073 for controlling different aspects of advanced conferencing 2074 applications. 2076 The logical entities defined in the two frameworks are not intended 2077 to be mapped one-to-one. The two frameworks differ in the 2078 interpretation of the internal conferencing system decomposition and 2079 the corresponding operations. Nevertheless, the basic SIP [2], the 2080 SIP Conferencing for User Agents [12], and the SIP Conference Package 2081 [9] are fully compatible with both Framework documents. 2083 10. Security Considerations 2085 There are a wide variety of potential attacks related to 2086 conferencing, due to the natural involvement of multiple endpoints 2087 and the many, often user-invoked, capabilities provided by the 2088 conferencing system. Examples of attacks include the following: an 2089 endpoint attempting to listen to conferences in which it is not 2090 authorized to participate, an endpoint attempting to disconnect or 2091 mute other users, and theft of service by an endpoint in attempting 2092 to create conferences it is not allowed to create. 2094 There are several issues surrounding security of this conferencing 2095 framework. One set of issues involves securing the actual protocols 2096 and the associated authorization mechanisms. This first set of 2097 issues should be addressed in the specifications specific to the 2098 protocols described in Section 7. The protocols used for 2099 manipulation and retrieval of confidential information need to 2100 support a confidentiality and integrity mechanism. Similar 2101 requirements apply for the floor control protocols. Section 10.3 2102 discusses an approach for client authentication of a floor control 2103 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. Another 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 A final issue is related to Denial of Service (DoS) attacks on the 2114 conferencing system itself. In order to minimize the potential for 2115 DoS attacks, it is recommended that conferencing systems require user 2116 authentication and authorization for any client participating in a 2117 conference. It is recommended that the specific signaling and media 2118 protocols include mechanisms to minimize the potential for DoS. 2120 10.1. User Authentication and Authorization 2122 Many policy authorization decisions are based on the identity of the 2123 user or the role that a user may have. Conferencing systems 2124 typically require authentication of users to validate their identity. 2125 There are several ways that a user might authenticate its identity to 2126 the system. For users joining a conference using one of the call 2127 signaling protocols, the user authentication mechanisms for the 2128 specific protocol often suffice. The conferencing system may also 2129 know (e.g., out of band mechanisms) about specific users and assign 2130 passwords to allow these users to be authorized. In some cases 2131 additional authorization may be required to allow the user to 2132 participate in the conference. This may be in the form of an 2133 Interactive Voice Response (IVR) system or other means. The users 2134 may also be authorized by knowing a particular conference ID and a 2135 Personal Identification (PIN) for it. Sometimes, a PIN is not 2136 required and the conference ID is used as a shared secret. 2138 When a conferencing system presents the identity of authorized users, 2139 it may choose to provide information about the way the identity was 2140 proven or verified by the system. A user may also come as a 2141 completely unauthenticated user into the system - this fact needs 2142 also be communicated to interested parties. 2144 When guest users interact with the system, it is often in the context 2145 of a particular conference. In this case, the user may provide a PIN 2146 or a password that is specific to the conferences and authorizes the 2147 user to take on a certain role in that conference. The guest user 2148 can then perform actions that are allowed to any user with that role. 2150 The term password refers to the usual, reasonable sized and hard to 2151 predict shared secret. Today users often have passwords containing 2152 up to 30 bits (8-16 characters). PIN is a special password case - a 2153 shared secret that is only numeric and often contains a fairly small 2154 number of bits (often as few as 10 bits or 3 digits). When 2155 conferencing systems are used for audio on the PSTN, there is often a 2156 need to authenticate using a PIN. Typically if the user fails to 2157 provide the correct PIN a few times in a row, the PSTN call is 2158 disconnected. The rate of making the calls and getting to the point 2159 to enter a PIN makes it fairly hard to do an exhaustive search of the 2160 PIN space even for 4 digit PINs. When using a high speed interface 2161 to connect to a conferencing system, it is often possible to do 2162 thousands of attempts per second and the PIN space could quickly be 2163 searched. Because of this, it is not appropriate to use PINs for 2164 authorization on any of the interfaces that provide fast queries or 2165 many simultaneous queries. 2167 10.2. Security and Privacy of Identity 2169 This conferencing system has an idea of the identity of a user but 2170 this does not mean it can reveal this identity to other users, due to 2171 privacy considerations. Users can select various options for 2172 revealing their identity to other users. A user can be "hidden" such 2173 that other users can not see they are participants in the conference, 2174 or they can be "anonymous" such that users can see that another user 2175 is there, but not see the identity of the user, or they can be 2176 "public" where other users can see their identity. If there are 2177 multiple "anonymous" users, other parties will be able to see them as 2178 independent "anonymous" parties and will be able to tell how many 2179 "anonymous" parties are in the conference. Note, that the visibility 2180 to other participants is dependent on their roles. For example, 2181 users' visibility (including "anonymous" and "hidden") may be 2182 displayed to the moderator or administrator, subject to a 2183 conferencing system's local policies. "Hidden" status is often used 2184 by automated or machine participants of a conference (e.g., call 2185 recording) and is also used in many call center situations. 2187 10.3. Floor Control Server Authentication 2189 The floor control protocol contains mechanisms that clients can use 2190 to authenticate servers and that servers can use to authenticate 2191 clients, as described in section 9 of RFC 4582 [13]. The precise 2192 mechanisms used for such authentication can vary depending on the 2193 call control protocol used. Clients using call control protocols 2194 that employ an SDP offer/answer model, such as SIP, use the mechanism 2195 described in section 8 of RFC 4583 [15]. Clients using other call 2196 control protocols make use of the mechanisms described in the BFCP 2197 Connection Establishment document [18]. 2199 11. IANA Considerations 2201 This document requires no action on the part of IANA. 2203 12. Acknowledgements 2205 This document is a result of architectural discussions among IETF 2206 XCON working group participants. The authors would like to thank 2207 Henning Schulzrinne for the "Conference Object Tree" proposal and 2208 general feedback, Cullen Jennings for providing input for the 2209 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 2210 Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan 2211 Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and 2212 Gonzalo Camarillo for their reviews and constructive input. In 2213 addition, the authors would like to thank Scott Brim for his gen-art 2214 review comments and Kurt Zeilenga for his secdir review comments. 2216 13. Changes since last Version 2218 NOTE TO THE RFC-Editor: Please remove this section prior to 2219 publication as an RFC. 2221 Changes from WG 09 to 10 (gen-art, secdir and initial IESG review 2222 comments): 2224 1) Abstract and Section 1: removed "along with a high level 2225 conferencing data model." 2227 2) Section 5.2.1: removed confusing unclear 2nd sentence since it 2228 really added no value(Scott Brim's comment from gen-art review) and 2229 changed the tense of the 3rd sentence (editor's comment) 2231 3) Updates to security section based on secdir (Kurt Zeilenga) and 2232 IESG (Tim Polk) comments 2234 3a) Section 10. Added a fourth paragraph about DoS attacks at the 2235 end of that section just prior to 10.1 2237 3b) Section 10.1. Clarifying Authentication versus Authorization 2239 3bi) Renamed section: OLD: Authorization NEW: User Authentication and 2240 Authorization 2242 3bii) First paragraph: expanded acronyms and clarified text. Added 2243 2nd sentence (removed last sentence) and moved 4th and 5th sentences 2244 to the end 2245 3biii) 3rd paragraph (change "authenticates" to "authorizes") 2247 3biv) 4th paragraph: Reworded to add detail about the number of 2248 digits/characters associated with specific numbers of bits in first 2249 two sentences 2251 4) Updated references (gen-art review comment): 2252 draft-ietf-simple-message-sessions => RFC 4975, 2253 draft-ietf-xcon-bfcp-connection => RFC 5018 2255 5) Updated Chris' affiliation. 2257 Changes from WG 08 to 09 (chair PROTO review comments): 2259 1) Changed Intended Status to standards track. 2261 2) Updated IANA section per 1). 2263 3) Removed normative language (i.e., "must" in CAPS in section 10) 2265 4) Updated section 10.3 (Floor Control authentication) to be more 2266 general based on changes to the final BFCP authentication mechanism. 2268 5) Miscellaneous editorial nits - it is amazing after all these 2269 reviews, how many were still there! 2271 Changes from WG 07 to 08 (post-WGLC comments, reflecting IETF-68 2272 discussions on policy): 2274 1) added Intended Status as Informational. 2276 2) Removed data model from Title and clarified reference to data 2277 model in this document as "high level data model". Renamed section 5 2278 from "Centralized Conferencing Data Model" to "Centralized 2279 Conferencing Data". 2281 3) Deleted Conventions section with reference to 2119. 2283 4) Moved terminology to just after intro, before overview. 2285 5) Changed "Common Conference Information" to "Conference 2286 Information". 2288 6) Removed references to policies as an integral part of data model: 2289 updated text discussing policies in section 5 and section 5.2, with 2290 section 7 text changed to be consistent with the updated text in 2291 section 5 and 5.2. 2293 7) Removal of references to individual conference-URI and Userid 2294 documents, bringing some background back into the framework, since 2295 those identifiers are defined in the data model. 2297 8) Miscellaneous editorial nits. 2299 Changes from WG 06 to 07 (WGLC comments): 2301 1) Section 4: Added definition for Conference User Identifier, 2302 including concept of a single user having multiple identifiers. 2304 2) Section 9: Clarified text to indicate that details of message 2305 flows are illustrative and exact states, etc. will be defined by the 2306 detailed data model, etc. 2308 3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster 2309 of main conference while in sidebar.Clarified text that Bob must 2310 already be a user of the conferencing system for internal sidebar 2311 scenario. 2313 4) Section 9.4.1/9.4.2: Clarified text in last paragraph to indicated 2314 that notifications may also go to the initial requestor. 2316 5) Section 9.5: Clarified text to explicitly state that sidebar 2317 participants also receive the audio from the main conference. 2319 6) Fixed Editorial nits including updating references to published 2320 RFC numbers and miscellaneous typos. 2322 Changes from WG 05 to 06: 2324 1) Section 9.4.2: Added a statement that whether the hold state is 2325 visible to other participants is subject to user and local policy. 2327 2) Fixed Editorial nits including updating references to published 2328 RFC numbers, adding references for userid and uri definitions, 2329 removing unused references, fixing names in detailed scenarios 2330 (section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as 2331 moderator), aligning with data model (section 9.5: "allowed to join" 2332 list -> "allowed-users-list") and miscellaneous typos. 2334 Changes from WG 04 to 05: 2336 1) Removed all references to "Conference Template": 2338 Section 4: 2340 - Updated "Common Conference Information" definition, merging details 2341 from "Conference Template" definition, which was removed. 2343 - In definition of "conference blueprint" 2345 - In definition of "conference object" 2347 - Removed definition of "Registered conference document" 2349 Section 5: 2351 - 1st paragraph. Reworded. 2353 - Figure2: added "boxes" for all the data listed in the Conference 2354 Template type in the diagram. 2356 - Paragraph following Figure 2. Reworded. 2358 Section 5.1/5.2: Merged 5.2 into section 5.1 and reworded 2359 appropriately. 2361 Section 7.1: Second paragraph, 3rd sentence. 2363 Section 7.3: 2365 - Second paragraph, 2nd and 3rd sentences. Deleted. Remaining 2366 sentence merged with 1st paragraph 2368 - Third paragraph. Deleted. 2370 Section 8.4, 1st paragraph. Removed Editor's note containing 2371 reference to alternative proposal for floor control using templates. 2373 Section 9.3, 1st paragraph after Figure 10. 2375 2) Section 4: 2377 - Sidebar. Clarified definition. 2379 - Whisper. Added definition. 2381 3) Section 5, last paragraph, added reference to 2382 draft-ietf-xcon-common-data-model. 2384 4) Section 8.3. Deleted Editor's note. Deleted subsections 2385 containing details of separate protocol proposals. 2387 5) Section 9.4. Sidebar. Added another example - an external 2388 sidebar (i.e. one involving a participant not in the main conference 2389 and with no media from the main conference). 2391 6) New section 9.5. Floor control with sidebars. 2393 7) Section 9.5 (new 9.6) Whisper. Added more detail and an example 2394 diagram. 2396 8) Section 9.8. (new 9.9) Observing a Conference. Added more details 2397 to example, including concept of coaching and added a corresponding 2398 diagram. 2400 9) Removed Appendix A and Appendix B and updated references to these. 2401 The content will be in separate documents (references TBD). 2403 10) Updated references. Changed drafts to RFCs as appropriate and 2404 removed unused references. 2406 Changes from WG 03 to 04: 2408 - Editorial nits and clarifications. 2410 - Section 4. Template: Removed reference to "user interface 2411 abstractions". 2413 - Section 5.2. Conference Template: deleted references to user 2414 interface abstraction (1st paragraph, last phrase and 4th paragraph). 2416 - Section 9.6. Conference Announcements and Recording: text 2417 expanded. Moved discussion of DTMF to a new section. 2419 - Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), 2420 with some initial text. 2422 Changes from WG 02 to 03: 2424 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 2426 - Added definition for Sidebar. 2428 - Section 5.2 Added text indicating that adding new elements or 2429 modifying elements requires the definition of a new template. (per 2430 DP4.2 conclusion). 2432 - Section 7.3. Added text reiterating that the blueprint comprises 2433 both the common conference information and a template (per DP4/4.1 2434 discussions. 2436 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 2437 blueprint is common conference information + one template and that 2438 multiple templates is FFS. 2440 - Section 8.3 - Updated Conference Control Protocol section to 2441 include the protocols on the table for WG discussion as of 31 Dec 2442 2005 deadline. 2444 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 2446 - Section 9.5 - Whisper - Added some text, reflecting past WG 2447 discussions. Basic definition and further details/example still 2448 needed. 2450 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 2451 Further details/example still needed. 2453 Changes from WG 01 to 02: 2455 - Editorial nits -i.e. consistent terminology, capatilization, etc. 2457 - Revamped abstract and introduction 2459 - Global removal of XCON as a qualifier (we had previously done this 2460 in a previous version with all the identifiers). 2462 - Global change of "call control signalling" to "call signaling" 2464 - Moved the terminology section after the Overview section: 2466 - - Modified the definitions to be more concise and per some of 2467 Henning's recommendations. 2469 - - Added definitions for blueprint and conference reservation. 2471 - Clarified the definition of policy and added more explicit text as 2472 to how policy is accomplished via the data model and system 2473 realization (section 4.3 and 6.1) 2475 - Removed the Editor's note/text in section 4 about the options for 2476 the schema; added a reference to a TBD schema document. 2478 - Section 5: 2480 - - clarified the identifiers. Kept the logical definition as 2481 "identifiers", although most will be realized as URIs. 2483 - - deleted the section on conference instance. 2485 - - removed the term "umbrella" from sections conference User and 2486 conference object identifier sections 2488 - - moved alot of detail from Conference User Identifier and 2489 conference Object Identifier sections into appendices, and added 2490 additional detail, that will become the basis for separate documents. 2492 - In section 6: 2494 - - added a bit of explanation as to the intent of the cloning tree 2495 model - it's not implementation binding, but rather to illustrate the 2496 data model and context for the protocol interactions. 2498 - - removed the term copying altogether. Cloning is the model and 2499 the idea is that the cloned object contains data indentical to the 2500 parent when it was created (whether it gets "copied" or whatever from 2501 the parent is an implementation issue). 2503 - - introduce the blueprint concept in section 6.1 prior to its 2504 implied usage in 6.2 and 6.3. 2506 - - removed the usage of the term occurrence (which is just a child 2507 reservation). 2509 - Removed security related details from Floor Control section and 2510 moved those to the security section. As a result removed most of the 2511 editorial notes from the front of the Floor control section and 2512 integrated the remaining ones inline into that section, where the 2513 resolution should be documented. 2515 - Section 8: 2517 - - Added new example 8.1 - conference creation 2519 - - Added a placeholder for a more detailed example to the sidebar 2520 section to show a sidebar which has some media specifically 2521 associated with the sidebar (i.e. audio), yet still use the main 2522 conference for other media (visual presentation). 2524 - Section 11: As a result of adding additional information to the 2525 security section, divided this section into subsections for clarity. 2527 Changes from WG 00 to 01:: 2529 - Section 2 (Conventions and Terminology). Slight modifications to 2530 definitions of Call (control) signaling, Conference Identifier, 2531 Conference Instance, Conference Object. 2533 - Section 2 (Conventions and Terminology).Renaming of term 2534 "Registered Template Definition" to "Registered Conference Document" 2535 (per agreement at interim meeting). 2537 - Section 3 (Next to the last paragraph on the media model). 2538 Clarified the text such that it doesn't read that the focus performs 2539 media mixing. Changed "focus" to "media mixer controlled by the 2540 focus" in the 2nd sentence and "performed" to "controlled" in the 2541 4th. 2543 - Section 5. Rearranged the sub-sections a bit for better flow. 2544 First describe the Conference ID, then the Conference Instance, 2545 followed by the Conference Object, with the Conference Object 2546 Identifier described in a subsection of the Conference Object 2547 section. Added a diagram showing the relationship between Conference 2548 Identifier/Focus and Conference Object Identifier, within the context 2549 of a Conference Instance to the Conference Object section. 2551 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 2552 apply to independent objects (and non-independent). 2554 - Section 6.3 (Advanced Example). Added additional text with regards 2555 to future conferences, introducing the concept of infinite series 2556 (which would be limited by calendaring interface). 2558 - Section 7.3 (Conference Control Protocol). Updated to include 2559 reference to SOAP option. 2561 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 2562 about the XCON FW constructs used. 2564 Changes from individual 02 to WG 00: 2566 - few minor editorial changes 2568 - Section 2. Removed second sentence of definition of Conference ID, 2569 as that's now included/described in context in new Identifier 2570 section. 2572 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 2573 Protocol" (per Keith's comment to be more explicit). 2575 - Section 4.1. Identifiers. Moved this to a new section ( 2576 Section 5). 2578 - New section for Identifiers ( Section 5), thus all section 2579 references beyond 4 are incremented in the new version. 2581 - Section 4. Since section 4.1 was removed, section 4.2 became the 2582 body text for section 4. 2584 - Section 4.2. Added "Floor Information" to Figure 2 as part of 2585 Common Conference Information, also added "Floor Control" to 2586 Conference Template (per text and Cullen's draft). 2588 - Section 4.5. Conference policies. Reworded to not introduce new 2589 terms, but use the general terms identified in the 1st paragraph. 2591 - Section 5.2. Removed "Instance" from "Active Conference Instance" 2592 in Figure 4. 2594 - Section 5.3. Added text clarifying that templates are retrieved 2595 from server (not central repository) (per DP3 conclusion). 2597 - Section 5.4. Added text that there is a single time and that the 2598 times are all relative the one time (per DP1 conclusion). 2600 - Section 5.4. Added text clarifying that changes to a series impact 2601 "all future occurrences (per DP1 discussion/conclusion). 2603 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 2604 as the CCP. 2606 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 2607 Condensed the text only slightly, but added explicit references to 2608 new identifier section. 2610 - Section 6.4.1 Moved to new Identifier section ( Section 5) 2612 - Section 7.1 - moved example to 7.2. Included a new (more 2613 appropriate example) in 7.1, although this may be too basic. 2615 - Section 7.3 - added some proposed text for Sidebars. 2617 14. Informative References 2619 [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2620 Description Protocol", RFC 4566, July 2006. 2622 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2623 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2624 Session Initiation Protocol", RFC 3261, June 2002. 2626 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2627 Session Description Protocol (SDP)", RFC 3264, June 2002. 2629 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2630 Notification", RFC 3265, June 2002. 2632 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2633 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2634 RFC 3550, July 2003. 2636 [6] Dawson, F. and Stenerson, D., "Internet Calendaring and 2637 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2638 November 1998. 2640 [7] Levin, O. and R. Even, "High-Level Requirements for Tightly 2641 Coupled SIP Conferencing", RFC 4245, November 2005. 2643 [8] Rosenberg, J., "A Framework for Conferencing with the Session 2644 Initiation Protocol (SIP)", RFC 4353, February 2006. 2646 [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2647 Initiation Protocol (SIP) Event Package for Conference State", 2648 RFC 4575, August 2006. 2650 [10] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 2651 "Requirements for Floor Control Protocols", RFC 4376, 2652 February 2006. 2654 [11] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, 2655 August 2006. 2657 [12] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2658 Call Control - Conferencing for User Agents", BCP 119, 2659 RFC 4579, August 2006. 2661 [13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 2662 Protocol (BFCP)", RFC 4582, November 2006. 2664 [14] Levin, O. and G. Camarillo, "The Session Description Protocol 2665 (SDP) Label Attribute", RFC 4574, August 2006. 2667 [15] Camarillo, G., "Session Description Protocol (SDP) Format for 2668 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 2669 November 2006. 2671 [16] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference 2672 Information Data Model for Centralized Conferencing (XCON)", 2673 draft-ietf-xcon-common-data-model-06 (work in progress), 2674 October 2007. 2676 [17] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 2677 Relay Protocol (MSRP)", RFC 4975, September 2007. 2679 [18] Camarillo, G., "Connection Establishment in the Binary Floor 2680 Control Protocol (BFCP)", RFC 5018, September 2007. 2682 Authors' Addresses 2684 Mary Barnes 2685 Nortel 2686 2201 Lakeside Blvd 2687 Richardson, TX 2689 Email: mary.barnes@nortel.com 2691 Chris Boulton 2692 Avaya 2693 Building 3 2694 Wern Fawr Lane 2695 St Mellons 2696 Cardiff, South Wales CF3 5EA 2698 Email: cboulton@avaya.com 2700 Orit Levin 2701 Microsoft Corporation 2702 One Microsoft Way 2703 Redmond, WA 98052 2705 Email: oritl@microsoft.com 2707 Full Copyright Statement 2709 Copyright (C) The IETF Trust (2007). 2711 This document is subject to the rights, licenses and restrictions 2712 contained in BCP 78, and except as set forth therein, the authors 2713 retain all their rights. 2715 This document and the information contained herein are provided on an 2716 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2717 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2718 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2719 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2720 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2721 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2723 Intellectual Property 2725 The IETF takes no position regarding the validity or scope of any 2726 Intellectual Property Rights or other rights that might be claimed to 2727 pertain to the implementation or use of the technology described in 2728 this document or the extent to which any license under such rights 2729 might or might not be available; nor does it represent that it has 2730 made any independent effort to identify any such rights. Information 2731 on the procedures with respect to rights in RFC documents can be 2732 found in BCP 78 and BCP 79. 2734 Copies of IPR disclosures made to the IETF Secretariat and any 2735 assurances of licenses to be made available, or the result of an 2736 attempt made to obtain a general license or permission for the use of 2737 such proprietary rights by implementers or users of this 2738 specification can be obtained from the IETF on-line IPR repository at 2739 http://www.ietf.org/ipr. 2741 The IETF invites any interested party to bring to its attention any 2742 copyrights, patents or patent applications, or other proprietary 2743 rights that may cover technology that may be required to implement 2744 this standard. Please address the information to the IETF at 2745 ietf-ipr@ietf.org. 2747 Acknowledgment 2749 Funding for the RFC Editor function is provided by the IETF 2750 Administrative Support Activity (IASA).