idnits 2.17.1 draft-ietf-xcon-framework-06.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 on line 2607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2631. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 RFC 3978 Section 5.4 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 (December 4, 2006) is 6351 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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) == 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-16 == 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: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Informational C. Boulton 5 Expires: June 7, 2007 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 December 4, 2006 10 A Framework and Data Model for Centralized Conferencing 11 draft-ietf-xcon-framework-06 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 June 7, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 58 101 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58 102 15.2. Informative References . . . . . . . . . . . . . . . . . . 58 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 104 Intellectual Property and Copyright Statements . . . . . . . . . . 61 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 upon request, unique URI(s) to identify and represent a 304 conference 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 Floor: Floor refers to a set of data or resources associated with a 337 conference instance, for which a conference participant, or group 338 of participants, is granted temporary access. 339 Floor chair: A floor chair is a floor control protocol compliant 340 client, either a human participant or automated entity, who is 341 authorized to manage access to one floor and can grant, deny or 342 revoke access. The floor chair does not have to be a participant 343 in the conference instance. 344 Focus: A focus is a logical entity that maintains the call 345 signalling interface with each participating client and the 346 conference object representing the active state. As such, the 347 focus acts as an endpoint for each of the supported signaling 348 protocols and is responsible for all primary conference membership 349 operations (e.g., join, leave, update the conference instance) and 350 for media negotiation/maintenance between a conference participant 351 and the focus. 352 Media graph: The media graph is the logical representation of the 353 flow of media for a conference. 354 Media mixer: A media mixer is the logical entity with the capability 355 to combine media inputs of the same type, transcode the media and 356 distribute the result(s) to a single or multiple outputs. In this 357 context, the term "media" means any type of data being delivered 358 over the network using appropriate transport means, such as RTP/ 359 RTCP (defined in RFC 3550[6]) or Message Session Relay Protocol 360 (defined in [18]). 361 Role: A role provides the context for the set of conference 362 operations that a participant can perform. A default role (e.g., 363 standard conference participant) will always exist, providing a 364 user with a set of basic conference operations. Based on system 365 specific authentication and authorization, a user may take on 366 alternate roles, such as conference moderator, allowing access to 367 a wider set of conference operations. 368 Sidebar: A sidebar is a separate Conference instance that only 369 exists within the context of a parent conference instance. The 370 objective of a sidebar is to be able to provide additional or 371 alternate media only to specific participants. 372 Whisper: A whisper involves a one-time media input to a specific 373 participant(s) within a specific conference instance, accomplished 374 using a sidebar. An example of a whisper would be an announcement 375 injected only to the conference chair or to a new participant 376 joining a conference. 378 5. Centralized Conferencing Data Model 380 The centralized conference data model is logically represented by the 381 conference object. A conference object is of type 'Common conference 382 information type', as illustrated in Figure 2. The common conference 383 information type is extensible for including multiple sub-types. 385 +------------------------------------------------------+ 386 | C o n f e r e n c e o b j e c t | 387 | | 388 | +--------------------------------------------------+ | 389 | | Common conference information type | | 390 | | | | 391 | | +----------------------------------------------+ | | 392 | | | Conference description (times, duration) | | | 393 | | +----------------------------------------------+ | | 394 | | +----------------------------------------------+ | | 395 | | | Membership (roles, capacity, names) | | | 396 | | +----------------------------------------------+ | | 397 | | +----------------------------------------------+ | | 398 | | | Signaling (protocol, direction, status) | | | 399 | | +----------------------------------------------+ | | 400 | | +----------------------------------------------+ | | 401 | | | Floor information | | | 402 | | +----------------------------------------------+ | | 403 | | +----------------------------------------------+ | | 404 | | | Sidebars, Etc. | | | 405 | | +----------------------------------------------+ | | 406 | | +----------------------------------------------+ | | 407 | | | Mixer algorithm, inputs, and outputs | | | 408 | | +----------------------------------------------+ | | 409 | | +----------------------------------------------+ | | 410 | | | Floor controls | | | 411 | | +----------------------------------------------+ | | 412 | | +----------------------------------------------+ | | 413 | | | Etc. | | | 414 | | +----------------------------------------------+ | | 415 | +--------------------------------------------------+ | 416 +------------------------------------------------------+ 418 Figure 2: Conference Object Type Decomposition. 420 In a system based on this conferencing framework, the same conference 421 object type is used for representation of a conference during 422 different stages of a conference, such as expressing conferencing 423 system capabilities, reserving conferencing resources or reflecting 424 the state of ongoing conferences. Section 7 describes the usage 425 semantics of the conference objects. 427 The centralized conferencing data model defined in this framework has 428 no strict separation between conference membership, conference media 429 information and the related policies. The policies are an integral 430 part of the data model and are realized by local, system level 431 boundaries associated with specific data elements, such as the 432 membership, and by the ranges and limitations on other data elements. 433 Additional policy considerations for a system realization based on 434 this data model are discussed in Section 5.2. The integration of the 435 data in this model meets the requirement of many conference control 436 operations to enable synchronized access to the integral conference 437 policies, to the conference state as a whole, and for receiving 438 notifications about changes to either using the same interface. 440 The exact XML schema of the conference object, including the 441 organization of the common conference information is detailed in a 442 separate document [17]. 444 5.1. Common Conference Information 446 There is a core set of data in the common conference information that 447 is utilized in any conference, independent of the specific conference 448 media nature (e.g., the mixing algorithms performed, the advanced 449 floor control applied, etc.). This core set of data in the common 450 conference information contains the definitions representing the 451 conference object capabilities, membership, roles, call signaling and 452 media status relevant to different stages of the conference life- 453 cycle. This core set of common conference information may be 454 represented using the conference-type as defined in [10]. Typically, 455 participants with read-only access to the conference information 456 would be interested in this core set of common conference information 457 only. 459 In order to support more complex media manipulations and enhanced 460 conferencing features the common conference information contains 461 additional data, beyond that defined in [10]. The data model defined 462 in [17] would be the basis for conferencing systems supporting 463 enhanced conferencing features. The additional information defined 464 in [17] provides the details of the specific media mixing details, 465 the associated client roles and the available floor controls. This 466 information would allow authorized clients to manipulate the mixer's 467 behavior via the focus, and the resultant distribution of the media 468 to all or individual participants. By doing so, a client can change 469 its own state and/or state of other participants in the conference. 471 New centralized conferencing specifications can extend the basic 472 conference-type as defined in [17] and introduce additional data 473 elements to be used within the common conference information type. 475 5.2. Conference policies 477 Conference policies collectively refers to a set of rights, 478 permissions and limitations pertaining to operations being performed 479 on a certain conference object. 481 The set of rights describes the read/write access privileges for the 482 conference object as a whole. This access would usually be granted 483 and defined in terms of giving the read-only or read-write access to 484 clients with certain roles in the conference. As such, the policies 485 represented by the set of rights aren't explicitly defined within the 486 data model, but rather are reflected in the system realization 487 (Section 7). 489 The permissions and limits, however, are specified as an integral 490 part of the conference object type, with data objects containing the 491 allowed ranges for other data objects (e.g., maximum number of 492 participants) and lists of clients allowed to perform certain 493 operations on a conference object. For example, the "allowed-users- 494 list" of participants is consulted to decide who is allowed to join. 495 The entries in the list can specify the identity of an individual 496 user (joe@example.com), a role, a domain (*@example.com), etc. For 497 further details, refer to the detailed data model [17]. 499 A more general rule mechanism, beyond the functionality provided by 500 the permissions and limits, is an item for future study. 502 6. Centralized Conferencing Constructs and Identifiers 504 This section provides details of the identifiers associated with the 505 centralized conferencing framework constructs and the identifiers 506 necessary to address and manage the clients associated with a 507 conferencing system. An overview of the allocation, characteristics 508 and functional role of the identifiers is provided. 510 6.1. Conference Identifier 512 The conference identifier (conference ID) is a call signaling 513 protocol-specific URI that identifies a specific conference focus and 514 its associated conference instance. A conference factory is one 515 method for generating a unique conference ID, to identify and address 516 a conference focus, using a call signaling interface. Details on the 517 use of a conference factory for SIP signaling can be found in [13]. 518 The conference identifier can also be obtained using the conference 519 control protocol [Section 8.3] or other, including proprietary, out- 520 of-band mechanisms. 522 6.2. Conference Object 524 A Conference object provides the logical representation of a 525 conference instance in a certain stage, such as a conference 526 blueprint representing a conferencing system's capabilities, the data 527 representing a conference reservation, and the conference state 528 during an active conference. Each conference object is independently 529 addressable through the conference control protocol interface 530 [Section 8.3]. 532 Figure 3 illustrates the relationships between the conference 533 identifier, the focus and the conference object ID within the context 534 of a logical conference instance, with the conference object 535 corresponding to an active conference. 537 A conference object representing a conference in the active state can 538 have multiple call signalling conference identifiers; for example, 539 for each call signalling protocol supported. There is a one-to-one 540 mapping between an active conference object and a conference focus. 541 The focus is addressed by explicitly associating unique conference 542 IDs for each signaling protocol supported by the active conference 543 object. 545 ...................................................................... 546 . Conference Instance . 547 . . 548 . . 549 . +---------------------------------------------------+ . 550 . | Conference Object Identifier | . 551 . | | . 552 . | | . 553 . +---------------------------------------------------+ . 554 . ^ ^ . 555 . | | . 556 . v | . 557 . ................................................... | . 558 . . Focus . | . 559 . . . | . 560 . . +----------------------------------+ . | . 561 . . |Conference Identifier (Protocol Y)| . | . 562 . . +------------------------------------+ | . | . 563 . . | Conference Identifier (PSTN) | | . | . 564 . . +--------------------------------------+ |-+ . | . 565 . . | Conference Identifier (SIP) | |^ . | . 566 . . | |-+| . | . 567 . . | |^ | . | . 568 . . +--------------------------------------+| | . | . 569 . ............^...............................|.|.... | . 570 . | | | | . 571 ................|...............................|.|......|............ 572 | | | | 573 |SIP | | |Conference 574 | PSTN | |Y |Control 575 | | | |Protocol 576 | +---------------+ | | 577 | | | | 578 | | | | 579 v v v v 580 +----------------+ +--------------+ +---------------+ 581 | Conferencing | | Conferencing | | Conference | 582 | Client | | Client | | Client | 583 | 1 | | 2 | | X | 584 +----------------+ +--------------+ +---------------+ 586 Figure 3: Identifier Relationships for an Active Conference. 588 6.2.1. Conference Object Identifier 590 In order to make each conference object externally accessible, the 591 conferencing system allocates a unique URI per distinct conference 592 object in the system. A conference control protocol includes the 593 conference object identifier in requests for directly manipulating a 594 particular conference object and for obtaining its current state. 595 The conference object identifier logically maps to other protocol 596 specific identifiers associated with the conference instance, such as 597 the BFCP 'confid'. A full description and semantics of how the 598 conference object identifier is created and used as defined in [19]. 600 6.3. Conference User Identifier 602 Each user within a conferencing system is allocated a unique 603 conference user identifier. The user identifier is used in 604 association with the conference object identifier to uniquely 605 identify a user within the scope of conferencing system. There is 606 also a requirement for identifying conferencing system users who may 607 not be participating in a conference instance. Examples of these 608 users would be a non participating 'Floor Control Chair' or 'Media 609 Policy Controller'. The conference user identifier is required in 610 conference control protocol requests to uniquely determine who is 611 issuing commands, so that appropriate policies can be applied to the 612 requested command. The conference user identifer is logically 613 associated with the other user identifiers assigned to the 614 conferencing client for other protocol interfaces, such as an 615 authenticated SIP user. A full description and semantics of the 616 conference user identifier is provided in [20]. 618 7. Conferencing System Realization 620 Implementations based on this centralized conferencing framework can 621 range from systems supporting ad-hoc conferences, with default 622 behavior only, to sophisticated systems with the ability to schedule 623 recurring conferences, each with distinct characteristics, being 624 integrated with external resource reservation tools, and providing 625 snapshots of the conference information at any of the stages of the 626 conference life-cycle. 628 A conference object is the logical representation of a conference 629 instance at a certain stage, such as capabilities description upon 630 conference creation, reservation, activation, etc., which a 631 conferencing system maintains in order to describe the system 632 capabilities and to provide access to the available services provided 633 by the conferencing system. Consequently, this centralized 634 conferencing framework does not mandate the actual usage of the 635 conference object, but rather defines the general cloning tree 636 concept and the mechanisms required for its realization, as described 637 in detail in Section 7.1. 639 Adhoc and advanced conferencing examples are provided in Section 7.2 640 and Section 7.3, with the latter providing additional description of 641 the Conference Object in terms of the stages of a conference, to 642 support scheduled and other advanced conference capabilities. The 643 scheduling of a conference based on these concepts and mechanisms is 644 then detailed in Section 7.4 646 As discussed in Section 5.2, there are conference policies implicit 647 in and derivable from the data in the conference objects and there 648 are also policies applying to the conference objects as a whole. In 649 the examples in this section, these latter policies are shown 650 logically associated with the conference objects, however, it is an 651 implementation specific mechanism as to how these policies are 652 managed and applied to the conference objects. 654 7.1. Cloning Tree 656 The concept defined in this section is a logical representation only, 657 as it is reflected through the centralized conferencing mechanisms: 658 the URIs and the protocols. Of course, the actual system realization 659 can differ from the presented model. The intent is to illustrate the 660 role of the logical elements in providing an interface to the data, 661 based on conferencing system and conferencing client actions, and 662 describe the resultant protocol implications 664 Any conference object in a conferencing system is created by either 665 being explicitly cloned from an existing parent object or being 666 implicitly cloned from a default system conference blueprint. A 667 conference blueprint is a static conference object used to describe a 668 typical conference setting supported by the system. Each system can 669 maintain multiple blueprints, typically each describing a different 670 conferencing type using the common conference information format. 671 This document uses the "cloning" metaphor instead of the 672 "inheritance" metaphor because it more closely fits the idea of 673 object replication, rather than a data type re-usage and extension 674 concept. 676 The cloning operation needs to specify whether the link between the 677 parent and the child needs to be maintained in the system or not. If 678 no link between the parent and the child exists, the objects become 679 independent and are not impacted by any operations on the parent 680 object nor subject to any limitations of the parent object. 682 Once the new object is created, it can be addressed by a unique 683 conference object URI assigned by the system, as described in [19]. 684 By default, the newly created object contains all the data existing 685 in the parent object. The newly created object can expand the data 686 it contains, within the schema types supported by the parent. It can 687 also restrict the read/write access to its objects. However, unless 688 the object is independent, it cannot modify the access restrictions 689 imposed by the parent object. 691 Any piece of data in the child object can be independently accessed 692 and, by default, can be independently modified without affecting the 693 parent data. 695 Unless the object is independent, the parent object can enforce a 696 different policy by marking certain data elements as "parent 697 enforceable". The values of these data elements can not be changed 698 by directly accessing the child object; neither can they be expanded 699 in the child object alone. 701 Figure 4 illustrates an example of a conference (Parent B), which is 702 created independent of its Parent (Parent A). Parent B creates two 703 child objects, Child 1 and Child 2. Any of the data elements of 704 Parent B can be modified (i.e. there are no "parent enforceable" data 705 elements) and depending upon the element, the changes will be 706 reflected in Child 1 and Child 2 , whereas changes to Parent A will 707 not impact the data elements of Parent B. Any "parent enforceable" 708 data elements as defined by Parent B cannot be modified in the child 709 objects. 711 +---+-----------------------+ 712 | p | | 713 | o | P A R E N T A | 714 | l | | 715 | i | C O N F E R E N C E | 716 | c | | 717 | i | O B J E C T | 718 | e | | 719 +-s-+-----------------------+ 720 | 721 \| / 722 \/ INDEPENDENT 723 /\ 724 /| \ 725 V 726 +---+-----------------------+ 727 | p | | 728 | o | P A R E N T B | 729 | l | | 730 | i | C O N F E R E N C E | 731 | c | | 732 | i | O B J E C T | 733 | e | | 734 +-s-+-----------------------+ 735 | | 736 | | 737 | --------------------------- 738 | | 739 V V 740 +---+-----------------------+ +---+-----------------------+ 741 | p | | | p | | 742 | o | C H I L D 1 | | o | C H I L D 2 | 743 | i | | | l | | 744 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 745 | i | | | c | | 746 | c | O B J E C T | | i | O B J E C T | 747 | i | | | e | | 748 +-s-+-----------------------+ +-s-+-----------------------+ 750 Figure 4: The Cloning Tree. 752 Using the defined cloning model and its tools, the following sections 753 show examples of how different systems based on this framework can be 754 realized. 756 7.2. Ad-hoc Example 758 Figure 5 illustrates how an ad-hoc conference can be created and 759 managed in a conferencing system. A client can create a conference 760 by establishing a call signaling channel with a conference factory as 761 specified in Section 6.1. The conference factory can internally 762 select one of the system supported conference blueprints based on the 763 requesting client privileges and the media lines included in the SDP 764 body. 766 The selected blueprint with its default values is copied by the 767 server into a newly created conference object, referred to as an 768 'Active Conference'. At this point the conference object becomes 769 independent from its blueprint. A new conference object identifier, 770 a new conference identifier and a new focus are allocated by the 771 server. 773 During the conference lifetime, an authorized client can manipulate 774 the conference object, such as adding participants, using the 775 Conference Control Protocol [Section 8.3]. 777 +---+-----------------------+ 778 | p | | 779 | o | System Default | 780 | l | | 781 | i | Conference | 782 | c | | 783 | i | Blueprint | 784 | e | | 785 +-s-+-----------------------+ 786 | 787 \| / 788 \/ 789 /\ 790 /| \ 791 V 792 +---+-----------------------+ 793 | p | | 794 | o | Active | 795 | l | | 796 | i | Conference | 797 | c | | 798 | i | | 799 | e | | 800 +-s-+-----------------------+ 801 Figure 5: Conference Ad-hoc Creation and Lifetime. 803 7.3. Advanced Example 805 Figure 6 illustrates how a recurring conference can be specified 806 according to system capabilities, scheduled, reserved, and managed in 807 a conferencing system. A client would first query a conferencing 808 system for its capabilities. This can be done by requesting a list 809 of the conference blueprints the system supports. Each blueprint 810 contains a specific combination of capabilities and limitations of 811 the conference server in terms of supported media types (e.g., audio, 812 video, text, or combinations of these), participant roles, maximum 813 number of participants of each role, availability of floor control, 814 controls available for participants, availability and type of 815 sidebars, the definitions and names of media streams, etc. 817 The selected blueprint with its default values is cloned by the 818 client into a newly created conference object, referred to as a 819 conference reservation, that specifies the resources needed from the 820 system for this conference instance. At this point the conference 821 reservation becomes independent from its blueprint. The client can 822 also change the default values, within the system ranges, and add 823 additional information, such as the list of participants and the 824 conference start time, to the conference reservation. 826 At this point the client can ask the conference server to create new 827 conference reservations by attaching the conference reservation to 828 the request. As a result, the server can allocate the needed 829 resources, create the additional conference objects for the child 830 conference reservations and allocate the conference object 831 identifiers for all - the original conference reservation and for 832 each child conference reservation. 834 From this point on, any authorized client is able to access and 835 modify each of the conference objects independently. By default, 836 changes to an individual child conference reservation will affect 837 neither the parent conference reservation, from which it was created, 838 nor its siblings. 840 On the other hand, some of the conference sub-objects, such as the 841 maximum number of participants and the participants list, can be 842 defined by the system as parent enforceable. As a result, these 843 objects can be modified by accessing the parent conference 844 reservation only. The changes to these objects can be applied 845 automatically to each of the child reservations, subject to local 846 policy. 848 +---+-----------------------+ 849 | p | | 850 | o | Selected | 851 | l | | 852 | i | Conference | 853 | c | | 854 | i | Blueprint | 855 | e | | 856 +-s-+-----------------------+ 857 | 858 \| / 859 \/ 860 /\ 861 /| \ 862 V 863 +---+-----------------------+ 864 | p | | 865 | o | Conference | 866 | l | | 867 | i | Reservation | 868 | c | | 869 | i | | 870 | e | | 871 +-s-+-----------------------+ 872 | | | 873 | | | 874 | | | 875 | | | 876 +---|--|--V-----------------+ 877 +-+---|--V------------------+ | 878 +-+-+---V-------------------+ | | 879 | p | | | | 880 | o | Child Conference | | | 881 | l | | | | 882 | i | Reservation | | | 883 | c | | | | 884 | i | | |-+ 885 | e | |-+ 886 +-s-+-----------------------+ 888 Figure 6: Advanced Conference Definition, Creation, and Lifetime. 890 When the time comes to schedule the conference reservation, either 891 via the system determination that the 'start' time has been reached 892 or via client invocation, an active conference is cloned based on the 893 conference reservation. As in the adhoc example, the active 894 conference is independent from the parent and changes to the 895 conference reservation will not impact the active conference. Any 896 desired changes must be targeted towards the active conference. An 897 example of this interaction is shown in Section 9.1 899 7.4. Scheduling a conference 901 The capability to schedule conferences forms an important part of the 902 conferencing system solution. An individual conference reservation 903 typically has a specified 'start' and 'end' time, with the times 904 being specified relative to a single specified 'fixed' time (e.g., 905 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 906 considerations. In most advanced conferencing solutions it is 907 possible to not only schedule an individual occurrence of a 908 conference reservation, but also schedule a series of related 909 conferences (e.g., a weekly meeting that starts on Thursday at 09.00 910 GMT). 912 To be able to achieve such functionality, a conferencing system needs 913 to be able to appropriately schedule and maintain conference 914 reservations that form part of a recurring conference. The mechanism 915 proposed in this document makes use of the 'Internet Calendaring and 916 Scheduling Core Object' specification defined in RFC2445[7] in union 917 with the concepts introduced in Section 5 for the purpose of 918 achieving advanced conference scheduling capability. 920 Figure 7 illustrates a simplified view of a client interacting with a 921 conferencing system. The client is using the Conference Control 922 Protocol (Section 8.3) to add a new conference reservation to the 923 conferencing system by interfacing with the conference control 924 server. A CCP request contains a valid conference reservation and 925 reference by value to an 'iCal' object which contains scheduling 926 information about the conference (e.g., start time, end time). 928 +--------------+ +-------Conferencing System-----------------+ 929 | Generic ICAL | | | 930 | Resource | | ..Conference Instance.... | 931 +--------------+ | . . +-----------+| 932 ^ ^ | . +-------------------+ . | Conference|| 933 | | | . |Conference Objects |<--| Control || 934 | ----------------->. +-------------------+ . | Server || 935 | | . . +-----------+| 936 | | ......................... ^ | 937 | | ^ | | 938 +-----|--------------+ | | | 939 | v | | | 940 | +--------------+ | | | 941 | | Resource |<------------------+ | | 942 | | Scheduler | | | 943 | +--------------+ | | 944 | | | 945 +---------------------------------------------------------|------+ 946 | 947 | 948 +-Request-+ 949 | | 950 +----+ | 951 |ICAL| | 952 +----+----+ 953 | 954 | 955 | 956 Conference Control| 957 Protocol | 958 | 959 +-------------+ 960 | Conferencing| 961 | Client | 962 +-------------+ 964 Figure 7: Resource Scheduling 966 A CCP request to create a new conference reservation is validated, 967 including the associated iCal object, and the resultant conference 968 reservation is created. The conference reservation is uniquely 969 represented within the conferencing system by a conference object 970 identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and 971 defined in [19]. This unique URI is returned to the client and can 972 be used to reference the conference reservation, if any future 973 manipulations are required (e.g., alter start time), using a CCP 974 request. 976 The previous example explains how a client creates a basic conference 977 reservation using an iCal reference in association with a conference 978 control protocol. Figure 7 can also be applied when explaining how a 979 series of conferences are scheduled in the system. The description 980 is almost identical with the exception that the iCal definition that 981 is included in a CCP request represents a series of recurring 982 conference instances (e.g., conference start time, end time, occur 983 weekly). The conferencing system will treat this request the same as 984 the first example. The CCP request will be validated, along with the 985 associated iCal object, and the conference reservation is created. 986 The conference reservation and its conference object ID created for 987 this example represent the entire series of recurring conference 988 instances rather than a single Conference. If the client uses the 989 conference object ID provided and a CCP request to adjust the 990 conference reservation, every conference instance in the series will 991 be altered. This includes all future occurrences, such as a 992 conference scheduled as an infinite series, subject to the 993 limitations of the available calendaring interface. 995 A conferencing system that supports the scheduling of a series of 996 conference instances should also be able to support manipulation 997 within a specific range of the series. A good example is a 998 conference reservation that has been scheduled to occur every Monday 999 at 09.00 GMT. For the next three weeks only, the meeting has been 1000 altered to occur at 10.00 GMT in an alternative venue. With Figure 7 1001 in mind, the client will construct a CCP request whose purpose is to 1002 modify the existing conference reservation for the recurring 1003 conference instance. The client will include the conference object 1004 ID provided by the conferencing system to explicitly reference the 1005 conference reservation within the conferencing system. A CCP request 1006 will contain all the required changes to the conference reservation 1007 (e.g., change of venue). 1009 The conferencing system matches the incoming CCP request to the 1010 existing conference reservation but identifies that the associated 1011 iCal object only refers to a range of the existing series. The 1012 conferencing system creates a child, by cloning the original 1013 conference reservation, to represent the altered conference instances 1014 within the series. The cloned child object is not independent of the 1015 original parent object, thus preventing any potential conflicts in 1016 scheduling (e.g., a change to the whole series 'start time'). The 1017 cloned conference reservation, representing the altered series of 1018 conference instances, has its own associated conference object ID 1019 which is returned to the client using a CCP response. This 1020 conference object ID is then used by the client to make any future 1021 alterations on the newly defined sub-series. This process can be 1022 repeated any number of times as the newly returned conference object 1023 ID representing an altered (cloned) series of conference instances, 1024 can itself be manipulated using a CCP request for the newly created 1025 conference object ID . This provides a flexible approach to the 1026 scheduling of recurring conference instances. 1028 8. Conferencing Mechanisms 1030 8.1. Call Signaling 1032 The focus is the central component of the conference. Participants 1033 interface with the focus using an appropriate call signaling protocol 1034 (CSP). Participants request to establish or join a conference using 1035 the CSP. After checking the applicable policies, a focus then either 1036 accepts the request, sends a progress indication related to the 1037 status of the request (e.g., for a parked call while awaiting 1038 moderator approval to join) or rejects that request using the call 1039 signaling interface. 1041 During an active conference, a Conference Control Protocol 1042 [Section 8.3] can be used to affect the conference state. For 1043 example, CCP requests to add and delete participants are communicated 1044 to the focus and checked against the conference policies. If 1045 approved, the participants are added or deleted using the call 1046 signaling to/from the focus. 1048 8.2. Notifications 1050 A conferencing system is responsible for implementing a Conference 1051 Notification Service. The Conference Notification Service provides 1052 updates about the conference instance state to authorized parties, 1053 including participants. A model for notifications using SIP is 1054 defined in [5] with the specifics to support conferencing defined in 1055 [10]. 1057 The conference user identifier and associated role are used by the 1058 conferencing system to filter the notifications such that they 1059 contain only information that is allowed to be sent to that user. 1061 8.3. Conference Control Protocol 1063 The conference control protocol provides for data manipulation and 1064 state retrieval for the centralized conferencing data, represented by 1065 the conference object. The details of the conference control 1066 protocol are provided in separate documents. 1068 8.4. Floor Control 1070 A floor control protocol allows an authorized client to manage access 1071 to a specific floor and to grant, deny or revoke access of other 1072 conference users to that floor. Floor control is not a mandatory 1073 mechanism for a conferencing system implementation but provides 1074 advanced media input control features for conference users. A 1075 mechanism for floor control within a conferencing system is defined 1076 in the Binary Floor Control Protocol specification [14]. 1078 Within this framework, a client supporting floor control needs to 1079 obtain information for connecting to a floor control server to enable 1080 it to issue floor requests. This connection information can be 1081 retrieved using information provided by mechanisms such as 1082 negotiation using the SDP[2] offer/answer[4] exchange on the 1083 signaling interface with the focus. Section 11.3 provides a 1084 discussion of client authentication of a floor control server. 1086 As well as the client to the floor control server connection 1087 information, a client wishing to interact with a floor control server 1088 requires access to additional information. This information 1089 associates floor control interactions with the appropriate floor 1090 instance. Once a connection has been established and authenticated 1091 (see [14] for authentication details), a specific floor control 1092 message requires detailed information to uniquely identify a 1093 conference, a user and a floor. 1095 The conference is uniquely identifed by the conference object ID per 1096 Section 6.2.1. This conference object ID must be included in all 1097 floor control messages. When the SDP model is used as described in 1098 [16] this identifier maps to the 'confid' SDP attribute. 1100 Each authorized user associated with a conference object is uniquely 1101 represented by a conference user ID per Section 6.3. This conference 1102 user ID must be included in all floor control messages. When using 1103 SDP offer/answer exchange to negotiate a Floor control connection 1104 with the focus using the call signaling protocol, the unique 1105 conference identifier is contained in the 'userid' SDP attribute, as 1106 defined in [16] 1108 A media session within a conferencing system can have any number of 1109 floors (0 or more) that are represented by the conference identifer. 1110 When using SDP offer/answer exchange to negotiate a floor control 1111 connection with the focus using the call signaling interface, the 1112 unique conference identifier is contained in the 'floorid' SDP 1113 attribute, as defined in [16] e.g., a=floorid:1 m-stream:10 . Each 1114 'floorid' attribute, representing a unique floor, has an 'm-stream' 1115 tag containing one or more identifiers. The identifiers represent 1116 individual SDP media sessions (as defined using 'm=' from SDP) using 1117 the SDP 'Label' attribute as defined in [15]. 1119 9. Conferencing Scenario Realizations 1121 This section addresses how advanced conferencing scenarios, many of 1122 which have been described in [12], are realized using this 1123 centralized conferencing framework. The objective of this section is 1124 to further illustrate the model, mechanisms and protocols presented 1125 in the previous sections and also serves to validate that the model, 1126 mechanisms and protocols are sufficient to support advanced 1127 conferencing scenarios. 1129 The details shown in the messages are for illustrative purposes only 1130 and don't reflect the structure of the conference control protocol 1131 messages, but rather provide a high level primitive view of the 1132 necessary operations and general logic flow, including the data 1133 manipulation aspects. It should be noted that not all entities 1134 impacted by the request are shown in the diagram (e.g., Focus), but 1135 rather the emphasis is on the new entities introduced by this 1136 centralized conferencing framework. 1138 9.1. Conference Creation 1140 There are different ways to create a conference. A participant can 1141 create a conference using call signaling means only, such as SIP and 1142 detailed in [13]. For a conferencing client to have more flexibility 1143 in defining the charaterisitics and capabilities of a conference, a 1144 conferencing client would implement a conference control protocol 1145 client. By using a conference control protocol, the client can 1146 determine the capabilities of a conferencing system and its various 1147 resources. 1149 Figure 8 provides an example of one client "Alice" determining the 1150 conference blueprints available for a particular conferencing system 1151 and creating a conference based on the desired blueprint. 1153 +--------------------------------+ 1154 | Conferencing System | 1155 "Alice" | +------------+| 1156 +--------+ | | || 1157 | |CCP Request | +-----------+ | || 1158 | Client |-------------------------->|Conference | |Conference || 1159 | |<--------------------------|Control |~~~>|Blueprint(s)|| 1160 +--------+CCP Response | | 1164 "Alice" | 1165 +--------+ | | 1166 | |CCP Request |Conference | |Conference || 1169 | | confUserID> | |Control |~~~>|BlueprintA || 1170 | |<--------------------------|Server | | || 1171 | |CCP Response | | | +------------+| 1172 +--------+ | | | /|\ | 1174 | | | V | 1175 | | | +------------+| 1176 | | |~~~>|Conference || 1177 | | | |Reservation || 1178 | +-----------+ +------------+| 1179 "Alice" | | | 1180 +--------+ | | | 1181 | |CCP Request |Conference | |Active || 1184 | | confID,confUserID> | |Control |~~~>|Conference || 1185 | |<--------------------------|Server | | || 1186 | |CCP Response | | | +------------+| 1187 +--------+ | +-----------+ | 1189 +--------------------------------+ 1191 Figure 8: Client Creation of Conference using Blueprints 1193 Upon receipt of the Conference Control Protocol request for 1194 blueprints, the conferencing system would first authenticate "Alice" 1195 (and allocate a conference user identifier, if necessary) and then 1196 ensure that "Alice" has the appropriate authority based on system 1197 policies to receive any blueprints supported by that system. Any 1198 blueprints that "Alice" is authorized to use are returned in a 1199 response, along with the conference user ID. 1201 Upon receipt of the Conference Control Protocol response containing 1202 the blueprints, "Alice" determines which blueprint to use for the 1203 conference to be created. "Alice" creates a conference object based 1204 on the blueprint (i.e., clones) and modifies applicable fields, such 1205 as membership list and start time. "Alice" then sends a request to 1206 the conferencing system to create a conference reservation based upon 1207 the updated blueprint. 1209 Upon receipt of the Conference Control Protocol request to "reserve" 1210 a conference based upon the blueprint in the request, the 1211 conferencing system ensures that the blueprint received is a valid 1212 blueprint (i.e. the values of the various field are within range). 1213 The conferencing system determines the appropriate read/write access 1214 of any users to be added to a conference based on this blueprint 1215 (using membership, roles, etc.). The conferencing system uses the 1216 received blueprint to clone a conference reservation. The 1217 conferencing system also reserves or allocates a conference ID to be 1218 used for any subsequent protocol requests from any of the members of 1219 the conference. The conferencing system maintains the mapping 1220 between this conference ID and the conference object ID associated 1221 with the reservation through the conference instance. 1223 Upon receipt of the conference control protocol response to reserve 1224 the conference, "Alice" can now create an active conference using 1225 that reservation or create additional reservations based upon the 1226 existing reservations. In this example, "Alice" has reserved a 1227 meetme conference bridge. Thus, "Alice" provides the conference 1228 information, including the necessary conference ID, to desired 1229 participants. When the first participant, including "Alice", 1230 requests to be added to the conference, an active conference and 1231 focus are created. The focus is associated with the conference ID 1232 received in the request. Any participants that have the authority to 1233 manipulate the conference would receive the conference object 1234 identifier of the active conference object in the response. 1236 9.2. Participant Manipulations 1238 There are different ways to affect a participant state in a 1239 conference. A participant can join and leave the conference using 1240 call signaling means only, such as SIP. This kind of operation is 1241 called "1st party signaling" and does not affect the state of other 1242 participants in the conference. 1244 Limited operations for controlling other conference participants (a 1245 so called "3rd party control") through the Focus, using call 1246 signaling only, may also be available for some signaling protocols. 1247 For example, "Conferencing for SIP User Agents" [13] shows how SIP 1248 with REFER can be used to achieve this functionality. 1250 In order to perform richer conference control a user client needs to 1251 implement a conference control protocol client. By using a 1252 conference control protocol, the client can affect its own state, 1253 state of other participants, and state of various resources (such as 1254 media mixers) which may indirectly affect the state of any of the 1255 conference participants. 1257 Figure 9 provides an example of one client "Alice" impacting the 1258 state of another client "Bob". This example assumes an established 1259 conference. In this example, "Alice" wants to add "Bob" to the 1260 conference. 1262 +--------------------------------+ 1263 | Conferencing System | 1264 "Alice" | +---------+--+| 1265 +--------+ | |policies | || 1266 | |CCP Request < | +-----------+ +---------+ || 1267 | Client |-------------------------->|Conference | | Active || 1268 | | Conference Object ID, | |Control |~~~>|Conference || 1269 +--------+ Add, "Bob" > | |Server | | || 1270 | +-----------+ +-------+ || 1271 | |"Alice"| || 1272 "Carol" | ' ' '| 1273 +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| 1274 | |<-------------------------|Notification|<~~~| || 1275 | Client |. . ||Service | +-------+ || 1276 +--------+--+ . || | |"Bob" | || 1277 | |<----------------------| | +-------+----+| 1278 | Client |NOTIFY <"Bob"="added">|+------------+ | 1279 +--------+ +--------------------------------+ 1280 "Bob" 1282 Figure 9: Client Manipulation of Conference - Add a party 1284 Upon receipt of the Conference Control Protocol request to "add" a 1285 party ("Bob") in the specific conference as identified by the 1286 conference object ID, the conferencing system ensures that "Alice" 1287 has the appropriate authority based on the policies associated with 1288 that specific conference object to perform the operation. The 1289 conferencing system must also determine whether "Bob" is already a 1290 user of this conferencing system or whether he is a new user. 1292 If "Bob" is a new user for this conferencing system, a Conference 1293 User Identifier is created for Bob. Based upon the addressing 1294 information provided for "Bob" by "Alice", the call signaling to add 1295 "Bob" to the conference is instigated through the Focus. 1297 Once the call signaling indicates that "Bob" has been successfully 1298 added to the specific conference, per updates to the state, and 1299 depending upon the policies, other participants (including "Bob") may 1300 be notified of the addition of "Bob" to the conference via the 1301 Conference Notification Service. 1303 9.3. Media Manipulations 1305 There are different ways to manipulate the media in a conference. A 1306 participant can change its own media streams by, for example, sending 1307 re-INVITE with new SDP content using SIP only. This kind of 1308 operation is called "1st party signaling" and they do not affect the 1309 state of other participants in the conference. 1311 In order to perform richer conference control a user client needs to 1312 implement a conference control protocol client. By using a 1313 conference control protocol, the client can manipulate the state of 1314 various resources, such as media mixers, which may indirectly affect 1315 the state of any of the conference participants. 1317 Figure 10 provides an example of one client "Alice" impacting the 1318 media state of another client "Bob". This example assumes an 1319 established conference. In this example, the client, "Alice" whose 1320 Role is "moderator" of the conference, wants to mute "Bob" on a 1321 medium-size multi-party conference, as his device is not muted (and 1322 he's obviously not listening to the call) and background noise in his 1323 office environment is disruptive to the conference. 1325 +--------------------------------+ 1326 | Conferencing System | 1327 "Alice" | +---------+--+| 1328 +--------+ | |policies | || 1329 | |CCP Request < | +-----------+ +---------+ || 1330 | Client |-------------------------->|Conference | |Active || 1331 | | Conference Object ID, | |Control |~~~>|Conference || 1332 +--------+ Mute, "Bob" > | |Server | | || 1333 | +-----------+ +-------+ || 1334 | |"Alice"| || 1335 | ' ' '| 1336 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1337 | |<-------------------------|Notification|<~~~| || 1338 | Client |. . ||Service | +-------+ || 1339 +--------+--+ . || | |"Bob" | || 1340 | |<----------------------| | +-------+----+| 1341 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1342 +--------+ +--------------------------------+ 1344 Figure 10: Client Manipulation of Conference - Mute a party 1346 Upon receipt of the Conference Control Protocol request to "mute" a 1347 party ("Bob") in the specific conference as identified by the 1348 conference object ID, the Conference Server ensures that "Alice" has 1349 the appropriate authority based on the policies associated with that 1350 specific conference object to perform the operation. "Bob's" status 1351 is marked as "recvonly" and the the conference object is updated to 1352 reflect that "Bob's" media is not to be "mixed" with the conference 1353 media. 1355 Depending upon the policies, other participants (including "Bob") may 1356 be notified of this change via the Conference Notification Service. 1358 9.4. Sidebar Manipulations 1360 A sidebar can be viewed as a separate Conference instance that only 1361 exists within the context of a parent conference instance. Although 1362 viewed as an independent conference instance, it can not exist 1363 without a parent. A sidebar is created using the same mechanisms 1364 employed for a standard conference as described in Section 7.1. 1366 A conference object representing a sidebar is created by cloning the 1367 parent associated with the existing conference and updating any 1368 information specific to the sidebar. A sidebar conference object is 1369 implicitly linked to the parent conference object (i.e. it is not an 1370 independent object) and is associated with the parent conference 1371 object identifier as as shown in Figure 11. A conferencing system 1372 manages and enforces the parent and appropriate localized 1373 restrictions on the sidebar conference object (e.g., no members from 1374 outside the parent conference instance can join, sidebar conference 1375 can not exist if parent conference is terminated, etc.). 1377 +--------------+ 1378 | Conference | 1379 | Object | 1380 | Identifier | 1381 +--------------+ 1382 | 1383 | 1384 | 1385 +---------------------+---------------------+ 1386 | | | 1387 +-------+-------+ +-------+-------+ +-------+-------+ 1388 | Sidebar | | Sidebar | | Sidebar | 1389 | Conference | | Conference | | Conference | 1390 | Object | | Object | | Object | 1391 | Identifier | | Identifier | | Identifier | 1392 +-------+-------+ +-------+-------+ +---------------+ 1394 Figure 11: Conference Object Mapping. 1396 Figure 11 illustrates the relationship between a conference object 1397 and associated Sidebar conference objects within a conferencing 1398 system. Each Sidebar conference object has a unique conference 1399 object Identifier as described in Section 6.2.1. The main conference 1400 object identifier acts as a top level identifier for associated 1401 sidebars. 1403 A sidebar conference object Identifier follows many of the concepts 1404 outlined in the cloning tree model described in Section 7.1. A 1405 Sidebar conference object contains a subset of members from the 1406 original Conference object. Properties of the sidebar conference 1407 object can be manipulated by a Conference Control Protocol 1408 (Section 8.3) using the unique conference object identifier for the 1409 sidebar. It is also possible for the top level conference object to 1410 enforce policy on the sidebar object (similar to parent enforceable 1411 as discussed in Section 7.1). 1413 9.4.1. Internal Sidebar 1415 Figure 12 provides an example of one client "Alice" involved in 1416 active conference with "Bob" and "Carol". "Alice" wants to create a 1417 sidebar to have a side discussion with "Bob" while still viewing the 1418 video associated with the main conference. Alternatively, the audio 1419 from the main conference could be maintained at a reduced volume. 1420 "Alice" initiates the sidebar by sending a request to the 1421 conferencing system to create a conference reservation based upon the 1422 active conference object. "Alice" and "Bob" would remain on the 1423 roster of the main conference such that the other participants would 1424 be unaware of the sidebar. 1426 +--------------------------------+ 1427 | Conferencing System | 1428 | +---------+--+| 1429 | |policies | || 1430 | +---------+ || 1431 | |Active || 1432 | |Conference || 1433 "Alice" | +-------+ || 1434 +--------+ | |"Alice"| || 1435 | |CCP Req |Conference | +-------+ || 1438 | | confUserID> | |Control |~~~>|"Carol"| || 1439 | |<--------------------------|Server | +-------+----+| 1440 | |CCP Response | | | | | 1441 +--------+ | | | V | 1443 | | | +---------+--+| 1444 | | | |policies | || 1445 | | |~~~>+---------+ || 1446 | | | | || 1447 | +-----------+ | || 1448 "Alice" | | Sidebar || 1449 +--------+ | | Reservation|| 1450 | |CCP Request | |~~~>| || 1453 | | confID,confUserID, | | | +------------+| 1454 | | video=parent, | | | | | 1455 | | audio=sidebar> | |Conference | | | 1456 | | | |Control | V | 1457 | | | |Server | +---------+--+| 1458 | |CCP Response | | | |policies | || 1459 | | | | | |Sidebar || 1462 | | | |Conference || 1463 | +-----------+ +-------+ || 1464 | |"Alice"| || 1465 "Bob" | | | || 1466 +--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ || 1467 | |<-------------------------|Notification|<~~~| | || 1468 | Client | ||Service | |"Bob" | || 1469 +--------+ || | +-------+----+| 1470 |+------------+ | 1471 +--------------------------------+ 1473 Figure 12: Client Creation of a Sidebar Conference 1475 Upon receipt of the Conference Control Protocol request to "reserve" 1476 a new sidebar conference, based upon the active conference received 1477 in the request, the conferencing system uses the received active 1478 conference to clone a conference reservation for the sidebar. As 1479 discussed previously, the sidebar reservation is NOT independent of 1480 the active conference (i.e., parent). The conferencing system also 1481 reserves or allocates a conference ID to be used for any subsequent 1482 protocol requests from any of the members of the conference. The 1483 conferencing system maintains the mapping between this conference ID 1484 and the conference object ID associated with the sidebar reservation 1485 through the conference instance. 1487 Upon receipt of the conference control protocol response to reserve 1488 the conference, "Alice" can now create an active conference using 1489 that reservation or create additional reservations based upon the 1490 existing reservations. In this example, "Alice" wants only "Bob" to 1491 be involved in the sidebar, thus she manipulates the membership. 1492 "Alice" also only wants the video from the original conference and 1493 wants the audio to be restricted to the participants in the sidebar. 1494 Alternatively, "Alice" could manipulate the media values to recieve 1495 the audio from the main conference at a reduced volume. "Alice" 1496 sends a conference control protocol request to update the information 1497 in the reservation and to create an active conference. 1499 Upon receipt of the conference control protocol request to update the 1500 reservation and to create an active conference for the sidebar, as 1501 identified by the conference object ID, the conferencing system 1502 ensures that "Alice" has the appropriate authority based on the 1503 policies associated with that specific conference object to perform 1504 the operation. The conferencing system must also validate the 1505 updated information in the reservation, ensuring whether members like 1506 "Bob" are already a user of this conferencing system or whether he is 1507 a new user. If "Bob" is a new user for this conferencing system, a 1508 conference user identifier is created for Bob. Based upon the 1509 addressing information provided for "Bob" by "Alice", the call 1510 signaling to add "Bob" to the conference is instigated through the 1511 Focus. 1513 Depending upon the policies, the participants in the sidebar (i.e., 1514 "Bob") may be notified of his addition to the sidebar via the 1515 conference notification service. 1517 9.4.2. External Sidebar 1519 Figure 13 provides an example of one client "Alice" involved in an 1520 active conference with "Bob", "Carol", "David" and "Ethel". "Alice" 1521 gets an important text message via a whisper from "Bob" that a 1522 critical customer needs to talk to "Alice", "Bob" and "Ethel". 1523 "Alice" creates a sidebar to have a side discussion with the customer 1524 "Fred" including the participants in the current conference with the 1525 exception of "Carol" and "David", who remain in the active 1526 conference. "Alice" initiates the sidebar by sending a request to 1527 the conferencing system to create a conference reservation based upon 1528 the active conference object. "Alice", "Bob" and "Ethel" would 1529 remain on the roster of the main conference in a hold state. Whether 1530 or not the hold state of these participants is visible to other 1531 participants depends upon the individual and local policy. 1533 +--------------------------------+ 1534 | Conferencing System | 1535 | +---------+--+| 1536 | |policies | || 1537 | +---------+ || 1538 | |Active || 1539 | |Conference || 1540 "Alice" | +-------+ || 1541 +--------+ | |"Alice"| || 1542 | |CCP Req |Conference | +-------+ || 1545 | | confUserID> | |Control |~~~>|"Carol"| || 1546 | |<--------------------------|Server | +-------+ || 1547 | |CCP Response | | | |"David"| || 1548 +--------+ | | | |"Ethel"| || 1550 | | | +-------+----+| 1551 | | | | | 1552 | | | V | 1553 | | | +---------+--+| 1554 | | | |policies | || 1555 | | |~~~>+---------+ || 1556 | +-----------+ | || 1557 "Alice" | | Sidebar || 1558 +--------+ | | Reservation|| 1559 | |CCP Request | |~~~>| || 1562 | | confID,confUserID, | | | +------------+| 1563 | | video=sidebar, | | | | | 1564 | | audio=sidebar> | |Conference | | | 1565 | | | |Control | V | 1566 | | | |Server | +---------+--+| 1567 | |CCP Response | | | |policies | || 1568 | | | | | |Sidebar || 1571 | | | |Conference || 1572 | +-----------+ +-------+ || 1573 | |"Alice"| || 1574 "Bob" | +-------+ || 1575 +--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | || 1576 | Client |<-------------------------|Notification|<~~~+-------+ || 1577 +--------+ "Ethel"=added, ||Service | |"Ethel"| || 1578 "Fred"=added,> || | +-------+ || 1579 "Ethel" +---| | |"Fred" | || 1580 +--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+| 1581 | Client | <--------------------+ +--------------------------------+ 1582 +--------+ "Ethel"=added,"Fred"=added,> 1584 Figure 13: Client Creation of an External Sidebar 1586 Upon receipt of the Conference Control Protocol request to "reserve" 1587 a new sidebar conference, based upon the active conference received 1588 in the request, the conferencing system uses the received active 1589 conference to clone a conference reservation for the sidebar. As 1590 discussed previously, the sidebar reservation is NOT independent of 1591 the active conference (i.e., parent). The conferencing system also 1592 reserves or allocates a conference ID to be used for any subsequent 1593 protocol requests from any of the members of the conference. The 1594 conferencing system maintains the mapping between this conference ID 1595 and the conference object ID associated with the sidebar reservation 1596 through the conference instance. 1598 Upon receipt of the conference control protocol response to reserve 1599 the conference, "Alice" can now create an active conference using 1600 that reservation or create additional reservations based upon the 1601 existing reservations. In this example, "Alice" wants only "Bob" and 1602 "Ethel", along with the new participant "Fred" to be involved in the 1603 sidebar, thus she manipulates the membership. "Alice" sets the media 1604 such that the participants in the sidebar don't receive any media 1605 from the main conference. "Alice" sends a conference control 1606 protocol request to update the information in the reservation and to 1607 create an active conference. 1609 Upon receipt of the conference control protocol request to update the 1610 reservation and to create an active conference for the sidebar, as 1611 identified by the conference object ID, the conferencing system 1612 ensures that "Alice" has the appropriate authority based on the 1613 policies associated with that specific conference object to perform 1614 the operation. The conferencing system must also validate the 1615 updated information in the reservation, ensuring whether members like 1616 "Fred" are already a user of this conferencing system or whether he 1617 is a new user. Since "Fred" is a new user for this conferencing 1618 system, a conference user identifier is created for "Fred". Based 1619 upon the addressing information provided for "Fred" by "Alice", the 1620 call signaling to add "Fred" to the conference is instigated through 1621 the Focus. 1623 Depending upon the policies, the participants in the sidebar (i.e., 1624 "Bob" and "Ethel") may be notified of his addition to the sidebar via 1625 the conference notification service. 1627 9.5. Floor control using sidebars 1629 Floor control with sidebars can be used to realize conferencing 1630 scenario such as an analyst briefing. In this scenario, the 1631 conference call has a panel of speakers who are allowed to talk in 1632 the main conference. The other participants are the analysts, who 1633 are not allowed to speak unless they have the floor. To request 1634 access to the floor, they have to join a new sidebar with the 1635 moderator and ask their question. The moderator can also whisper to 1636 each analyst what their status/position in the floor control queue, 1637 similar to the example in Figure 15 1639 Figure 14 provides an example of the configuration involved for this 1640 type of conference. As in the previous sidebar examples, there is 1641 the main conference along with a sidebar. "Alice" and "Bob" are the 1642 main participants in the conference, with "A1", "A2" and "A3" 1643 representing the analysts. The sidebar remains active throughout the 1644 conference, with the moderator, "Carol", serving as the chair. As 1645 discussed previously, the sidebar conference is NOT independent of 1646 the active conference (i.e., parent). The analysts are provided the 1647 conference object ID associated with the active sidebar when they 1648 join the main conference. The conferencing system also allocates a 1649 conference ID to be used for any subsequent manipulations of the 1650 sidebar conference. The conferencing system maintains the mapping 1651 between this conference ID and the conference object ID associated 1652 with the active sidebar conference through the conference instance. 1653 The analysts are permanently muted while in the main conference. The 1654 analysts are moved to the sidebar when they wish to speak. Only one 1655 analyst is given the floor at a given time. All participants in the 1656 sidebar conference receive audio from the main conference. 1658 +--------------------------------+ 1659 | Conferencing System | 1660 | +---------+--+| 1661 | |policies | || 1662 | +---------+ || 1663 | |Active || 1664 | |Conference || 1665 | +-------+ || 1666 | |"Alice"| || 1667 | +-------+ || 1668 | +-----------+ |"Bob" | || 1669 | |Conference | +-------+ || 1670 | |Control |~~~>|"A1" | || 1671 | |Server | +-------+ || 1672 | | | |"A2" | || 1673 | | | +-------+ || 1674 | | | |"A3" | || 1675 | | | +-------+----+| 1676 | | | | | 1677 | | | V | 1678 | | | +---------+--+| 1679 | | | |policies | || 1680 | | |~~~>+---------+ || 1681 | | | |Active || 1682 | +-----------+ |Sidebar || 1683 "A1" | |Conference || 1684 +--------+ Floor Request <"A1", |+------------+ +-------+ || 1685 | |------------------------->|Floor Ctrl | |"Carol"| || 1686 |Client | activeSideConfObjID,||Server |~~~>| | || 1687 +--------+ confID > || | +-------+----+| 1688 |+------------+ | | 1689 | V | 1690 | +---------+--+| 1691 | |policies | || 1692 | +---------+ || 1693 | |Active || 1694 | |Sidebar || 1695 "A1" | |Conference || 1696 +--------+ Floor Granted <"A1", |+------------+ +-------+ || 1697 | |<-------------------------|Floor Ctrl |<~~~|"Carol"| || 1698 | Client | activeSideConfObjID,||Server | +-------+ || 1699 +--------+ confID > || | |"A1" | || 1700 |+------------+ +-------+----+| 1701 +--------------------------------+ 1703 Figure 14: Floor Control with sidebars 1705 When "A1" wishes to ask a question, he sends a Floor Request message 1706 to the floor control server. Upon receipt of the request, the floor 1707 control server notifies the moderator, "Carol" of the active sidebar 1708 conference, whose serving as the floor chair. Note, that this 1709 signaling flow is not shown in the diagram. Since no other analysts 1710 have yet requested the floor, "Carol" indicates to the floor control 1711 server that "A1" may be granted the floor. 1713 9.6. Whispering or Private Messages 1715 The case of private messages can be handled as a sidebar with just 1716 two participants, similar to the example in section Section 9.4.1, 1717 but rather than using audio within the sidebar, "Alice" could add an 1718 additional text based media stream to the sidebar. The other 1719 context, referred to as whisper, in this document refers to 1720 situations involving one time media targetted to specific user(s). 1721 An example of a whisper would be an announcement injected only to the 1722 conference chair or to a new participant joining a conference. 1724 Figure 15 provides an example of one user "Alice" whose chairing a 1725 fixed length conference with "Bob" and "Carol". The configuration is 1726 such that only the chair is providing a warning when there is only 10 1727 minutes left in the conference. At that time, "Alice" is moved into 1728 a sidebar created by the conferencing system and only "Alice" 1729 receives the announcement. 1731 +--------------------------------+ 1732 | Conferencing System | 1733 | +---------+--+| 1734 | |policies | || 1735 | +---------+ || 1736 | |Active || 1737 | |Conference || 1738 | +-------+ || 1739 | |"Alice"| || 1740 | +-------+ || 1741 | +-----------+ |"Bob" | || 1742 | |Conference | +-------+ || 1743 | |Control |~~~>|"Carol"| || 1744 | |Server | +-------+----+| 1745 | | | | | 1746 | | | | | 1747 | | | V | 1748 | | | +---------+--+| 1749 | | | |policies | || 1750 | | |~~~>+---------+ || 1751 | | | | || 1752 | +-----------+ |Sidebar || 1753 "Alice" | |Conference || 1754 +--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ || 1755 | |<-------------------------|Notification| | | || 1756 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1757 +--------+ confID > || | +-------+----+| 1758 |+------------+ | 1759 ~~~Announcement provided to "Alice"~~~ 1760 | +-----------+ | 1761 | |Conference | | 1762 | |Control | | 1763 | |Server | | 1764 | | | | 1765 | | | \---------+--/| 1766 | | | |\ /|| 1767 | | |~~~>+ \ / || 1768 | | | | \ / || 1769 | +-----------+ |Sid\bar / || 1770 "Alice" | |Conf\re/ce || 1771 +--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ || 1772 | |<-------------------------|Notification|<~~~| /\| || 1773 | Client | activeSideConfObjID,||Service | |"Ali/ce\ || 1774 +--------+ confID > || | +---/---+\---+| 1775 |+------------+ / \ | 1776 +--------------------------------+ 1778 Figure 15: Whisper 1780 When the conferencing system determines that there is only 10 minutes 1781 left in the conference which "Alice" is chairing, rather than 1782 creating a reservation as was done for the sidebar in Section 9.4.1, 1783 the conferencing system directly creates an active sidebar 1784 conference, based on the active conference associated with "Alice". 1785 As discussed previously, the sidebar conference is NOT independent of 1786 the active conference (i.e., parent). The conferencing system also 1787 allocates a conference ID to be used for any subsequent manipulations 1788 of the sidebar conference. The conferencing system maintains the 1789 mapping between this conference ID and the conference object ID 1790 associated with the active sidebar conference through the conference 1791 instance. 1793 Immediately upon creation of the active sidebar conference, the 1794 announcement media is provided to "Alice". Depending upon the 1795 policies, Alice may be notified of her addition to the sidebar via 1796 the conference notification service. "Alice" continues to receive 1797 the media from the main conference. 1799 Upon completion of the announcement, "Alice" is removed from the 1800 siebar and the sidebar conference is deleted. Depending upon the 1801 policies, "Alice" may be notified of her removal from the sidebar via 1802 the conference notification service. 1804 9.7. Conference Announcements and Recordings 1806 Each participant can require a different type of announcement and/or 1807 recording service from the system. For example, "Alice", the 1808 conference chair, could be listening to a roll call while "Bob" may 1809 be using a telephony user interface to create a sidebar. Some 1810 announcements would apply to all the participants such as "This 1811 conference will end in 10 minutes". Recording is often required to 1812 capture the names of participants as they join a conference, 1813 typically after the participant has entered an access code as 1814 discussed in Section 9.8. These recorded names are then announced to 1815 all the participants as the new participant is added to the active 1816 conference. 1818 An example of a conferencing recording and announcement , along with 1819 collecting the DTMF, within the context of this framework, is shown 1820 in Figure 16. 1822 +--------------------------------+ 1823 | Conferencing System | 1824 "Alice" | +-----------+ | 1825 +--------+ | |Conference | | 1826 | |CCP Request < | |Control | | 1827 | Client |--------------------------->| |Server | | 1828 | |Bob's Conference ID, | | | | 1829 +--------+ Join > | | | | 1830 | | | | 1831 | ~ ~ | 1832 ~~~Announcement provided to "Alice"~~~ 1833 ~~~ Digits collected from "Alice"~~~ 1834 | ~ ~ +---------+--+| 1835 | | |~~~>|policies | || 1836 | | | +---------+ || 1837 | | | |Active || 1838 | | | |Conference || 1839 | | | +-------+ || 1840 | | | |"Bob" | || 1841 | | | +-------+ || 1842 | | | |"Carol"| || 1843 | | | +-------+----+| 1844 | ~ ~ | 1845 ~~~Announcement provided to "Alice"~~~ 1846 ~~~ Alice records her name ~~~ 1847 | ~ ~ +---------+--+| 1848 | | | |policies | || 1849 | | | +---------+ || 1850 | | |~~~>|Active || 1851 | +-----------+ |Sidebar || 1852 | |Conference || 1853 | +-------+ || 1854 | |"Bob" | || 1855 "Bob " | +-------+ || 1856 +--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| || 1857 | |<-------------------------|Notification| +-------+ || 1858 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1859 +--------+ confID > || | +-------+----+| 1860 |+------------+ | 1861 ~~~Announcement provided to All Parties~~~ 1862 | | 1863 +--------------------------------+ 1865 Figure 16: Recording and Announcements 1867 Upon receipt of the Conference Control Protocol request from "Alice" 1868 to join "Bob's" conference, the conferencing system maps the 1869 identifier received in the request to the conference object 1870 representing "Bob's" active conference. The conferencing system 1871 determines that a password is required for this specific conference, 1872 thus an announcement asking "Alice" to enter the password is provided 1873 to "Alice". Once "Alice" enters the password, it is validated 1874 against the policies associated with "Bob's" active conference. The 1875 conferencing system then connects to a server which prompts and 1876 records "Alice's" name. The conferencing system must also determine 1877 whether "Alice" is already a user of this conferencing system or 1878 whether she is a new user. 1880 If "Alice" is a new user for this conferencing system, a conference 1881 user identifier is created for "Alice". Based upon the addressing 1882 information provided by "Alice", the call signaling to add "Alice" to 1883 the conference is instigated through the Focus. 1885 Once the call signaling indicates that "Alice" has been successfully 1886 added to the specific conference, per updates to the state, and 1887 depending upon the policies, other participants (e.g., "Bob") are 1888 notified of the addition of "Alice" to the conference via the 1889 conference notification service and an announcement is provided to 1890 all the participants indicating that "Alice" has joined the 1891 conference. 1893 9.8. Monitoring for DTMF 1895 The conferencing system also needs the capability to monitor for DTMF 1896 from each individual participant. This would typically be used to 1897 enter the identifier and/or access code for joining a specific 1898 conference. 1900 An example of DTMF monitoring, within the context of the framework 1901 elements, is shown in Figure 16. 1903 9.9. Observing and Coaching 1905 The capability to observe a conference allows a participant with the 1906 appropriate authority to listen to the conference, typically without 1907 being an active participant and often as a hidden participant. When 1908 such a capability is available on a conferencing system, there is 1909 often an announcement provided to each participant as they join the 1910 conference indicating the call may be monitored. This capability is 1911 useful in the context of conferences which might be experiencing 1912 technical difficulties, thus allowing a technician to listen in to 1913 evaluate the type of problem. 1915 This capability could also apply to call center applications as it 1916 provides a mechanism for a supervisor to observe how the agent is 1917 handling a particular call with a customer. This scenario can be 1918 handled by by supervisor adding themselves to the existing active 1919 conference, with a listen only audio media path. Whether the agent 1920 is aware of when the supervisor joins the call should be 1921 configurable. 1923 Taking the supervisor capability one step further introduces a 1924 scenario whereby the agent can hear the supervisor, as well as the 1925 customer. The customer can still only hear the agent. This scenario 1926 would involve the creation of a sidebar involving the agent and the 1927 supervisor. Both the agent and supervisor receive the audio from the 1928 main conference. When the agent speaks, it is heard by the customer 1929 in the main conference. When the supervisor speaks, it is heard only 1930 by the agent in the sidebar conference. 1932 An example of observing and coachin is shown in figure Figure 17. In 1933 this example, call center agent "Bob" is involved in a conference 1934 with customer "Carol". Since "Bob" is a new agent and "Alice" sees 1935 that he has been on the call with "Carol" for longer than normal, she 1936 decides to observe the call and coach "Bob" as necessary. 1938 +--------------------------------+ 1939 | Conferencing System | 1940 | +---------+--+| 1941 | |policies | || 1942 | +---------+ || 1943 | |Active || 1944 | |Conference || 1945 "Alice" | | || 1946 +--------+ | | || 1947 | |CCP Req |Conference | +-------+ || 1950 | | confUserID> | |Control |~~~>|"Carol"| || 1951 | |<--------------------------|Server | +-------+----+| 1952 | |CCP Response | | | | | 1953 +--------+ | | | V | 1955 | | | +---------+--+| 1956 | | | |policies | || 1957 | | |~~~>+---------+ || 1958 | | | | || 1959 | +-----------+ | || 1960 "Alice" | | Sidebar || 1961 +--------+ | | Reservation|| 1962 | |CCP Request | |~~~>| || 1965 | | confID,confUserID> | | | +------------+| 1966 | | | | | | | 1967 | | | |Conference | | | 1968 | | | |Control | V | 1969 | | | |Server | +---------+--+| 1970 | |CCP Response | | | |policies | || 1971 | | | | | |Sidebar || 1974 | | | |Conference || 1975 | +-----------+ +-------+ || 1976 | |"Alice"| || 1977 "Bob" | | | || 1978 +--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ || 1979 | |<-------------------------|Notification|<~~~| | || 1980 | Client | "chair"="Alice" ||Service | |"Bob" | || 1981 +--------+ || | +-------+----+| 1982 |+------------+ | 1983 +--------------------------------+ 1985 Figure 17: Supervisor Creating a Sidebar for Observing/Coaching 1987 Upon receipt of the Conference Control Protocol request from "Alice" 1988 to "reserve" a new sidebar conference, based upon the active 1989 conference received in the request, the conferencing system uses the 1990 received active conference to clone a conference reservation for the 1991 sidebar. The conferencing system also reserves or allocates a 1992 conference ID to be used for any subsequent protocol requests from 1993 any of the members of the conference. The conferencing system 1994 maintains the mapping between this conference ID and the conference 1995 object ID associated with the sidebar reservation through the 1996 conference instance. 1998 Upon receipt of the conference control protocol response to reserve 1999 the conference, "Alice" can now create an active conference using 2000 that reservation or create additional reservations based upon the 2001 existing reservations. In this example, "Alice" wants only "Bob" to 2002 be involved in the sidebar, thus she manipulates the membership. 2003 "Alice" also wants the audio to be received by herself and "Bob" from 2004 the original conference, but wants any outgoing audio from herself to 2005 be restricted to the participants in the sidebar, whereas "Bob's" 2006 outgoing audio should go to the main conference, so that both "Alice" 2007 and the customer "Carol" hear the same audio from "Bob". "Alice" 2008 sends a conference control protocol request to update the information 2009 in the reservation and to create an active conference. 2011 Upon receipt of the conference control protocol request to update the 2012 reservation and to create an active conference for the sidebar, as 2013 identified by the conference object ID, the conferencing system 2014 ensures that "Alice" has the appropriate authority based on the 2015 policies associated with that specific conference object to perform 2016 the operation. Based upon the addressing information provided for 2017 "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with 2018 the appropriate media characteristics is instigated through the 2019 Focus. 2021 "Bob" is notified of his addition to the sidebar via the conference 2022 notification service, thus he is aware that "Alice" the supervisor is 2023 available for coaching him through this call. 2025 10. Relationships between SIPPING and Centralized Conferencing 2026 Frameworks 2028 The SIPPING Conferencing Framework [9] provides an overview of a wide 2029 range of centralized conferencing solutions known today in the 2030 conferencing industry. The document introduces a terminology and 2031 logical entities in order to systemize the overview and to show the 2032 common core of many of these systems. The logical entities and the 2033 listed scenarios in the SIPPING Conferencing Framework are being used 2034 to illustrate how SIP [3] can be used as a signaling means in these 2035 conferencing systems. SIPPING Conferencing Framework does not define 2036 new conference control protocols to be used by the general 2037 conferencing system. It uses only basic SIP [3], the SIP 2038 Conferencing for User Agents [13], and the SIPPING Conference Package 2039 [10] for basic SIP conferencing realization. 2041 This centralized conferencing framework document defines a particular 2042 centralized conferencing system and the logical entities implementing 2043 it. It also defines a particular data model and refers to the set of 2044 protocols (beyond call signaling means) being defined by the XCON WG 2045 to be used among the logical entities for implementing advanced 2046 conferencing features. The purpose of the XCON working group and 2047 this framework is to achieve interoperability between the logical 2048 entities from different vendors for controlling different aspects of 2049 advanced conferencing applications. 2051 The logical entities defined in the two frameworks are not intended 2052 to be mapped one-to-one. The two frameworks differ in the 2053 interpretation of the internal conferencing system decomposition and 2054 the corresponding operations. Nevertheless, the basic SIP [3], the 2055 SIP Conferencing for User Agents [13], and the SIPPING Conference 2056 Package [10] are fully compatible with both Framework documents. 2058 11. Security Considerations 2060 There are a wide variety of potential attacks related to 2061 conferencing, due to the natural involvement of multiple endpoints 2062 and the many, often user-invoked, capabilities provided by the 2063 conferencing system. Examples of attacks include the following: an 2064 endpoint attempting to listen to conferences in which it is not 2065 authorized to participate, an endpoint attempting to disconnect or 2066 mute other users, and theft of service, by an endpoint, in attempting 2067 to create conferences it is not allowed to create. 2069 There are several issues surrounding security of this conferencing 2070 framework. One set of issues involves securing the actual protocols 2071 and the associated authorization mechanisms. This first set of 2072 issues should be addressed in the specifications specific to the 2073 protocols described in Section 8. The protocols used for 2074 manipulation and retrieval of confidential information MUST support a 2075 confidentiality and integrity mechanism. Similar requirements apply 2076 for the floor control protocols. Section 11.3 discusses an approach 2077 for client authentication of a floor control server. 2079 There are also security issues associated with the authorization to 2080 perform actions on the conferencing system to invoke specific 2081 capabilities. Section 5.2 discusses the policies associated with the 2082 conference object to ensure that only authorized entities are able to 2083 manipulate the data to access the capabilities. The final set of 2084 issues involves the privacy and security of the identity of a user in 2085 the conference, which is discussed in Section 11.2 2087 11.1. Authorization 2089 Many policy authorization decisions are based on the identity of the 2090 user or the role that a user may have. There are several ways that a 2091 user might authenticate its identity to the system. The conferencing 2092 system may know about specific users and assign passwords to the 2093 users. The users may also be authenticated by knowing a particular 2094 conference ID and a PIN for it. Sometimes, a PIN is not required and 2095 the conference ID is used as a shared secret. The call signaling 2096 means can provide a trusted form of the user identity or it might 2097 just provide a hint of the possible identity and the user still needs 2098 to provide some authentication to prove it has the identity that was 2099 provided as a hint in the call signaling. This may be in the form of 2100 an IVR system or other means. The goal for the conferencing system 2101 is to figure out a user identity and a role for any attempt to send a 2102 request to the conferencing system. 2104 When a conferencing system presents the identity of authorized users, 2105 it may choose to provide information about the way the identity was 2106 proven or verified by the system. A user may also come as a 2107 completely unauthenticated user into the system - this fact needs 2108 also be communicated to interested parties. 2110 When guest users interact with the system, it is often in the context 2111 of a particular conference. In this case, the user may provide a PIN 2112 or a password that is specific to the conferences and authenticates 2113 the user to take on a certain role in that conference. The guest 2114 user can then perform actions that are allowed to any user with that 2115 role. 2117 The term password is used to mean the usual, that is to say a 2118 reasonable sized, in number of bits, hard to predict shared secret. 2119 Today users often have passwords with more than 30 bits of randomness 2120 in them. PIN is a special password case - a shared secret that is 2121 only numeric and often contains a fairly small number of bits (often 2122 as few as 10 bits). When conferencing systems are used for audio on 2123 the PSTN, there is often a need to authenticate using a PIN. 2124 Typically if the user fails to provide the correct PIN a few times in 2125 a row, the PSTN call is disconnected. The rate of making the calls 2126 and getting to the point to enter a PIN makes it fairly hard to do an 2127 exhaustive search of the PIN space even for 4 digit PINs. When using 2128 a high speed interface to connect to a conferencing system, it is 2129 often possible to do thousands of attempts per second and the PIN 2130 space could quickly be searched. Because of this, it is not 2131 appropriate to use PINs for authorization on any of the interfaces 2132 that provide fast queries or many simultaneous queries. 2134 11.2. Security and Privacy of Identity 2136 This conferencing system has an idea of the identity of a user but 2137 this does not mean it can reveal this identity to other users, due to 2138 privacy considerations. Users can select various options for 2139 revealing their identity to other users. A user can be "hidden" such 2140 that other users can not see they are participants in the conference, 2141 or they can be "anonymous" such that users can see that another user 2142 is there, but not see the identity of the user, or they can be 2143 "public" where other users can see their identity. If there are 2144 multiple "anonymous" users, other parties will be able to see them as 2145 independent "anonymous" parties and will be able to tell how many 2146 "anonymous" parties are in the conference. Note, that the visibility 2147 to other participants is dependent on their roles. For example, 2148 users' visibility (including "anonymous" and "hidden") may be 2149 displayed to the moderator or administrator, subject to a 2150 conferencing system's local policies. "Hidden" status is often used 2151 by automated or machine participants of a conference (e.g., call 2152 recording) and is also used in many call center situations. 2154 11.3. Floor Control Server Authentication 2156 Clients can authenticate a floor control server using the TLS 2157 certificates. Requests submitted on a successfully created 2158 connection between the client and floor control server may 2159 additionally require digest authentication within the BFCP protocol 2160 to authenticate the floor control client to the server. For this to 2161 take place, a shared secret needs to be exchanged between the floor 2162 control client/server entities. This can be achieved out of band 2163 using a mechanism such as the 'k=' SDP attribute. The shared secret 2164 can also be exchanged using un-specified 'out of band' mechanisms. 2165 When using Digest authentication of floor control client messages the 2166 exchange of an active 'Nonce' is also required. This can be achieved 2167 using a BFCP request response interaction as defined in BFCP (A 2168 request is submitted without a Nonce TLV and the server generates an 2169 error response with either an Error Code 7 (DIGEST TLV Required) or 6 2170 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 2171 can also be obtained 'out of band' using information provided in the 2172 offer/answer exchange. As with the other SDP Floor attributes 2173 referenced in this section and defined in [16], the 'nonce' attribute 2174 can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. 2176 12. IANA Considerations 2178 This is an informational draft, with no IANA considerations required. 2180 13. Acknowledgements 2182 This document is a result of architectural discussions among IETF 2183 XCON working group participants. The authors would like to thank 2184 Henning Schulzrinne for the "Conference Object Tree" proposal and 2185 general feedback, Cullen Jennings for providing input for the 2186 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 2187 Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan 2188 Mahy, Brian Rosen and Pierre Tane for their reviews and constructive 2189 input. 2191 14. Changes since last Version 2193 NOTE TO THE RFC-Editor: Please remove this section prior to 2194 publication as an RFC. 2196 Changes from WG 05 to 06: 2198 1) Section 9.4.2: Added a statement that whether the hold state is 2199 visible to other participants is subject to user and local policy. 2201 2) Fixed Editorial nits including updating references to published 2202 RFC numbers, adding references for userid and uri definitions, 2203 removing unused references, fixing names in detailed scenarios 2204 (section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as 2205 moderator), aligning with data model (section 9.5: "allowed to join" 2206 list -> "allowed-users-list") and miscellaneous typos. 2208 Changes from WG 04 to 05: 2210 1) Removed all references to "Conference Template": 2212 Section 4: 2214 - Updated "Common Conference Information" definition, merging details 2215 from "Conference Template" definition, which was removed. 2217 - In definition of "conference blueprint" 2219 - In definition of "conference object" 2221 - Removed definition of "Registered conference document" 2222 Section 5: 2224 - 1st paragraph. Reworded. 2226 - Figure2: added "boxes" for all the data listed in the Conference 2227 Template type in the diagram. 2229 - Paragraph following Figure 2. Reworded. 2231 Section 5.1/5.2: Merged 5.2 into section 5.1 and reworded 2232 appropriately. 2234 Section 7.1: Second paragraph, 3rd sentence. 2236 Section 7.3: 2238 - Second paragraph, 2nd and 3rd sentences. Deleted. Remaining 2239 sentence merged with 1st paragraph 2241 - Third paragraph. Deleted. 2243 Section 8.4, 1st paragraph. Removed Editor's note containing 2244 reference to alternative proposal for floor control using templates. 2246 Section 9.3, 1st paragraph after Figure 10. 2248 2) Section 4: 2250 - Sidebar. Clarified definition. 2252 - Whisper. Added definition. 2254 3) Section 5, last paragraph, added reference to 2255 draft-ietf-xcon-common-data-model. 2257 4) Section 8.3. Deleted Editor's note. Deleted subsections 2258 containing details of separate protocol proposals. 2260 5) Section 9.4. Sidebar. Added another example - an external 2261 sidebar (i.e. one involving a participant not in the main conference 2262 and with no media from the main conference). 2264 6) New section 9.5. Floor control with sidebars. 2266 7) Section 9.5 (new 9.6) Whisper. Added more detail and an example 2267 diagram. 2269 8) Section 9.8. (new 9.9) Observing a Conference. Added more details 2270 to example, including concept of coaching and added a corresponding 2271 diagram. 2273 9) Removed Appendix A and Appendix B and updated references to these. 2274 The content will be in separate documents (references TBD). 2276 10) Updated references. Changed drafts to RFCs as appropriate and 2277 removed unused references. 2279 Changes from WG 03 to 04: 2281 - Editorial nits and clarifications. 2283 - Section 4. Template: Removed reference to "user interface 2284 abstractions". 2286 - Section 5.2. Conference Template: deleted references to user 2287 interface abstraction (1st paragraph, last phrase and 4th paragraph). 2289 - Section 9.6. Conference Announcements and Recording: text 2290 expanded. Moved discussion of DTMF to a new section. 2292 - Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), 2293 with some initial text. 2295 Changes from WG 02 to 03: 2297 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 2299 - Added definition for Sidebar. 2301 - Section 5.2 Added text indicating that adding new elements or 2302 modifying elements requires the definition of a new template. (per 2303 DP4.2 conclusion). 2305 - Section 7.3. Added text reiterating that the blueprint comprises 2306 both the common conference information and a template (per DP4/4.1 2307 discussions. 2309 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 2310 blueprint is common conference information + one template and that 2311 multiple templates is FFS. 2313 - Section 8.3 - Updated Conference Control Protocol section to 2314 include the protocols on the table for WG discussion as of 31 Dec 2315 2005 deadline. 2317 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 2318 - Section 9.5 - Whisper - Added some text, reflecting past WG 2319 discussions. Basic definition and further details/example still 2320 needed. 2322 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 2323 Further details/example still needed. 2325 Changes from WG 01 to 02: 2327 - Editorial nits -i.e. consistent terminology, capatilization, etc. 2329 - Revamped abstract and introduction 2331 - Global removal of XCON as a qualifier (we had previously done this 2332 in a previous version with all the identifiers). 2334 - Global change of "call control signalling" to "call signaling" 2336 - Moved the terminology section after the Overview section: 2338 - - Modified the definitions to be more concise and per some of 2339 Henning's recommendations. 2341 - - Added definitions for blueprint and conference reservation. 2343 - Clarified the definition of policy and added more explicit text as 2344 to how policy is accomplished via the data model and system 2345 realization (section 4.3 and 6.1) 2347 - Removed the Editor's note/text in section 4 about the options for 2348 the schema; added a reference to a TBD schema document. 2350 - Section 5: 2352 - - clarified the identifiers. Kept the logical definition as 2353 "identifiers", although most will be realized as URIs. 2355 - - deleted the section on conference instance. 2357 - - removed the term "umbrella" from sections conference User and 2358 conference object identifier sections 2360 - - moved alot of detail from Conference User Identifier and 2361 conference Object Identifier sections into appendices, and added 2362 additional detail, that will become the basis for separate documents. 2364 - In section 6: 2366 - - added a bit of explanation as to the intent of the cloning tree 2367 model - it's not implementation binding, but rather to illustrate the 2368 data model and context for the protocol interactions. 2370 - - removed the term copying altogether. Cloning is the model and 2371 the idea is that the cloned object contains data indentical to the 2372 parent when it was created (whether it gets "copied" or whatever from 2373 the parent is an implementation issue). 2375 - - introduce the blueprint concept in section 6.1 prior to its 2376 implied usage in 6.2 and 6.3. 2378 - - removed the usage of the term occurrence (which is just a child 2379 reservation). 2381 - Removed security related details from Floor Control section and 2382 moved those to the security section. As a result removed most of the 2383 editorial notes from the front of the Floor control section and 2384 integrated the remaining ones inline into that section, where the 2385 resolution should be documented. 2387 - Section 8: 2389 - - Added new example 8.1 - conference creation 2391 - - Added a placeholder for a more detailed example to the sidebar 2392 section to show a sidebar which has some media specifically 2393 associated with the sidebar (i.e. audio), yet still use the main 2394 conference for other media (visual presentation). 2396 - Section 11: As a result of adding additional information to the 2397 security section, divided this section into subsections for clarity. 2399 Changes from WG 00 to 01:: 2401 - Section 2 (Conventions and Terminology). Slight modifications to 2402 definitions of Call (control) signaling, Conference Identifer, 2403 Conference Instance, Conference Object. 2405 - Section 2 (Conventions and Terminology).Renaming of term 2406 "Registered Template Definition" to "Registered Conference Document" 2407 (per agreement at interim meeting). 2409 - Section 3 (Next to the last paragraph on the media model). 2410 Clarified the text such that it doesn't read that the focus performs 2411 media mixing. Changed "focus" to "media mixer controlled by the 2412 focus" in the 2nd sentence and "performed" to "controlled" in the 2413 4th. 2415 - Section 5. Rearranged the sub-sections a bit for better flow. 2416 First describe the Conference ID, then the Conference Instance, 2417 followed by the Conference Object, with the Conference Object 2418 Identifer described in a subsection of the Conference Object section. 2419 Added a diagram showing the relationship between Conference 2420 Identifer/Focus and Conference Object Identifier, within the context 2421 of a Conference Instance to the Conference Object section. 2423 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 2424 apply to independent objects (and non-independent). 2426 - Section 6.3 (Advanced Example). Added additional text with regards 2427 to future conferences, introducing the concept of infinite series 2428 (which would be limited by calendaring interface). 2430 - Section 7.3 (Conference Control Protocol). Updated to include 2431 reference to SOAP option. 2433 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 2434 about the XCON FW constructs used. 2436 Changes from individual 02 to WG 00: 2438 - few minor editorial changes 2440 - Section 2. Removed second sentence of definition of Conference ID, 2441 as that's now included/described in context in new Identifier 2442 section. 2444 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 2445 Protocol" (per Keith's comment to be more explicit). 2447 - Section 4.1. Identifiers. Moved this to a new section ( 2448 Section 6). 2450 - New section for Identifiers ( Section 6), thus all section 2451 references beyond 4 are incremented in the new version. 2453 - Section 4. Since section 4.1 was removed, section 4.2 became the 2454 body text for section 4. 2456 - Section 4.2. Added "Floor Information" to Figure 2 as part of 2457 Common Conference Information, also added "Floor Control" to 2458 Conference Template (per text and Cullen's draft). 2460 - Section 4.5. Conference policies. Reworded to not introduce new 2461 terms, but use the general terms identified in the 1st paragraph. 2463 - Section 5.2. Removed "Instance" from "Active Conference Instance" 2464 in Figure 4. 2466 - Section 5.3. Added text clarifying that templates are retrieved 2467 from server (not central repository) (per DP3 conclusion). 2469 - Section 5.4. Added text that there is a single time and that the 2470 times are all relative the one time (per DP1 conclusion). 2472 - Section 5.4. Added text clarifying that changes to a series impact 2473 "all future occurrences (per DP1 discussion/conclusion). 2475 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 2476 as the CCP. 2478 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 2479 Condensed the text only slightly, but added explicit references to 2480 new identifier section. 2482 - Section 6.4.1 Moved to new Identifier section ( Section 6) 2484 - Section 7.1 - moved example to 7.2. Included a new (more 2485 appropriate example) in 7.1, although this may be too basic. 2487 - Section 7.3 - added some proposed text for Sidebars. 2489 15. References 2491 15.1. Normative References 2493 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2494 Levels", BCP 14, RFC 2119, March 1997. 2496 15.2. Informative References 2498 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2499 Protocol", RFC 2327, April 1998. 2501 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2502 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2503 Session Initiation Protocol", RFC 3261, June 2002. 2505 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2506 Session Description Protocol (SDP)", RFC 3264, June 2002. 2508 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2509 Notification", RFC 3265, June 2002. 2511 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2512 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2513 RFC 3550, July 2003. 2515 [7] Dawson, F. and Stenerson, D., "Internet Calendaring and 2516 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2517 November 1998. 2519 [8] Levin, O. and R. Even, "High-Level Requirements for Tightly 2520 Coupled SIP Conferencing", RFC 4245, November 2005. 2522 [9] Rosenberg, J., "A Framework for Conferencing with the Session 2523 Initiation Protocol (SIP)", RFC 4353, February 2006. 2525 [10] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2526 Initiation Protocol (SIP) Event Package for Conference State", 2527 RFC 4575, August 2006. 2529 [11] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 2530 "Requirements for Floor Control Protocols", RFC 4376, 2531 February 2006. 2533 [12] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, 2534 August 2006. 2536 [13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2537 Call Control - Conferencing for User Agents", BCP 119, 2538 RFC 4579, August 2006. 2540 [14] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 2541 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 2543 [15] Levin, O. and G. Camarillo, "The Session Description Protocol 2544 (SDP) Label Attribute", RFC 4574, August 2006. 2546 [16] Camarillo, G., "Session Description Protocol (SDP) Format for 2547 Binary Floor Control Protocol (BFCP) Streams", 2548 draft-ietf-mmusic-sdp-bfcp-03 (work in progress), 2549 December 2005. 2551 [17] Novo, O., "A Common Conference Information Data Model for 2552 Centralized Conferencing (XCON)", 2553 draft-ietf-xcon-common-data-model-03 (work in progress), 2554 October 2006. 2556 [18] Campbell, B., "The Message Session Relay Protocol", 2557 draft-ietf-simple-message-sessions-16 (work in progress), 2558 October 2006. 2560 [19] Boulton, C. and M. Barnes, "A Universal Resource Identifier 2561 (URI) for Centralized Conferencing (XCON)", 2562 draft-boulton-xcon-uri-00 (work in progress), October 2006. 2564 [20] Boulton, C. and M. Barnes, "A User Identifier for Centralized 2565 Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in 2566 progress), October 2006. 2568 Authors' Addresses 2570 Mary Barnes 2571 Nortel 2572 2201 Lakeside Blvd 2573 Richardson, TX 2575 Email: mary.barnes@nortel.com 2577 Chris Boulton 2578 Ubiquity Software Corporation 2579 Building 3 2580 Wern Fawr Lane 2581 St Mellons 2582 Cardiff, South Wales CF3 5EA 2584 Email: cboulton@ubiquitysoftware.com 2586 Orit Levin 2587 Microsoft Corporation 2588 One Microsoft Way 2589 Redmond, WA 98052 2591 Email: oritl@microsoft.com 2593 Full Copyright Statement 2595 Copyright (C) The Internet Society (2006). 2597 This document is subject to the rights, licenses and restrictions 2598 contained in BCP 78, and except as set forth therein, the authors 2599 retain all their rights. 2601 This document and the information contained herein are provided on an 2602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2604 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2605 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2606 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2609 Intellectual Property 2611 The IETF takes no position regarding the validity or scope of any 2612 Intellectual Property Rights or other rights that might be claimed to 2613 pertain to the implementation or use of the technology described in 2614 this document or the extent to which any license under such rights 2615 might or might not be available; nor does it represent that it has 2616 made any independent effort to identify any such rights. Information 2617 on the procedures with respect to rights in RFC documents can be 2618 found in BCP 78 and BCP 79. 2620 Copies of IPR disclosures made to the IETF Secretariat and any 2621 assurances of licenses to be made available, or the result of an 2622 attempt made to obtain a general license or permission for the use of 2623 such proprietary rights by implementers or users of this 2624 specification can be obtained from the IETF on-line IPR repository at 2625 http://www.ietf.org/ipr. 2627 The IETF invites any interested party to bring to its attention any 2628 copyrights, patents or patent applications, or other proprietary 2629 rights that may cover technology that may be required to implement 2630 this standard. Please address the information to the IETF at 2631 ietf-ipr@ietf.org. 2633 Acknowledgment 2635 Funding for the RFC Editor function is provided by the IETF 2636 Administrative Support Activity (IASA).