XCON Working Group M. Barnes Internet-Draft Nortel Expires: September 2, 2006 C. Boulton Ubiquity Software Corporation O. Levin Microsoft Corporation Mar 2006 A Framework and Data Model for Centralized Conferencing draft-ietf-xcon-framework-03 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with Barnes, et al. Expires September 2, 2006 [Page 1] Internet-Draft XCON Framework Mar 2006 a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10 5.1. Common Conference Information . . . . . . . . . . . . . . 11 5.2. Conference Template . . . . . . . . . . . . . . . . . . . 12 5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12 6. Centralized Conferencing Constructs and Identifiers . . . . . 13 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 7. Conferencing System Realization . . . . . . . . . . . . . . . 15 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26 8.3.1. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38 9.6. Conference Announcements and Recordings . . . . . . . . . 39 10. Relationships between SIPPING and Centralized Conferencing Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 40 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 41 11.3. Floor Control Server Authentication . . . . . . . . . . . 42 Barnes, et al. Expires September 2, 2006 [Page 2] Internet-Draft XCON Framework Mar 2006 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 15. Appendix A - Conference Object Identifier . . . . . . . . . . 47 15.1. Conference Object URI Definition . . . . . . . . . . . . . 50 16. Appendix B - Conference User Identifier . . . . . . . . . . . 50 16.1. Conference User Definition . . . . . . . . . . . . . . . . 52 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 17.1. Normative References . . . . . . . . . . . . . . . . . . . 52 17.2. Informative References . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . . . . 56 Barnes, et al. Expires September 2, 2006 [Page 3] Internet-Draft XCON Framework Mar 2006 1. Introduction This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in a centralized unicast conference. Other than references to general functionality (e.g., establishment and teardown), details of these call signaling protocols are outside the scope of this document The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The Centralized Conferencing Framework is compatible with the functional model presented in the SIPPING Conferencing Framework [9]. Section 10 of this document discusses the relationship between the Centralized Conferencing Framework and the SIPPING Conferencing framework, in the context of the Centralized Conferencing model presented in this document. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Overview A centralized conference is an association of endpoints, called conference participants, with a central endpoint, called a conference Focus. The Focus has direct peer relationships with the participants by maintaining a separate call signaling interface with each. Consequently, in this centralized conferencing model, the call signaling graph is always a star. The most basic conference supported in this model would be an ad-hoc unmanaged conference, which would not necessarily require any of the functionality defined within this framework. For example, it could be supported using basic SIP signaling functionality with a participant serving as the Focus; the SIPPING Conferencing Framework [9] together with the SIP Call Control Conferencing for User Agents[15] documents address these types of scenarios. Barnes, et al. Expires September 2, 2006 [Page 4] Internet-Draft XCON Framework Mar 2006 In addition to the basic features, however, a conferencing system supporting the centralized conferencing model proposed in this framework document can offer richer functionality, by including dedicated conferencing applications with explicitly defined capabilities, reserved recurring conferences, along with providing the standard protocols for managing and controlling the different attributes of these conferences. The core requirements for centralized conferencing are outlined in [10]. These requirements are applicable for conferencing systems using various call signaling protocols, including SIP. Additional conferencing requirements are provided in [12], [13], and [14]. The centralizing conferencing system proposed by this framework is built around a fundamental concept of a conference object. A conference object provides the data representation of a conference during each of the various stages of a conference (e.g., creation, reservation, active, completed, etc.). A conference object is accessed via the logical functional elements, with whom a conferencing client interfaces, using the various protocols identified in Figure 1. The functional elements defined for a conferencing system described by the framework are a Conference Control Server, Floor Control Server, any number of Foci and a Notification Service. A Conference Control Protocol (CCP) provides the interface between a conference and media control client and the conference control server. A Binary Floor Control Protocol (BFCP) provides the interface between a floor control client and the floor control server. A call signaling protocol (e.g., SIP, H.323, PSTN, etc.) provides the interface between a call signaling client and a Focus. A notification protocol (e.g. SIP Notify) provides the interface between the conferencing client and the Notification Service. A conferencing system can support a subset of the conferencing functions depicted in the conferencing system logical decomposition in Figure 1 and described in this document. However, there are some essential components that would typically be used by most other advanced functions, such as the Notification Service. For example, the notification service is used to correlate information, such as list of participants with their media streams, between the various other components. Barnes, et al. Expires September 2, 2006 [Page 5] Internet-Draft XCON Framework Mar 2006 ................................................................... . Conferencing System . . . . +-----------------------------------------------------+ . . | C o n f e r e n c e o b j e c t | . . +-+---------------------------------------------------+ | . . | C o n f e r e n c e o b j e c t | | . . +-+---------------------------------------------------+ | | . . | C o n f e r e n c e o b j e c t | | | . . | | | | . . | | |-+ . . | |-+ . . +-----------------------------------------------------+ . . ^ ^ ^ | . . | | | | . . v v v v . . +-------------------+ +--------------+ +-------+ +------------+. . | Conference Control| | Floor Control| |Foci | |Notification|. . | Server | | Server | | | |Service |. . +-------------------+ +--------------+ +-------+ +------------+. . ^ ^ ^ | . ..............|.................|...........|..........|........... | | | | |Conference |Binary |Call |Notification |Control |Floor |Signaling |Protocol |Protocol |Control |Protocol | | |Protocol | | | | | | ..............|.................|...........|..........|........... . V V V V . . +----------------+ +------------+ +----------+ +------------+. . | Conference | | Floor | | Call | |Notification|. . | and Media | | Control | | Signaling| | Client |. . | Control | | Client | | Client | | |. . | Client | | | | | | |. . +----------------+ +------------+ +----------+ +------------+. . . . Conferencing Client . ................................................................... Figure 1: Conferencing System Logical Decomposition. The media graph of a conference can be centralized, decentralized, or any combination of both and potentially differ per media type. In the centralized case, the media sessions are established between a media mixer controlled by the focus and each one of the participants. In the decentralized (i.e., distributed) case, the media graph is a Barnes, et al. Expires September 2, 2006 [Page 6] Internet-Draft XCON Framework Mar 2006 multicast or multi-unicast mesh among the participants. Consequently, the media processing (e.g., mixing) can be controlled either by the focus alone or by the participants. The concepts in this framework document clearly map to a centralized media model. The concepts can also apply to the decentralized media case, however, the details of such are left for future study. Section 5 of this document provides more details on the conference object. Section 6 provides an overview of the identifiers necessary to address and manage the conference objects, instances and users associated with a conferencing system. Section 7 of this document describes how a conferencing system is logically built using the defined data model and how the conference objects are maintained. Section 8 describes the fundamental conferencing mechanisms and provides a high level overview of the protocols. Section 9 then provides realizations of various conferencing scenarios, detailing the manipulation of the conference objects using the defined protocols. Section 10 of this document summarizes the relationship between this Centralized Conferencing Framework and the SIPPING Conferencing Framework. 4. Terminology This Centralized Conferencing Framework document generalizes, when appropriate, the SIPPING Conferencing Framework [9] terminology and introduces new concepts, as listed below. Further details and clarification of the new terms and concepts are provided in the subsequent sections of this document. Active conference: The term active conference refers to a conference cbject that has been created and activated via the allocation of its identifiers (e.g., conference object identifier and conference identifier) and the associated focus. An active conference is created based on either a system default conference blueprint or a specific conference reservation. Call Signaling protocol: The call signaling protocol is used between a participant and a focus. In this context, the term "call" means a channel or session used for media streams. Common conference information: The common conference information is the data type (i.e., the XML schema) which is used to represent the core set of information for a conference object. This core information includes a common set of definitions for basic conference features, such as conference identifiers, membership, signaling, capabilities and media types, applicable to a wide range of conferencing applications. Barnes, et al. Expires September 2, 2006 [Page 7] Internet-Draft XCON Framework Mar 2006 Conference blueprint: A conference blueprint is a static conference object within a conferencing system, which describes a typical conference setting supported by the system. A conference blueprint is the basis for creation of dynamic conference objects. A system may maintain multiple blueprints. Each blueprint is comprised of the initial values and ranges for the elements in the object, conformant to the data schemas for the common conference information and the specific template associated with the blueprint. Conference control protocol (CCP): A conference control protocol provides the interface for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object. Conference factory: A conference factory is a logical entity, that generates upon request, unique URI(s) to identify and represent a conference focus. Conference identifier (ID): A conference identifier is a call signaling protocol-specific URI that identifies a conference focus and its associated conference instance. Conference instance: A conference instance refers to an internal implementation of a specific conference, represented as a set of logical conference objects and associated identifiers. Conference object: A conference object represents a conference at a certain stage (e.g., description upon conference creation, reservation, activation, etc.), which a conferencing system maintains in order to describe the system capabilities and to provide access to the services available for each object independently. The conference object schema is comprised of two distinct sub components; the common conference information and the conference template(s). Conference object identifier (ID): A conference object identifier is a URI which uniquely identifies a conference object and is used by a conference control protocol to access and modify the conference information. Conference policies: Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object. Conference reservation: A conference reservation is a conference object, which is created from either a system default or client selected blueprint. Conference state: The conference state reflects the state of a conference instance and is represented using a specific, well- defined schema. Conferencing system: Conferencing system refers to a conferencing solution based on the data model discussed in this framework document and built using the protocol specifications referenced in this framework document. Barnes, et al. Expires September 2, 2006 [Page 8] Internet-Draft XCON Framework Mar 2006 Conference template: The conference template refers to the data type (i.e. the XML schema) which is used to represent the media or application specific part of the conference object. This information represents enhanced conferencing features or capabilities, such as media mixers, and/or user interface abstractions. Floor: Floor refers to a set of data or resources associated with a conference instance, for which a conference participant, or group of participants, is granted temporary access. Floor chair: A floor chair is a floor control protocol compliant client, either a human participant or automated entity, who is authorized to manage access to one floor and can grant, deny or revoke access. The floor chair does not have to be a participant in the conference instance. Focus: A focus is a logical entity that maintains the call signalling interface with each participating client and the conference object representing the active state. As such, the focus acts as an endpoint for each of the supported signaling protocols and is responsible for all primary conference membership operations (e.g., join, leave, update the conference instance) and for media negotiation/maintenance between a conference participant and the focus. Media graph: The media graph is the logical representation of the flow of media for a conference. Media mixer: A media mixer is the logical entity with the capability to combine media inputs of the same type, transcode the media and distribute the result(s) to a single or multiple outputs. In this context, the term "media" means any type of data being delivered over the network using appropriate transport means, such as RTP/ RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol (defined in [24]). Registered conference document : A standards track document (i.e., RFC) that defines and registers a conference template schema with the appropriate organization (e.g., IANA). A registered conference document also includes any complementary textual information. Role: A role provides the context for the set of conference operations that a participant can perform. A default role (e.g., standard conference participant) will always exist, providing a user with a set of basic conference operations. Based on system specific authentication and authorization, a user may take on alternate roles, such as conference moderator, allowing access to a wider set of conference operations. Sidebar: A sidebar is a separate Conference instance that only exists within the context of a parent conference instance. Barnes, et al. Expires September 2, 2006 [Page 9] Internet-Draft XCON Framework Mar 2006 Whisper: TBD. 5. Centralized Conferencing Data Model The centralized conference data model is logically represented by the conference object. A conference object is of type 'Conference object type', which is comprised of two distinct components: the 'Common conference information type' and the 'Conference template type', as illustrated in Figure 2. Each of these types is extensible for including potentially multiple sub-types. +------------------------------------------------------+ | C o n f e r e n c e o b j e c t t y p e | | | | +--------------------------------------------------+ | | | Common conference information type | | | | | | | | +----------------------------------------------+ | | | | | Conference description (times, duration) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Membership (roles, capacity, names) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Signaling (protocol, direction, status) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Floor information | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Sidebars, Etc. | | | | | +----------------------------------------------+ | | | | | | | +--------------------------------------------------+ | | +--------------------------------------------------+ | | | Conference template type | | | | | | | | - Mixer algorithm, inputs, and outputs | | | | - Floor controls | | | | - User Control Interface | | | | - User's View | | | | - Etc. | | | +--------------------------------------------------+ | | | +------------------------------------------------------+ Barnes, et al. Expires September 2, 2006 [Page 10] Internet-Draft XCON Framework Mar 2006 Figure 2: Conference Object Type Decomposition. In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources or reflecting the state of ongoing conferences. Thus, each of the two components (i.e., the common conference information and the conference template) may be optionally included in a particular conference object. Section 7 describes the usage semantics of the conference objects. The centralized conferencing data model defined in this framework has no strict separation between conference membership, conference media information and the related policies. The policies are an integral part of the data model and are realized by local, system level boundaries associated with specific data elements, such as the membership, and by the ranges and limitations on other data elements. Additional policy considerations for a system realization based on this data model are discussed in Section 5.3. The integration of the data in this model meets the requirement of many conference control operations to enable synchronized access to the integral conference policies, to the conference state as a whole, and for receiving notifications about changes to either using the same interface. The exact XML schema of the Conference Object, including the organization of the Common Conference Information and the Conference Templates, are detailed in separate documents [ref: TBD]. 5.1. Common Conference Information The common conference information section contains the core information that is utilized in any conference and is independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). Typically, participants with read-only access to the conference information would be interested in this common conference information only. The common conference information may be represented using the conference-type as defined in [11]. The conference-type contains the definitions for representation of the conference object capabilities, membership, roles, call signaling and media status relevant to different stages of the conference life-cycle. New centralized conferencing specifications can extend the basic conference-type and introduce additional data elements to be used within the common conference information type. Barnes, et al. Expires September 2, 2006 [Page 11] Internet-Draft XCON Framework Mar 2006 5.2. Conference Template The concept of a conference template is introduced to separate the complexity and the details of the "mixer" and other enhanced conferencing features from the common conference information and to allow for easy user interface abstraction for advanced conferencing systems. Each conference template needs to be registered with IANA. The IANA registration needs to point to an RFC having the text description of the feature behavior and the XML definition allowing the feature presentation, configuration, and management. The RFCs defining these templates are referred to as a registered conference document. Typically, a conference template would contain the information about the specific media mixing details, the associated client roles and the available floor controls. This information would allow authorized clients to manipulate the mixer's behavior via the focus, and the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or state of other participants in the conference. A conference template can also include an abstract user interface definition in terms of sliders, radio boxes, etc. for simplifying user interaction with a specific non-trivial feature. The addition of new elements or the modification of the controls within an element of an existing template requires the definition of a new template. 5.3. Conference policies Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object. The set of rights describes the read/write access privileges for the conference object as a whole. This access would usually be granted and defined in terms of giving the read-only or read-write access to clients with certain roles in the conference. As such, the policies represented by the set of rights aren't explicitly defined within the data model, but rather are reflected in the system realization (Section 7). The permissions and limits, however, are specified as an integral part of the conference object type, with data objects containing the allowed ranges for other data objects (e.g., maximum number of participants) and lists of clients allowed to perform certain Barnes, et al. Expires September 2, 2006 [Page 12] Internet-Draft XCON Framework Mar 2006 operations on a conference object. For example, the "allowed to join" list of participants is consulted to decide who is allowed to join. The entries in the list can specify the identity of an individual user (joe@example.com), a role, a domain (*@example.com), etc. For further details, refer to the detailed data model [ref: TBD]. A more general rule mechanism, beyond the functionality provided by the permissions and limits, is an item for future study. 6. Centralized Conferencing Constructs and Identifiers This section provides details of the identifiers associated with the centralized conferencing framework constructs and the identifiers necessary to address and manage the clients associated with a conferencing system. An overview of the allocation, characteristics and functional role of the identifiers is provided. 6.1. Conference Identifier The conference identifier (conference ID) is a call signaling protocol-specific URI that identifies a specific conference focus and its associated conference instance. A conference factory is one method for generating a unique conference ID, to identify and address a conference focus, using a call signaling interface. Details on the use of a conference factory for SIP signaling can be found in [15]. The conference identifier can also be obtained using the conference control protocol [Section 8.3] or other, including proprietary, out- of-band mechanisms. 6.2. Conference Object A Conference object provides the logical representation of a conference iInstance in a certain stage, such as a conference blueprint representing a conferencing system's capabilities, the data representing a conference reservation, and the conference state during an active conference. Each conference object is independently addressable through the conference control protocol interface [Section 8.3]. Figure 3 illustrates the relationships between the conference identifier, the focus and the conference object ID within the context of a logical conference instance, with the conference object corresponding to an active conference. A conference object representing a conference in the active state can have multiple call signalling conference identifiers; for example, Barnes, et al. Expires September 2, 2006 [Page 13] Internet-Draft XCON Framework Mar 2006 for each call signalling protocol supported. There is a one-to-one mapping between an active conference object and a conference focus. The focus is addressed by explicitly associating unique conference IDs for each signaling protocol supported by the active conference object. ...................................................................... . Conference Instance . . . . . . +---------------------------------------------------+ . . | Conference Object Identifier | . . | | . . | | . . +---------------------------------------------------+ . . ^ ^ . . | | . . v | . . ................................................... | . . . Focus . | . . . . | . . . +----------------------------------+ . | . . . |Conference Identifier (Protocol Y)| . | . . . +------------------------------------+ | . | . . . | Conference Identifier (PSTN) | | . | . . . +--------------------------------------+ |-+ . | . . . | Conference Identifier (SIP) | |^ . | . . . | |-+| . | . . . | |^ | . | . . . +--------------------------------------+| | . | . . ............^...............................|.|.... | . . | | | | . ................|...............................|.|......|............ | | | | |SIP | | |Conference | PSTN | |Y |Control | | | |Protocol | +---------------+ | | | | | | | | | | v v v v +----------------+ +--------------+ +---------------+ | Conferencing | | Conferencing | | Conference | | Client | | Client | | Client | | 1 | | 2 | | X | +----------------+ +--------------+ +---------------+ Barnes, et al. Expires September 2, 2006 [Page 14] Internet-Draft XCON Framework Mar 2006 Figure 3: Identifier Relationships for an Active Conference. 6.2.1. Conference Object Identifier In order to make each conference object externally accessible, the conferencing system allocates a unique URI per distinct conference object in the system. A conference control protocol includes the conference object identifier in requests for directly manipulating a particular conference object and for obtaining its current state. The conference object identifier logically maps to other protocol specific identifiers associated with the conference instance, such as the BFCP 'confid'. A full description and semantics of how the conference object identifier is created and used is defined in Section 15. 6.3. Conference User Identifier Each user within a conferencing system is allocated a unique conference user identifier. The user identifier is used in association with the conference object identifier to uniquely identify a user within the scope of conferencing system. There is also a requirement for identifying conferencing system users who may not be participating in a conference instance. Examples of these users would be a non participating 'Floor Control Chair' or 'Media Policy Controller'. The conference user identifier is required in conference control protocol requests to uniquely determine who is issuing commands, so that appropriate policies can be applied to the requested command. The conference user identifer is logically associated with the other user identifiers assigned to the conferencing client for other protocol interfaces, such as an authenticated SIP user. A full description and semantics of the conference user identifier is provided in Section 16 7. Conferencing System Realization Implementations based on this centralized conferencing framework can range from systems supporting ad-hoc conferences, with default behavior only, to sophisticated systems with the ability to schedule recurring conferences, each with distinct characteristics, being integrated with external resource reservation tools, and providing snapshots of the conference information at any of the stages of the conference life-cycle. A conference object is the logical representation of a conference instance at a certain stage, such as capabilities description upon conference creation, reservation, activation, etc., which a conferencing system maintains in order to describe the system Barnes, et al. Expires September 2, 2006 [Page 15] Internet-Draft XCON Framework Mar 2006 capabilities and to provide access to the available services provided by the conferencing system. Consequently, this centralized conferencing framework does not mandate the actual usage of the conference object, but rather defines the general cloning tree concept and the mechanisms required for its realization, as described in detail in Section 7.1. Adhoc and advanced conferencing examples are provided in Section 7.2 and Section 7.3, with the latter providing additional description of the Conference Object in terms of the stages of a conference, to support scheduled and other advanced conference capabilities. The scheduling of a conference based on these concepts and mechanisms is then detailed in Section 7.4 As discussed in Section 5.3, there are conference policies implicit in and derivable from the data in the conference objects and there are also policies applying to the conference objects as a whole. In the examples in this section, these latter policies are shown logically associated with the conference objects, however, it is an implementation specific mechansim as to how these policies are managed and applied to the conference objects. 7.1. Cloning Tree The concept defined in this section is a logical representation only, as it is reflected through the centralized conferencing mechanisms: the URIs and the protocols. Of course, the actual system realization can differ from the presented model. The intent is to illustrate the role of the logical elements in providing an interface to the data, based on conferencing system and conferencing client actions, and describe the resultant protocol implications Any conference object in a conferencing system is created by either being explicitly cloned from an existing parent object or being implicitly cloned from a default system conference blueprint. A conference blueprint is a static conference object used to describe a typical conference setting supported by the system. Each system can maintain multiple blueprints, typically each describing a different conferencing type using the common conference information format, along with any number of template definitions This document uses the "cloning" metaphor instead of the "inheritance" metaphor because it more closely fits the idea of object replication, rather than a data type re-usage and extension concept. The cloning operation needs to specify whether the link between the parent and the child needs to be maintained in the system or not. If no link between the parent and the child exists, the objects become independent and are not impacted by any operations on the parent Barnes, et al. Expires September 2, 2006 [Page 16] Internet-Draft XCON Framework Mar 2006 object nor subject to any limitations of the parent object. Once the new object is created, it can be addressed by a unique conference object URI assigned by the system, as described in Section 15 /[ref:TBD]. By default, the newly created object contains all the data existing in the parent object. The newly created object can expand the data it contains, within the schema types supported by the parent. It can also restrict the read/write access to its objects. However, unless the object is independent, it cannot relax the access relative to its parent's access. Any piece of data in the child object can be independently accessed and, by default, can be independently modified without affecting the parent data. Unless the object is independent, the parent object can enforce a different policy by marking certain data elements as "parent enforceable". The values of these data elements can not be changed by directly accessing the child object; neither can they be expanded in the child object alone. Figure 4 illustrates an example of a conference (Parent B), which is created independent of its Parent (Parent A). Parent B creates two child objects, Child 1 and Child 2. Any of the data elements of Parent B can be modified (i.e. there are no "parent enforceable" data elements) and depending upon the element, the changes will be reflected in Child 1 and Child 2 , whereas changes to Parent A will not impact the data elements of Parent B. Any "parent enforceable" data elements as defined by Parent B cannot be modified in the child objects. Barnes, et al. Expires September 2, 2006 [Page 17] Internet-Draft XCON Framework Mar 2006 +---+-----------------------+ | p | | | o | P A R E N T A | | l | | | i | C O N F E R E N C E | | c | | | i | O B J E C T | | e | | +-s-+-----------------------+ | \| / \/ INDEPENDENT /\ /| \ V +---+-----------------------+ | p | | | o | P A R E N T B | | l | | | i | C O N F E R E N C E | | c | | | i | O B J E C T | | e | | +-s-+-----------------------+ | | | | | --------------------------- | | V V +---+-----------------------+ +---+-----------------------+ | p | | | p | | | o | C H I L D 1 | | o | C H I L D 2 | | i | | | l | | | l | C O N F E R E N C E | | i | C O N F E R E N C E | | i | | | c | | | c | O B J E C T | | i | O B J E C T | | i | | | e | | +-s-+-----------------------+ +-s-+-----------------------+ Figure 4: The Cloning Tree. Using the defined cloning model and its tools, the following sections show examples of how different systems based on this framework can be realized. Barnes, et al. Expires September 2, 2006 [Page 18] Internet-Draft XCON Framework Mar 2006 7.2. Ad-hoc Example Figure 5 illustrates how an ad-hoc conference can be created and managed in a conferencing system. A client can create a conference by establishing a call signaling channel with a conference factory as specified in Section 6.1. The conference factory can internally select one of the system supported conference blueprints based on the requesting client privileges and the media lines included in the SDP body. The selected blueprint with its default values is copied by the server into a newly created conference object, referred to as an 'Active Conference'. At this point the conference object becomes independent from its blueprint. A new conference object identifier, a new conference identifier and a new focus are allocated by the server. During the conference lifetime, an authorized client can manipulate the conference object, such as adding participants, using the Conference Control Protocol [Section 8.3]. +---+-----------------------+ | p | | | o | System Default | | l | | | i | Conference | | c | | | i | Blueprint | | e | | +-s-+-----------------------+ | \| / \/ /\ /| \ V +---+-----------------------+ | p | | | o | Active | | l | | | i | Conference | | c | | | i | | | e | | +-s-+-----------------------+ Barnes, et al. Expires September 2, 2006 [Page 19] Internet-Draft XCON Framework Mar 2006 Figure 5: Conference Ad-hoc Creation and Lifetime. 7.3. Advanced Example Figure 6 illustrates how a recurring conference can be specified according to system capabilities, scheduled, reserved, and managed in a conferencing system. A client would first query a conferencing system for its capabilities. This can be done by requesting a list of the conference blueprints the system supports. Each blueprint contains a specific combination of capabilities and limitations of the conference server in terms of supported media types (e.g., audio, video, text, or combinations of these), participant roles, maximum number of participants of each role, availability of floor control, controls available for participants, availability and type of sidebars, the definitions and names of media streams, etc. As defined within this framework, a blueprint is comprised of the common conference information and a template. A blueprint consists of a single template, as the template approach allows for defining combinations of media types in a single template [ref]. Whether a blueprint needs to additionally support multiple templates, and the associated mechanism, is for future study. The template within the blueprint can either be included by-value or by-reference depending upon the system implementation. In the case of a template included by-reference within a blueprint, a client may need to query a template that it doesn't understand and then make a decision on compatibility. Interface hints need to be included as per [20]. In this case, a client selects the specific blueprint to use and retrieves the associated template from the conferencing system itself, rather than from a centralized repository. The selected blueprint with its default values is cloned by the client into a newly created conference object, referred to as a conference reservation, that specifies the resources needed from the system for this conference instance. At this point the conference reservation becomes independent from its blueprint. The client can also change the default values, within the system ranges, and add additional information, such as the list of participants and the conference start time, to the conference reservation. At this point the client can ask the conference server to create new conference reservations by attaching the conference reservation to the request. As a result, the server can allocate the needed resources, create the additional conference objects for the child conference reservations and allocate the conference object identifiers for all - the original conference reservation and for each child conference reservation. Barnes, et al. Expires September 2, 2006 [Page 20] Internet-Draft XCON Framework Mar 2006 From this point on, any authorized client is able to access and modify each of the conference objects independently. By default, changes to an individual child conference reservation will affect neither the parent conference reservation, from which it was created, nor its siblings. On the other hand, some of the conference sub-objects, such as the maximum number of participants and the participants list, can be defined by the system as parent enforceable. As a result, these objects can be modified by accessing the parent conference reservation only. The changes to these objects can be applied automatically to each of the child reservations, subject to local policy. Barnes, et al. Expires September 2, 2006 [Page 21] Internet-Draft XCON Framework Mar 2006 +---+-----------------------+ | p | | | o | Selected | | l | | | i | Conference | | c | | | i | Blueprint | | e | | +-s-+-----------------------+ | \| / \/ /\ /| \ V +---+-----------------------+ | p | | | o | Conference | | l | | | i | Reservation | | c | | | i | | | e | | +-s-+-----------------------+ | | | | | | | | | | | | +---|--|--V-----------------+ +-+---|--V------------------+ | +-+-+---V-------------------+ | | | p | | | | | o | Child Conference | | | | l | | | | | i | Reservation | | | | c | | | | | i | | |-+ | e | |-+ +-s-+-----------------------+ Figure 6: Advanced Conference Definition, Creation, and Lifetime. When the time comes to schedule the conference reservation, either via the system determination that the 'start' time has been reached or via client invocation, an active conference is cloned based on the conference reservation. As in the adhoc example, the active conference is independent from the parent and changes to the Barnes, et al. Expires September 2, 2006 [Page 22] Internet-Draft XCON Framework Mar 2006 conference reservation will not impact the active conference. Any desired changes must be targeted towards the active conference. An example of this interaction is shown in Section 9.1 7.4. Scheduling a conference The capability to schedule conferences forms an important part of the conferencing system solution. An individual conference reservation typically has a specified 'start' and 'end' time, with the times being specified relative to a single specified 'fixed' time (e.g., 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system considerations. In most advanced conferencing solutions it is possible to not only schedule an individual occurrence of a conference reservation, but also schedule a series of related conferences (e.g., a weekly meeting that starts on Thursday at 09.00 GMT). To be able to achieve such functionality, a conferencing system needs to be able to appropriately schedule and maintain conference reservations that form part of a recurring conference. The mechanism proposed in this document makes use of the 'Internet Calendaring and Scheduling Core Object' specification defined in RFC2445[8] in union with the concepts introduced in Section 5 for the purpose of achieving advanced conference scheduling capability. Figure 7 illustrates a simplified view of a client interacting with a conferencing system. The client is using the Conference Control Protocol (Section 8.3) to add a new conference reservation to the conferencing system by interfacing with the conference control server. A CCP request contains a valid conference reservation and reference by value to an 'iCal' object which contains scheduling information about the conference (e.g., start time, end time). Barnes, et al. Expires September 2, 2006 [Page 23] Internet-Draft XCON Framework Mar 2006 +--------------+ +-------Conferencing System-----------------+ | Generic ICAL | | | | Resource | | ..Conference Instance.... | +--------------+ | . . +-----------+| ^ ^ | . +-------------------+ . | Conference|| | | | . |Conference Objects |<--| Control || | ----------------->. +-------------------+ . | Server || | | . . +-----------+| | | ......................... ^ | | | ^ | | +-----|--------------+ | | | | v | | | | +--------------+ | | | | | Resource |<------------------+ | | | | Scheduler | | | | +--------------+ | | | | | +---------------------------------------------------------|------+ | | +-Request-+ | | +----+ | |ICAL| | +----+----+ | | | Conference Control| Protocol | | +-------------+ | Conferencing| | Client | +-------------+ Figure 7: Resource Scheduling A CCP request to create a new conference reservation is validated, including the associated iCal object, and the resultant conference reservation is created. The conference reservation is uniquely represented within the conferencing system by a conference object identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and defined in [ref:TBD]. This unique URI is returned to the client and can be used to reference the conference reservation, if any future manipulations are required (e.g., alter start time), using a CCP request. Barnes, et al. Expires September 2, 2006 [Page 24] Internet-Draft XCON Framework Mar 2006 The previous example explains how a client creates a basic conference reservation using an iCal reference in association with a conference control protocol. Figure 7 can also be applied when explaining how a series of conferences are scheduled in the system. The description is almost identical with the exception that the iCal definition that is included in a CCP request represents a series of recurring conference instances (e.g., conference start time, end time, occur weekly). The conferencing system will treat this request the same as the first example. The CCP request will be validated, along with the associated iCal object, and the conference reservation is created. The conference reservation and its conference object ID created for this example represent the entire series of recurring conference instances rather than a single Conference. If the client uses the conference object ID provided and a CCP request to adjust the conference reservation, every conference instance in the series will be altered. This includes all future occurrences, such as a conference scheduled as an infinite series, subject to the limitations of the available calendaring interface. A conferencing system that supports the scheduling of a series of conference instances should also be able to support manipulation within a specific range of the series. A good example is a conference reservation that has been scheduled to occur every Monday at 09.00 GMT. For the next three weeks only, the meeting has been altered to occur at 10.00 GMT in an alternative venue. With Figure 7 in mind, the client will construct a CCP request whose purpose is to modify the existing conference reservation for the recurring conference instance. The client will include the conference object ID provided by the conferencing system to explicitly reference the conference reservation within the conferencing system. A CCP request will contain all the required changes to the conference reservation (e.g., change of venue). The conferencing system matches the incoming CCP request to the existing conference reservation but identifies that the associated iCal object only refers to a range of the existing series. The conferencing system creates a child, by cloning the original conference reservation, to represent the altered conference instances within the series. The cloned child object is not independent of the original parent object, thus preventing any potential conflicts in scheduling (e.g., a change to the whole series 'start time'). The cloned conference reservation, representing the altered series of conference instances, has its own associated conference object ID which is returned to the client using a CCP response. This conference object ID is then used by the client to make any future alterations on the newly defined sub-series. This process can be repeated any number of times as the newly returned conference object ID representing an altered (cloned) series of conference instances, Barnes, et al. Expires September 2, 2006 [Page 25] Internet-Draft XCON Framework Mar 2006 can itself be manipulated using a CCP request for the newly created conference object ID . This provides a flexible approach to the scheduling of recurring conference instances. 8. Conferencing Mechanisms 8.1. Call Signaling The focus is the central component of the conference. Participants interface with the focus using an appropriate call signaling protocol. Participants request to establish or join a conference using the call interface. After checking the applicable policies, a focus then either accepts the request, sends a progress indication related to the status of the request (e.g., for a parked call while awaiting moderator approval to join) or rejects that request using the call signaling interface. During an active conference, a Conference Control Protocol [Section 8.3] can be used to affect the conference state. For example, CCP requests to add and delete participants are communicated to the focus and checked against the conference policies. If approved, the participants are added or deleted using the call signaling to/from the focus. 8.2. Notifications A conferencing system is responsible for implementing a Conference Notification Service. The Conference Notification Service provides updates about the conference instance state to authorized parties, including participants. A model for notifications using SIP is defined in [11]. The conference user identifier and associated role are used by the conferencing system to filter the notifications such that they contain only information that is allowed to be sent to that user. 8.3. Conference Control Protocol The conference control protocol provides for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object. The details of the conference control protocol are detailed in separate documents [references TBD]. [Editor's note: The remaining paragraphs and subsections of this section, detailing the various protocol options should be pruned from this document, once the WG reaches consensus on the conference control protocol.] Barnes, et al. Expires September 2, 2006 [Page 26] Internet-Draft XCON Framework Mar 2006 8.3.1. CCCP A Centralized Conferencing Control Protocol [19] is a semantic- oriented protocol defined to allow participants or otherwise authorized entities to directly manipulate an active conference instance. CCCP is defined as a set of transactions issued over a reliable transport protocol. A transaction consists of a Request carrying the required information in an XML body and a corresponding Response carrying an appropriate XML body. CCCP requests are submitted to the CCCP server and can be prioritized and queued, based on the CCCP client Role and the requested primitives. CCCP requires no single lock per document, and the CCCP server can locally implement an optimization strategy independent of CCCP client behavior. 8.3.2. CSCP A Conference State Change protocol [25] is a client server protocol used to change the state of a conference object. CSCP extends the BFCP protocol [16] with new commands. A client sends the server a request representing a sequence of commands. Each command can set, get, add, or delete a single field in the conference object. Changes to the conference object are performed on a hierarchal set of elements and unique attributes within those elements. A series of changes can be pipelined in a single BFCP message. The server executes each action in series. If one of them fails, the server returns an error for the action that failed and does not execute any of the actions after that. Each individual action is atomic but the pipelined series is not. The item to which a command applies is specified by a unique ID and, where appropriate, attribute name. The ID is an unsigned 32 bit integer called the Element ID. The server discovery of the Element ID is outside of CSCP. Typically this is done by using the conference notification service per Section 8.2. Each field in the data received in the notification contains a unique field ID attribute that can be used in BFCP requests. 8.3.3. SOAP The SOAP protocol is fundamentally an XML messaging scheme, capable of supporting remote procedure calls. SOAP defines a simple message format composed of a "header" and a "body" contained within an "envelope". The "header" contains meta-information relating to the message, and can be used to indicate such things as store-and-forward behaviour or transactional characteristics. In addition, SOAP encoding is optimized for ease of automated deserialization. Barnes, et al. Expires September 2, 2006 [Page 27] Internet-Draft XCON Framework Mar 2006 SOAP [17] and [18] is proposed as the mechanism for object content manipulation and state retrieval for the centralized conferencing data. In general, SOAP is a good fit for Conference Control, essentially because of its remote procedure call characteristics and its inherently synchronous and client-driven nature. 8.4. Floor Control A floor control protocol allows an authorized client to manage access to a specific floor and to grant, deny or revoke access of other conference users to that floor. Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. A mechanism for floor control within a conferencing system is defined in the Binary Floor Control Protocol specification [16]. [Editor's note: Evaluation of an alternative proposal, as a stand alone draft, for using Templates as the means for correlating Floor Control identifiers has been proposed. If/when this work is done, it needs to be introduced and referenced here]. Within this framework, a client supporting floor control needs to obtain information for connecting to a floor control server to enable it to issue floor requests. This connection information can be retrieved using information provided by mechanisms such as negotiation using the SDP[2] offer/answer[5] exchange on the signaling interface with the focus. Section 11.3 provides a discussion of client authentication of a floor control server. As well as the client to the floor control server connection information, a client wishing to interact with a floor control server requires access to additional information. This information associates floor control interactions with the appropriate floor instance. Once a connection has been established and authenticated (see [16] for authentication details), a specific floor control message requires detailed information to uniquely identify a conference, a user and a floor. The conference is uniquely identifed by the conference object ID per Section 6.2.1. This conference object ID must be included in all floor control messages. When the SDP model is used as described in [23] this identifier maps to the 'confid' SDP attribute. Each authorized user associated with a conference object is uniquely represented by a conference user ID per Section 6.3. This conference user ID must be included in all floor control messages. When using SDP offer/answer exchange to negotiate a Floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'userid' SDP attribute, as Barnes, et al. Expires September 2, 2006 [Page 28] Internet-Draft XCON Framework Mar 2006 defined in [23] A media session witin a conferencing system can have any number of floors (0 or more) that are represented by the conference identifer. When using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 . Each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers. The identifiers represent individual SDP media sessions (as defined using 'm=' from SDP) using the SDP 'Label' attribute as defined in [22]. 9. Conferencing Scenario Realizations This section addresses how advanced conferencing scenarios, many of which have been described in [14], are realized using this centralized conferencing framework. The objective of this section is to further illustrate the model, mechanisms and protocols presented in the previous sections and also serves to validate that the model, mechanisms and protocols are sufficient to support advanced conferencing scenarios. The details shown in the messages are for illustrative purposes only and don't reflect the structure of the conference control protocol messages, but rather provide a high level primitive view of the necessary operations and general logic flow, including the data manipulation aspects. It should be noted that not all entities impacted by the request are shown in the diagram (e.g., Focus), but rather the emphasis is on the new entities introduced by this centralized conferencing framework. 9.1. Conference Creation There are different ways to create a conference. A participant can create a conference using call signaling means only, such as SIP and detailed in [15]. For a conferencing client to have more flexibility in defining the charaterisitics and capabilities of a conference, a conferencing client would implement a conference control protocol client. By using a conference control protocol, the client can determine the capabilities of a conferencing system and its various resources. Figure 8 provides an example of one client "Alice" determining the conference blueprints available for a particular conferencing system and creating a conference based on the desired blueprint. Barnes, et al. Expires September 2, 2006 [Page 29] Internet-Draft XCON Framework Mar 2006 +--------------------------------+ | Conferencing System | "Alice" | +------------+| +--------+ | | || | |CCP Request | +-----------+ | || | Client |-------------------------->|Conference | |Conference || | |<--------------------------|Control |~~~>|Blueprint(s)|| +--------+CCP Response | | "Alice" | +--------+ | | | |CCP Request |Conference | |Conference || | | confUserID> | |Control |~~~>|BlueprintA || | |<--------------------------|Server | | || | |CCP Response | | | +------------+| +--------+ | | | /|\ | | | | V | | | | +------------+| | | |~~~>|Conference || | | | |Reservation || | +-----------+ +------------+| "Alice" | | | +--------+ | | | | |CCP Request |Conference | |Active || | | confID,confUserID> | |Control |~~~>|Conference || | |<--------------------------|Server | | || | |CCP Response | | | +------------+| +--------+ | +-----------+ | +--------------------------------+ Figure 8: Client Creation of Conference using Blueprints Upon receipt of the Conference Control Protocol request for blueprints, the conferencing system would first authenticate "Alice" (and allocate a conference user identifier, if necessary) and then Barnes, et al. Expires September 2, 2006 [Page 30] Internet-Draft XCON Framework Mar 2006 ensure that "Alice" has the appropriate authority based on system policies to receive any blueprints supported by that system. Any blueprints that "Alice" is authorized to use are returned in a response, along with the conference user ID. Upon receipt of the Conference Control Protocol response containing the blueprints, "Alice" determines which blueprint to use for the conference to be created. "Alice" creates a conference object based on the blueprint (i.e., clones) and modifies applicable fields, such as membership list and start time. "Alice" then sends a request to the conferencing system to create a conference reservation based upon the updated blueprint. Upon receipt of the Conference Control Protocol request to "reserve" a conference based upon the blueprint in the request, the conferencing system ensures that the blueprint received is a valid blueprint (i.e. the values of the various field are within range). The conferencing system determines the appropriate read/write access of any users to be added to a conference based on this blueprint (using membership, roles, etc.). The conferencing system uses the received blueprint to clone a conference reservation. The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the reservation through the conference instance. Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" has reserved a meetme conference bridge. Thus, "Alice" provides the conference information, including the necessary conference ID, to desired participants. When the first participant, including "Alice", requests to be added to the conference, an active conference and focus are created. The focus is associated with the conference ID received in the request. Any participants that have the authority to manipulate the conference would receive the conference object identifier of the active conference in the response. 9.2. Participant Manipulations There are different ways to affect a participant state in a conference. A participant can join and leave the conference using call signaling means only, such as SIP. This kind of operation is called "1st party signaling" and does not affect the state of other participants in the conference. Barnes, et al. Expires September 2, 2006 [Page 31] Internet-Draft XCON Framework Mar 2006 Limited operations for controlling other conference participants (a so called "3rd party control") through the Focus, using call signaling only, may also be available for some signaling protocols. For example, "Conferencing for SIP User Agents" [15] shows how SIP with REFER can be used to achieve this functionality. In order to perform richer conference control a user client needs to implement a conference control protocol client. By using a conference control protocol, the client can affect its own state, state of other participants, and state of various resources (such as media mixers) which may indirectly affect the state of any of the conference participants. Figure 9 provides an example of one client "Alice" impacting the state of another client "Bob". This example assumes an established conference. In this example, "Alice" wants to add "Bob" to the conference. +--------------------------------+ | Conferencing System | "Alice" | +---------+--+| +--------+ | |policies | || | |CCP Request < | +-----------+ +---------+ || | Client |-------------------------->|Conference | | Active || | | Conference Object ID, | |Control |~~~>|Conference || +--------+ Add, "Bob" > | |Server | | || | +-----------+ +-------+ || | |"Alice"| || "Bud" | ' ' '| +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| | |<-------------------------|Notification|<~~~| || | Client |. . ||Service | +-------+ || +--------+--+ . || | |"Bob" | || | |<----------------------| | +-------+----+| | Client |NOTIFY <"Bob"="added">|+------------+ | +--------+ +--------------------------------+ "Bob" Figure 9: Client Manipulation of Conference - Add a party Upon receipt of the Conference Control Protocol request to "add" a party ("Bob") in the specific conference as identified by the Barnes, et al. Expires September 2, 2006 [Page 32] Internet-Draft XCON Framework Mar 2006 conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also determine whether "Bob" is already a user of this conferencing system or whether he is a new user. If "Bob" is a new user for this conferencing system, a Conference User Identifier is created for Bob. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the conference is instigated through the Focus. Once the call signaling indicates that "Bob" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (including "Bob") may be notified of the addition of "Bob" to the conference via the Conference Notification Service. 9.3. Media Manipulations There are different ways to manipulate the media in a conference. A participant can change its own media streams by, for example, sending re-INVITE with new SDP content using SIP only. This kind of operations is called "1st party signaling" and they do not affect the state of other participants in the conference. In order to perform richer conference control a user client needs to implement a conference control protocol client. By using a conference control protocol, the client can manipulate the state of various resources, such as media mixers, which may indirectly affect the state of any of the conference participants. Figure 10 provides an example of one client "Alice" impacting the media state of another client "Bob". This example assumes an established conference. In this example, the client, "Alice" whose Role is "moderator" of the conference, wants to mute "Bob" on a medium-size multi-party conference, as his device is not muted (and he's obviously not listening to the call) and background noise in his office environment is disruptive to the conference. Barnes, et al. Expires September 2, 2006 [Page 33] Internet-Draft XCON Framework Mar 2006 +--------------------------------+ | Conferencing System | "Alice" | +---------+--+| +--------+ | |policies | || | |CCP Request < | +-----------+ +---------+ || | Client |-------------------------->|Conference | |Active || | | Conference Object ID, | |Control |~~~>|Conference || +--------+ Mute, "Bob" > | |Server | | || | +-----------+ +-------+ || | |"Alice"| || | ' ' '| +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| | |<-------------------------|Notification|<~~~| || | Client |. . ||Service | +-------+ || +--------+--+ . || | |"Bob" | || | |<----------------------| | +-------+----+| | Client | NOTIFY <"Bob"=mute">|+------------+ | +--------+ +--------------------------------+ Figure 10: Client Manipulation of Conference - Mute a party Upon receipt of the Conference Control Protocol request to "mute" a party ("Bob") in the specific conference as identified by the conference object ID, the Conference Server ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. "Bob's" status is marked as "recvonly" and the Conference Template of the Conference Object (if included) is updated to reflect that "Bob's" media is not to be "mixed" with the conference media. Depending upon the policies, other participants (including "Bob") may be notified of this change via the Conference Notification Service. 9.4. Sidebar Manipulations A sidebar can be viewed as a separate Conference instance that only exists within the context of a parent conference instance. Although viewed as an independent conference instance, it can not exist without a parent. A sidebar is created using the same mechanisms employed for a standard conference as described in Section 7.1. A conference object representing a sidebar is created by cloning the parent associated with the existing conference and updating any information specific to the sidebar. A sidebar conference object is Barnes, et al. Expires September 2, 2006 [Page 34] Internet-Draft XCON Framework Mar 2006 implicitly linked to the parent conference object (i.e. it is not an independent object) and is associated with the parent conference object identifier as as shown in Figure 11. A conferencing system manages and enforces the parent and appropriate localized restrictions on the sidebar conference object (e.g., no members from outside the parent conference instance can join, sidebar conference can not exist if parent conference is terminated, etc.). +--------------+ | Conference | | Object | | Identifier | +--------------+ | | | +---------------------+---------------------+ | | | +-------+-------+ +-------+-------+ +-------+-------+ | Sidebar | | Sidebar | | Sidebar | | Conference | | Conference | | Conference | | Object | | Object | | Object | | Identifier | | Identifier | | Identifier | +-------+-------+ +-------+-------+ +---------------+ Figure 11: Conference Object Mapping. Figure 11 illustrates the relationship between a conference object and associated Sidebar conference objects within a conferencing system. Each Sidebar conference object has a unique conference object Identifier as described in Section 6.2.1. The main conference object identifier acts as a top level identifier for associated sidebars. A sidebar conference object Identifier follows many of the concepts outlined in the cloning tree model described in Section 7.1. A Sidebar conference object contains a subset of members from the original Conference object. Properties of the sidebar conference object can be manipulated by a Conference Control Protocol (Section 8.3) using the unique conference object identifier for the sidebar. It is also possible for the top level conference object to enforce policy on the sidebar object (similar to parent enforceable as discussed in Section 7.1). Figure 12 provides an example of one client "Alice" involved in active conference with "Bob" and "Bud". "Alice" wants to create a Barnes, et al. Expires September 2, 2006 [Page 35] Internet-Draft XCON Framework Mar 2006 sidebar to have a side discussion with "Bob" while still viewing the video associated with the main conference. "Alice" initiates the sidebar by sending a request to the conferencing system to create a conference reservation based upon the active conference object. Barnes, et al. Expires September 2, 2006 [Page 36] Internet-Draft XCON Framework Mar 2006 +--------------------------------+ | Conferencing System | | +---------+--+| | |policies | || | +---------+ || | |Active || | |Conference || "Alice" | +-------+ || +--------+ | |"Alice"| || | |CCP Req |Conference | +-------+ || | | confUserID> | |Control |~~~>|"Bud" | || | |<--------------------------|Server | +-------+----+| | |CCP Response | | | | | +--------+ | | | V | | | | +---------+--+| | | | |policies | || | | |~~~>+---------+ || | | | | || | +-----------+ | || "Alice" | | Sidebar || +--------+ | | Reservation|| | |CCP Request | |~~~>| || | | confID,confUserID, | | | +------------+| | | video=parent, | | | | | | | audio=sidebar> | |Conference | | | | | | |Control | V | | | | |Server | +---------+--+| | |CCP Response | | | |policies | || | | | | | |Sidebar || | | | |Conference || | +-----------+ +-------+ || | |"Alice"| || "Bob" | | | || +--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ || | |<-------------------------|Notification|<~~~| | || | Client | ||Service | |"Bob" | || +--------+ || | +-------+----+| |+------------+ | +--------------------------------+ Barnes, et al. Expires September 2, 2006 [Page 37] Internet-Draft XCON Framework Mar 2006 Figure 12: Client Creation of a Sidebar Conference Upon receipt of the Conference Control Protocol request to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. As discussed previously, the sidebar reservation is NOT independent of the active conference (i.e., parent). The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance. Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" to be involved in the sidebar, thus she manipulates the membership. Alice also only wants the video from the original conference and wants the audio to be restricted to the participants in the sidebar. Alice sends a conference control protocol request to update the information in the reservation and to create an active conference. Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring whether members like "Bob" are already a user of this conferencing system or whether he is a new user. If "Bob" is a new user for this conferencing system, a conference user identifier is created for Bob. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the conference is instigated through the Focus. Depending upon the policies, the participants in the sidebar (i.e., "Bob") may be notified of his addition to the sidebar via the conference notification service. 9.5. Whispering or Private Messages The case of private messages can be handled as a sidebar with just two participants, similar to the example in section Section 9.4, but rather than using audio within the sidebar, "Alice" could add an additional text based media stream to the sidebar. The other Barnes, et al. Expires September 2, 2006 [Page 38] Internet-Draft XCON Framework Mar 2006 context, referred to as whisper, in this document refers to situations such as when a announcement server injects a message targetted to specific user(s). The details of this mechanism within the context of the framework are TBD. 9.6. Conference Announcements and Recordings Each participant can require a different type of announcement and/or recording service from the system. For example, "Alice", the conference chair, could be listening to a roll call while "Bob" may be using a telephony user interface to create a sidebar. The conferencing system would also need to have the capability to monitor for DTMF from each individual participant. Further details of conference announcements and recordings, within the context of this framework, are TBD. 10. Relationships between SIPPING and Centralized Conferencing Frameworks The SIPPING Conferencing Framework [9] provides an overview of a wide range of centralized conferencing solutions known today in the conferencing industry. The document introduces a terminology and logical entities in order to systemize the overview and to show the common core of many of these systems. The logical entities and the listed scenarios in the SIPPING Conferencing Framework are being used to illustrate how SIP [4] can be used as a signaling means in these conferencing systems. SIPPING Conferencing Framework does not define new conference control protocols to be used by the general conferencing system. It uses only basic SIP [4], the SIP Conferencing for User Agents [15], and the SIPPING Conference Package [9] for basic SIP conferencing realization. This centralized conferencing framework document defines a particular centralized conferencing system and the logical entities implementing it. It also defines a particular data model and refers to the set of protocols (beyond call signaling means) being defined by the XCON WG to be used among the logical entities for implementing advanced conferencing features. The purpose of the XCON working group and this framework is to achieve interoperability between the logical entities from different vendors for controlling different aspects of advanced conferencing applications. The logical entities defined in the two frameworks are not intended to be mapped one-to-one. The two frameworks differ in the interpretation of the internal conferencing system decomposition and the corresponding operations. Nevertheless, the basic SIP [4], the Barnes, et al. Expires September 2, 2006 [Page 39] Internet-Draft XCON Framework Mar 2006 SIP Conferencing for User Agents [15], and the SIPPING Conference Package [9] are fully compatible with both Framework documents. 11. Security Considerations There are a wide variety of potential attacks related to conferencing, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the conferencing system. Examples of attacks include the following: an endpoint attempting to listen to conferences in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and theft of service, by an endpoint, in attempting to create conferences it is not allowed to create. There are several issues surrounding security of this conferencing framework. One set of issues involves securing the actual protocols and the associated authorization mechanisms. This first set of issues should be addressed in the specifications specific to the protocols described in Section 8. The protocols used for manipulation and retrieval of confidential information MUST support a confidentiality and integrity mechanism. Similar requirements apply for the floor control protocols. Section 11.3 discusses an approach for client authentication of a floor control server. There are also security issues associated with the authorization to perform actions on the conferencing system to invoke specific capabilities. Section 5.3 discusses the policies associated with the conference object to ensure that only authorized entities are able to manipulate the data to access the capabilities. The final set of issues involves the privacy and security of the identity of a user in the conference, which is discussed in Section 11.2 11.1. Authorization Many policy authorization decisions are based on the identity of the user or the role that a user may have. There are several ways that a user might authenticate its identity to the system. The conferencing system may know about specific users and assign passwords to the users. The users may also be authenticated by knowing a particular conference ID and a PIN for it. Sometimes, a PIN is not required and the conference ID is used as a shared secret. The call signaling means can provide a trusted form of the user identity or it might just provide a hint of the possible identity and the user still needs to provide some authentication to prove it has the identity that was provided as a hint in the call signaling. This may be in the form of an IVR system or other means. The goal for the conferencing system is to figure out a user identity and a role for any attempt to send a Barnes, et al. Expires September 2, 2006 [Page 40] Internet-Draft XCON Framework Mar 2006 request to the conferencing system. When a conferencing system presents the identity of authorized users, it may choose to provide information about the way the identity was proven to or verified by the system. A user may also come as a completely unauthenticated user into the system - this fact needs also be communicated to interested parties. When guest users interact with the system, it is often in the context of a particular conference. In this case, the user may provide a PIN or a password that is specific to the conferences and authenticates the user to take on a certain role in that conference. The guest user can then perform actions that are allowed to any user with that role. The term password is used to mean the usual, that is to say a reasonable sized, in number of bits, hard to predict shared secret. Today users often have passwords with more than 30 bits of randomness in them. PIN is a special password case - a shared secret that is only numeric and often contains a fairly small number of bits (often as few as 10 bits). When conferencing systems are used for audio on the PSTN, there is often a need to authenticate using a PIN. Typically if the user fails to provide the correct PIN a few times in a row, the PSTN call is disconnected. The rate of making the calls and getting to the point to enter a PIN makes it fairly hard to do an exhaustive search of the PIN space even for 4 digit PINs. When using a high speed interface to connect to a conferencing system, it is often possible to do thousands of attempts per second and the PIN space could quickly be searched. Because of this, it is not appropriate to use PINs for authorization on any of the interfaces that provide fast queries or many simultaneous queries. 11.2. Security and Privacy of Identity This conferencing system has an idea of the identity of a user but this does not mean it can reveal this identity to other users, due to privacy considerations. Users can set select various options for revealing their identity to other users. A user can be "hidden" such that other users can not see they are involved in the conference, or they can be "anonymous" such that users can see that another user is there, but not see the identity of the user, or they can be "public" where other users can see their identity. If there are multiple "anonymous" users, other parties will be able to see them as independent "anonymous" parties and will be able to tell how many "anonymous" parties are in the conference. Note, that the visibility to other participants is dependent on their roles. For example, users' visibility (including "anonymous" and "hidden") may be displayed to the moderator or administrator, subject to a Barnes, et al. Expires September 2, 2006 [Page 41] Internet-Draft XCON Framework Mar 2006 conferencing system's local policies. "Hidden" status is often used by robot participants of a conference (e.g., call recording) and is also used in many call center situations. 11.3. Floor Control Server Authentication Clients can authenticate a floor control server using the TLS certificates. Requests submitted on a successfully created connection between the client and floor control server may additionally require digest authentication within the BFCP protocol to authenticate the floor control client to the server. For this to take place, a shared secret needs to be exchanged between the floor control client/server entities. This can be achieved out of band using a mechanism such as the 'k=' SDP attribute. The shared secret can also be exchanged using un-specified 'out of band' mechanisms. When using Digest authentication of floor control client messages the exchange of an active 'Nonce' is also required. This can be achieved using a BFCP request response interaction as defined in BFCP (A request is submitted without a Nonce TLV and the server generates an error response with either an Error Code 7 (DIGEST TLV Required) or 6 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value can also be obtained 'out of band' using information provided in the offer/answer exchange. As with the other SDP Floor attributes referenced in this section and defined in [23], the 'nonce' attribute can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. [Editor's Note: May need more specifics on fetching from the conference object the credentials required for BFCP. This includes the conference id, user id, and password.] 12. IANA Considerations This is an informational draft, with no IANA considerations required. 13. Acknowledgements This document is a result of architectural discussions among IETF XCON working group participants. The authors would like to thank Henning Schulzrinne for the "Conference Object Tree" proposal and general feedback, Cullen Jennings for providing input for the "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews and constructive input. Barnes, et al. Expires September 2, 2006 [Page 42] Internet-Draft XCON Framework Mar 2006 14. Changes since last Version Changes from WG 02 to 03: - Updated the definition of Blueprint (per DP 4/4.1 discussions) - Added definition for Sidebar. - Section 5.2 Added text indicating that adding new elements or modifying elements requires the definition of a new template. (per DP4.2 conclusion). - Section 7.3. Added text reiterating that the blueprint comprises both the common conference information and a template (per DP4/4.1 discussions. - Section 7.3. Added text per resolution of DP 4.3 indicating that a blueprint is common conference information + one template and that multiple templates is FFS. - Section 8.3 - Updated Conference Control Protocol section to include the protocols on the table for WG discussion as of 31 Dec 2005 deadline. - Section 9.4 - Sidebars - added Ascii art to show FW interactions - Section 9.5 - Whisper - Added some text, reflecting past WG discussions. Basic definition and further details/example still needed. - Section 9.6 - Conf Anncs and Recordings - Added some basic text. Further details/example still needed. Changes from WG 01 to 02: - Editorial nits -i.e. consistent terminology, capatilization, etc. - Revamped abstract and introduction - Global removal of XCON as a qualifier (we had previously done this in a previous version with all the identifiers). - Global change of "call control signalling" to "call signaling" - Moved the terminology section after the Overview section: - - Modified the definitions to be more concise and per some of Henning's recommendations. Barnes, et al. Expires September 2, 2006 [Page 43] Internet-Draft XCON Framework Mar 2006 - - Added definitions for blueprint and conference reservation. - Clarified the definition of policy and added more explicit text as to how policy is accomplished via the data model and system realization (section 4.3 and 6.1) - Removed the Editor's note/text in section 4 about the options for the schema; added a reference to a TBD schema document. - Section 5: - - clarified the identifiers. Kept the logical definition as "identifiers", although most will be realized as URIs. - - deleted the section on conference instance. - - removed the term "umbrella" from sections conference User and conference object identifier sections - - moved alot of detail from Conference User Identifier and conference Object Identifier sections into appendices, and added additional detail, that will become the basis for separate documents. - In section 6: - - added a bit of explanation as to the intent of the cloning tree model - it's not implementation binding, but rather to illustrate the data model and context for the protocol interactions. - - removed the term copying altogether. Cloning is the model and the idea is that the cloned object contains data indentical to the parent when it was created (whether it gets "copied" or whatever from the parent is an implementation issue). - - introduce the blueprint concept in section 6.1 prior to its implied usage in 6.2 and 6.3. - - removed the usage of the term occurrence (which is just a child reservation). - Removed security related details from Floor Control section and moved those to the security section. As a result removed most of the editorial notes from the front of the Floor control section and integrated the remaining ones inline into that section, where the resolution should be documented. - Section 8: Barnes, et al. Expires September 2, 2006 [Page 44] Internet-Draft XCON Framework Mar 2006 - - Added new example 8.1 - conference creation - - Added a placeholder for a more detailed example to the sidebar section to show a sidebar which has some media specifically associated with the sidebar (i.e. audio), yet still use the main conference for other media (visual presentation). - Section 11: As a result of adding additional information to the security section, divided this section into subsections for clarity. Changes from WG 00 to 01:: - Section 2 (Conventions and Terminology). Slight modifications to definitions of Call (control) signaling, Conference Identifer, Conference Instance, Conference Object. - Section 2 (Conventions and Terminology).Renaming of term "Registered Template Definition" to "Registered Conference Document" (per agreement at interim meeting). - Section 3 (Next to the last paragraph on the media model). Clarified the text such that it doesn't read that the focus performs media mixing. Changed "focus" to "media mixer controlled by the focus" in the 2nd sentence and "performed" to "controlled" in the 4th. - Section 5. Rearranged the sub-sections a bit for better flow. First describe the Conference ID, then the Conference Instance, followed by the Conference Object, with the Conference Object Identifer described in a subsection of the Conference Object section. Added a diagram showing the relationship between Conference Identifer/Focus and Conference Object Identifier, within the context of a Conference Instance to the Conference Object section. - Section 6.1 (Cloning Tree). Rewording to clarify which operations apply to independent objects (and non-independent). - Section 6.3 (Advanced Example). Added additional text with regards to future conferences, introducing the concept of infinite series (which would be limited by calendaring interface). - Section 7.3 (Conference Control Protocol). Updated to include reference to SOAP option. - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit about the XCON FW constructs used. Changes from individual 02 to WG 00: Barnes, et al. Expires September 2, 2006 [Page 45] Internet-Draft XCON Framework Mar 2006 - few minor editorial changes - Section 2. Removed second sentence of definition of Conference ID, as that's now included/described in context in new Identifier section. - Section 3. Clarified that TBD in Figure 1 is "Conference Control Protocol" (per Keith's comment to be more explicit). - Section 4.1. Identifiers. Moved this to a new section ( Section 6). - New section for Identifiers ( Section 6), thus all section references beyond 4 are incremented in the new version. - Section 4. Since section 4.1 was removed, section 4.2 became the body text for section 4. - Section 4.2. Added "Floor Information" to Figure 2 as part of Common Conference Information, also added "Floor Control" to Conference Template (per text and Cullen's draft). - Section 4.5. Conference policies. Reworded to not introduce new terms, but use the general terms identified in the 1st paragraph. - Section 5.2. Removed "Instance" from "Active Conference Instance" in Figure 4. - Section 5.3. Added text clarifying that templates are retrieved from server (not central repository) (per DP3 conclusion). - Section 5.4. Added text that there is a single time and that the times are all relative the one time (per DP1 conclusion). - Section 5.4. Added text clarifying that changes to a series impact "all future occurrences (per DP1 discussion/conclusion). - Section 6.3 - Added subsections for discussion of CSCP and NETCONF as the CCP. - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. Condensed the text only slightly, but added explicit references to new identifier section. - Section 6.4.1 Moved to new Identifier section ( Section 6) - Section 7.1 - moved example to 7.2. Included a new (more appropriate example) in 7.1, although this may be too basic. Barnes, et al. Expires September 2, 2006 [Page 46] Internet-Draft XCON Framework Mar 2006 - Section 7.3 - added some proposed text for Sidebars. 15. Appendix A - Conference Object Identifier [Editors Note: This appendix will be incorporated in a separate specification in the next release of this document and will include all relevant detail.] The conference object URI can be viewed as a key to accessing a specific conference object. It is used by the Conference Control Protocol as described in Section 8.3 to access, manipulate and delete a conference object associated with a specific conference instance. A conference object identifier is provided to the Conference Control Client to enable such functions to be carried out. This can either be returned through the Conference Control Protocol while creating a conference object, be provided by the conference notification service or through out-of-band mechanisms (e.g. E-Mail). [Editors Note: Previous section to be expanded and more detail included. It also needs to link up with other drafts and explicitly reference.] A centralized conferencing system, as defined in the Conference Framework [ref] has potential to expose a range of interfaces and protocols. It is also possible that future centralized conferencing enhancements might place requirements to provide further additional protocols and interfaces. A conference object can consist and be associated with many identifiers that are in some way related to a conference object. Good examples include the Binary Floor Control Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each use unique identifiers to represent a protocol instance associated with a conference object. A conferencing system may maintain a relationship between the conference object URIs and the identifiers associated with each of the complementary centralized conferencing protocols (e.g., call signaling protocols, BFCP, etc.). To facilitate the maintenance of these relationships, the conference object URI acts as a top level identifier within the conferencing system for the purpose of identifying the interfaces for these other protocols. This implicit binding provides a structured mapping of the various protocols with the associated conference object identifier. Figure 13 illustrates the relationship between the identifiers used for the protocols within this framework and the general conference object identifier. Barnes, et al. Expires September 2, 2006 [Page 47] Internet-Draft XCON Framework Mar 2006 +--------------+ | Conference | | Object | | Identifier | +------+-------+ | | | +-----------------+---------------+ | | +-------+---------+ +-------+-------+ |CSP Conference ID| | BFCP 'confid' | +-----------------+ +---------------+ Figure 13: Conference Object Mapping. In Figure 13, the conference object identifier acts as the top level key in the identification process. The call signaling protocols have an associated conference ID representation in the form of URIs. The binary floor control protocol, as defined in [23], defines the 'conf-id' identifier which represents a conference instance within floor control. When created within the conferencing system, the 'conf-id' has a 1:1 mapping to the unique conference object Identifier. Operations associated with the Conference Control Protocols are directly associated with the conference object, thus the primary identifier associated with these protocols is the conference object identifier. The mappings between additional protocols/interface is not strictly 1:1 and does allow for multiple occurrences. For example, multiple call signaling protocols will each have a representation that is implicitly linked to the top level conference object identifier, for example, H323 and SIP URIs that represent a conference instance. It should be noted that a conferencing system is free to structure such relationships as required and this information is just included as a guideline that can be used. The following example illustrates the representation and relationships that might occur in a typical conference instance. The table in Figure 14 lists a typical conference instance and related properties. Barnes, et al. Expires September 2, 2006 [Page 48] Internet-Draft XCON Framework Mar 2006 +----------------------+------------------------+----------------------+ | Conf Obj URI | CSP URI | BFCP Conf-ID | +----------------------+------------------------+----------------------+ | xcon:Ji092i | sip:Ji092i@example.com | Ji092i | | | tel:+44(0)2920930033 | | | | h323:Ji092i@example.com| | +----------------------+------------------------+----------------------+ Figure 14: Conference Table Representation The information from Figure 14 can then be applied to the representation introduced in Figure 13. This results in Figure 15. +--------------+ | Conference | | Object | | Identifier | +--------------+ | xcon:Ji092i | +------+-------+ | | | +-----------------+---------------+ | | +-----------+-----------+ +-------+-------+ | CSP Conference IDs | | BFCP 'confid' | +-----------------------+ +---------------+ |h323:Ji092i@example.com| | Ji092i | |tel:+44(0)2920930033 | +-------+-------+ |sip:Ji092i@example.com | | +-----------------------+ +-------|-------+ | BFCP 'floorid | +---------------+ | UEK78d | | 09cnJk | +---------------+ Figure 15: Conference Tree Representation Further elements can be added to the tree representation in Figure 15 to enable a complete representation of a conference instance within a conferencing system. Barnes, et al. Expires September 2, 2006 [Page 49] Internet-Draft XCON Framework Mar 2006 This style of association can be applied to any supplementary protocols or conferencing mechanisms that are applied to the centralized conferencing model defined in this document as long as a unique reference per conference instance is available that can be mapped to a conference object. 15.1. Conference Object URI Definition [Editors Note: When the appendix split from the Framework document, full URI definition will be included. 16. Appendix B - Conference User Identifier [Editors Note: This appendix will be incorporated in a separate specification in the next release of this document and will include all relevant detail.] Each user within a conferencing system is allocated a unique conference user identifier. The user identifier is used in association with the conference object identifier defined in Section 15, and by the conference control protocol to uniquely identify a user within the scope of conferencing system. The conference control protocol uses the user identifier to uniquely determine who is issuing commands. Appropriate policies can then be applied to the requested command. As with the conference object identifier, a number of supplementary user identifiers defined in other protocols are used within a conference instance. Such user identifiers can be associated with this conference user identifier and enable the conferencing system to correlate and map these multiple authenticated user identities to the single user identifier. Figure 16 illustrates an example using the conference user identifier in association with the user identity defined for BFCP and SIP Digest user identity as defined in RFC3261[4], which would be used when SIP is the call signaling protocol. It should be noted that a conferencing system is free to structure such relationships as required and this information is just included as a guideline that can be used. Barnes, et al. Expires September 2, 2006 [Page 50] Internet-Draft XCON Framework Mar 2006 +---------------+ | Conference | | User | | Identifier | +-------+-------+ | | | +---------------+---------------+ | | +-------+-------+ +-------+-------+ | BFCP | | SIP Digest | | 'UserID' | | Username | +---------------+ +-------+-------+ Figure 16: Conference User Identifier Within a conferencing system, a user is identified by a single conference user identifier. Any additional conferencing mechanisms that contain a protocol specific user ID can be associated with the conference user identifier, as illustrated in Figure 16. This mechanism allows conferencing systems to manage and relate system wide user identities in relation to specific conference objects and helps in the enforcement of system wide policies. The following example illustrates the representation and relationships that might occur in a typical conference instance. The table in Figure 17 lists a typical representation of user identifier hierarchy and associations. +----------------+----------------+---------------+----------------+ | Conf User ID | BFCP User ID | SIP User ID | H323 User ID | +----------------+----------------+---------------+----------------+ | John | HK37ihdaj | 123674 | 928373 | +----------------+----------------+---------------+----------------+ Figure 17: User Identitier Representation The information from Figure 17 can then be applied to the representation introduced in Figure 16. This results in Figure 18. Barnes, et al. Expires September 2, 2006 [Page 51] Internet-Draft XCON Framework Mar 2006 +--------------+ | Conference | | User | | Identifier | +--------------+ | John | +------+-------+ | | | +---------------------+---------------------+ | | | +-------+--------+ +-------+-------+ +--------+-------+ | BFCP User ID | | SIP User ID | | H323 User ID | +----------------+ +---------------+ +----------------+ | HK37ihdaj | | 123674 | | 928373 | +----------------+ +-------+-------+ +----------------+ Figure 18: User ID Tree Representation Further elements can be added to the tree representation in Figure 15 to enable a complete representation of a conference instance within a conferencing system. 16.1. Conference User Definition [Editors Note: When the appendix is split from the Framework document, full definition will be included. 17. References 17.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 17.2. Informative References [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Barnes, et al. Expires September 2, 2006 [Page 52] Internet-Draft XCON Framework Mar 2006 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [8] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [9] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-05 (work in progress), May 2005. [10] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", draft-ietf-sipping-conferencing-requirements-01 (work in progress), October 2004. [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-12 (work in progress), July 2005. [12] Schulzrinne, H., "Requirements for Floor Control Protocol", draft-ietf-xcon-floor-control-req-03 (work in progress), October 2005. [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in progress), August 2004. [14] Even, R. and N. Ismail, "Conferencing Scenarios", draft-ietf-xcon-conference-scenarios-05 (work in progress), September 2005. [15] Levin, O., "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-07 (work in progress), Barnes, et al. Expires September 2, 2006 [Page 53] Internet-Draft XCON Framework Mar 2006 June 2005. [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-06 (work in progress), December 2005. [17] Schulzrinne, H., "COMP: Conference Object Manipulation Protocol", draft-schulzrinne-xcon-comp-00 (work in progress), January 2006. [18] Boulton, C. and M. Barnes, "Centralized Conferencing Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in progress), January 2006. [19] Levin, O., "Centralized Conference Control Protocol", draft-levin-xcon-cccp-04 (work in progress), January 2006. [20] Jennings, C. and B. Rosen, "Media Conference Server Control for XCON", draft-jennings-xcon-media-control-03 (work in progress), July 2005. [21] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", draft-rosen-xcon-conf-sidebars-01 (work in progress), July 2004. [22] Levin, O. and G. Camarillo, "The SDP (Session Description Protocol) Label Attribute", draft-ietf-mmusic-sdp-media-label-01 (work in progress), January 2005. [23] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), October 2004. [24] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-14 (work in progress), February 2006. [25] Jennings, C., "Conference State Change Protocol (CSCP)", draft-jennings-xcon-cscp-02 (work in progress), December 2005. [26] Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-11 (work in progress), February 2006. Barnes, et al. Expires September 2, 2006 [Page 54] Internet-Draft XCON Framework Mar 2006 Authors' Addresses Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX Email: mary.barnes@nortel.com Chris Boulton Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: oritl@microsoft.com Barnes, et al. Expires September 2, 2006 [Page 55] Internet-Draft XCON Framework Mar 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barnes, et al. Expires September 2, 2006 [Page 56]