draft-ietf-xcon-framework-01.txt   draft-ietf-xcon-framework-02.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: January 16, 2006 C. Boulton Expires: April 4, 2006 C. Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
July 15, 2005 Oct 2005
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-01 draft-ietf-xcon-framework-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2006. This Internet-Draft will expire on April 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines the framework for Centralized Conferencing This document defines the framework for Centralized Conferencing.
(XCON), which is applicable to participants using different call The framework allows participants using various call signaling
control signaling protocols and exchanging media over networks with protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
potentially different characteristics. The XCON Framework defines a centralized unicast conference. The Centralized Conferencing
the XCON data model, the XCON logical entities, the naming Framework defines logical entities and naming conventions, along with
conventions, and outlines the standard conferencing protocols a conferencing data model. The framework also outlines a set of
(complementary to the call control signalling protocols) for building conferencing protocols, which are complementary to the call signaling
advanced conferencing applications. The framework binds all the protocols, for building advanced conferencing applications. The
defined components together for the benefit of conferencing system framework binds all the defined components together for the benefit
builders. of builders of conferencing systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 9 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Common Conference Information . . . . . . . . . . . . . . 11 5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10
4.2 Conference Template . . . . . . . . . . . . . . . . . . . 12 5.1. Common Conference Information . . . . . . . . . . . . . . 11
4.3 Conference policies . . . . . . . . . . . . . . . . . . . 12 5.2. Conference Template . . . . . . . . . . . . . . . . . . . 12
5. XCON Constructs and Identifiers . . . . . . . . . . . . . . . 13 5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12
5.1 Conference Identifier . . . . . . . . . . . . . . . . . . 13 6. Centralized Conferencing Constructs and Identifiers . . . . . 13
5.2 Conference Instance . . . . . . . . . . . . . . . . . . . 13 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
5.3 Conference Object . . . . . . . . . . . . . . . . . . . . 14 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Conference Object Identifier . . . . . . . . . . . . . 16 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
5.4 Conference User Identifier . . . . . . . . . . . . . . . . 17 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15
6. Conferencing System Realization . . . . . . . . . . . . . . . 18 7. Conferencing System Realization . . . . . . . . . . . . . . . 15
6.1 Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Advanced Example . . . . . . . . . . . . . . . . . . . . . 22 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
6.4 Scheduling a 'Conference Object for Reservation' . . . . . 24 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22
7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 28 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25
7.1 Call Control Signalling . . . . . . . . . . . . . . . . . 28 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25
7.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Conference Control Protocol . . . . . . . . . . . . . . . 28 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25
7.3.1 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.3.1. CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3.2 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.3.2. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3.3 CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.3.3. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3.4 NETCONF . . . . . . . . . . . . . . . . . . . . . . . 30 8.3.4. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 28
7.3.5 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.3.5. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4 Floor Control . . . . . . . . . . . . . . . . . . . . . . 31 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28
8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 33 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 30
8.1 Participant Manipulations . . . . . . . . . . . . . . . . 33 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 30
8.2 Media Manipulations . . . . . . . . . . . . . . . . . . . 35 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 32
8.3 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 36 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 34
8.4 Whispering or Private Messages . . . . . . . . . . . . . . 38 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 35
8.5 Conference Announcements and Recordings . . . . . . . . . 38 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 37
9. Relationships between SIPPING and XCON Frameworks . . . . . . 38 9.6. Conference Announcements and Recordings . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . 38 10. Relationships between SIPPING and Centralized Conferencing
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 38
14. Changes since last Version . . . . . . . . . . . . . . . . . 41 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 39
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.3. Floor Control Server Authentication . . . . . . . . . . . 40
15.1 Normative References . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
15.2 Informative References . . . . . . . . . . . . . . . . . . 43 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 14. Changes since last Version . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 47 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
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing This document defines the framework for Centralized Conferencing.
(XCON), which is applicable to participants using various call The framework allows participants using various call signaling
signalling protocols (such as SIP, H.323, Jabber, HTML, PSTN, etc.) protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
and exchanging media over networks with potentially different a centralized unicast conference. Other than references to general
characteristics. functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document
The XCON Framework defines the XCON data model, the XCON logical The Centralized Conferencing Framework defines logical entities and
entities, the naming conventions, and outlines the standard naming conventions, along with a conferencing data model. The
conferencing protocols (complementary to the call control signalling framework also outlines a set of conferencing protocols, which are
protocols) for building advanced conferencing applications. The complementary to the call signaling protocols, for building advanced
framework binds all the defined components together for the benefit conferencing applications.
of conferencing system builders.
The XCON Framework is compatible with the functional model presented The Centralized Conferencing Framework is compatible with the
in the SIPPING Conferencing Framework [9] . Section 9 of this functional model presented in the SIPPING Conferencing Framework [9].
document discusses the relationship between the XCON Framework and Section 10 of this document discusses the relationship between the
the SIPPING Conferencing framework, in the context of the XCON Centralized Conferencing Framework and the SIPPING Conferencing
architecture. framework, in the context of the Centralized Conferencing model
presented in this document.
2. Conventions and Terminology 2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
The XCON Framework document both generalizes, when appropriate, the
SIPPING Conferencing Framework [9] terminology and introduces new
concepts as listed below.
Active Conference: The term Active Conference refers to a Conference
Object that's been created (for example, using a "blueprint") and
"activated" via the allocation of its identifiers (i.e.
Conference Object Identifier, Conference Identifier) and the
associated Focus.
Call (Control) Signalling: The protocol used between a participant
and a Focus. In this context, the term "call" means a channel or
session used for media streams establishment. Protocol examples
include, but are not limited to, SIP, H.323, MSRP, Jabber, HTML
and PSTN signalling. Other than references to general
functionality required (e.g. establishment and teardown), details
of these protocols are outside the scope of this document.
Common Conference Information: The data type (i.e. the XML schema)
which is used to represent the fixed information part of a
Conference Object. It includes a common set of definitions for
basic conference features, such as conference identifiers,
membership, signalling, capabilities, media, etc.
Conference Control Protocol (CCP): A protocol used by clients to
manipulate a Conference Object [Section 7.3].
Conference Factory: A logical entity that, upon request, generates
unique URI(s) to identify and represent a conference Focus. The
Conference Factory is typically used in the conference creation
process via a signalling interface and non-signalling methods such
as Conference Control Protocol [Section 7.3] and proprietary
mechanisms.
Conference Identifier(ID): The call signalling protocol-specific URI
that uniquely identifies a conference Focus and its associated
Conference Instance.
Conference Instance: An instantiation of a Conference Object. The
Conferencing System associates a Conference Instance with the
Conference Identifier(s). There is a one-to-one mapping between a
Conference Instance and a conference Focus.
Conference Object: A representation of 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
available services provided by the Conferencing System. All
Conference Objects are of type 'Conference Object Type' which is
comprised of two distinct sub components; the 'Common Conference
Information' and the 'Conference Template' (see definitions in
this section for details).
Conference Object Identifier (ID): A [TBD schema name] URI which
uniquly identifies a Conference Object and is being used by a
Conference Control Protocol [Section 7.3].
Conference policies: A term which is used to collectively refer to a
virtual set of rights, permissions and limitations pertaining to
operations being performed on a certain Conference Object. The
term is described in more details in Section 4.3.
Conference State: The state of a Conference Instance as represented
using the Conference Package mechanism defined in [11].
Conferencing System: The term used to refer to a conferencing
solution (system) that is based on the set of specifications and
is built using the protocols and the data model defined by the
XCON working group within the IETF.
Conference Template: The data type (i.e. the XML schema) which is
used to represent the variable information part of the Conference
Object. It can be included in the Conference Object to represent
enhanced conferencing capabilities (e.g. media mixers, etc.)
and/or user interface abstraction.
Floor: A term which is used to refer to a set of data or resources
associated with a Conference Instance, for which a conference
participant (or group of participants) is granted temporary input
access.
Floor Chair: A Floor control protocol compliant client (human
participant or automated entity) who is authorized to manage
access to one floor (grants, denies, or revokes a floor). The
floor chair does not have to be a participant in the Conference
Instance.
Focus: Focus is a logical entity that maintains the call signalling
interface between each participating client (i.e. participant) and
the Conference Instance. As such, the Focus acts as an endpoint
for each of the supported signalling 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. There
is a one-to-one mapping between the Focus and its Conference
Instance. Focus is addressed by explicitly associated unique
conference URIs for each signalling protocol, supported for its
Conference Instance.
Media Graph: The logical representation of the flow of media for a
conference.
Media Mixer: A logical entity that has the capability to combine
media inputs of the same type (or/and 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]), Message Session Relay Protocol
(defined in [25]), etc.
Registered Conference Document : An official standards document (RFC)
that defines and registers a Conference Template schema with the
appropriate standards body (IANA). A 'Registered Conference
Document' also includes any complimentary textual information in
relation to the conference template schema and its meaning.
Role: Represents differing membership categories that a conference
participant can assume within a conference. Each category has a
difference set of conference operations that a participant can
perform. A default (e.g. Standard Conference Participant) 'Role'
will always exist which provides a standard user with a set of
basic conference operations. Any user with appropriate
authentication and authorization may assume a role that has a
wider set of conference operations that are otherwise not
available (to a standard Conference Participant) - e.g. A 'Role'
called 'Conference Moderator' may exist that has additional
conference operations such as 'modify conference end time'.
Sidebar: TBD.
Whisper: TBD.
3. Overview 3. Overview
A centralized conference is an association of endpoints (called A centralized conference is an association of endpoints, called
conference participants) with a central endpoint (called a conference conference participants, with a central endpoint, called a conference
Focus) where the Focus has direct peer-wise relationships with the Focus. The Focus has direct peer relationships with the participants
participants by maintaining a separate call control signalling by maintaining a separate call signaling interface with each.
interface with each. Consequently, in this tightly coupled model, Consequently, in this centralized conferencing model, the call
the call control signalling graph is always a star. signaling graph is always a star.
The most basic conference supported would be an ad-hoc unmanaged The most basic conference supported in this model would be an ad-hoc
conference, which would not necessarily require any of the unmanaged conference, which would not necessarily require any of the
functionality defined within this framework. For example, it could functionality defined within this framework. For example, it could
be supported using basic SIP signalling functionality with a be supported using basic SIP signaling functionality with a
participant serving as the Focus; the SIPPING Conferencing Framework participant serving as the Focus; the SIPPING Conferencing Framework
[9] together with the SIP Call Control Conferencing for User [9] together with the SIP Call Control Conferencing for User
Agents[15] documents address these types of scenarios. Agents[15] documents address these types of scenarios.
An XCON-compliant Conferencing System, in addition to the basic In addition to the basic features, however, a conferencing system
features, can offer richer functionality including dedicated supporting the centralized conferencing model proposed in this
conferencing applications with explicitly defined capabilities, framework document can offer richer functionality, by including
reserved reoccurring conferences, and the standard protocols for dedicated conferencing applications with explicitly defined
managing and controlling different conference aspects. capabilities, reserved recurring conferences, along with providing
the standard protocols for managing and controlling the different
attributes of these conferences.
The core requirements for tightly managed centralized conferencing The core requirements for centralized conferencing are outlined in
are outlined in [10]. These requirements are applicable for [10]. These requirements are applicable for conferencing systems
conferencing systems using various call control signalling protocols, using various call signaling protocols, including SIP. Additional
not restricted to SIP alone. Additional conferencing requirements conferencing requirements are provided in [12], [13], and [14].
are provided in [12], [13], and [14].
The XCON architecture is built around a fundamental concept of a The centralizing conferencing system proposed by this framework is
Conference Object. A Conference Object is a logical representation built around a fundamental concept of a conference object. A
of a Conference Instance. For conference creation, a Conference conference object provides the data representation of a conference
Object provides a "blueprint" representing the System Capabilities. during each of the various stages of a conference (e.g., creation,
A conference object also provides the logical representation of a reservation, active, completed, etc.). A conference object is
conference during each of the various stages of a conference (e.g. accessed via the logical functional elements, with whom a
reservation, active, completed, etc.). A Conference Object is conferencing client interfaces, using the various protocols
accessible using XCON protocols (e.g. a Conference Control Protocol identified in Figure 1. The functional elements defined for a
[Section 7.3]. 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 any subset of the conferencing A conferencing system can support a subset of the conferencing
functions depicted in the Conferencing System logical decomposition functions depicted in the conferencing system logical decomposition
in Figure 1 and described in this document. Nevertheless, typically in Figure 1 and described in this document. However, there are some
advanced functions could not be implemented without implementing essential components that would typically be used by most other
others. For example, the Notification Service is an essential advanced functions, such as the Notification Service. For example,
component required for implementing almost any advanced functionality the notification service is used to correlate information, such as
and being used, among other things, for correlation of information list of participants with their media streams, between the various
(such as list of participants with their media streams) between other components.
otherwise distinct functions.
...................................................................... ...................................................................
. Conferencing System . . 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 | | . . | 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 . . v v v v .
. +-------------------+ +--------------+ +-------+ +------------+ . . +-------------------+ +--------------+ +-------+ +------------+ .
. | Conference Control| | Floor Control| |Foci | |Notification| . . | Conference Control| | Floor Control| |Foci | |Notification| .
. | Server | | Server | | | |Service | . . | Server | | Server | | | |Service | .
. +-------------------+ +--------------+ +-------+ +------------+ . . +-------------------+ +--------------+ +-------+ +------------+ .
. ^ ^ ^ | . . ^ ^ ^ | .
................|.................|...........|..........|............ ..............|.................|...........|..........|...........
| | | | | | | |
|Conference |BFCP |SIP/ |SIP NOTIFY/ |Conference |Binary |Call |Notification
|Control | |PSTN/ |Etc. |Control |Floor |Signaling |Protocol
|Protocol | |H.323/ | |Protocol |Control |Protocol |
| | |T.120/ | | |Protocol | |
| | |Etc. | | | | |
................|.................|...........|..........|............ ..............|.................|...........|..........|...........
. V V V V . . V V V V .
. +----------------+ +------------+ +----------+ +------------+ . . +----------------+ +------------+ +----------+ +------------+ .
. | Conference | | Floor | | Call | |Notification| . . | Conference | | Floor | | Call | |Notification| .
. | Control | | Control | | Control | | Client | . . | and Media | | Control | | Signaling| | Client |.
. | Client | | Client | | Client | | | . . | Control | | Client | | Client | | |.
. | Client | | | | | | |.
. +----------------+ +------------+ +----------+ +------------+ . . +----------------+ +------------+ +----------+ +------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
...................................................................... ...................................................................
Figure 1: Conferencing System Logical Decomposition. Figure 1: Conferencing System Logical Decomposition.
The media graph of a conference can be centralized, de-centralized, The media graph of a conference can be centralized, decentralized, or
or any combination of both and potentially differ per media type. In any combination of both and potentially differ per media type. In
the centralized case, the media sessions are established between a the centralized case, the media sessions are established between a
media mixer controlled by the focus and each one of the participants. media mixer controlled by the focus and each one of the participants.
In the de-centralized (i.e. distributed) case, the media graph is a In the decentralized (i.e., distributed) case, the media graph is a
(multicast or multi-unicast) mesh among the participants. multicast or multi-unicast mesh among the participants.
Consequently, the media processing (e.g. mixing) can be controlled Consequently, the media processing (e.g., mixing) can be controlled
either by the focus alone or by the participants. The concepts in either by the focus alone or by the participants. The concepts in
this framework document clearly map to a centralized media model. this framework document clearly map to a centralized media model.
The concepts can also apply to the de-centralized media case, The concepts can also apply to the decentralized media case, however,
however, the details of such are left for future study by the XCON WG the details of such are left for future study.
charter.
Section 4 of this document provides more details on the Conference Section 5 of this document provides more details on the conference
Object. Section 5 provides an overview of the identifiers necessary object. Section 6 provides an overview of the identifiers necessary
to address and manage the Conference Objects, Instances and Users to address and manage the conference objects, instances and users
associated with a Conferencing System. Section 6 of this document associated with a conferencing system. Section 7 of this document
describes how a Conferencing System is logically built using the describes how a conferencing system is logically built using the
defined data model and how the Conference Objects are maintained. defined data model and how the conference objects are maintained.
Section 7 describes the fundamental conferencing mechanisms and Section 8 describes the fundamental conferencing mechanisms and
provides a high level overview of the XCON protocols. Section 8 then provides a high level overview of the protocols. Section 9 then
provides realizations of various conferencing scenarios, detailing provides realizations of various conferencing scenarios, detailing
the manipulation of the Conference Objects using XCON defined the manipulation of the conference objects using the defined
protocols. Section 9 of this document summarizes the relationship protocols. Section 10 of this document summarizes the relationship
between the XCON Framework and the SIPPING Conferencing Framework. between this Centralized Conferencing Framework and the SIPPING
Conferencing Framework.
4. XCON Data Model 4. Terminology
The XCON data model defined in this framework has no strict This Centralized Conferencing Framework document generalizes, when
separation between conference membership, conference media appropriate, the SIPPING Conferencing Framework [9] terminology and
information and the related policies (i.e. the capabilities and introduces new concepts, as listed below. Further details and
limitations for each). This approach meets the requirement in many clarification of the new terms and concepts are provided in the
conference control operations to enable synchronized access to the subsequent sections of this document.
conference policies as a whole, to the conference state as a whole,
and for receiving notifications about changes to either.
A Conference Object is of type 'Conference Object Type' which is Active conference: The term active conference refers to a conference
comprised of two distinct components: the 'Common Conference cbject that has been created and activated via the allocation of
Information Type' and the 'Conference Template Type', as illustrated its identifiers (e.g., conference object identifier and conference
in Figure 2. Each of these types is a placeholder for including identifier) and the associated focus. An active conference is
potentially multiple sub-types. 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.
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.
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.
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 | | C o n f e r e n c e o b j e c t t y p e |
| | | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | COMMON CONFERENCE INFORMATION TYPE | | | | Common conference information type | |
| | | | | | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Conference Description | | | | | | Conference description (times, duration) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Membership (Roles, Capacity, Names) | | | | | | Membership (roles, capacity, names) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Signaling (Protocol, Direction, Status) | | | | | | Signaling (protocol, direction, status) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Floor Information | | | | | | Floor information | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Sidebars, Etc. | | | | | | Sidebars, Etc. | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | | | | | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | CONFERENCE TEMPLATE TYPE | | | | Conference template type | |
| | | | | | | |
| | - Mixer algorithm, inputs, and outputs | | | | - Mixer algorithm, inputs, and outputs | |
| | - Floor controls | | | | - Floor controls | |
| | - User Control Interface | | | | - User Control Interface | |
| | - User's View | | | | - User's View | |
| | - Etc. | | | | - Etc. | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | | |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: Conference Object Type Decomposition. Figure 2: Conference Object Type Decomposition.
Since, in an XCON-compliant system the same Conference Object Type is In a system based on this conferencing framework, the same conference
used for representation of a conference for different purposes, such object type is used for representation of a conference during
as expressing Conferencing System capabilities, reserving different stages of a conference, such as expressing conferencing
conferencing resources or reflecting the state of ongoing system capabilities, reserving conferencing resources or reflecting
conferences, each of the two components (i.e., the Common Conference the state of ongoing conferences. Thus, each of the two components
Information and the Conference Template) is syntactically optional to (i.e., the common conference information and the conference template)
be included in a particular Conference Object. Section 6 describes may be optionally included in a particular conference object.
the usage semantics of the Conference Objects. Section 7 describes the usage semantics of the conference objects.
[Editor's Note: The exact XML schema of the Conference Object (i.e.
the organization of the Common Conference Information and the
Conference Template) is an open issue (Discussion Point 4 on the
mailing list), which has been summarized as the three potential
alternatives below:
1. The top-level information is the template section, and it
contains a subsection that is the common conference information.
This has the advantage that the schema can all be well defined:
because the common conference information is known at the time the
template is developed, the appropriate schema definition can be
inserted into the template schema. The downside is that this setup
requires navigation of the template information to get to the common
information, which is likely to be manipulated most frequently.
2. The top-level information is the common conference information,
which contains the template information. This has the advantage that
clients don't even need to care about the template being used to
allow rendering and control over basic conference functionality(which
will suffice for many clients (e.g. those with limited screen). The
downside is that the common conference information schema must
include an extension point to allow new templates to hook into the
schema. This may make schema validation more difficult.
3. The template information and common conference information are The centralized conferencing data model defined in this framework has
conveyed as two separate objects (e.g. using multipart MIME). This no strict separation between conference membership, conference media
provides the benefits of allowing completely separate schema, information and the related policies. The policies are an integral
straightforward schema validation, and easy access to the common part of the data model and are realized by local, system level
conference information. The downside is that any mechanism for boundaries associated with specific data elements, such as the
separating the schema is going to add some amount of protocol membership, and by the ranges and limitations on other data elements.
complexity and the need for synchronization between the two data Additional policy considerations for a system realization based on
objects. Note that it has been argued that it is increasingly this data model are discussed in Section 5.3. The integration of the
difficult to find a potential client of the XCON protocols that data in this model meets the requirement of many conference control
doesn't already support multipart MIME). 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 model put forth in this document is the result of the consensus The exact XML schema of the Conference Object, including the
reached during the XCON second interim meeting in Boston and depicts organization of the Common Conference Information and the Conference
option 2 above. With slight adaptations it can also support option Templates, are detailed in separate documents [ref: TBD].
3. ]
4.1 Common Conference Information 5.1. Common Conference Information
The common conference information section contains the core The common conference information section contains the core
information that is utilized in any conference and can be abstracted information that is utilized in any conference and is independent of
regardless of the specific conference media nature (e.g. the mixing the specific conference media nature (e.g., the mixing algorithms
algorithms performed, the advanced floor control applied, etc.). performed, the advanced floor control applied, etc.). Typically,
Typically, participants with read-only access to the conference participants with read-only access to the conference information
information would be interested in this common information only. would be interested in this common conference information only.
The basic common conference information can be represented using the The common conference information may be represented using the
conference-info-type schema as defined in [11]. This schema contains conference-type as defined in [11]. The conference-type contains the
the definitions for representation of the Conference Object definitions for representation of the conference object capabilities,
capabilities, membership, roles, call control signalling and media membership, roles, call signaling and media status relevant to
statuses relevant to different stages of the conference life-cycle. different stages of the conference life-cycle.
New XCON specifications can extend the basic conference-info-type and New centralized conferencing specifications can extend the basic
introduce additional schemas to be used within the common conference conference-type and introduce additional data elements to be used
information type placeholder. within the common conference information type.
4.2 Conference Template 5.2. Conference Template
The concept of a "Conference Template" is introduced to abstract the The concept of a conference template is introduced to separate the
complexity and the details of the "mixer" and other conferencing complexity and the details of the "mixer" and other enhanced
features and to allow for easy user interface abstraction for conferencing features from the common conference information and to
advanced Conferencing Systems. allow for easy user interface abstraction for advanced conferencing
systems.
Each Conference Template needs to be registered with IANA. The IANA Each conference template needs to be registered with IANA. The IANA
registration needs to point to an RFC having the text description of registration needs to point to an RFC having the text description of
the feature behavior and optionally the XML definition allowing the the feature behavior and the XML definition allowing the feature
feature presentation, configuration, and management. RFCs of this presentation, configuration, and management. The RFCs defining these
kind are referred by XCON documents as a "Registered Conference templates are referred to as a registered conference document.
Document".
Typically, a conference template would contain the information about Typically, a conference template would contain the information about
the specific media mixing details, the associated client roles and the specific media mixing details, the associated client roles and
the available floor controls. This information would allow the available floor controls. This information would allow
authorized clients to manipulate mixer's behavior and the resultant authorized clients to manipulate the mixer's behavior via the focus,
distribution of the media to all or individual participants. By and the resultant distribution of the media to all or individual
doing so, a client can change its own state and/or state of other participants. By doing so, a client can change its own state and/or
participants in the conference. state of other participants in the conference.
A conference template can also include an abstract user interface A conference template can also include an abstract user interface
definition in terms of sliders, radio boxes, etc. for simplifying definition in terms of sliders, radio boxes, etc. for simplifying
user interaction with a specific non-trivial feature. user interaction with a specific non-trivial feature.
4.3 Conference policies 5.3. Conference policies
Conference policies is the term used to collectively refer to a Conference policies collectively refers to a set of rights,
virtual set of rights, permissions and limitations pertaining to permissions and limitations pertaining to operations being performed
operations being performed on a certain Conference Object. on a certain conference object.
The virtual set of rights describes the read/write access privileges The set of rights describes the read/write access privileges for the
for the Conference Object as a whole. This access would usually be conference object as a whole. This access would usually be granted
granted and defined in terms of giving the read-only or read-write and defined in terms of giving the read-only or read-write access to
access to clients with certain roles in the conference. For details clients with certain roles in the conference. As such, the policies
see [TBD]. 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 are specified as an integral part of the The permissions and limits, however, are specified as an integral
Conference Object Type, with data objects containing the allowed part of the conference object type, with data objects containing the
ranges for other data objects (e.g. maximum number of participants) allowed ranges for other data objects (e.g., maximum number of
and lists of clients allowed to perform certain operations on a participants) and lists of clients allowed to perform certain
conference object. For example, the "allowed to join" list of operations on a conference object. For example, the "allowed to
participants is consulted to decide who is allowed to join. The join" list of participants is consulted to decide who is allowed to
entries in the list can specify the identity of an individual user join. The entries in the list can specify the identity of an
(joe@example.com), a role, a domain (*@example.com), etc. For individual user (joe@example.com), a role, a domain (*@example.com),
details see [TBD]. etc. For further details, refer to the detailed data model [ref:
TBD].
A more general rule mechanism, beyond the functionality provided by A more general rule mechanism, beyond the functionality provided by
the permissions and limits, is an item for future study for the XCON the permissions and limits, is an item for future study.
WG.
5. XCON Constructs and Identifiers 6. Centralized Conferencing Constructs and Identifiers
This section provides details of the identifiers associated with the This section provides details of the identifiers associated with the
XCON constructs (e.g. Conference Object and Conference Instance) and centralized conferencing framework constructs and the identifiers
the identifiers necessary to address and manage the clients necessary to address and manage the clients associated with a
associated with a Conferencing System. An overview of the conferencing system. An overview of the allocation, characteristics
allocation, characteristics and functional role of the identifiers is and functional role of the identifiers is provided.
provided.
5.1 Conference Identifier
The Conference Identifier (ID) is the call signalling protocol-
specific URI that uniquely identifies a Conference Instance and a
conference Focus. The Conference Factory is the logical entity that
generates the unique Conference ID to identify and represent a
conference Focus. The Conference Factory is typically used in the
conference creation process via a signalling interface and non-
signalling methods such as Conference Control Protocol [Section 7.3]
and proprietary mechanisms.
5.2 Conference Instance
A Conference Instance is an internal implementation construct of a 6.1. Conference Identifier
conference, which is accessible by call signalling means, thus no
explicit identifier is required. Note that a Conference Instance can
have more than a single Conference Identifier, for example, for each
call signalling protocol supported. There is a one-to-one mapping
between a Conference Instance and a conference Focus. The Focus is
addressed by explicitly associating unique Conference IDs for each
signalling protocol supported by its Conference Instance.
A single Conference Instance can be internally mapped to a single or The conference identifier (conference ID) is a call signaling
multiple Conference Objects; each of them accessible by a Call protocol-specific URI that identifies a specific conference focus and
Control protocol. 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.
5.3 Conference Object 6.2. Conference Object
A Conference Object is the logical representation of a Conference A Conference object provides the logical representation of a
Instance at a certain stage, such as a "blueprint" representing a conference iInstance in a certain stage, such as a conference
Conferencing System's capabilities, the data representing a reserved blueprint representing a conferencing system's capabilities, the data
or scheduled conference, or the conference state during an active representing a conference reservation, and the conference state
conference. The Conferencing System exposes this data as separate during an active conference. Each conference object is independently
objects to allow independent access. Consequently, the XCON addressable through the conference control protocol interface
specifications allow the association of multiple Conference Objects [Section 8.3].
with a single Conference Instance.
Figure 3 illustrates the relationships between the Conference Figure 3 illustrates the relationships between the conference
Identifier, the Focus and the Conference Object Identifier within the identifier, the focus and the conference object ID within the context
context of a logical Conference Instance, with the Conference Object of a logical conference instance, with the conference object
corresponding to an ongoing conference (i.e. a conference in the corresponding to an active conference.
active state). The Conference Object is identified by a single or a
set of call signaling Conference Identifiers, with a one-to-one
mapping, as shown in the figure.
The Conference Objects corresponding to additional conference stages A conference object representing a conference in the active state can
are addressing using CCP [Section 7.3]. CCP will define the have multiple call signalling conference identifiers; for example,
necessary logical naming conventions for addressing additional for each call signalling protocol supported. There is a one-to-one
Conference Objects, within the context of the cloning tree concept mapping between an active conference object and a conference focus.
introduced in Section 6. The focus is addressed by explicitly associating unique conference
IDs for each signaling protocol supported by the active conference
object.
...................................................................... ......................................................................
. Conference Instance . . Conference Instance .
. . . .
. . . .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
. | Conference Object Identifier | . . | Conference Object Identifier | .
. | | . . | | .
. | | . . | | .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
skipping to change at page 15, line 46 skipping to change at page 14, line 47
| +---------------+ | | | +---------------+ | |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----------------+ +--------------+ +---------------+ +----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference | | Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client | | Client | | Client | | Client |
| 1 | | 2 | | X | | 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+ +----------------+ +--------------+ +---------------+
Figure 3: Conference Identifer, Focus, Conference Instance and Figure 3: Identifier Relationships for an Active Conference.
Conference Object Identifier Relationships.
5.3.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, as defined in [ref:TBD]. A Conference Control
Protocol [as outlined in Section 7.3] can then be used for directly
manipulating a particular Conference Object and for obtaining its
current state.
The Conference Object URI acts as a top level identifier for an
'umbrella style' construct within the Conference System for the
purpose of identifying incoming connections for complimentary XCON
protocols (e.g. BFCP). This implicit binding provides a structured
mapping of the various XCON protocols with the associated Conference
Object Identifier. As an example, Figure 4 illustrates how BFCP
connections fall under the general Conference Object identifier
umbrella.
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
|
|
|
+-------+-------+
| BFCP 'confid' |
+-------+-------+
|
|
+---------------+---------------+
| |
+-------+-------+ +-------+-------+
|BFCP 'floorid' | |BFCP 'floorid' |
+-------+-------+ +-------+-------+
Figure 4: Conference Object Mapping.
In Figure 4, the Conference Object Identifier acts as the top level
key in the identification process. The BFCP protocol, as defined in
[24], defines the 'conf-id' identifier which represents a conference
instance within Floor Control. BFCP also defines the 'floorid'
identifier for specific floors within a Conference instance. When
created within the Conference System, the 'conf-id' has a 1:1 mapping
to the unique XCON Conference Object Identifier. Using the BFCP
example, the Conference System is able to map the floor request to
the associated Conference Object.
This umbrella style association can be applied to any supplementary
mechanisms that are applied to the XCON model defined in this
document as long as a unique reference per conference instance is
available that can be mapped to a Conference Object.
[Editor's Note: The URI schema name per TBD must be registered with
IANA.]
5.4 Conference User Identifier
Section 5.3.1 discusses the concept of an umbrella mechanism for
associating various protocol identifiers with a top level XCON
identifier. This section outlines a similar umbrella mechanism for
the purpose of correlating users of supplementary XCON protocols
under one universal XCON identity within an XCON Conference System.
It is important to emphasize that the Conference User Identifier
being described must be in the context of the Conference System.
This is due to the requirement for identity of Conference System
users who may not be participating in a Conference Instance.
Examples being a non participating 'Floor Control Chair' or 'Media
Policy' Controller. Users can then be associated with Conference
Objects as defined in Section 5.3.1. This association enables the
Conference System to associate and enforce user level policies at
both a system level and Conference Object level.
Each user within a Conference System is allocated a unique Conference 6.2.1. Conference Object Identifier
User Identifier, as defined in [TBD]. This identifier acts as a top
level identifier, in a similar fashion to that defined for the
Conference Object Identifier described in Section 5.3.1. User
identifiers defined in other protocols that are used within a
Conference Instance fall underneath the top level identifier and
enable the Conference System to correlate and map authentication
under the single user umbrella.
Figure 5 illustrates an example using the Conference User Identifier In order to make each conference object externally accessible, the
in association with the user identity defined for BFCP and SIP Digest conferencing system allocates a unique URI per distinct conference
user identity as defined in RFC3261[4] object in the system. A conference control protocol includes the
+---------------+ conference object identifier in requests for directly manipulating a
| Conference | particular conference object and for obtaining its current state.
| User | The conference object identifier logically maps to other protocol
| Identifier | 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.
|
+---------------+---------------+
| |
+-------+-------+ +-------+-------+
| BFCP | | SIP Digest |
| 'UserID' | | Username |
+---------------+ +-------+-------+
Figure 5: Conference Object Mapping. 6.3. Conference User Identifier
Within a Conference System, a user is identified by a single Each user within a conferencing system is allocated a unique
Conference User Identifier. Any other XCON mechanisms that contain a conference user identifier. The user identifier is used in
protocol specific user ID can be associated with the 'Conference User association with the conference object identifier to uniquely
Identifier', as illustrated in Figure 5. This mechanism allows identify a user within the scope of conferencing system. There is
conference systems to manage and relate system wide user identities also a requirement for identifying conferencing system users who may
in relation to specific Conference Objects and helps in the not be participating in a conference instance. Examples of these
enforcement of system wide policies. 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
6. Conferencing System Realization 7. Conferencing System Realization
XCON-compliant implementations can range from systems supporting ad- Implementations based on this centralized conferencing framework can
hoc conferences, with default behavior only, to sophisticated systems range from systems supporting ad-hoc conferences, with default
with the ability to schedule re-occurring conferences (each with behavior only, to sophisticated systems with the ability to schedule
distinct characteristics), being integrated with external resource recurring conferences, each with distinct characteristics, being
reservation tools, and providing snapshots of the conference integrated with external resource reservation tools, and providing
information at any of the stages of the conference life-cycle. 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 A conference object is the logical representation of a conference
Instance at a certain stage, such as capabilities description upon instance at a certain stage, such as capabilities description upon
conference creation, reservation, activation, etc., which a conference creation, reservation, activation, etc., which a
Conferencing System maintains in order to describe the system conferencing system maintains in order to describe the system
capabilities and to provide access to the available services provided capabilities and to provide access to the available services provided
by the Conferencing System. by the conferencing system. Consequently, this centralized
conferencing framework does not mandate the actual usage of the
Consequently, the XCON specifications don't mandate the actual usage conference object, but rather defines the general cloning tree
of the Conference Object, but rather defines the general cloning tree concept and the mechanisms required for its realization, as described
concept and the mechanisms required for its realization, which is in detail in Section 7.1.
described in detail in Section 6.1.
Adhoc and advanced conferencing examples are provided in Section 6.2 Adhoc and advanced conferencing examples are provided in Section 7.2
and Section 6.3, with the latter providing additional description of and Section 7.3, with the latter providing additional description of
the Conference Object in terms of the stages of a conference, to the Conference Object in terms of the stages of a conference, to
support scheduled and other advanced conference capabilites. 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
The scheduling of a conference based on these concepts and mechanisms As discussed in Section 5.3, there are conference policies implicit
is then detailed in Section 6.4 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.
6.1 Cloning Tree 7.1. Cloning Tree
The concept defined in this section is a logical representation only, The concept defined in this section is a logical representation only,
as it is reflected through the XCON mechanisms: the URIs and the as it is reflected through the centralized conferencing mechanisms:
protocols. Of course, the actual system realization can differ from the URIs and the protocols. Of course, the actual system realization
the presented model and doesn't require physical copying of the can differ from the presented model. The intent is to illustrate the
information, etc. 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 Any conference object in a conferencing system is created by either
being explicitly cloned from an existing parent object or being being explicitly cloned from an existing parent object or being
implicitly cloned from a default system object. This document uses implicitly cloned from a default system conference blueprint. A
the "cloning" metaphor instead of the "inheritance" metaphor because conference blueprint is a static conference object used to describe a
it more closely fits the object replication and extension concept, typical conference setting supported by the system. Each system can
rather than data type re-usage and extension concept. 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 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 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 no link between the parent and the child exists, the objects become
independent and are not impacted by any operations on the parent independent and are not impacted by any operations on the parent
object nor subject to any limitations of the parent object. object nor subject to any limitations of the parent object.
By default, all the data existing in the parent object is copied to
the newly created object.
Once the new object is created, it can be addressed by a unique Once the new object is created, it can be addressed by a unique
Conference Object URI assigned by the system, as described in conference object URI assigned by the system, as described in
Section 5.3.1 Section 15 /[ref:TBD]. By default, the newly created object contains
all the data existing in the parent object. The newly created object
By default, the newly created object can expand the data it contains, can expand the data it contains, within the schema types supported by
within the schema types supported by the parent. It can also the parent. It can also restrict the read/write access to its
restrict the read/write access to its objects. However, unless the objects. However, unless the object is independent, it cannot relax
object is independent, it cannot relax the access relative to its the access relative to its parent's access.
parent's access.
Any piece of data in the child object can be independently accessed Any piece of data in the child object can be independently accessed
and, by default, can be independently modified without affecting the and, by default, can be independently modified without affecting the
parent data. parent data.
Unless the object is independent, the parent object can enforce a Unless the object is independent, the parent object can enforce a
different policy by marking certain data elements as "parent different policy by marking certain data elements as "parent
enforceable". The values of these data objects can not be changed by enforceable". The values of these data elements can not be changed
directly accessing the child object; neither can they be expanded in by directly accessing the child object; neither can they be expanded
the child object alone. in the child object alone.
In the future, XCON specifications may introduce logical Figure 4 illustrates an example of a conference (Parent B), which is
relationships, in addition to the "parent enforceable", between created independent of its Parent (Parent A). Parent B creates two
elements being cloned from one another. 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.
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | P A R E N T A | | o | P A R E N T A |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | O B J E C T | | i | O B J E C T |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
skipping to change at page 21, line 4 skipping to change at page 18, line 43
V V V V
+---+-----------------------+ +---+-----------------------+ +---+-----------------------+ +---+-----------------------+
| p | | | p | | | p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 | | o | C H I L D 1 | | o | C H I L D 2 |
| i | | | l | | | i | | | l | |
| l | C O N F E R E N C E | | i | C O N F E R E N C E | | l | C O N F E R E N C E | | i | C O N F E R E N C E |
| i | | | c | | | i | | | c | |
| c | O B J E C T | | i | O B J E C T | | c | O B J E C T | | i | O B J E C T |
| i | | | e | | | i | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+
Figure 6: The Cloning Tree.
Figure 4: The Cloning Tree.
Using the defined cloning model and its tools, the following sections Using the defined cloning model and its tools, the following sections
show examples of how different XCON-compliant systems can be show examples of how different systems based on this framework can be
realized. realized.
6.2 Ad-hoc Example 7.2. Ad-hoc Example
Figure 7 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 control Figure 5 illustrates how an ad-hoc conference can be created and
signalling channel with a Conference Factory as specified in managed in a conferencing system. A client can create a conference
Section 5.1. The Conference Factory can internally select one of the by establishing a call signaling channel with a conference factory as
system supported Conference Object blueprints based on the requesting specified in Section 6.1. The conference factory can internally
client privileges and the media lines included in the SDP body. 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 The selected blueprint with its default values is copied by the
server into a newly created Conference Object, referred to as an server into a newly created conference object, referred to as an
'Active Conference'. At this point the Conference Object becomes 'Active Conference'. At this point the conference object becomes
independent from its blueprint. A new Conference Object Identifier, independent from its blueprint. A new conference object identifier,
a new Conference Identifier and a new focus are allocated by the a new conference identifier and a new focus are allocated by the
server. server.
During the conference lifetime, an authorized client can manipulate During the conference lifetime, an authorized client can manipulate
the Conference Object (such as adding participants) using the the conference object, such as adding participants, using the
Conference Control Protocol [Section 7.3]. Conference Control Protocol [Section 8.3].
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C O N F E R E N C E | | o | System Default |
| l | | | l | |
| i | S Y S T E M | | i | Conference |
| c | | | c | |
| i | D E F A U L T | | i | Blueprint |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
| |
\| / \| /
\/ \/
/\ /\
/| \ /| \
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | A C T I V E | | o | Active |
| l | | | l | |
| i | C O N F E R E N C E | | i | Conference |
| c | | | c | |
| i | | | i | |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime.
Figure 7: Conference Ad-hoc Creation and Lifetime. 7.3. Advanced Example
6.3 Advanced Example
Figure 8 illustrates how a recurring conference can be specified Figure 6 illustrates how a recurring conference can be specified
according to system capabilities, scheduled, reserved, and managed in according to system capabilities, scheduled, reserved, and managed in
a conferencing system. a conferencing system. A client would first query a conferencing
system for its capabilities. This can be done by requesting a list
Firstly, a client would query a Conferencing System for its of the conference blueprints the system supports. Each blueprint
capabilities. This can be done by requesting a list of the contains a specific combination of capabilities and limitations of
Conference Object "blueprints" (or templates) the system supports. the conference server in terms of supported media types (e.g., audio,
Each blueprint can contain a specific combination of capabilities and video, text, or combinations of these), participant roles, maximum
limitations of the conference server in terms of supported media number of participants of each role, availability of floor control,
types (audio, video, text, or combinations of these), participant controls available for participants, availability and type of
roles, maximum number of participants of each role, availability of sidebars, the definitions and names of media streams, etc.
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 that it doesn't understand A client may need to query any templates in the blueprints that it
and then make a decision on compatibility. Interface hints need to doesn't understand and then make a decision on compatibility.
be included as per [21]. The client then selects which specific Interface hints need to be included as per [21]. The client then
template to use and retrieves the template from the server itself selects which specific templates to use and retrieves the templates
(and NOT from some centralized repository). from the server itself, rather than from a centralized repository.
The selected blueprint with its default values is copied by the The selected blueprint with its default values is cloned by the
client into a newly created Conference Object, referred to as a client into a newly created conference object, referred to as a
'Conference Object for Reservation', that specifies the resources conference reservation, that specifies the resources needed from the
needed from the system for this Conference Instance. At this point system for this conference instance. At this point the conference
the 'Conference Object for Reservation' becomes independent from its reservation becomes independent from its blueprint. The client can
blueprint. The client can also change the default values (within the also change the default values, within the system ranges, and add
system ranges) and add additional information (such as the list of additional information, such as the list of participants and the
participants and the conference start time) to the 'Conference Object conference start time, to the conference reservation.
for Reservation'.
At this point the client can ask the conference server to create a At this point the client can ask the conference server to create new
new conference reservation by attaching the 'Conference Object for conference reservations by attaching the conference reservation to
Reservation' to the request. As a result, the server can allocate the request. As a result, the server can allocate the needed
the needed resources, create the additional Conference Objects for resources, create the additional conference objects for the child
each conference occurrence (referred to as a 'Conference Object for conference reservations and allocate the conference object
Occurrence') and allocate the Conference Object identifiers for all - identifiers for all - the original conference reservation and for
the 'Conference Object for Reservation' and for each 'Conference each child conference reservation.
Object for Occurrence'.
From this point on, any authorized client is able to access and From this point on, any authorized client is able to access and
modify each of the Conference Objects independently. By default, modify each of the conference objects independently. By default,
changes to an individual 'Conference Object for Occurrence' will changes to an individual child conference reservation will affect
affect neither the 'Conference Object for Reservation' nor its neither the parent conference reservation, from which it was created,
siblings. nor its siblings.
On the other hand, some of the conference sub-objects, such as the On the other hand, some of the conference sub-objects, such as the
maximum number of participants and the participants list, can be maximum number of participants and the participants list, can be
defined by the system as parent-forcible. As a result, these objects defined by the system as parent enforceable. As a result, these
can be modified by accessing the 'Conference Object for Reservation' objects can be modified by accessing the parent conference
only. The changes to these objects can be applied automatically to reservation only. The changes to these objects can be applied
each of the 'Conference Object for Occurrence's (subject to local automatically to each of the child reservations, subject to local
policy). policy.
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | S E L E C T E D | | o | Selected |
| l | | | l | |
| i | C O N F E R E N C E | | i | Conference |
| c | | | c | |
| i | B L U E P R I N T | | i | Blueprint |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
| |
\| / \| /
\/ \/
/\ /\
/| \ /| \
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C O N F E R E N C E | | o | Conference |
| l | | | l | |
| i | R E S E R V A T I O N | | i | Reservation |
| c | | | c | |
| i | | | i | |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+---|--|--V-----------------+ +---|--|--V-----------------+
+-+---|--V------------------+ | +-+---|--V------------------+ |
+-+-+---V-------------------+ | | +-+-+---V-------------------+ | |
| p | | | | | p | | | |
| o | C O N F E R E N C E | | | | o | Child Conference | | |
| l | | | | | l | | | |
| i | O C C U R R E N C E | | | | i | Reservation | | |
| c | | | | | c | | | |
| i | | |-+ | i | | |-+
| e | |-+ | e | |-+
+-s-+-----------------------+ +-s-+-----------------------+
Figure 8: Advanced Conference Definition, Creation, and Lifetime. Figure 6: Advanced Conference Definition, Creation, and Lifetime.
6.4 Scheduling a 'Conference Object for Reservation' 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
Scheduling conferences forms an important part of the Conferencing 7.4. Scheduling a conference
System solution. The concept of an individual Conference Instance
and its relationship to a specific Conference Object is introduced in The capability to schedule conferences forms an important part of the
Section 5.2 and Section 5.3. A basic Conference Instance represents conferencing system solution. An individual conference reservation
a single occurrence that has a specified 'start' and 'end' time, with typically has a specified 'start' and 'end' time, with the times
the times being specified relative to a single specified 'fixed' being specified relative to a single specified 'fixed' time (e.g.,
time (e.g. 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
considerations . In most advanced conferencing solutions it is considerations . In most advanced conferencing solutions it is
possible to not only schedule an individual conference instance, but possible to not only schedule an individual occurrence of a
also schedule a series of related conferences (e.g. A weekly meeting conference reservation, but also schedule a series of related
that starts on Thursday at 09.00 GMT). 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 achieve such functionality, a conferencing system needs
to be able to appropriately schedule and maintain Conference to be able to appropriately schedule and maintain conference
Instances that form part of a recurring conference schedule. The reservations that form part of a recurring conference. The mechanism
mechanism proposed in this document makes use of the 'Internet proposed in this document makes use of the 'Internet Calendaring and
Calendaring and Scheduling Core Object' specification defined in Scheduling Core Object' specification defined in RFC2445[8] in union
RFC2445[8] in union with the concepts introduced in Section 4 for the with the concepts introduced in Section 5 for the purpose of
purpose of achieving advanced conference scheduling capability. achieving advanced conference scheduling capability.
Figure 9 illustrates a simplified view of a Client interacting with a Figure 7 illustrates a simplified view of a client interacting with a
Conference System. The Client is using the Conference Control conferencing system. The client is using the Conference Control
Protocol (Section 7.3) to add a new Conference Instance to the Protocol (Section 8.3) to add a new conference reservation to the
Conference System by interfacing with the Conference Control Server. conferencing system by interfacing with the conference control
A Conference Control Protocol request contains a valid 'Conference server. A CCP request contains a valid conference reservation and
Object for Reservation' and reference by value to an 'iCal' object reference by value to an 'iCal' object which contains scheduling
which contains scheduling information about the conference instance information about the conference (e.g., start time, end time).
(e.g. start time, end time).
+--------------+ +-------Conferencing System-----------------+ +--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | | | Generic ICAL | | |
| Resource | | ..Conference Instance.... | | Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+| +--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference|| ^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control || | | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server || | ----------------->. +-------------------+ . | Server ||
| | . . +-----------+| | | . . +-----------+|
| | ......................... ^ | | | ......................... ^ |
skipping to change at page 26, line 41 skipping to change at page 23, line 41
| |
| |
Conference Control| Conference Control|
Protocol | Protocol |
| |
+-------------+ +-------------+
| Conferencing| | Conferencing|
| Client | | Client |
+-------------+ +-------------+
Figure 9: Resource Scheduling Figure 7: Resource Scheduling
A successful creation of a Conference Instance using the Conference A CCP request to create a new conference reservation is validated,
Control Protocol results in a new 'Conference Object for including the associated iCal object, and the resultant conference
Reservation'. A Conference Control Protocol request is validated, reservation is created. The conference reservation is uniquely
including the associated iCal object, and the resultant 'Conference represented within the conferencing system by a conference object
Object for Reservation' is created. The Conference Object is identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and
uniquely represented within the Conference System by Conference defined in [ref:TBD]. This unique URI is returned to the client and
Object Identifier (e.g. xcon:hd87928374) as discussed in can be used to reference the conference reservation, if any future
Section 5.3. The unique URI is returned to the client and can be manipulations are required (e.g., alter start time), using a CCP
used to reference the 'Conference Object for Reservation' request.
representation if any future manipulations are required (e.g. Alter
start time) using a Conference Control Protocol.
The previous example explains how a client creates a basic The previous example explains how a client creates a basic conference
'Conference Object for Reservation' using an iCal reference in reservation using an iCal reference in association with a conference
association with a Conference Control Protocol. Figure 9 can also be control protocol. Figure 7 can also be applied when explaining how a
applied when explaining how a series of Conferences are scheduled in series of conferences are scheduled in the system. The description
the system. The description is almost identical with the exception is almost identical with the exception that the iCal definition that
that the iCal definition that is included in a Conference Control is included in a CCP request represents a series of recurring
Request represents a series of recurring Conference Instances (e.g. conference instances (e.g., conference start time, end time, occur
conference start time, end time, occur weekly). The Conference weekly). The conferencing system will treat this request the same as
system will treat this request the same as the first example. The the first example. The CCP request will be validated, along with the
protocol request will be validated, along with the associated iCal associated iCal object, and the conference reservation is created.
object, and the 'Conference Object for Reservation' will be created. The conference reservation and its conference object ID created for
The 'Conference Object for Reservation' and the Conference Object ID this example represent the entire series of recurring conference
created for this example represent the entire series of recurring instances rather than a single Conference. If the client uses the
Conference Instances rather than a single Conference. If the client conference object ID provided and a CCP request to adjust the
uses the Conference Object ID provided and a Conference Control conference reservation, every conference instance in the series will
Protocol to adjust the 'Conference Object for Reservation', every be altered. This includes all future occurrences, such as a
Conference Instance in the series will be altered. This includes all conference scheduled as an infinite series, subject to the
future occurrences, such as a conference scheduled as an infinite limitations of the available calendaring interface.
series, subject to the limitations of the available calendaring
interface.
A Conferencing System that supports the scheduling of a series of A conferencing system that supports the scheduling of a series of
Conference Instances should also be able to support manipulation conference instances should also be able to support manipulation
within a series range. A good example might be that a 'Conference within a specific range of the series. A good example is a
Object for Reservation' has been scheduled to occur every Monday at conference reservation that has been scheduled to occur every Monday
09.00 GMT. For the next three weeks only, the meeting has been 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 altered to occur at 10.00 GMT in an alternative venue. With Figure 7
Figure 9 in mind, the client will construct a Conference Control in mind, the client will construct a CCP request whose purpose is to
request whose purpose is to modify the existing 'Conference Object modify the existing conference reservation for the recurring
for Reservation' representing the recurring Conference Instance. The conference instance. The client will include the conference object
Client will include the Conference Object ID provided by the ID provided by the conferencing system to explicitly reference the
Conference System to explicitly reference the 'Conference Object for conference reservation within the conferencing system. A CCP request
Reservation' within the Conference System. A Conference Control will contain all the required changes to the conference reservation
request will contain all the required changes to the 'Conference (e.g., change of venue).
Object for Reservation'(e.g. Change of venue). The Conference
System matches the incoming request to the existing 'Conference
Object for Reservation' but identifies that the associated iCal
object only refers to a range of the existing series. The Conference
System creates a child clone of the original 'Conference Object for
Reservation' to represent the altered Conference Instances within
the Series. The cloned 'Conference Object for Reservation'
representing the altered series of Conference Instances has its own
associated Conference Object ID which is returned to the Client using
a Conference Control Protocol. 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, can itself be manipulated
using the Conference Control Protocol and the newly created
Conference Object ID representation. This provides a flexible
approach to the scheduling of recurring Conference instances.
7. Conferencing Mechanisms 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,
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.
7.1 Call Control Signalling 8. Conferencing Mechanisms
8.1. Call Signaling
The focus is the central component of the conference. Participants The focus is the central component of the conference. Participants
interface with the focus using an appropriate Call Control Signalling interface with the focus using an appropriate call signaling
protocol. Participants request to establish or join a conference protocol. Participants request to establish or join a conference
using the Call control signalling interface. A focus then either using the call interface. After checking the applicable policies, a
accepts (after checking the policies), sends a progress indication focus then either accepts the request, sends a progress indication
(e.g. for a parked call while awaiting moderator approval to join) or related to the status of the request (e.g., for a parked call while
rejects that request using the call control signalling interface. awaiting moderator approval to join) or rejects that request using
the call signaling interface.
During an active conference, a Conference Control Protocol During an active conference, a Conference Control Protocol
[Section 7.3] can be used to affect the conference state. For [Section 8.3] can be used to affect the conference state. For
example, Conference Control Protocol requests to add and delete example, CCP requests to add and delete participants are communicated
participants will be communicated to the focus and checked against to the focus and checked against the conference policies. If
the conference policies. If approved, the participants will be added approved, the participants are added or deleted using the call
or deleted using the call signalling to/from the focus. signaling to/from the focus.
7.2 Notifications 8.2. Notifications
A Conferencing System is responsible for implementing a Conference A conferencing system is responsible for implementing a Conference
Notification Service. The Conference Notification Service provides Notification Service. The Conference Notification Service provides
updates about the Conference Instance state to authorized parties updates about the conference instance state to authorized parties,
(e.g. participants) according to [11]. including participants. A model for notifications using SIP is
defined in [11].
The Conference User Identifier and associated Role are used by the The conference user identifier and associated role are used by the
conferencing system to filter the notifications such that they conferencing system to filter the notifications such that they
contain only information that is allowed to be sent to that user. contain only information that is allowed to be sent to that user.
7.3 Conference Control Protocol 8.3. Conference Control Protocol
The XCON working group charter includes the development of a protocol The conference control protocol provides for data manipulation and
or a set of protocols for controlling the state of a Conference state retrieval for the centralized conferencing data, represented by
Object and for retrieving its state. The nature of this protocol is the conference object. The details of the conference control
currently under discussion in the XCON working group. The proposals 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
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 span from data manipulation (management-like) protocols (CPCP and
NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the
proposed protocols are in the sections below. The following proposed protocols are in the sections below. The following
paragraphs summarize the fundamental issues around the selection of paragraphs summarize the fundamental issues around the selection of
the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG
mailing list]. mailing list].
It is recognized that semantic manipulations make for a cleaner It is recognized that semantic manipulations make for a cleaner
protocol design, with the disadvantage that extensions to the protocol design, with the disadvantage that extensions to the
underlying data model require extensions to the protocol used to underlying data model require extensions to the protocol used to
skipping to change at page 29, line 31 skipping to change at page 26, line 41
conference object state (common and template). conference object state (common and template).
The third statement in the paragraph above makes the first two The third statement in the paragraph above makes the first two
solution options mutually exclusive. A proposal was made that by solution options mutually exclusive. A proposal was made that by
allowing more than one protocol, a hybrid approach could be taken 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 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 other protocols that are likely to be supported by the clients (XCAP
and BFCP, respectively). However, the very rough consensus of the WG and BFCP, respectively). However, the very rough consensus of the WG
supports a single protocol for Conference Control and SOAP has most supports a single protocol for Conference Control and SOAP has most
recently been put forth as that protocol. A basic overview of SOAP recently been put forth as that protocol. A basic overview of SOAP
in the context of Conference control is provided in Section 7.3.5 in the context of Conference control is provided in Section 8.3.5
7.3.1 CPCP 8.3.1. CPCP
A Conference Policy Control Protocol (CPCP) is a data manipulation A Conference Policy Control Protocol (CPCP) is a data manipulation
protocol being proposed as a standard means of storing and protocol being proposed as a standard means of storing and
manipulating the conference policy. According to CPCP, the manipulating the conference policy. According to CPCP, the
conference policy is comprised of the rules associated with a conference policy is comprised of the rules associated with a
specific Conference Instance. Requirements for the CPCP are defined specific conference instance. Requirements for the CPCP are defined
in the CPCP Requirements document [13]. The Conference Policy in the CPCP Requirements document [13]. The Conference Policy
Control Protocol document [17] defines the XML Schema for the Control Protocol document [17] defines the XML Schema for the
conference policy data elements. conference policy data elements.
The privileges as to which users are allowed to read and/or The privileges as to which users are allowed to read and/or
manipulate a specific Conference Instance are defined in a separate manipulate a specific conference instance are defined in a separate
Extensible Markup Language (XML) Schema[19]. This schema is based on Extensible Markup Language (XML) Schema[19]. This schema is based on
the common policy model being used for geographic privacy information the common policy model being used for geographic privacy information
and for presence information. and for presence information.
A separate document [18] proposes XCAP as one protocol mechanism for A separate document [18] proposes XCAP as one protocol mechanism for
storing and manipulating this conferencing policy data. XCAP is a storing and manipulating this conferencing policy data. XCAP is a
HTTP 1.1 based protocol that allows clients to read, write, modify 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 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 the main advantages of XCAP is that it maps XML document elements and
attributes to HTTP URIs that can be directly accessed by HTTP. attributes to HTTP URIs that can be directly accessed by HTTP.
7.3.2 CCCP 8.3.2. CCCP
A Centralized Conferencing Control Protocol [20] is a semantic- A Centralized Conferencing Control Protocol [20] is a semantic-
oriented protocol defined to allow participants or otherwise oriented protocol defined to allow participants or otherwise
authorized entities to directly manipulate an active Conference authorized entities to directly manipulate an active conference
Instance. CCCP is defined as a set of transactions issued over a instance. CCCP is defined as a set of transactions issued over a
reliable transport protocol. A transaction consists of a Request reliable transport protocol. A transaction consists of a Request
carrying the required information in an XML body and a corresponding carrying the required information in an XML body and a corresponding
Response carrying an appropriate XML body. Response carrying an appropriate XML body.
CCCP requests are submitted to the CCCP server and can be prioritized CCCP requests are submitted to the CCCP server and can be prioritized
and queued, based on the CCCP client Role and the requested and queued, based on the CCCP client Role and the requested
primitives. CCCP requires no single lock per document, and the CCCP primitives. CCCP requires no single lock per document, and the CCCP
server can locally implement an optimization strategy independent of server can locally implement an optimization strategy independent of
CCCP client behavior. CCCP client behavior.
7.3.3 CSCP 8.3.3. CSCP
A Conference State Change protocol [26] is a client server protocol A Conference State Change protocol [26] is a client server protocol
used to change the state of a conference object. CSCP extends the used to change the state of a conference object. CSCP extends the
BFCP protocol [16] with new commands. A client sends the server a BFCP protocol [16] with new commands. A client sends the server a
request representing a sequence of commands. Each command can set, request representing a sequence of commands. Each command can set,
get, add, or delete a single field in the conference object. Changes get, add, or delete a single field in the conference object. Changes
to the conference object are performed on a hierarchal set of to the conference object are performed on a hierarchal set of
elements and unique attributes within those elements. A series of elements and unique attributes within those elements. A series of
changes can be pipelined in a single BFCP message. The server changes can be pipelined in a single BFCP message. The server
executes each action in series. If one of them fails, 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 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 of the actions after that. Each individual action is atomic but the
pipelined series is not. pipelined series is not.
The item to which a command applies is specified by a unique ID and, 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 where appropriate, attribute name. The ID is an unsigned 32 bit
integer called the Element ID. The server discovery of the Element integer called the Element ID. The server discovery of the Element
ID is outside of CSCP. Typically this is done by using the ID is outside of CSCP. Typically this is done by using the
conference notification service per Section 7.2. Each field in the conference notification service per Section 8.2. Each field in the
data received in the notification contains a unique field ID data received in the notification contains a unique field ID
attribute that can be used in BFCP requests. attribute that can be used in BFCP requests.
7.3.4 NETCONF 8.3.4. NETCONF
The Network Configuration (NETFCONF) protocol [27] defines a simple The Network Configuration (NETFCONF) protocol [27] defines a simple
mechanism through which a network device can be managed, mechanism through which a network device can be managed,
configuration data information can be retrieved, and new configuration data information can be retrieved, and new
configuration data can be uploaded and manipulated. The protocol configuration data can be uploaded and manipulated. The protocol
allows the device to expose a full, formal, application programming allows the device to expose a full, formal, application programming
interface (API). interface (API).
NETCONF is proposed as the mechanism for object content manipulation NETCONF is proposed as the mechanism for object content manipulation
and state retrieval for the XCON data. NETCONF provides a flexible and state retrieval for the centralized conferencing data. NETCONF
configuration retrieval mechanism, with extensibility. It allows for provides a flexible configuration retrieval mechanism, with
incremental configuration and commits. NETCONF supports stored extensibility. It allows for incremental configuration and commits.
configurations (e.g. for startup, running, etc.). It also supports NETCONF supports stored configurations (e.g., for startup, running,
XPath and subtree filtering. With NETCONF, there are no constraints etc.). It also supports XPath and subtree filtering. With NETCONF,
on the configuration content. there are no constraints on the configuration content.
7.3.5 SOAP 8.3.5. SOAP
The SOAP protocol is fundamentally an XML messaging scheme, capable The SOAP protocol is fundamentally an XML messaging scheme, capable
of supporting remote procedure calls. SOAP defines a simple message of supporting remote procedure calls. SOAP defines a simple message
format composed of a "header" and a "body" contained within an format composed of a "header" and a "body" contained within an
"envelope". The "header" contains meta-information relating to the "envelope". The "header" contains meta-information relating to the
message, and can be used to indicate such things as store-and-forward message, and can be used to indicate such things as store-and-forward
behaviour or transactional characteristics. In addition, SOAP behaviour or transactional characteristics. In addition, SOAP
encoding is optimized for ease of automated deserialization. encoding is optimized for ease of automated deserialization.
SOAP is proposed as the mechanism for object content manipulation and SOAP is proposed as the mechanism for object content manipulation and
state retrieval for the XCON data. In general, SOAP is a good fit state retrieval for the centralized conferencing data. In general,
for Conference Control, essentially because of its remote procedure SOAP is a good fit for Conference Control, essentially because of its
call characteristics and its inherently synchronous and client-driven remote procedure call characteristics and its inherently synchronous
nature. and client-driven nature.
7.4 Floor Control 8.4. Floor Control
[Editor's Note: This text still requires further updating to reflect A floor control protocol allows an authorized client to manage access
new model and pending new WG agreements. Amongst the things TODO to a specific floor and to grant, deny or revoke access of other
are: conference users to that floor. Floor control is not a mandatory
mechanism for a conferencing system implementation but provides
advanced media input control features for conference users. A
mechanism for floor control within a conferencing system is defined
in the Binary Floor Control Protocol specification [16]. [Editor's
note: Evaluation of an alternative proposal, as a stand alone draft,
for using Templates as the means for correlating Floor Control
identifiers has been proposed. If/when this work is done, it needs
to be introduced and referenced here].
1. Need to be able to fetch from the Conference Object the Within this framework, a client supporting floor control needs to
credentials required for BFCP. This includes the conference id, user obtain information for connecting to a floor control server to enable
id, and password. 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.
4. Evaluation of an alternative proposal [TBD as a stand alone draft As well as the client to the floor control server connection
as well] for using Templates as the means for correlating Floor information, a client wishing to interact with a floor control server
Control identifiers. 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.
5. Still need to condense this section - propose to add a scenario The conference is uniquely identifed by the conference object ID per
to section 8 and thus remove some of the details, leaving this Section 6.2.1. This conference object ID must be included in all
description a very basic overview and mapping of the identifiers. 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
A mechanism for floor control within a Conferencing System is defined represented by a conference user ID per Section 6.3. This conference
in the 'Binary Floor Control Protocol' specification [16]. Floor user ID must be included in all floor control messages. When using
control is not a mandatory mechanism for a Conferencing System SDP offer/answer exchange to negotiate a Floor control connection
implementation but provides advanced media input control features for with the focus using the call signaling interface, the unique
participants. conference identifier is contained in the 'userid' SDP attribute, as
defined in [24]
An XCON compliant client supporting floor control needs to obtain A media session witin a conferencing system can have any number of
information for connecting to a floor control server to enable it to floors (0 or more) that are represented by the conference identifer.
issue floor requests. This connection information can be retrieved When using SDP offer/answer exchange to negotiate a floor control
using information provided by mechanisms such as negotiation using connection with the focus using the call signaling interface, the
the SDP[2] offer/answer[5] exchange on the signalling interface with unique conference identifier is contained in the 'floorid' SDP
the focus. 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].
As well as the Client --> Floor Server connection information, a 9. Conferencing Scenario Realizations
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 user, a floor and a
conference. This information, defined in the next set of bullet
points, can be obtained using methods such as negotiation using the
SDP offer/answer exchange on the signalling interface with the focus:
o Conference Object ID - Each Conference Object has a unique This section addresses how advanced conferencing scenarios, many of
identifier per Section 5.3.1, obtained from the Conference which have been described in [14], are realized using this
server, which MUST be included in all Floor messages. When the centralized conferencing framework. The objective of this section is
SDP model is used as described in [24] this identifier maps to the to further illustrate the model, mechanisms and protocols presented
'confid' SDP attribute. in the previous sections and also serves to validate that the model,
o Conference User Identifier - Each user has a unique identifier mechanisms and protocols are sufficient to support advanced
within the Conference Object per Section 5.4, obtained from the conferencing scenarios.
Conference server, which MUST be included in all Floor messages.
When using SDP offer/answer exchange to negotiate a Floor control
connection with the focus using the call control signalling
interface, the unique conference identifier is contained in the
'userid' SDP attribute, as defined in [24]
o Floor ID - A media session with a Conferencing System can have any
number of 'Floors' (0 or more) that are represented by a unique
identifier within the Conference Instance (as represented by
Conference ID). When using SDP offer/answer exchange to negotiate
a Floor control connection with the focus using the call control
signalling 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].
Clients can authenticate a BFCP server using the TLS certificates. 9.1. Conference Creation
Requests submitted on a successfully created BFCP connection 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 BFCP
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 BFCP 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.
8. Conferencing Scenario Realizations 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.
This section addresses how advanced conferencing scenarios, many of Figure 8 provides an example of one client "Alice" determining the
which have been described in [14], are realized using this XCON conference blueprints available for a particular conferencing system
framework. The objective of this section is to further illustrate and creating a conference based on the desired blueprint. It should
the model, mechanisms and protocols presented in the previous be noted that not all entities impacted by the request are shown in
sections and also serves to validate that the model, mechanisms and the diagram (e.g., Focus), but rather the emphasis is on the new
protocols are sufficient to support advanced conferencing scenarios. entities introduced by this centralized conferencing framework.
Section 6.2 and Section 6.3 provide examples of the creation of a +--------------------------------+
basic adhoc conference and a more advanced scheduled conference. | Conferencing System |
"Alice" | +------------+|
+--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+|
blueprintZ, | |
confUserID> | |
"Alice" |
+--------+ | |
| |CCP Request <reserve, | +------------+|
| | blueprintAConfObjID,| +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| | confUserID> | |Control |~~~>|BlueprintA ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <reservationConfObjID, | | | \|/ |
confID> | | | /|\ |
| | | V |
| | | +------------+|
| | |~~~>|Conference ||
| | | |Reservation ||
| +-----------+ +------------+|
"Alice" | | |
+--------+ | | |
| |CCP Request <add, | V |
| |reservationConfObjID, | +-----------+ +------------+|
| Client |-------------------------->|Conference | |Active ||
| | confID,confUserID> | |Control |~~~>|Conference ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <activeConfObjID, | | | |
confID> | +-----------+ |
+--------------------------------+
8.1 Participant Manipulations 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
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 There are different ways to affect a participant state in a
conference. A participant can join and leave the conference using conference. A participant can join and leave the conference using
call signalling means only, such as SIP. This kind of operation is call signaling means only, such as SIP. This kind of operation is
called "1st party signalling" and does not affect the state of other called "1st party signaling" and does not affect the state of other
participants in the conference. participants in the conference.
Limited operations for controlling other conference participants (a Limited operations for controlling other conference participants (a
so called "3rd party control") through the Focus, using call so called "3rd party control") through the Focus, using call
signalling only, may also be available for some signalling protocols. signaling only, may also be available for some signaling protocols.
For example, "Conferencing for SIP User Agents" [15] shows how SIP For example, "Conferencing for SIP User Agents" [15] shows how SIP
with REFER can be used to achieve this functionality. with REFER can be used to achieve this functionality.
In order to perform richer conference control a user client needs to In order to perform richer conference control a user client needs to
implement a conference control protocol client. By using a implement a conference control protocol client. By using a
conference control protocol, the client can affect its own state, conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state of any of the media mixers) which may indirectly affect the state of any of the
conference participants. conference participants.
Figure 11 provides an example of one client "Alice" impacting the Figure 9 provides an example of one client "Alice" impacting the
state of another client "Bob". This example assumes an established state of another client "Bob". This example assumes an established
conference. In this example, "Alice" wants to add "Bob" to the conference. In this example, "Alice" wants to add "Bob" to the
conference. conference.
It should be noted that not all entities impacted by the request are 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 shown in the diagram (e.g., Focus), but rather the emphasis is on the
new entities introduced by XCON. new entities introduced by this centralized conferencing framework.
+--------------------------------+ +--------------------------------+
| Conference System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Conference || | Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Object of || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | |occurrence || +--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
"Bud" | ' ' '| "Bud" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ | | Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
"Bob" "Bob"
Figure 9: Client Manipulation of Conference - Add a party
Figure 10: Client Manipulation of Conference - Add a party
Upon receipt of the Conference Control Protocol request to "add" a Upon receipt of the Conference Control Protocol request to "add" a
party ("Bob") in the specific conference as identified by the party ("Bob") in the specific conference as identified by the
Conference Object ID, the Conference System ensures that "Alice" has conference object ID, the conferencing system ensures that "Alice"
the appropriate authority based on the policies associated with that has the appropriate authority based on the policies associated with
specific Conference Object to perform the operation. The Conference that specific conference object to perform the operation. The
System must also determine whether "Bob" is already a user of this conferencing system must also determine whether "Bob" is already a
Conference System or whether he is a new user. user of this conferencing system or whether he is a new user.
If "Bob" is a new user for this conference system, a Conference User If "Bob" is a new user for this conferencing system, a Conference
Identifier is created for Bob. Based upon the addressing information User Identifier is created for Bob. Based upon the addressing
provided for "Bob" by "Alice", the call signalling to add "Bob" to information provided for "Bob" by "Alice", the call signaling to add
the conference is instigated through the Focus. "Bob" to the conference is instigated through the Focus.
Once the call signalling indicates that "Bob" has been successfully Once the call signaling indicates that "Bob" has been successfully
added to the specific conference, per updates to the state, and added to the specific conference, per updates to the state, and
depending upon the policies, other participants (including "Bob") may depending upon the policies, other participants (including "Bob") may
be notified of the addition of "Bob" to the conference via the be notified of the addition of "Bob" to the conference via the
Conference Notification Service. Conference Notification Service.
8.2 Media Manipulations 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, There are different ways to manipulate the media in a conference. A
sending re-INVITE with new SDP content using SIP only. This kind of participant can change its own media streams by, for example, sending
operations is called "1st party signalling" and they do not affect re-INVITE with new SDP content using SIP only. This kind of
the state of other participants in the conference. 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 In order to perform richer conference control a user client needs to
implement a conference control protocol client. By using a implement a conference control protocol client. By using a
conference control protocol, the client can manipulate the state of conference control protocol, the client can manipulate the state of
various resources, such as media mixers, which may indirectly affect various resources, such as media mixers, which may indirectly affect
the state of any of the conference participants. the state of any of the conference participants.
Figure 11 provides an example of one client "Alice" impacting the Figure 10 provides an example of one client "Alice" impacting the
media state of another client "Bob". This example assumes an media state of another client "Bob". This example assumes an
established conference. In this example, the Client, "Alice" whose established conference. In this example, the client, "Alice" whose
Role is "moderator" of the conference, wants to mute "Bob" on a Role is "moderator" of the conference, wants to mute "Bob" on a
medium-size multi-party conference, as his device is not muted (and medium-size multi-party conference, as his device is not muted (and
he's obviously not listening to the call) and background noise in he's obviously not listening to the call) and background noise in his
his office environment is disruptive to the conference. office environment is disruptive to the conference.
It should be noted that only entities impacted by the request are It should be noted that only entities impacted by the request are
shown in the diagram (e.g. there is no Focus shown). shown in the diagram (e.g., there is no Focus shown).
+--------------------------------+ +--------------------------------+
| Conference System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Conference || | Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Object of || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | |occurrence || +--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
| ' ' '| | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ | | Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
Figure 11: Client Manipulation of Conference - Mute a party Figure 10: Client Manipulation of Conference - Mute a party
Upon receipt of the Conference Control Protocol request to "mute" a Upon receipt of the Conference Control Protocol request to "mute" a
party ("Bob") in the specific conference as identified by the party ("Bob") in the specific conference as identified by the
Conference Object ID, the Conference Server ensures that "Alice" has conference object ID, the Conference Server ensures that "Alice" has
the appropriate authority based on the policies associated with that the appropriate authority based on the policies associated with that
specific Conference Object to perform the operation. "Bob's" status specific conference object to perform the operation. "Bob's" status
is marked as "recvonly" and the Conference Template of the Conference is marked as "recvonly" and the Conference Template of the Conference
Object (if included) is updated to reflect that "Bob's" media is not Object (if included) is updated to reflect that "Bob's" media is not
to be "mixed" with the conference media. to be "mixed" with the conference media.
Depending upon the policies, other participants (including "Bob") may Depending upon the policies, other participants (including "Bob") may
be notified of this change via the Conference Notification Service. be notified of this change via the Conference Notification Service.
8.3 Sidebar Manipulations 9.4. Sidebar Manipulations
A sidebar can be viewed as a separate Conference instance that only A sidebar can be viewed as a separate Conference instance that only
exists within the context of a parent Conference instance. Although exists within the context of a parent conference instance. Although
viewed as an independent Conference instance, it can not exist viewed as an independent conference instance, it can not exist
without a parent. A Sidebar is created using the same mechanisms without a parent. A sidebar is created using the same mechanisms
employed for a standard conference as described in Section 6.1 A employed for a standard conference as described in Section 7.1.
Conference object representing a Sidebar is created by cloning the
parent associated with the existing conference, copying the A conference object representing a sidebar is created by cloning the
information from the parent and updating any information specific to parent associated with the existing conference and updating any
the sidebar. A Sidebar Conference Object is implicitly linked to the information specific to the sidebar. A sidebar conference object is
parent Conference Object (i.e. it is not an independent object). A implicitly linked to the parent conference object (i.e. it is not an
Conference System manages and enforces the parent and appropriate independent object) and is associated with the parent conference
localized restrictions on the Sidebar Conference Object (e.g. No object identifier as as shown in Figure 11. A conferencing system
members from outside the parent conference instance can join, Sidebar manages and enforces the parent and appropriate localized
conference can not exist if parent Conference is terminated, etc.). restrictions on the sidebar conference object (e.g., no members from
The Sidebar mechanism uses the umbrella approach for association of outside the parent conference instance can join, sidebar conference
XCON Conference Object Identifiers as introduced in other sections of can not exist if parent conference is terminated, etc.).
this document.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------+ +--------------+
| |
| |
| |
+---------------------+---------------------+ +---------------------+---------------------+
| | | | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar | | Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference | | Conference | | Conference | | Conference |
| Object | | Object | | Object | | Object | | Object | | Object |
| Identifier | | Identifier | | Identifier | | Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+ +-------+-------+ +-------+-------+ +---------------+
Figure 12: Conference Object Mapping. Figure 11: Conference Object Mapping.
Figure 12 illustrates the relationship between a Conference Object Figure 11 illustrates the relationship between a conference object
and associated Sidebar Conference Objects within a Conference System. and associated Sidebar conference objects within a conferencing
Each Sidebar Conference Object has a unique Conference Object system. Each Sidebar conference object has a unique conference
Identifier as described in Section 5.3.1. The main Conference Object object Identifier as described in Section 6.2.1. The main conference
Identifier acts as a top level identifier for associated Sidebars. object identifier acts as a top level identifier for associated
sidebars.
A sidebar Conference Object Identifier follows many of the concepts A sidebar conference object Identifier follows many of the concepts
outlined in the Cloning tree model described in Section 6.1. A outlined in the cloning tree model described in Section 7.1. A
Sidebar Conference Object contains a subset of members from the Sidebar conference object contains a subset of members from the
original Conference object. Properties of the Sidebar Conference original Conference object. Properties of the sidebar conference
Object can be manipulated by a Conference Control Protocol object can be manipulated by a Conference Control Protocol
(Section 7.3 using the unique Conference Object identifier for the (Section 8.3) using the unique conference object identifier for the
sidebar. It is also possible for the top level Conference Object to sidebar. It is also possible for the top level conference object to
enforce policy on the Sidebar Object (similar to parent enforceable enforce policy on the sidebar object (similar to parent enforceable
as discussed in Section 6.1). as discussed in Section 7.1).
[Editor's Note: this needs more detail - especially around cloning [Editor's Note: this needs more detail - especially around cloning
tree.] tree, including an example scenario such as a sidebar which still
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.]
8.4 Whispering or Private Messages 9.5. Whispering or Private Messages
[Editor's Note: TBD. Once we get full agreement on terminology and [Editor's Note: TBD. Once we get full agreement on terminology and
the basic ideas in the other sections, we'll tackle this.] the basic ideas in the other sections, we'll tackle this.]
8.5 Conference Announcements and Recordings 9.6. Conference Announcements and Recordings
[Editor's note: TBD. Use Cullen's comments on the previous version [Editor's note: TBD. Use Cullen's comments on the previous version
of the doc .] of the doc .]
9. Relationships between SIPPING and XCON Frameworks 10. Relationships between SIPPING and Centralized Conferencing
Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIPPING Conferencing Framework are being used
to illustrate how SIP [4] can be used as a signalling means in these to illustrate how SIP [4] can be used as a signaling means in these
conferencing systems. SIPPING Conferencing Framework does not define conferencing systems. SIPPING Conferencing Framework does not define
new conference control protocols to be used by the general new conference control protocols to be used by the general
conferencing system. It uses only basic SIP [4], the SIP conferencing system. It uses only basic SIP [4], the SIP
Conferencing for User Agents [15], and the SIPPING Conference Conferencing for User Agents [15], and the SIPPING Conference Package
Package [9] for basic SIP conferencing realization. [9] for basic SIP conferencing realization.
The XCON framework defines a particular centralized Conferencing This centralized conferencing framework document defines a particular
System and the logical entities implementing it. It also defines a centralized conferencing system and the logical entities implementing
particular XCON Data Model and refers to the standard protocols it. It also defines a particular data model and refers to the set of
(beyond call signalling means) being defined by the XCON WG to be protocols (beyond call signaling means) being defined by the XCON WG
used among the XCON logical entities for implementing advanced to be used among the logical entities for implementing advanced
conferencing features. The purpose of XCON working group and this conferencing features. The purpose of the XCON working group and
framework is to achieve interoperability between the XCON entities this framework is to achieve interoperability between the logical
from different vendors for controlling different aspects of advanced entities from different vendors for controlling different aspects of
conferencing applications. advanced conferencing applications.
The logical entities defined in the two frameworks are not intended The logical entities defined in the two frameworks are not intended
to be mapped one-to-one. The two frameworks differ in the to be mapped one-to-one. The two frameworks differ in the
interpretation of the internal conferencing system decomposition and interpretation of the internal conferencing system decomposition and
the corresponding operations. Nevertheless, the basic SIP [4], the the corresponding operations. Nevertheless, the basic SIP [4], the
SIP Conferencing for User Agents [15], and the SIPPING Conference SIP Conferencing for User Agents [15], and the SIPPING Conference
Package [9] are fully compatible with both Framework documents. Package [9] are fully compatible with both Framework documents.
10. Security Considerations 11. Security Considerations
There are a wide variety of potential attacks related to There are a wide variety of potential attacks related to
conferencing, due to the natural involvement of multiple endpoints conferencing, due to the natural involvement of multiple endpoints
and the many, often user-invoked, capabilities provided by the and the many, often user-invoked, capabilities provided by the
conferencing system. Examples of attacks include the following: an conferencing system. Examples of attacks include the following: an
endpoint attempting to listen to conferences in which it is not endpoint attempting to listen to conferences in which it is not
authorized to participate, an endpoint attempting to disconnect or authorized to participate, an endpoint attempting to disconnect or
mute other users, and theft of service, by an endpoint, in attempting mute other users, and theft of service, by an endpoint, in attempting
to create conferences it is not allowed to create. to create conferences it is not allowed to create.
There are several issues surrounding security of this conferencing There are several issues surrounding security of this conferencing
framework. One set of issues involves securing the actual protocols framework. One set of issues involves securing the actual protocols
and the associated authorization mechanisms. This first set of and the associated authorization mechanisms. This first set of
issues should be addressed in the specificiations specific to the issues should be addressed in the specifications specific to the
protocols described in Section 7. The protocols used for protocols described in Section 8. The protocols used for
manipulation and retrieval of confidential information MUST support a manipulation and retrieval of confidential information MUST support a
confidentiality and integrity mechanism. Similar requirements apply confidentiality and integrity mechanism. Similar requirements apply
for the floor control protocols. 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 There are also security issues associated with the authorization to
perform actions on the conferencing system to invoke specific perform actions on the conferencing system to invoke specific
capabilities. Section 4.3 discusses the policies associated with the capabilities. Section 5.3 discusses the policies associated with the
Conference Object to ensure that only authorized entities are able to conference object to ensure that only authorized entities are able to
manipulate the data to access the capabilities. The final set of manipulate the data to access the capabilities. The final set of
issues involves the privacy and security of the identity of a user in issues involves the privacy and security of the identity of a user in
the conference. the conference, which is discussed in Section 11.2
11.1. Authorization
Many policy authorization decisions are based on the identity of the 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 or the role that a user may have. There are several ways that a
user might authenticate its identity to the system. The conferencing user might authenticate its identity to the system. The conferencing
system may know about specific users and assign passwords to the system may know about specific users and assign passwords to the
users. The users may also be authenticated by knowing a particular 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 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 signalling 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 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 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 to provide some authentication to prove it has the identity that was
provided as a hint in the call signalling. This may be in the form provided as a hint in the call signaling. This may be in the form of
of an IVR system or other means. The goal for the Conferencing an IVR system or other means. The goal for the conferencing system
System is to figure out a user identity and a Role for any attempt to is to figure out a user identity and a role for any attempt to send a
send a request to the Conferencing System. request to the conferencing system.
When a Conferencing System presents the identity of authorized users, When a conferencing system presents the identity of authorized users,
it may choose to provide information about the way the identity was 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 proven to or verified by the system. A user may also come as a
completely unauthenticated user into the system - this fact needs completely unauthenticated user into the system - this fact needs
also be communicated to interested parties. also be communicated to interested parties.
When guest users interact with the system, it is often in the context 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 of a particular conference. In this case, the user may provide a PIN
or a password that is specific to the conferences and authenticates or a password that is specific to the conferences and authenticates
the user to take on a certain role in that conference. The guest 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 user can then perform actions that are allowed to any user with that
Role. role.
The term password is used to mean the usual, that is to say a 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. reasonable sized, in number of bits, hard to predict shared secret.
Today users often have passwords with more than 30 bits of randomness 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 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 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 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. 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 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 a row, the PSTN call is disconnected. The rate of making the calls
and getting to the point to enter a PIN makes is fairly hard to do an 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 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 a high speed interface to connect to a conferencing system, it is
often possible to do thousands of attempts per second and the PIN often possible to do thousands of attempts per second and the PIN
space could quickly be searched. Because of this, it is not space could quickly be searched. Because of this, it is not
appropriate to use PINs for authorization on any of the interfaces appropriate to use PINs for authorization on any of the interfaces
that provide fast queries or many simultaneous queries. 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 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 this does not mean it can reveal this identity to other users, due to
privacy considerations. Users can set select various options for privacy considerations. Users can set select various options for
revealing their identity to other users. A user can be "hidden" such 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 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 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" 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 where other users can see their identity. If there are multiple
"anonymous" users, other parties will be able to see them as "anonymous" users, other parties will be able to see them as
independent "anonymous" parties and will be able to tell how many independent "anonymous" parties and will be able to tell how many
"anonymous" parties are in the conference. Note, that the visibility "anonymous" parties are in the conference. Note, that the visibility
to other participants is dependent on their Roles. For example, to other participants is dependent on their roles. For example,
users' visibility (including "anonymous" and "hidden") may be users' visibility (including "anonymous" and "hidden") may be
displayed to the moderator or administrator, subject to a displayed to the moderator or administrator, subject to a
Conferencing System's local policies. "Hidden" status is often used conferencing system's local policies. "Hidden" status is often used
by robot participants of a conference and is also used in many call by robot participants of a conference (e.g., call recording) and is
center conference situations. also used in many call center situations.
11. IANA Considerations 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. This is an informational draft, with no IANA considerations required.
12. Acknowledgements 13. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal, Cullen Henning Schulzrinne for the "Conference Object Tree" proposal and
Jennings for providing input for the "Security Considerations" general feedback, Cullen Jennings for providing input for the
section and Keith Lantz for his careful reviews and constructive "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
input. Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews
and constructive input.
13. Open Issues 14. Changes since last Version
Several open issues are identified in the body of the document. This Changes from WG 01 to 02::
list is intended as a summary to facilitate the tracking of the
primary open issues that require WG input.
1. DP4. Object Schema structure and Template definition. - Editorial nits -i.e. consistent terminology, capatilization, etc.
Clarification of Templates versus Blueprints and details of XML
schema.
2. DP5. CCP Protocol. - Revamped abstract and introduction
14. Changes since last Version - 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).
- - 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:: Changes from WG 00 to 01::
- Section 2 (Conventions and Terminology). Slight modifications to - Section 2 (Conventions and Terminology). Slight modifications to
definitions of Call (control) signalling, Conference Identifer, definitions of Call (control) signaling, Conference Identifer,
Conference Instance, Conference Object. Conference Instance, Conference Object.
- Section 2 (Conventions and Terminology).Renaming of term - Section 2 (Conventions and Terminology).Renaming of term
"Registered Template Definition" to "Registered Conference Document" "Registered Template Definition" to "Registered Conference Document"
(per agreement at interim meeting). (per agreement at interim meeting).
- Section 3 (Next to the last paragraph on the media model). - Section 3 (Next to the last paragraph on the media model).
Clarified the text such that it doesn't read that the focus performs Clarified the text such that it doesn't read that the focus performs
media mixing. Changed "focus" to "media mixer controlled by the media mixing. Changed "focus" to "media mixer controlled by the
focus" in the 2nd sentence and "performed" to "controlled" in the focus" in the 2nd sentence and "performed" to "controlled" in the
4th. 4th.
- Section 5. Rearranged the sub-sections a bit for better flow. - Section 5. Rearranged the sub-sections a bit for better flow.
First describe the Conference ID, then the Conference Instance, First describe the Conference ID, then the Conference Instance,
followed by the Conference Object, with the Conference Object followed by the Conference Object, with the Conference Object
Identifer described in a subsection of the Conference Object Identifer described in a subsection of the Conference Object section.
section. Added a diagram showing the relationship between Conference Added a diagram showing the relationship between Conference
Identifer/Focus and Conference Object Identifier, within the context Identifer/Focus and Conference Object Identifier, within the context
of a Conference Instance to the Conference Object section. of a Conference Instance to the Conference Object section.
- Section 6.1 (Cloning Tree). Rewording to clarify which operations - Section 6.1 (Cloning Tree). Rewording to clarify which operations
apply to independent objects (and non-independent). apply to independent objects (and non-independent).
- Section 6.3 (Advanced Example). Added additional text with regards - Section 6.3 (Advanced Example). Added additional text with regards
to future conferences, introducing the concept of infinite series to future conferences, introducing the concept of infinite series
(which would be limited by calendaring interface). (which would be limited by calendaring interface).
- Section 7.3 (Conference Control Protocol). Updated to include - Section 7.3 (Conference Control Protocol). Updated to include
reference to SOAP option. reference to SOAP option.
- Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit
about the XCON FW constructs used. about the XCON FW constructs used.
Changes from individual 02 to WG 00: Changes from individual 02 to WG 00:
- few minor editorial changes - few minor editorial changes
- Section 2. Removed second sentence of definition of Conference - Section 2. Removed second sentence of definition of Conference ID,
ID, as that's now included/described in context in new Identifier as that's now included/described in context in new Identifier
section. section.
- Section 3. Clarified that TBD in Figure 1 is "Conference Control - Section 3. Clarified that TBD in Figure 1 is "Conference Control
Protocol" (per Keith's comment to be more explicit). Protocol" (per Keith's comment to be more explicit).
- Section 4.1. Identifiers. Moved this to a new section ( - Section 4.1. Identifiers. Moved this to a new section (
Section 5). Section 6).
- New section for Identifiers ( Section 5), thus all section - New section for Identifiers ( Section 6), thus all section
references beyond 4 are incremented in the new version. references beyond 4 are incremented in the new version.
- Section 4. Since section 4.1 was removed, section 4.2 became the - Section 4. Since section 4.1 was removed, section 4.2 became the
body text for section 4. body text for section 4.
- Section 4.2. Added "Floor Information" to Figure 2 as part of - Section 4.2. Added "Floor Information" to Figure 2 as part of
Common Conference Information, also added "Floor Control" to Common Conference Information, also added "Floor Control" to
Conference Template (per text and Cullen's draft). Conference Template (per text and Cullen's draft).
- Section 4.5. Conference policies. Reworded to not introduce new - Section 4.5. Conference policies. Reworded to not introduce new
skipping to change at page 43, line 4 skipping to change at page 44, line 12
- Section 5.4. Added text that there is a single time and that the - Section 5.4. Added text that there is a single time and that the
times are all relative the one time (per DP1 conclusion). times are all relative the one time (per DP1 conclusion).
- Section 5.4. Added text clarifying that changes to a series impact - Section 5.4. Added text clarifying that changes to a series impact
"all future occurrences (per DP1 discussion/conclusion). "all future occurrences (per DP1 discussion/conclusion).
- Section 6.3 - Added subsections for discussion of CSCP and NETCONF - Section 6.3 - Added subsections for discussion of CSCP and NETCONF
as the CCP. as the CCP.
- Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3.
Condensed the text only slightly, but added explicit references to Condensed the text only slightly, but added explicit references to
new identifier section. new identifier section.
- Section 6.4.1 Moved to new Identifier section ( Section 5) - Section 6.4.1 Moved to new Identifier section ( Section 6)
- Section 7.1 - moved example to 7.2. Included a new (more - Section 7.1 - moved example to 7.2. Included a new (more
appropriate example) in 7.1, although this may be too basic. appropriate example) in 7.1, although this may be too basic.
- Section 7.3 - added some proposed text for Sidebars. - Section 7.3 - added some proposed text for Sidebars.
15. References 15. Appendix A - Conference Object Identifier
15.1 Normative References [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.
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
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 |
+---------------+
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.
+---------------+
| 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.
+--------------+
| 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
15.2 Informative References 17.2. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
skipping to change at page 44, line 17 skipping to change at page 50, line 40
draft-ietf-sipping-conferencing-requirements-01 (work in draft-ietf-sipping-conferencing-requirements-01 (work in
progress), October 2004. progress), October 2004.
[11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress), draft-ietf-sipping-conference-package-12 (work in progress),
July 2005. July 2005.
[12] Schulzrinne, H., "Requirements for Floor Control Protocol", [12] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-03 (work in progress), draft-ietf-xcon-floor-control-req-03 (work in progress),
January 2005. October 2005.
[13] Koskelainen, P. and H. Khartabil, "Requirements for Conference [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), August 2004. progress), August 2004.
[14] Even, R. and N. Ismail, "Conferencing Scenarios", [14] Even, R. and N. Ismail, "Conferencing Scenarios",
draft-ietf-xcon-conference-scenarios-04 (work in progress), draft-ietf-xcon-conference-scenarios-05 (work in progress),
April 2005. September 2005.
[15] Johnston, A. and O. Levin, "Session Initiation Protocol Call [15] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-07 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005. June 2005.
[16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-04 (work in progress), May 2005. draft-ietf-xcon-bfcp-05 (work in progress), July 2005.
[17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", [17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004. draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[18] Khartabil, H., "An Extensible Markup Language (XML) [18] Khartabil, H., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usages for Conference Configuration Access Protocol (XCAP) Usages for Conference
Policy Manipulation and Conference Policy Privelges Policy Manipulation and Conference Policy Privelges
Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress), Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress),
October 2004. October 2004.
[19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a [19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Conference Policy", Conference Policy",
draft-ietf-xcon-conference-policy-privileges-01 (work in draft-ietf-xcon-conference-policy-privileges-01 (work in
progress), October 2004. progress), October 2004.
[20] Levin, O. and G. Kimchi, "Centralized Conference Data Model", [20] Levin, O. and G. Kimchi, "Centralized Conference Data Model",
draft-levin-xcon-cccp-02 (work in progress), February 2005. draft-levin-xcon-cccp-02 (work in progress), February 2005.
[21] Jennings, C., "Media Conference Server Control for XCON", [21] Jennings, C. and B. Rosen, "Media Conference Server Control for
draft-jennings-xcon-media-control-02 (work in progress), XCON", draft-jennings-xcon-media-control-03 (work in progress),
February 2005. July 2005.
[22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", [22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
draft-rosen-xcon-conf-sidebars-01 (work in progress), draft-rosen-xcon-conf-sidebars-01 (work in progress),
July 2004. July 2004.
[23] Levin, O. and G. Camarillo, "The SDP (Session Description [23] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress), draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005. January 2005.
[24] Camarillo, G., "Session Description Protocol (SDP) Format for [24] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), draft-camarillo-mmusic-sdp-bfcp-00 (work in progress),
October 2004. October 2004.
[25] Campbell, B., "The Message Session Relay Protocol", [25] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress), draft-ietf-simple-message-sessions-12 (work in progress),
February 2005. October 2005.
[26] Jennings, C. and A. Roach, "Conference State Change Protocol [26] Jennings, C. and A. Roach, "Conference State Change Protocol
(CSCP)", draft-jennings-xcon-cscp-00 (work in progress), (CSCP)", draft-jennings-xcon-cscp-01 (work in progress),
February 2005. July 2005.
[27] Enns, R., "NETCONF Configuration Protocol", [27] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-07 (work in progress), June 2005. draft-ietf-netconf-prot-09 (work in progress), October 2005.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
 End of changes. 237 change blocks. 
1030 lines changed or deleted 1354 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/