idnits 2.17.1 draft-ietf-xcon-framework-05.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 2593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2617. ** 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 (September 11, 2006) is 6437 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2498, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2512, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '8') (Obsoleted by RFC 5545) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-02 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-15 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 11 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: March 15, 2007 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 September 11, 2006 10 A Framework and Data Model for Centralized Conferencing 11 draft-ietf-xcon-framework-05 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 March 15, 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 . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . 59 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 [14] 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 [9]. These requirements are applicable for conferencing systems 163 using various call signaling protocols, including SIP. Additional 164 conferencing requirements are provided in [12], and [13]. 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[7]) or Message Session Relay Protocol 360 (defined in [19]). 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 [18]. 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 [11]. 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 [11]. The data model defined 462 in [18] would be the basis for conferencing systems supporting 463 enhanced conferencing features. The additional information defined 464 in [18] 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 [18] 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 to 494 join" list of participants is consulted to decide who is allowed to 495 join. The entries in the list can specify the identity of an 496 individual user (joe@example.com), a role, a domain (*@example.com), 497 etc. For further details, refer to the detailed data model [18]. 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 [14]. 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 [ref 599 conf-uri: TBD]. 601 6.3. Conference User Identifier 603 Each user within a conferencing system is allocated a unique 604 conference user identifier. The user identifier is used in 605 association with the conference object identifier to uniquely 606 identify a user within the scope of conferencing system. There is 607 also a requirement for identifying conferencing system users who may 608 not be participating in a conference instance. Examples of these 609 users would be a non participating 'Floor Control Chair' or 'Media 610 Policy Controller'. The conference user identifier is required in 611 conference control protocol requests to uniquely determine who is 612 issuing commands, so that appropriate policies can be applied to the 613 requested command. The conference user identifer is logically 614 associated with the other user identifiers assigned to the 615 conferencing client for other protocol interfaces, such as an 616 authenticated SIP user. A full description and semantics of the 617 conference user identifier is provided in [ref conf-userid: TBD]. 619 7. Conferencing System Realization 621 Implementations based on this centralized conferencing framework can 622 range from systems supporting ad-hoc conferences, with default 623 behavior only, to sophisticated systems with the ability to schedule 624 recurring conferences, each with distinct characteristics, being 625 integrated with external resource reservation tools, and providing 626 snapshots of the conference information at any of the stages of the 627 conference life-cycle. 629 A conference object is the logical representation of a conference 630 instance at a certain stage, such as capabilities description upon 631 conference creation, reservation, activation, etc., which a 632 conferencing system maintains in order to describe the system 633 capabilities and to provide access to the available services provided 634 by the conferencing system. Consequently, this centralized 635 conferencing framework does not mandate the actual usage of the 636 conference object, but rather defines the general cloning tree 637 concept and the mechanisms required for its realization, as described 638 in detail in Section 7.1. 640 Adhoc and advanced conferencing examples are provided in Section 7.2 641 and Section 7.3, with the latter providing additional description of 642 the Conference Object in terms of the stages of a conference, to 643 support scheduled and other advanced conference capabilities. The 644 scheduling of a conference based on these concepts and mechanisms is 645 then detailed in Section 7.4 647 As discussed in Section 5.2, there are conference policies implicit 648 in and derivable from the data in the conference objects and there 649 are also policies applying to the conference objects as a whole. In 650 the examples in this section, these latter policies are shown 651 logically associated with the conference objects, however, it is an 652 implementation specific mechansim as to how these policies are 653 managed and applied to the conference objects. 655 7.1. Cloning Tree 657 The concept defined in this section is a logical representation only, 658 as it is reflected through the centralized conferencing mechanisms: 659 the URIs and the protocols. Of course, the actual system realization 660 can differ from the presented model. The intent is to illustrate the 661 role of the logical elements in providing an interface to the data, 662 based on conferencing system and conferencing client actions, and 663 describe the resultant protocol implications 665 Any conference object in a conferencing system is created by either 666 being explicitly cloned from an existing parent object or being 667 implicitly cloned from a default system conference blueprint. A 668 conference blueprint is a static conference object used to describe a 669 typical conference setting supported by the system. Each system can 670 maintain multiple blueprints, typically each describing a different 671 conferencing type using the common conference information format. 672 This document uses the "cloning" metaphor instead of the 673 "inheritance" metaphor because it more closely fits the idea of 674 object replication, rather than a data type re-usage and extension 675 concept. 677 The cloning operation needs to specify whether the link between the 678 parent and the child needs to be maintained in the system or not. If 679 no link between the parent and the child exists, the objects become 680 independent and are not impacted by any operations on the parent 681 object nor subject to any limitations of the parent object. 683 Once the new object is created, it can be addressed by a unique 684 conference object URI assigned by the system, as described in [ref 685 conf-uri:TBD]. By default, the newly created object contains all the 686 data existing in the parent object. The newly created object can 687 expand the data it contains, within the schema types supported by the 688 parent. It can also restrict the read/write access to its objects. 689 However, unless the object is independent, it cannot modify the 690 access restrictions imposed by the parent object. 692 Any piece of data in the child object can be independently accessed 693 and, by default, can be independently modified without affecting the 694 parent data. 696 Unless the object is independent, the parent object can enforce a 697 different policy by marking certain data elements as "parent 698 enforceable". The values of these data elements can not be changed 699 by directly accessing the child object; neither can they be expanded 700 in the child object alone. 702 Figure 4 illustrates an example of a conference (Parent B), which is 703 created independent of its Parent (Parent A). Parent B creates two 704 child objects, Child 1 and Child 2. Any of the data elements of 705 Parent B can be modified (i.e. there are no "parent enforceable" data 706 elements) and depending upon the element, the changes will be 707 reflected in Child 1 and Child 2 , whereas changes to Parent A will 708 not impact the data elements of Parent B. Any "parent enforceable" 709 data elements as defined by Parent B cannot be modified in the child 710 objects. 712 +---+-----------------------+ 713 | p | | 714 | o | P A R E N T A | 715 | l | | 716 | i | C O N F E R E N C E | 717 | c | | 718 | i | O B J E C T | 719 | e | | 720 +-s-+-----------------------+ 721 | 722 \| / 723 \/ INDEPENDENT 724 /\ 725 /| \ 726 V 727 +---+-----------------------+ 728 | p | | 729 | o | P A R E N T B | 730 | l | | 731 | i | C O N F E R E N C E | 732 | c | | 733 | i | O B J E C T | 734 | e | | 735 +-s-+-----------------------+ 736 | | 737 | | 738 | --------------------------- 739 | | 740 V V 741 +---+-----------------------+ +---+-----------------------+ 742 | p | | | p | | 743 | o | C H I L D 1 | | o | C H I L D 2 | 744 | i | | | l | | 745 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 746 | i | | | c | | 747 | c | O B J E C T | | i | O B J E C T | 748 | i | | | e | | 749 +-s-+-----------------------+ +-s-+-----------------------+ 751 Figure 4: The Cloning Tree. 753 Using the defined cloning model and its tools, the following sections 754 show examples of how different systems based on this framework can be 755 realized. 757 7.2. Ad-hoc Example 759 Figure 5 illustrates how an ad-hoc conference can be created and 760 managed in a conferencing system. A client can create a conference 761 by establishing a call signaling channel with a conference factory as 762 specified in Section 6.1. The conference factory can internally 763 select one of the system supported conference blueprints based on the 764 requesting client privileges and the media lines included in the SDP 765 body. 767 The selected blueprint with its default values is copied by the 768 server into a newly created conference object, referred to as an 769 'Active Conference'. At this point the conference object becomes 770 independent from its blueprint. A new conference object identifier, 771 a new conference identifier and a new focus are allocated by the 772 server. 774 During the conference lifetime, an authorized client can manipulate 775 the conference object, such as adding participants, using the 776 Conference Control Protocol [Section 8.3]. 778 +---+-----------------------+ 779 | p | | 780 | o | System Default | 781 | l | | 782 | i | Conference | 783 | c | | 784 | i | Blueprint | 785 | e | | 786 +-s-+-----------------------+ 787 | 788 \| / 789 \/ 790 /\ 791 /| \ 792 V 793 +---+-----------------------+ 794 | p | | 795 | o | Active | 796 | l | | 797 | i | Conference | 798 | c | | 799 | i | | 800 | e | | 801 +-s-+-----------------------+ 802 Figure 5: Conference Ad-hoc Creation and Lifetime. 804 7.3. Advanced Example 806 Figure 6 illustrates how a recurring conference can be specified 807 according to system capabilities, scheduled, reserved, and managed in 808 a conferencing system. A client would first query a conferencing 809 system for its capabilities. This can be done by requesting a list 810 of the conference blueprints the system supports. Each blueprint 811 contains a specific combination of capabilities and limitations of 812 the conference server in terms of supported media types (e.g., audio, 813 video, text, or combinations of these), participant roles, maximum 814 number of participants of each role, availability of floor control, 815 controls available for participants, availability and type of 816 sidebars, the definitions and names of media streams, etc. 818 The selected blueprint with its default values is cloned by the 819 client into a newly created conference object, referred to as a 820 conference reservation, that specifies the resources needed from the 821 system for this conference instance. At this point the conference 822 reservation becomes independent from its blueprint. The client can 823 also change the default values, within the system ranges, and add 824 additional information, such as the list of participants and the 825 conference start time, to the conference reservation. 827 At this point the client can ask the conference server to create new 828 conference reservations by attaching the conference reservation to 829 the request. As a result, the server can allocate the needed 830 resources, create the additional conference objects for the child 831 conference reservations and allocate the conference object 832 identifiers for all - the original conference reservation and for 833 each child conference reservation. 835 From this point on, any authorized client is able to access and 836 modify each of the conference objects independently. By default, 837 changes to an individual child conference reservation will affect 838 neither the parent conference reservation, from which it was created, 839 nor its siblings. 841 On the other hand, some of the conference sub-objects, such as the 842 maximum number of participants and the participants list, can be 843 defined by the system as parent enforceable. As a result, these 844 objects can be modified by accessing the parent conference 845 reservation only. The changes to these objects can be applied 846 automatically to each of the child reservations, subject to local 847 policy. 849 +---+-----------------------+ 850 | p | | 851 | o | Selected | 852 | l | | 853 | i | Conference | 854 | c | | 855 | i | Blueprint | 856 | e | | 857 +-s-+-----------------------+ 858 | 859 \| / 860 \/ 861 /\ 862 /| \ 863 V 864 +---+-----------------------+ 865 | p | | 866 | o | Conference | 867 | l | | 868 | i | Reservation | 869 | c | | 870 | i | | 871 | e | | 872 +-s-+-----------------------+ 873 | | | 874 | | | 875 | | | 876 | | | 877 +---|--|--V-----------------+ 878 +-+---|--V------------------+ | 879 +-+-+---V-------------------+ | | 880 | p | | | | 881 | o | Child Conference | | | 882 | l | | | | 883 | i | Reservation | | | 884 | c | | | | 885 | i | | |-+ 886 | e | |-+ 887 +-s-+-----------------------+ 889 Figure 6: Advanced Conference Definition, Creation, and Lifetime. 891 When the time comes to schedule the conference reservation, either 892 via the system determination that the 'start' time has been reached 893 or via client invocation, an active conference is cloned based on the 894 conference reservation. As in the adhoc example, the active 895 conference is independent from the parent and changes to the 896 conference reservation will not impact the active conference. Any 897 desired changes must be targeted towards the active conference. An 898 example of this interaction is shown in Section 9.1 900 7.4. Scheduling a conference 902 The capability to schedule conferences forms an important part of the 903 conferencing system solution. An individual conference reservation 904 typically has a specified 'start' and 'end' time, with the times 905 being specified relative to a single specified 'fixed' time (e.g., 906 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 907 considerations. In most advanced conferencing solutions it is 908 possible to not only schedule an individual occurrence of a 909 conference reservation, but also schedule a series of related 910 conferences (e.g., a weekly meeting that starts on Thursday at 09.00 911 GMT). 913 To be able to achieve such functionality, a conferencing system needs 914 to be able to appropriately schedule and maintain conference 915 reservations that form part of a recurring conference. The mechanism 916 proposed in this document makes use of the 'Internet Calendaring and 917 Scheduling Core Object' specification defined in RFC2445[8] in union 918 with the concepts introduced in Section 5 for the purpose of 919 achieving advanced conference scheduling capability. 921 Figure 7 illustrates a simplified view of a client interacting with a 922 conferencing system. The client is using the Conference Control 923 Protocol (Section 8.3) to add a new conference reservation to the 924 conferencing system by interfacing with the conference control 925 server. A CCP request contains a valid conference reservation and 926 reference by value to an 'iCal' object which contains scheduling 927 information about the conference (e.g., start time, end time). 929 +--------------+ +-------Conferencing System-----------------+ 930 | Generic ICAL | | | 931 | Resource | | ..Conference Instance.... | 932 +--------------+ | . . +-----------+| 933 ^ ^ | . +-------------------+ . | Conference|| 934 | | | . |Conference Objects |<--| Control || 935 | ----------------->. +-------------------+ . | Server || 936 | | . . +-----------+| 937 | | ......................... ^ | 938 | | ^ | | 939 +-----|--------------+ | | | 940 | v | | | 941 | +--------------+ | | | 942 | | Resource |<------------------+ | | 943 | | Scheduler | | | 944 | +--------------+ | | 945 | | | 946 +---------------------------------------------------------|------+ 947 | 948 | 949 +-Request-+ 950 | | 951 +----+ | 952 |ICAL| | 953 +----+----+ 954 | 955 | 956 | 957 Conference Control| 958 Protocol | 959 | 960 +-------------+ 961 | Conferencing| 962 | Client | 963 +-------------+ 965 Figure 7: Resource Scheduling 967 A CCP request to create a new conference reservation is validated, 968 including the associated iCal object, and the resultant conference 969 reservation is created. The conference reservation is uniquely 970 represented within the conferencing system by a conference object 971 identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and 972 defined in [ref conf-uri:TBD]. This unique URI is returned to the 973 client and can be used to reference the conference reservation, if 974 any future manipulations are required (e.g., alter start time), using 975 a CCP request. 977 The previous example explains how a client creates a basic conference 978 reservation using an iCal reference in association with a conference 979 control protocol. Figure 7 can also be applied when explaining how a 980 series of conferences are scheduled in the system. The description 981 is almost identical with the exception that the iCal definition that 982 is included in a CCP request represents a series of recurring 983 conference instances (e.g., conference start time, end time, occur 984 weekly). The conferencing system will treat this request the same as 985 the first example. The CCP request will be validated, along with the 986 associated iCal object, and the conference reservation is created. 987 The conference reservation and its conference object ID created for 988 this example represent the entire series of recurring conference 989 instances rather than a single Conference. If the client uses the 990 conference object ID provided and a CCP request to adjust the 991 conference reservation, every conference instance in the series will 992 be altered. This includes all future occurrences, such as a 993 conference scheduled as an infinite series, subject to the 994 limitations of the available calendaring interface. 996 A conferencing system that supports the scheduling of a series of 997 conference instances should also be able to support manipulation 998 within a specific range of the series. A good example is a 999 conference reservation that has been scheduled to occur every Monday 1000 at 09.00 GMT. For the next three weeks only, the meeting has been 1001 altered to occur at 10.00 GMT in an alternative venue. With Figure 7 1002 in mind, the client will construct a CCP request whose purpose is to 1003 modify the existing conference reservation for the recurring 1004 conference instance. The client will include the conference object 1005 ID provided by the conferencing system to explicitly reference the 1006 conference reservation within the conferencing system. A CCP request 1007 will contain all the required changes to the conference reservation 1008 (e.g., change of venue). 1010 The conferencing system matches the incoming CCP request to the 1011 existing conference reservation but identifies that the associated 1012 iCal object only refers to a range of the existing series. The 1013 conferencing system creates a child, by cloning the original 1014 conference reservation, to represent the altered conference instances 1015 within the series. The cloned child object is not independent of the 1016 original parent object, thus preventing any potential conflicts in 1017 scheduling (e.g., a change to the whole series 'start time'). The 1018 cloned conference reservation, representing the altered series of 1019 conference instances, has its own associated conference object ID 1020 which is returned to the client using a CCP response. This 1021 conference object ID is then used by the client to make any future 1022 alterations on the newly defined sub-series. This process can be 1023 repeated any number of times as the newly returned conference object 1024 ID representing an altered (cloned) series of conference instances, 1025 can itself be manipulated using a CCP request for the newly created 1026 conference object ID . This provides a flexible approach to the 1027 scheduling of recurring conference instances. 1029 8. Conferencing Mechanisms 1031 8.1. Call Signaling 1033 The focus is the central component of the conference. Participants 1034 interface with the focus using an appropriate call signaling protocol 1035 (CSP). Participants request to establish or join a conference using 1036 the CSP. After checking the applicable policies, a focus then either 1037 accepts the request, sends a progress indication related to the 1038 status of the request (e.g., for a parked call while awaiting 1039 moderator approval to join) or rejects that request using the call 1040 signaling interface. 1042 During an active conference, a Conference Control Protocol 1043 [Section 8.3] can be used to affect the conference state. For 1044 example, CCP requests to add and delete participants are communicated 1045 to the focus and checked against the conference policies. If 1046 approved, the participants are added or deleted using the call 1047 signaling to/from the focus. 1049 8.2. Notifications 1051 A conferencing system is responsible for implementing a Conference 1052 Notification Service. The Conference Notification Service provides 1053 updates about the conference instance state to authorized parties, 1054 including participants. A model for notifications using SIP is 1055 defined in [11]. 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 [references TBD]. 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 [15]. 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[5] 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 [15] 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 [17] 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 [17] 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 [17] 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 [16]. 1119 9. Conferencing Scenario Realizations 1121 This section addresses how advanced conferencing scenarios, many of 1122 which have been described in [13], 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 [14]. 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" [14] 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 "Frank" 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. 1531 +--------------------------------+ 1532 | Conferencing System | 1533 | +---------+--+| 1534 | |policies | || 1535 | +---------+ || 1536 | |Active || 1537 | |Conference || 1538 "Alice" | +-------+ || 1539 +--------+ | |"Alice"| || 1540 | |CCP Req |Conference | +-------+ || 1543 | | confUserID> | |Control |~~~>|"Carol"| || 1544 | |<--------------------------|Server | +-------+ || 1545 | |CCP Response | | | |"David"| || 1546 +--------+ | | | |"Ethel"| || 1548 | | | +-------+----+| 1549 | | | | | 1550 | | | V | 1551 | | | +---------+--+| 1552 | | | |policies | || 1553 | | |~~~>+---------+ || 1554 | +-----------+ | || 1555 "Alice" | | Sidebar || 1556 +--------+ | | Reservation|| 1557 | |CCP Request | |~~~>| || 1560 | | confID,confUserID, | | | +------------+| 1561 | | video=sidebar, | | | | | 1562 | | audio=sidebar> | |Conference | | | 1563 | | | |Control | V | 1564 | | | |Server | +---------+--+| 1565 | |CCP Response | | | |policies | || 1566 | | | | | |Sidebar || 1569 | | | |Conference || 1570 | +-----------+ +-------+ || 1571 | |"Alice"| || 1572 "Bob" | +-------+ || 1573 +--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | || 1574 | Client |<-------------------------|Notification|<~~~+-------+ || 1575 +--------+ "Ethel"=added, ||Service | |"Ethel"| || 1576 "Fred"=added,> || | +-------+ || 1577 "Ethel" +---| | |"Fred" | || 1578 +--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+| 1579 | Client | <--------------------+ +--------------------------------+ 1580 +--------+ "Ethel"=added,"Fred"=added,> 1582 Figure 13: Client Creation of an External Sidebar 1584 Upon receipt of the Conference Control Protocol request to "reserve" 1585 a new sidebar conference, based upon the active conference received 1586 in the request, the conferencing system uses the received active 1587 conference to clone a conference reservation for the sidebar. As 1588 discussed previously, the sidebar reservation is NOT independent of 1589 the active conference (i.e., parent). The conferencing system also 1590 reserves or allocates a conference ID to be used for any subsequent 1591 protocol requests from any of the members of the conference. The 1592 conferencing system maintains the mapping between this conference ID 1593 and the conference object ID associated with the sidebar reservation 1594 through the conference instance. 1596 Upon receipt of the conference control protocol response to reserve 1597 the conference, "Alice" can now create an active conference using 1598 that reservation or create additional reservations based upon the 1599 existing reservations. In this example, "Alice" wants only "Bob" and 1600 "Ethel", along with the new participant "Fred" to be involved in the 1601 sidebar, thus she manipulates the membership. "Alice" sets the media 1602 such that the participants in the sidebar don't receive any media 1603 from the main conference. "Alice" sends a conference control 1604 protocol request to update the information in the reservation and to 1605 create an active conference. 1607 Upon receipt of the conference control protocol request to update the 1608 reservation and to create an active conference for the sidebar, as 1609 identified by the conference object ID, the conferencing system 1610 ensures that "Alice" has the appropriate authority based on the 1611 policies associated with that specific conference object to perform 1612 the operation. The conferencing system must also validate the 1613 updated information in the reservation, ensuring whether members like 1614 "Fred" are already a user of this conferencing system or whether he 1615 is a new user. Since "Fred" is a new user for this conferencing 1616 system, a conference user identifier is created for "Fred". Based 1617 upon the addressing information provided for "Fred" by "Alice", the 1618 call signaling to add "Fred" to the conference is instigated through 1619 the Focus. 1621 Depending upon the policies, the participants in the sidebar (i.e., 1622 "Bob" and "Ethel") may be notified of his addition to the sidebar via 1623 the conference notification service. 1625 9.5. Floor control using sidebars 1627 Floor control with sidebars can be used to realize conferencing 1628 scenario such as an analyst briefing. In this scenario, the 1629 conference call has a panel of speakers who are allowed to talk in 1630 the main conference. The other participants are the analysts, who 1631 are not allowed to speak unless they have the floor. To request 1632 access to the floor, they have to join a new sidebar with the 1633 moderator and ask their question. The moderator can also whisper to 1634 each analyst what their status/position in the floor control queue, 1635 similar to the example in Figure 15 1637 Figure 14 provides an example of the configuration involved for this 1638 type of conference. As in the previous sidebar examples, there is 1639 the main conference along with a sidebar. "Alice" and "Bob" are the 1640 main participants in the conference, with "A1", "A2" and "A3" 1641 representing the analysts. The sidebar remains active throughout the 1642 conference, with the moderator, "Carol", serving as the chair. As 1643 discussed previously, the sidebar conference is NOT independent of 1644 the active conference (i.e., parent). The analysts are provided the 1645 conference object ID associated with the active sidebar when they 1646 join the main conference. The conferencing system also allocates a 1647 conference ID to be used for any subsequent manipulations of the 1648 sidebar conference. The conferencing system maintains the mapping 1649 between this conference ID and the conference object ID associated 1650 with the active sidebar conference through the conference instance. 1651 The analysts are permanently muted while in the main conference. The 1652 analysts are moved to the sidebar when they wish to speak. Only one 1653 analyst is given the floor at a given time. All participants in the 1654 sidebar conference receive audio from the main conference. 1656 +--------------------------------+ 1657 | Conferencing System | 1658 | +---------+--+| 1659 | |policies | || 1660 | +---------+ || 1661 | |Active || 1662 | |Conference || 1663 | +-------+ || 1664 | |"Alice"| || 1665 | +-------+ || 1666 | +-----------+ |"Bob" | || 1667 | |Conference | +-------+ || 1668 | |Control |~~~>|"A1" | || 1669 | |Server | +-------+ || 1670 | | | |"A2" | || 1671 | | | +-------+ || 1672 | | | |"A3" | || 1673 | | | +-------+----+| 1674 | | | | | 1675 | | | V | 1676 | | | +---------+--+| 1677 | | | |policies | || 1678 | | |~~~>+---------+ || 1679 | | | |Active || 1680 | +-----------+ |Sidebar || 1681 "A1" | |Conference || 1682 +--------+ Floor Request <"A1", |+------------+ +-------+ || 1683 | |------------------------->|Floor Ctrl | |"Carol"| || 1684 |Client | activeSideConfObjID,||Server |~~~>| | || 1685 +--------+ confID > || | +-------+----+| 1686 |+------------+ | | 1687 | V | 1688 | +---------+--+| 1689 | |policies | || 1690 | +---------+ || 1691 | |Active || 1692 | |Sidebar || 1693 "A1" | |Conference || 1694 +--------+ Floor Granted <"A1", |+------------+ +-------+ || 1695 | |<-------------------------|Floor Ctrl |<~~~|"Carol"| || 1696 | Client | activeSideConfObjID,||Server | +-------+ || 1697 +--------+ confID > || | |"A1" | || 1698 |+------------+ +-------+----+| 1699 +--------------------------------+ 1701 Figure 14: Floor Control with sidebars 1703 When "A1" wishes to ask a question, he sends a Floor Request message 1704 to the floor control server. Upon receipt of the request, the floor 1705 control server notifies the moderator, "Alice" of the active sidebar 1706 conference, whose serving as the floor chair. Note, that this 1707 signaling flow is not shown in the diagram. Since no other analysts 1708 have yet requested the floor, "Alice" indicates to the floor control 1709 server that "A1" may be granted the floor. 1711 9.6. Whispering or Private Messages 1713 The case of private messages can be handled as a sidebar with just 1714 two participants, similar to the example in section Section 9.4.1, 1715 but rather than using audio within the sidebar, "Alice" could add an 1716 additional text based media stream to the sidebar. The other 1717 context, referred to as whisper, in this document refers to 1718 situations involving one time media targetted to specific user(s). 1719 An example of a whisper would be an announcement injected only to the 1720 conference chair or to a new participant joining a conference. 1722 Figure 15 provides an example of one user "Alice" whose chairing a 1723 fixed length conference with "Bob" and "Carol". The configuration is 1724 such that only the chair is providing a warning when there is only 10 1725 minutes left in the conference. At that time, "Alice" is moved into 1726 a sidebar created by the conferencing system and only "Alice" 1727 receives the announcement. 1729 +--------------------------------+ 1730 | Conferencing System | 1731 | +---------+--+| 1732 | |policies | || 1733 | +---------+ || 1734 | |Active || 1735 | |Conference || 1736 | +-------+ || 1737 | |"Alice"| || 1738 | +-------+ || 1739 | +-----------+ |"Bob" | || 1740 | |Conference | +-------+ || 1741 | |Control |~~~>|"Carol"| || 1742 | |Server | +-------+----+| 1743 | | | | | 1744 | | | | | 1745 | | | V | 1746 | | | +---------+--+| 1747 | | | |policies | || 1748 | | |~~~>+---------+ || 1749 | | | | || 1750 | +-----------+ |Sidebar || 1751 "Alice" | |Conference || 1752 +--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ || 1753 | |<-------------------------|Notification| | | || 1754 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1755 +--------+ confID > || | +-------+----+| 1756 |+------------+ | 1757 ~~~Announcement provided to "Alice"~~~ 1758 | +-----------+ | 1759 | |Conference | | 1760 | |Control | | 1761 | |Server | | 1762 | | | | 1763 | | | \---------+--/| 1764 | | | |\ /|| 1765 | | |~~~>+ \ / || 1766 | | | | \ / || 1767 | +-----------+ |Sid\bar / || 1768 "Alice" | |Conf\re/ce || 1769 +--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ || 1770 | |<-------------------------|Notification|<~~~| /\| || 1771 | Client | activeSideConfObjID,||Service | |"Ali/ce\ || 1772 +--------+ confID > || | +---/---+\---+| 1773 |+------------+ / \ | 1774 +--------------------------------+ 1776 Figure 15: Whisper 1778 When the conferencing system determines that there is only 10 minutes 1779 left in the conference which "Alice" is chairing, rather than 1780 creating a reservation as was done for the sidebar in Section 9.4.1, 1781 the conferencing system directly creates an active sidebar 1782 conference, based on the active conference associated with "Alice". 1783 As discussed previously, the sidebar conference is NOT independent of 1784 the active conference (i.e., parent). The conferencing system also 1785 allocates a conference ID to be used for any subsequent manipulations 1786 of the sidebar conference. The conferencing system maintains the 1787 mapping between this conference ID and the conference object ID 1788 associated with the active sidebar conference through the conference 1789 instance. 1791 Immediately upon creation of the active sidebar conference, the 1792 announcement media is provided to "Alice". Depending upon the 1793 policies, Alice may be notified of her addition to the sidebar via 1794 the conference notification service. "Alice" continues to receive 1795 the media from the main conference. 1797 Upon completion of the announcement, "Alice" is removed from the 1798 siebar and the sidebar conference is deleted. Depending upon the 1799 policies, "Alice" may be notified of her removal from the sidebar via 1800 the conference notification service. 1802 9.7. Conference Announcements and Recordings 1804 Each participant can require a different type of announcement and/or 1805 recording service from the system. For example, "Alice", the 1806 conference chair, could be listening to a roll call while "Bob" may 1807 be using a telephony user interface to create a sidebar. Some 1808 announcements would apply to all the participants such as "This 1809 conference will end in 10 minutes". Recording is often required to 1810 capture the names of participants as they join a conference, 1811 typically after the participant has entered an access code as 1812 discussed in Section 9.8. These recorded names are then announced to 1813 all the participants as the new participant is added to the active 1814 conference. 1816 An example of a conferencing recording and announcement , along with 1817 collecting the DTMF, within the context of this framework, is shown 1818 in Figure 16. 1820 +--------------------------------+ 1821 | Conferencing System | 1822 "Alice" | +-----------+ | 1823 +--------+ | |Conference | | 1824 | |CCP Request < | |Control | | 1825 | Client |--------------------------->| |Server | | 1826 | |Bob's Conference ID, | | | | 1827 +--------+ Join > | | | | 1828 | | | | 1829 | ~ ~ | 1830 ~~~Announcement provided to "Alice"~~~ 1831 ~~~ Digits collected from "Alice"~~~ 1832 | ~ ~ +---------+--+| 1833 | | |~~~>|policies | || 1834 | | | +---------+ || 1835 | | | |Active || 1836 | | | |Conference || 1837 | | | +-------+ || 1838 | | | |"Bob" | || 1839 | | | +-------+ || 1840 | | | |"Carol"| || 1841 | | | +-------+----+| 1842 | ~ ~ | 1843 ~~~Announcement provided to "Alice"~~~ 1844 ~~~ Alice records her name ~~~ 1845 | ~ ~ +---------+--+| 1846 | | | |policies | || 1847 | | | +---------+ || 1848 | | |~~~>|Active || 1849 | +-----------+ |Sidebar || 1850 | |Conference || 1851 | +-------+ || 1852 | |"Bob" | || 1853 "Bob " | +-------+ || 1854 +--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| || 1855 | |<-------------------------|Notification| +-------+ || 1856 | Client | activeSideConfObjID,||Service |<~~~|"Alice"| || 1857 +--------+ confID > || | +-------+----+| 1858 |+------------+ | 1859 ~~~Announcement provided to All Parties~~~ 1860 | | 1861 +--------------------------------+ 1863 Figure 16: Recording and Announcements 1865 Upon receipt of the Conference Control Protocol request from "Alice" 1866 to join "Bob's" conference, the conferencing system maps the 1867 identifier received in the request to the conference object 1868 representing "Bob's" active conference. The conferencing system 1869 determines that a password is required for this specific conference, 1870 thus an announcement asking "Alice" to enter the password is provided 1871 to "Alice". Once "Alice" enters the password, it is validated 1872 against the policies associated with "Bob's" active conference. The 1873 conferencing system then connects to a server which prompts and 1874 records "Alice's" name. The conferencing system must also determine 1875 whether "Alice" is already a user of this conferencing system or 1876 whether she is a new user. 1878 If "Alice" is a new user for this conferencing system, a conference 1879 user identifier is created for "Alice". Based upon the addressing 1880 information provided by "Alice", the call signaling to add "Alice" to 1881 the conference is instigated through the Focus. 1883 Once the call signaling indicates that "Alice" has been successfully 1884 added to the specific conference, per updates to the state, and 1885 depending upon the policies, other participants (e.g., "Bob") are 1886 notified of the addition of "Alice" to the conference via the 1887 conference notification service and an announcement is provided to 1888 all the participants indicating that "Alice" has joined the 1889 conference. 1891 9.8. Monitoring for DTMF 1893 The conferencing system also needs the capability to monitor for DTMF 1894 from each individual participant. This would typically be used to 1895 enter the identifier and/or access code for joining a specific 1896 conference. 1898 An example of DTMF monitoring, within the context of the framework 1899 elements, is shown in Figure 16. 1901 9.9. Observing and Coaching 1903 The capability to observe a conference allows a participant with the 1904 appropriate authority to listen to the conference, typically without 1905 being an active participant and often as a hidden participant. When 1906 such a capability is available on a conferencing system, there is 1907 often an announcement provided to each participant as they join the 1908 conference indicating the call may be monitored. This capability is 1909 useful in the context of conferences which might be experiencing 1910 technical difficulties, thus allowing a technician to listen in to 1911 evaluate the type of problem. 1913 This capability could also apply to call center applications as it 1914 provides a mechanism for a supervisor to observe how the agent is 1915 handling a particular call with a customer. This scenario can be 1916 handled by by supervisor adding themselves to the existing active 1917 conference, with a listen only audio media path. Whether the agent 1918 is aware of when the supervisor joins the call should be 1919 configurable. 1921 Taking the supervisor capability one step further introduces a 1922 scenario whereby the agent can hear the supervisor, as well as the 1923 customer. The customer can still only hear the agent. This scenario 1924 would involve the creation of a sidebar involving the agent and the 1925 supervisor. Both the agent and supervisor receive the audio from the 1926 main conference. When the agent speaks, it is heard by the customer 1927 in the main conference. When the supervisor speaks, it is heard only 1928 by the agent in the sidebar conference. 1930 An example of observing and coachin is shown in figure Figure 17. In 1931 this example, call center agent "Bob" is involved in a conference 1932 with customer "Carol". Since "Bob" is a new agent and "Alice" sees 1933 that he has been on the call with "Carol" for longer than normal, she 1934 decides to observe the call and coach "Bob" as necessary. 1936 +--------------------------------+ 1937 | Conferencing System | 1938 | +---------+--+| 1939 | |policies | || 1940 | +---------+ || 1941 | |Active || 1942 | |Conference || 1943 "Alice" | | || 1944 +--------+ | | || 1945 | |CCP Req |Conference | +-------+ || 1948 | | confUserID> | |Control |~~~>|"Carol"| || 1949 | |<--------------------------|Server | +-------+----+| 1950 | |CCP Response | | | | | 1951 +--------+ | | | V | 1953 | | | +---------+--+| 1954 | | | |policies | || 1955 | | |~~~>+---------+ || 1956 | | | | || 1957 | +-----------+ | || 1958 "Alice" | | Sidebar || 1959 +--------+ | | Reservation|| 1960 | |CCP Request | |~~~>| || 1963 | | confID,confUserID> | | | +------------+| 1964 | | | | | | | 1965 | | | |Conference | | | 1966 | | | |Control | V | 1967 | | | |Server | +---------+--+| 1968 | |CCP Response | | | |policies | || 1969 | | | | | |Sidebar || 1972 | | | |Conference || 1973 | +-----------+ +-------+ || 1974 | |"Alice"| || 1975 "Bob" | | | || 1976 +--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ || 1977 | |<-------------------------|Notification|<~~~| | || 1978 | Client | "chair"="Alice" ||Service | |"Bob" | || 1979 +--------+ || | +-------+----+| 1980 |+------------+ | 1981 +--------------------------------+ 1983 Figure 17: Supervisor Creating a Sidebar for Observing/Coaching 1985 Upon receipt of the Conference Control Protocol request from "Alice" 1986 to "reserve" a new sidebar conference, based upon the active 1987 conference received in the request, the conferencing system uses the 1988 received active conference to clone a conference reservation for the 1989 sidebar. The conferencing system also reserves or allocates a 1990 conference ID to be used for any subsequent protocol requests from 1991 any of the members of the conference. The conferencing system 1992 maintains the mapping between this conference ID and the conference 1993 object ID associated with the sidebar reservation through the 1994 conference instance. 1996 Upon receipt of the conference control protocol response to reserve 1997 the conference, "Alice" can now create an active conference using 1998 that reservation or create additional reservations based upon the 1999 existing reservations. In this example, "Alice" wants only "Bob" to 2000 be involved in the sidebar, thus she manipulates the membership. 2001 "Alice" also wants the audio to be received by herself and "Bob" from 2002 the original conference, but wants any outgoing audio from herself to 2003 be restricted to the participants in the sidebar, whereas "Bob's" 2004 outgoing audio should go to the main conference, so that both "Alice" 2005 and the customer "Carol" hear the same audio from "Bob". "Alice" 2006 sends a conference control protocol request to update the information 2007 in the reservation and to create an active conference. 2009 Upon receipt of the conference control protocol request to update the 2010 reservation and to create an active conference for the sidebar, as 2011 identified by the conference object ID, the conferencing system 2012 ensures that "Alice" has the appropriate authority based on the 2013 policies associated with that specific conference object to perform 2014 the operation. Based upon the addressing information provided for 2015 "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with 2016 the appropriate media characteristics is instigated through the 2017 Focus. 2019 "Bob" is notified of his addition to the sidebar via the conference 2020 notification service, thus he is aware that "Alice" the supervisor is 2021 available for coaching him through this call. 2023 10. Relationships between SIPPING and Centralized Conferencing 2024 Frameworks 2026 The SIPPING Conferencing Framework [9] provides an overview of a wide 2027 range of centralized conferencing solutions known today in the 2028 conferencing industry. The document introduces a terminology and 2029 logical entities in order to systemize the overview and to show the 2030 common core of many of these systems. The logical entities and the 2031 listed scenarios in the SIPPING Conferencing Framework are being used 2032 to illustrate how SIP [4] can be used as a signaling means in these 2033 conferencing systems. SIPPING Conferencing Framework does not define 2034 new conference control protocols to be used by the general 2035 conferencing system. It uses only basic SIP [4], the SIP 2036 Conferencing for User Agents [14], and the SIPPING Conference Package 2037 [9] for basic SIP conferencing realization. 2039 This centralized conferencing framework document defines a particular 2040 centralized conferencing system and the logical entities implementing 2041 it. It also defines a particular data model and refers to the set of 2042 protocols (beyond call signaling means) being defined by the XCON WG 2043 to be used among the logical entities for implementing advanced 2044 conferencing features. The purpose of the XCON working group and 2045 this framework is to achieve interoperability between the logical 2046 entities from different vendors for controlling different aspects of 2047 advanced conferencing applications. 2049 The logical entities defined in the two frameworks are not intended 2050 to be mapped one-to-one. The two frameworks differ in the 2051 interpretation of the internal conferencing system decomposition and 2052 the corresponding operations. Nevertheless, the basic SIP [4], the 2053 SIP Conferencing for User Agents [14], and the SIPPING Conference 2054 Package [9] are fully compatible with both Framework documents. 2056 11. Security Considerations 2058 There are a wide variety of potential attacks related to 2059 conferencing, due to the natural involvement of multiple endpoints 2060 and the many, often user-invoked, capabilities provided by the 2061 conferencing system. Examples of attacks include the following: an 2062 endpoint attempting to listen to conferences in which it is not 2063 authorized to participate, an endpoint attempting to disconnect or 2064 mute other users, and theft of service, by an endpoint, in attempting 2065 to create conferences it is not allowed to create. 2067 There are several issues surrounding security of this conferencing 2068 framework. One set of issues involves securing the actual protocols 2069 and the associated authorization mechanisms. This first set of 2070 issues should be addressed in the specifications specific to the 2071 protocols described in Section 8. The protocols used for 2072 manipulation and retrieval of confidential information MUST support a 2073 confidentiality and integrity mechanism. Similar requirements apply 2074 for the floor control protocols. Section 11.3 discusses an approach 2075 for client authentication of a floor control server. 2077 There are also security issues associated with the authorization to 2078 perform actions on the conferencing system to invoke specific 2079 capabilities. Section 5.2 discusses the policies associated with the 2080 conference object to ensure that only authorized entities are able to 2081 manipulate the data to access the capabilities. The final set of 2082 issues involves the privacy and security of the identity of a user in 2083 the conference, which is discussed in Section 11.2 2085 11.1. Authorization 2087 Many policy authorization decisions are based on the identity of the 2088 user or the role that a user may have. There are several ways that a 2089 user might authenticate its identity to the system. The conferencing 2090 system may know about specific users and assign passwords to the 2091 users. The users may also be authenticated by knowing a particular 2092 conference ID and a PIN for it. Sometimes, a PIN is not required and 2093 the conference ID is used as a shared secret. The call signaling 2094 means can provide a trusted form of the user identity or it might 2095 just provide a hint of the possible identity and the user still needs 2096 to provide some authentication to prove it has the identity that was 2097 provided as a hint in the call signaling. This may be in the form of 2098 an IVR system or other means. The goal for the conferencing system 2099 is to figure out a user identity and a role for any attempt to send a 2100 request to the conferencing system. 2102 When a conferencing system presents the identity of authorized users, 2103 it may choose to provide information about the way the identity was 2104 proven or verified by the system. A user may also come as a 2105 completely unauthenticated user into the system - this fact needs 2106 also be communicated to interested parties. 2108 When guest users interact with the system, it is often in the context 2109 of a particular conference. In this case, the user may provide a PIN 2110 or a password that is specific to the conferences and authenticates 2111 the user to take on a certain role in that conference. The guest 2112 user can then perform actions that are allowed to any user with that 2113 role. 2115 The term password is used to mean the usual, that is to say a 2116 reasonable sized, in number of bits, hard to predict shared secret. 2117 Today users often have passwords with more than 30 bits of randomness 2118 in them. PIN is a special password case - a shared secret that is 2119 only numeric and often contains a fairly small number of bits (often 2120 as few as 10 bits). When conferencing systems are used for audio on 2121 the PSTN, there is often a need to authenticate using a PIN. 2122 Typically if the user fails to provide the correct PIN a few times in 2123 a row, the PSTN call is disconnected. The rate of making the calls 2124 and getting to the point to enter a PIN makes it fairly hard to do an 2125 exhaustive search of the PIN space even for 4 digit PINs. When using 2126 a high speed interface to connect to a conferencing system, it is 2127 often possible to do thousands of attempts per second and the PIN 2128 space could quickly be searched. Because of this, it is not 2129 appropriate to use PINs for authorization on any of the interfaces 2130 that provide fast queries or many simultaneous queries. 2132 11.2. Security and Privacy of Identity 2134 This conferencing system has an idea of the identity of a user but 2135 this does not mean it can reveal this identity to other users, due to 2136 privacy considerations. Users can select various options for 2137 revealing their identity to other users. A user can be "hidden" such 2138 that other users can not see they are participants in the conference, 2139 or they can be "anonymous" such that users can see that another user 2140 is there, but not see the identity of the user, or they can be 2141 "public" where other users can see their identity. If there are 2142 multiple "anonymous" users, other parties will be able to see them as 2143 independent "anonymous" parties and will be able to tell how many 2144 "anonymous" parties are in the conference. Note, that the visibility 2145 to other participants is dependent on their roles. For example, 2146 users' visibility (including "anonymous" and "hidden") may be 2147 displayed to the moderator or administrator, subject to a 2148 conferencing system's local policies. "Hidden" status is often used 2149 by automated or machine participants of a conference (e.g., call 2150 recording) and is also used in many call center situations. 2152 11.3. Floor Control Server Authentication 2154 Clients can authenticate a floor control server using the TLS 2155 certificates. Requests submitted on a successfully created 2156 connection between the client and floor control server may 2157 additionally require digest authentication within the BFCP protocol 2158 to authenticate the floor control client to the server. For this to 2159 take place, a shared secret needs to be exchanged between the floor 2160 control client/server entities. This can be achieved out of band 2161 using a mechanism such as the 'k=' SDP attribute. The shared secret 2162 can also be exchanged using un-specified 'out of band' mechanisms. 2163 When using Digest authentication of floor control client messages the 2164 exchange of an active 'Nonce' is also required. This can be achieved 2165 using a BFCP request response interaction as defined in BFCP (A 2166 request is submitted without a Nonce TLV and the server generates an 2167 error response with either an Error Code 7 (DIGEST TLV Required) or 6 2168 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 2169 can also be obtained 'out of band' using information provided in the 2170 offer/answer exchange. As with the other SDP Floor attributes 2171 referenced in this section and defined in [17], the 'nonce' attribute 2172 can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. 2174 12. IANA Considerations 2176 This is an informational draft, with no IANA considerations required. 2178 13. Acknowledgements 2180 This document is a result of architectural discussions among IETF 2181 XCON working group participants. The authors would like to thank 2182 Henning Schulzrinne for the "Conference Object Tree" proposal and 2183 general feedback, Cullen Jennings for providing input for the 2184 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 2185 Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson and Rohan 2186 Mahy for their reviews and constructive input. 2188 14. Changes since last Version 2190 NOTE TO THE RFC-Editor: Please remove this section prior to 2191 publication as an RFC. 2193 Changes from WG 04 to 05: 2195 1) Removed all references to "Conference Template": 2197 Section 4: 2199 - Updated "Common Conference Information" definition, merging details 2200 from "Conference Template" definition, which was removed. 2202 - In definition of "conference blueprint" 2204 - In definition of "conference object" 2206 - Removed definition of "Registered conference document" 2208 Section 5: 2210 - 1st paragraph. Reworded. 2212 - Figure2: added "boxes" for all the data listed in the Conference 2213 Template type in the diagram. 2215 - Paragraph following Figure 2. Reworded. 2217 Section 5.1/5.2: Merged 5.2 into section 5.1 and reworded 2218 appropriately. 2220 Section 7.1: Second paragraph, 3rd sentence. 2222 Section 7.3: 2224 - Second paragraph, 2nd and 3rd sentences. Deleted. Remaining 2225 sentence merged with 1st paragraph 2227 - Third paragraph. Deleted. 2229 Section 8.4, 1st paragraph. Removed Editor's note containing 2230 reference to alternative proposal for floor control using templates. 2232 Section 9.3, 1st paragraph after Figure 10. 2234 2) Section 4: 2236 - Sidebar. Clarified definition. 2238 - Whisper. Added definition. 2240 3) Section 5, last paragraph, added reference to 2241 draft-ietf-xcon-common-data-model. 2243 4) Section 8.3. Deleted Editor's note. Deleted subsections 2244 containing details of separate protocol proposals. 2246 5) Section 9.4. Sidebar. Added another example - an external 2247 sidebar (i.e. one involving a participant not in the main conference 2248 and with no media from the main conference). 2250 6) New section 9.5. Floor control with sidebars. 2252 7) Section 9.5 (new 9.6) Whisper. Added more detail and an example 2253 diagram. 2255 8) Section 9.8. (new 9.9) Observing a Conference. Added more details 2256 to example, including concept of coaching and added a corresponding 2257 diagram. 2259 9) Removed Appendix A and Appendix B and updated references to these. 2260 The content will be in separate documents (references TBD). 2262 10) Updated references. Changed drafts to RFCs as appropriate and 2263 removed unused references. 2265 Changes from WG 03 to 04: 2267 - Editorial nits and clarifications. 2269 - Section 4. Template: Removed reference to "user interface 2270 abstractions". 2272 - Section 5.2. Conference Template: deleted references to user 2273 interface abstraction (1st paragraph, last phrase and 4th paragraph). 2275 - Section 9.6. Conference Announcements and Recording: text 2276 expanded. Moved discussion of DTMF to a new section. 2278 - Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), 2279 with some initial text. 2281 Changes from WG 02 to 03: 2283 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 2285 - Added definition for Sidebar. 2287 - Section 5.2 Added text indicating that adding new elements or 2288 modifying elements requires the definition of a new template. (per 2289 DP4.2 conclusion). 2291 - Section 7.3. Added text reiterating that the blueprint comprises 2292 both the common conference information and a template (per DP4/4.1 2293 discussions. 2295 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 2296 blueprint is common conference information + one template and that 2297 multiple templates is FFS. 2299 - Section 8.3 - Updated Conference Control Protocol section to 2300 include the protocols on the table for WG discussion as of 31 Dec 2301 2005 deadline. 2303 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 2305 - Section 9.5 - Whisper - Added some text, reflecting past WG 2306 discussions. Basic definition and further details/example still 2307 needed. 2309 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 2310 Further details/example still needed. 2312 Changes from WG 01 to 02: 2314 - Editorial nits -i.e. consistent terminology, capatilization, etc. 2316 - Revamped abstract and introduction 2317 - Global removal of XCON as a qualifier (we had previously done this 2318 in a previous version with all the identifiers). 2320 - Global change of "call control signalling" to "call signaling" 2322 - Moved the terminology section after the Overview section: 2324 - - Modified the definitions to be more concise and per some of 2325 Henning's recommendations. 2327 - - Added definitions for blueprint and conference reservation. 2329 - Clarified the definition of policy and added more explicit text as 2330 to how policy is accomplished via the data model and system 2331 realization (section 4.3 and 6.1) 2333 - Removed the Editor's note/text in section 4 about the options for 2334 the schema; added a reference to a TBD schema document. 2336 - Section 5: 2338 - - clarified the identifiers. Kept the logical definition as 2339 "identifiers", although most will be realized as URIs. 2341 - - deleted the section on conference instance. 2343 - - removed the term "umbrella" from sections conference User and 2344 conference object identifier sections 2346 - - moved alot of detail from Conference User Identifier and 2347 conference Object Identifier sections into appendices, and added 2348 additional detail, that will become the basis for separate documents. 2350 - In section 6: 2352 - - added a bit of explanation as to the intent of the cloning tree 2353 model - it's not implementation binding, but rather to illustrate the 2354 data model and context for the protocol interactions. 2356 - - removed the term copying altogether. Cloning is the model and 2357 the idea is that the cloned object contains data indentical to the 2358 parent when it was created (whether it gets "copied" or whatever from 2359 the parent is an implementation issue). 2361 - - introduce the blueprint concept in section 6.1 prior to its 2362 implied usage in 6.2 and 6.3. 2364 - - removed the usage of the term occurrence (which is just a child 2365 reservation). 2367 - Removed security related details from Floor Control section and 2368 moved those to the security section. As a result removed most of the 2369 editorial notes from the front of the Floor control section and 2370 integrated the remaining ones inline into that section, where the 2371 resolution should be documented. 2373 - Section 8: 2375 - - Added new example 8.1 - conference creation 2377 - - Added a placeholder for a more detailed example to the sidebar 2378 section to show a sidebar which has some media specifically 2379 associated with the sidebar (i.e. audio), yet still use the main 2380 conference for other media (visual presentation). 2382 - Section 11: As a result of adding additional information to the 2383 security section, divided this section into subsections for clarity. 2385 Changes from WG 00 to 01:: 2387 - Section 2 (Conventions and Terminology). Slight modifications to 2388 definitions of Call (control) signaling, Conference Identifer, 2389 Conference Instance, Conference Object. 2391 - Section 2 (Conventions and Terminology).Renaming of term 2392 "Registered Template Definition" to "Registered Conference Document" 2393 (per agreement at interim meeting). 2395 - Section 3 (Next to the last paragraph on the media model). 2396 Clarified the text such that it doesn't read that the focus performs 2397 media mixing. Changed "focus" to "media mixer controlled by the 2398 focus" in the 2nd sentence and "performed" to "controlled" in the 2399 4th. 2401 - Section 5. Rearranged the sub-sections a bit for better flow. 2402 First describe the Conference ID, then the Conference Instance, 2403 followed by the Conference Object, with the Conference Object 2404 Identifer described in a subsection of the Conference Object section. 2405 Added a diagram showing the relationship between Conference 2406 Identifer/Focus and Conference Object Identifier, within the context 2407 of a Conference Instance to the Conference Object section. 2409 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 2410 apply to independent objects (and non-independent). 2412 - Section 6.3 (Advanced Example). Added additional text with regards 2413 to future conferences, introducing the concept of infinite series 2414 (which would be limited by calendaring interface). 2416 - Section 7.3 (Conference Control Protocol). Updated to include 2417 reference to SOAP option. 2419 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 2420 about the XCON FW constructs used. 2422 Changes from individual 02 to WG 00: 2424 - few minor editorial changes 2426 - Section 2. Removed second sentence of definition of Conference ID, 2427 as that's now included/described in context in new Identifier 2428 section. 2430 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 2431 Protocol" (per Keith's comment to be more explicit). 2433 - Section 4.1. Identifiers. Moved this to a new section ( 2434 Section 6). 2436 - New section for Identifiers ( Section 6), thus all section 2437 references beyond 4 are incremented in the new version. 2439 - Section 4. Since section 4.1 was removed, section 4.2 became the 2440 body text for section 4. 2442 - Section 4.2. Added "Floor Information" to Figure 2 as part of 2443 Common Conference Information, also added "Floor Control" to 2444 Conference Template (per text and Cullen's draft). 2446 - Section 4.5. Conference policies. Reworded to not introduce new 2447 terms, but use the general terms identified in the 1st paragraph. 2449 - Section 5.2. Removed "Instance" from "Active Conference Instance" 2450 in Figure 4. 2452 - Section 5.3. Added text clarifying that templates are retrieved 2453 from server (not central repository) (per DP3 conclusion). 2455 - Section 5.4. Added text that there is a single time and that the 2456 times are all relative the one time (per DP1 conclusion). 2458 - Section 5.4. Added text clarifying that changes to a series impact 2459 "all future occurrences (per DP1 discussion/conclusion). 2461 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 2462 as the CCP. 2464 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 2465 Condensed the text only slightly, but added explicit references to 2466 new identifier section. 2468 - Section 6.4.1 Moved to new Identifier section ( Section 6) 2470 - Section 7.1 - moved example to 7.2. Included a new (more 2471 appropriate example) in 7.1, although this may be too basic. 2473 - Section 7.3 - added some proposed text for Sidebars. 2475 15. References 2477 15.1. Normative References 2479 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2480 Levels", BCP 14, RFC 2119, March 1997. 2482 15.2. Informative References 2484 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2485 Protocol", RFC 2327, April 1998. 2487 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2488 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2489 August 1998. 2491 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2492 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2493 Session Initiation Protocol", RFC 3261, June 2002. 2495 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2496 Session Description Protocol (SDP)", RFC 3264, June 2002. 2498 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2499 Notification", RFC 3265, June 2002. 2501 [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2502 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2503 RFC 3550, July 2003. 2505 [8] Dawson, F. and Stenerson, D., "Internet Calendaring and 2506 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2507 November 1998. 2509 [9] Rosenberg, J., "A Framework for Conferencing with the Session 2510 Initiation Protocol (SIP)", RFC 4353, February 2006. 2512 [10] Levin, O. and R. Even, "High-Level Requirements for Tightly 2513 Coupled SIP Conferencing", RFC 4245, November 2005. 2515 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2516 Package for Conference State", 2517 draft-ietf-sipping-conference-package-12 (work in progress), 2518 July 2005. 2520 [12] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 2521 "Requirements for Floor Control Protocols", RFC 4376, 2522 February 2006. 2524 [13] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, 2525 August 2006. 2527 [14] Levin, O., "Session Initiation Protocol Call Control - 2528 Conferencing for User Agents", 2529 draft-ietf-sipping-cc-conferencing-07 (work in progress), 2530 June 2005. 2532 [15] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 2533 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 2535 [16] Levin, O. and G. Camarillo, "The SDP (Session Description 2536 Protocol) Label Attribute", 2537 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 2538 January 2005. 2540 [17] Camarillo, G., "Session Description Protocol (SDP) Format for 2541 Binary Floor Control Protocol (BFCP) Streams", 2542 draft-ietf-mmusic-sdp-bfcp-03 (work in progress), 2543 December 2005. 2545 [18] Novo, O., "A Common Conference Information Data Model for 2546 Centralized Conferencing (XCON)", 2547 draft-ietf-xcon-common-data-model-02 (work in progress), 2548 July 2006. 2550 [19] Campbell, B., "The Message Session Relay Protocol", 2551 draft-ietf-simple-message-sessions-15 (work in progress), 2552 July 2006. 2554 Authors' Addresses 2556 Mary Barnes 2557 Nortel 2558 2201 Lakeside Blvd 2559 Richardson, TX 2561 Email: mary.barnes@nortel.com 2563 Chris Boulton 2564 Ubiquity Software Corporation 2565 Building 3 2566 Wern Fawr Lane 2567 St Mellons 2568 Cardiff, South Wales CF3 5EA 2570 Email: cboulton@ubiquitysoftware.com 2572 Orit Levin 2573 Microsoft Corporation 2574 One Microsoft Way 2575 Redmond, WA 98052 2577 Email: oritl@microsoft.com 2579 Full Copyright Statement 2581 Copyright (C) The Internet Society (2006). 2583 This document is subject to the rights, licenses and restrictions 2584 contained in BCP 78, and except as set forth therein, the authors 2585 retain all their rights. 2587 This document and the information contained herein are provided on an 2588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2590 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2591 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2592 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2595 Intellectual Property 2597 The IETF takes no position regarding the validity or scope of any 2598 Intellectual Property Rights or other rights that might be claimed to 2599 pertain to the implementation or use of the technology described in 2600 this document or the extent to which any license under such rights 2601 might or might not be available; nor does it represent that it has 2602 made any independent effort to identify any such rights. Information 2603 on the procedures with respect to rights in RFC documents can be 2604 found in BCP 78 and BCP 79. 2606 Copies of IPR disclosures made to the IETF Secretariat and any 2607 assurances of licenses to be made available, or the result of an 2608 attempt made to obtain a general license or permission for the use of 2609 such proprietary rights by implementers or users of this 2610 specification can be obtained from the IETF on-line IPR repository at 2611 http://www.ietf.org/ipr. 2613 The IETF invites any interested party to bring to its attention any 2614 copyrights, patents or patent applications, or other proprietary 2615 rights that may cover technology that may be required to implement 2616 this standard. Please address the information to the IETF at 2617 ietf-ipr@ietf.org. 2619 Acknowledgment 2621 Funding for the RFC Editor function is provided by the IETF 2622 Administrative Support Activity (IASA).