XCON Working Group M. Barnes Internet-Draft Nortel Expires: April 4, 2006 C. Boulton Ubiquity Software Corporation O. Levin Microsoft Corporation Oct 2005 A Framework and Data Model for Centralized Conferencing draft-ietf-xcon-framework-02 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 April 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 April 4, 2006 [Page 1] Internet-Draft XCON Framework Oct 2005 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 . . . . . . . . . . . . . . . . . 22 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25 8.3.1. CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.3.2. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.3. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.4. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 28 8.3.5. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 30 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 30 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 32 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 34 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 35 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 37 9.6. Conference Announcements and Recordings . . . . . . . . . 37 10. Relationships between SIPPING and Centralized Conferencing Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 38 Barnes, et al. Expires April 4, 2006 [Page 2] Internet-Draft XCON Framework Oct 2005 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 39 11.3. Floor Control Server Authentication . . . . . . . . . . . 40 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 14. Changes since last Version . . . . . . . . . . . . . . . . . . 40 15. Appendix A - Conference Object Identifier . . . . . . . . . . 44 15.1. Conference Object URI Definition . . . . . . . . . . . . . 47 16. Appendix B - Conference User Identifier . . . . . . . . . . . 47 16.1. Conference User Definition . . . . . . . . . . . . . . . . 49 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 17.1. Normative References . . . . . . . . . . . . . . . . . . . 49 17.2. Informative References . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Intellectual Property and Copyright Statements . . . . . . . . . . 54 Barnes, et al. Expires April 4, 2006 [Page 3] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 4] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 5] Internet-Draft XCON Framework Oct 2005 ................................................................... . 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 April 4, 2006 [Page 6] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 7] Internet-Draft XCON Framework Oct 2005 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 comprised of the common conference information, along with any number of templates. 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 April 4, 2006 [Page 8] Internet-Draft XCON Framework Oct 2005 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 [25]). 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: TBD. Barnes, et al. Expires April 4, 2006 [Page 9] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 10] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 11] Internet-Draft XCON Framework Oct 2005 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. 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 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), Barnes, et al. Expires April 4, 2006 [Page 12] Internet-Draft XCON Framework Oct 2005 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, 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 Barnes, et al. Expires April 4, 2006 [Page 13] Internet-Draft XCON Framework Oct 2005 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 | +----------------+ +--------------+ +---------------+ Figure 3: Identifier Relationships for an Active Conference. Barnes, et al. Expires April 4, 2006 [Page 14] Internet-Draft XCON Framework Oct 2005 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 capabilities and to provide access to the available services provided by the conferencing system. Consequently, this centralized Barnes, et al. Expires April 4, 2006 [Page 15] Internet-Draft XCON Framework Oct 2005 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 object nor subject to any limitations of the parent object. Barnes, et al. Expires April 4, 2006 [Page 16] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 17] Internet-Draft XCON Framework Oct 2005 +---+-----------------------+ | 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 April 4, 2006 [Page 18] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 19] Internet-Draft XCON Framework Oct 2005 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. A client may need to query any templates in the blueprints that it doesn't understand and then make a decision on compatibility. Interface hints need to be included as per [21]. The client then selects which specific templates to use and retrieves the templates from the server 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. 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 Barnes, et al. Expires April 4, 2006 [Page 20] Internet-Draft XCON Framework Oct 2005 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. +---+-----------------------+ | 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. Barnes, et al. Expires April 4, 2006 [Page 21] Internet-Draft XCON Framework Oct 2005 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 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 April 4, 2006 [Page 22] Internet-Draft XCON Framework Oct 2005 +--------------+ +-------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 April 4, 2006 [Page 23] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 24] Internet-Draft XCON Framework Oct 2005 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 should be removed from this document once the WG reaches consensus and a high level overview of the requirements for the conference control protocol should be provided here. However, until Barnes, et al. Expires April 4, 2006 [Page 25] Internet-Draft XCON Framework Oct 2005 the WG reaches that consensus (and agrees the fundamental requirements) it seems premature to remove these details from this document.] The proposals for the conference control protocol under discussion span from data manipulation (management-like) protocols (CPCP and NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the proposed protocols are in the sections below. The following paragraphs summarize the fundamental issues around the selection of the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG mailing list]. It is recognized that semantic manipulations make for a cleaner protocol design, with the disadvantage that extensions to the underlying data model require extensions to the protocol used to manipulate it. Syntactic manipulations allow for extensions to the data model without requiring protocol extensions, with the disadvantage that the server generally has to infer intent from data manipulations instead of having intent explicitly signaled. It is worth noting that one portion of the data to be manipulated, the Common Conference Information, will not be extended, and would naturally lend itself to semantic manipulation. Another part of the data, the Conference Template, is intended to be extended, and would naturally lend itself to syntactic manipulation. However, there has been a stated desire to use a single protocol (and presumably a single mode of operation within this protocol) to manipulate all conference object state (common and template). The third statement in the paragraph above makes the first two solution options mutually exclusive. A proposal was made that by allowing more than one protocol, a hybrid approach could be taken such that CPCP and CSCP can both be used, since they are based on other protocols that are likely to be supported by the clients (XCAP and BFCP, respectively). However, the very rough consensus of the WG supports a single protocol for Conference Control and SOAP has most recently been put forth as that protocol. A basic overview of SOAP in the context of Conference control is provided in Section 8.3.5 8.3.1. CPCP A Conference Policy Control Protocol (CPCP) is a data manipulation protocol being proposed as a standard means of storing and manipulating the conference policy. According to CPCP, the conference policy is comprised of the rules associated with a specific conference instance. Requirements for the CPCP are defined in the CPCP Requirements document [13]. The Conference Policy Control Protocol document [17] defines the XML Schema for the Barnes, et al. Expires April 4, 2006 [Page 26] Internet-Draft XCON Framework Oct 2005 conference policy data elements. The privileges as to which users are allowed to read and/or manipulate a specific conference instance are defined in a separate Extensible Markup Language (XML) Schema[19]. This schema is based on the common policy model being used for geographic privacy information and for presence information. A separate document [18] proposes XCAP as one protocol mechanism for storing and manipulating this conferencing policy data. XCAP is a HTTP 1.1 based protocol that allows clients to read, write, modify and delete application data stored in XML format on a server. One of the main advantages of XCAP is that it maps XML document elements and attributes to HTTP URIs that can be directly accessed by HTTP. 8.3.2. CCCP A Centralized Conferencing Control Protocol [20] 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.3. CSCP A Conference State Change protocol [26] 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 Barnes, et al. Expires April 4, 2006 [Page 27] Internet-Draft XCON Framework Oct 2005 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.4. NETCONF The Network Configuration (NETFCONF) protocol [27] defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal, application programming interface (API). NETCONF is proposed as the mechanism for object content manipulation and state retrieval for the centralized conferencing data. NETCONF provides a flexible configuration retrieval mechanism, with extensibility. It allows for incremental configuration and commits. NETCONF supports stored configurations (e.g., for startup, running, etc.). It also supports XPath and subtree filtering. With NETCONF, there are no constraints on the configuration content. 8.3.5. 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. SOAP 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 Barnes, et al. Expires April 4, 2006 [Page 28] Internet-Draft XCON Framework Oct 2005 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 [24] 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 defined in [24] 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 [24] 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 [23]. Barnes, et al. Expires April 4, 2006 [Page 29] Internet-Draft XCON Framework Oct 2005 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. 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. 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. Barnes, et al. Expires April 4, 2006 [Page 30] Internet-Draft XCON Framework Oct 2005 +--------------------------------+ | 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 April 4, 2006 [Page 31] Internet-Draft XCON Framework Oct 2005 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 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 April 4, 2006 [Page 32] Internet-Draft XCON Framework Oct 2005 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. 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. +--------------------------------+ | 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" Barnes, et al. Expires April 4, 2006 [Page 33] Internet-Draft XCON Framework Oct 2005 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 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. It should be noted that only entities impacted by the request are shown in the diagram (e.g., there is no Focus shown). Barnes, et al. Expires April 4, 2006 [Page 34] Internet-Draft XCON Framework Oct 2005 +--------------------------------+ | 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 April 4, 2006 [Page 35] Internet-Draft XCON Framework Oct 2005 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). [Editor's Note: this needs more detail - especially around cloning tree, including an example scenario such as a sidebar which still Barnes, et al. Expires April 4, 2006 [Page 36] Internet-Draft XCON Framework Oct 2005 receives the visual media from the main conference, but has audio within the sidebar. The example would use some of the mechanisms shown in previous sections (e.g. create a new sidebar conference, cloned from the existing active conference, manipulate the media, add participants.] 9.5. Whispering or Private Messages [Editor's Note: TBD. Once we get full agreement on terminology and the basic ideas in the other sections, we'll tackle this.] 9.6. Conference Announcements and Recordings [Editor's note: TBD. Use Cullen's comments on the previous version of the doc .] 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 SIP Conferencing for User Agents [15], and the SIPPING Conference Barnes, et al. Expires April 4, 2006 [Page 37] Internet-Draft XCON Framework Oct 2005 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 request to the conferencing system. Barnes, et al. Expires April 4, 2006 [Page 38] Internet-Draft XCON Framework Oct 2005 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 conferencing system's local policies. "Hidden" status is often used by robot participants of a conference (e.g., call recording) and is Barnes, et al. Expires April 4, 2006 [Page 39] Internet-Draft XCON Framework Oct 2005 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 [24], 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. 14. Changes since last Version Changes from WG 01 to 02:: Barnes, et al. Expires April 4, 2006 [Page 40] Internet-Draft XCON Framework Oct 2005 - 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. - - 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). Barnes, et al. Expires April 4, 2006 [Page 41] Internet-Draft XCON Framework Oct 2005 - - 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: - - 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. Barnes, et al. Expires April 4, 2006 [Page 42] Internet-Draft XCON Framework Oct 2005 - 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: - 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). Barnes, et al. Expires April 4, 2006 [Page 43] Internet-Draft XCON Framework Oct 2005 - 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. - 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)[24] and call signaling protocols, such as SIP. Each use unique identifiers to represent a protocol instance associated with a conference object. Barnes, et al. Expires April 4, 2006 [Page 44] Internet-Draft XCON Framework Oct 2005 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 12 illustrates the relationship between the identifiers used for the protocols within this framework and the general conference object identifier. +--------------+ | Conference | | Object | | Identifier | +------+-------+ | | | +-----------------+---------------+ | | +-------+---------+ +-------+-------+ |CSP Conference ID| | BFCP 'confid' | +-----------------+ +---------------+ Figure 12: Conference Object Mapping. In Figure 12, 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 [24], 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 Barnes, et al. Expires April 4, 2006 [Page 45] Internet-Draft XCON Framework Oct 2005 can be used. The following example illustrates the representation and relationships that might occur in a typical conference instance. The table in Figure 13 lists a typical conference instance and related properties. +----------------------+------------------------+----------------------+ | Conf Obj URI | CSP URI | BFCP Conf-ID | +----------------------+------------------------+----------------------+ | xcon:Ji092i | sip:Ji092i@example.com | Ji092i | | | tel:+44(0)2920930033 | | | | h323:Ji092i@example.com| | +----------------------+------------------------+----------------------+ Figure 13: Conference Table Representation The information from Figure 13 can then be applied to the representation introduced in Figure 12. This results in Figure 14. +--------------+ | 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 | +---------------+ Barnes, et al. Expires April 4, 2006 [Page 46] Internet-Draft XCON Framework Oct 2005 Figure 14: Conference Tree Representation Further elements can be added to the tree representation in Figure 14 to enable a complete representation of a conference instance within a conferencing system. 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 15 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 April 4, 2006 [Page 47] Internet-Draft XCON Framework Oct 2005 +---------------+ | Conference | | User | | Identifier | +-------+-------+ | | | +---------------+---------------+ | | +-------+-------+ +-------+-------+ | BFCP | | SIP Digest | | 'UserID' | | Username | +---------------+ +-------+-------+ Figure 15: 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 15. 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 16 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 16: User Identitier Representation The information from Figure 16 can then be applied to the representation introduced in Figure 15. This results in Figure 17. Barnes, et al. Expires April 4, 2006 [Page 48] Internet-Draft XCON Framework Oct 2005 +--------------+ | Conference | | User | | Identifier | +--------------+ | John | +------+-------+ | | | +---------------------+---------------------+ | | | +-------+--------+ +-------+-------+ +--------+-------+ | BFCP User ID | | SIP User ID | | H323 User ID | +----------------+ +---------------+ +----------------+ | HK37ihdaj | | 123674 | | 928373 | +----------------+ +-------+-------+ +----------------+ Figure 17: User ID Tree Representation Further elements can be added to the tree representation in Figure 14 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 April 4, 2006 [Page 49] Internet-Draft XCON Framework Oct 2005 [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] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-07 (work in progress), Barnes, et al. Expires April 4, 2006 [Page 50] Internet-Draft XCON Framework Oct 2005 June 2005. [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-05 (work in progress), July 2005. [17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01 (work in progress), October 2004. [18] Khartabil, H., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usages for Conference Policy Manipulation and Conference Policy Privelges Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress), October 2004. [19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a Conference Policy", draft-ietf-xcon-conference-policy-privileges-01 (work in progress), October 2004. [20] Levin, O. and G. Kimchi, "Centralized Conference Data Model", draft-levin-xcon-cccp-02 (work in progress), February 2005. [21] Jennings, C. and B. Rosen, "Media Conference Server Control for XCON", draft-jennings-xcon-media-control-03 (work in progress), July 2005. [22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", draft-rosen-xcon-conf-sidebars-01 (work in progress), July 2004. [23] Levin, O. and G. Camarillo, "The SDP (Session Description Protocol) Label Attribute", draft-ietf-mmusic-sdp-media-label-01 (work in progress), January 2005. [24] 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. [25] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-12 (work in progress), October 2005. [26] Jennings, C. and A. Roach, "Conference State Change Protocol (CSCP)", draft-jennings-xcon-cscp-01 (work in progress), July 2005. Barnes, et al. Expires April 4, 2006 [Page 51] Internet-Draft XCON Framework Oct 2005 [27] Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-09 (work in progress), October 2005. Barnes, et al. Expires April 4, 2006 [Page 52] Internet-Draft XCON Framework Oct 2005 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 April 4, 2006 [Page 53] Internet-Draft XCON Framework Oct 2005 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 (2005). 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 April 4, 2006 [Page 54]