A Framework for Centralized Conferencing
Extracted elements (28)
Conference scheduling uses iCalendar (RFC 2445) objects referenced by value in CCP requests to carry start/end times and recurrence rules. A recurring series is represented by a single conference reservation; modifications to a sub-range are realized by cloning the parent into a non-independent child with its own conference object ID, preventing scheduling conflicts with the parent series.
The centralized conferencing model enforces a star-topology call signaling graph: each participant maintains a direct peer relationship with the focus. This simplifies membership enforcement and media negotiation. The framework notes that concepts could apply to decentralized (multicast/multi-unicast mesh) media topologies but leaves those details for future study.
The conference object identifier logically maps to other protocol-specific identifiers (e.g., BFCP 'confid') rather than requiring those protocols to use the URI natively. This mapping is treated as sensitive because it reveals internal conference topology and identifier associations to parties who should not have that visibility.
The framework uses a 'cloning' metaphor rather than 'inheritance' because it more closely fits object replication rather than data-type re-usage and extension. A cloned child conference object contains all parent data by default, may expand data within supported schema types, but cannot override parent-enforceable data elements unless the child is declared independent of its parent.
The same conference object type is reused for all lifecycle stages (blueprint, reservation, active, completed) rather than using separate schemas per stage. This allows conferencing systems to support a subset of conferencing functions while remaining framework-compliant, and allows read-only participants to consume the core conference-type defined in RFC 4575.
Floor control connection information is retrieved via SDP offer/answer exchange with the focus. The conference object ID maps to the BFCP 'confid' SDP attribute (RFC 4583), the conference user ID maps to 'userid', and each floor maps to a 'floorid' attribute containing 'm-stream' tags that reference SDP media sections via the 'Label' attribute (RFC 4574).
The Centralized Conferencing Framework is explicitly designed to be compatible with the SIP Conferencing Framework (RFC 4353). Section 10 describes the relationship; conferencing systems may use basic SIP-only conferencing (RFC 4579) for ad hoc conferences without any of the additional framework machinery defined in this document.
A conferencing system is REQUIRED to support SIP as the default call signaling protocol. Other call signaling protocols (e.g., ISUP, H.323) are OPTIONAL.
A conferencing system MUST be capable of allocating and distributing a conference user identifier during the first signaling interaction with the conferencing system. When a user joins via a dial-in signaling protocol (e.g., SIP), a conference user identifier MUST be assigned if one is not already associated with that user.
A conferencing system MUST provide a default blueprint representing the basic capabilities provided by that specific conferencing system.
Each user within a conferencing system MUST be allocated a unique conference user identifier. The conference user identifier is REQUIRED in conference control protocol requests to uniquely identify the requesting user for policy enforcement.
Once a conference is established, the conference object identifier MUST be used to manipulate any conferencing data or access advanced conferencing features. This applies regardless of the call signaling protocol used to initially join the conference.
The conferencing system MUST allocate a unique URI per distinct conference object in the system, covering every blueprint, every reservation, and every active conference.
The conferencing system MUST ensure appropriate access control around any internal data structure that maintains the persistent mapping between conference user identifiers and signaling-specific user identifiers; this information is typically available only to a conferencing system administrator.
A conference blueprint is a static conference object describing a typical conference setting supported by the system, including supported media types, participant roles, capacity limits, floor control availability, and sidebar definitions. Each system maintains one or more blueprints that serve as the basis for cloning conference reservations and active conferences.
A conference factory is a logical entity that generates unique URIs identifying a conference focus. The conference identifier (conference ID) is a call-signaling-protocol-specific URI that identifies a specific conference focus and its associated conference instance; it is protocol-specific (e.g., SIP URI, ISUP address).
A conference object provides the logical representation of a conference instance at a specific lifecycle stage (blueprint, reservation, active, completed). It is the central data structure of the framework, accessed via the conference control protocol and represented using an extensible conference information type (XML schema) defined in XCON-COMMON.
A focus is a logical entity that maintains a separate call signaling interface with each participating client and holds the conference object representing the active conference state. There is a one-to-one mapping between an active conference object and a focus; the focus handles primary membership operations (join, leave) and media negotiation. An active conference may have multiple conference identifiers, one per supported signaling protocol.
A sidebar is a separate conference instance that exists only within the context of a parent conference instance. It is implicitly linked (non-independent) to the parent conference object, contains a subset of parent members, and cannot exist if the parent conference is terminated. No members from outside the parent conference instance may join a sidebar.
Floor control (using BFCP per RFC 4582) allows an authorized client (floor chair) to manage access to a floor—a set of resources for which temporary access is granted to a participant or group. Floor control is not mandatory but provides advanced media input control. Each floor control message must include the conference object ID and conference user ID.
The conference control protocol (CCP) provides data manipulation and state retrieval for the centralized conferencing data represented by the conference object. It is used to request blueprints, create reservations, activate conferences, and manipulate participant and media state; the CCP client requires the conference object identifier for all operations.
The conference notification service provides updates about conference instance state to authorized parties. Notification content is filtered by conference user identifier and associated role, so users receive only data they are authorized to view. SIP NOTIFY (RFC 3265) with the conferencing event package (RFC 4575) is used for SIP-based notifications.
The conference object identifier is a URI that uniquely identifies a single conference object (blueprint, reservation, or active conference) within a conferencing system and is used by the conference control protocol to access and modify conference information. It is defined in XCON-COMMON and logically maps to protocol-specific identifiers such as the BFCP 'confid'.
The conference user identifier is a unique URI identifying a user within the scope of a conferencing system. A user may have multiple conference user identifiers (e.g., representing different roles) and the identifier is required in all conference control protocol requests to determine who is issuing commands for policy enforcement.
Floor control server authentication is required: a client must authenticate the floor control server before issuing floor requests, to prevent rogue servers from granting unauthorized floor access. Authentication mechanisms are specified in the BFCP specification (RFC 4582).
The mapping between conference user identifiers and call-signaling-specific user identities is sensitive. The conferencing system must protect this data, restrict manipulation to authorized users via CCP, and ensure that only appropriate users receive it through the notification protocol. Identity mapping is typically restricted to conferencing system administrators.
User authentication and authorization must be performed before any conferencing operation. The conferencing system must authenticate users, allocate conference user identifiers, and verify the user has appropriate authority based on system and conference-object-specific policies before processing any CCP request.
A conference instance progresses through lifecycle stages: (1) blueprint — static system capability description; (2) reservation — client-cloned object with scheduled resources and participant list; (3) active conference — triggered by first participant join or system start-time determination, allocating a new focus; (4) completed — after termination. Each stage is represented by a distinct conference object with its own conference object identifier.