draft-ietf-xcon-framework-07.txt   draft-ietf-xcon-framework-08.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: July 26, 2007 C. Boulton Intended status: Informational C. Boulton
Ubiquity Software Corporation Expires: November 15, 2007 Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
January 22, 2007 May 14, 2007
A Framework and Data Model for Centralized Conferencing A Framework for Centralized Conferencing
draft-ietf-xcon-framework-07 draft-ietf-xcon-framework-08
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 July 26, 2007. This Internet-Draft will expire on November 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
a centralized unicast conference. The Centralized Conferencing a centralized unicast conference. The Centralized Conferencing
Framework defines logical entities and naming conventions, along with Framework defines logical entities and naming conventions, along with
a conferencing data model. The framework also outlines a set of a high level conferencing data model. The framework also outlines a
conferencing protocols, which are complementary to the call signaling set of conferencing protocols, which are complementary to the call
protocols, for building advanced conferencing applications. The signaling protocols, for building advanced conferencing applications.
framework binds all the defined components together for the benefit The framework binds all the defined components together for the
of builders of conferencing systems. benefit of builders of conferencing systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10 4.1. Conference Information . . . . . . . . . . . . . . . . . . 12
5.1. Common Conference Information . . . . . . . . . . . . . . 11 4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12 5. Centralized Conferencing Constructs and Identifiers . . . . . 13
6. Centralized Conferencing Constructs and Identifiers . . . . . 12 5.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 12 5.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 5.3. Conference User Identifier . . . . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 6. Conferencing System Realization . . . . . . . . . . . . . . . 16
7. Conferencing System Realization . . . . . . . . . . . . . . . 15 6.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 6.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23
7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22 7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25 7.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25 7.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26 8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 27 8.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 27 8.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 29 8.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 31 8.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 32 8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 34 8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 36 8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40
9.5. Floor control using sidebars . . . . . . . . . . . . . . . 39 8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 41 8.7. Conference Announcements and Recordings . . . . . . . . . 44
9.7. Conference Announcements and Recordings . . . . . . . . . 43 8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45 8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 45 9. Relationships between SIPPING and Centralized Conferencing
10. Relationships between SIPPING and Centralized Conferencing Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 50 10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 51 10.3. Floor Control Server Authentication . . . . . . . . . . . 52
11.3. Floor Control Server Authentication . . . . . . . . . . . 51 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 13. Changes since last Version . . . . . . . . . . . . . . . . . . 53
14. Changes since last Version . . . . . . . . . . . . . . . . . . 52 14. Informative References . . . . . . . . . . . . . . . . . . . . 60
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
15.1. Normative References . . . . . . . . . . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 63
15.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 62
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
a centralized unicast conference. Other than references to general a centralized unicast conference. Other than references to general
functionality (e.g., establishment and teardown), details of these functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document call signaling protocols are outside the scope of this document.
The Centralized Conferencing Framework defines logical entities and The Centralized Conferencing Framework defines logical entities and
naming conventions, along with a conferencing data model. The naming conventions, along with a high level conferencing data model.
framework also outlines a set of conferencing protocols, which are The framework also outlines a set of conferencing protocols, which
complementary to the call signaling protocols, for building advanced are complementary to the call signaling protocols, for building
conferencing applications. advanced conferencing applications.
The Centralized Conferencing Framework is compatible with the The Centralized Conferencing Framework is compatible with the
functional model presented in the SIPPING Conferencing Framework [9]. functional model presented in the SIPPING Conferencing Framework [8].
Section 10 of this document discusses the relationship between the Section 9 of this document discusses the relationship between the
Centralized Conferencing Framework and the SIPPING Conferencing Centralized Conferencing Framework and the SIPPING Conferencing
framework, in the context of the Centralized Conferencing model framework, in the context of the Centralized Conferencing model
presented in this document. presented in this document.
2. Conventions 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", This Centralized Conferencing Framework document generalizes, when
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT appropriate, the SIPPING Conferencing Framework [8] terminology and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as introduces new concepts, as listed below. Further details and
described in BCP 14, RFC 2119 [1] and indicate requirement levels for clarification of the new terms and concepts are provided in the
compliant implementations. subsequent sections of this document.
Active conference: The term active conference refers to a conference
object that has been created and activated via the allocation of
its identifiers (e.g., conference object identifier and conference
identifier) and the associated focus. An active conference is
created based on either a system default conference blueprint or a
specific conference reservation.
Call Signaling protocol: The call signaling protocol is used between
a participant and a focus. In this context, the term "call" means
a channel or session used for media streams.
Conference information: The conference information includes
definitions for basic conference features, such as conference
identifiers, membership, signaling, capabilities and media types,
applicable to a wide range of conferencing applications. The
conference information also includes the media and application
specific data for enhanced conferencing features or capabilities,
such as media mixers. The conference information is the data type
(i.e., the XML schema) for a conference object.
Conference blueprint: A conference blueprint is a static conference
object within a conferencing system, which describes a typical
conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints. Each blueprint is
comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the conference
information.
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 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 based on the
conference information.
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 user identifier (ID): A unique identifier for a user
within the scope of a conferencing system. A user may have
multiple conference user identifiers within a conferencing system
(e.g., to represent different roles).
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[5]) or Message Session Relay Protocol
(defined in [17]).
Role: A role provides the context for the set of conference
operations that a participant can perform. A default role (e.g.,
standard conference participant) will always exist, providing a
user with a set of basic conference operations. Based on system
specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to
a wider set of conference operations.
Sidebar: A sidebar is a separate Conference instance that only
exists within the context of a parent conference instance. The
objective of a sidebar is to be able to provide additional or
alternate media only to specific participants.
Whisper: A whisper involves a one-time media input to a specific
participant(s) within a specific conference instance, accomplished
using a sidebar. An example of a whisper would be an announcement
injected only to the conference chair or to a new participant
joining a conference.
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. The Focus has direct peer relationships with the participants Focus. The Focus has direct peer relationships with the participants
by maintaining a separate call signaling interface with each. by maintaining a separate call signaling interface with each.
Consequently, in this centralized conferencing model, the call Consequently, in this centralized conferencing model, the call
signaling graph is always a star. signaling graph is always a star.
The most basic conference supported in this model would be an ad-hoc The most basic conference supported in this model would be an ad-hoc
unmanaged 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 signaling 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 Agents [8] together with the SIP Call Control Conferencing for User Agents
[13] documents address these types of scenarios. [12] documents address these types of scenarios.
In addition to the basic features, however, a conferencing system In addition to the basic features, however, a conferencing system
supporting the centralized conferencing model proposed in this supporting the centralized conferencing model proposed in this
framework document can offer richer functionality, by including framework document can offer richer functionality, by including
dedicated conferencing applications with explicitly defined dedicated conferencing applications with explicitly defined
capabilities, reserved recurring conferences, along with providing capabilities, reserved recurring conferences, along with providing
the standard protocols for managing and controlling the different the standard protocols for managing and controlling the different
attributes of these conferences. attributes of these conferences.
The core requirements for centralized conferencing are outlined in The core requirements for centralized conferencing are outlined in
[8]. These requirements are applicable for conferencing systems [7]. These requirements are applicable for conferencing systems
using various call signaling protocols, including SIP. Additional using various call signaling protocols, including SIP. Additional
conferencing requirements are provided in [11], and [12]. conferencing requirements are provided in [10], and [11].
The centralizing conferencing system proposed by this framework is The centralizing conferencing system proposed by this framework is
built around a fundamental concept of a conference object. A built around a fundamental concept of a conference object. A
conference object provides the data representation of a conference conference object provides the data representation of a conference
during each of the various stages of a conference (e.g., creation, during each of the various stages of a conference (e.g., creation,
reservation, active, completed, etc.). A conference object is reservation, active, completed, etc.). A conference object is
accessed via the logical functional elements, with whom a accessed via the logical functional elements, with whom a
conferencing client interfaces, using the various protocols conferencing client interfaces, using the various protocols
identified in Figure 1. The functional elements defined for a identified in Figure 1. The functional elements defined for a
conferencing system described by the framework are a Conference conferencing system described by the framework are a Conference
Control Server, Floor Control Server, any number of Foci and a Control Server, Floor Control Server, any number of Foci and a
Notification Service. A Conference Control Protocol (CCP) provides Notification Service. A Conference Control Protocol (CCP) provides
the interface between a conference and media control client and the the interface between a conference and media control client and the
conference control server. A Binary Floor Control Protocol (BFCP) conference control server. A floor control protocol (e.g., BFCP)
provides the interface between a floor control client and the floor provides the interface between a floor control client and the floor
control server. A call signaling protocol (e.g., SIP, H.323, PSTN, control server. A call signaling protocol (e.g., SIP, H.323, PSTN,
etc.) provides the interface between a call signaling client and a etc.) provides the interface between a call signaling client and a
Focus. A notification protocol (e.g. SIP Notify) provides the Focus. A notification protocol (e.g. SIP Notify) provides the
interface between the conferencing client and the Notification interface between the conferencing client and the Notification
Service. Service.
A conferencing system can support a 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. However, there are some in Figure 1 and described in this document. However, there are some
essential components that would typically be used by most other essential components that would typically be used by most other
advanced functions, such as the Notification Service. For example, advanced functions, such as the Notification Service. For example,
the notification service is used to correlate information, such as the notification service is used to correlate information, such as
list of participants with their media streams, between the various list of participants with their media streams, between the various
other components. other components.
................................................................... ....................................................................
. 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 |Binary |Call |Notification |Conference |Binary |Call |Notification
|Control |Floor |Signaling |Protocol |Control |Floor |Signaling |Protocol
|Protocol |Control |Protocol | |Protocol |Control |Protocol |
| |Protocol | | | |Protocol | |
| | | | | | | |
..............|.................|...........|..........|........... ..............|.................|...........|..........|............
. V V V V . . V V V V .
. +----------------+ +------------+ +----------+ +------------+. . +----------------+ +------------+ +----------+ +------------+.
. | Conference | | Floor | | Call | |Notification|. . | Conference | | Floor | | Call | |Notification|.
. | and Media | | Control | | Signaling| | Client |. . | and Media | | Control | | Signaling| | Client |.
. | Control | | Client | | Client | | |. . | Control | | Client | | 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, decentralized, or The media graph of a conference can be centralized, decentralized, 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 decentralized (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 decentralized media case, however, The concepts can also apply to the decentralized media case, however,
the details of such are left for future study. the details of such are left for future study.
Section 5 of this document provides more details on the conference Section 4 of this document provides more details on the conference
object. Section 6 provides an overview of the identifiers necessary object. Section 5 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 7 of this document associated with a conferencing system. Section 6 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 high level data model and how the conference objects are
Section 8 describes the fundamental conferencing mechanisms and maintained. Section 7 describes the fundamental conferencing
provides a high level overview of the protocols. Section 9 then mechanisms and provides a high level overview of the protocols.
provides realizations of various conferencing scenarios, detailing Section 8 then provides realizations of various conferencing
the manipulation of the conference objects using the defined scenarios, detailing the manipulation of the conference objects using
protocols. Section 10 of this document summarizes the relationship the defined protocols. Section 9 of this document summarizes the
between this Centralized Conferencing Framework and the SIPPING relationship between this Centralized Conferencing Framework and the
Conferencing Framework. SIPPING Conferencing Framework.
4. Terminology
This Centralized Conferencing Framework document generalizes, when
appropriate, the SIPPING Conferencing Framework [9] terminology and
introduces new concepts, as listed below. Further details and
clarification of the new terms and concepts are provided in the
subsequent sections of this document.
Active conference: The term active conference refers to a conference
cbject that has been created and activated via the allocation of
its identifiers (e.g., conference object identifier and conference
identifier) and the associated focus. An active conference is
created based on either a system default conference blueprint or a
specific conference reservation.
Call Signaling protocol: The call signaling protocol is used between
a participant and a focus. In this context, the term "call" means
a channel or session used for media streams.
Common conference information: The common conference information
includes definitions for basic conference features, such as
conference identifiers, membership, signaling, capabilities and
media types, applicable to a wide range of conferencing
applications. The common conference information also includes the
media and application specific data for enhanced conferencing
features or capabilities, such as media mixers. The common
conference information is the data type (i.e., the XML schema) for
a conference object
Conference blueprint: A conference blueprint is a static conference
object within a conferencing system, which describes a typical
conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints. Each blueprint is
comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the common conference
information.
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 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 based on the
common conference information.
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 user identifier (ID): A unique identifier for a user
within the scope of a conferencing system. A user may have
multiple conference user identifiers within a conferencing system
(e.g., to represent different roles).
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[6]) or Message Session Relay Protocol
(defined in [18]).
Role: A role provides the context for the set of conference
operations that a participant can perform. A default role (e.g.,
standard conference participant) will always exist, providing a
user with a set of basic conference operations. Based on system
specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to
a wider set of conference operations.
Sidebar: A sidebar is a separate Conference instance that only
exists within the context of a parent conference instance. The
objective of a sidebar is to be able to provide additional or
alternate media only to specific participants.
Whisper: A whisper involves a one-time media input to a specific
participant(s) within a specific conference instance, accomplished
using a sidebar. An example of a whisper would be an announcement
injected only to the conference chair or to a new participant
joining a conference.
5. Centralized Conferencing Data Model 4. Centralized Conferencing Data
The centralized conference data model is logically represented by the The centralized conference data is logically represented by the
conference object. A conference object is of type 'Common conference conference object. A conference object is of type 'Conference
information type', as illustrated in Figure 2. The common conference information type', as illustrated in Figure 2. The conference
information type is extensible for including multiple sub-types. information type is extensible.
+------------------------------------------------------+ +------------------------------------------------------+
| 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 |
| | | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | Common conference information type | | | | Conference information type | |
| | | | | | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Conference description (times, duration) | | | | | | Conference description (times, duration) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Membership (roles, capacity, names) | | | | | | Membership (roles, capacity, names) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Signaling (protocol, direction, status) | | | | | | Signaling (protocol, direction, status) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
skipping to change at page 11, line 4 skipping to change at page 11, line 44
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: Conference Object Type Decomposition. Figure 2: Conference Object Type Decomposition.
In a system based on this conferencing framework, the same conference In a system based on this conferencing framework, the same conference
object type is used for representation of a conference during object type is used for representation of a conference during
different stages of a conference, such as expressing conferencing different stages of a conference, such as expressing conferencing
system capabilities, reserving conferencing resources or reflecting system capabilities, reserving conferencing resources or reflecting
the state of ongoing conferences. Section 7 describes the usage the state of ongoing conferences. Section 6 describes the usage
semantics of the conference objects. semantics of the conference objects. The exact XML schema of the
conference object, including the organization of the conference
The centralized conferencing data model defined in this framework has information is detailed in a separate document [16].
no strict separation between conference membership, conference media
information and the related policies. The policies are an integral
part of the data model and are realized by local, system level
boundaries associated with specific data elements, such as the
membership, and by the ranges and limitations on other data elements.
Additional policy considerations for a system realization based on
this data model are discussed in Section 5.2. The integration of the
data in this model meets the requirement of many conference control
operations to enable synchronized access to the integral conference
policies, to the conference state as a whole, and for receiving
notifications about changes to either using the same interface.
The exact XML schema of the conference object, including the Along with the basic data model as defined in [16], the realization
organization of the common conference information is detailed in a of this framework requires a policy infrastructure. The policies
separate document [17]. required by this framework to manage and control access to the data
include local, system level boundaries associated with specific data
elements, such as the membership, and by the ranges and limitations
of other data elements. Additional policy considerations for a
system realization based on this data model are discussed in
Section 4.2.
5.1. Common Conference Information 4.1. Conference Information
There is a core set of data in the common conference information that There is a core set of data in the conference information that is
is utilized in any conference, independent of the specific conference utilized in any conference, independent of the specific conference
media nature (e.g., the mixing algorithms performed, the advanced media nature (e.g., the mixing algorithms performed, the advanced
floor control applied, etc.). This core set of data in the common floor control applied, etc.). This core set of data in the
conference information contains the definitions representing the conference information contains the definitions representing the
conference object capabilities, membership, roles, call signaling and conference object capabilities, membership, roles, call signaling and
media status relevant to different stages of the conference life- media status relevant to different stages of the conference life-
cycle. This core set of common conference information may be cycle. This core set of conference information may be represented
represented using the conference-type as defined in [10]. Typically, using the conference-type as defined in [9]. Typically, participants
participants with read-only access to the conference information with read-only access to the conference information would be
would be interested in this core set of common conference information interested in this core set of conference information only.
only.
In order to support more complex media manipulations and enhanced In order to support more complex media manipulations and enhanced
conferencing features the common conference information contains conferencing features the conference information, as reflected by the
additional data, beyond that defined in [10]. The data model defined data model defined in [16], contains additional data beyond that
in [17] would be the basis for conferencing systems supporting defined in [9]. The information defined in [16] provides specific
enhanced conferencing features. The additional information defined media mixing details, available floor controls and other data
in [17] provides the details of the specific media mixing details, necessary to support enhanced conferencing features. This
the associated client roles and the available floor controls. This information allows authorized clients to manipulate the mixer's
information would allow authorized clients to manipulate the mixer's behavior via the focus, with the resultant distribution of the media
behavior via the focus, and the resultant distribution of the media
to all or individual participants. By doing so, a client can change to all or individual participants. By doing so, a client can change
its own state and/or state of other participants in the conference. its own state and/or state of other participants in the conference.
New centralized conferencing specifications can extend the basic New centralized conferencing specifications can extend the basic
conference-type as defined in [17] and introduce additional data conference-type as defined in [16] and introduce additional data
elements to be used within the common conference information type. elements to be used within the conference information type.
5.2. Conference policies 4.2. Conference policies
Conference policies collectively refers to a set of rights, Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed permissions and limitations pertaining to operations being performed
on a certain conference object. on a certain conference object.
The set of rights describes the read/write access privileges for the The set of rights describes the read/write access privileges for the
conference object as a whole. This access would usually be granted conference object as a whole. This access would usually be granted
and defined in terms of giving the read-only or read-write access to and defined in terms of giving the read-only or read-write access to
clients with certain roles in the conference. As such, the policies clients with certain roles in the conference. Managing this access
represented by the set of rights aren't explicitly defined within the would require a conferencing system have access to basic policy
data model, but rather are reflected in the system realization information to make the decisions, but doesn't necessarily require an
(Section 7). explicit representation in the policy model. As such, for this
framework document, the policies represented by the set of rights are
The permissions and limits, however, are specified as an integral reflected in the system realization (Section 6).
part of the conference object type, with data objects containing the
allowed ranges for other data objects (e.g., maximum number of
participants) and lists of clients allowed to perform certain
operations on a conference object. For example, the "allowed-users-
list" of participants is consulted to decide who is allowed to join.
The entries in the list can specify the identity of an individual
user (joe@example.com), a role, a domain (*@example.com), etc. For
further details, refer to the detailed data model [17].
A more general rule mechanism, beyond the functionality provided by The permissions and limits require explicit policy mechanisms and are
the permissions and limits, is an item for future study. outside the scope of the data model [16] and this framework document.
6. Centralized Conferencing Constructs and Identifiers 5. 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
centralized conferencing framework constructs and the identifiers centralized conferencing framework constructs and the identifiers
necessary to address and manage the clients associated with a necessary to address and manage the clients associated with a
conferencing system. An overview of the allocation, characteristics conferencing system. An overview of the allocation, characteristics
and functional role of the identifiers is provided. and functional role of the identifiers is provided.
6.1. Conference Identifier 5.1. Conference Identifier
The conference identifier (conference ID) is a call signaling The conference identifier (conference ID) is a call signaling
protocol-specific URI that identifies a specific conference focus and protocol-specific URI that identifies a specific conference focus and
its associated conference instance. A conference factory is one its associated conference instance. A conference factory is one
method for generating a unique conference ID, to identify and address method for generating a unique conference ID, to identify and address
a conference focus, using a call signaling interface. Details on the a conference focus, using a call signaling interface. Details on the
use of a conference factory for SIP signaling can be found in [13]. use of a conference factory for SIP signaling can be found in [12].
The conference identifier can also be obtained using the conference The conference identifier can also be obtained using the conference
control protocol [Section 8.3] or other, including proprietary, out- control protocol or other, including proprietary, out-of-band
of-band mechanisms. mechanisms.
6.2. Conference Object 5.2. Conference Object
A Conference object provides the logical representation of a A Conference object provides the logical representation of a
conference instance in a certain stage, such as a conference conference instance in a certain stage, such as a conference
blueprint representing a conferencing system's capabilities, the data blueprint representing a conferencing system's capabilities, the data
representing a conference reservation, and the conference state representing a conference reservation, and the conference state
during an active conference. Each conference object is independently during an active conference. Each conference object is independently
addressable through the conference control protocol interface addressable through the conference control protocol interface
[Section 8.3]. [Section 7.3].
Figure 3 illustrates the relationships between the conference Figure 3 illustrates the relationships between the conference
identifier, the focus and the conference object ID within the context identifier, the focus and the conference object ID within the context
of a logical conference instance, with the conference object of a logical conference instance, with the conference object
corresponding to an active conference. corresponding to an active conference.
A conference object representing a conference in the active state can A conference object representing a conference in the active state can
have multiple call signalling conference identifiers; for example, have multiple call signaling conference identifiers; for example, for
for each call signalling protocol supported. There is a one-to-one each call signaling protocol supported. There is a one-to-one
mapping between an active conference object and a conference focus. mapping between an active conference object and a conference focus.
The focus is addressed by explicitly associating unique conference The focus is addressed by explicitly associating unique conference
IDs for each signaling protocol supported by the active conference IDs for each signaling protocol supported by the active conference
object. object.
...................................................................... ....................................................................
. Conference Instance . . Conference Instance .
. . . .
. . . .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
. | Conference Object Identifier | . . | Conference Object Identifier | .
. | | . . | | .
. | | . . | | .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
. ^ ^ . . ^ ^ .
. | | . . | | .
skipping to change at page 14, line 31 skipping to change at page 14, line 32
. . |Conference Identifier (Protocol Y)| . | . . . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | . . . +------------------------------------+ | . | .
. . | Conference Identifier (PSTN) | | . | . . . | Conference Identifier (PSTN) | | . | .
. . +--------------------------------------+ |-+ . | . . . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | . . . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | . . . | |-+| . | .
. . | |^ | . | . . . | |^ | . | .
. . +--------------------------------------+| | . | . . . +--------------------------------------+| | . | .
. ............^...............................|.|.... | . . ............^...............................|.|.... | .
. | | | | . . | | | | .
................|...............................|.|......|............ ................|...............................|.|......|..........
| | | | | | | |
|SIP | | |Conference |SIP | | |Conference
| PSTN | |Y |Control | PSTN | |Y |Control
| | | |Protocol | | | |Protocol
| +---------------+ | | | +---------------+ | |
| | | | | | | |
| | | | | | | |
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: Identifier Relationships for an Active Conference. Figure 3: Identifier Relationships for an Active Conference.
6.2.1. Conference Object Identifier 5.2.1. Conference Object Identifier
In order to make each conference object externally accessible, the In order to make each conference object externally accessible, the
conferencing system allocates a unique URI per distinct conference conferencing system allocates a unique URI per distinct conference
object in the system. A conference control protocol includes the object in the system. The conference object identifier is created
conference object identifier in requests for directly manipulating a both by the conferencing system based on internal actions as well as
particular conference object and for obtaining its current state. based on specific conference protocol requests. A conferencing
system will allocate a conferencing object identifier for every
conference blueprint, for every conference reservation and for every
active conference. The distribution of the conference object
identifier depends upon the specific use case and includes a variety
of mechanisms, such as the through the conference control protocol
mechanism, the data model and conference package or out of band
mechanisms such as E-Mail.
When a user wishes to create or join a conference and the user does
not have the conference object identifier for the specific
conference, more general signaling mechanisms apply, such that a user
may have a pre-configured conference object identifier to access the
conferencing system or other signaling protocols may be used and the
conferencing system maps those to a specific conference object
identifier. Once a conference is established, a conference object
identifier is required for the user to manipulate any of the
conferencing data or take advantage of any of the advanced
conferencing features. The same notion applies to users joining a
conference using other signaling protocols. They are able to
initially join a conference using any of the other signaling
protocols supported by the specific conferencing system, but the
conference object identifer must be used to manipulate any of the
conferencing data or take advantage of any of the advanced
conferencing features. As mentioned previously, the mechanism by
which the user learns of the conference object identifier varies and
could be via the conference control protocol, using the data model
and conference package or entirely out of band such as E-Mail or a
web interface.
The conference object identifier logically maps to other protocol The conference object identifier logically maps to other protocol
specific identifiers associated with the conference instance, such as specific identifiers associated with the conference instance, such as
the BFCP 'confid'. A full description and semantics of how the the BFCP 'confid'. The conference object identifier is defined in
conference object identifier is created and used as defined in [19]. [16].
6.3. Conference User Identifier 5.3. Conference User Identifier
Each user within a conferencing system is allocated a unique Each user within a conferencing system is allocated a unique
conference user identifier. The user identifier is used in conference user identifier. The user identifier is used in
association with the conference object identifier to uniquely association with the conference object identifier to uniquely
identify a user within the scope of conferencing system. There is identify a user within the scope of conferencing system. There is
also a requirement for identifying conferencing system users who may also a requirement for identifying conferencing system users who may
not be participating in a conference instance. Examples of these not be participating in a conference instance. Examples of these
users would be a non participating 'Floor Control Chair' or 'Media users would be a non participating 'Floor Control Chair' or 'Media
Policy Controller'. The conference user identifier is required in Policy Controller'. The conference user identifier is required in
conference control protocol requests to uniquely determine who is conference control protocol requests to uniquely determine who is
issuing commands, so that appropriate policies can be applied to the issuing commands, so that appropriate policies can be applied to the
requested command. The conference user identifer is logically requested command.
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 [20].
7. Conferencing System Realization A typical mode for distributing the user identifer is out of band
during conferencing client configuration, thus the mechanism is
outside the scope of the centralized conferencing framework and
protocols. However, a conferencing system must also be capable of
allocating and distributing a user identifier during the first
signaling interaction with the conferencing system, such as an
initial request for blueprints or adding a new user to an existing
conference using the conference control protocol. When a user joins
a conference using a signaling specific protocol, such as SIP for a
dial-in conference, a conference user identifier must be assigned if
one is not already associated with that user. While this conference
user identifier isn't required for the participant to join the
conference, it is required to be allocated and assigned by the
conferencing system such that it is available for use for any
subsequent conference control protocol operations and/or
notifications associated with that conference. For example, the
conference user identifer would be sent in any notifications that may
be sent to existing participants, such as the moderator, when this
user joins.
The conference user identifier is logically associated with the other
user identifiers assigned to the conferencing client for other
protocol interfaces, such as an authenticated SIP user. The
conference user identifier is defined in [16].
6. Conferencing System Realization
Implementations based on this centralized conferencing framework can Implementations based on this centralized conferencing framework can
range from systems supporting ad-hoc conferences, with default range from systems supporting ad-hoc conferences, with default
behavior only, to sophisticated systems with the ability to schedule behavior only, to sophisticated systems with the ability to schedule
recurring conferences, each with distinct characteristics, being recurring conferences, each with distinct characteristics, being
integrated with external resource reservation tools, and providing integrated with external resource reservation tools, and providing
snapshots of the conference information at any of the stages of the snapshots of the conference information at any of the stages of the
conference life-cycle. 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. Consequently, this centralized by the conferencing system. Consequently, this centralized
conferencing framework does not mandate the actual usage of the conferencing framework does not mandate the actual usage of the
conference object, but rather defines the general cloning tree 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, as described
in detail in Section 7.1. in detail in Section 6.1.
Adhoc and advanced conferencing examples are provided in Section 7.2 Adhoc and advanced conferencing examples are provided in Section 6.2
and Section 7.3, with the latter providing additional description of and Section 6.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 capabilities. The support scheduled and other advanced conference capabilities. The
scheduling of a conference based on these concepts and mechanisms is scheduling of a conference based on these concepts and mechanisms is
then detailed in Section 7.4 then detailed in Section 6.4
As discussed in Section 5.2, there are conference policies implicit As discussed in Section 4.2, the overall policy in terms of
in and derivable from the data in the conference objects and there permissions and limitations is outside the scope of this framework
are also policies applying to the conference objects as a whole. In document. The policies applicable to the conference object as a
the examples in this section, these latter policies are shown whole in terms of read/write access would require a conferencing
logically associated with the conference objects, however, it is an system have access to basic policy information to make the decisions.
implementation specific mechanism as to how these policies are In the examples in this section, the policies are shown logically
managed and applied to the conference objects. associated with the conference objects to emphasize the general
requirement for policy functionality necessary for the realization of
this framework.
7.1. Cloning Tree 6.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 centralized conferencing mechanisms: as it is reflected through the centralized conferencing mechanisms:
the URIs and the protocols. Of course, the actual system realization the URIs and the protocols. Of course, the actual system realization
can differ from the presented model. The intent is to illustrate the can differ from the presented model. The intent is to illustrate the
role of the logical elements in providing an interface to the data, role of the logical elements in providing an interface to the data,
based on conferencing system and conferencing client actions, and based on conferencing system and conferencing client actions, and
describe the resultant protocol implications 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 conference blueprint. A implicitly cloned from a default system conference blueprint. A
conference blueprint is a static conference object used to describe a conference blueprint is a static conference object used to describe a
typical conference setting supported by the system. Each system can typical conference setting supported by the system. Each system can
maintain multiple blueprints, typically each describing a different maintain multiple blueprints, typically each describing a different
conferencing type using the common conference information format. conferencing type using the conference information format. This
This document uses the "cloning" metaphor instead of the document uses the "cloning" metaphor instead of the "inheritance"
"inheritance" metaphor because it more closely fits the idea of metaphor because it more closely fits the idea of object replication,
object replication, rather than a data type re-usage and extension rather than a data type re-usage and extension concept.
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.
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 [19]. conference object URI assigned by the system, as described in
By default, the newly created object contains all the data existing Section 5.2.1. By default, the newly created object contains all the
in the parent object. The newly created object can expand the data data existing in the parent object. The newly created object can
it contains, within the schema types supported by the parent. It can expand the data it contains, within the schema types supported by the
also restrict the read/write access to its objects. However, unless parent. It can also restrict the read/write access to its objects.
the object is independent, it cannot modify the access restrictions However, unless the object is independent, it cannot modify the
imposed by the parent object. access restrictions imposed by the parent object.
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 elements can not be changed enforceable". The values of these data elements can not be changed
by directly accessing the child object; neither can they be expanded by directly accessing the child object; neither can they be expanded
in the child object alone. in the child object alone.
skipping to change at page 19, line 5 skipping to change at page 20, line 5
| 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 4: 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 systems based on this framework can be show examples of how different systems based on this framework can be
realized. realized.
7.2. Ad-hoc Example 6.2. Ad-hoc Example
Figure 5 illustrates how an ad-hoc conference can be created and Figure 5 illustrates how an ad-hoc conference can be created and
managed in a conferencing system. A client can create a conference managed in a conferencing system. A client can create a conference
by establishing a call signaling channel with a conference factory as by establishing a call signaling channel with a conference factory as
specified in Section 6.1. The conference factory can internally specified in Section 5.1. The conference factory can internally
select one of the system supported conference blueprints based on the select one of the system supported conference blueprints based on the
requesting client privileges and the media lines included in the SDP requesting client privileges and the media lines included in the SDP
body. 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 8.3]. Conference Control Protocol.
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | System Default | | o | System Default |
| l | | | l | |
| i | Conference | | i | Conference |
| c | | | c | |
| i | Blueprint | | i | Blueprint |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
skipping to change at page 20, line 6 skipping to change at page 21, line 6
| p | | | p | |
| o | Active | | o | Active |
| l | | | l | |
| i | Conference | | i | Conference |
| c | | | c | |
| i | | | i | |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime. Figure 5: Conference Ad-hoc Creation and Lifetime.
7.3. Advanced Example 6.3. Advanced Example
Figure 6 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 client would first query a conferencing a conferencing system. A client would first query a conferencing
system for its capabilities. This can be done by requesting a list system for its capabilities. This can be done by requesting a list
of the conference blueprints the system supports. Each blueprint of the conference blueprints the system supports. Each blueprint
contains a specific combination of capabilities and limitations of contains a specific combination of capabilities and limitations of
the conference server in terms of supported media types (e.g., audio, the conference server in terms of supported media types (e.g., audio,
video, text, or combinations of these), participant roles, maximum video, text, or combinations of these), participant roles, maximum
number of participants of each role, availability of floor control, number of participants of each role, availability of floor control,
skipping to change at page 22, line 6 skipping to change at page 23, line 6
Figure 6: Advanced Conference Definition, Creation, and Lifetime. Figure 6: Advanced Conference Definition, Creation, and Lifetime.
When the time comes to schedule the conference reservation, either When the time comes to schedule the conference reservation, either
via the system determination that the 'start' time has been reached via the system determination that the 'start' time has been reached
or via client invocation, an active conference is cloned based on the or via client invocation, an active conference is cloned based on the
conference reservation. As in the adhoc example, the active conference reservation. As in the adhoc example, the active
conference is independent from the parent and changes to the conference is independent from the parent and changes to the
conference reservation will not impact the active conference. Any conference reservation will not impact the active conference. Any
desired changes must be targeted towards the active conference. An desired changes must be targeted towards the active conference. An
example of this interaction is shown in Section 9.1 example of this interaction is shown in Section 8.1
7.4. Scheduling a conference 6.4. Scheduling a conference
The capability to schedule conferences forms an important part of the The capability to schedule conferences forms an important part of the
conferencing system solution. An individual conference reservation conferencing system solution. An individual conference reservation
typically has a specified 'start' and 'end' time, with the times typically has a specified 'start' and 'end' time, with the times
being specified relative to a single specified 'fixed' time (e.g., being specified relative to a single specified 'fixed' 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 occurrence of a possible to not only schedule an individual occurrence of a
conference reservation, but also schedule a series of related conference reservation, but also schedule a series of related
conferences (e.g., a weekly meeting that starts on Thursday at 09.00 conferences (e.g., a weekly meeting that starts on Thursday at 09.00
GMT). 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
reservations that form part of a recurring conference. The mechanism reservations that form part of a recurring conference. The mechanism
proposed in this document makes use of the 'Internet Calendaring and proposed in this document makes use of the 'Internet Calendaring and
Scheduling Core Object' specification defined in RFC2445[7] in union Scheduling Core Object' specification defined in RFC2445[6] in union
with the concepts introduced in Section 5 for the purpose of with the concepts introduced in Section 4 for the purpose of
achieving advanced conference scheduling capability. achieving advanced conference scheduling capability.
Figure 7 illustrates a simplified view of a client interacting with a Figure 7 illustrates a simplified view of a client interacting with a
conferencing system. The client is using the Conference Control conferencing system. The client is using the Conference Control
Protocol (Section 8.3) to add a new conference reservation to the Protocol to add a new conference reservation to the conferencing
conferencing system by interfacing with the conference control system by interfacing with the conference control server. A CCP
server. A CCP request contains a valid conference reservation and request contains a valid conference reservation and reference by
reference by value to an 'iCal' object which contains scheduling value to an 'iCal' object which contains scheduling information about
information about the conference (e.g., start time, end time). the conference (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 23, line 47 skipping to change at page 24, line 47
| Conferencing| | Conferencing|
| Client | | Client |
+-------------+ +-------------+
Figure 7: Resource Scheduling Figure 7: Resource Scheduling
A CCP request to create a new conference reservation is validated, A CCP request to create a new conference reservation is validated,
including the associated iCal object, and the resultant conference including the associated iCal object, and the resultant conference
reservation is created. The conference reservation is uniquely reservation is created. The conference reservation is uniquely
represented within the conferencing system by a conference object represented within the conferencing system by a conference object
identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and identifier (e.g., xcon:hd87928374) as introduced in Section 5.2.1 and
defined in [19]. This unique URI is returned to the client and can defined in [16]. This unique URI is returned to the client and can
be used to reference the conference reservation, if any future be used to reference the conference reservation, if any future
manipulations are required (e.g., alter start time), using a CCP manipulations are required (e.g., alter start time), using a CCP
request. request.
The previous example explains how a client creates a basic conference The previous example explains how a client creates a basic conference
reservation using an iCal reference in association with a conference reservation using an iCal reference in association with a conference
control protocol. Figure 7 can also be applied when explaining how a control protocol. Figure 7 can also be applied when explaining how a
series of conferences are scheduled in the system. The description series of conferences are scheduled in the system. The description
is almost identical with the exception that the iCal definition that is almost identical with the exception that the iCal definition that
is included in a CCP request represents a series of recurring is included in a CCP request represents a series of recurring
skipping to change at page 25, line 8 skipping to change at page 26, line 8
conference instances, has its own associated conference object ID conference instances, has its own associated conference object ID
which is returned to the client using a CCP response. This which is returned to the client using a CCP response. This
conference object ID is then used by the client to make any future conference object ID is then used by the client to make any future
alterations on the newly defined sub-series. This process can be alterations on the newly defined sub-series. This process can be
repeated any number of times as the newly returned conference object repeated any number of times as the newly returned conference object
ID representing an altered (cloned) series of conference instances, ID representing an altered (cloned) series of conference instances,
can itself be manipulated using a CCP request for the newly created can itself be manipulated using a CCP request for the newly created
conference object ID . This provides a flexible approach to the conference object ID . This provides a flexible approach to the
scheduling of recurring conference instances. scheduling of recurring conference instances.
8. Conferencing Mechanisms 7. Conferencing Mechanisms
8.1. Call Signaling 7.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 signaling protocol interface with the focus using an appropriate call signaling protocol
(CSP). Participants request to establish or join a conference using (CSP). Participants request to establish or join a conference using
the CSP. After checking the applicable policies, a focus then either the CSP. After checking the applicable policies, a focus then either
accepts the request, sends a progress indication related to the accepts the request, sends a progress indication related to the
status of the request (e.g., for a parked call while awaiting status of the request (e.g., for a parked call while awaiting
moderator approval to join) or rejects that request using the call moderator approval to join) or rejects that request using the call
signaling interface. signaling interface.
During an active conference, a Conference Control Protocol During an active conference, a Conference Control Protocol can be
[Section 8.3] can be used to affect the conference state. For used to affect the conference state. For example, CCP requests to
example, CCP requests to add and delete participants are communicated add and delete participants are communicated to the focus and checked
to the focus and checked against the conference policies. If against the conference policies. If approved, the participants are
approved, the participants are added or deleted using the call added or deleted using the call signaling to/from the focus.
signaling to/from the focus.
8.2. Notifications 7.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,
including participants. A model for notifications using SIP is including participants. A model for notifications using SIP is
defined in [5] with the specifics to support conferencing defined in defined in [4] with the specifics to support conferencing defined in
[10]. [9].
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.
8.3. Conference Control Protocol 7.3. Conference Control Protocol
The conference control protocol provides for data manipulation and The conference control protocol provides for data manipulation and
state retrieval for the centralized conferencing data, represented by state retrieval for the centralized conferencing data, represented by
the conference object. The details of the conference control the conference object. The details of the conference control
protocol are provided in separate documents. protocol are provided in separate documents.
8.4. Floor Control 7.4. Floor Control
A floor control protocol allows an authorized client to manage access A floor control protocol allows an authorized client to manage access
to a specific floor and to grant, deny or revoke access of other to a specific floor and to grant, deny or revoke access of other
conference users to that floor. Floor control is not a mandatory conference users to that floor. Floor control is not a mandatory
mechanism for a conferencing system implementation but provides mechanism for a conferencing system implementation but provides
advanced media input control features for conference users. A advanced media input control features for conference users. A
mechanism for floor control within a conferencing system is defined mechanism for floor control within a conferencing system is defined
in the Binary Floor Control Protocol specification [14]. in the Binary Floor Control Protocol specification [13].
Within this framework, a client supporting floor control needs to Within this framework, a client supporting floor control needs to
obtain information for connecting to a floor control server to enable obtain information for connecting to a floor control server to enable
it to issue floor requests. This connection information can be it to issue floor requests. This connection information can be
retrieved using information provided by mechanisms such as retrieved using information provided by mechanisms such as
negotiation using the SDP[2] offer/answer[4] exchange on the negotiation using the SDP[1] offer/answer[3] exchange on the
signaling interface with the focus. Section 11.3 provides a signaling interface with the focus. Section 10.3 provides a
discussion of client authentication of a floor control server. discussion of client authentication of a floor control server.
As well as the client to the floor control server connection As well as the client to the floor control server connection
information, a client wishing to interact with a floor control server information, a client wishing to interact with a floor control server
requires access to additional information. This information requires access to additional information. This information
associates floor control interactions with the appropriate floor associates floor control interactions with the appropriate floor
instance. Once a connection has been established and authenticated instance. Once a connection has been established and authenticated
(see [14] for authentication details), a specific floor control (see [13] for authentication details), a specific floor control
message requires detailed information to uniquely identify a message requires detailed information to uniquely identify a
conference, a user and a floor. conference, a user and a floor.
The conference is uniquely identifed by the conference object ID per The conference is uniquely identifed by the conference object ID per
Section 6.2.1. This conference object ID must be included in all Section 5.2.1. This conference object ID must be included in all
floor control messages. When the SDP model is used as described in floor control messages. When the SDP model is used as described in
[16] this identifier maps to the 'confid' SDP attribute. [15] this identifier maps to the 'confid' SDP attribute.
Each authorized user associated with a conference object is uniquely Each authorized user associated with a conference object is uniquely
represented by a conference user ID per Section 6.3. This conference represented by a conference user ID per Section 5.3. This conference
user ID must be included in all floor control messages. When using user ID must be included in all floor control messages. When using
SDP offer/answer exchange to negotiate a Floor control connection SDP offer/answer exchange to negotiate a Floor control connection
with the focus using the call signaling protocol, the unique with the focus using the call signaling protocol, the unique
conference user identifier is contained in the 'userid' SDP conference user identifier is contained in the 'userid' SDP
attribute, as defined in [16] attribute, as defined in [15]
A media session within a conferencing system can have any number of A media session within a conferencing system can have any number of
floors (0 or more) that are represented by the conference identifer. floors (0 or more) that are represented by the conference identifier.
When using SDP offer/answer exchange to negotiate a floor control When using SDP offer/answer exchange to negotiate a floor control
connection with the focus using the call signaling interface, the connection with the focus using the call signaling interface, the
unique conference identifier is contained in the 'floorid' SDP unique conference identifier is contained in the 'floorid' SDP
attribute, as defined in [16] e.g., a=floorid:1 m-stream:10 . Each attribute, as defined in [15] e.g., a=floorid:1 m-stream:10 . Each
'floorid' attribute, representing a unique floor, has an 'm-stream' 'floorid' attribute, representing a unique floor, has an 'm-stream'
tag containing one or more identifiers. The identifiers represent tag containing one or more identifiers. The identifiers represent
individual SDP media sessions (as defined using 'm=' from SDP) using individual SDP media sessions (as defined using 'm=' from SDP) using
the SDP 'Label' attribute as defined in [15]. the SDP 'Label' attribute as defined in [14].
9. Conferencing Scenario Realizations 8. Conferencing Scenario Realizations
This section addresses how advanced conferencing scenarios, many of This section addresses how advanced conferencing scenarios, many of
which have been described in [12], are realized using this which have been described in [11], are realized using this
centralized conferencing framework. The objective of this section is centralized conferencing framework. The objective of this section is
to further illustrate the model, mechanisms and protocols presented to further illustrate the model, mechanisms and protocols presented
in the previous sections and also serves to validate that the model, in the previous sections and also serves to validate that the model,
mechanisms and protocols are sufficient to support advanced mechanisms and protocols are sufficient to support advanced
conferencing scenarios. conferencing scenarios.
The scenarios provide a high level primitive view of the necessary The scenarios provide a high level primitive view of the necessary
operations and general logic flow. The details shown in the operations and general logic flow. The details shown in the
scenarios are for illustrative purposes only and don't necessarily scenarios are for illustrative purposes only and don't necessarily
reflect the actual structure of the conference control protocol reflect the actual structure of the conference control protocol
messages nor the detailed data, including states, which are defined messages nor the detailed data, including states, which are defined
in separate documents. It should be noted that not all entities in separate documents. It should be noted that not all entities
impacted by the request are shown in the diagram (e.g., Focus), but impacted by the request are shown in the diagram (e.g., Focus), but
rather the emphasis is on the new entities introduced by this rather the emphasis is on the new entities introduced by this
centralized conferencing framework. centralized conferencing framework.
9.1. Conference Creation 8.1. Conference Creation
There are different ways to create a conference. A participant can There are different ways to create a conference. A participant can
create a conference using call signaling means only, such as SIP and create a conference using call signaling means only, such as SIP and
detailed in [13]. For a conferencing client to have more flexibility detailed in [12]. For a conferencing client to have more flexibility
in defining the charaterisitics and capabilities of a conference, a in defining the charaterisitics and capabilities of a conference, a
conferencing client would implement a conference control protocol conferencing client would implement a conference control protocol
client. By using a conference control protocol, the client can client. By using a conference control protocol, the client can
determine the capabilities of a conferencing system and its various determine the capabilities of a conferencing system and its various
resources. resources.
Figure 8 provides an example of one client "Alice" determining the Figure 8 provides an example of one client "Alice" determining the
conference blueprints available for a particular conferencing system conference blueprints available for a particular conferencing system
and creating a conference based on the desired blueprint. and creating a conference based on the desired blueprint.
skipping to change at page 29, line 44 skipping to change at page 30, line 44
existing reservations. In this example, "Alice" has reserved a existing reservations. In this example, "Alice" has reserved a
meetme conference bridge. Thus, "Alice" provides the conference meetme conference bridge. Thus, "Alice" provides the conference
information, including the necessary conference ID, to desired information, including the necessary conference ID, to desired
participants. When the first participant, including "Alice", participants. When the first participant, including "Alice",
requests to be added to the conference, an active conference and requests to be added to the conference, an active conference and
focus are created. The focus is associated with the conference ID focus are created. The focus is associated with the conference ID
received in the request. Any participants that have the authority to received in the request. Any participants that have the authority to
manipulate the conference would receive the conference object manipulate the conference would receive the conference object
identifier of the active conference object in the response. identifier of the active conference object in the response.
9.2. Participant Manipulations 8.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 signaling 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 signaling" 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
signaling only, may also be available for some signaling protocols. signaling only, may also be available for some signaling protocols.
For example, "Conferencing for SIP User Agents" [13] shows how SIP For example, "Conferencing for SIP User Agents" [12] 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 9 provides an example of one client "Alice" impacting the Figure 9 provides an example of one client "Alice" impacting the
skipping to change at page 31, line 21 skipping to change at page 32, line 21
User Identifier is created for Bob. Based upon the addressing User Identifier is created for Bob. Based upon the addressing
information provided for "Bob" by "Alice", the call signaling to add information provided for "Bob" by "Alice", the call signaling to add
"Bob" to the conference is instigated through the Focus. "Bob" to the conference is instigated through the Focus.
Once the call signaling 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.
9.3. Media Manipulations 8.3. Media Manipulations
There are different ways to manipulate the media in a conference. A There are different ways to manipulate the media in a conference. A
participant can change its own media streams by, for example, sending participant can change its own media streams by, for example, sending
re-INVITE with new SDP content using SIP only. This kind of re-INVITE with new SDP content using SIP only. This kind of
operation is called "1st party signaling" and they do not affect the operation is called "1st party signaling" and they do not affect the
state of other participants in the conference. 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
skipping to change at page 32, line 15 skipping to change at page 33, line 15
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Active || | Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Conference || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | | || +--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
| ' ' '| "Carol" | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ | | Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
"Bob"
Figure 10: 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 the conference object is updated to is marked as "recvonly" and the conference object is updated to
reflect that "Bob's" media is not to be "mixed" with the conference reflect that "Bob's" media is not to be "mixed" with the conference
media. 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.
9.4. Sidebar Manipulations 8.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 7.1. employed for a standard conference as described in Section 6.1.
A conference object representing a sidebar is created by cloning the A conference object representing a sidebar is created by cloning the
parent associated with the existing conference and updating any parent associated with the existing conference and updating any
information specific to the sidebar. A sidebar conference object is information specific to the sidebar. A sidebar conference object is
implicitly linked to the parent conference object (i.e. it is not an implicitly linked to the parent conference object (i.e. it is not an
independent object) and is associated with the parent conference independent object) and is associated with the parent conference
object identifier as as shown in Figure 11. A conferencing system object identifier as shown in Figure 11. A conferencing system
manages and enforces the parent and appropriate localized manages and enforces the parent and appropriate localized
restrictions on the sidebar conference object (e.g., no members from restrictions on the sidebar conference object (e.g., no members from
outside the parent conference instance can join, sidebar conference outside the parent conference instance can join, sidebar conference
can not exist if parent conference is terminated, etc.). can not exist if parent conference is terminated, etc.).
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------+ +--------------+
skipping to change at page 33, line 34 skipping to change at page 34, line 34
| Conference | | Conference | | Conference | | Conference | | Conference | | Conference |
| Object | | Object | | Object | | Object | | Object | | Object |
| Identifier | | Identifier | | Identifier | | Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+ +-------+-------+ +-------+-------+ +---------------+
Figure 11: Conference Object Mapping. Figure 11: Conference Object Mapping.
Figure 11 illustrates the relationship between a conference object Figure 11 illustrates the relationship between a conference object
and associated Sidebar conference objects within a conferencing and associated Sidebar conference objects within a conferencing
system. Each Sidebar conference object has a unique conference system. Each Sidebar conference object has a unique conference
object Identifier as described in Section 6.2.1. The main conference object Identifier as described in Section 5.2.1. The main conference
object identifier acts as a top level identifier for associated object identifier acts as a top level identifier for associated
sidebars. 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 7.1. A outlined in the cloning tree model described in Section 6.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 using the
(Section 8.3) using the unique conference object identifier for the unique conference object identifier for the sidebar. It is also
sidebar. It is also possible for the top level conference object to possible for the top level conference object to enforce policy on the
enforce policy on the sidebar object (similar to parent enforceable sidebar object (similar to parent enforceable as discussed in
as discussed in Section 7.1). Section 6.1).
9.4.1. Internal Sidebar 8.4.1. Internal Sidebar
Figure 12 provides an example of one client "Alice" involved in Figure 12 provides an example of one client "Alice" involved in
active conference with "Bob" and "Carol". "Alice" wants to create a active conference with "Bob" and "Carol". "Alice" wants to create a
sidebar to have a side discussion with "Bob" while still viewing the sidebar to have a side discussion with "Bob" while still viewing the
video associated with the main conference. Alternatively, the audio video associated with the main conference. Alternatively, the audio
from the main conference could be maintained at a reduced volume. from the main conference could be maintained at a reduced volume.
"Alice" initiates the sidebar by sending a request to the "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference reservation based upon the conferencing system to create a conference reservation based upon the
active conference object. "Alice" and "Bob" would remain on the active conference object. "Alice" and "Bob" would remain on the
roster of the main conference, such that other participants could be roster of the main conference, such that other participants could be
skipping to change at page 36, line 44 skipping to change at page 37, line 44
policies associated with that specific conference object to perform policies associated with that specific conference object to perform
the operation. The conferencing system must also validate the the operation. The conferencing system must also validate the
updated information in the reservation, ensuring that a member like updated information in the reservation, ensuring that a member like
"Bob" is already a user of this conferencing system. "Bob" is already a user of this conferencing system.
Depending upon the policies, the initiator of the request (i.e., Depending upon the policies, the initiator of the request (i.e.,
"Alice") and the participants in the sidebar (i.e., "Bob") may be "Alice") and the participants in the sidebar (i.e., "Bob") may be
notified of his addition to the sidebar via the conference notified of his addition to the sidebar via the conference
notification service. notification service.
9.4.2. External Sidebar 8.4.2. External Sidebar
Figure 13 provides an example of one client "Alice" involved in an Figure 13 provides an example of one client "Alice" involved in an
active conference with "Bob", "Carol", "David" and "Ethel". "Alice" active conference with "Bob", "Carol", "David" and "Ethel". "Alice"
gets an important text message via a whisper from "Bob" that a gets an important text message via a whisper from "Bob" that a
critical customer needs to talk to "Alice", "Bob" and "Ethel". critical customer needs to talk to "Alice", "Bob" and "Ethel".
"Alice" creates a sidebar to have a side discussion with the customer "Alice" creates a sidebar to have a side discussion with the customer
"Fred" including the participants in the current conference with the "Fred" including the participants in the current conference with the
exception of "Carol" and "David", who remain in the active exception of "Carol" and "David", who remain in the active
conference. "Alice" initiates the sidebar by sending a request to conference. "Alice" initiates the sidebar by sending a request to
the conferencing system to create a conference reservation based upon the conferencing system to create a conference reservation based upon
skipping to change at page 39, line 15 skipping to change at page 40, line 15
system, a conference user identifier is created for "Fred". Based system, a conference user identifier is created for "Fred". Based
upon the addressing information provided for "Fred" by "Alice", the upon the addressing information provided for "Fred" by "Alice", the
call signaling to add "Fred" to the conference is instigated through call signaling to add "Fred" to the conference is instigated through
the Focus. the Focus.
Depending upon the policies, the initiator of the request (i.e., Depending upon the policies, the initiator of the request (i.e.,
"Alice") and the participants in the sidebar (i.e., "Bob" and "Alice") and the participants in the sidebar (i.e., "Bob" and
"Ethel") may be notified of his addition to the sidebar via the "Ethel") may be notified of his addition to the sidebar via the
conference notification service. conference notification service.
9.5. Floor control using sidebars 8.5. Floor control using sidebars
Floor control with sidebars can be used to realize conferencing Floor control with sidebars can be used to realize conferencing
scenario such as an analyst briefing. In this scenario, the scenario such as an analyst briefing. In this scenario, the
conference call has a panel of speakers who are allowed to talk in conference call has a panel of speakers who are allowed to talk in
the main conference. The other participants are the analysts, who the main conference. The other participants are the analysts, who
are not allowed to speak unless they have the floor. To request are not allowed to speak unless they have the floor. To request
access to the floor, they have to join a new sidebar with the access to the floor, they have to join a new sidebar with the
moderator and ask their question. The moderator can also whisper to moderator and ask their question. The moderator can also whisper to
each analyst what their status/position in the floor control queue, each analyst what their status/position in the floor control queue,
similar to the example in Figure 15 similar to the example in Figure 15
skipping to change at page 41, line 12 skipping to change at page 42, line 12
Figure 14: Floor Control with sidebars Figure 14: Floor Control with sidebars
When "A1" wishes to ask a question, he sends a Floor Request message When "A1" wishes to ask a question, he sends a Floor Request message
to the floor control server. Upon receipt of the request, the floor to the floor control server. Upon receipt of the request, the floor
control server notifies the moderator, "Carol" of the active sidebar control server notifies the moderator, "Carol" of the active sidebar
conference, whose serving as the floor chair. Note, that this conference, whose serving as the floor chair. Note, that this
signaling flow is not shown in the diagram. Since no other analysts signaling flow is not shown in the diagram. Since no other analysts
have yet requested the floor, "Carol" indicates to the floor control have yet requested the floor, "Carol" indicates to the floor control
server that "A1" may be granted the floor. server that "A1" may be granted the floor.
9.6. Whispering or Private Messages 8.6. Whispering or Private Messages
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
two participants, similar to the example in section Section 9.4.1, two participants, similar to the example in section Section 8.4.1,
but rather than using audio within the sidebar, "Alice" could add an but rather than using audio within the sidebar, "Alice" could add an
additional text based media stream to the sidebar. The other additional text based media stream to the sidebar. The other
context, referred to as whisper, in this document refers to context, referred to as whisper, in this document refers to
situations involving one time media targetted to specific user(s). situations involving one time media targetted to specific user(s).
An example of a whisper would be an announcement injected only to the An example of a whisper would be an announcement injected only to the
conference chair or to a new participant joining a conference. conference chair or to a new participant joining a conference.
Figure 15 provides an example of one user "Alice" whose chairing a Figure 15 provides an example of one user "Alice" whose chairing a
fixed length conference with "Bob" and "Carol". The configuration is fixed length conference with "Bob" and "Carol". The configuration is
such that only the chair is providing a warning when there is only 10 such that only the chair is providing a warning when there is only 10
skipping to change at page 43, line 8 skipping to change at page 44, line 8
+--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ || +--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ ||
| |<-------------------------|Notification|<~~~| /\| || | |<-------------------------|Notification|<~~~| /\| ||
| Client | activeSideConfObjID,||Service | |"Ali/ce\ || | Client | activeSideConfObjID,||Service | |"Ali/ce\ ||
+--------+ confID > || | +---/---+\---+| +--------+ confID > || | +---/---+\---+|
|+------------+ / \ | |+------------+ / \ |
+--------------------------------+ +--------------------------------+
Figure 15: Whisper Figure 15: Whisper
When the conferencing system determines that there is only 10 minutes When the conferencing system determines that there is only 10 minutes
left in the conference which "Alice" is chairing, rather than left in the conference which "Alice" is chairing, rather than
creating a reservation as was done for the sidebar in Section 9.4.1, creating a reservation as was done for the sidebar in Section 8.4.1,
the conferencing system directly creates an active sidebar the conferencing system directly creates an active sidebar
conference, based on the active conference associated with "Alice". conference, based on the active conference associated with "Alice".
As discussed previously, the sidebar conference is NOT independent of As discussed previously, the sidebar conference is NOT independent of
the active conference (i.e., parent). The conferencing system also the active conference (i.e., parent). The conferencing system also
allocates a conference ID to be used for any subsequent manipulations allocates a conference ID to be used for any subsequent manipulations
of the sidebar conference. The conferencing system maintains the of the sidebar conference. The conferencing system maintains the
mapping between this conference ID and the conference object ID mapping between this conference ID and the conference object ID
associated with the active sidebar conference through the conference associated with the active sidebar conference through the conference
instance. instance.
skipping to change at page 43, line 30 skipping to change at page 44, line 30
announcement media is provided to "Alice". Depending upon the announcement media is provided to "Alice". Depending upon the
policies, Alice may be notified of her addition to the sidebar via policies, Alice may be notified of her addition to the sidebar via
the conference notification service. "Alice" continues to receive the conference notification service. "Alice" continues to receive
the media from the main conference. the media from the main conference.
Upon completion of the announcement, "Alice" is removed from the Upon completion of the announcement, "Alice" is removed from the
siebar and the sidebar conference is deleted. Depending upon the siebar and the sidebar conference is deleted. Depending upon the
policies, "Alice" may be notified of her removal from the sidebar via policies, "Alice" may be notified of her removal from the sidebar via
the conference notification service. the conference notification service.
9.7. Conference Announcements and Recordings 8.7. Conference Announcements and Recordings
Each participant can require a different type of announcement and/or Each participant can require a different type of announcement and/or
recording service from the system. For example, "Alice", the recording service from the system. For example, "Alice", the
conference chair, could be listening to a roll call while "Bob" may conference chair, could be listening to a roll call while "Bob" may
be using a telephony user interface to create a sidebar. Some be using a telephony user interface to create a sidebar. Some
announcements would apply to all the participants such as "This announcements would apply to all the participants such as "This
conference will end in 10 minutes". Recording is often required to conference will end in 10 minutes". Recording is often required to
capture the names of participants as they join a conference, capture the names of participants as they join a conference,
typically after the participant has entered an access code as typically after the participant has entered an access code as
discussed in Section 9.8. These recorded names are then announced to discussed in Section 8.8. These recorded names are then announced to
all the participants as the new participant is added to the active all the participants as the new participant is added to the active
conference. conference.
An example of a conferencing recording and announcement , along with An example of a conferencing recording and announcement , along with
collecting the DTMF, within the context of this framework, is shown collecting the DTMF, within the context of this framework, is shown
in Figure 16. in Figure 16.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +-----------+ | "Alice" | +-----------+ |
skipping to change at page 44, line 34 skipping to change at page 45, line 34
| | | +-------+ || | | | +-------+ ||
| | | |"Carol"| || | | | |"Carol"| ||
| | | +-------+----+| | | | +-------+----+|
| ~ ~ | | ~ ~ |
~~~Announcement provided to "Alice"~~~ ~~~Announcement provided to "Alice"~~~
~~~ Alice records her name ~~~ ~~~ Alice records her name ~~~
| ~ ~ +---------+--+| | ~ ~ +---------+--+|
| | | |policies | || | | | |policies | ||
| | | +---------+ || | | | +---------+ ||
| | |~~~>|Active || | | |~~~>|Active ||
| +-----------+ |Sidebar || | +-----------+ |Conference ||
| |Conference ||
| +-------+ || | +-------+ ||
| |"Bob" | || | |"Bob" | ||
"Bob " | +-------+ || "Bob " | +-------+ ||
+--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| || +--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| ||
| |<-------------------------|Notification| +-------+ || | |<-------------------------|Notification| +-------+ ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| || | Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+| +--------+ confID > || | +-------+----+|
|+------------+ | |+------------+ |
~~~Announcement provided to All Parties~~~ ~~~Announcement provided to All Parties~~~
| | | |
skipping to change at page 45, line 28 skipping to change at page 46, line 27
the conference is instigated through the Focus. the conference is instigated through the Focus.
Once the call signaling indicates that "Alice" has been successfully Once the call signaling indicates that "Alice" 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 (e.g., "Bob") are depending upon the policies, other participants (e.g., "Bob") are
notified of the addition of "Alice" to the conference via the notified of the addition of "Alice" to the conference via the
conference notification service and an announcement is provided to conference notification service and an announcement is provided to
all the participants indicating that "Alice" has joined the all the participants indicating that "Alice" has joined the
conference. conference.
9.8. Monitoring for DTMF 8.8. Monitoring for DTMF
The conferencing system also needs the capability to monitor for DTMF The conferencing system also needs the capability to monitor for DTMF
from each individual participant. This would typically be used to from each individual participant. This would typically be used to
enter the identifier and/or access code for joining a specific enter the identifier and/or access code for joining a specific
conference. conference.
An example of DTMF monitoring, within the context of the framework An example of DTMF monitoring, within the context of the framework
elements, is shown in Figure 16. elements, is shown in Figure 16.
9.9. Observing and Coaching 8.9. Observing and Coaching
The capability to observe a conference allows a participant with the The capability to observe a conference allows a participant with the
appropriate authority to listen to the conference, typically without appropriate authority to listen to the conference, typically without
being an active participant and often as a hidden participant. When being an active participant and often as a hidden participant. When
such a capability is available on a conferencing system, there is such a capability is available on a conferencing system, there is
often an announcement provided to each participant as they join the often an announcement provided to each participant as they join the
conference indicating the call may be monitored. This capability is conference indicating the call may be monitored. This capability is
useful in the context of conferences which might be experiencing useful in the context of conferences which might be experiencing
technical difficulties, thus allowing a technician to listen in to technical difficulties, thus allowing a technician to listen in to
evaluate the type of problem. evaluate the type of problem.
This capability could also apply to call center applications as it This capability could also apply to call center applications as it
provides a mechanism for a supervisor to observe how the agent is provides a mechanism for a supervisor to observe how the agent is
handling a particular call with a customer. This scenario can be handling a particular call with a customer. This scenario can be
handled by by supervisor adding themselves to the existing active handled by a supervisor adding themselves to the existing active
conference, with a listen only audio media path. Whether the agent conference, with a listen only audio media path. Whether the agent
is aware of when the supervisor joins the call should be is aware of when the supervisor joins the call should be
configurable. configurable.
Taking the supervisor capability one step further introduces a Taking the supervisor capability one step further introduces a
scenario whereby the agent can hear the supervisor, as well as the scenario whereby the agent can hear the supervisor, as well as the
customer. The customer can still only hear the agent. This scenario customer. The customer can still only hear the agent. This scenario
would involve the creation of a sidebar involving the agent and the would involve the creation of a sidebar involving the agent and the
supervisor. Both the agent and supervisor receive the audio from the supervisor. Both the agent and supervisor receive the audio from the
main conference. When the agent speaks, it is heard by the customer main conference. When the agent speaks, it is heard by the customer
skipping to change at page 48, line 44 skipping to change at page 49, line 44
policies associated with that specific conference object to perform policies associated with that specific conference object to perform
the operation. Based upon the addressing information provided for the operation. Based upon the addressing information provided for
"Bob" by "Alice", the call signaling to add "Bob" to the sidebar with "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with
the appropriate media characteristics is instigated through the the appropriate media characteristics is instigated through the
Focus. Focus.
"Bob" is notified of his addition to the sidebar via the conference "Bob" is notified of his addition to the sidebar via the conference
notification service, thus he is aware that "Alice" the supervisor is notification service, thus he is aware that "Alice" the supervisor is
available for coaching him through this call. available for coaching him through this call.
10. Relationships between SIPPING and Centralized Conferencing 9. Relationships between SIPPING and Centralized Conferencing
Frameworks Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [8] 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 [3] can be used as a signaling means in these to illustrate how SIP [2] 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 [3], the SIP conferencing system. It uses only basic SIP [2], the SIP
Conferencing for User Agents [13], and the SIPPING Conference Package Conferencing for User Agents [12], and the SIPPING Conference Package
[10] for basic SIP conferencing realization. [9] for basic SIP conferencing realization.
This centralized conferencing framework document defines a particular This centralized conferencing framework document defines a particular
centralized conferencing system and the logical entities implementing centralized conferencing system and the logical entities implementing
it. It also defines a particular data model and refers to the set of it. It also defines a particular data model and refers to the set of
protocols (beyond call signaling means) being defined by the XCON WG protocols (beyond call signaling means) being defined by the XCON WG
to be used among the logical entities for implementing advanced to be used among the logical entities for implementing advanced
conferencing features. The purpose of the XCON working group and conferencing features. The purpose of the XCON working group and
this framework is to achieve interoperability between the logical this framework is to achieve interoperability between the logical
entities from different vendors for controlling different aspects of entities from different vendors for controlling different aspects of
advanced 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 [3], the the corresponding operations. Nevertheless, the basic SIP [2], the
SIP Conferencing for User Agents [13], and the SIPPING Conference SIP Conferencing for User Agents [12], and the SIPPING Conference
Package [10] are fully compatible with both Framework documents. Package [9] are fully compatible with both Framework documents.
11. Security Considerations 10. 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 specifications specific to the issues should be addressed in the specifications specific to the
protocols described in Section 8. The protocols used for protocols described in Section 7. 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. Section 11.3 discusses an approach for the floor control protocols. Section 10.3 discusses an approach
for client authentication of a floor control server. 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 5.2 discusses the policies associated with the capabilities. Section 4.2 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, which is discussed in Section 11.2 the conference, which is discussed in Section 10.2
11.1. Authorization 10.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 signaling 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
skipping to change at page 51, line 11 skipping to change at page 52, line 11
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 it 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 10.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 select various options for privacy considerations. Users can 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 participants in the conference, that other users can not see they are participants in the conference,
or they can be "anonymous" such that users can see that another user or they can be "anonymous" such that users can see that another user
is there, but not see the identity of the user, or they can be is there, but not see the identity of the user, or they can be
"public" where other users can see their identity. If there are "public" where other users can see their identity. If there are
multiple "anonymous" users, other parties will be able to see them as multiple "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 automated or machine participants of a conference (e.g., call by automated or machine participants of a conference (e.g., call
recording) and is also used in many call center situations. recording) and is also used in many call center situations.
11.3. Floor Control Server Authentication 10.3. Floor Control Server Authentication
Clients can authenticate a floor control server using the TLS Clients can authenticate a floor control server using the TLS
certificates. Requests submitted on a successfully created certificates. Requests submitted on a successfully created
connection between the client and floor control server may connection between the client and floor control server may
additionally require digest authentication within the BFCP protocol additionally require digest authentication within the BFCP protocol
to authenticate the floor control client to the server. For this to to authenticate the floor control client to the server. For this to
take place, a shared secret needs to be exchanged between the floor take place, a shared secret needs to be exchanged between the floor
control client/server entities. This can be achieved out of band control client/server entities. This can be achieved out of band
using a mechanism such as the 'k=' SDP attribute. The shared secret using a mechanism such as the 'k=' SDP attribute. The shared secret
can also be exchanged using un-specified 'out of band' mechanisms. can also be exchanged using un-specified 'out of band' mechanisms.
When using Digest authentication of floor control client messages the When using Digest authentication of floor control client messages the
exchange of an active 'Nonce' is also required. This can be achieved exchange of an active 'Nonce' is also required. This can be achieved
using a BFCP request response interaction as defined in BFCP (A using a BFCP request response interaction as defined in BFCP (A
request is submitted without a Nonce TLV and the server generates an 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 error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value
can also be obtained 'out of band' using information provided in the can also be obtained 'out of band' using information provided in the
offer/answer exchange. As with the other SDP Floor attributes offer/answer exchange. As with the other SDP Floor attributes
referenced in this section and defined in [16], the 'nonce' attribute referenced in this section and defined in [15], the 'nonce' attribute
can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj.
12. IANA Considerations 11. IANA Considerations
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
13. Acknowledgements 12. 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 and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan
Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes for Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and
their reviews and constructive input. Gonzalo Camarillo for their reviews and constructive input.
14. Changes since last Version 13. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 07 to 08 (post-WGLC comments, reflecting IETF-68
discussions on policy):
1) added Intended Status as Informational.
2) Removed data model from Title and clarified reference to data
model in this document as "high level data model". Renamed section 5
from "Centralized Conferencing Data Model" to "Centralized
Conferencing Data".
3) Deleted Conventions section with reference to 2119.
4) Moved terminology to just after intro, before overview.
5) Changed "Common Conference Information" to "Conference
Information".
6) Removed references to policies as an integral part of data model:
updated text discussing policies in section 5 and section 5.2, with
section 7 text changed to be consistent with the updated text in
section 5 and 5.2.
7) Removal of references to individual conference-URI and Userid
documents, bringing some background back into the framework, since
those identifiers are defined in the data model.
8) Miscellaneous editorial nits.
Changes from WG 06 to 07 (WGLC comments): Changes from WG 06 to 07 (WGLC comments):
1) Section 4: Added definition for Conference User Identifier, 1) Section 4: Added definition for Conference User Identifier,
including concept of a single user having multiple identifiers. including concept of a single user having multiple identifiers.
2) Section 9: Clarified text to indicate that details of message 2) Section 9: Clarified text to indicate that details of message
flows are illustrative and exact states, etc. will be defined by the flows are illustrative and exact states, etc. will be defined by the
detailed data model, etc. detailed data model, etc.
3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster 3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster
skipping to change at page 57, line 15 skipping to change at page 58, line 45
section to show a sidebar which has some media specifically section to show a sidebar which has some media specifically
associated with the sidebar (i.e. audio), yet still use the main associated with the sidebar (i.e. audio), yet still use the main
conference for other media (visual presentation). conference for other media (visual presentation).
- Section 11: As a result of adding additional information to the - Section 11: As a result of adding additional information to the
security section, divided this section into subsections for clarity. 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) signaling, Conference Identifer, definitions of Call (control) signaling, Conference Identifier,
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 section. Identifier described in a subsection of the Conference Object
Added a diagram showing the relationship between Conference section. Added a diagram showing the relationship between Conference
Identifer/Focus and Conference Object Identifier, within the context Identifier/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
skipping to change at page 58, line 4 skipping to change at page 59, line 35
- 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 ID, - Section 2. Removed second sentence of definition of Conference 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 6). Section 5).
- New section for Identifiers ( Section 6), thus all section - New section for Identifiers ( Section 5), 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 58, line 46 skipping to change at page 60, line 29
- 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 6) - Section 6.4.1 Moved to new Identifier section ( Section 5)
- 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 14. Informative References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 4566, July 2006.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] 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:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[7] Dawson, F. and Stenerson, D., "Internet Calendaring and [6] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445, Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998. November 1998.
[8] Levin, O. and R. Even, "High-Level Requirements for Tightly [7] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005. Coupled SIP Conferencing", RFC 4245, November 2005.
[9] Rosenberg, J., "A Framework for Conferencing with the Session [8] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006. Initiation Protocol (SIP)", RFC 4353, February 2006.
[10] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006. RFC 4575, August 2006.
[11] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, [10] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376,
February 2006. February 2006.
[12] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, [11] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597,
August 2006. August 2006.
[13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) [12] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", BCP 119, Call Control - Conferencing for User Agents", BCP 119,
RFC 4579, August 2006. RFC 4579, August 2006.
[14] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006. Protocol (BFCP)", RFC 4582, November 2006.
[15] Levin, O. and G. Camarillo, "The Session Description Protocol [14] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006. (SDP) Label Attribute", RFC 4574, August 2006.
[16] Camarillo, G., "Session Description Protocol (SDP) Format for [15] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583, Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006. November 2006.
[17] Novo, O., "A Common Conference Information Data Model for [16] Novo, O., "Conference Information Data Model for Centralized
Centralized Conferencing (XCON)", Conferencing (XCON)", draft-ietf-xcon-common-data-model-05
draft-ietf-xcon-common-data-model-03 (work in progress), (work in progress), April 2007.
October 2006.
[18] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-18 (work in progress),
December 2006.
[19] Boulton, C. and M. Barnes, "A Universal Resource Identifier
(URI) for Centralized Conferencing (XCON)",
draft-boulton-xcon-uri-00 (work in progress), October 2006.
[20] Boulton, C. and M. Barnes, "A User Identifier for Centralized [17] Campbell, B., "The Message Session Relay Protocol",
Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in draft-ietf-simple-message-sessions-19 (work in progress),
progress), October 2006. February 2007.
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
Chris Boulton Chris Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com Email: cboulton@ubiquitysoftware.com
Orit Levin Orit Levin
 End of changes. 157 change blocks. 
458 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/