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