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