idnits 2.17.1 draft-barnes-xcon-framework-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1590. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 132 has weird spacing: '...r) and the...' == Line 179 has weird spacing: '...ons and limit...' == Line 426 has weird spacing: '...ased on the C...' == Line 538 has weird spacing: '...ons and limit...' == Line 592 has weird spacing: '...etailed in Se...' == (10 more instances...) == 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 (February 14, 2005) is 7011 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 904 == Unused Reference: '3' is defined on line 1450, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1527, 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 (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-08 == Outdated reference: A later version (-05) exists of draft-ietf-xcon-conference-scenarios-02 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-06 == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-03 == Outdated reference: A later version (-04) exists of draft-levin-xcon-cccp-01 == Outdated reference: A later version (-03) exists of draft-jennings-xcon-media-control-01 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-09 Summary: 6 errors (**), 0 flaws (~~), 21 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON Working Group M. Barnes 2 Internet-Draft Nortel 3 Expires: August 18, 2005 C. Boulton 4 Ubiquity Software Corporation 5 O. Levin 6 Microsoft Corporation 7 February 14, 2005 9 A Framework and Data Model for Centralized Conferencing 10 draft-barnes-xcon-framework-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document defines the framework for Centralized Conferencing 46 (XCON), which is applicable to participants using different call 47 control signaling protocols and exchanging media over networks with 48 potentially different characteristics. The XCON Framework defines 49 the XCON data model, the XCON logical entities, the naming 50 conventions, and outlines the standard conferencing protocols 51 (complementary to the call control signalling protocols) for building 52 advanced conferencing applications. The framework binds all the 53 defined components together for the benefit of conferencing system 54 builders. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. XCON Data Model and Identifiers . . . . . . . . . . . . . . . 8 62 4.1 Conference Object Identifiers . . . . . . . . . . . . . . 9 63 4.2 Conference Object Type . . . . . . . . . . . . . . . . . . 10 64 4.3 Common Conference Information . . . . . . . . . . . . . . 11 65 4.4 Conference Template . . . . . . . . . . . . . . . . . . . 12 66 4.5 Conference policies . . . . . . . . . . . . . . . . . . . 12 67 5. Conferencing System Realization . . . . . . . . . . . . . . . 13 68 5.1 Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.2 Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 16 70 5.3 Advanced Example . . . . . . . . . . . . . . . . . . . . . 17 71 5.4 Scheduling a 'Conference Object for Reservation' . . . . . 19 72 6. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 22 73 6.1 Call Control Signalling . . . . . . . . . . . . . . . . . 22 74 6.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 22 75 6.3 Conference Control Protocols . . . . . . . . . . . . . . . 23 76 6.3.1 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 6.3.2 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 6.4 Floor Control . . . . . . . . . . . . . . . . . . . . . . 24 79 6.4.1 User Identifier . . . . . . . . . . . . . . . . . . . 26 80 7. Conferencing Scenario Realizations . . . . . . . . . . . . . . 27 81 7.1 Participant Manipulations . . . . . . . . . . . . . . . . 27 82 7.2 Media Manipulations . . . . . . . . . . . . . . . . . . . 29 83 7.3 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 29 84 7.4 Whispering or Private Messages . . . . . . . . . . . . . . 29 85 7.5 Conference Announcements and Recordings . . . . . . . . . 29 86 8. Relationships between SIPPING and XCON Frameworks . . . . . . 29 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 12.1 Normative References . . . . . . . . . . . . . . . . . . . 32 92 12.2 Informative References . . . . . . . . . . . . . . . . . . 32 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 94 Intellectual Property and Copyright Statements . . . . . . . . 36 96 1. Introduction 98 This document defines the framework for Centralized Conferencing 99 (XCON), which is applicable to participants using various call 100 signalling protocols (such as SIP, H.323, Jabber, HTML, PSTN, etc.) 101 and exchanging media over networks with potentially different 102 characteristics. 104 The XCON Framework defines the XCON data model, the XCON logical 105 entities, the naming conventions, and outlines the standard 106 conferencing protocols (complementary to the call control signalling 107 protocols) for building advanced conferencing applications. The 108 framework binds all the defined components together for the benefit 109 of conferencing system builders. 111 The XCON Framework is compatible with the functional model presented 112 in the SIPPING Conferencing Framework [9] . Section 8 of this 113 document discusses the relationship between the XCON Framework and 114 the SIPPING Conferencing framework, in the context of the XCON 115 architecture. 117 2. Conventions and Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 121 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 122 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 123 compliant implementations. 125 The XCON Framework document both generalizes, when appropriate, the 126 SIPPING Conferencing Framework [9] terminology and introduces new 127 concepts as listed below. 129 Active Conference: The term Active Conference refers to a Conference 130 Object that's been created (for example, using a "blueprint") and 131 "activated" via the allocation of its identifiers (i.e. 132 Conference Object Identifier, Conference Identifier) and the 133 associated Focus. 134 Call (Control) Signalling: The protocol used between a participant 135 and a Focus. In this context, the term "call" means a channel or 136 session used for media streams establishment. Protocol examples 137 include SIP, H.323, MSRP, Jabber, HTML and PSTN signalling. This 138 interface is not limited to the listed protocols, however, other 139 than references to general functionality required (e.g. 140 establishment and teardown), details of these protocols are 141 outside the scope of this document. 143 Common Conference Information: The data type (i.e. the XML schema) 144 which is used to represent the fixed information part of a 145 Conference Object. It includes a common set of definitions for 146 basic conference features, such as conference identifiers, 147 membership, signalling, capabilities, media, etc. 148 Conference Control Protocol (CCP): A protocol used by clients to 149 manipulate a Conference Object [Section 6.3]. 150 Conference Factory: A logical entity that, upon request, generates 151 unique URI(s) to identify and represent a conference Focus. The 152 Conference Factory is typically used in the conference creation 153 process via a signalling interface and non-signalling methods such 154 as Conference Control Protocol [Section 6.3] and proprietary 155 mechanisms. 156 Conference Identifier(ID): The call signalling protocol-specific URI 157 that uniquely identifies a Conference Instance and a conference 158 Focus. Note that a Conference Instance can have more than a 159 single Conference Identifier, for example, for each call 160 signalling protocol supported. 161 Conference Instance: Represents the internal implementation of a 162 conference; addressable using the Conference Identifier. There is 163 a one-to-one mapping between a Conference Instance and a 164 conference Focus. 165 Conference Object: A Conference Object is a logical representation of 166 a Conference Instance at a certain stage (e.g. description upon 167 conference creation, reservation, activation, etc.), which a 168 Conferencing System maintains in order to describe the system 169 capabilities and to provide access to the available services 170 provided by the Conferencing System. All Conference Objects are 171 of type 'Conference Object Type' which is comprised of two 172 distinct sub components; the 'Common Conference Information' and 173 the 'Conference Template' (see definitions in this section for 174 details). 175 Conference Object Identifier (ID): A [TBD schema name] URI which 176 uniquly identifies a Conference Object and is being used by a Call 177 Control Protocol [Section 6.3]. 178 Conference policies: A term which is used to collectively refer to a 179 virtual set of rights, permissions and limitations pertaining to 180 operations being performed on a certain Conference Object. The 181 term is described in more details in Section 4.5. 182 Conference State: The state of a Conference Instance as represented 183 using the Conference Package mechanism defined in [11]. 184 Conferencing System: The term used to refer to a conferencing 185 solution (system) that is based on the set of specifications and 186 is built using the protocols and the data model defined by the 187 XCON working group within the IETF. 189 Conference Template: The data type (i.e. the XML schema) which used 190 to represent the variable information part of the Conference 191 Object. It can be included in the Conference Object to represent 192 enhanced conferencing capabilities (e.g. media mixers, etc.) 193 and/or user interface abstraction. 194 Floor: A term which is used to refer to a set of data or resources 195 associated with a Conference Instance, for which a conference 196 participant (or group of participants) is granted temporary input 197 access. 198 Floor Chair: A Floor control protocol compliant client (human 199 participant or automated entity) who is authorized to manage 200 access to one floor (grants, denies, or revokes a floor). The 201 floor chair does not have to be a participant in the Conference 202 Instance. 203 Focus: Focus is a logical entity that maintains the call signalling 204 interface between each participating client (i.e. participant) 205 and the Conference Instance. As such, the Focus acts as an 206 endpoint for each of the supported signalling protocols and is 207 responsible for all primary conference membership operations (e.g. 208 join, leave, update the Conference Instance) and for media 209 negotiation/maintenance between a conference participant and the 210 Focus. There is a one-to-one mapping between the Focus and its 211 Conference Instance. Focus is addressed by explicitly associated 212 unique conference URIs for each signalling protocol, supported for 213 its Conference Instance. 214 Media Graph: The logical representation of the flow of media for a 215 conference. 216 Media Mixer: A logical entity that has the capability to combine 217 media inputs of the same type (or/and transcode the media) and 218 distribute the result(s) to a single or multiple outputs. In this 219 context, the term "media" means any type of data being delivered 220 over the network using appropriate transport means, such as 221 RTP/RTCP (defined in RFC 3550[7]), Message Session Relay Protocol 222 (defined in [25]), etc. 223 Registered Template Definition: 'Registered Template Definition' is 224 the term used to refer to an official standards document (RFC) 225 that defines and registers a Conference Template schema with the 226 appropriate standards body (IANA). A 'Registered Template 227 Definition' also includes any complimentary textual information in 228 relation to the conference template schema and its meaning. 229 Role: Represents differing membership categories that a conference 230 participant can assume within a conference. Each category has a 231 difference set of conference operations that a participant can 232 perform. A default (e.g. Standard Conference Participant) 'Role' 233 will always exist which provides a standard user with a set of 234 basic conference operations. Any user with appropriate 235 authentication and authorization may assume a role that has a 236 wider set of conference operations that are otherwise not 237 available (to a standard Conference Participant) - e.g. A 'Role' 238 called 'Conference Moderator' may exist that has additional 239 conference operations such as 'modify conference end time'. 240 Sidebar: TBD. 241 Whisper: TBD. 243 3. Overview 245 A centralized conference is an association of endpoints (called 246 conference participants) with a central endpoint (called a conference 247 Focus) where the Focus has direct peer-wise relationships with the 248 participants by maintaining a separate call control signalling 249 interface with each. Consequently, in this tightly coupled model, 250 the call control signalling graph is always a star. 252 The most basic conference supported would be an ad-hoc unmanaged 253 conference, which would not necessarily require any of the 254 functionality defined within this framework. For example, it could 255 be supported with basic SIP signalling functionality with a 256 participant serving as the Focus; the SIPPING Conferencing Framework 257 [9] together with the SIP Call Control Conferencing for User 258 Agents[15] documents address these types of scenarios. 260 An XCON-compliant Conferencing System, in addition to the basic 261 features, can offer richer functionality including dedicated 262 conferencing applications with explicitly defined capabilities, 263 reserved reoccurring conferences, and the standard protocols for 264 managing and controlling different conference aspects. 266 The core requirements for tightly managed centralized conferencing 267 are outlined in [10]. These requirements are applicable for 268 conferencing systems using various call control signalling protocols, 269 not restricted to SIP alone. Additional conferencing requirements 270 are provided in [12], [13], and [14]. 272 The XCON architecture is built around a fundamental concept of a 273 Conference Object. A Conference Object is a logical representation 274 of a Conference Instance. For conference creation, a Conference 275 Object provides a "blueprint" representing the System Capabilities. 276 A conference object also provides the logical representation of a 277 conference during each of the various stages of a conference (e.g. 278 reservation, active, completed, etc.). A Conference Object is 279 accessible using XCON protocols (e.g. a Conference Control Protocol 280 [Section 6.3]. 282 A Conferencing System can support any subset of the conferencing 283 functions depicted in the Conferencing System logical decomposition 284 in Figure 1 and described in this document. Nevertheless, typically 285 advanced functions could not be implemented without implementing 286 others. For example, the Notification Service is an essential 287 component required for implementing almost any advanced functionality 288 and being used, among other things, for correlating of information 289 (such as list of participants with their media streams) between 290 otherwise distinct functions. 292 ...................................................................... 293 . Conferencing System . 294 . . 295 . +-----------------------------------------------------+ . 296 . | C O N F E R E N C E O B J E C T | . 297 . +-+---------------------------------------------------+ | . 298 . | C O N F E R E N C E O B J E C T | | . 299 . +-+---------------------------------------------------+ | | . 300 . | C O N F E R E N C E O B J E C T | | | . 301 . | | | | . 302 . | | |-+ . 303 . | |-+ . 304 . +-----------------------------------------------------+ . 305 . ^ ^ ^ | . 306 . | | | | . 307 . v v v v . 308 . +-------------------+ +--------------+ +-------+ +------------+ . 309 . | Conference Control| | Floor Control| |Foci | |Notification| . 310 . | Server | | Server | | | |Service | . 311 . +-------------------+ +--------------+ +-------+ +------------+ . 312 . ^ ^ ^ | . 313 ................|.................|...........|..........|............ 314 | | | | 315 |TBD |BFCP |SIP/ |SIP NOTIFY/ 316 | | |PSTN/ |Etc. 317 | | |H.323/ | 318 | | |T.120/ | 319 | | |Etc. | 320 ................|.................|...........|..........|............ 321 . V V V V . 322 . +----------------+ +------------+ +----------+ +------------+ . 323 . | Conference | | Floor | | Call | |Notification| . 324 . | Control | | Control | | Control | | Client | . 325 . | Client | | Client | | Client | | | . 326 . +----------------+ +------------+ +----------+ +------------+ . 327 . . 328 . Conferencing Client . 329 ...................................................................... 331 Figure 1: Conferencing System Logical Decomposition. 333 The media graph of a conference can be centralized, de-centralized, 334 or any combination of both and potentially differ per media type. In 335 the centralized case, the media sessions are established between the 336 focus and each one of the participants. In de-centralized (i.e. 337 distributed) case, the media graph is a (multicast or multi-unicast) 338 mesh among the participants. Consequently, the media processing 339 (e.g. mixing) can be performed either by the focus alone or by the 340 participants. The concepts in this framework document clearly map to 341 a centralized media model. They can also apply to the de-centralized 342 media case, however, the details of such are left for future study by 343 XCON charter. 345 Section 4 of this document describes the usage of the Conference 346 Object in more details. Section 5 of this document describes how a 347 Conferencing System is built using the defined data model and how the 348 Conference Object trees are maintained. Section 6 describes the 349 fundamental conferencing mechanisms and provides a high level 350 overview of the XCON protocols. Section 7 then provides realizations 351 of various conferencing scenarios, detailing the manipulation of the 352 Conference Objects using XCON defined protocols. Section 8 of this 353 document summarizes the relationship between the XCON Framework and 354 the SIPPING Conferencing Framework. 356 4. XCON Data Model and Identifiers 358 This section first provides details of the identifiers associated 359 with the XCON constructs (e.g. Conference Object and Conference 360 Instance). The constructs of the XCON Data Model are then described 361 in detail. 363 [Editor's Note: The exact XML schema of the Conference Object (i.e. 364 the organization of the Common Conference Information and the 365 Conference Template) is an open issue, which has been summarized as 366 the three potential alternatives below: 368 1. The top-level information is the template section, and it 369 contains a subsection that is the common conference information. 370 This has the advantage that the schema can all be well defined: 371 because the common conference information is known at the time the 372 template is developed, the appropriate schema definition can be 373 inserted into the template schema. The downside is that this setup 374 requires navigation of the template information to get to the common 375 information, which is likely to be manipulated most frequently. 377 2. The top-level information is the common conference information, 378 which contains the template information. This has the advantage that 379 clients don't even need to care about the template being used to 380 allow rendering and control over basic conference functionality(which 381 will suffice for many clients (e.g. those with limited screen). The 382 downside is that the common conference information schema must 383 include an extension point to allow new templates to hook into the 384 schema. This may make schema validation more difficult. 386 3. The template information and common conference information are 387 conveyed as two separate objects (e.g. using multipart MIME). This 388 provides the benefits of allowing completely separate schema, 389 straightforward schema validation, and easy access to the common 390 conference information. The downside is that any mechanism for 391 separating the schema is going to add some amount of protocol 392 complexity and the need for synchronization between the two data 393 objects. Note that it has been argued that it is increasingly 394 difficult to find a potential client of the XCON protocols that 395 doesn't already support multipart MIME). 397 The model put forth in this document is the result of the consensus 398 reached during the XCON second interim meeting in Boston and depicts 399 option 2 above. With slight adaptations it can also support option 400 3. ] 402 4.1 Conference Object Identifiers 404 In order to make a certain Conference Object accessible, the 405 Conferencing System allocates a unique URI for each distinct 406 Conference Object in the system. A Conference Control Protocol 407 [Section 6.3] can be used for manipulating a particular Conference 408 Object and for retrieving its state. 410 [Editor's Note: The URI schema name TBD and registered with IANA.] 412 A Conference Instance is an internal implementation of a conference, 413 which is accessible by call signalling means. A single Conference 414 Instance can be internally mapped to a single or multiple Conference 415 Objects; each of them accessible by a Call Control protocol. The 416 mapping details are an implementation decision and out of scope of 417 this framework. 419 There is a one-to-one mapping between a Conference Instance and a 420 conference Focus. The Focus is addressed by explicitly associating 421 unique conference URIs for each signalling protocol, supported for 422 its Conference Instance. The state of a Conference Instance may be 423 retrieved by a call signalling dependent mechanism. For example, 424 the the Conference Package mechanism [11] can be used for SIP. Note, 425 that in this case, the subscription to the state information is 426 performed based on the Conference Focus SIP URI. 428 [ Editor's Note: Do we need to add additional text here to officially 429 introduce "Conference Factory" as defined in Section 2 and referenced 430 in Section 5.2? ] 432 4.2 Conference Object Type 434 The XCON data model defined in this framework has no strict 435 separation between conference membership, conference media 436 information and the related policies (i.e. the capabilities and 437 limitations for each). This approach meets the requirement in many 438 conference control operations to enable synchronized access to the 439 conference policies as a whole, to the conference state as a whole, 440 and for receiving notifications about changes to either. 442 A Conference Object is of type 'Conference Object Type' which is 443 comprised of two distinct components: the 'Common Conference 444 Information Type' and the 'Conference Template Type', as illustrated 445 in Figure 2. Each of these types is a placeholder for including 446 potentially multiple sub-types. 448 +------------------------------------------------------+ 449 | C O N F E R E N C E O B J E C T T Y P E | 450 | | 451 | +--------------------------------------------------+ | 452 | | COMMON CONFERENCE INFORMATION TYPE | | 453 | | | | 454 | | +----------------------------------------------+ | | 455 | | | Conference Description | | | 456 | | +----------------------------------------------+ | | 457 | | +----------------------------------------------+ | | 458 | | | Membership (Roles, Capacity, Names) | | | 459 | | +----------------------------------------------+ | | 460 | | +----------------------------------------------+ | | 461 | | | Signaling (Protocol, Direction, Status) | | | 462 | | +----------------------------------------------+ | | 463 | | +----------------------------------------------+ | | 464 | | | Sidebars, Etc. | | | 465 | | +----------------------------------------------+ | | 466 | | | | 467 | +--------------------------------------------------+ | 468 | +--------------------------------------------------+ | 469 | | CONFERENCE TEMPLATE TYPE | | 470 | | | | 471 | | - Mixer algorithm, inputs, and outputs | | 472 | | - User Control Interface | | 473 | | - User's View | | 474 | | - Etc. | | 475 | +--------------------------------------------------+ | 476 | | 477 +------------------------------------------------------+ 479 Figure 2: Conference Object Type Decomposition. 481 Since, in an XCON-compliant system the same Conference Object Type is 482 used for representation of a conference for different purposes, such 483 as expressing Conferencing System capabilities, reserving 484 conferencing resources or reflecting the state of ongoing 485 conferences, each of the two components (i.e., the Common Conference 486 Iinformation and the Conference Template) is syntactically optional 487 to be included in a particular Conference Object. Section 5 488 describes the usage semantics of the Conference Objects. 490 4.3 Common Conference Information 492 The common conference information section contains the core 493 information that is utilized in any conference and can be abstracted 494 regardless of the specific conference media nature (e.g. the mixing 495 algorithms performed, the advanced floor control applied, etc.). 496 Typically, participants with read-only access to the conference 497 information would be interested in this common information only. 499 The basic common conference information can be represented using the 500 conference-info-type schema as defined in [11]. This schema contains 501 the definitions for representation of the Conference Object 502 capabilities, membership, roles, call control signalling and media 503 statuses relevant to different stages of the conference life-cycle. 505 New XCON specifications can extend the basic conference-info-type and 506 introduce additional schemas to be used within the common conference 507 information type placeholder. 509 4.4 Conference Template 511 The concept of a "Conference Template" is introduced to abstract the 512 complexity and the details of the "mixer" and other conferencing 513 features and to allow for easy user interface abstraction for 514 advanced Conferencing Systems. 516 Each Conference Template needs to be registered with IANA. The IANA 517 registration needs to point to an RFC having the text description of 518 the feature behavior and optionally the XML definition allowing the 519 feature presentation, configuration, and management. RFCs of this 520 kind are referred by XCON documents as a "Registered Template 521 Definitions". 523 Typically, a conference template would contain the information about 524 the specific media mixing details, the associated client roles and 525 the available floor controls. This information would allow 526 authorized clients to manipulate mixer's behavior and the resultant 527 distribution of the media to all or individual participants. By 528 doing so, a client can change its own state and/or state of other 529 participants in the conference. 531 A conference template can also include an abstract user interface 532 definition in terms of sliders, radio boxes, etc. for simplifying 533 user interaction with a specific non-trivial feature. 535 4.5 Conference policies 537 Conference policies is the term used to collectively refer to a 538 virtual set of rights, permissions and limitations pertaining to 539 operations being performed on a certain Conference Object. 541 The XCON architecture identifies three different levels of Conference 542 policies: 544 Data Access Rights: The Data Access Rights is the data object 545 describing the read/write access privileges for accessing the 546 Conference Object as a whole. This access would usually be 547 granted and defined in terms of giving the read-only or read-write 548 access to clients with certain roles in the conference. For 549 details see [TBD]. 550 Conference Control Limits and Permissions: The Conference Control 551 Limits and permissions is specified as an integral part of the 552 Conference Object Type. This term collectively references the 553 data objects containing the allowed ranges for other data objects 554 (e.g. maximum number of participants) and lists of clients 555 allowed to perform certain operations on a conference object. For 556 example, the "allowed to join" list of participants is consulted 557 to decide who is allowed to join. The entries in the list can 558 specify the identity of an individual user (joe@example.com), a 559 role, a domain (*@example.com), etc. For details see [TBD]. 560 Common Conference Rules: The Common Conference Rules are envisioned 561 as a more general rule mechanism, beyond the functionality 562 provided by the Conference Control Limits and Permissions. These 563 Common Conference Rules are left for future study by XCON charter. 565 5. Conferencing System Realization 567 XCON-compliant implementations can range from systems supporting 568 ad-hoc conferences, with default behavior only, to sophisticated 569 systems with the ability to schedule re-occurring conferences (each 570 with distinct characteristics), being integrated with external 571 resource reservation tools, and providing snapshots of the conference 572 information at any of the stages of the conference life-cycle. 574 A Conference Object is the logical representation of a Conference 575 Instance at a certain stage, such as capabilities description upon 576 conference creation, reservation, activation, etc., which a 577 Conferencing System maintains in order to describe the system 578 capabilities and to provide access to the available services provided 579 by the Conferencing System. 581 Consequently, the XCON specifications don't mandate the actual usage 582 of the Conference Object, but rather defines the general cloning tree 583 concept and the mechanisms required for its realization, which is 584 described in detail in Section 5.1. 586 Adhoc and advanced conferencing examples are provided in Section 5.2 587 and Section 5.3, with the latter providing additional description of 588 the Conference Object in terms of the stages of a conference, to 589 support scheduled and other advanced conference capabilites. 591 The scheduling of a conference based on these concepts and mechanisms 592 is then detailed in Section 5.4 594 5.1 Cloning Tree 596 The concept defined in this section is a logical representation only, 597 as it is reflected through the XCON mechanisms: the URIs and the 598 protocols. Of course, the actual system realization can differ from 599 the presented model and doesn't require physical copying of the 600 information, etc. 602 Any Conference Object in a Conferencing System is created by either 603 being explicitly cloned from an existing parent object or being 604 implicitly cloned from a default system object. This document uses 605 the "cloning" metaphor instead of the "inheritance" metaphor because 606 it more closely fits the object replication and extension concept, 607 rather than data type re-usage and extension concept. 609 By default, all the data existing in the parent object is copied to 610 the newly created object. 612 The cloning operation needs to specify whether the link between the 613 parent and the child needs to be maintained in the system or not. If 614 no link between the parent and the child exists, the objects become 615 independent and the rest of the cloning process doesn't apply. 617 Once the new object is created, it can be addressed by a unique 618 Conference Object URI assigned by the system. The Conference Object 619 URI is defined by [TBD]. 621 By default, the newly created object can expand the data it contains, 622 within the schema types supported by the parent, just as an 623 independent object can. It can also restrict the read/write access 624 to its objects, but unlike an independent object, cannot relax it 625 relative to its parents access. 627 Any piece of data in the child object can be independently accessed 628 and, by default, can be independently modified without affecting the 629 parent data. 631 On the other hand, the parent object can enforce a different policy 632 by marking certain data elements as "parent enforceable". The values 633 of these data objects can not be changed by directly accessing the 634 child object; neither can they be expanded in the child object alone. 636 If required in the future, XCON specifications may introduce 637 additional (to the "parent enforceable") logical relationships 638 between elements being cloned from one another. 640 +---+-----------------------+ 641 | p | | 642 | o | P A R E N T A | 643 | l | | 644 | i | C O N F E R E N C E | 645 | c | | 646 | i | O B J E C T | 647 | e | | 648 +-s-+-----------------------+ 649 | 650 \| / 651 \/ INDEPENDENT 652 /\ 653 /| \ 654 V 655 +---+-----------------------+ 656 | p | | 657 | o | P A R E N T B | 658 | l | | 659 | i | C O N F E R E N C E | 660 | c | | 661 | i | O B J E C T | 662 | e | | 663 +-s-+-----------------------+ 664 | | 665 | | 666 | --------------------------- 667 | | 668 V V 669 +---+-----------------------+ +---+-----------------------+ 670 | p | | | p | | 671 | o | C H I L D 1 | | o | C H I L D 2 | 672 | i | | | l | | 673 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 674 | i | | | c | | 675 | c | O B J E C T | | i | O B J E C T | 676 | i | | | e | | 677 +-s-+-----------------------+ +-s-+-----------------------+ 679 Figure 3: The Cloning Tree. 681 Using the defined cloning model and its tools, the following sections 682 show examples of how different XCON-compliant systems can be 683 realized. 685 5.2 Ad-hoc Example 687 Figure 4 illustrates how an ad-hoc conference can be created and 688 managed in a conferencing system. 690 A client can create a conference by establishing a call control 691 signalling channel with a Conference Factory as specified in 692 Section 2. The Conference Factory can internally select one of the 693 system supported Conference Object blueprints based on the requesting 694 client privileges and the media lines included in the SDP body. 696 The selected blueprint with its default values is copied by the 697 server into a newly created Conference Object, referred to as an 698 'Active Conference'. At this point the Conference Object becomes 699 independent from its blueprint. A new Conference Object Identifier, 700 a new Conference Identifier and a new focus are allocated by the 701 server. 703 During the conference lifetime, an authorized client can manipulate 704 the Conference Object (such as adding participants) using the 705 Conference Control Protocol [Section 6.3]. 707 +---+-----------------------+ 708 | p | | 709 | o | C O N F E R E N C E | 710 | l | | 711 | i | S Y S T E M | 712 | c | | 713 | i | D E F A U L T | 714 | e | | 715 +-s-+-----------------------+ 716 | 717 \| / 718 \/ 719 /\ 720 /| \ 721 V 722 +---+-----------------------+ 723 | p | | 724 | o | A C T I V E | 725 | l | | 726 | i | C O N F E R E N C E | 727 | c | | 728 | i | I N S T A N C E | 729 | e | | 730 +-s-+-----------------------+ 732 Figure 4: Conference Ad-hoc Creation and Lifetime. 734 5.3 Advanced Example 736 Figure 5 illustrates how a recurring conference can be specified 737 according to system capabilities, scheduled, reserved, and managed in 738 a conferencing system. 740 Firstly, a client would query a Conferencing System for its 741 capabilities. This can be done by requesting a list of the 742 Conference Object "blueprints" the system supports. Each blueprint 743 can contain a specific combination of capabilities and limitations of 744 the conference server in terms of supported media types (audio, 745 video, text, or combinations of these), participant roles, maximum 746 number of participants of each role, availability of floor control, 747 controls available for participants, availability and type of 748 sidebars, the definitions and names of media streams, etc. 750 [Editor's Note: Currently, there is an open issue around Querying a 751 server for a particular template, per Discussion Point 3 on the 752 mailing list.] 753 The selected blueprint with its default values is copied by the 754 client into a newly created Conference Object, referred to as a 755 'Conference Object for Reservation', that specifies the resources 756 needed from the system for this Conference Instance. At this point 757 the 'Conference Object for Reservation' becomes independent from its 758 blueprint. The client can also change the default values (within the 759 system ranges) and add additional information (such as the list of 760 participants and the conference start time) to the 'Conference Object 761 for Reservation'. 763 At this point the client can ask the conference server to create a 764 new conference reservation by attaching the 'Conference Object for 765 Reservation' to the request. As a result, the server can allocate 766 the needed resources, create the additional Conference Objects for 767 each conference occurrence (referred to as a 'Conference Object for 768 Occurrence') and allocate the Conference Object identifiers for all - 769 the 'Conference Object for Reservation' and for each 'Conference 770 Object for Occurrence'. 772 From this point on, any authorized client is able to access and 773 modify each of the Conference Objects independently. By default, 774 changes to an individual 'Conference Object for Occurrence' will 775 affect neither the 'Conference Object for Reservation' nor its 776 siblings. 778 On the other hand, some of the conference sub-objects, such as the 779 maximum number of participants and the participants list, can be 780 defined by the system as parent-forcible. As a result, these objects 781 can be modified by accessing the 'Conference Object for Reservation' 782 only. The changes to these objects can be applied automatically to 783 each of the 'Conference Object for Occurrence's (subject to local 784 policy). 786 +---+-----------------------+ 787 | p | | 788 | o | S E L E C T E D | 789 | l | | 790 | i | C O N F E R E N C E | 791 | c | | 792 | i | B L U E P R I N T | 793 | e | | 794 +-s-+-----------------------+ 795 | 796 \| / 797 \/ 798 /\ 799 /| \ 800 V 801 +---+-----------------------+ 802 | p | | 803 | o | C O N F E R E N C E | 804 | l | | 805 | i | R E S E R V A T I O N | 806 | c | | 807 | i | | 808 | e | | 809 +-s-+-----------------------+ 810 | | | 811 | | | 812 | | | 813 | | | 814 +---|--|--V-----------------+ 815 +-+---|--V------------------+ | 816 +-+-+---V-------------------+ | | 817 | p | | | | 818 | o | C O N F E R E N C E | | | 819 | l | | | | 820 | i | O C C U R R E N C E | | | 821 | c | | | | 822 | i | | |-+ 823 | e | |-+ 824 +-s-+-----------------------+ 826 Figure 5: Advanced Conference Definition, Creation, and Lifetime. 828 5.4 Scheduling a 'Conference Object for Reservation' 830 Scheduling conferences forms an important part of the Conferencing 831 System solution. The concept of a Conference Data Object 832 representing an individual Conference instance is introduced in 833 Section 4.2. A basic Conference Instance represents a single 834 occurrence that has a specified 'start' and 'end' time. In most 835 advanced conferencing solutions it is possible to not only schedule 836 an individual conference instance, but also schedule a series of 837 related conferences (e.g. A weekly meeting that occurs on Thursday 838 at 09.00). 840 [Editor's Note: Currently, there is an open issue around Referring 841 to sets of meetings, per Discussion Point 1 on the mailing list.] 843 To be able to achieve such functionality, a Conferencing System needs 844 to be able to appropriately schedule and maintain Conference 845 Instances that form part of a recurring conference schedule. The 846 mechanism proposed in this document makes use of the 'Internet 847 Calendaring and Scheduling Core Object' specification defined in 848 RFC2445[8] in union with the concepts introduced in Section 4 for the 849 purpose of achieving advanced conference scheduling capability. 851 Figure 6 illustrates a simplified view of a Client interacting with a 852 Conference System. The Client is using the 'Conference Control 853 Protocol'[ref - TBD] protocol to add a new Conference Instance to the 854 Conference System by interfacing with the Conference Control Server. 855 A Conference Control Protocol request contains a valid 'Conference 856 Object for Reservation' and reference by value to an 'iCal' object 857 which contains scheduling information about the conference instance 858 (e.g. start time, end time). 860 +--------------+ +-------Conferencing System-----------------+ 861 | Generic ICAL | | | 862 | Resource | | ..Conference Instance.... | 863 +--------------+ | . . +-----------+| 864 ^ ^ | . +-------------------+ . | Conference|| 865 | | | . |Conference Objects |<--| Control || 866 | ----------------->. +-------------------+ . | Server || 867 | | . . +-----------+| 868 | | ......................... ^ | 869 | | ^ | | 870 +-----|--------------+ | | | 871 | v | | | 872 | +--------------+ | | | 873 | | Resource |<------------------+ | | 874 | | Scheduler | | | 875 | +--------------+ | | 876 | | | 877 +---------------------------------------------------------|------+ 878 | 879 | 880 +-Request-+ 881 | | 882 +----+ | 883 |ICAL| | 884 +----+----+ 885 | 886 | 887 | 888 Conference Control| 889 Protocol | 890 | 891 +-------------+ 892 | Conferencing| 893 | Client | 894 +-------------+ 896 Figure 6: Resource Scheduling 898 A successful creation of a Conference Instance using the Conference 899 Control Protocol results in a new 'Conference Object for 900 Reservation'. A Conference Control Protocol request is validated, 901 including the associated iCal object, and the resultant 'Conference 902 Object for Reservation' is created. The Conference Object is 903 uniquely represented within the Conference System by Conference 904 Object Identifier (e.g. xcon:hd87928374) as defined in [TBD] and 905 discussed in Section 4.1. The unique URI is returned to the client 906 and can be used to reference the 'Conference Object for Reservation' 907 representation if any future manipulations are required (e.g. Alter 908 start time) using a Conference Control Protocol. 910 The previous example explains how a client creates a basic 911 'Conference Object for Reservation' using an iCal reference in 912 association with a Conference Control Protocol. Figure 6 can also be 913 applied when explaining how a series of Conferences are scheduled in 914 the system. The description is almost identical with the exception 915 that the iCal definition that is included in a Conference Control 916 Request represents a series of recurring Conference Instances (e.g. 917 conference start time, end time, occur weekly). The Conference 918 system will treat this request the same as the first example. The 919 protocol request will be validated, along with the associated iCal 920 object, and the 'Conference Object for Reservation' will be created. 921 The 'Conference Object for Reservation' and the Conference Object ID 922 created for this example represent the entire series of recurring 923 Conference Instances rather than a single Conference. If the client 924 uses the Conference Object ID provided and a Conference Control 925 Protocol to adjust the 'Conference Object for Reservation', every 926 Conference Instance in the series will be altered. 928 A Conferencing System that supports the scheduling of a series of 929 Conference Instances should also be able to support manipulation 930 within a series range. A good example might be that a 'Conference 931 Object for Reservation' has been scheduled to occur every Monday at 932 09.00 GMT. For the next three weeks only, the meeting has been 933 altered to occur at 10.00 GMT in an alternative venue. With Figure 6 934 in mind, the client will construct a Conference Control request 935 whose purpose is to modify the existing 'Conference Object for 936 Reservation' representing the recurring Conference Instance. The 937 Client will include the Conference Object ID provided by the 938 Conference System to explicitly reference the 'Conference Object for 939 Reservation' within the Conference System. A Conference Control 940 request will contain all the required changes to the 'Conference 941 Object for Reservation'(e.g. Change of venue). The Conference 942 System matches the incoming request to the existing 'Conference 943 Object for Reservation' but identifies that the associated iCal 944 object only refers to a range of the existing series. The Conference 945 System creates a child clone of the original 'Conference Object for 946 Reservation' to represent the altered Conference Instances within 947 the Series. The cloned 'Conference Object for Reservation' 948 representing the altered series of Conference Instances has its own 949 associated Conference Object ID which is returned to the Client using 950 a Conference Control Protocol. This Conference Object ID is then 951 used by the client to make any future alterations on the newly 952 defined sub-series. This process can be repeated any number of times 953 as the newly returned Conference Object ID representing an altered 954 (cloned) series of Conference Instances, can itself be manipulated 955 using the Conference Control Protocol and the newly created 956 Conference Object ID representation. This provides a flexible 957 approach to the scheduling of recurring Conference instances. 959 6. Conferencing Mechanisms 961 6.1 Call Control Signalling 963 The focus is the central component of the conference. Participants 964 interface with the focus using an appropriate Call Control Signalling 965 protocol. Participants request to establish or join a conference 966 using the Call control signalling interface. A focus then either 967 accepts (after checking the policies), sends a progress indication 968 (e.g. for a parked call while awaiting moderator approval to join) 969 or rejects that request using the call control signalling interface. 971 During an active conference, a Conference Control Protocol 972 [Section 6.3] can be used to affect the conference state. For 973 example, Conference Control Protocol requests to add and delete 974 participants will be communicated to the focus and checked against 975 the conference policies. If approved, the participants will be added 976 or deleted using the call signalling to/from the focus. 978 6.2 Notifications 980 A Conferencing System is responsible for implementing a Conference 981 Notification Service. The Conference Notification Service provides 982 updates about the Conference Instance state to authorized parties 983 (e.g. participants) according to [11]. 985 User identity and his/her Role are used by the conferencing system to 986 filter the notifications such that they contain only information 987 that is allowed to be sent to that user. 989 6.3 Conference Control Protocols 991 The XCON working group will develop a protocol or a set of protocols 992 for controlling the state of a Conference Object and for retrieving 993 its state. The nature of this protocol is currently under discussion 994 in the XCON working group. The proposals span from data manipulation 995 (management-like) protocols to semantic-oriented. Two of the 996 proposed protocols are detailed in the sections below. Among other 997 mentioned candidates are SOAP and HTML FORMS. The following 998 paragraphs summarize the fundamental issues around the selection of 999 the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG 1000 mailing list]. 1002 It is recognized that semantic manipulations make for a cleaner 1003 protocol design, with the disadvantage that extensions to the 1004 underlying data model require extensions to the protocol used to 1005 manipulate it. Syntactic manipulations allow for extensions to the 1006 data model without requiring protocol extensions, with the 1007 disadvantage that the server generally has to infer intent from data 1008 manipulations instead of having intent explicitly signaled. 1010 It is worth noting that one portion of the data to be manipulated, 1011 the Common Conference Information, will not be extended, and would 1012 naturally lend itself to semantic manipulation. Another part of the 1013 data, the Conference Template, is intended to be extended, and would 1014 naturally lend itself to syntactic manipulation. However, there has 1015 been a stated desire to use a single protocol (and presumably a 1016 single mode of operation within this protocol) to manipulate all 1017 conference object state (common and template). 1019 The third statement in the paragraph above makes the first two 1020 solution options mutually exclusive; the XCON working group needs to 1021 determine which of the three statements above is least important to 1022 the working group. 1024 6.3.1 CPCP 1026 A Conference Policy Control Protocol (CPCP) is a data manipulation 1027 protocol being proposed as a standard means of storing and 1028 manipulating the conference policy. According to CPCP, the 1029 conference policy is comprised of the rules associated with a 1030 specific Conference Instance. Requirements for the CPCP are defined 1031 in the CPCP Requirements document [13]. The Conference Policy 1032 Control Protocol document [17] defines the XML Schema for the 1033 conference policy data elements. 1035 The privileges as to which users are allowed to read and/or 1036 manipulate a specific Conference Instance are defined in a separate 1037 Extensible Markup Language (XML) Schema[19]. This schema is based on 1038 the common policy model being used for geographic privacy information 1039 and for presence information. 1041 A separate document [18] proposes XCAP as one protocol mechanism for 1042 storing and manipulating this conferencing policy data. XCAP is a 1043 HTTP 1.1 based protocol that allows clients to read, write, modify 1044 and delete application data stored in XML format on a server. One of 1045 the main advantages of XCAP is that it maps XML document elements and 1046 attributes to HTTP URIs that can be directly accessed by HTTP. 1048 6.3.2 CCCP 1050 A Centralized Conferencing Control Protocol [20] is a 1051 semantic-oriented protocol defined to allow participants or otherwise 1052 authorized entities to directly manipulate an active Conference 1053 Instance. CCCP is defined as a set of transactions issued over a 1054 reliable transport protocol. A transaction consists of a Request 1055 carrying the required information in an XML body and a corresponding 1056 Response carrying an appropriate XML body. 1058 CCCP requests are submitted to the CCCP server and can be prioritized 1059 and queued, based on the CCCP client Role and the requested 1060 primitives. CCCP requires no single lock per document, and the CCCP 1061 server can locally implement an optimization strategy independent of 1062 CCCP client behavior. 1064 6.4 Floor Control 1066 [Editor's Note: This text still requires further updating to reflect 1067 new model and pending new WG agreements. Amongst the things TODO 1068 are: 1070 1. Need to be able to fetch from the Conference Object the 1071 credentials required for BFCP. This includes the conference id, user 1072 id, and password. 1074 2. Clarification of identifiers based on agreement with content in 1075 section Section 6.4.1, etc. 1077 3 Trimming the level of detail in this section since some of it is 1078 beyond the scope of the framework - it's here for now to establish 1079 the context for discussion. New draft TBD if mechanism details need 1080 to be specified. 1082 4. Evaluation of an alternative proposal [TBD as a stand alone draft 1083 as well] for using Templates as the means for correlating Floor 1084 Control identifiers. 1086 ] 1088 A mechanism for floor control within a Conferencing System is defined 1089 in the 'Binary Floor Control Protocol' specification [16]. Floor 1090 control is not a mandatory mechanism for a Conferencing System 1091 implementation but provides advanced media input control features for 1092 participants. 1094 An XCON compliant client supporting floor control needs to obtain 1095 information for connecting to a floor control server to enable it to 1096 issue floor requests. This connection information can be retrieved 1097 using information provided by mechanisms such as negotiation using 1098 the SDP[2] offer/answer[5] exchange on the signalling interface with 1099 the focus. 1101 As well as the Client --> Floor Server connection information, a 1102 client wishing to interact with a Floor Control server requires 1103 access to additional information. This information associates Floor 1104 Control interactions with the appropriate Floor instance. Once a 1105 connection has been established and authenticated (see [16] for 1106 authentication details), a specific floor control message requires 1107 detailed information to uniquely identify a user, a floor and a 1108 conference. This information, defined in the next set of bullet 1109 points, can be obtained using methods such as negotiation using the 1110 SDP offer/answer exchange on the signalling interface with the focus: 1112 o Conference Object ID - Each Conference Object has a unique 1113 identifier per Section 4.1, obtained from the Conference server, 1114 which MUST be included in all Floor messages. When using SDP 1115 offer/answer exchange to negotiate a Floor control connection with 1116 the focus using the call control signalling interface, the unique 1117 conference identifier is contained in the 'confid' SDP attribute, 1118 as defined in [24] - e.g. a=confid:2874. 1119 o User Identifier - Each user has a unique identifier within the 1120 Conference Object per Section 6.4.1, obtained from the Conference 1121 server, which MUST be included in all Floor messages. When using 1122 SDP offer/answer exchange to negotiate a Floor control connection 1123 with the focus using the call control signalling interface, the 1124 unique conference identifier is contained in the 'userid' SDP 1125 attribute, as defined in [24] - e.g. a=userid:8937. 1126 o Floor ID - A media session with a Conferencing System can have any 1127 number of 'Floors' (0 or more) that are represented by a unique 1128 identifier within the Conference Instance (as represented by 1129 Conference ID). When using SDP offer/answer exchange to negotiate 1130 a Floor control connection with the focus using the call control 1131 signalling interface, the unique conference identifier is 1132 contained in the 'floorid' SDP attribute, as defined in [24] 1133 e.g.a=floorid:1 m-stream:10 . Each 'floorid' attribute, 1134 representing a unique floor, has an 'm-stream' tag containing one 1135 or more identifiers. The identifiers represent individual SDP 1136 media sessions (as defined using 'm=' from SDP) using the SDP 1137 'Label' attribute as defined in [23]. 1139 Clients can authenticate a BFCP server using the TLS certificates. 1140 Requests submitted on a successfully created BFCP connection may 1141 additionally require digest authentication within the BFCP protocol 1142 to authenticate the Floor control client to the server. For this to 1143 take place a shared secret needs to be exchanged between the BFCP 1144 client/server entities. This can be achieved out of band using a 1145 mechanism such as the 'k=' SDP attribute. The shared secret can also 1146 be exchanged using un-specified 'out of band' mechanisms. When using 1147 Digest authentication of BFCP client messages the exchange of an 1148 active 'Nonce' is also required. This can be achieved using a BFCP 1149 request response interaction as defined in BFCP (A request is 1150 submitted without a Nonce TLV and the server generates an error 1151 response with either an Error Code 7 (DIGEST TLV Required) or 6 1152 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 1153 can also be obtained 'out of band' using information provided in the 1154 Offer/Answer exchange. As with the other SDP Floor attributes 1155 referenced in this section and defined in [24], the 'nonce' attribute 1156 can be inserted in the SIP response e.g. a=nonce:dhsa8hd0dwqj. 1158 Editors Note: Should we be referencing SDP-new? The authors believe 1159 so, but the SDP BFCP draft does NOT, so we need to agree and align 1160 all the documents to be consistent. 1162 6.4.1 User Identifier 1164 [Editor's Note: This section is included to capture the information 1165 for discussion. It's likely this topic should be covered in a 1166 separate document once there's agreement on the concept. It will 1167 need to include more details such as use of User ID as 'username' 1168 challenge in SIP Digest etc.] 1170 An important concept when considering a Conference System is the 1171 identity of users. This document introduces the concept of a 1172 Conferencing System User Identifier, as defined in [*TBD - may fit 1173 with new Conference Object ID concept doc]. A Conference System user 1174 has an associated unique identifier (in the context of the Conference 1175 System) that forms a generic internal representation. 1177 It is intended that the generic User Identity (User ID) for a 1178 Conference system can be used in all relevant supporting protocols 1179 (e.g. Floor Control, Media Policy, CCP, signaling interface). The 1180 mapping of User ID from various XCON protocols should be discussed 1181 and referenced in relevant protocol documents. Section 6.4 provides 1182 more details regarding the mapping of User ID with floor control. 1184 It is important to emphasize that the User Identity being described 1185 is in the context of the Conference System. This is due to the 1186 requirement for identity of Conference System users who may not be 1187 participating in a Conference Instance. Examples being a non 1188 participating 'Floor Control Chair' or 'Media Policy' Controller. 1189 Users can then be associated with Conference Objects as defined in 1190 Section 4.2. This association enables the Conference System to 1191 associate and enforce user level policies at both a system level and 1192 Conference Object level. 1194 7. Conferencing Scenario Realizations 1196 This section addresses how advanced conferencing scenarios, many of 1197 which have been described in [14], are realized using this XCON 1198 framework. The objective of this section is to further illustrate 1199 the model, mechanisms and protocols presented in the previous 1200 sections and also serves to validate that the model, mechanisms and 1201 protocols are sufficient to support advanced conferencing scenarios. 1203 Section 5.2 and Section 5.3 provide examples of the creation of a 1204 basic adhoc conference and a more advanced scheduled conference. 1206 [Editor's note: This whole section needs additional work based upon 1207 the new agreed model, new terminology and needs to reflect the rework 1208 done in the other WG documents. In the end, some XML snippets would 1209 also likely be useful. Section 7.1 is a 1st pass at a detailed 1210 diagram. WG feedback on this approach (versus traditional ladder 1211 diagrams) is appreciated.] 1213 7.1 Participant Manipulations 1215 There are different ways to affect a participant state in a 1216 conference. 1218 A participant can join and leave the conference using call signalling 1219 means only, such as SIP. A participant can change its own media 1220 streams by, for example, sending re-INVITE with new SDP content using 1221 SIP only. This kind of operations is called "1st party signalling" 1222 and they do not affect the state of other participants in the 1223 conference. 1225 Limited operations for controlling other conference participants (a 1226 so called "3rd party control") through the Focus using call 1227 signalling only may also be available for some signalling protocols. 1228 For example, "Conferencing for SIP User Agents" [15] shows how SIP 1229 with REFER can be used to achieve this functionality. 1231 In order to perform richer conference control a user client needs to 1232 implement a conference control protocol client. By using a 1233 conference control protocol, the client can affect its own state, 1234 state of other participants, and state of various resources (such as 1235 media mixers) which may indirectly affect the state of any of the 1236 conference participants. 1238 Figure 7 provides an example of one client "Alice" impacting the 1239 state of another client "Bob". This example assumes an established 1240 conference. In this example, the Client, "Alice" whose Role is 1241 "moderator" of the conference, wants to mute "Bob" on a medium-size 1242 multi-party conference, as his device is not muted (and he's 1243 obviously not listening to the call) and background noise in his 1244 office environment is disruptive to the conference. 1246 It should be noted that only entities impacted by the request are 1247 shown in the diagram 1249 +--------------------------------+ 1250 | Conference System | 1251 "Alice" | +---------+--+| 1252 +--------+ | |policies | || 1253 | |CCP Request < | +-----------+ +---------+ || 1254 | Client |-------------------------->|Conference | |Conference || 1255 | | Conference Object ID, | |Control |~~~>|Object of || 1256 +--------+ Mute, "Bob" > | |Server | |occurrence || 1257 | +-----------+ +-------+ || 1258 | |"Alice"| || 1259 | ' ' '| 1260 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1261 | |<-------------------------|Notification|<~~~| || 1262 | Client |. . ||Service | +-------+ || 1263 +--------+--+ . || | |"Bob" | || 1264 | |<----------------------| | +-------+----+| 1265 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1266 +--------+ +--------------------------------+ 1268 Figure 7: Client Manipulation of Conference - Mute a party 1270 Upon receipt of the Conference Control Protocol request to "mute" a 1271 party ("Bob") in the specific conference as identified by the 1272 Conference Object ID, the Conference Server ensures that "Alice" has 1273 the appropriate authority based on the policies associated with that 1274 specific Conference Object to perform the operation. "Bob's" status 1275 is marked as "recvonly" and the Conference Template of the Conference 1276 Object (if included) is updated to reflect that "Bob's" media is not 1277 to be "mixed" with the conference media. 1279 Depending upon the policies, other participants (including "Bob") may 1280 be notified of this change via the Notification Service. 1282 7.2 Media Manipulations 1284 7.3 Sidebar Manipulations 1286 [Editor's Note: TBD. Once we get full agreement on terminology and 1287 the basic ideas in the other sections, we'll tackle this. Sidebars 1288 are in many ways normal conferences but additional authorization 1289 aspects need to be taken into consideration. Such as that only 1290 members of the parent conference may be allowed to interact with the 1291 sidebar.] 1293 7.4 Whispering or Private Messages 1295 [Editor's Note: TBD. Once we get full agreement on terminology and 1296 the basic ideas in the other sections, we'll tackle this.] 1298 7.5 Conference Announcements and Recordings 1300 [Editor's note: TBD. Use Cullen's comments on the previous version 1301 of the doc .] 1303 8. Relationships between SIPPING and XCON Frameworks 1305 The SIPPING Conferencing Framework [9] provides an overview of a wide 1306 range of centralized conferencing solutions known today in the 1307 conferencing industry. The document introduces a terminology and 1308 logical entities in order to systemize the overview and to show the 1309 common core of many of these systems. The logical entities and the 1310 listed scenarios in the SIPPING Conferencing Framework are being used 1311 to illustrate how SIP [4] can be used as a signalling means in these 1312 conferencing systems. SIPPING Conferencing Framework does not define 1313 new conference control protocols to be used by the general 1314 conferencing system. It uses only basic SIP [4], the SIP 1315 Conferencing for User Agents [15], and the SIPPING Conference 1316 Package [9] for basic SIP conferencing realization. 1318 The XCON framework defines a particular centralized Conferencing 1319 System and the logical entities implementing it. It also defines a 1320 particular XCON Data Model and refers to the standard protocols 1321 (beyond call signalling means) being defined by the XCON WG to be 1322 used among the XCON logical entities for implementing advanced 1323 conferencing features. The purpose of XCON working group and this 1324 framework is to achieve interoperability between the XCON entities 1325 from different vendors for controlling different aspects of advanced 1326 conferencing applications. 1328 The logical entities defined in the two frameworks are not intended 1329 to be mapped one-to-one. The two frameworks differ in the 1330 interpretation of the internal conferencing system decomposition and 1331 the corresponding operations. Nevertheless, the basic SIP [4], the 1332 SIP Conferencing for User Agents [15], and the SIPPING Conference 1333 Package [9] are fully compatible with both Framework documents. 1335 9. Security Considerations 1337 There are a wide variety of potential attacks related to 1338 conferencing, due to the natural involvement of multiple endpoints 1339 and the many, often user-invoked, capabilities provided by the 1340 conferencing system. Examples of attacks include the following: an 1341 endpoint attempting to listen to conferences in which it is not 1342 authorized to participate, an endpoint attempting to disconnect or 1343 mute other users, and theft of service, by an endpoint, in attempting 1344 to create conferences it is not allowed to create. 1346 There are several issues surrounding security of this conferencing 1347 framework. One set of issues involves securing the actual protocols 1348 and the associated authorization mechanisms. This first set of 1349 issues should be addressed in the specificiations specific to the 1350 protocols described in Section 6. The protocols used for 1351 manipulation and retrieval of confidential information MUST support a 1352 confidentiality and integrity mechanism. Similar requirements apply 1353 for the floor control protocols. 1355 There are also security issues associated with the authorization to 1356 perform actions on the conferencing system to invoke specific 1357 capabilities. Section 4.5 discusses the policies associated with the 1358 Conference Object to ensure that only authorized entities are able to 1359 manipulate the data to access the capabilities. The final set of 1360 issues involves the privacy and security of the identity of a user in 1361 the conference. 1363 Many policy authorization decisions are based on the identity of the 1364 user or the Role that a user may have. There are several ways that a 1365 user might authenticate its identity to the system. The conferencing 1366 system may know about specific users and assign passwords to the 1367 users. The users may also be authenticated by knowing a particular 1368 Conference ID and a PIN for it. Sometimes, a PIN is not required and 1369 the Conference ID is used as a shared secret. The call signalling 1370 means can provide a trusted form of the user identity or it might 1371 just provide a hint of the possible identity and the user still needs 1372 to provide some authentication to prove it has the identity that was 1373 provided as a hint in the call signalling. This may be in the form 1374 of an IVR system or other means. The goal for the Conferencing 1375 System is to figure out a user identity and a Role for any attempt to 1376 send a request to the Conferencing System. 1378 When a Conferencing System presents the identity of authorized users, 1379 it may choose to provide information about the way the identity was 1380 proven to or verified by the system. A user may also come as a 1381 completely unauthenticated user into the system - this fact needs 1382 also be communicated to interested parties. 1384 When guest users interact with the system, it is often in the context 1385 of a particular conference. In this case the user may provide a PIN 1386 or a password that is specific to the conferences and authenticates 1387 the user to take on a certain role in that conference. The guest 1388 user can then perform actions that are allowed to any user with that 1389 Role. 1391 The term password is used to mean the usual, that is to say a 1392 reasonable sized, in number of bits, hard to predict shared secret. 1393 Today users often have passwords with more than 30 bits of randomness 1394 in them. PIN is a special password case - a shared secret that is 1395 only numeric and often contains a fairly small number of bits (often 1396 as few as 10 bits). When Conferencing Systems are used for audio on 1397 the PSTN, there is often a need to authenticate using a PIN. 1398 Typically if the user fails to provide the correct PIN a few times in 1399 a row, the PSTN call is disconnected. The rate of making the calls 1400 and getting to the point to enter a PIN makes is fairly hard to do an 1401 exhaustive search of the PIN space even for 4 digit PINs. When using 1402 a high speed interface to connect to a Conferencing System, it is 1403 often possible to do thousands of attempts per second and the PIN 1404 space could quickly be searched. Because of this, it is not 1405 appropriate to use PINs for authorization on any of the interfaces 1406 that provide fast queries or many simultaneous queries. 1408 This conferencing system has an idea of the identity of a user but 1409 this does not mean it can reveal this identity to other users, due to 1410 privacy considerations. Users can set select various options for 1411 revealing their identity to other users. A user can be "hidden" such 1412 that other users can not see they are involved in the conference, or 1413 they can be "anonymous" such that users can see that another user is 1414 there, but not see the identity of the user, or they can be "public" 1415 where other users can see their identity. If there are multiple 1416 "anonymous" users, other parties will be able to see them as 1417 independent "anonymous" parties and will be able to tell how many 1418 "anonymous" parties are in the conference. Note, that the visibility 1419 to other participants is dependent on their Roles. For example, 1420 users' visibility (including "anonymous" and "hidden") may be 1421 displayed to the moderator or administrator, subject to a 1422 Conferencing System's local policies. "Hidden" status is often used 1423 by robot participants of a conference and is also used in many call 1424 center conference situations. 1426 10. IANA Considerations 1428 This is an informational draft, with no IANA considerations required. 1430 11. Acknowledgements 1432 This document is a result of architectural discussions among IETF 1433 XCON working group participants. The authors would like to thank 1434 Henning Schulzrinne for the "Conference Object Tree" proposal and 1435 Cullen Jennings for providing input for the "Security Considerations" 1436 section. 1438 12. References 1440 12.1 Normative References 1442 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1443 Levels", BCP 14, RFC 2119, March 1997. 1445 12.2 Informative References 1447 [2] Handley, M. and V. Jacobson, "SDP: Session Description 1448 Protocol", RFC 2327, April 1998. 1450 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1451 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1452 1998. 1454 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1455 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1456 Session Initiation Protocol", RFC 3261, June 2002. 1458 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1459 Session Description Protocol (SDP)", RFC 3264, June 2002. 1461 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1462 Notification", RFC 3265, June 2002. 1464 [7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1465 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1466 RFC 3550, July 2003. 1468 [8] Dawson, F. and Stenerson, D., "Internet Calendaring and 1469 Scheduling Core Object Specification (iCalendar)", RFC 2445, 1470 November 1998. 1472 [9] Rosenberg, J., "A Framework for Conferencing with the Session 1473 Initiation Protocol", 1474 Internet-Draft draft-ietf-sipping-conferencing-framework-03, 1475 October 2004. 1477 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 1478 Coupled SIP Conferencing", 1479 Internet-Draft draft-ietf-sipping-conferencing-requirements-01, 1480 October 2004. 1482 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1483 Package for Conference State", 1484 Internet-Draft draft-ietf-sipping-conference-package-08, 1485 December 2004. 1487 [12] Schulzrinne, H., "Requirements for Floor Control Protocol", 1488 Internet-Draft draft-ietf-xcon-floor-control-req-03, January 1489 2005. 1491 [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference 1492 Policy Control Protocol", 1493 Internet-Draft draft-ietf-xcon-cpcp-reqs-04, August 2004. 1495 [14] Even, R., "Conferencing Scenarios", 1496 Internet-Draft draft-ietf-xcon-conference-scenarios-02, July 1497 2004. 1499 [15] Johnston, A. and O. Levin, "Session Initiation Protocol Call 1500 Control - Conferencing for User Agents", 1501 Internet-Draft draft-ietf-sipping-cc-conferencing-06, November 1502 2004. 1504 [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 1505 Internet-Draft draft-ietf-xcon-bfcp-03, January 2005. 1507 [17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", 1508 Internet-Draft draft-ietf-xcon-cpcp-01, October 2004. 1510 [18] Khartabil, H., "An Extensible Markup Language (XML) 1511 Configuration Access Protocol (XCAP) Usages for Conference 1512 Policy Manipulation and Conference Policy Privelges 1513 Manipulation", Internet-Draft draft-ietf-xcon-cpcp-xcap-03, 1514 October 2004. 1516 [19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a 1517 Conference Policy", 1518 Internet-Draft draft-ietf-xcon-conference-policy-privileges-01, 1519 October 2004. 1521 [20] Levin, O. and G. Kimchi, "Centralized Conference Data Model", 1522 Internet-Draft draft-levin-xcon-cccp-01, January 2005. 1524 [21] Jennings, C., "Media Mixer Control for XCON", 1525 Internet-Draft draft-jennings-xcon-media-control-01, July 2004. 1527 [22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", 1528 Internet-Draft draft-rosen-xcon-conf-sidebars-01, July 2004. 1530 [23] Levin, O. and G. Camarillo, "The SDP (Session Description 1531 Protocol) Label Attribute", 1532 Internet-Draft draft-ietf-mmusic-sdp-media-label-01, January 1533 2005. 1535 [24] Camarillo, G., "Session Description Protocol (SDP) Format for 1536 Binary Floor Control Protocol (BFCP) Streams", 1537 Internet-Draft draft-camarillo-mmusic-sdp-bfcp-00, October 1538 2004. 1540 [25] Campbell, B., "The Message Session Relay Protocol", 1541 Internet-Draft draft-ietf-simple-message-sessions-09, October 1542 2004. 1544 Authors' Addresses 1546 Mary Barnes 1547 Nortel 1548 2380 Performance Drive 1549 Richardson, TX 1551 Email: mary.barnes@nortel.com 1552 Chris Boulton 1553 Ubiquity Software Corporation 1554 Building 3 1555 Wern Fawr Lane 1556 St Mellons 1557 Cardiff, South Wales CF3 5EA 1559 Email: cboulton@ubiquitysoftware.com 1561 Orit Levin 1562 Microsoft Corporation 1563 One Microsoft Way 1564 Redmond, WA 98052 1566 Email: oritl@microsoft.com 1568 Intellectual Property Statement 1570 The IETF takes no position regarding the validity or scope of any 1571 Intellectual Property Rights or other rights that might be claimed to 1572 pertain to the implementation or use of the technology described in 1573 this document or the extent to which any license under such rights 1574 might or might not be available; nor does it represent that it has 1575 made any independent effort to identify any such rights. Information 1576 on the procedures with respect to rights in RFC documents can be 1577 found in BCP 78 and BCP 79. 1579 Copies of IPR disclosures made to the IETF Secretariat and any 1580 assurances of licenses to be made available, or the result of an 1581 attempt made to obtain a general license or permission for the use of 1582 such proprietary rights by implementers or users of this 1583 specification can be obtained from the IETF on-line IPR repository at 1584 http://www.ietf.org/ipr. 1586 The IETF invites any interested party to bring to its attention any 1587 copyrights, patents or patent applications, or other proprietary 1588 rights that may cover technology that may be required to implement 1589 this standard. Please address the information to the IETF at 1590 ietf-ipr@ietf.org. 1592 Disclaimer of Validity 1594 This document and the information contained herein are provided on an 1595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1597 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1598 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1599 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1602 Copyright Statement 1604 Copyright (C) The Internet Society (2005). This document is subject 1605 to the rights, licenses and restrictions contained in BCP 78, and 1606 except as set forth therein, the authors retain all their rights. 1608 Acknowledgment 1610 Funding for the RFC Editor function is currently provided by the 1611 Internet Society.