idnits 2.17.1 draft-ietf-xcon-framework-04.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 2303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2293. ** 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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 25) being 89 lines == It seems as if not all pages are separated by form feeds - found 52 form feeds but 57 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 4 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 (June 22, 2006) is 6516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 1514 == Unused Reference: '3' is defined on line 2150, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2161, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2168, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2222, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 2243, 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 (-04) exists of draft-barnes-xcon-ccmp-00 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-14 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Expires: December 24, 2006 C. Boulton 5 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 June 22, 2006 10 A Framework and Data Model for Centralized Conferencing 11 draft-ietf-xcon-framework-04 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 December 24, 2006. 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 . . . . . . . . . . . . . 10 62 5.1. Common Conference Information . . . . . . . . . . . . . . 11 63 5.2. Conference Template . . . . . . . . . . . . . . . . . . . 12 64 5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12 65 6. Centralized Conferencing Constructs and Identifiers . . . . . 13 66 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13 67 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 68 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 69 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 70 7. Conferencing System Realization . . . . . . . . . . . . . . . 15 71 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 72 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 73 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 74 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23 75 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 76 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 77 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 78 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26 79 8.3.1. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 83 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29 84 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29 85 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31 86 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33 87 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 88 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38 89 9.6. Conference Announcements and Recordings . . . . . . . . . 39 90 9.7. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 39 91 9.8. Observing a Conference . . . . . . . . . . . . . . . . . . 39 92 10. Relationships between SIPPING and Centralized Conferencing 93 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 40 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 95 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 41 96 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 42 97 11.3. Floor Control Server Authentication . . . . . . . . . . . 42 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 100 14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 101 15. Appendix A - Conference Object Identifier . . . . . . . . . . 48 102 15.1. Conference Object URI Definition . . . . . . . . . . . . . 51 103 16. Appendix B - Conference User Identifier . . . . . . . . . . . 51 104 16.1. Conference User Definition . . . . . . . . . . . . . . . . 53 105 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 106 17.1. Normative References . . . . . . . . . . . . . . . . . . . 53 107 17.2. Informative References . . . . . . . . . . . . . . . . . . 53 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 109 Intellectual Property and Copyright Statements . . . . . . . . . . 57 111 1. Introduction 113 This document defines the framework for Centralized Conferencing. 114 The framework allows participants using various call signaling 115 protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in 116 a centralized unicast conference. Other than references to general 117 functionality (e.g., establishment and teardown), details of these 118 call signaling protocols are outside the scope of this document 120 The Centralized Conferencing Framework defines logical entities and 121 naming conventions, along with a conferencing data model. The 122 framework also outlines a set of conferencing protocols, which are 123 complementary to the call signaling protocols, for building advanced 124 conferencing applications. 126 The Centralized Conferencing Framework is compatible with the 127 functional model presented in the SIPPING Conferencing Framework [9]. 128 Section 10 of this document discusses the relationship between the 129 Centralized Conferencing Framework and the SIPPING Conferencing 130 framework, in the context of the Centralized Conferencing model 131 presented in this document. 133 2. Conventions 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 137 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 138 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 139 compliant implementations. 141 3. Overview 143 A centralized conference is an association of endpoints, called 144 conference participants, with a central endpoint, called a conference 145 Focus. The Focus has direct peer relationships with the participants 146 by maintaining a separate call signaling interface with each. 147 Consequently, in this centralized conferencing model, the call 148 signaling graph is always a star. 150 The most basic conference supported in this model would be an ad-hoc 151 unmanaged conference, which would not necessarily require any of the 152 functionality defined within this framework. For example, it could 153 be supported using basic SIP signaling functionality with a 154 participant serving as the Focus; the SIPPING Conferencing Framework 155 [9] together with the SIP Call Control Conferencing for User 156 Agents[15] documents address these types of scenarios. 158 In addition to the basic features, however, a conferencing system 159 supporting the centralized conferencing model proposed in this 160 framework document can offer richer functionality, by including 161 dedicated conferencing applications with explicitly defined 162 capabilities, reserved recurring conferences, along with providing 163 the standard protocols for managing and controlling the different 164 attributes of these conferences. 166 The core requirements for centralized conferencing are outlined in 167 [10]. These requirements are applicable for conferencing systems 168 using various call signaling protocols, including SIP. Additional 169 conferencing requirements are provided in [12], [13], and [14]. 171 The centralizing conferencing system proposed by this framework is 172 built around a fundamental concept of a conference object. A 173 conference object provides the data representation of a conference 174 during each of the various stages of a conference (e.g., creation, 175 reservation, active, completed, etc.). A conference object is 176 accessed via the logical functional elements, with whom a 177 conferencing client interfaces, using the various protocols 178 identified in Figure 1. The functional elements defined for a 179 conferencing system described by the framework are a Conference 180 Control Server, Floor Control Server, any number of Foci and a 181 Notification Service. A Conference Control Protocol (CCP) provides 182 the interface between a conference and media control client and the 183 conference control server. A Binary Floor Control Protocol (BFCP) 184 provides the interface between a floor control client and the floor 185 control server. A call signaling protocol (e.g., SIP, H.323, PSTN, 186 etc.) provides the interface between a call signaling client and a 187 Focus. A notification protocol (e.g. SIP Notify) provides the 188 interface between the conferencing client and the Notification 189 Service. 191 A conferencing system can support a subset of the conferencing 192 functions depicted in the conferencing system logical decomposition 193 in Figure 1 and described in this document. However, there are some 194 essential components that would typically be used by most other 195 advanced functions, such as the Notification Service. For example, 196 the notification service is used to correlate information, such as 197 list of participants with their media streams, between the various 198 other components. 200 ................................................................... 201 . Conferencing System . 202 . . 203 . +-----------------------------------------------------+ . 204 . | C o n f e r e n c e o b j e c t | . 205 . +-+---------------------------------------------------+ | . 206 . | C o n f e r e n c e o b j e c t | | . 207 . +-+---------------------------------------------------+ | | . 208 . | C o n f e r e n c e o b j e c t | | | . 209 . | | | | . 210 . | | |-+ . 211 . | |-+ . 212 . +-----------------------------------------------------+ . 213 . ^ ^ ^ | . 214 . | | | | . 215 . v v v v . 216 . +-------------------+ +--------------+ +-------+ +------------+. 217 . | Conference Control| | Floor Control| |Foci | |Notification|. 218 . | Server | | Server | | | |Service |. 219 . +-------------------+ +--------------+ +-------+ +------------+. 220 . ^ ^ ^ | . 221 ..............|.................|...........|..........|........... 222 | | | | 223 |Conference |Binary |Call |Notification 224 |Control |Floor |Signaling |Protocol 225 |Protocol |Control |Protocol | 226 | |Protocol | | 227 | | | | 228 ..............|.................|...........|..........|........... 229 . V V V V . 230 . +----------------+ +------------+ +----------+ +------------+. 231 . | Conference | | Floor | | Call | |Notification|. 232 . | and Media | | Control | | Signaling| | Client |. 233 . | Control | | Client | | Client | | |. 234 . | Client | | | | | | |. 235 . +----------------+ +------------+ +----------+ +------------+. 236 . . 237 . Conferencing Client . 238 ................................................................... 240 Figure 1: Conferencing System Logical Decomposition. 242 The media graph of a conference can be centralized, decentralized, or 243 any combination of both and potentially differ per media type. In 244 the centralized case, the media sessions are established between a 245 media mixer controlled by the focus and each one of the participants. 246 In the decentralized (i.e., distributed) case, the media graph is a 247 multicast or multi-unicast mesh among the participants. 248 Consequently, the media processing (e.g., mixing) can be controlled 249 either by the focus alone or by the participants. The concepts in 250 this framework document clearly map to a centralized media model. 251 The concepts can also apply to the decentralized media case, however, 252 the details of such are left for future study. 254 Section 5 of this document provides more details on the conference 255 object. Section 6 provides an overview of the identifiers necessary 256 to address and manage the conference objects, instances and users 257 associated with a conferencing system. Section 7 of this document 258 describes how a conferencing system is logically built using the 259 defined data model and how the conference objects are maintained. 260 Section 8 describes the fundamental conferencing mechanisms and 261 provides a high level overview of the protocols. Section 9 then 262 provides realizations of various conferencing scenarios, detailing 263 the manipulation of the conference objects using the defined 264 protocols. Section 10 of this document summarizes the relationship 265 between this Centralized Conferencing Framework and the SIPPING 266 Conferencing Framework. 268 4. Terminology 270 This Centralized Conferencing Framework document generalizes, when 271 appropriate, the SIPPING Conferencing Framework [9] terminology and 272 introduces new concepts, as listed below. Further details and 273 clarification of the new terms and concepts are provided in the 274 subsequent sections of this document. 276 Active conference: The term active conference refers to a conference 277 cbject that has been created and activated via the allocation of 278 its identifiers (e.g., conference object identifier and conference 279 identifier) and the associated focus. An active conference is 280 created based on either a system default conference blueprint or a 281 specific conference reservation. 282 Call Signaling protocol: The call signaling protocol is used between 283 a participant and a focus. In this context, the term "call" means 284 a channel or session used for media streams. 285 Common conference information: The common conference information is 286 the data type (i.e., the XML schema) which is used to represent 287 the core set of information for a conference object. This core 288 information includes a common set of definitions for basic 289 conference features, such as conference identifiers, membership, 290 signaling, capabilities and media types, applicable to a wide 291 range of conferencing applications. 293 Conference blueprint: A conference blueprint is a static conference 294 object within a conferencing system, which describes a typical 295 conference setting supported by the system. A conference 296 blueprint is the basis for creation of dynamic conference objects. 297 A system may maintain multiple blueprints. Each blueprint is 298 comprised of the initial values and ranges for the elements in the 299 object, conformant to the data schemas for the common conference 300 information and the specific template associated with the 301 blueprint. 302 Conference control protocol (CCP): A conference control protocol 303 provides the interface for data manipulation and state retrieval 304 for the centralized conferencing data, represented by the 305 conference object. 306 Conference factory: A conference factory is a logical entity, that 307 generates upon request, unique URI(s) to identify and represent a 308 conference focus. 309 Conference identifier (ID): A conference identifier is a call 310 signaling protocol-specific URI that identifies a conference focus 311 and its associated conference instance. 312 Conference instance: A conference instance refers to an internal 313 implementation of a specific conference, represented as a set of 314 logical conference objects and associated identifiers. 315 Conference object: A conference object represents a conference at a 316 certain stage (e.g., description upon conference creation, 317 reservation, activation, etc.), which a conferencing system 318 maintains in order to describe the system capabilities and to 319 provide access to the services available for each object 320 independently. The conference object schema is comprised of two 321 distinct sub components; the common conference information and the 322 conference template(s). 323 Conference object identifier (ID): A conference object identifier is 324 a URI which uniquely identifies a conference object and is used by 325 a conference control protocol to access and modify the conference 326 information. 327 Conference policies: Conference policies collectively refers to a set 328 of rights, permissions and limitations pertaining to operations 329 being performed on a certain conference object. 330 Conference reservation: A conference reservation is a conference 331 object, which is created from either a system default or client 332 selected blueprint. 333 Conference state: The conference state reflects the state of a 334 conference instance and is represented using a specific, well- 335 defined schema. 336 Conferencing system: Conferencing system refers to a conferencing 337 solution based on the data model discussed in this framework 338 document and built using the protocol specifications referenced in 339 this framework document. 341 Conference template: The conference template refers to the data type 342 (i.e. the XML schema) which is used to represent the media or 343 application specific part of the conference object. This 344 information represents enhanced conferencing features or 345 capabilities, such as media mixers. 346 Floor: Floor refers to a set of data or resources associated with a 347 conference instance, for which a conference participant, or group 348 of participants, is granted temporary access. 349 Floor chair: A floor chair is a floor control protocol compliant 350 client, either a human participant or automated entity, who is 351 authorized to manage access to one floor and can grant, deny or 352 revoke access. The floor chair does not have to be a participant 353 in the conference instance. 354 Focus: A focus is a logical entity that maintains the call signalling 355 interface with each participating client and the conference object 356 representing the active state. As such, the focus acts as an 357 endpoint for each of the supported signaling protocols and is 358 responsible for all primary conference membership operations 359 (e.g., join, leave, update the conference instance) and for media 360 negotiation/maintenance between a conference participant and the 361 focus. 362 Media graph: The media graph is the logical representation of the 363 flow of media for a conference. 364 Media mixer: A media mixer is the logical entity with the capability 365 to combine media inputs of the same type, transcode the media and 366 distribute the result(s) to a single or multiple outputs. In this 367 context, the term "media" means any type of data being delivered 368 over the network using appropriate transport means, such as RTP/ 369 RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol 370 (defined in [24]). 371 Registered conference document : A standards track document (i.e., 372 RFC) that defines and registers a conference template schema with 373 the appropriate organization (e.g., IANA). A registered 374 conference document also includes any complementary textual 375 information. 376 Role: A role provides the context for the set of conference 377 operations that a participant can perform. A default role (e.g., 378 standard conference participant) will always exist, providing a 379 user with a set of basic conference operations. Based on system 380 specific authentication and authorization, a user may take on 381 alternate roles, such as conference moderator, allowing access to 382 a wider set of conference operations. 383 Sidebar: A sidebar is a separate Conference instance that only exists 384 within the context of a parent conference instance. 386 Whisper: TBD. 388 5. Centralized Conferencing Data Model 390 The centralized conference data model is logically represented by the 391 conference object. A conference object is of type 'Conference object 392 type', which is comprised of two distinct components: the 'Common 393 conference information type' and the 'Conference template type', as 394 illustrated in Figure 2. Each of these types is extensible for 395 including potentially multiple sub-types. 397 +------------------------------------------------------+ 398 | C o n f e r e n c e o b j e c t t y p e | 399 | | 400 | +--------------------------------------------------+ | 401 | | Common conference information type | | 402 | | | | 403 | | +----------------------------------------------+ | | 404 | | | Conference description (times, duration) | | | 405 | | +----------------------------------------------+ | | 406 | | +----------------------------------------------+ | | 407 | | | Membership (roles, capacity, names) | | | 408 | | +----------------------------------------------+ | | 409 | | +----------------------------------------------+ | | 410 | | | Signaling (protocol, direction, status) | | | 411 | | +----------------------------------------------+ | | 412 | | +----------------------------------------------+ | | 413 | | | Floor information | | | 414 | | +----------------------------------------------+ | | 415 | | +----------------------------------------------+ | | 416 | | | Sidebars, Etc. | | | 417 | | +----------------------------------------------+ | | 418 | | | | 419 | +--------------------------------------------------+ | 420 | +--------------------------------------------------+ | 421 | | Conference template type | | 422 | | | | 423 | | - Mixer algorithm, inputs, and outputs | | 424 | | - Floor controls | | 425 | | - User Control Interface | | 426 | | - User's View | | 427 | | - Etc. | | 428 | +--------------------------------------------------+ | 429 | | 430 +------------------------------------------------------+ 431 Figure 2: Conference Object Type Decomposition. 433 In a system based on this conferencing framework, the same conference 434 object type is used for representation of a conference during 435 different stages of a conference, such as expressing conferencing 436 system capabilities, reserving conferencing resources or reflecting 437 the state of ongoing conferences. Thus, each of the two components 438 (i.e., the common conference information and the conference template) 439 may be optionally included in a particular conference object. 440 Section 7 describes the usage semantics of the conference objects. 442 The centralized conferencing data model defined in this framework has 443 no strict separation between conference membership, conference media 444 information and the related policies. The policies are an integral 445 part of the data model and are realized by local, system level 446 boundaries associated with specific data elements, such as the 447 membership, and by the ranges and limitations on other data elements. 448 Additional policy considerations for a system realization based on 449 this data model are discussed in Section 5.3. The integration of the 450 data in this model meets the requirement of many conference control 451 operations to enable synchronized access to the integral conference 452 policies, to the conference state as a whole, and for receiving 453 notifications about changes to either using the same interface. 455 The exact XML schema of the Conference Object, including the 456 organization of the Common Conference Information and the Conference 457 Templates, are detailed in separate documents [ref: TBD]. 459 5.1. Common Conference Information 461 The common conference information section contains the core 462 information that is utilized in any conference and is independent of 463 the specific conference media nature (e.g., the mixing algorithms 464 performed, the advanced floor control applied, etc.). Typically, 465 participants with read-only access to the conference information 466 would be interested in this common conference information only. 468 The common conference information may be represented using the 469 conference-type as defined in [11]. The conference-type contains the 470 definitions for representation of the conference object capabilities, 471 membership, roles, call signaling and media status relevant to 472 different stages of the conference life-cycle. 474 New centralized conferencing specifications can extend the basic 475 conference-type and introduce additional data elements to be used 476 within the common conference information type. 478 5.2. Conference Template 480 The concept of a conference template is introduced to separate the 481 complexity and the details of the "mixer" and other enhanced 482 conferencing features from the common conference information. 484 Each conference template needs to be registered with IANA. The IANA 485 registration needs to point to an RFC having the text description of 486 the feature behavior and the XML definition allowing the feature 487 presentation, configuration, and management. The RFCs defining these 488 templates are referred to as a registered conference document. 490 Typically, a conference template would contain the information about 491 the specific media mixing details, the associated client roles and 492 the available floor controls. This information would allow 493 authorized clients to manipulate the mixer's behavior via the focus, 494 and the resultant distribution of the media to all or individual 495 participants. By doing so, a client can change its own state and/or 496 state of other participants in the conference. 498 The addition of new elements or the modification of the controls 499 within an element of an existing template requires the definition of 500 a new template. 502 5.3. Conference policies 504 Conference policies collectively refers to a set of rights, 505 permissions and limitations pertaining to operations being performed 506 on a certain conference object. 508 The set of rights describes the read/write access privileges for the 509 conference object as a whole. This access would usually be granted 510 and defined in terms of giving the read-only or read-write access to 511 clients with certain roles in the conference. As such, the policies 512 represented by the set of rights aren't explicitly defined within the 513 data model, but rather are reflected in the system realization 514 (Section 7). 516 The permissions and limits, however, are specified as an integral 517 part of the conference object type, with data objects containing the 518 allowed ranges for other data objects (e.g., maximum number of 519 participants) and lists of clients allowed to perform certain 520 operations on a conference object. For example, the "allowed to 521 join" list of participants is consulted to decide who is allowed to 522 join. The entries in the list can specify the identity of an 523 individual user (joe@example.com), a role, a domain (*@example.com), 524 etc. For further details, refer to the detailed data model [ref: 525 TBD]. 527 A more general rule mechanism, beyond the functionality provided by 528 the permissions and limits, is an item for future study. 530 6. Centralized Conferencing Constructs and Identifiers 532 This section provides details of the identifiers associated with the 533 centralized conferencing framework constructs and the identifiers 534 necessary to address and manage the clients associated with a 535 conferencing system. An overview of the allocation, characteristics 536 and functional role of the identifiers is provided. 538 6.1. Conference Identifier 540 The conference identifier (conference ID) is a call signaling 541 protocol-specific URI that identifies a specific conference focus and 542 its associated conference instance. A conference factory is one 543 method for generating a unique conference ID, to identify and address 544 a conference focus, using a call signaling interface. Details on the 545 use of a conference factory for SIP signaling can be found in [15]. 546 The conference identifier can also be obtained using the conference 547 control protocol [Section 8.3] or other, including proprietary, out- 548 of-band mechanisms. 550 6.2. Conference Object 552 A Conference object provides the logical representation of a 553 conference iInstance in a certain stage, such as a conference 554 blueprint representing a conferencing system's capabilities, the data 555 representing a conference reservation, and the conference state 556 during an active conference. Each conference object is independently 557 addressable through the conference control protocol interface 558 [Section 8.3]. 560 Figure 3 illustrates the relationships between the conference 561 identifier, the focus and the conference object ID within the context 562 of a logical conference instance, with the conference object 563 corresponding to an active conference. 565 A conference object representing a conference in the active state can 566 have multiple call signalling conference identifiers; for example, 567 for each call signalling protocol supported. There is a one-to-one 568 mapping between an active conference object and a conference focus. 569 The focus is addressed by explicitly associating unique conference 570 IDs for each signaling protocol supported by the active conference 571 object. 573 ...................................................................... 574 . Conference Instance . 575 . . 576 . . 577 . +---------------------------------------------------+ . 578 . | Conference Object Identifier | . 579 . | | . 580 . | | . 581 . +---------------------------------------------------+ . 582 . ^ ^ . 583 . | | . 584 . v | . 585 . ................................................... | . 586 . . Focus . | . 587 . . . | . 588 . . +----------------------------------+ . | . 589 . . |Conference Identifier (Protocol Y)| . | . 590 . . +------------------------------------+ | . | . 591 . . | Conference Identifier (PSTN) | | . | . 592 . . +--------------------------------------+ |-+ . | . 593 . . | Conference Identifier (SIP) | |^ . | . 594 . . | |-+| . | . 595 . . | |^ | . | . 596 . . +--------------------------------------+| | . | . 597 . ............^...............................|.|.... | . 598 . | | | | . 599 ................|...............................|.|......|............ 600 | | | | 601 |SIP | | |Conference 602 | PSTN | |Y |Control 603 | | | |Protocol 604 | +---------------+ | | 605 | | | | 606 | | | | 607 v v v v 608 +----------------+ +--------------+ +---------------+ 609 | Conferencing | | Conferencing | | Conference | 610 | Client | | Client | | Client | 611 | 1 | | 2 | | X | 612 +----------------+ +--------------+ +---------------+ 614 Figure 3: Identifier Relationships for an Active Conference. 616 6.2.1. Conference Object Identifier 618 In order to make each conference object externally accessible, the 619 conferencing system allocates a unique URI per distinct conference 620 object in the system. A conference control protocol includes the 621 conference object identifier in requests for directly manipulating a 622 particular conference object and for obtaining its current state. 623 The conference object identifier logically maps to other protocol 624 specific identifiers associated with the conference instance, such as 625 the BFCP 'confid'. A full description and semantics of how the 626 conference object identifier is created and used is defined in 627 Section 15. 629 6.3. Conference User Identifier 631 Each user within a conferencing system is allocated a unique 632 conference user identifier. The user identifier is used in 633 association with the conference object identifier to uniquely 634 identify a user within the scope of conferencing system. There is 635 also a requirement for identifying conferencing system users who may 636 not be participating in a conference instance. Examples of these 637 users would be a non participating 'Floor Control Chair' or 'Media 638 Policy Controller'. The conference user identifier is required in 639 conference control protocol requests to uniquely determine who is 640 issuing commands, so that appropriate policies can be applied to the 641 requested command. The conference user identifer is logically 642 associated with the other user identifiers assigned to the 643 conferencing client for other protocol interfaces, such as an 644 authenticated SIP user. A full description and semantics of the 645 conference user identifier is provided in Section 16 647 7. Conferencing System Realization 649 Implementations based on this centralized conferencing framework can 650 range from systems supporting ad-hoc conferences, with default 651 behavior only, to sophisticated systems with the ability to schedule 652 recurring conferences, each with distinct characteristics, being 653 integrated with external resource reservation tools, and providing 654 snapshots of the conference information at any of the stages of the 655 conference life-cycle. 657 A conference object is the logical representation of a conference 658 instance at a certain stage, such as capabilities description upon 659 conference creation, reservation, activation, etc., which a 660 conferencing system maintains in order to describe the system 661 capabilities and to provide access to the available services provided 662 by the conferencing system. Consequently, this centralized 663 conferencing framework does not mandate the actual usage of the 664 conference object, but rather defines the general cloning tree 665 concept and the mechanisms required for its realization, as described 666 in detail in Section 7.1. 668 Adhoc and advanced conferencing examples are provided in Section 7.2 669 and Section 7.3, with the latter providing additional description of 670 the Conference Object in terms of the stages of a conference, to 671 support scheduled and other advanced conference capabilities. The 672 scheduling of a conference based on these concepts and mechanisms is 673 then detailed in Section 7.4 675 As discussed in Section 5.3, there are conference policies implicit 676 in and derivable from the data in the conference objects and there 677 are also policies applying to the conference objects as a whole. In 678 the examples in this section, these latter policies are shown 679 logically associated with the conference objects, however, it is an 680 implementation specific mechansim as to how these policies are 681 managed and applied to the conference objects. 683 7.1. Cloning Tree 685 The concept defined in this section is a logical representation only, 686 as it is reflected through the centralized conferencing mechanisms: 687 the URIs and the protocols. Of course, the actual system realization 688 can differ from the presented model. The intent is to illustrate the 689 role of the logical elements in providing an interface to the data, 690 based on conferencing system and conferencing client actions, and 691 describe the resultant protocol implications 693 Any conference object in a conferencing system is created by either 694 being explicitly cloned from an existing parent object or being 695 implicitly cloned from a default system conference blueprint. A 696 conference blueprint is a static conference object used to describe a 697 typical conference setting supported by the system. Each system can 698 maintain multiple blueprints, typically each describing a different 699 conferencing type using the common conference information format, 700 along with any number of template definitions. This document uses 701 the "cloning" metaphor instead of the "inheritance" metaphor because 702 it more closely fits the idea of object replication, rather than a 703 data type re-usage and extension concept. 705 The cloning operation needs to specify whether the link between the 706 parent and the child needs to be maintained in the system or not. If 707 no link between the parent and the child exists, the objects become 708 independent and are not impacted by any operations on the parent 709 object nor subject to any limitations of the parent object. 711 Once the new object is created, it can be addressed by a unique 712 conference object URI assigned by the system, as described in 713 Section 15 /[ref:TBD]. By default, the newly created object contains 714 all the data existing in the parent object. The newly created object 715 can expand the data it contains, within the schema types supported by 716 the parent. It can also restrict the read/write access to its 717 objects. However, unless the object is independent, it cannot modify 718 the access restrictions imposed by the parent object. 720 Any piece of data in the child object can be independently accessed 721 and, by default, can be independently modified without affecting the 722 parent data. 724 Unless the object is independent, the parent object can enforce a 725 different policy by marking certain data elements as "parent 726 enforceable". The values of these data elements can not be changed 727 by directly accessing the child object; neither can they be expanded 728 in the child object alone. 730 Figure 4 illustrates an example of a conference (Parent B), which is 731 created independent of its Parent (Parent A). Parent B creates two 732 child objects, Child 1 and Child 2. Any of the data elements of 733 Parent B can be modified (i.e. there are no "parent enforceable" data 734 elements) and depending upon the element, the changes will be 735 reflected in Child 1 and Child 2 , whereas changes to Parent A will 736 not impact the data elements of Parent B. Any "parent enforceable" 737 data elements as defined by Parent B cannot be modified in the child 738 objects. 740 +---+-----------------------+ 741 | p | | 742 | o | P A R E N T A | 743 | l | | 744 | i | C O N F E R E N C E | 745 | c | | 746 | i | O B J E C T | 747 | e | | 748 +-s-+-----------------------+ 749 | 750 \| / 751 \/ INDEPENDENT 752 /\ 753 /| \ 754 V 755 +---+-----------------------+ 756 | p | | 757 | o | P A R E N T B | 758 | l | | 759 | i | C O N F E R E N C E | 760 | c | | 761 | i | O B J E C T | 762 | e | | 763 +-s-+-----------------------+ 764 | | 765 | | 766 | --------------------------- 767 | | 768 V V 769 +---+-----------------------+ +---+-----------------------+ 770 | p | | | p | | 771 | o | C H I L D 1 | | o | C H I L D 2 | 772 | i | | | l | | 773 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 774 | i | | | c | | 775 | c | O B J E C T | | i | O B J E C T | 776 | i | | | e | | 777 +-s-+-----------------------+ +-s-+-----------------------+ 779 Figure 4: The Cloning Tree. 781 Using the defined cloning model and its tools, the following sections 782 show examples of how different systems based on this framework can be 783 realized. 785 7.2. Ad-hoc Example 787 Figure 5 illustrates how an ad-hoc conference can be created and 788 managed in a conferencing system. A client can create a conference 789 by establishing a call signaling channel with a conference factory as 790 specified in Section 6.1. The conference factory can internally 791 select one of the system supported conference blueprints based on the 792 requesting client privileges and the media lines included in the SDP 793 body. 795 The selected blueprint with its default values is copied by the 796 server into a newly created conference object, referred to as an 797 'Active Conference'. At this point the conference object becomes 798 independent from its blueprint. A new conference object identifier, 799 a new conference identifier and a new focus are allocated by the 800 server. 802 During the conference lifetime, an authorized client can manipulate 803 the conference object, such as adding participants, using the 804 Conference Control Protocol [Section 8.3]. 806 +---+-----------------------+ 807 | p | | 808 | o | System Default | 809 | l | | 810 | i | Conference | 811 | c | | 812 | i | Blueprint | 813 | e | | 814 +-s-+-----------------------+ 815 | 816 \| / 817 \/ 818 /\ 819 /| \ 820 V 821 +---+-----------------------+ 822 | p | | 823 | o | Active | 824 | l | | 825 | i | Conference | 826 | c | | 827 | i | | 828 | e | | 829 +-s-+-----------------------+ 830 Figure 5: Conference Ad-hoc Creation and Lifetime. 832 7.3. Advanced Example 834 Figure 6 illustrates how a recurring conference can be specified 835 according to system capabilities, scheduled, reserved, and managed in 836 a conferencing system. A client would first query a conferencing 837 system for its capabilities. This can be done by requesting a list 838 of the conference blueprints the system supports. 840 Each blueprint contains a specific combination of capabilities and 841 limitations of the conference server in terms of supported media 842 types (e.g., audio, video, text, or combinations of these), 843 participant roles, maximum number of participants of each role, 844 availability of floor control, controls available for participants, 845 availability and type of sidebars, the definitions and names of media 846 streams, etc. As defined within this framework, a blueprint is 847 comprised of the common conference information and a template. A 848 blueprint consists of a single template, as the template approach 849 allows for defining combinations of media types in a single template 850 [ref]. Whether a blueprint needs to additionally support multiple 851 templates, and the associated mechanism, is for future study. 853 The template within the blueprint can either be included by-value or 854 by-reference depending upon the system implementation. In the case 855 of a template included by-reference within a blueprint, a client may 856 need to query a template that it doesn't understand and then make a 857 decision on compatibility. Interface hints need to be included as 858 per [20]. In this case, a client selects the specific blueprint to 859 use and retrieves the associated template from the conferencing 860 system itself, rather than from a centralized repository. 862 The selected blueprint with its default values is cloned by the 863 client into a newly created conference object, referred to as a 864 conference reservation, that specifies the resources needed from the 865 system for this conference instance. At this point the conference 866 reservation becomes independent from its blueprint. The client can 867 also change the default values, within the system ranges, and add 868 additional information, such as the list of participants and the 869 conference start time, to the conference reservation. 871 At this point the client can ask the conference server to create new 872 conference reservations by attaching the conference reservation to 873 the request. As a result, the server can allocate the needed 874 resources, create the additional conference objects for the child 875 conference reservations and allocate the conference object 876 instances rather than a single Conference. If the client uses the 877 conference object ID provided and a CCP request to adjust the 878 conference reservation, every conference instance in the series will 879 be altered. This includes all future occurrences, such as a 880 conference scheduled as an infinite series, subject to the 881 limitations of the available calendaring interface. 883 A conferencing system that supports the scheduling of a series of 884 conference instances should also be able to support manipulation 885 within a specific range of the series. A good example is a 886 conference reservation that has been scheduled to occur every Monday 887 at 09.00 GMT. For the next three weeks only, the meeting has been 888 altered to occur at 10.00 GMT in an alternative venue. With Figure 7 889 in mind, the client will construct a CCP request whose purpose is to 890 modify the existing conference reservation for the recurring 891 conference instance. The client will include the conference object 892 ID provided by the conferencing system to explicitly reference the 893 conference reservation within the conferencing system. A CCP request 894 will contain all the required changes to the conference reservation 895 (e.g., change of venue). 897 The conferencing system matches the incoming CCP request to the 898 existing conference reservation but identifies that the associated 899 iCal object only refers to a range of the existing series. The 900 conferencing system creates a child, by cloning the original 901 conference reservation, to represent the altered conference instances 902 within the series. The cloned child object is not independent of the 903 original parent object, thus preventing any potential conflicts in 904 scheduling (e.g., a change to the whole series 'start time'). The 905 cloned conference reservation, representing the altered series of 906 conference instances, has its own associated conference object ID 907 which is returned to the client using a CCP response. This 908 conference object ID is then used by the client to make any future 909 alterations on the newly defined sub-series. This process can be 910 repeated any number of times as the newly returned conference object 911 ID representing an altered (cloned) series of conference instances, 912 can itself be manipulated using a CCP request for the newly created 913 conference object ID . This provides a flexible approach to the 914 scheduling of recurring conference instances. 916 8. Conferencing Mechanisms 918 8.1. Call Signaling 920 The focus is the central component of the conference. Participants 921 interface with the focus using an appropriate call signaling protocol 922 (CSP). Participants request to establish or join a conference using 923 the CSP. After checking the applicable policies, a focus then either 924 accepts the request, sends a progress indication related to the 925 status of the request (e.g., for a parked call while awaiting 926 moderator approval to join) or rejects that request using the call 927 signaling interface. 929 During an active conference, a Conference Control Protocol 930 [Section 8.3] can be used to affect the conference state. For 931 example, CCP requests to add and delete participants are communicated 932 to the focus and checked against the conference policies. If 933 approved, the participants are added or deleted using the call 934 signaling to/from the focus. 936 8.2. Notifications 938 A conferencing system is responsible for implementing a Conference 939 Notification Service. The Conference Notification Service provides 940 updates about the conference instance state to authorized parties, 941 including participants. A model for notifications using SIP is 942 defined in [11]. 944 The conference user identifier and associated role are used by the 945 conferencing system to filter the notifications such that they 946 contain only information that is allowed to be sent to that user. 948 8.3. Conference Control Protocol 950 The conference control protocol provides for data manipulation and 951 state retrieval for the centralized conferencing data, represented by 952 the conference object. The details of the conference control 953 protocol are detailed in separate documents [references TBD]. 955 [Editor's note: The remaining paragraphs and subsections of this 956 section, detailing the various protocol options should be pruned from 957 this document, once the WG reaches consensus on the conference 958 control protocol.] 960 8.3.1. CCCP 962 A Centralized Conferencing Control Protocol [19] is a semantic- 963 oriented protocol defined to allow participants or otherwise 964 authorized entities to directly manipulate an active conference 965 instance. CCCP is defined as a set of transactions issued over a 966 reliable transport protocol. A transaction consists of a Request 967 carrying the required information in an XML body and a corresponding 968 Response carrying an appropriate XML body. 970 CCCP requests are submitted to the CCCP server and can be prioritized 971 and queued, based on the CCCP client Role and the requested 972 primitives. CCCP requires no single lock per document, and the CCCP 973 server can locally implement an optimization strategy independent of 974 CCCP client behavior. 976 8.3.2. CSCP 978 A Conference State Change protocol [25] is a client server protocol 979 used to change the state of a conference object. CSCP extends the 980 BFCP protocol [16] with new commands. A client sends the server a 981 request representing a sequence of commands. Each command can set, 982 get, add, or delete a single field in the conference object. Changes 983 to the conference object are performed on a hierarchal set of 984 elements and unique attributes within those elements. A series of 985 changes can be pipelined in a single BFCP message. The server 986 executes each action in series. If one of them fails, the server 987 returns an error for the action that failed and does not execute any 988 of the actions after that. Each individual action is atomic but the 989 pipelined series is not. 991 The item to which a command applies is specified by a unique ID and, 992 where appropriate, attribute name. The ID is an unsigned 32 bit 993 integer called the Element ID. The server discovery of the Element 994 ID is outside of CSCP. Typically this is done by using the 995 conference notification service per Section 8.2. Each field in the 996 data received in the notification contains a unique field ID 997 attribute that can be used in BFCP requests. 999 8.3.3. SOAP 1001 The SOAP protocol is fundamentally an XML messaging scheme, capable 1002 of supporting remote procedure calls. SOAP defines a simple message 1003 format composed of a "header" and a "body" contained within an 1004 "envelope". The "header" contains meta-information relating to the 1005 message, and can be used to indicate such things as store-and-forward 1006 behaviour or transactional characteristics. In addition, SOAP 1007 encoding is optimized for ease of automated deserialization of the 1008 message body. 1010 SOAP [17] and [18] is proposed as the mechanism for object content 1011 manipulation and state retrieval for the centralized conferencing 1012 data. In general, SOAP is a good fit for Conference Control, 1013 essentially because of its remote procedure call characteristics and 1014 its inherently synchronous and client-driven nature. 1016 8.4. Floor Control 1018 A floor control protocol allows an authorized client to manage access 1019 to a specific floor and to grant, deny or revoke access of other 1020 conference users to that floor. Floor control is not a mandatory 1021 mechanism for a conferencing system implementation but provides 1022 advanced media input control features for conference users. A 1023 mechanism for floor control within a conferencing system is defined 1024 in the Binary Floor Control Protocol specification [16]. [Editor's 1025 note: Evaluation of an alternative proposal, as a stand alone draft, 1026 for using Templates as the means for correlating Floor Control 1027 identifiers has been proposed. If/when this work is done, it needs 1028 to be introduced and referenced here]. 1030 Within this framework, a client supporting floor control needs to 1031 obtain information for connecting to a floor control server to enable 1032 it to issue floor requests. This connection information can be 1033 retrieved using information provided by mechanisms such as 1034 negotiation using the SDP[2] offer/answer[5] exchange on the 1035 signaling interface with the focus. Section 11.3 provides a 1036 discussion of client authentication of a floor control server. 1038 As well as the client to the floor control server connection 1039 information, a client wishing to interact with a floor control server 1040 requires access to additional information. This information 1041 associates floor control interactions with the appropriate floor 1042 instance. Once a connection has been established and authenticated 1043 (see [16] for authentication details), a specific floor control 1044 message requires detailed information to uniquely identify a 1045 conference, a user and a floor. 1047 The conference is uniquely identifed by the conference object ID per 1048 Section 6.2.1. This conference object ID must be included in all 1049 floor control messages. When the SDP model is used as described in 1050 [23] this identifier maps to the 'confid' SDP attribute. 1052 Each authorized user associated with a conference object is uniquely 1053 represented by a conference user ID per Section 6.3. This conference 1054 user ID must be included in all floor control messages. When using 1055 SDP offer/answer exchange to negotiate a Floor control connection 1056 with the focus using the call signaling protocol, the unique 1057 conference identifier is contained in the 'userid' SDP attribute, as 1058 defined in [23] 1060 A media session within a conferencing system can have any number of 1061 floors (0 or more) that are represented by the conference identifer. 1062 When using SDP offer/answer exchange to negotiate a floor control 1063 connection with the focus using the call signaling interface, the 1064 unique conference identifier is contained in the 'floorid' SDP 1065 attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 . Each 1066 'floorid' attribute, representing a unique floor, has an 'm-stream' 1067 tag containing one or more identifiers. The identifiers represent 1068 individual SDP media sessions (as defined using 'm=' from SDP) using 1069 the SDP 'Label' attribute as defined in [22]. 1071 9. Conferencing Scenario Realizations 1073 This section addresses how advanced conferencing scenarios, many of 1074 which have been described in [14], are realized using this 1075 centralized conferencing framework. The objective of this section is 1076 to further illustrate the model, mechanisms and protocols presented 1077 in the previous sections and also serves to validate that the model, 1078 mechanisms and protocols are sufficient to support advanced 1079 conferencing scenarios. 1081 The details shown in the messages are for illustrative purposes only 1082 and don't reflect the structure of the conference control protocol 1083 messages, but rather provide a high level primitive view of the 1084 necessary operations and general logic flow, including the data 1085 manipulation aspects. It should be noted that not all entities 1086 impacted by the request are shown in the diagram (e.g., Focus), but 1087 rather the emphasis is on the new entities introduced by this 1088 centralized conferencing framework. 1090 9.1. Conference Creation 1092 There are different ways to create a conference. A participant can 1093 create a conference using call signaling means only, such as SIP and 1094 detailed in [15]. For a conferencing client to have more flexibility 1095 in defining the charaterisitics and capabilities of a conference, a 1096 conferencing client would implement a conference control protocol 1097 client. By using a conference control protocol, the client can 1098 determine the capabilities of a conferencing system and its various 1099 resources. 1101 Figure 8 provides an example of one client "Alice" determining the 1102 conference blueprints available for a particular conferencing system 1103 and creating a conference based on the desired blueprint. 1105 +--------------------------------+ 1106 | Conferencing System | 1107 "Alice" | +------------+| 1108 +--------+ | | || 1109 | |CCP Request | +-----------+ | || 1110 | Client |-------------------------->|Conference | |Conference || 1111 | |<--------------------------|Control |~~~>|Blueprint(s)|| 1112 +--------+CCP Response | | 1116 "Alice" | 1117 +--------+ | | 1118 | |CCP Request |Conference | |Conference || 1121 | | confUserID> | |Control |~~~>|BlueprintA || 1122 | |<--------------------------|Server | | || 1123 | |CCP Response | | | +------------+| 1124 +--------+ | | | /|\ | 1126 | | | V | 1127 | | | +------------+| 1128 | | |~~~>|Conference || 1129 | | | |Reservation || 1130 | +-----------+ +------------+| 1131 "Alice" | | | 1132 +--------+ | | | 1133 | |CCP Request |Conference | |Active || 1136 | | confID,confUserID> | |Control |~~~>|Conference || 1137 | |<--------------------------|Server | | || 1138 | |CCP Response | | | +------------+| 1139 +--------+ | +-----------+ | 1141 +--------------------------------+ 1143 Figure 8: Client Creation of Conference using Blueprints 1144 Upon receipt of the Conference Control Protocol request for 1145 blueprints, the conferencing system would first authenticate "Alice" 1146 (and allocate a conference user identifier, if necessary) and then 1147 ensure that "Alice" has the appropriate authority based on system 1148 policies to receive any blueprints supported by that system. Any 1149 blueprints that "Alice" is authorized to use are returned in a 1150 response, along with the conference user ID. 1152 Upon receipt of the Conference Control Protocol response containing 1153 the blueprints, "Alice" determines which blueprint to use for the 1154 conference to be created. "Alice" creates a conference object based 1155 on the blueprint (i.e., clones) and modifies applicable fields, such 1156 as membership list and start time. "Alice" then sends a request to 1157 the conferencing system to create a conference reservation based upon 1158 the updated blueprint. 1160 Upon receipt of the Conference Control Protocol request to "reserve" 1161 a conference based upon the blueprint in the request, the 1162 conferencing system ensures that the blueprint received is a valid 1163 blueprint (i.e. the values of the various field are within range). 1164 The conferencing system determines the appropriate read/write access 1165 of any users to be added to a conference based on this blueprint 1166 (using membership, roles, etc.). The conferencing system uses the 1167 received blueprint to clone a conference reservation. The 1168 conferencing system also reserves or allocates a conference ID to be 1169 used for any subsequent protocol requests from any of the members of 1170 the conference. The conferencing system maintains the mapping 1171 between this conference ID and the conference object ID associated 1172 with the reservation through the conference instance. 1174 Upon receipt of the conference control protocol response to reserve 1175 the conference, "Alice" can now create an active conference using 1176 that reservation or create additional reservations based upon the 1177 existing reservations. In this example, "Alice" has reserved a 1178 meetme conference bridge. Thus, "Alice" provides the conference 1179 information, including the necessary conference ID, to desired 1180 participants. When the first participant, including "Alice", 1181 requests to be added to the conference, an active conference and 1182 focus are created. The focus is associated with the conference ID 1183 received in the request. Any participants that have the authority to 1184 manipulate the conference would receive the conference object 1185 identifier of the active conference object in the response. 1187 9.2. Participant Manipulations 1189 There are different ways to affect a participant state in a 1190 conference. A participant can join and leave the conference using 1191 call signaling means only, such as SIP. This kind of operation is 1192 called "1st party signaling" and does not affect the state of other 1193 participants in the conference. 1195 Limited operations for controlling other conference participants (a 1196 so called "3rd party control") through the Focus, using call 1197 signaling only, may also be available for some signaling protocols. 1198 For example, "Conferencing for SIP User Agents" [15] shows how SIP 1199 with REFER can be used to achieve this functionality. 1201 In order to perform richer conference control a user client needs to 1202 implement a conference control protocol client. By using a 1203 conference control protocol, the client can affect its own state, 1204 state of other participants, and state of various resources (such as 1205 media mixers) which may indirectly affect the state of any of the 1206 conference participants. 1208 Figure 9 provides an example of one client "Alice" impacting the 1209 state of another client "Bob". This example assumes an established 1210 conference. In this example, "Alice" wants to add "Bob" to the 1211 conference. 1213 +--------------------------------+ 1214 | Conferencing System | 1215 "Alice" | +---------+--+| 1216 +--------+ | |policies | || 1217 | |CCP Request < | +-----------+ +---------+ || 1218 | Client |-------------------------->|Conference | | Active || 1219 | | Conference Object ID, | |Control |~~~>|Conference || 1220 +--------+ Add, "Bob" > | |Server | | || 1221 | +-----------+ +-------+ || 1222 | |"Alice"| || 1223 "Carol" | ' ' '| 1224 +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| 1225 | |<-------------------------|Notification|<~~~| || 1226 | Client |. . ||Service | +-------+ || 1227 +--------+--+ . || | |"Bob" | || 1228 | |<----------------------| | +-------+----+| 1229 | Client |NOTIFY <"Bob"="added">|+------------+ | 1230 +--------+ +--------------------------------+ 1231 "Bob" 1233 Figure 9: Client Manipulation of Conference - Add a party 1234 Upon receipt of the Conference Control Protocol request to "add" a 1235 party ("Bob") in the specific conference as identified by the 1236 conference object ID, the conferencing system ensures that "Alice" 1237 has the appropriate authority based on the policies associated with 1238 that specific conference object to perform the operation. The 1239 conferencing system must also determine whether "Bob" is already a 1240 user of this conferencing system or whether he is a new user. 1242 If "Bob" is a new user for this conferencing system, a Conference 1243 User Identifier is created for Bob. Based upon the addressing 1244 information provided for "Bob" by "Alice", the call signaling to add 1245 "Bob" to the conference is instigated through the Focus. 1247 Once the call signaling indicates that "Bob" has been successfully 1248 added to the specific conference, per updates to the state, and 1249 depending upon the policies, other participants (including "Bob") may 1250 be notified of the addition of "Bob" to the conference via the 1251 Conference Notification Service. 1253 9.3. Media Manipulations 1255 There are different ways to manipulate the media in a conference. A 1256 participant can change its own media streams by, for example, sending 1257 re-INVITE with new SDP content using SIP only. This kind of 1258 operations is called "1st party signaling" and they do not affect the 1259 state of other participants in the conference. 1261 In order to perform richer conference control a user client needs to 1262 implement a conference control protocol client. By using a 1263 conference control protocol, the client can manipulate the state of 1264 various resources, such as media mixers, which may indirectly affect 1265 the state of any of the conference participants. 1267 Figure 10 provides an example of one client "Alice" impacting the 1268 media state of another client "Bob". This example assumes an 1269 established conference. In this example, the client, "Alice" whose 1270 Role is "moderator" of the conference, wants to mute "Bob" on a 1271 medium-size multi-party conference, as his device is not muted (and 1272 he's obviously not listening to the call) and background noise in his 1273 office environment is disruptive to the conference. 1275 +--------------------------------+ 1276 | Conferencing System | 1277 "Alice" | +---------+--+| 1278 +--------+ | |policies | || 1279 | |CCP Request < | +-----------+ +---------+ || 1280 | Client |-------------------------->|Conference | |Active || 1281 | | Conference Object ID, | |Control |~~~>|Conference || 1282 +--------+ Mute, "Bob" > | |Server | | || 1283 | +-----------+ +-------+ || 1284 | |"Alice"| || 1285 | ' ' '| 1286 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1287 | |<-------------------------|Notification|<~~~| || 1288 | Client |. . ||Service | +-------+ || 1289 +--------+--+ . || | |"Bob" | || 1290 | |<----------------------| | +-------+----+| 1291 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1292 +--------+ +--------------------------------+ 1294 Figure 10: Client Manipulation of Conference - Mute a party 1296 Upon receipt of the Conference Control Protocol request to "mute" a 1297 party ("Bob") in the specific conference as identified by the 1298 conference object ID, the Conference Server ensures that "Alice" has 1299 the appropriate authority based on the policies associated with that 1300 specific conference object to perform the operation. "Bob's" status 1301 is marked as "recvonly" and the Conference Template of the Conference 1302 Object (if included) is updated to reflect that "Bob's" media is not 1303 to be "mixed" with the conference media. 1305 Depending upon the policies, other participants (including "Bob") may 1306 be notified of this change via the Conference Notification Service. 1308 9.4. Sidebar Manipulations 1310 A sidebar can be viewed as a separate Conference instance that only 1311 exists within the context of a parent conference instance. Although 1312 viewed as an independent conference instance, it can not exist 1313 without a parent. A sidebar is created using the same mechanisms 1314 employed for a standard conference as described in Section 7.1. 1316 A conference object representing a sidebar is created by cloning the 1317 parent associated with the existing conference and updating any 1318 information specific to the sidebar. A sidebar conference object is 1319 implicitly linked to the parent conference object (i.e. it is not an 1320 independent object) and is associated with the parent conference 1321 object identifier as as shown in Figure 11. A conferencing system 1322 manages and enforces the parent and appropriate localized 1323 restrictions on the sidebar conference object (e.g., no members from 1324 outside the parent conference instance can join, sidebar conference 1325 can not exist if parent conference is terminated, etc.). 1327 +--------------+ 1328 | Conference | 1329 | Object | 1330 | Identifier | 1331 +--------------+ 1332 | 1333 | 1334 | 1335 +---------------------+---------------------+ 1336 | | | 1337 +-------+-------+ +-------+-------+ +-------+-------+ 1338 | Sidebar | | Sidebar | | Sidebar | 1339 | Conference | | Conference | | Conference | 1340 | Object | | Object | | Object | 1341 | Identifier | | Identifier | | Identifier | 1342 +-------+-------+ +-------+-------+ +---------------+ 1344 Figure 11: Conference Object Mapping. 1346 Figure 11 illustrates the relationship between a conference object 1347 and associated Sidebar conference objects within a conferencing 1348 system. Each Sidebar conference object has a unique conference 1349 object Identifier as described in Section 6.2.1. The main conference 1350 object identifier acts as a top level identifier for associated 1351 sidebars. 1353 A sidebar conference object Identifier follows many of the concepts 1354 outlined in the cloning tree model described in Section 7.1. A 1355 Sidebar conference object contains a subset of members from the 1356 original Conference object. Properties of the sidebar conference 1357 object can be manipulated by a Conference Control Protocol 1358 (Section 8.3) using the unique conference object identifier for the 1359 sidebar. It is also possible for the top level conference object to 1360 enforce policy on the sidebar object (similar to parent enforceable 1361 as discussed in Section 7.1). 1363 Figure 12 provides an example of one client "Alice" involved in 1364 active conference with "Bob" and "Carol". "Alice" wants to create a 1365 sidebar to have a side discussion with "Bob" while still viewing the 1366 video associated with the main conference. "Alice" initiates the 1367 sidebar by sending a request to the conferencing system to create a 1368 conference reservation based upon the active conference object. 1370 +--------------------------------+ 1371 | Conferencing System | 1372 | +---------+--+| 1373 | |policies | || 1374 | +---------+ || 1375 | |Active || 1376 | |Conference || 1377 "Alice" | +-------+ || 1378 +--------+ | |"Alice"| || 1379 | |CCP Req |Conference | +-------+ || 1382 | | confUserID> | |Control |~~~>|"Carol"| || 1383 | |<--------------------------|Server | +-------+----+| 1384 | |CCP Response | | | | | 1385 +--------+ | | | V | 1387 | | | +---------+--+| 1388 | | | |policies | || 1389 | | |~~~>+---------+ || 1390 | | | | || 1391 | +-----------+ | || 1392 "Alice" | | Sidebar || 1393 +--------+ | | Reservation|| 1394 | |CCP Request | |~~~>| || 1397 | | confID,confUserID, | | | +------------+| 1398 | | video=parent, | | | | | 1399 | | audio=sidebar> | |Conference | | | 1400 | | | |Control | V | 1401 | | | |Server | +---------+--+| 1402 | |CCP Response | | | |policies | || 1403 | | | | | |Sidebar || 1406 | | | |Conference || 1407 | +-----------+ +-------+ || 1408 | |"Alice"| || 1409 "Bob" | | | || 1410 +--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ || 1411 | |<-------------------------|Notification|<~~~| | || 1412 | Client | ||Service | |"Bob" | || 1413 +--------+ || | +-------+----+| 1414 |+------------+ | 1415 +--------------------------------+ 1417 Figure 12: Client Creation of a Sidebar Conference 1419 Upon receipt of the Conference Control Protocol request to "reserve" 1420 a new sidebar conference, based upon the active conference received 1421 in the request, the conferencing system uses the received active 1422 conference to clone a conference reservation for the sidebar. As 1423 discussed previously, the sidebar reservation is NOT independent of 1424 the active conference (i.e., parent). The conferencing system also 1425 reserves or allocates a conference ID to be used for any subsequent 1426 protocol requests from any of the members of the conference. The 1427 conferencing system maintains the mapping between this conference ID 1428 and the conference object ID associated with the sidebar reservation 1429 through the conference instance. 1431 Upon receipt of the conference control protocol response to reserve 1432 the conference, "Alice" can now create an active conference using 1433 that reservation or create additional reservations based upon the 1434 existing reservations. In this example, "Alice" wants only "Bob" to 1435 be involved in the sidebar, thus she manipulates the membership. 1436 Alice also only wants the video from the original conference and 1437 wants the audio to be restricted to the participants in the sidebar. 1438 Alice sends a conference control protocol request to update the 1439 information in the reservation and to create an active conference. 1441 Upon receipt of the conference control protocol request to update the 1442 reservation and to create an active conference for the sidebar, as 1443 identified by the conference object ID, the conferencing system 1444 ensures that "Alice" has the appropriate authority based on the 1445 policies associated with that specific conference object to perform 1446 the operation. The conferencing system must also validate the 1447 updated information in the reservation, ensuring whether members like 1448 "Bob" are already a user of this conferencing system or whether he is 1449 a new user. If "Bob" is a new user for this conferencing system, a 1450 conference user identifier is created for Bob. Based upon the 1451 addressing information provided for "Bob" by "Alice", the call 1452 signaling to add "Bob" to the conference is instigated through the 1453 Focus. 1455 Depending upon the policies, the participants in the sidebar (i.e., 1456 "Bob") may be notified of his addition to the sidebar via the 1457 conference notification service. 1459 9.5. Whispering or Private Messages 1461 The case of private messages can be handled as a sidebar with just 1462 two participants, similar to the example in section Section 9.4, but 1463 rather than using audio within the sidebar, "Alice" could add an 1464 additional text based media stream to the sidebar. The other 1465 context, referred to as whisper, in this document refers to 1466 situations such as when a announcement server injects a message 1467 targetted to specific user(s). The details of this mechanism within 1468 the context of the framework are TBD. 1470 9.6. Conference Announcements and Recordings 1472 Each participant can require a different type of announcement and/or 1473 recording service from the system. For example, "Alice", the 1474 conference chair, could be listening to a roll call while "Bob" may 1475 be using a telephony user interface to create a sidebar. Some 1476 announcements would apply to all the participants such as "This 1477 conference will end in 10 minutes". Recording is often required to 1478 capture the names of participants as they join a conference, 1479 typically after the participant has entered an access code as 1480 discussed in Section 9.7. These recorded names are then announced to 1481 all the participants as the new participant is added to the active 1482 conference. 1484 An example of conference recording and announcements, along with 1485 monitoring for DTMF, within the context of this framework, is shown 1486 in figure [TBD]. 1488 9.7. Monitoring for DTMF 1490 The conferencing system also needs the capability to monitor for DTMF 1491 from each individual participant. This would typically be used to 1492 enter the identifier and/or access code for joining a specific 1493 conference. 1495 An example of DTMF monitoring, within the context of this framework, 1496 is shown in figure [TBD] in the previous section. 1498 9.8. Observing a Conference 1500 The capability to observe a conference allows a participant with the 1501 appropriate authority to listen to the conference, typically without 1502 being an active participant and often as a hidden participant. When 1503 such a capability is available on a conferencing system, there is 1504 often an announcement provided to each participant as they join the 1505 conference indicating the call may be monitored. This capability is 1506 useful in the context of conferences which might be experiencing 1507 technical difficulties, thus allowing a technician to listen in to 1508 evaluate the type of problem. This capability could also apply to 1509 call center applications as it provides a mechanism for a supervisor 1510 to observe how the agent is handling a particular call. Whether the 1511 agent is aware of when the supervisor joins the call should be 1512 configurable. 1514 An example of oberving a conference is shown in figure [TBD]. 1516 10. Relationships between SIPPING and Centralized Conferencing 1517 Frameworks 1519 The SIPPING Conferencing Framework [9] provides an overview of a wide 1520 range of centralized conferencing solutions known today in the 1521 conferencing industry. The document introduces a terminology and 1522 logical entities in order to systemize the overview and to show the 1523 common core of many of these systems. The logical entities and the 1524 listed scenarios in the SIPPING Conferencing Framework are being used 1525 to illustrate how SIP [4] can be used as a signaling means in these 1526 conferencing systems. SIPPING Conferencing Framework does not define 1527 new conference control protocols to be used by the general 1528 conferencing system. It uses only basic SIP [4], the SIP 1529 Conferencing for User Agents [15], and the SIPPING Conference Package 1530 [9] for basic SIP conferencing realization. 1532 This centralized conferencing framework document defines a particular 1533 centralized conferencing system and the logical entities implementing 1534 it. It also defines a particular data model and refers to the set of 1535 protocols (beyond call signaling means) being defined by the XCON WG 1536 to be used among the logical entities for implementing advanced 1537 conferencing features. The purpose of the XCON working group and 1538 this framework is to achieve interoperability between the logical 1539 entities from different vendors for controlling different aspects of 1540 advanced conferencing applications. 1542 The logical entities defined in the two frameworks are not intended 1543 to be mapped one-to-one. The two frameworks differ in the 1544 interpretation of the internal conferencing system decomposition and 1545 the corresponding operations. Nevertheless, the basic SIP [4], the 1546 SIP Conferencing for User Agents [15], and the SIPPING Conference 1547 Package [9] are fully compatible with both Framework documents. 1549 11. Security Considerations 1551 There are a wide variety of potential attacks related to 1552 conferencing, due to the natural involvement of multiple endpoints 1553 and the many, often user-invoked, capabilities provided by the 1554 conferencing system. Examples of attacks include the following: an 1555 endpoint attempting to listen to conferences in which it is not 1556 authorized to participate, an endpoint attempting to disconnect or 1557 mute other users, and theft of service, by an endpoint, in attempting 1558 to create conferences it is not allowed to create. 1560 There are several issues surrounding security of this conferencing 1561 framework. One set of issues involves securing the actual protocols 1562 and the associated authorization mechanisms. This first set of 1563 issues should be addressed in the specifications specific to the 1564 protocols described in Section 8. The protocols used for 1565 manipulation and retrieval of confidential information MUST support a 1566 confidentiality and integrity mechanism. Similar requirements apply 1567 for the floor control protocols. Section 11.3 discusses an approach 1568 for client authentication of a floor control server. 1570 There are also security issues associated with the authorization to 1571 perform actions on the conferencing system to invoke specific 1572 capabilities. Section 5.3 discusses the policies associated with the 1573 conference object to ensure that only authorized entities are able to 1574 manipulate the data to access the capabilities. The final set of 1575 issues involves the privacy and security of the identity of a user in 1576 the conference, which is discussed in Section 11.2 1578 11.1. Authorization 1580 Many policy authorization decisions are based on the identity of the 1581 user or the role that a user may have. There are several ways that a 1582 user might authenticate its identity to the system. The conferencing 1583 system may know about specific users and assign passwords to the 1584 users. The users may also be authenticated by knowing a particular 1585 conference ID and a PIN for it. Sometimes, a PIN is not required and 1586 the conference ID is used as a shared secret. The call signaling 1587 means can provide a trusted form of the user identity or it might 1588 just provide a hint of the possible identity and the user still needs 1589 to provide some authentication to prove it has the identity that was 1590 provided as a hint in the call signaling. This may be in the form of 1591 an IVR system or other means. The goal for the conferencing system 1592 is to figure out a user identity and a role for any attempt to send a 1593 request to the conferencing system. 1595 When a conferencing system presents the identity of authorized users, 1596 it may choose to provide information about the way the identity was 1597 proven or verified by the system. A user may also come as a 1598 completely unauthenticated user into the system - this fact needs 1599 also be communicated to interested parties. 1601 When guest users interact with the system, it is often in the context 1602 of a particular conference. In this case, the user may provide a PIN 1603 or a password that is specific to the conferences and authenticates 1604 the user to take on a certain role in that conference. The guest 1605 user can then perform actions that are allowed to any user with that 1606 role. 1608 The term password is used to mean the usual, that is to say a 1609 reasonable sized, in number of bits, hard to predict shared secret. 1610 Today users often have passwords with more than 30 bits of randomness 1611 in them. PIN is a special password case - a shared secret that is 1612 only numeric and often contains a fairly small number of bits (often 1613 as few as 10 bits). When conferencing systems are used for audio on 1614 the PSTN, there is often a need to authenticate using a PIN. 1615 Typically if the user fails to provide the correct PIN a few times in 1616 a row, the PSTN call is disconnected. The rate of making the calls 1617 and getting to the point to enter a PIN makes it fairly hard to do an 1618 exhaustive search of the PIN space even for 4 digit PINs. When using 1619 a high speed interface to connect to a conferencing system, it is 1620 often possible to do thousands of attempts per second and the PIN 1621 space could quickly be searched. Because of this, it is not 1622 appropriate to use PINs for authorization on any of the interfaces 1623 that provide fast queries or many simultaneous queries. 1625 11.2. Security and Privacy of Identity 1627 This conferencing system has an idea of the identity of a user but 1628 this does not mean it can reveal this identity to other users, due to 1629 privacy considerations. Users can select various options for 1630 revealing their identity to other users. A user can be "hidden" such 1631 that other users can not see they are participants in the conference, 1632 or they can be "anonymous" such that users can see that another user 1633 is there, but not see the identity of the user, or they can be 1634 "public" where other users can see their identity. If there are 1635 multiple "anonymous" users, other parties will be able to see them as 1636 independent "anonymous" parties and will be able to tell how many 1637 "anonymous" parties are in the conference. Note, that the visibility 1638 to other participants is dependent on their roles. For example, 1639 users' visibility (including "anonymous" and "hidden") may be 1640 displayed to the moderator or administrator, subject to a 1641 conferencing system's local policies. "Hidden" status is often used 1642 by automated or machine participants of a conference (e.g., call 1643 recording) and is also used in many call center situations. 1645 11.3. Floor Control Server Authentication 1647 Clients can authenticate a floor control server using the TLS 1648 certificates. Requests submitted on a successfully created 1649 connection between the client and floor control server may 1650 additionally require digest authentication within the BFCP protocol 1651 to authenticate the floor control client to the server. For this to 1652 take place, a shared secret needs to be exchanged between the floor 1653 control client/server entities. This can be achieved out of band 1654 using a mechanism such as the 'k=' SDP attribute. The shared secret 1655 can also be exchanged using un-specified 'out of band' mechanisms. 1657 When using Digest authentication of floor control client messages the 1658 exchange of an active 'Nonce' is also required. This can be achieved 1659 using a BFCP request response interaction as defined in BFCP (A 1660 request is submitted without a Nonce TLV and the server generates an 1661 error response with either an Error Code 7 (DIGEST TLV Required) or 6 1662 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 1663 can also be obtained 'out of band' using information provided in the 1664 offer/answer exchange. As with the other SDP Floor attributes 1665 referenced in this section and defined in [23], the 'nonce' attribute 1666 can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. 1668 [Editor's Note: May need more specifics on fetching from the 1669 conference object the credentials required for BFCP. This includes 1670 the conference id, user id, and password.] 1672 12. IANA Considerations 1674 This is an informational draft, with no IANA considerations required. 1676 13. Acknowledgements 1678 This document is a result of architectural discussions among IETF 1679 XCON working group participants. The authors would like to thank 1680 Henning Schulzrinne for the "Conference Object Tree" proposal and 1681 general feedback, Cullen Jennings for providing input for the 1682 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 1683 Novo, Roni Even, Umesh Chandra, Avshalom Houri and Sean Olson for 1684 their reviews and constructive input. 1686 14. Changes since last Version 1688 Changes from WG 03 to 04: 1690 - Editorial nits and clarifications. 1692 - Section 4. Template: Removed reference to "user interface 1693 abstractions". 1695 - Section 5.2. Conference Template: deleted references to user 1696 interface abstraction (1st paragraph, last phrase and 4th paragraph). 1698 - Section 9.6. Conference Announcements and Recording: text 1699 expanded. Moved discussion of DTMF to a new section. 1701 - Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), 1702 with some initial text. 1704 Changes from WG 02 to 03: 1706 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 1708 - Added definition for Sidebar. 1710 - Section 5.2 Added text indicating that adding new elements or 1711 modifying elements requires the definition of a new template. (per 1712 DP4.2 conclusion). 1714 - Section 7.3. Added text reiterating that the blueprint comprises 1715 both the common conference information and a template (per DP4/4.1 1716 discussions. 1718 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 1719 blueprint is common conference information + one template and that 1720 multiple templates is FFS. 1722 - Section 8.3 - Updated Conference Control Protocol section to 1723 include the protocols on the table for WG discussion as of 31 Dec 1724 2005 deadline. 1726 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 1728 - Section 9.5 - Whisper - Added some text, reflecting past WG 1729 discussions. Basic definition and further details/example still 1730 needed. 1732 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 1733 Further details/example still needed. 1735 Changes from WG 01 to 02: 1737 - Editorial nits -i.e. consistent terminology, capatilization, etc. 1739 - Revamped abstract and introduction 1741 - Global removal of XCON as a qualifier (we had previously done this 1742 in a previous version with all the identifiers). 1744 - Global change of "call control signalling" to "call signaling" 1746 - Moved the terminology section after the Overview section: 1748 - - Modified the definitions to be more concise and per some of 1749 Henning's recommendations. 1751 - - Added definitions for blueprint and conference reservation. 1753 - Clarified the definition of policy and added more explicit text as 1754 to how policy is accomplished via the data model and system 1755 realization (section 4.3 and 6.1) 1757 - Removed the Editor's note/text in section 4 about the options for 1758 the schema; added a reference to a TBD schema document. 1760 - Section 5: 1762 - - clarified the identifiers. Kept the logical definition as 1763 "identifiers", although most will be realized as URIs. 1765 - - deleted the section on conference instance. 1767 - - removed the term "umbrella" from sections conference User and 1768 conference object identifier sections 1770 - - moved alot of detail from Conference User Identifier and 1771 conference Object Identifier sections into appendices, and added 1772 additional detail, that will become the basis for separate documents. 1774 - In section 6: 1776 - - added a bit of explanation as to the intent of the cloning tree 1777 model - it's not implementation binding, but rather to illustrate the 1778 data model and context for the protocol interactions. 1780 - - removed the term copying altogether. Cloning is the model and 1781 the idea is that the cloned object contains data indentical to the 1782 parent when it was created (whether it gets "copied" or whatever from 1783 the parent is an implementation issue). 1785 - - introduce the blueprint concept in section 6.1 prior to its 1786 implied usage in 6.2 and 6.3. 1788 - - removed the usage of the term occurrence (which is just a child 1789 reservation). 1791 - Removed security related details from Floor Control section and 1792 moved those to the security section. As a result removed most of the 1793 editorial notes from the front of the Floor control section and 1794 integrated the remaining ones inline into that section, where the 1795 resolution should be documented. 1797 - Section 8: 1799 - - Added new example 8.1 - conference creation 1801 - - Added a placeholder for a more detailed example to the sidebar 1802 section to show a sidebar which has some media specifically 1803 associated with the sidebar (i.e. audio), yet still use the main 1804 conference for other media (visual presentation). 1806 - Section 11: As a result of adding additional information to the 1807 security section, divided this section into subsections for clarity. 1809 Changes from WG 00 to 01:: 1811 - Section 2 (Conventions and Terminology). Slight modifications to 1812 definitions of Call (control) signaling, Conference Identifer, 1813 Conference Instance, Conference Object. 1815 - Section 2 (Conventions and Terminology).Renaming of term 1816 "Registered Template Definition" to "Registered Conference Document" 1817 (per agreement at interim meeting). 1819 - Section 3 (Next to the last paragraph on the media model). 1820 Clarified the text such that it doesn't read that the focus performs 1821 media mixing. Changed "focus" to "media mixer controlled by the 1822 focus" in the 2nd sentence and "performed" to "controlled" in the 1823 4th. 1825 - Section 5. Rearranged the sub-sections a bit for better flow. 1826 First describe the Conference ID, then the Conference Instance, 1827 followed by the Conference Object, with the Conference Object 1828 Identifer described in a subsection of the Conference Object section. 1829 Added a diagram showing the relationship between Conference 1830 Identifer/Focus and Conference Object Identifier, within the context 1831 of a Conference Instance to the Conference Object section. 1833 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 1834 apply to independent objects (and non-independent). 1836 - Section 6.3 (Advanced Example). Added additional text with regards 1837 to future conferences, introducing the concept of infinite series 1838 (which would be limited by calendaring interface). 1840 - Section 7.3 (Conference Control Protocol). Updated to include 1841 reference to SOAP option. 1843 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 1844 about the XCON FW constructs used. 1846 Changes from individual 02 to WG 00: 1848 - few minor editorial changes 1850 - Section 2. Removed second sentence of definition of Conference ID, 1851 as that's now included/described in context in new Identifier 1852 section. 1854 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 1855 Protocol" (per Keith's comment to be more explicit). 1857 - Section 4.1. Identifiers. Moved this to a new section ( 1858 Section 6). 1860 - New section for Identifiers ( Section 6), thus all section 1861 references beyond 4 are incremented in the new version. 1863 - Section 4. Since section 4.1 was removed, section 4.2 became the 1864 body text for section 4. 1866 - Section 4.2. Added "Floor Information" to Figure 2 as part of 1867 Common Conference Information, also added "Floor Control" to 1868 Conference Template (per text and Cullen's draft). 1870 - Section 4.5. Conference policies. Reworded to not introduce new 1871 terms, but use the general terms identified in the 1st paragraph. 1873 - Section 5.2. Removed "Instance" from "Active Conference Instance" 1874 in Figure 4. 1876 - Section 5.3. Added text clarifying that templates are retrieved 1877 from server (not central repository) (per DP3 conclusion). 1879 - Section 5.4. Added text that there is a single time and that the 1880 times are all relative the one time (per DP1 conclusion). 1882 - Section 5.4. Added text clarifying that changes to a series impact 1883 "all future occurrences (per DP1 discussion/conclusion). 1885 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 1886 as the CCP. 1888 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 1889 Condensed the text only slightly, but added explicit references to 1890 new identifier section. 1892 - Section 6.4.1 Moved to new Identifier section ( Section 6) 1894 - Section 7.1 - moved example to 7.2. Included a new (more 1895 appropriate example) in 7.1, although this may be too basic. 1897 - Section 7.3 - added some proposed text for Sidebars. 1899 15. Appendix A - Conference Object Identifier 1901 [Editors Note: This appendix will be incorporated in a separate 1902 specification in the next release of this document and will include 1903 all relevant detail.] 1905 The conference object URI can be viewed as a key to accessing a 1906 specific conference object. It is used by the Conference Control 1907 Protocol as described in Section 8.3 to access, manipulate and delete 1908 a conference object associated with a specific conference instance. 1909 A conference object identifier is provided to the Conference Control 1910 Client to enable such functions to be carried out. This can either 1911 be returned through the Conference Control Protocol while creating a 1912 conference object, be provided by the conference notification service 1913 or through out-of-band mechanisms (e.g. E-Mail). 1915 [Editors Note: Previous section to be expanded and more detail 1916 included. It also needs to link up with other drafts and explicitly 1917 reference.] 1919 A centralized conferencing system, as defined in the Conference 1920 Framework [ref] has potential to expose a range of interfaces and 1921 protocols. It is also possible that future centralized conferencing 1922 enhancements might place requirements to provide further additional 1923 protocols and interfaces. A conference object can consist and be 1924 associated with many identifiers that are in some way related to a 1925 conference object. Good examples include the Binary Floor Control 1926 Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each 1927 use unique identifiers to represent a protocol instance associated 1928 with a conference object. 1930 A conferencing system may maintain a relationship between the 1931 conference object URIs and the identifiers associated with each of 1932 the complementary centralized conferencing protocols (e.g., CSP, 1933 BFCP, etc.). To facilitate the maintenance of these relationships, 1934 the conference object URI acts as a top level identifier within the 1935 conferencing system for the purpose of identifying the interfaces for 1936 these other protocols. This implicit binding provides a structured 1937 mapping of the various protocols with the associated conference 1938 object identifier. Figure 13 illustrates the relationship between 1939 the identifiers used for the protocols within this framework and the 1940 general conference object identifier. 1942 +--------------+ 1943 | Conference | 1944 | Object | 1945 | Identifier | 1946 +------+-------+ 1947 | 1948 | 1949 | 1950 +-----------------+---------------+ 1951 | | 1952 +-------+---------+ +-------+-------+ 1953 |CSP Conference ID| | BFCP 'confid' | 1954 +-----------------+ +---------------+ 1956 Figure 13: Conference Object Mapping. 1958 In Figure 13, the conference object identifier acts as the top level 1959 key in the identification process. The call signaling protocols have 1960 an associated conference ID representation in the form of URIs. The 1961 binary floor control protocol, as defined in [23], defines the 1962 'conf-id' identifier which represents a conference instance within 1963 floor control. When created within the conferencing system, the 1964 'conf-id' has a 1:1 mapping to the unique conference object 1965 Identifier. Operations associated with the Conference Control 1966 Protocols are directly associated with the conference object, thus 1967 the primary identifier associated with these protocols is the 1968 conference object identifier. The mappings between additional 1969 protocols/interface is not strictly 1:1 and does allow for multiple 1970 occurrences. For example, multiple call signaling protocols will 1971 each have a representation that is implicitly linked to the top level 1972 conference object identifier, for example, H323 and SIP URIs that 1973 represent a conference instance. It should be noted that a 1974 conferencing system is free to structure such relationships as 1975 required and this information is just included as a guideline that 1976 can be used. 1978 The following example illustrates the representation and 1979 relationships that might occur in a typical conference instance. The 1980 table in Figure 14 lists a typical conference instance and related 1981 properties. 1983 +----------------------+------------------------+----------------------+ 1984 | Conf Obj URI | CSP URI | BFCP Conf-ID | 1985 +----------------------+------------------------+----------------------+ 1986 | confid:Ji092i | sip:Ji092i@example.com | Ji092i | 1987 | | tel:+44(0)2920930033 | | 1988 | | h323:Ji092i@example.com| | 1989 +----------------------+------------------------+----------------------+ 1991 Figure 14: Conference Table Representation 1993 The information from Figure 14 can then be applied to the 1994 representation introduced in Figure 13. This results in Figure 15. 1996 +--------------+ 1997 | Conference | 1998 | Object | 1999 | Identifier | 2000 +--------------+ 2001 | xcon:Ji092i | 2002 +------+-------+ 2003 | 2004 | 2005 | 2006 +-----------------+---------------+ 2007 | | 2008 +-----------+-----------+ +-------+-------+ 2009 | CSP Conference IDs | | BFCP 'confid' | 2010 +-----------------------+ +---------------+ 2011 |h323:Ji092i@example.com| | Ji092i | 2012 |tel:+44(0)2920930033 | +-------+-------+ 2013 |sip:Ji092i@example.com | | 2014 +-----------------------+ +-------|-------+ 2015 | BFCP 'floorid | 2016 +---------------+ 2017 | UEK78d | 2018 | 09cnJk | 2019 +---------------+ 2021 Figure 15: Conference Tree Representation 2023 Further elements can be added to the tree representation in Figure 15 2024 to enable a complete representation of a conference instance within a 2025 conferencing system. 2027 This style of association can be applied to any supplementary 2028 protocols or conferencing mechanisms that are applied to the 2029 centralized conferencing model defined in this document as long as a 2030 unique reference per conference instance is available that can be 2031 mapped to a conference object. 2033 15.1. Conference Object URI Definition 2035 [Editors Note: When the appendix split from the Framework document, 2036 full URI definition will be included. 2038 16. Appendix B - Conference User Identifier 2040 [Editors Note: This appendix will be incorporated in a separate 2041 specification in the next release of this document and will include 2042 all relevant detail.] 2044 Each user within a conferencing system is allocated a unique 2045 conference user identifier. The user identifier is used in 2046 association with the conference object identifier defined in 2047 Section 15, and by the conference control protocol to uniquely 2048 identify a user within the scope of conferencing system. The 2049 conference control protocol uses the user identifier to uniquely 2050 determine who is issuing commands. Appropriate policies can then be 2051 applied to the requested command. 2053 As with the conference object identifier, a number of supplementary 2054 user identifiers defined in other protocols are used within a 2055 conference instance. Such user identifiers can be associated with 2056 this conference user identifier and enable the conferencing system to 2057 correlate and map these multiple authenticated user identities to the 2058 single user identifier. 2060 Figure 16 illustrates an example using the conference user identifier 2061 in association with the user identity defined for BFCP and SIP Digest 2062 user identity as defined in RFC3261[4], which would be used when SIP 2063 is the call signaling protocol. It should be noted that a 2064 conferencing system is free to structure such relationships as 2065 required and this information is just included as a guideline that 2066 can be used. 2068 +---------------+ 2069 | Conference | 2070 | User | 2071 | Identifier | 2072 +-------+-------+ 2073 | 2074 | 2075 | 2076 +---------------+---------------+ 2077 | | 2078 +-------+-------+ +-------+-------+ 2079 | BFCP | | SIP Digest | 2080 | 'UserID' | | Username | 2081 +---------------+ +-------+-------+ 2083 Figure 16: Conference User Identifier 2085 Within a conferencing system, a user is identified by a single 2086 conference user identifier. Any additional conferencing mechanisms 2087 that contain a protocol specific user ID can be associated with the 2088 conference user identifier, as illustrated in Figure 16. This 2089 mechanism allows conferencing systems to manage and relate system 2090 wide user identities in relation to specific conference objects and 2091 helps in the enforcement of system wide policies. 2093 The following example illustrates the representation and 2094 relationships that might occur in a typical conference instance. The 2095 table in Figure 17 lists a typical representation of user identifier 2096 hierarchy and associations. 2098 +----------------+----------------+---------------+----------------+ 2099 | Conf User ID | BFCP User ID | SIP User ID | H323 User ID | 2100 +----------------+----------------+---------------+----------------+ 2101 | John | HK37ihdaj | 123674 | 928373 | 2102 +----------------+----------------+---------------+----------------+ 2104 Figure 17: User Identitier Representation 2106 The information from Figure 17 can then be applied to the 2107 representation introduced in Figure 16. This results in Figure 18. 2109 +--------------+ 2110 | Conference | 2111 | User | 2112 | Identifier | 2113 +--------------+ 2114 | John | 2115 +------+-------+ 2116 | 2117 | 2118 | 2119 +---------------------+---------------------+ 2120 | | | 2121 +-------+--------+ +-------+-------+ +--------+-------+ 2122 | BFCP User ID | | SIP User ID | | H323 User ID | 2123 +----------------+ +---------------+ +----------------+ 2124 | HK37ihdaj | | 123674 | | 928373 | 2125 +----------------+ +-------+-------+ +----------------+ 2127 Figure 18: User ID Tree Representation 2129 Further elements can be added to the tree representation in Figure 15 2130 to enable a complete representation of a conference instance within a 2131 conferencing system. 2133 16.1. Conference User Definition 2135 [Editors Note: When the appendix is split from the Framework 2136 document, full definition will be included. 2138 17. References 2140 17.1. Normative References 2142 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2143 Levels", BCP 14, RFC 2119, March 1997. 2145 17.2. Informative References 2147 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2148 Protocol", RFC 2327, April 1998. 2150 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2151 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2152 August 1998. 2154 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2155 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2156 Session Initiation Protocol", RFC 3261, June 2002. 2158 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2159 Session Description Protocol (SDP)", RFC 3264, June 2002. 2161 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2162 Notification", RFC 3265, June 2002. 2164 [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2165 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2166 RFC 3550, July 2003. 2168 [8] Dawson, F. and Stenerson, D., "Internet Calendaring and 2169 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2170 November 1998. 2172 [9] Rosenberg, J., "A Framework for Conferencing with the Session 2173 Initiation Protocol", 2174 draft-ietf-sipping-conferencing-framework-05 (work in 2175 progress), May 2005. 2177 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 2178 Coupled SIP Conferencing", 2179 draft-ietf-sipping-conferencing-requirements-01 (work in 2180 progress), October 2004. 2182 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2183 Package for Conference State", 2184 draft-ietf-sipping-conference-package-12 (work in progress), 2185 July 2005. 2187 [12] Schulzrinne, H., "Requirements for Floor Control Protocol", 2188 draft-ietf-xcon-floor-control-req-03 (work in progress), 2189 October 2005. 2191 [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference 2192 Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in 2193 progress), August 2004. 2195 [14] Even, R. and N. Ismail, "Conferencing Scenarios", 2196 draft-ietf-xcon-conference-scenarios-05 (work in progress), 2197 September 2005. 2199 [15] Levin, O., "Session Initiation Protocol Call Control - 2200 Conferencing for User Agents", 2201 draft-ietf-sipping-cc-conferencing-07 (work in progress), 2202 June 2005. 2204 [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 2205 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 2207 [17] Schulzrinne, H., "COMP: Conference Object Manipulation 2208 Protocol", draft-schulzrinne-xcon-comp-00 (work in progress), 2209 January 2006. 2211 [18] Boulton, C. and M. Barnes, "Centralized Conferencing 2212 Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in 2213 progress), January 2006. 2215 [19] Levin, O., "Centralized Conference Control Protocol", 2216 draft-levin-xcon-cccp-04 (work in progress), January 2006. 2218 [20] Jennings, C. and B. Rosen, "Media Conference Server Control for 2219 XCON", draft-jennings-xcon-media-control-03 (work in progress), 2220 July 2005. 2222 [21] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", 2223 draft-rosen-xcon-conf-sidebars-01 (work in progress), 2224 July 2004. 2226 [22] Levin, O. and G. Camarillo, "The SDP (Session Description 2227 Protocol) Label Attribute", 2228 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 2229 January 2005. 2231 [23] Camarillo, G., "Session Description Protocol (SDP) Format for 2232 Binary Floor Control Protocol (BFCP) Streams", 2233 draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), 2234 October 2004. 2236 [24] Campbell, B., "The Message Session Relay Protocol", 2237 draft-ietf-simple-message-sessions-14 (work in progress), 2238 February 2006. 2240 [25] Jennings, C., "Conference State Change Protocol (CSCP)", 2241 draft-jennings-xcon-cscp-02 (work in progress), December 2005. 2243 [26] Enns, R., "NETCONF Configuration Protocol", 2244 draft-ietf-netconf-prot-12 (work in progress), March 2006. 2246 Authors' Addresses 2248 Mary Barnes 2249 Nortel 2250 2201 Lakeside Blvd 2251 Richardson, TX 2253 Email: mary.barnes@nortel.com 2255 Chris Boulton 2256 Ubiquity Software Corporation 2257 Building 3 2258 Wern Fawr Lane 2259 St Mellons 2260 Cardiff, South Wales CF3 5EA 2262 Email: cboulton@ubiquitysoftware.com 2264 Orit Levin 2265 Microsoft Corporation 2266 One Microsoft Way 2267 Redmond, WA 98052 2269 Email: oritl@microsoft.com 2271 Intellectual Property Statement 2273 The IETF takes no position regarding the validity or scope of any 2274 Intellectual Property Rights or other rights that might be claimed to 2275 pertain to the implementation or use of the technology described in 2276 this document or the extent to which any license under such rights 2277 might or might not be available; nor does it represent that it has 2278 made any independent effort to identify any such rights. Information 2279 on the procedures with respect to rights in RFC documents can be 2280 found in BCP 78 and BCP 79. 2282 Copies of IPR disclosures made to the IETF Secretariat and any 2283 assurances of licenses to be made available, or the result of an 2284 attempt made to obtain a general license or permission for the use of 2285 such proprietary rights by implementers or users of this 2286 specification can be obtained from the IETF on-line IPR repository at 2287 http://www.ietf.org/ipr. 2289 The IETF invites any interested party to bring to its attention any 2290 copyrights, patents or patent applications, or other proprietary 2291 rights that may cover technology that may be required to implement 2292 this standard. Please address the information to the IETF at 2293 ietf-ipr@ietf.org. 2295 Disclaimer of Validity 2297 This document and the information contained herein are provided on an 2298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2300 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2301 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2302 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2305 Copyright Statement 2307 Copyright (C) The Internet Society (2006). This document is subject 2308 to the rights, licenses and restrictions contained in BCP 78, and 2309 except as set forth therein, the authors retain all their rights. 2311 Acknowledgment 2313 Funding for the RFC Editor function is currently provided by the 2314 Internet Society.