draft-ietf-xcon-framework-04.txt   draft-ietf-xcon-framework-05.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: December 24, 2006 C. Boulton Intended status: Informational C. Boulton
Ubiquity Software Corporation Expires: March 15, 2007 Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
June 22, 2006 September 11, 2006
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-04 draft-ietf-xcon-framework-05
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 December 24, 2006. This Internet-Draft will expire on March 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
protocols, for building advanced conferencing applications. The protocols, for building advanced conferencing applications. The
framework binds all the defined components together for the benefit framework binds all the defined components together for the benefit
of builders of conferencing systems. of builders of conferencing systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10 5. Centralized Conferencing Data Model . . . . . . . . . . . . . 9
5.1. Common Conference Information . . . . . . . . . . . . . . 11 5.1. Common Conference Information . . . . . . . . . . . . . . 11
5.2. Conference Template . . . . . . . . . . . . . . . . . . . 12 5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12 6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 13 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15
7. Conferencing System Realization . . . . . . . . . . . . . . . 15 7. Conferencing System Realization . . . . . . . . . . . . . . . 15
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25
8.3.1. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 25
8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 27
8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 27
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 29
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 31
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 32
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31 9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 34
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33 9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 36
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 9.5. Floor control using sidebars . . . . . . . . . . . . . . . 39
9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38 9.6. Whispering or Private Messages . . . . . . . . . . . . . . 41
9.6. Conference Announcements and Recordings . . . . . . . . . 39 9.7. Conference Announcements and Recordings . . . . . . . . . 43
9.7. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 39 9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 45
9.8. Observing a Conference . . . . . . . . . . . . . . . . . . 39 9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 45
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 41 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 50
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 42 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 51
11.3. Floor Control Server Authentication . . . . . . . . . . . 42 11.3. Floor Control Server Authentication . . . . . . . . . . . 51
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 14. Changes since last Version . . . . . . . . . . . . . . . . . . 52
15. Appendix A - Conference Object Identifier . . . . . . . . . . 48 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Conference Object URI Definition . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58
16. Appendix B - Conference User Identifier . . . . . . . . . . . 51 15.2. Informative References . . . . . . . . . . . . . . . . . . 58
16.1. Conference User Definition . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Intellectual Property and Copyright Statements . . . . . . . . . . 61
17.1. Normative References . . . . . . . . . . . . . . . . . . . 53
17.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 57
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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 [9] together with the SIP Call Control Conferencing for User Agents
Agents[15] documents address these types of scenarios. [14] 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
[10]. These requirements are applicable for conferencing systems [9]. 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 [12], [13], and [14]. conferencing requirements are provided in [12], and [13].
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
skipping to change at page 7, line 42 skipping to change at page 7, line 42
Active conference: The term active conference refers to a conference Active conference: The term active conference refers to a conference
cbject that has been created and activated via the allocation of cbject that has been created and activated via the allocation of
its identifiers (e.g., conference object identifier and conference its identifiers (e.g., conference object identifier and conference
identifier) and the associated focus. An active conference is identifier) and the associated focus. An active conference is
created based on either a system default conference blueprint or a created based on either a system default conference blueprint or a
specific conference reservation. specific conference reservation.
Call Signaling protocol: The call signaling protocol is used between Call Signaling protocol: The call signaling protocol is used between
a participant and a focus. In this context, the term "call" means a participant and a focus. In this context, the term "call" means
a channel or session used for media streams. a channel or session used for media streams.
Common conference information: The common conference information is Common conference information: The common conference information
the data type (i.e., the XML schema) which is used to represent includes definitions for basic conference features, such as
the core set of information for a conference object. This core conference identifiers, membership, signaling, capabilities and
information includes a common set of definitions for basic media types, applicable to a wide range of conferencing
conference features, such as conference identifiers, membership, applications. The common conference information also includes the
signaling, capabilities and media types, applicable to a wide media and application specific data for enhanced conferencing
range of conferencing applications. 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 Conference blueprint: A conference blueprint is a static conference
object within a conferencing system, which describes a typical object within a conferencing system, which describes a typical
conference setting supported by the system. A conference conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects. blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints. Each blueprint is A system may maintain multiple blueprints. Each blueprint is
comprised of the initial values and ranges for the elements in the comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the common conference object, conformant to the data schemas for the common conference
information and the specific template associated with the information.
blueprint.
Conference control protocol (CCP): A conference control protocol Conference control protocol (CCP): A conference control protocol
provides the interface for data manipulation and state retrieval provides the interface for data manipulation and state retrieval
for the centralized conferencing data, represented by the for the centralized conferencing data, represented by the
conference object. conference object.
Conference factory: A conference factory is a logical entity, that Conference factory: A conference factory is a logical entity, that
generates upon request, unique URI(s) to identify and represent a generates upon request, unique URI(s) to identify and represent a
conference focus. conference focus.
Conference identifier (ID): A conference identifier is a call Conference identifier (ID): A conference identifier is a call
signaling protocol-specific URI that identifies a conference focus signaling protocol-specific URI that identifies a conference focus
and its associated conference instance. and its associated conference instance.
Conference instance: A conference instance refers to an internal Conference instance: A conference instance refers to an internal
implementation of a specific conference, represented as a set of implementation of a specific conference, represented as a set of
logical conference objects and associated identifiers. logical conference objects and associated identifiers.
Conference object: A conference object represents a conference at a Conference object: A conference object represents a conference at a
certain stage (e.g., description upon conference creation, certain stage (e.g., description upon conference creation,
reservation, activation, etc.), which a conferencing system reservation, activation, etc.), which a conferencing system
maintains in order to describe the system capabilities and to maintains in order to describe the system capabilities and to
provide access to the services available for each object provide access to the services available for each object
independently. The conference object schema is comprised of two independently. The conference object schema is based on the
distinct sub components; the common conference information and the common conference information.
conference template(s).
Conference object identifier (ID): A conference object identifier is Conference object identifier (ID): A conference object identifier is
a URI which uniquely identifies a conference object and is used by a URI which uniquely identifies a conference object and is used by
a conference control protocol to access and modify the conference a conference control protocol to access and modify the conference
information. information.
Conference policies: Conference policies collectively refers to a set Conference policies: Conference policies collectively refers to a
of rights, permissions and limitations pertaining to operations set of rights, permissions and limitations pertaining to
being performed on a certain conference object. operations being performed on a certain conference object.
Conference reservation: A conference reservation is a conference Conference reservation: A conference reservation is a conference
object, which is created from either a system default or client object, which is created from either a system default or client
selected blueprint. selected blueprint.
Conference state: The conference state reflects the state of a Conference state: The conference state reflects the state of a
conference instance and is represented using a specific, well- conference instance and is represented using a specific, well-
defined schema. defined schema.
Conferencing system: Conferencing system refers to a conferencing Conferencing system: Conferencing system refers to a conferencing
solution based on the data model discussed in this framework solution based on the data model discussed in this framework
document and built using the protocol specifications referenced in document and built using the protocol specifications referenced in
this framework document. this framework document.
Conference template: The conference template refers to the data type
(i.e. the XML schema) which is used to represent the media or
application specific part of the conference object. This
information represents enhanced conferencing features or
capabilities, such as media mixers.
Floor: Floor refers to a set of data or resources associated with a Floor: Floor refers to a set of data or resources associated with a
conference instance, for which a conference participant, or group conference instance, for which a conference participant, or group
of participants, is granted temporary access. of participants, is granted temporary access.
Floor chair: A floor chair is a floor control protocol compliant Floor chair: A floor chair is a floor control protocol compliant
client, either a human participant or automated entity, who is client, either a human participant or automated entity, who is
authorized to manage access to one floor and can grant, deny or authorized to manage access to one floor and can grant, deny or
revoke access. The floor chair does not have to be a participant revoke access. The floor chair does not have to be a participant
in the conference instance. in the conference instance.
Focus: A focus is a logical entity that maintains the call signalling Focus: A focus is a logical entity that maintains the call
interface with each participating client and the conference object signalling interface with each participating client and the
representing the active state. As such, the focus acts as an conference object representing the active state. As such, the
endpoint for each of the supported signaling protocols and is focus acts as an endpoint for each of the supported signaling
responsible for all primary conference membership operations protocols and is responsible for all primary conference membership
(e.g., join, leave, update the conference instance) and for media operations (e.g., join, leave, update the conference instance) and
negotiation/maintenance between a conference participant and the for media negotiation/maintenance between a conference participant
focus. and the focus.
Media graph: The media graph is the logical representation of the Media graph: The media graph is the logical representation of the
flow of media for a conference. flow of media for a conference.
Media mixer: A media mixer is the logical entity with the capability Media mixer: A media mixer is the logical entity with the capability
to combine media inputs of the same type, transcode the media and to combine media inputs of the same type, transcode the media and
distribute the result(s) to a single or multiple outputs. In this distribute the result(s) to a single or multiple outputs. In this
context, the term "media" means any type of data being delivered context, the term "media" means any type of data being delivered
over the network using appropriate transport means, such as RTP/ over the network using appropriate transport means, such as RTP/
RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol
(defined in [24]). (defined in [19]).
Registered conference document : A standards track document (i.e.,
RFC) that defines and registers a conference template schema with
the appropriate organization (e.g., IANA). A registered
conference document also includes any complementary textual
information.
Role: A role provides the context for the set of conference Role: A role provides the context for the set of conference
operations that a participant can perform. A default role (e.g., operations that a participant can perform. A default role (e.g.,
standard conference participant) will always exist, providing a standard conference participant) will always exist, providing a
user with a set of basic conference operations. Based on system user with a set of basic conference operations. Based on system
specific authentication and authorization, a user may take on specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to alternate roles, such as conference moderator, allowing access to
a wider set of conference operations. a wider set of conference operations.
Sidebar: A sidebar is a separate Conference instance that only exists Sidebar: A sidebar is a separate Conference instance that only
within the context of a parent conference instance. exists within the context of a parent conference instance. The
objective of a sidebar is to be able to provide additional or
Whisper: TBD. 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 5. Centralized Conferencing Data Model
The centralized conference data model is logically represented by the The centralized conference data model is logically represented by the
conference object. A conference object is of type 'Conference object conference object. A conference object is of type 'Common conference
type', which is comprised of two distinct components: the 'Common information type', as illustrated in Figure 2. The common conference
conference information type' and the 'Conference template type', as information type is extensible for including multiple sub-types.
illustrated in Figure 2. Each of these types is extensible for
including potentially multiple sub-types.
+------------------------------------------------------+ +------------------------------------------------------+
| C o n f e r e n c e o b j e c t t y p e | | C o n f e r e n c e o b j e c t |
| | | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | Common conference information type | | | | Common 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) | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Floor information | | | | | | Floor information | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | Sidebars, Etc. | | | | | | Sidebars, Etc. | | |
| | +----------------------------------------------+ | | | | +----------------------------------------------+ | |
| | | | | | +----------------------------------------------+ | |
| +--------------------------------------------------+ | | | | Mixer algorithm, inputs, and outputs | | |
| +--------------------------------------------------+ | | | +----------------------------------------------+ | |
| | Conference template type | | | | +----------------------------------------------+ | |
| | | | | | | Floor controls | | |
| | - Mixer algorithm, inputs, and outputs | | | | +----------------------------------------------+ | |
| | - Floor controls | | | | +----------------------------------------------+ | |
| | - User Control Interface | | | | | Etc. | | |
| | - User's View | | | | +----------------------------------------------+ | |
| | - Etc. | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| |
+------------------------------------------------------+ +------------------------------------------------------+
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. Thus, each of the two components the state of ongoing conferences. Section 7 describes the usage
(i.e., the common conference information and the conference template) semantics of the conference objects.
may be optionally included in a particular conference object.
Section 7 describes the usage semantics of the conference objects.
The centralized conferencing data model defined in this framework has The centralized conferencing data model defined in this framework has
no strict separation between conference membership, conference media no strict separation between conference membership, conference media
information and the related policies. The policies are an integral information and the related policies. The policies are an integral
part of the data model and are realized by local, system level part of the data model and are realized by local, system level
boundaries associated with specific data elements, such as the boundaries associated with specific data elements, such as the
membership, and by the ranges and limitations on other data elements. membership, and by the ranges and limitations on other data elements.
Additional policy considerations for a system realization based on Additional policy considerations for a system realization based on
this data model are discussed in Section 5.3. The integration of the this data model are discussed in Section 5.2. The integration of the
data in this model meets the requirement of many conference control data in this model meets the requirement of many conference control
operations to enable synchronized access to the integral conference operations to enable synchronized access to the integral conference
policies, to the conference state as a whole, and for receiving policies, to the conference state as a whole, and for receiving
notifications about changes to either using the same interface. notifications about changes to either using the same interface.
The exact XML schema of the Conference Object, including the The exact XML schema of the conference object, including the
organization of the Common Conference Information and the Conference organization of the common conference information is detailed in a
Templates, are detailed in separate documents [ref: TBD]. separate document [18].
5.1. Common Conference Information 5.1. Common Conference Information
The common conference information section contains the core There is a core set of data in the common conference information that
information that is utilized in any conference and is independent of is utilized in any conference, independent of the specific conference
the specific conference media nature (e.g., the mixing algorithms media nature (e.g., the mixing algorithms performed, the advanced
performed, the advanced floor control applied, etc.). Typically, floor control applied, etc.). This core set of data in the common
conference information contains the definitions representing the
conference object capabilities, membership, roles, call signaling and
media status relevant to different stages of the conference life-
cycle. This core set of common conference information may be
represented using the conference-type as defined in [11]. Typically,
participants with read-only access to the conference information participants with read-only access to the conference information
would be interested in this common conference information only. would be interested in this core set of common conference information
only.
The common conference information may be represented using the In order to support more complex media manipulations and enhanced
conference-type as defined in [11]. The conference-type contains the conferencing features the common conference information contains
definitions for representation of the conference object capabilities, additional data, beyond that defined in [11]. The data model defined
membership, roles, call signaling and media status relevant to in [18] would be the basis for conferencing systems supporting
different stages of the conference life-cycle. enhanced conferencing features. The additional information defined
in [18] provides the details of the specific media mixing details,
the associated client roles and the available floor controls. This
information would allow authorized clients to manipulate the mixer's
behavior via the focus, and the resultant distribution of the media
to all or individual participants. By doing so, a client can change
its own state and/or state of other participants in the conference.
New centralized conferencing specifications can extend the basic New centralized conferencing specifications can extend the basic
conference-type and introduce additional data elements to be used conference-type as defined in [18] and introduce additional data
within the common conference information type. elements to be used within the common conference information type.
5.2. Conference Template
The concept of a conference template is introduced to separate the
complexity and the details of the "mixer" and other enhanced
conferencing features from the common conference information.
Each conference template needs to be registered with IANA. The IANA
registration needs to point to an RFC having the text description of
the feature behavior and the XML definition allowing the feature
presentation, configuration, and management. The RFCs defining these
templates are referred to as a registered conference document.
Typically, a conference template would contain the information about
the specific media mixing details, the associated client roles and
the available floor controls. This information would allow
authorized clients to manipulate the mixer's behavior via the focus,
and the resultant distribution of the media to all or individual
participants. By doing so, a client can change its own state and/or
state of other participants in the conference.
The addition of new elements or the modification of the controls
within an element of an existing template requires the definition of
a new template.
5.3. Conference policies 5.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. As such, the policies
represented by the set of rights aren't explicitly defined within the represented by the set of rights aren't explicitly defined within the
skipping to change at page 12, line 51 skipping to change at page 12, line 27
(Section 7). (Section 7).
The permissions and limits, however, are specified as an integral The permissions and limits, however, are specified as an integral
part of the conference object type, with data objects containing the part of the conference object type, with data objects containing the
allowed ranges for other data objects (e.g., maximum number of allowed ranges for other data objects (e.g., maximum number of
participants) and lists of clients allowed to perform certain participants) and lists of clients allowed to perform certain
operations on a conference object. For example, the "allowed to operations on a conference object. For example, the "allowed to
join" list of participants is consulted to decide who is allowed to join" list of participants is consulted to decide who is allowed to
join. The entries in the list can specify the identity of an join. The entries in the list can specify the identity of an
individual user (joe@example.com), a role, a domain (*@example.com), individual user (joe@example.com), a role, a domain (*@example.com),
etc. For further details, refer to the detailed data model [ref: etc. For further details, refer to the detailed data model [18].
TBD].
A more general rule mechanism, beyond the functionality provided by A more general rule mechanism, beyond the functionality provided by
the permissions and limits, is an item for future study. the permissions and limits, is an item for future study.
6. Centralized Conferencing Constructs and Identifiers 6. Centralized Conferencing Constructs and Identifiers
This section provides details of the identifiers associated with the This section provides details of the identifiers associated with the
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 6.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 [15]. use of a conference factory for SIP signaling can be found in [14].
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 [Section 8.3] or other, including proprietary, out-
of-band mechanisms. of-band mechanisms.
6.2. Conference Object 6.2. Conference Object
A Conference object provides the logical representation of a A Conference object provides the logical representation of a
conference iInstance 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 8.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.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
6.2.1. Conference Object Identifier 6.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. A conference control protocol includes the
conference object identifier in requests for directly manipulating a conference object identifier in requests for directly manipulating a
particular conference object and for obtaining its current state. particular conference object and for obtaining its current state.
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'. A full description and semantics of how the
conference object identifier is created and used is defined in conference object identifier is created and used as defined in [ref
Section 15. conf-uri: TBD].
6.3. Conference User Identifier 6.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. The conference user identifer is logically
associated with the other user identifiers assigned to the associated with the other user identifiers assigned to the
conferencing client for other protocol interfaces, such as an conferencing client for other protocol interfaces, such as an
authenticated SIP user. A full description and semantics of the authenticated SIP user. A full description and semantics of the
conference user identifier is provided in Section 16 conference user identifier is provided in [ref conf-userid: TBD].
7. Conferencing System Realization 7. 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.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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 7.1.
Adhoc and advanced conferencing examples are provided in Section 7.2 Adhoc and advanced conferencing examples are provided in Section 7.2
and Section 7.3, with the latter providing additional description of and Section 7.3, with the latter providing additional description of
the Conference Object in terms of the stages of a conference, to the Conference Object in terms of the stages of a conference, to
support scheduled and other advanced conference 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 7.4
As discussed in Section 5.3, there are conference policies implicit As discussed in Section 5.2, there are conference policies implicit
in and derivable from the data in the conference objects and there in and derivable from the data in the conference objects and there
are also policies applying to the conference objects as a whole. In are also policies applying to the conference objects as a whole. In
the examples in this section, these latter policies are shown the examples in this section, these latter policies are shown
logically associated with the conference objects, however, it is an logically associated with the conference objects, however, it is an
implementation specific mechansim as to how these policies are implementation specific mechansim as to how these policies are
managed and applied to the conference objects. managed and applied to the conference objects.
7.1. Cloning Tree 7.1. Cloning Tree
The concept defined in this section is a logical representation only, The concept defined in this section is a logical representation only,
skipping to change at page 16, line 40 skipping to change at page 16, line 40
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 common conference information format.
along with any number of template definitions. This document uses This document uses the "cloning" metaphor instead of the
the "cloning" metaphor instead of the "inheritance" metaphor because "inheritance" metaphor because it more closely fits the idea of
it more closely fits the idea of object replication, rather than a object replication, rather than a data type re-usage and extension
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 conference object URI assigned by the system, as described in [ref
Section 15 /[ref:TBD]. By default, the newly created object contains conf-uri:TBD]. By default, the newly created object contains all the
all the data existing in the parent object. The newly created object data existing in the parent object. The newly created object can
can expand the data it contains, within the schema types supported by expand the data it contains, within the schema types supported by the
the parent. It can also restrict the read/write access to its parent. It can also restrict the read/write access to its objects.
objects. However, unless the object is independent, it cannot modify However, unless the object is independent, it cannot modify the
the access restrictions 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 25, line ? skipping to change at page 20, line 12
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime. Figure 5: Conference Ad-hoc Creation and Lifetime.
7.3. Advanced Example 7.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. of the conference blueprints the system supports. Each blueprint
contains a specific combination of capabilities and limitations of
Each blueprint contains a specific combination of capabilities and the conference server in terms of supported media types (e.g., audio,
limitations of the conference server in terms of supported media video, text, or combinations of these), participant roles, maximum
types (e.g., audio, video, text, or combinations of these), number of participants of each role, availability of floor control,
participant roles, maximum number of participants of each role, controls available for participants, availability and type of
availability of floor control, controls available for participants, sidebars, the definitions and names of media streams, etc.
availability and type of sidebars, the definitions and names of media
streams, etc. As defined within this framework, a blueprint is
comprised of the common conference information and a template. A
blueprint consists of a single template, as the template approach
allows for defining combinations of media types in a single template
[ref]. Whether a blueprint needs to additionally support multiple
templates, and the associated mechanism, is for future study.
The template within the blueprint can either be included by-value or
by-reference depending upon the system implementation. In the case
of a template included by-reference within a blueprint, a client may
need to query a template that it doesn't understand and then make a
decision on compatibility. Interface hints need to be included as
per [20]. In this case, a client selects the specific blueprint to
use and retrieves the associated template from the conferencing
system itself, rather than from a centralized repository.
The selected blueprint with its default values is cloned by the The selected blueprint with its default values is cloned by the
client into a newly created conference object, referred to as a client into a newly created conference object, referred to as a
conference reservation, that specifies the resources needed from the conference reservation, that specifies the resources needed from the
system for this conference instance. At this point the conference system for this conference instance. At this point the conference
reservation becomes independent from its blueprint. The client can reservation becomes independent from its blueprint. The client can
also change the default values, within the system ranges, and add also change the default values, within the system ranges, and add
additional information, such as the list of participants and the additional information, such as the list of participants and the
conference start time, to the conference reservation. conference start time, to the conference reservation.
At this point the client can ask the conference server to create new At this point the client can ask the conference server to create new
conference reservations by attaching the conference reservation to conference reservations by attaching the conference reservation to
the request. As a result, the server can allocate the needed the request. As a result, the server can allocate the needed
resources, create the additional conference objects for the child resources, create the additional conference objects for the child
conference reservations and allocate the conference object conference reservations and allocate the conference object
identifiers for all - the original conference reservation and for
each child conference reservation.
From this point on, any authorized client is able to access and
modify each of the conference objects independently. By default,
changes to an individual child conference reservation will affect
neither the parent conference reservation, from which it was created,
nor its siblings.
On the other hand, some of the conference sub-objects, such as the
maximum number of participants and the participants list, can be
defined by the system as parent enforceable. As a result, these
objects can be modified by accessing the parent conference
reservation only. The changes to these objects can be applied
automatically to each of the child reservations, subject to local
policy.
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
Figure 6: Advanced Conference Definition, Creation, and Lifetime.
When the time comes to schedule the conference reservation, either
via the system determination that the 'start' time has been reached
or via client invocation, an active conference is cloned based on the
conference reservation. As in the adhoc example, the active
conference is independent from the parent and changes to the
conference reservation will not impact the active conference. Any
desired changes must be targeted towards the active conference. An
example of this interaction is shown in Section 9.1
7.4. Scheduling a conference
The capability to schedule conferences forms an important part of the
conferencing system solution. An individual conference reservation
typically has a specified 'start' and 'end' time, with the times
being specified relative to a single specified 'fixed' time (e.g.,
'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
considerations. In most advanced conferencing solutions it is
possible to not only schedule an individual occurrence of a
conference reservation, but also schedule a series of related
conferences (e.g., a weekly meeting that starts on Thursday at 09.00
GMT).
To be able to achieve such functionality, a conferencing system needs
to be able to appropriately schedule and maintain conference
reservations that form part of a recurring conference. The mechanism
proposed in this document makes use of the 'Internet Calendaring and
Scheduling Core Object' specification defined in RFC2445[8] in union
with the concepts introduced in Section 5 for the purpose of
achieving advanced conference scheduling capability.
Figure 7 illustrates a simplified view of a client interacting with a
conferencing system. The client is using the Conference Control
Protocol (Section 8.3) to add a new conference reservation to the
conferencing system by interfacing with the conference control
server. A CCP request contains a valid conference reservation and
reference by value to an 'iCal' object which contains scheduling
information about the conference (e.g., start time, end time).
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+
Figure 7: Resource Scheduling
A CCP request to create a new conference reservation is validated,
including the associated iCal object, and the resultant conference
reservation is created. The conference reservation is uniquely
represented within the conferencing system by a conference object
identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and
defined in [ref conf-uri:TBD]. This unique URI is returned to the
client and can be used to reference the conference reservation, if
any future manipulations are required (e.g., alter start time), using
a CCP request.
The previous example explains how a client creates a basic conference
reservation using an iCal reference in association with a conference
control protocol. Figure 7 can also be applied when explaining how a
series of conferences are scheduled in the system. The description
is almost identical with the exception that the iCal definition that
is included in a CCP request represents a series of recurring
conference instances (e.g., conference start time, end time, occur
weekly). The conferencing system will treat this request the same as
the first example. The CCP request will be validated, along with the
associated iCal object, and the conference reservation is created.
The conference reservation and its conference object ID created for
this example represent the entire series of recurring conference
instances rather than a single Conference. If the client uses the instances rather than a single Conference. If the client uses the
conference object ID provided and a CCP request to adjust the conference object ID provided and a CCP request to adjust the
conference reservation, every conference instance in the series will conference reservation, every conference instance in the series will
be altered. This includes all future occurrences, such as a be altered. This includes all future occurrences, such as a
conference scheduled as an infinite series, subject to the conference scheduled as an infinite series, subject to the
limitations of the available calendaring interface. limitations of the available calendaring interface.
A conferencing system that supports the scheduling of a series of A conferencing system that supports the scheduling of a series of
conference instances should also be able to support manipulation conference instances should also be able to support manipulation
within a specific range of the series. A good example is a within a specific range of the series. A good example is a
skipping to change at page 26, line 45 skipping to change at page 25, line 45
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 8.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 detailed in separate documents [references TBD]. protocol are provided in separate documents [references TBD].
[Editor's note: The remaining paragraphs and subsections of this
section, detailing the various protocol options should be pruned from
this document, once the WG reaches consensus on the conference
control protocol.]
8.3.1. CCCP
A Centralized Conferencing Control Protocol [19] is a semantic-
oriented protocol defined to allow participants or otherwise
authorized entities to directly manipulate an active conference
instance. CCCP is defined as a set of transactions issued over a
reliable transport protocol. A transaction consists of a Request
carrying the required information in an XML body and a corresponding
Response carrying an appropriate XML body.
CCCP requests are submitted to the CCCP server and can be prioritized
and queued, based on the CCCP client Role and the requested
primitives. CCCP requires no single lock per document, and the CCCP
server can locally implement an optimization strategy independent of
CCCP client behavior.
8.3.2. CSCP
A Conference State Change protocol [25] is a client server protocol
used to change the state of a conference object. CSCP extends the
BFCP protocol [16] with new commands. A client sends the server a
request representing a sequence of commands. Each command can set,
get, add, or delete a single field in the conference object. Changes
to the conference object are performed on a hierarchal set of
elements and unique attributes within those elements. A series of
changes can be pipelined in a single BFCP message. The server
executes each action in series. If one of them fails, the server
returns an error for the action that failed and does not execute any
of the actions after that. Each individual action is atomic but the
pipelined series is not.
The item to which a command applies is specified by a unique ID and,
where appropriate, attribute name. The ID is an unsigned 32 bit
integer called the Element ID. The server discovery of the Element
ID is outside of CSCP. Typically this is done by using the
conference notification service per Section 8.2. Each field in the
data received in the notification contains a unique field ID
attribute that can be used in BFCP requests.
8.3.3. SOAP
The SOAP protocol is fundamentally an XML messaging scheme, capable
of supporting remote procedure calls. SOAP defines a simple message
format composed of a "header" and a "body" contained within an
"envelope". The "header" contains meta-information relating to the
message, and can be used to indicate such things as store-and-forward
behaviour or transactional characteristics. In addition, SOAP
encoding is optimized for ease of automated deserialization of the
message body.
SOAP [17] and [18] is proposed as the mechanism for object content
manipulation and state retrieval for the centralized conferencing
data. In general, SOAP is a good fit for Conference Control,
essentially because of its remote procedure call characteristics and
its inherently synchronous and client-driven nature.
8.4. Floor Control 8.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 [16]. [Editor's in the Binary Floor Control Protocol specification [15].
note: Evaluation of an alternative proposal, as a stand alone draft,
for using Templates as the means for correlating Floor Control
identifiers has been proposed. If/when this work is done, it needs
to be introduced and referenced here].
Within this framework, a client supporting floor control needs to 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[5] exchange on the negotiation using the SDP[2] offer/answer[5] exchange on the
signaling interface with the focus. Section 11.3 provides a signaling interface with the focus. Section 11.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 [16] for authentication details), a specific floor control (see [15] 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 6.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
[23] this identifier maps to the 'confid' SDP attribute. [17] 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 6.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 identifier is contained in the 'userid' SDP attribute, as conference identifier is contained in the 'userid' SDP attribute, as
defined in [23] defined in [17]
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 identifer.
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 [23] e.g., a=floorid:1 m-stream:10 . Each attribute, as defined in [17] 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 [22]. the SDP 'Label' attribute as defined in [16].
9. Conferencing Scenario Realizations 9. 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 [14], are realized using this which have been described in [13], 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 details shown in the messages are for illustrative purposes only The details shown in the messages are for illustrative purposes only
and don't reflect the structure of the conference control protocol and don't reflect the structure of the conference control protocol
messages, but rather provide a high level primitive view of the messages, but rather provide a high level primitive view of the
necessary operations and general logic flow, including the data necessary operations and general logic flow, including the data
manipulation aspects. It should be noted that not all entities manipulation aspects. 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 9.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 [15]. For a conferencing client to have more flexibility detailed in [14]. 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 32, line 10 skipping to change at page 30, line 8
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" [15] shows how SIP For example, "Conferencing for SIP User Agents" [14] 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 33, line 28 skipping to change at page 31, line 26
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 9.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
operations 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
various resources, such as media mixers, which may indirectly affect various resources, such as media mixers, which may indirectly affect
the state of any of the conference participants. the state of any of the conference participants.
Figure 10 provides an example of one client "Alice" impacting the Figure 10 provides an example of one client "Alice" impacting the
media state of another client "Bob". This example assumes an media state of another client "Bob". This example assumes an
skipping to change at page 34, line 31 skipping to change at page 32, line 31
| Client | NOTIFY <"Bob"=mute">|+------------+ | | Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
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 Conference Template of the Conference is marked as "recvonly" and the the conference object is updated to
Object (if included) is updated to reflect that "Bob's" media is not reflect that "Bob's" media is not to be "mixed" with the conference
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 9.4. Sidebar Manipulations
A sidebar can be viewed as a separate Conference instance that only A sidebar can be viewed as a separate Conference instance that only
exists within the context of a parent conference instance. Although exists within the context of a parent conference instance. Although
viewed as an independent conference instance, it can not exist viewed as an independent conference instance, it can not exist
without a parent. A sidebar is created using the same mechanisms without a parent. A sidebar is created using the same mechanisms
skipping to change at page 35, line 48 skipping to change at page 34, line 5
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 7.1. A
Sidebar conference object contains a subset of members from the Sidebar conference object contains a subset of members from the
original Conference object. Properties of the sidebar conference original Conference object. Properties of the sidebar conference
object can be manipulated by a Conference Control Protocol object can be manipulated by a Conference Control Protocol
(Section 8.3) using the unique conference object identifier for the (Section 8.3) using the unique conference object identifier for the
sidebar. It is also possible for the top level conference object to sidebar. It is also possible for the top level conference object to
enforce policy on the sidebar object (similar to parent enforceable enforce policy on the sidebar object (similar to parent enforceable
as discussed in Section 7.1). as discussed in Section 7.1).
9.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. "Alice" initiates the video associated with the main conference. Alternatively, the audio
sidebar by sending a request to the conferencing system to create a from the main conference could be maintained at a reduced volume.
conference reservation based upon the active conference object. "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference reservation based upon the
active conference object. "Alice" and "Bob" would remain on the
roster of the main conference such that the other participants would
be unaware of the sidebar.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
| |Conference || | |Conference ||
"Alice" | +-------+ || "Alice" | +-------+ ||
+--------+ | |"Alice"| || +--------+ | |"Alice"| ||
skipping to change at page 38, line 23 skipping to change at page 36, line 23
protocol requests from any of the members of the conference. The protocol requests from any of the members of the conference. The
conferencing system maintains the mapping between this conference ID conferencing system maintains the mapping between this conference ID
and the conference object ID associated with the sidebar reservation and the conference object ID associated with the sidebar reservation
through the conference instance. through the conference instance.
Upon receipt of the conference control protocol response to reserve Upon receipt of the conference control protocol response to reserve
the conference, "Alice" can now create an active conference using the conference, "Alice" can now create an active conference using
that reservation or create additional reservations based upon the that reservation or create additional reservations based upon the
existing reservations. In this example, "Alice" wants only "Bob" to existing reservations. In this example, "Alice" wants only "Bob" to
be involved in the sidebar, thus she manipulates the membership. be involved in the sidebar, thus she manipulates the membership.
Alice also only wants the video from the original conference and "Alice" also only wants the video from the original conference and
wants the audio to be restricted to the participants in the sidebar. wants the audio to be restricted to the participants in the sidebar.
Alice sends a conference control protocol request to update the Alternatively, "Alice" could manipulate the media values to recieve
information in the reservation and to create an active conference. the audio from the main conference at a reduced volume. "Alice"
sends a conference control protocol request to update the information
in the reservation and to create an active conference.
Upon receipt of the conference control protocol request to update the Upon receipt of the conference control protocol request to update the
reservation and to create an active conference for the sidebar, as reservation and to create an active conference for the sidebar, as
identified by the conference object ID, the conferencing system identified by the conference object ID, the conferencing system
ensures that "Alice" has the appropriate authority based on the ensures that "Alice" has the appropriate authority based on the
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 whether members like updated information in the reservation, ensuring whether members like
"Bob" are already a user of this conferencing system or whether he is "Bob" are already a user of this conferencing system or whether he is
a new user. If "Bob" is a new user for this conferencing system, a a new user. If "Bob" is a new user for this conferencing system, a
conference user identifier is created for Bob. Based upon the conference user identifier is created for Bob. Based upon the
addressing information provided for "Bob" by "Alice", the call addressing information provided for "Bob" by "Alice", the call
signaling to add "Bob" to the conference is instigated through the signaling to add "Bob" to the conference is instigated through the
Focus. Focus.
Depending upon the policies, the participants in the sidebar (i.e., Depending upon the policies, the participants in the sidebar (i.e.,
"Bob") may be notified of his addition to the sidebar via the "Bob") may be notified of his addition to the sidebar via the
conference notification service. conference notification service.
9.5. Whispering or Private Messages 9.4.2. External Sidebar
Figure 13 provides an example of one client "Alice" involved in an
active conference with "Bob", "Carol", "David" and "Ethel". "Alice"
gets an important text message via a whisper from "Bob" that a
critical customer needs to talk to "Alice", "Bob" and "Ethel".
"Alice" creates a sidebar to have a side discussion with the customer
"Frank" including the participants in the current conference with the
exception of "Carol" and "David", who remain in the active
conference. "Alice" initiates the sidebar by sending a request to
the conferencing system to create a conference reservation based upon
the active conference object. "Alice", "Bob" and "Ethel" would
remain on the roster of the main conference in a hold state.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+ ||
| |CCP Response | | | |"David"| ||
+--------+ <sidebarResvConfObjID, | | | +-------+ ||
confID> | | | |"Ethel"| ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=sidebar, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | +-------+ ||
+--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | ||
| Client |<-------------------------|Notification|<~~~+-------+ ||
+--------+ "Ethel"=added, ||Service | |"Ethel"| ||
"Fred"=added,> || | +-------+ ||
"Ethel" +---| | |"Fred" | ||
+--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+|
| Client | <--------------------+ +--------------------------------+
+--------+ "Ethel"=added,"Fred"=added,>
Figure 13: Client Creation of an External Sidebar
Upon receipt of the Conference Control Protocol request to "reserve"
a new sidebar conference, based upon the active conference received
in the request, the conferencing system uses the received active
conference to clone a conference reservation for the sidebar. As
discussed previously, the sidebar reservation is NOT independent of
the active conference (i.e., parent). The conferencing system also
reserves or allocates a conference ID to be used for any subsequent
protocol requests from any of the members of the conference. The
conferencing system maintains the mapping between this conference ID
and the conference object ID associated with the sidebar reservation
through the conference instance.
Upon receipt of the conference control protocol response to reserve
the conference, "Alice" can now create an active conference using
that reservation or create additional reservations based upon the
existing reservations. In this example, "Alice" wants only "Bob" and
"Ethel", along with the new participant "Fred" to be involved in the
sidebar, thus she manipulates the membership. "Alice" sets the media
such that the participants in the sidebar don't receive any media
from the main conference. "Alice" sends a conference control
protocol request to update the information in the reservation and to
create an active conference.
Upon receipt of the conference control protocol request to update the
reservation and to create an active conference for the sidebar, as
identified by the conference object ID, the conferencing system
ensures that "Alice" has the appropriate authority based on the
policies associated with that specific conference object to perform
the operation. The conferencing system must also validate the
updated information in the reservation, ensuring whether members like
"Fred" are already a user of this conferencing system or whether he
is a new user. Since "Fred" is a new user for this conferencing
system, a conference user identifier is created for "Fred". Based
upon the addressing information provided for "Fred" by "Alice", the
call signaling to add "Fred" to the conference is instigated through
the Focus.
Depending upon the policies, the participants in the sidebar (i.e.,
"Bob" and "Ethel") may be notified of his addition to the sidebar via
the conference notification service.
9.5. Floor control using sidebars
Floor control with sidebars can be used to realize conferencing
scenario such as an analyst briefing. In this scenario, the
conference call has a panel of speakers who are allowed to talk in
the main conference. The other participants are the analysts, who
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
moderator and ask their question. The moderator can also whisper to
each analyst what their status/position in the floor control queue,
similar to the example in Figure 15
Figure 14 provides an example of the configuration involved for this
type of conference. As in the previous sidebar examples, there is
the main conference along with a sidebar. "Alice" and "Bob" are the
main participants in the conference, with "A1", "A2" and "A3"
representing the analysts. The sidebar remains active throughout the
conference, with the moderator, "Carol", serving as the chair. As
discussed previously, the sidebar conference is NOT independent of
the active conference (i.e., parent). The analysts are provided the
conference object ID associated with the active sidebar when they
join the main conference. The conferencing system also allocates a
conference ID to be used for any subsequent manipulations of the
sidebar conference. The conferencing system maintains the mapping
between this conference ID and the conference object ID associated
with the active sidebar conference through the conference instance.
The analysts are permanently muted while in the main conference. The
analysts are moved to the sidebar when they wish to speak. Only one
analyst is given the floor at a given time. All participants in the
sidebar conference receive audio from the main conference.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"A1" | ||
| |Server | +-------+ ||
| | | |"A2" | ||
| | | +-------+ ||
| | | |"A3" | ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | |Active ||
| +-----------+ |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Request <"A1", |+------------+ +-------+ ||
| |------------------------->|Floor Ctrl | |"Carol"| ||
|Client | activeSideConfObjID,||Server |~~~>| | ||
+--------+ confID > || | +-------+----+|
|+------------+ | |
| V |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Granted <"A1", |+------------+ +-------+ ||
| |<-------------------------|Floor Ctrl |<~~~|"Carol"| ||
| Client | activeSideConfObjID,||Server | +-------+ ||
+--------+ confID > || | |"A1" | ||
|+------------+ +-------+----+|
+--------------------------------+
Figure 14: Floor Control with sidebars
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
control server notifies the moderator, "Alice" of the active sidebar
conference, whose serving as the floor chair. Note, that this
signaling flow is not shown in the diagram. Since no other analysts
have yet requested the floor, "Alice" indicates to the floor control
server that "A1" may be granted the floor.
9.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, but two participants, similar to the example in section Section 9.4.1,
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 such as when a announcement server injects a message situations involving one time media targetted to specific user(s).
targetted to specific user(s). The details of this mechanism within An example of a whisper would be an announcement injected only to the
the context of the framework are TBD. conference chair or to a new participant joining a conference.
9.6. Conference Announcements and Recordings Figure 15 provides an example of one user "Alice" whose chairing a
fixed length conference with "Bob" and "Carol". The configuration is
such that only the chair is providing a warning when there is only 10
minutes left in the conference. At that time, "Alice" is moved into
a sidebar created by the conferencing system and only "Alice"
receives the announcement.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"Carol"| ||
| |Server | +-------+----+|
| | | | |
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ |Sidebar ||
"Alice" | |Conference ||
+--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification| | | ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to "Alice"~~~
| +-----------+ |
| |Conference | |
| |Control | |
| |Server | |
| | | |
| | | \---------+--/|
| | | |\ /||
| | |~~~>+ \ / ||
| | | | \ / ||
| +-----------+ |Sid\bar / ||
"Alice" | |Conf\re/ce ||
+--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ ||
| |<-------------------------|Notification|<~~~| /\| ||
| Client | activeSideConfObjID,||Service | |"Ali/ce\ ||
+--------+ confID > || | +---/---+\---+|
|+------------+ / \ |
+--------------------------------+
Figure 15: Whisper
When the conferencing system determines that there is only 10 minutes
left in the conference which "Alice" is chairing, rather than
creating a reservation as was done for the sidebar in Section 9.4.1,
the conferencing system directly creates an active sidebar
conference, based on the active conference associated with "Alice".
As discussed previously, the sidebar conference is NOT independent of
the active conference (i.e., parent). The conferencing system also
allocates a conference ID to be used for any subsequent manipulations
of the sidebar conference. The conferencing system maintains the
mapping between this conference ID and the conference object ID
associated with the active sidebar conference through the conference
instance.
Immediately upon creation of the active sidebar conference, the
announcement media is provided to "Alice". Depending upon the
policies, Alice may be notified of her addition to the sidebar via
the conference notification service. "Alice" continues to receive
the media from the main conference.
Upon completion of the announcement, "Alice" is removed from the
siebar and the sidebar conference is deleted. Depending upon the
policies, "Alice" may be notified of her removal from the sidebar via
the conference notification service.
9.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.7. These recorded names are then announced to discussed in Section 9.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 conference recording and announcements, along with An example of a conferencing recording and announcement , along with
monitoring for DTMF, within the context of this framework, is shown collecting the DTMF, within the context of this framework, is shown
in figure [TBD]. in Figure 16.
9.7. Monitoring for DTMF +--------------------------------+
| Conferencing System |
"Alice" | +-----------+ |
+--------+ | |Conference | |
| |CCP Request < | |Control | |
| Client |--------------------------->| |Server | |
| |Bob's Conference ID, | | | |
+--------+ Join > | | | |
| | | |
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Digits collected from "Alice"~~~
| ~ ~ +---------+--+|
| | |~~~>|policies | ||
| | | +---------+ ||
| | | |Active ||
| | | |Conference ||
| | | +-------+ ||
| | | |"Bob" | ||
| | | +-------+ ||
| | | |"Carol"| ||
| | | +-------+----+|
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Alice records her name ~~~
| ~ ~ +---------+--+|
| | | |policies | ||
| | | +---------+ ||
| | |~~~>|Active ||
| +-----------+ |Sidebar ||
| |Conference ||
| +-------+ ||
| |"Bob" | ||
"Bob " | +-------+ ||
+--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| ||
| |<-------------------------|Notification| +-------+ ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to All Parties~~~
| |
+--------------------------------+
Figure 16: Recording and Announcements
Upon receipt of the Conference Control Protocol request from "Alice"
to join "Bob's" conference, the conferencing system maps the
identifier received in the request to the conference object
representing "Bob's" active conference. The conferencing system
determines that a password is required for this specific conference,
thus an announcement asking "Alice" to enter the password is provided
to "Alice". Once "Alice" enters the password, it is validated
against the policies associated with "Bob's" active conference. The
conferencing system then connects to a server which prompts and
records "Alice's" name. The conferencing system must also determine
whether "Alice" is already a user of this conferencing system or
whether she is a new user.
If "Alice" is a new user for this conferencing system, a conference
user identifier is created for "Alice". Based upon the addressing
information provided by "Alice", the call signaling to add "Alice" to
the conference is instigated through the Focus.
Once the call signaling indicates that "Alice" has been successfully
added to the specific conference, per updates to the state, and
depending upon the policies, other participants (e.g., "Bob") are
notified of the addition of "Alice" to the conference via the
conference notification service and an announcement is provided to
all the participants indicating that "Alice" has joined the
conference.
9.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 this framework, An example of DTMF monitoring, within the context of the framework
is shown in figure [TBD] in the previous section. elements, is shown in Figure 16.
9.8. Observing a Conference 9.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. This capability could also apply to evaluate the type of problem.
call center applications as it provides a mechanism for a supervisor
to observe how the agent is handling a particular call. Whether the This capability could also apply to call center applications as it
agent is aware of when the supervisor joins the call should be provides a mechanism for a supervisor to observe how the agent is
handling a particular call with a customer. This scenario can be
handled by by supervisor adding themselves to the existing active
conference, with a listen only audio media path. Whether the agent
is aware of when the supervisor joins the call should be
configurable. configurable.
An example of oberving a conference is shown in figure [TBD]. Taking the supervisor capability one step further introduces a
scenario whereby the agent can hear the supervisor, as well as the
customer. The customer can still only hear the agent. This scenario
would involve the creation of a sidebar involving the agent and the
supervisor. Both the agent and supervisor receive the audio from the
main conference. When the agent speaks, it is heard by the customer
in the main conference. When the supervisor speaks, it is heard only
by the agent in the sidebar conference.
An example of observing and coachin is shown in figure Figure 17. In
this example, call center agent "Bob" is involved in a conference
with customer "Carol". Since "Bob" is a new agent and "Alice" sees
that he has been on the call with "Carol" for longer than normal, she
decides to observe the call and coach "Bob" as necessary.
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | | ||
+--------+ | | ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID> | | | +------------+|
| | | | | | |
| | | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | "chair"="Alice" ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
Figure 17: Supervisor Creating a Sidebar for Observing/Coaching
Upon receipt of the Conference Control Protocol request from "Alice"
to "reserve" a new sidebar conference, based upon the active
conference received in the request, the conferencing system uses the
received active conference to clone a conference reservation for the
sidebar. The conferencing system also reserves or allocates a
conference ID to be used for any subsequent protocol requests from
any of the members of the conference. The conferencing system
maintains the mapping between this conference ID and the conference
object ID associated with the sidebar reservation through the
conference instance.
Upon receipt of the conference control protocol response to reserve
the conference, "Alice" can now create an active conference using
that reservation or create additional reservations based upon the
existing reservations. In this example, "Alice" wants only "Bob" to
be involved in the sidebar, thus she manipulates the membership.
"Alice" also wants the audio to be received by herself and "Bob" from
the original conference, but wants any outgoing audio from herself to
be restricted to the participants in the sidebar, whereas "Bob's"
outgoing audio should go to the main conference, so that both "Alice"
and the customer "Carol" hear the same audio from "Bob". "Alice"
sends a conference control protocol request to update the information
in the reservation and to create an active conference.
Upon receipt of the conference control protocol request to update the
reservation and to create an active conference for the sidebar, as
identified by the conference object ID, the conferencing system
ensures that "Alice" has the appropriate authority based on the
policies associated with that specific conference object to perform
the operation. Based upon the addressing information provided for
"Bob" by "Alice", the call signaling to add "Bob" to the sidebar with
the appropriate media characteristics is instigated through the
Focus.
"Bob" is notified of his addition to the sidebar via the conference
notification service, thus he is aware that "Alice" the supervisor is
available for coaching him through this call.
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIPPING Conferencing Framework are being used
to illustrate how SIP [4] can be used as a signaling means in these to illustrate how SIP [4] can be used as a signaling means in these
conferencing systems. SIPPING Conferencing Framework does not define conferencing systems. SIPPING Conferencing Framework does not define
new conference control protocols to be used by the general new conference control protocols to be used by the general
conferencing system. It uses only basic SIP [4], the SIP conferencing system. It uses only basic SIP [4], the SIP
Conferencing for User Agents [15], and the SIPPING Conference Package Conferencing for User Agents [14], and the SIPPING Conference Package
[9] 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 [4], the the corresponding operations. Nevertheless, the basic SIP [4], the
SIP Conferencing for User Agents [15], and the SIPPING Conference SIP Conferencing for User Agents [14], and the SIPPING Conference
Package [9] are fully compatible with both Framework documents. Package [9] are fully compatible with both Framework documents.
11. Security Considerations 11. Security Considerations
There are a wide variety of potential attacks related to There are a wide variety of potential attacks related to
conferencing, due to the natural involvement of multiple endpoints conferencing, due to the natural involvement of multiple endpoints
and the many, often user-invoked, capabilities provided by the and the many, often user-invoked, capabilities provided by the
conferencing system. Examples of attacks include the following: an conferencing system. Examples of attacks include the following: an
endpoint attempting to listen to conferences in which it is not endpoint attempting to listen to conferences in which it is not
authorized to participate, an endpoint attempting to disconnect or authorized to participate, an endpoint attempting to disconnect or
skipping to change at page 41, line 17 skipping to change at page 50, line 7
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 8. The protocols used for
manipulation and retrieval of confidential information MUST support a manipulation and retrieval of confidential information MUST support a
confidentiality and integrity mechanism. Similar requirements apply confidentiality and integrity mechanism. Similar requirements apply
for the floor control protocols. Section 11.3 discusses an approach for the floor control protocols. Section 11.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.3 discusses the policies associated with the capabilities. Section 5.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 11.2
11.1. Authorization 11.1. Authorization
Many policy authorization decisions are based on the identity of the Many policy authorization decisions are based on the identity of the
user or the role that a user may have. There are several ways that a user or the role that a user may have. There are several ways that a
user might authenticate its identity to the system. The conferencing user might authenticate its identity to the system. The conferencing
skipping to change at page 43, line 4 skipping to change at page 51, line 42
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 [23], the 'nonce' attribute referenced in this section and defined in [17], 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.
[Editor's Note: May need more specifics on fetching from the
conference object the credentials required for BFCP. This includes
the conference id, user id, and password.]
12. IANA Considerations 12. IANA Considerations
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
13. Acknowledgements 13. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal 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 and Sean Olson for Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson and Rohan
their reviews and constructive input. Mahy for their reviews and constructive input.
14. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
Changes from WG 04 to 05:
1) Removed all references to "Conference Template":
Section 4:
- Updated "Common Conference Information" definition, merging details
from "Conference Template" definition, which was removed.
- In definition of "conference blueprint"
- In definition of "conference object"
- Removed definition of "Registered conference document"
Section 5:
- 1st paragraph. Reworded.
- Figure2: added "boxes" for all the data listed in the Conference
Template type in the diagram.
- Paragraph following Figure 2. Reworded.
Section 5.1/5.2: Merged 5.2 into section 5.1 and reworded
appropriately.
Section 7.1: Second paragraph, 3rd sentence.
Section 7.3:
- Second paragraph, 2nd and 3rd sentences. Deleted. Remaining
sentence merged with 1st paragraph
- Third paragraph. Deleted.
Section 8.4, 1st paragraph. Removed Editor's note containing
reference to alternative proposal for floor control using templates.
Section 9.3, 1st paragraph after Figure 10.
2) Section 4:
- Sidebar. Clarified definition.
- Whisper. Added definition.
3) Section 5, last paragraph, added reference to
draft-ietf-xcon-common-data-model.
4) Section 8.3. Deleted Editor's note. Deleted subsections
containing details of separate protocol proposals.
5) Section 9.4. Sidebar. Added another example - an external
sidebar (i.e. one involving a participant not in the main conference
and with no media from the main conference).
6) New section 9.5. Floor control with sidebars.
7) Section 9.5 (new 9.6) Whisper. Added more detail and an example
diagram.
8) Section 9.8. (new 9.9) Observing a Conference. Added more details
to example, including concept of coaching and added a corresponding
diagram.
9) Removed Appendix A and Appendix B and updated references to these.
The content will be in separate documents (references TBD).
10) Updated references. Changed drafts to RFCs as appropriate and
removed unused references.
Changes from WG 03 to 04: Changes from WG 03 to 04:
- Editorial nits and clarifications. - Editorial nits and clarifications.
- Section 4. Template: Removed reference to "user interface - Section 4. Template: Removed reference to "user interface
abstractions". abstractions".
- Section 5.2. Conference Template: deleted references to user - Section 5.2. Conference Template: deleted references to user
interface abstraction (1st paragraph, last phrase and 4th paragraph). interface abstraction (1st paragraph, last phrase and 4th paragraph).
skipping to change at page 48, line 7 skipping to change at page 58, line 19
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 6)
- Section 7.1 - moved example to 7.2. Included a new (more - Section 7.1 - moved example to 7.2. Included a new (more
appropriate example) in 7.1, although this may be too basic. appropriate example) in 7.1, although this may be too basic.
- Section 7.3 - added some proposed text for Sidebars. - Section 7.3 - added some proposed text for Sidebars.
15. Appendix A - Conference Object Identifier 15. References
[Editors Note: This appendix will be incorporated in a separate
specification in the next release of this document and will include
all relevant detail.]
The conference object URI can be viewed as a key to accessing a
specific conference object. It is used by the Conference Control
Protocol as described in Section 8.3 to access, manipulate and delete
a conference object associated with a specific conference instance.
A conference object identifier is provided to the Conference Control
Client to enable such functions to be carried out. This can either
be returned through the Conference Control Protocol while creating a
conference object, be provided by the conference notification service
or through out-of-band mechanisms (e.g. E-Mail).
[Editors Note: Previous section to be expanded and more detail
included. It also needs to link up with other drafts and explicitly
reference.]
A centralized conferencing system, as defined in the Conference
Framework [ref] has potential to expose a range of interfaces and
protocols. It is also possible that future centralized conferencing
enhancements might place requirements to provide further additional
protocols and interfaces. A conference object can consist and be
associated with many identifiers that are in some way related to a
conference object. Good examples include the Binary Floor Control
Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each
use unique identifiers to represent a protocol instance associated
with a conference object.
A conferencing system may maintain a relationship between the
conference object URIs and the identifiers associated with each of
the complementary centralized conferencing protocols (e.g., CSP,
BFCP, etc.). To facilitate the maintenance of these relationships,
the conference object URI acts as a top level identifier within the
conferencing system for the purpose of identifying the interfaces for
these other protocols. This implicit binding provides a structured
mapping of the various protocols with the associated conference
object identifier. Figure 13 illustrates the relationship between
the identifiers used for the protocols within this framework and the
general conference object identifier.
+--------------+
| Conference |
| Object |
| Identifier |
+------+-------+
|
|
|
+-----------------+---------------+
| |
+-------+---------+ +-------+-------+
|CSP Conference ID| | BFCP 'confid' |
+-----------------+ +---------------+
Figure 13: Conference Object Mapping.
In Figure 13, the conference object identifier acts as the top level
key in the identification process. The call signaling protocols have
an associated conference ID representation in the form of URIs. The
binary floor control protocol, as defined in [23], defines the
'conf-id' identifier which represents a conference instance within
floor control. When created within the conferencing system, the
'conf-id' has a 1:1 mapping to the unique conference object
Identifier. Operations associated with the Conference Control
Protocols are directly associated with the conference object, thus
the primary identifier associated with these protocols is the
conference object identifier. The mappings between additional
protocols/interface is not strictly 1:1 and does allow for multiple
occurrences. For example, multiple call signaling protocols will
each have a representation that is implicitly linked to the top level
conference object identifier, for example, H323 and SIP URIs that
represent a conference instance. It should be noted that a
conferencing system is free to structure such relationships as
required and this information is just included as a guideline that
can be used.
The following example illustrates the representation and
relationships that might occur in a typical conference instance. The
table in Figure 14 lists a typical conference instance and related
properties.
+----------------------+------------------------+----------------------+
| Conf Obj URI | CSP URI | BFCP Conf-ID |
+----------------------+------------------------+----------------------+
| confid:Ji092i | sip:Ji092i@example.com | Ji092i |
| | tel:+44(0)2920930033 | |
| | h323:Ji092i@example.com| |
+----------------------+------------------------+----------------------+
Figure 14: Conference Table Representation
The information from Figure 14 can then be applied to the
representation introduced in Figure 13. This results in Figure 15.
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
| xcon:Ji092i |
+------+-------+
|
|
|
+-----------------+---------------+
| |
+-----------+-----------+ +-------+-------+
| CSP Conference IDs | | BFCP 'confid' |
+-----------------------+ +---------------+
|h323:Ji092i@example.com| | Ji092i |
|tel:+44(0)2920930033 | +-------+-------+
|sip:Ji092i@example.com | |
+-----------------------+ +-------|-------+
| BFCP 'floorid |
+---------------+
| UEK78d |
| 09cnJk |
+---------------+
Figure 15: Conference Tree Representation
Further elements can be added to the tree representation in Figure 15
to enable a complete representation of a conference instance within a
conferencing system.
This style of association can be applied to any supplementary
protocols or conferencing mechanisms that are applied to the
centralized conferencing model defined in this document as long as a
unique reference per conference instance is available that can be
mapped to a conference object.
15.1. Conference Object URI Definition
[Editors Note: When the appendix split from the Framework document,
full URI definition will be included.
16. Appendix B - Conference User Identifier
[Editors Note: This appendix will be incorporated in a separate
specification in the next release of this document and will include
all relevant detail.]
Each user within a conferencing system is allocated a unique
conference user identifier. The user identifier is used in
association with the conference object identifier defined in
Section 15, and by the conference control protocol to uniquely
identify a user within the scope of conferencing system. The
conference control protocol uses the user identifier to uniquely
determine who is issuing commands. Appropriate policies can then be
applied to the requested command.
As with the conference object identifier, a number of supplementary
user identifiers defined in other protocols are used within a
conference instance. Such user identifiers can be associated with
this conference user identifier and enable the conferencing system to
correlate and map these multiple authenticated user identities to the
single user identifier.
Figure 16 illustrates an example using the conference user identifier
in association with the user identity defined for BFCP and SIP Digest
user identity as defined in RFC3261[4], which would be used when SIP
is the call signaling protocol. It should be noted that a
conferencing system is free to structure such relationships as
required and this information is just included as a guideline that
can be used.
+---------------+
| Conference |
| User |
| Identifier |
+-------+-------+
|
|
|
+---------------+---------------+
| |
+-------+-------+ +-------+-------+
| BFCP | | SIP Digest |
| 'UserID' | | Username |
+---------------+ +-------+-------+
Figure 16: Conference User Identifier
Within a conferencing system, a user is identified by a single
conference user identifier. Any additional conferencing mechanisms
that contain a protocol specific user ID can be associated with the
conference user identifier, as illustrated in Figure 16. This
mechanism allows conferencing systems to manage and relate system
wide user identities in relation to specific conference objects and
helps in the enforcement of system wide policies.
The following example illustrates the representation and
relationships that might occur in a typical conference instance. The
table in Figure 17 lists a typical representation of user identifier
hierarchy and associations.
+----------------+----------------+---------------+----------------+
| Conf User ID | BFCP User ID | SIP User ID | H323 User ID |
+----------------+----------------+---------------+----------------+
| John | HK37ihdaj | 123674 | 928373 |
+----------------+----------------+---------------+----------------+
Figure 17: User Identitier Representation
The information from Figure 17 can then be applied to the
representation introduced in Figure 16. This results in Figure 18.
+--------------+
| Conference |
| User |
| Identifier |
+--------------+
| John |
+------+-------+
|
|
|
+---------------------+---------------------+
| | |
+-------+--------+ +-------+-------+ +--------+-------+
| BFCP User ID | | SIP User ID | | H323 User ID |
+----------------+ +---------------+ +----------------+
| HK37ihdaj | | 123674 | | 928373 |
+----------------+ +-------+-------+ +----------------+
Figure 18: User ID Tree Representation
Further elements can be added to the tree representation in Figure 15
to enable a complete representation of a conference instance within a
conferencing system.
16.1. Conference User Definition
[Editors Note: When the appendix is split from the Framework
document, full definition will be included.
17. References
17.1. Normative References 15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References 15.2. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
skipping to change at page 54, line 24 skipping to change at page 59, line 6
[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [7] 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.
[8] Dawson, F. and Stenerson, D., "Internet Calendaring and [8] 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.
[9] Rosenberg, J., "A Framework for Conferencing with the Session [9] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol (SIP)", RFC 4353, February 2006.
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
[10] Levin, O. and R. Even, "High Level Requirements for Tightly [10] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", Coupled SIP Conferencing", RFC 4245, November 2005.
draft-ietf-sipping-conferencing-requirements-01 (work in
progress), October 2004.
[11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress), draft-ietf-sipping-conference-package-12 (work in progress),
July 2005. July 2005.
[12] Schulzrinne, H., "Requirements for Floor Control Protocol", [12] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
draft-ietf-xcon-floor-control-req-03 (work in progress), "Requirements for Floor Control Protocols", RFC 4376,
October 2005. February 2006.
[13] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), August 2004.
[14] Even, R. and N. Ismail, "Conferencing Scenarios", [13] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597,
draft-ietf-xcon-conference-scenarios-05 (work in progress), August 2006.
September 2005.
[15] Levin, O., "Session Initiation Protocol Call Control - [14] Levin, O., "Session Initiation Protocol Call Control -
Conferencing for User Agents", Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-07 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005. June 2005.
[16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [15] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005. draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[17] Schulzrinne, H., "COMP: Conference Object Manipulation [16] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol", draft-schulzrinne-xcon-comp-00 (work in progress),
January 2006.
[18] Boulton, C. and M. Barnes, "Centralized Conferencing
Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in
progress), January 2006.
[19] Levin, O., "Centralized Conference Control Protocol",
draft-levin-xcon-cccp-04 (work in progress), January 2006.
[20] Jennings, C. and B. Rosen, "Media Conference Server Control for
XCON", draft-jennings-xcon-media-control-03 (work in progress),
July 2005.
[21] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
draft-rosen-xcon-conf-sidebars-01 (work in progress),
July 2004.
[22] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress), draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005. January 2005.
[23] Camarillo, G., "Session Description Protocol (SDP) Format for [17] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), draft-ietf-mmusic-sdp-bfcp-03 (work in progress),
October 2004. December 2005.
[24] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-14 (work in progress),
February 2006.
[25] Jennings, C., "Conference State Change Protocol (CSCP)", [18] Novo, O., "A Common Conference Information Data Model for
draft-jennings-xcon-cscp-02 (work in progress), December 2005. Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-02 (work in progress),
July 2006.
[26] Enns, R., "NETCONF Configuration Protocol", [19] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-netconf-prot-12 (work in progress), March 2006. draft-ietf-simple-message-sessions-15 (work in progress),
July 2006.
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
skipping to change at page 57, line 5 skipping to change at page 61, line 5
Email: cboulton@ubiquitysoftware.com Email: cboulton@ubiquitysoftware.com
Orit Levin Orit Levin
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: oritl@microsoft.com Email: oritl@microsoft.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 57, line 29 skipping to change at page 61, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 94 change blocks. 
618 lines changed or deleted 921 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/