XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Expires: December 24, 2006
Intended status: Informational                                C. Boulton
Expires: March 15, 2007                    Ubiquity Software Corporation
O. Levin
Microsoft Corporation
June 22,
September 11, 2006

A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-04
draft-ietf-xcon-framework-05

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on December 24, 2006. March 15, 2007.

Copyright (C) The Internet Society (2006).

Abstract

This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
a centralized unicast conference.  The Centralized Conferencing
Framework defines logical entities and naming conventions, along with
a conferencing data model.  The framework also outlines a set of
conferencing protocols, which are complementary to the call signaling
protocols, for building advanced conferencing applications.  The
framework binds all the defined components together for the benefit
of builders of conferencing systems.

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
5.  Centralized Conferencing Data Model  . . . . . . . . . . . . . 10  9
5.1.  Common Conference Information  . . . . . . . . . . . . . . 11
5.2.  Conference Template  . . . . . . . . . . . . . . . . . . . 12
5.3.  Conference policies  . . . . . . . . . . . . . . . . . . . 12
6.  Centralized Conferencing Constructs and Identifiers  . . . . . 13 12
6.1.  Conference Identifier  . . . . . . . . . . . . . . . . . . 13 12
6.2.  Conference Object  . . . . . . . . . . . . . . . . . . . . 13
6.2.1.  Conference Object Identifier . . . . . . . . . . . . . 15
6.3.  Conference User Identifier . . . . . . . . . . . . . . . . 15
7.  Conferencing System Realization  . . . . . . . . . . . . . . . 15
7.1.  Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.  Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
7.3.  Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
7.4.  Scheduling a conference  . . . . . . . . . . . . . . . . . 23 22
8.  Conferencing Mechanisms  . . . . . . . . . . . . . . . . . . . 26 25
8.1.  Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 25
8.2.  Notifications  . . . . . . . . . . . . . . . . . . . . . . 26 25
8.3.  Conference Control Protocol  . . . . . . . . . . . . . . . 26
8.3.1.  CCCP . . . . . . . . . . . . . . 25
8.4.  Floor Control  . . . . . . . . . . . 27
8.3.2.  CSCP . . . . . . . . . . . 25
9.  Conferencing Scenario Realizations . . . . . . . . . . . . . . 27
8.3.3.  SOAP . . . . . .
9.1.  Conference Creation  . . . . . . . . . . . . . . . . . . . 27
8.4.  Floor Control  . .
9.2.  Participant Manipulations  . . . . . . . . . . . . . . . . 29
9.3.  Media Manipulations  . . . . 28
9.  Conferencing Scenario Realizations . . . . . . . . . . . . . . 29
9.1.  Conference Creation . 31
9.4.  Sidebar Manipulations  . . . . . . . . . . . . . . . . . . 29
9.2.  Participant Manipulations 32
9.4.1.  Internal Sidebar . . . . . . . . . . . . . . . . 31
9.3.  Media Manipulations . . . 34
9.4.2.  External Sidebar . . . . . . . . . . . . . . . . 33
9.4.  Sidebar Manipulations . . . 36
9.5.  Floor control using sidebars . . . . . . . . . . . . . . . 34
9.5. 39
9.6.  Whispering or Private Messages . . . . . . . . . . . . . . 38
9.6. 41
9.7.  Conference Announcements and Recordings  . . . . . . . . . 39
9.7. 43
9.8.  Monitoring for DTMF  . . . . . . . . . . . . . . . . . . . 39
9.8. 45
9.9.  Observing a Conference and Coaching . . . . . . . . . . . . . . . . . . 39 45
10. Relationships between SIPPING and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 40 48
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 40 49
11.1. Authorization  . . . . . . . . . . . . . . . . . . . . . . 41 50
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 42 51
11.3. Floor Control Server Authentication  . . . . . . . . . . . 42 51
12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43 52
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 52
14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 52
15. Appendix A - Conference Object Identifier  . . . . . . . . . . 48
15.1. Conference Object URI Definition . . . . . . . . . . . . . 51
16. Appendix B - Conference User Identifier  . . . . . . . . . . . 51
16.1. Conference User Definition . . . . . . . . . . . . . . . . 53
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
17.1. 58
15.1. Normative References . . . . . . . . . . . . . . . . . . . 53
17.2. 58
15.2. Informative References . . . . . . . . . . . . . . . . . . 53 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 59
Intellectual Property and Copyright Statements . . . . . . . . . . 57 61

1.  Introduction

This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
a centralized unicast conference.  Other than references to general
functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document

The Centralized Conferencing Framework defines logical entities and
naming conventions, along with a conferencing data model.  The
framework also outlines a set of conferencing protocols, which are
complementary to the call signaling protocols, for building advanced
conferencing applications.

The Centralized Conferencing Framework is compatible with the
functional model presented in the SIPPING Conferencing Framework [9].
Section 10 of this document discusses the relationship between the
Centralized Conferencing Framework and the SIPPING Conferencing
framework, in the context of the Centralized Conferencing model
presented in this document.

2.  Conventions

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.

3.  Overview

A centralized conference is an association of endpoints, called
conference participants, with a central endpoint, called a conference
Focus.  The Focus has direct peer relationships with the participants
by maintaining a separate call signaling interface with each.
Consequently, in this centralized conferencing model, the call
signaling graph is always a star.

The most basic conference supported in this model would be an ad-hoc
unmanaged conference, which would not necessarily require any of the
functionality defined within this framework.  For example, it could
be supported using basic SIP signaling functionality with a
participant serving as the Focus; the SIPPING Conferencing Framework
[9] together with the SIP Call Control Conferencing for User
Agents[15] Agents
[14] documents address these types of scenarios.

In addition to the basic features, however, a conferencing system
supporting the centralized conferencing model proposed in this
framework document can offer richer functionality, by including
dedicated conferencing applications with explicitly defined
capabilities, reserved recurring conferences, along with providing
the standard protocols for managing and controlling the different
attributes of these conferences.

The core requirements for centralized conferencing are outlined in
[10].
[9].  These requirements are applicable for conferencing systems
using various call signaling protocols, including SIP.  Additional
conferencing requirements are provided in [12], [13], and [14]. [13].

The centralizing conferencing system proposed by this framework is
built around a fundamental concept of a conference object.  A
conference object provides the data representation of a conference
during each of the various stages of a conference (e.g., creation,
reservation, active, completed, etc.).  A conference object is
accessed via the logical functional elements, with whom a
conferencing client interfaces, using the various protocols
identified in Figure 1.  The functional elements defined for a
conferencing system described by the framework are a Conference
Control Server, Floor Control Server, any number of Foci and a
Notification Service.  A Conference Control Protocol (CCP) provides
the interface between a conference and media control client and the
conference control server.  A Binary Floor Control Protocol (BFCP)
provides the interface between a floor control client and the floor
control server.  A call signaling protocol (e.g., SIP, H.323, PSTN,
etc.) provides the interface between a call signaling client and a
Focus.  A notification protocol (e.g.  SIP Notify) provides the
interface between the conferencing client and the Notification
Service.

A conferencing system can support a subset of the conferencing
functions depicted in the conferencing system logical decomposition
in Figure 1 and described in this document.  However, there are some
essential components that would typically be used by most other
advanced functions, such as the Notification Service.  For example,
the notification service is used to correlate information, such as
list of participants with their media streams, between the various
other components.

...................................................................
.  Conferencing System                                            .
.                                                                 .
.        +-----------------------------------------------------+  .
.        |       C o  n  f  e  r  e n  c  e   o b  j  e  c  t  |  .
.      +-+---------------------------------------------------+ |  .
.      |       C o n f e r e n c e   o b j e c t             | |  .
.    +-+---------------------------------------------------+ | |  .
.    |       C o n f e r e n c e   o b j e c t             | | |  .
.    |                                                     | | |  .
.    |                                                     | |-+  .
.    |                                                     |-+    .
.    +-----------------------------------------------------+      .
.              ^                  ^             ^        |        .
.              |                  |             |        |        .
.              v                  v             v        v        .
.  +-------------------+ +--------------+ +-------+ +------------+.
.  | Conference Control| | Floor Control| |Foci   | |Notification|.
.  | Server            | | Server       | |       | |Service     |.
.  +-------------------+ +--------------+ +-------+ +------------+.
.             ^                 ^           ^          |          .
..............|.................|...........|..........|...........
|                 |           |          |
|Conference       |Binary     |Call      |Notification
|Control          |Floor      |Signaling |Protocol
|Protocol         |Control    |Protocol  |
|                 |Protocol   |          |
|                 |           |          |
..............|.................|...........|..........|...........
.             V                 V           V          V          .
.  +----------------+  +------------+  +----------+ +------------+.
.  | Conference     |  | Floor      |  | Call     | |Notification|.
.  | and Media      |  | Control    |  | Signaling| | Client     |.
.  | Control        |  | Client     |  | Client   | |            |.
.  | Client         |  |            |  |          | |            |.
.  +----------------+  +------------+  +----------+ +------------+.
.                                                                 .
. Conferencing Client                                             .
...................................................................

Figure 1: Conferencing System Logical Decomposition.

The media graph of a conference can be centralized, decentralized, or
any combination of both and potentially differ per media type.  In
the centralized case, the media sessions are established between a
media mixer controlled by the focus and each one of the participants.
In the decentralized (i.e., distributed) case, the media graph is a
multicast or multi-unicast mesh among the participants.
Consequently, the media processing (e.g., mixing) can be controlled
either by the focus alone or by the participants.  The concepts in
this framework document clearly map to a centralized media model.
The concepts can also apply to the decentralized media case, however,
the details of such are left for future study.

Section 5 of this document provides more details on the conference
object.  Section 6 provides an overview of the identifiers necessary
to address and manage the conference objects, instances and users
associated with a conferencing system.  Section 7 of this document
describes how a conferencing system is logically built using the
defined data model and how the conference objects are maintained.
Section 8 describes the fundamental conferencing mechanisms and
provides a high level overview of the protocols.  Section 9 then
provides realizations of various conferencing scenarios, detailing
the manipulation of the conference objects using the defined
protocols.  Section 10 of this document summarizes the relationship
between this Centralized Conferencing Framework and the SIPPING
Conferencing Framework.

4.  Terminology

This Centralized Conferencing Framework document generalizes, when
appropriate, the SIPPING Conferencing Framework [9] terminology and
introduces new concepts, as listed below.  Further details and
clarification of the new terms and concepts are provided in the
subsequent sections of this document.

Active conference:  The term active conference refers to a conference
cbject that has been created and activated via the allocation of
its identifiers (e.g., conference object identifier and conference
identifier) and the associated focus.  An active conference is
created based on either a system default conference blueprint or a
specific conference reservation.
Call Signaling protocol:  The call signaling protocol is used between
a participant and a focus.  In this context, the term "call" means
a channel or session used for media streams.
Common conference information:  The common conference information is
the data type (i.e., the XML schema) which is used to represent
the core set of information for a conference object.  This core
information
includes a common set of definitions for basic conference features, such as
conference identifiers, membership, signaling, capabilities and
media types, applicable to a wide range of conferencing
applications.

Conference blueprint: A  The common conference blueprint is information also includes the
media and application specific data for enhanced conferencing
features or capabilities, such as media mixers.  The common
conference information is the data type (i.e., the XML schema) for
a conference object
Conference blueprint:  A conference blueprint is a static conference
object within a conferencing system, which describes a typical
conference setting supported by the system.  A conference
blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints.  Each blueprint is
comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the common conference
information and the specific template associated with the
blueprint.
information.
Conference control protocol (CCP):  A conference control protocol
provides the interface for data manipulation and state retrieval
for the centralized conferencing data, represented by the
conference object.
Conference factory:  A conference factory is a logical entity, that
generates upon request, unique URI(s) to identify and represent a
conference focus.
Conference identifier (ID):  A conference identifier is a call
signaling protocol-specific URI that identifies a conference focus
and its associated conference instance.
Conference instance:  A conference instance refers to an internal
implementation of a specific conference, represented as a set of
logical conference objects and associated identifiers.
Conference object:  A conference object represents a conference at a
certain stage (e.g., description upon conference creation,
reservation, activation, etc.), which a conferencing system
maintains in order to describe the system capabilities and to
provide access to the services available for each object
independently.  The conference object schema is comprised of two
distinct sub components; based on the
common conference information and the
conference template(s). information.
Conference object identifier (ID):  A conference object identifier is
a URI which uniquely identifies a conference object and is used by
a conference control protocol to access and modify the conference
information.
Conference policies:  Conference policies collectively refers to a
set of rights, permissions and limitations pertaining to
operations being performed on a certain conference object.
Conference reservation:  A conference reservation is a conference
object, which is created from either a system default or client
selected blueprint.
Conference state:  The conference state reflects the state of a
conference instance and is represented using a specific, well-
defined schema.
Conferencing system:  Conferencing system refers to a conferencing
solution based on the data model discussed in this framework
document and built using the protocol specifications referenced in
this framework document.

Conference 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
conference instance, for which a conference participant, or group
of participants, is granted temporary access.
Floor chair:  A floor chair is a floor control protocol compliant
client, either a human participant or automated entity, who is
authorized to manage access to one floor and can grant, deny or
revoke access.  The floor chair does not have to be a participant
in the conference instance.
Focus:  A focus is a logical entity that maintains the call
signalling interface with each participating client and the
conference object representing the active state.  As such, the
focus acts as an endpoint for each of the supported signaling
protocols and is responsible for all primary conference membership
operations (e.g., join, leave, update the conference instance) and
for media negotiation/maintenance between a conference participant
and the focus.
Media graph:  The media graph is the logical representation of the
flow of media for a conference.
Media mixer:  A media mixer is the logical entity with the capability
to combine media inputs of the same type, transcode the media and
distribute the result(s) to a single or multiple outputs.  In this
context, the term "media" means any type of data being delivered
over the network using appropriate transport means, such as RTP/
RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol
(defined in [24]).
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. [19]).
Role:  A role provides the context for the set of conference
operations that a participant can perform.  A default role (e.g.,
standard conference participant) will always exist, providing a
user with a set of basic conference operations.  Based on system
specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to
a wider set of conference operations.
Sidebar:  A sidebar is a separate Conference instance that only
exists within the context of a parent conference instance.  The
objective of a sidebar is to be able to provide additional or
alternate media only to specific participants.
Whisper: TBD.  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

The centralized conference data model is logically represented by the
conference object.  A conference object is of type 'Conference object
type', which is comprised of two distinct components: the 'Common conference
information type' and the 'Conference template type', as illustrated in Figure 2.  Each of these types  The common conference
information type is extensible for including potentially multiple sub-types.

+------------------------------------------------------+
| C o n f e r e n c e   o b j e c t   t y p e                    |
|                                                      |
| +--------------------------------------------------+ |
| | Common conference information type               | |
| |                                                  | |
| | +----------------------------------------------+ | |
| | | Conference description  (times, duration)    | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Membership (roles, capacity, names)          | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Signaling (protocol, direction, status)      | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor information                            | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Sidebars, Etc.                               | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ | Mixer algorithm, inputs, and outputs         | | Conference template type |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ |   - Mixer algorithm, inputs, and outputs |
| | |   - Floor controls                               | | |
|   - User Control Interface | +----------------------------------------------+ | |
| |   - User's View +----------------------------------------------+ | |
| | |   - Etc.                                         | | | +--------------------------------------------------+
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+

Figure 2: Conference Object Type Decomposition.

In a system based on this conferencing framework, the same conference
object type is used for representation of a conference during
different stages of a conference, such as expressing conferencing
system capabilities, reserving conferencing resources or reflecting
the state of ongoing conferences.  Thus, each of the two components
(i.e., the common conference information and the conference template)
may be optionally included in a particular conference object.
Section 7 describes the usage semantics  Section 7 describes the usage
semantics of the conference objects.

The centralized conferencing data model defined in this framework has
no strict separation between conference membership, conference media
information and the related policies.  The policies are an integral
part of the data model and are realized by local, system level
boundaries associated with specific data elements, such as the
membership, and by the ranges and limitations on other data elements.
Additional policy considerations for a system realization based on
this data model are discussed in Section 5.3. 5.2.  The integration of the
data in this model meets the requirement of many conference control
operations to enable synchronized access to the integral conference
policies, to the conference state as a whole, and for receiving
notifications about changes to either using the same interface.

The exact XML schema of the Conference Object, conference object, including the
organization of the Common Conference Information and the Conference
Templates, are common conference information is detailed in a
separate documents [ref: TBD]. document [18].

5.1.  Common Conference Information

The

There is a core set of data in the common conference information section contains the core
information that
is utilized in any conference and is conference, independent of the specific conference
media nature (e.g., the mixing algorithms performed, the advanced
floor control applied, etc.).  Typically,
would be interested  This core set of data in this common conference information only.

The the common
conference information may be represented using the
conference-type as defined in [11].  The conference-type contains the definitions for representation of representing the
conference object capabilities, membership, roles, call signaling and
media status relevant to different stages of the conference life-cycle.

New centralized conferencing specifications can extend life-
cycle.  This core set of common conference information may be
represented using the basic conference-type and introduce additional data elements as defined in [11].  Typically,
within the common conference information type.

5.2.  Conference Template

The concept
would be interested in this core set of a common conference template is introduced information
only.

In order to separate the
complexity and the details of the "mixer" support more complex media manipulations 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. information contains
additional data, beyond that defined in [11].  The RFCs defining these
templates are referred to as a registered conference document.

Typically, a conference template data model defined
in [18] would contain be the basis for conferencing systems supporting
enhanced conferencing features.  The additional information about 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.

The addition of new elements or the modification of

New centralized conferencing specifications can extend the controls basic
conference-type as defined in [18] and introduce additional data
elements to be used within an element of an existing template requires the definition of
a new template.

5.3. common conference information type.

5.2.  Conference policies

Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed
on a certain conference object.

The set of rights describes the read/write access privileges for the
conference object as a whole.  This access would usually be granted
clients with certain roles in the conference.  As such, the policies
represented by the set of rights aren't explicitly defined within the
data model, but rather are reflected in the system realization
(Section 7).

The permissions and limits, however, are specified as an integral
part of the conference object type, with data objects containing the
allowed ranges for other data objects (e.g., maximum number of
participants) and lists of clients allowed to perform certain
operations on a conference object.  For example, the "allowed to
join" list of participants is consulted to decide who is allowed to
join.  The entries in the list can specify the identity of an
individual user (joe@example.com), a role, a domain (*@example.com),
etc.  For further details, refer to the detailed data model [ref:
TBD]. [18].

A more general rule mechanism, beyond the functionality provided by
the permissions and limits, is an item for future study.

6.  Centralized Conferencing Constructs and Identifiers

This section provides details of the identifiers associated with the
centralized conferencing framework constructs and the identifiers
necessary to address and manage the clients associated with a
conferencing system.  An overview of the allocation, characteristics
and functional role of the identifiers is provided.

6.1.  Conference Identifier

The conference identifier (conference ID) is a call signaling
protocol-specific URI that identifies a specific conference focus and
its associated conference instance.  A conference factory is one
method for generating a unique conference ID, to identify and address
a conference focus, using a call signaling interface.  Details on the
use of a conference factory for SIP signaling can be found in [15]. [14].
The conference identifier can also be obtained using the conference
control protocol [Section 8.3] or other, including proprietary, out-
of-band mechanisms.

6.2.  Conference Object

A Conference object provides the logical representation of a
conference iInstance instance in a certain stage, such as a conference
blueprint representing a conferencing system's capabilities, the data
representing a conference reservation, and the conference state
during an active conference.  Each conference object is independently
addressable through the conference control protocol interface
[Section 8.3].

Figure 3 illustrates the relationships between the conference
identifier, the focus and the conference object ID within the context
of a logical conference instance, with the conference object
corresponding to an active conference.

A conference object representing a conference in the active state can
have multiple call signalling conference identifiers; for example,
for each call signalling protocol supported.  There is a one-to-one
mapping between an active conference object and a conference focus.
The focus is addressed by explicitly associating unique conference
IDs for each signaling protocol supported by the active conference
object.

......................................................................
.  Conference Instance                                               .
.                                                                    .
.                                                                    .
.        +---------------------------------------------------+       .
.        |       Conference Object Identifier                |       .
.        |                                                   |       .
.        |                                                   |       .
.        +---------------------------------------------------+       .
.                           ^                            ^           .
.                           |                            |           .
.                           v                            |           .
.   ...................................................  |           .
.   . Focus                                           .  |           .
.   .                                                 .  |           .
.   .           +----------------------------------+  .  |           .
.   .           |Conference Identifier (Protocol Y)|  .  |           .
.   .       +------------------------------------+ |  .  |           .
.   .       |  Conference Identifier (PSTN)      | |  .  |           .
.   .   +--------------------------------------+ |-+  .  |           .
.   .   |     Conference Identifier (SIP)      | |^   .  |           .
.   .   |                                      |-+|   .  |           .
.   .   |                                      |^ |   .  |           .
.   .   +--------------------------------------+| |   .  |           .
.   ............^...............................|.|....  |           .
.               |                               | |      |           .
................|...............................|.|......|............
|                               | |      |
|SIP                            | |      |Conference
|                          PSTN | |Y     |Control
|                               | |      |Protocol
|               +---------------+ |      |
|               |                 |      |
|               |                 |      |
v               v                 v      v
+----------------+  +--------------+  +---------------+
| Conferencing   |  | Conferencing |  | Conference    |
| Client         |  | Client       |  | Client        |
| 1              |  | 2            |  | X             |
+----------------+  +--------------+  +---------------+

Figure 3: Identifier Relationships for an Active Conference.

6.2.1.  Conference Object Identifier

In order to make each conference object externally accessible, the
conferencing system allocates a unique URI per distinct conference
object in the system.  A conference control protocol includes the
conference object identifier in requests for directly manipulating a
particular conference object and for obtaining its current state.
The conference object identifier logically maps to other protocol
specific identifiers associated with the conference instance, such as
the BFCP 'confid'.  A full description and semantics of how the
conference object identifier is created and used is as defined in
Section 15. [ref
conf-uri: TBD].

6.3.  Conference User Identifier

Each user within a conferencing system is allocated a unique
conference user identifier.  The user identifier is used in
association with the conference object identifier to uniquely
identify a user within the scope of conferencing system.  There is
also a requirement for identifying conferencing system users who may
not be participating in a conference instance.  Examples of these
users would be a non participating 'Floor Control Chair' or 'Media
Policy Controller'.  The conference user identifier is required in
conference control protocol requests to uniquely determine who is
issuing commands, so that appropriate policies can be applied to the
requested command.  The conference user identifer is logically
associated with the other user identifiers assigned to the
conferencing client for other protocol interfaces, such as an
authenticated SIP user.  A full description and semantics of the
conference user identifier is provided in Section 16 [ref conf-userid: TBD].

7.  Conferencing System Realization

Implementations based on this centralized conferencing framework can
range from systems supporting ad-hoc conferences, with default
behavior only, to sophisticated systems with the ability to schedule
recurring conferences, each with distinct characteristics, being
integrated with external resource reservation tools, and providing
snapshots of the conference information at any of the stages of the
conference life-cycle.

A conference object is the logical representation of a conference
instance at a certain stage, such as capabilities description upon
conference creation, reservation, activation, etc., which a
conferencing system maintains in order to describe the system
capabilities and to provide access to the available services provided
by the conferencing system.  Consequently, this centralized
conferencing framework does not mandate the actual usage of the
conference object, but rather defines the general cloning tree
concept and the mechanisms required for its realization, as described
in detail in Section 7.1.

Adhoc and advanced conferencing examples are provided in Section 7.2
and Section 7.3, with the latter providing additional description of
the Conference Object in terms of the stages of a conference, to
support scheduled and other advanced conference capabilities.  The
scheduling of a conference based on these concepts and mechanisms is
then detailed in Section 7.4

As discussed in Section 5.3, 5.2, there are conference policies implicit
in and derivable from the data in the conference objects and there
are also policies applying to the conference objects as a whole.  In
the examples in this section, these latter policies are shown
logically associated with the conference objects, however, it is an
implementation specific mechansim as to how these policies are
managed and applied to the conference objects.

7.1.  Cloning Tree

The concept defined in this section is a logical representation only,
as it is reflected through the centralized conferencing mechanisms:
the URIs and the protocols.  Of course, the actual system realization
can differ from the presented model.  The intent is to illustrate the
role of the logical elements in providing an interface to the data,
based on conferencing system and conferencing client actions, and
describe the resultant protocol implications

Any conference object in a conferencing system is created by either
being explicitly cloned from an existing parent object or being
implicitly cloned from a default system conference blueprint.  A
conference blueprint is a static conference object used to describe a
typical conference setting supported by the system.  Each system can
maintain multiple blueprints, typically each describing a different
conferencing type using the common conference information format,
along with any number of template definitions. format.
This document uses the "cloning" metaphor instead of the
"inheritance" metaphor because it more closely fits the idea of
object replication, rather than a data type re-usage and extension
concept.

The cloning operation needs to specify whether the link between the
parent and the child needs to be maintained in the system or not.  If
no link between the parent and the child exists, the objects become
independent and are not impacted by any operations on the parent
object nor subject to any limitations of the parent object.

Once the new object is created, it can be addressed by a unique
conference object URI assigned by the system, as described in
Section 15 /[ref:TBD]. [ref
conf-uri:TBD].  By default, the newly created object contains all the
data existing in the parent object.  The newly created object can
expand the data it contains, within the schema types supported by the
parent.  It can also restrict the read/write access to its objects.
However, unless the object is independent, it cannot modify the
access restrictions imposed by the parent object.

Any piece of data in the child object can be independently accessed
and, by default, can be independently modified without affecting the
parent data.

Unless the object is independent, the parent object can enforce a
different policy by marking certain data elements as "parent
enforceable".  The values of these data elements can not be changed
by directly accessing the child object; neither can they be expanded
in the child object alone.

Figure 4 illustrates an example of a conference (Parent B), which is
created independent of its Parent (Parent A).  Parent B creates two
child objects, Child 1 and Child 2.  Any of the data elements of
Parent B can be modified (i.e. there are no "parent enforceable" data
elements) and depending upon the element, the changes will be
reflected in Child 1 and Child 2 , whereas changes to Parent A will
not impact the data elements of Parent B. Any "parent enforceable"
data elements as defined by Parent B cannot be modified in the child
objects.

+---+-----------------------+
| p |                       |
| o |   P A R E N T  A      |
| l |                       |
| i |   C O N F E R E N C E |
| c |                       |
| i |   O B J E C T         |
| e |                       |
+-s-+-----------------------+
|
\| /
\/  INDEPENDENT
/\
/| \
V
+---+-----------------------+
| p |                       |
| o |   P A R E N T  B      |
| l |                       |
| i |   C O N F E R E N C E |
| c |                       |
| i |   O B J E C T         |
| e |                       |
+-s-+-----------------------+
|    |
|    |
|    ---------------------------
|                              |
V                              V
+---+-----------------------+    +---+-----------------------+
| p |                       |    | p |                       |
| o |   C H I L D  1        |    | o |   C H I L D  2        |
| i |                       |    | l |                       |
| l |   C O N F E R E N C E |    | i |   C O N F E R E N C E |
| i |                       |    | c |                       |
| c |   O B J E C T         |    | i |   O B J E C T         |
| i |                       |    | e |                       |
+-s-+-----------------------+    +-s-+-----------------------+

Figure 4: The Cloning Tree.

Using the defined cloning model and its tools, the following sections
show examples of how different systems based on this framework can be
realized.

Figure 5 illustrates how an ad-hoc conference can be created and
managed in a conferencing system.  A client can create a conference
by establishing a call signaling channel with a conference factory as
specified in Section 6.1.  The conference factory can internally
select one of the system supported conference blueprints based on the
requesting client privileges and the media lines included in the SDP
body.

The selected blueprint with its default values is copied by the
server into a newly created conference object, referred to as an
'Active Conference'.  At this point the conference object becomes
independent from its blueprint.  A new conference object identifier,
a new conference identifier and a new focus are allocated by the
server.

During the conference lifetime, an authorized client can manipulate
the conference object, such as adding participants, using the
Conference Control Protocol [Section 8.3].

+---+-----------------------+
| p |                       |
| o |   System  Default     |
| l |                       |
| i |   Conference          |
| c |                       |
| i |   Blueprint           |
| e |                       |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p |                       |
| o |  Active               |
| l |                       |
| i |  Conference           |
| c |                       |
| i |                       |
| e |                       |
+-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime.

Figure 6 illustrates how a recurring conference can be specified
according to system capabilities, scheduled, reserved, and managed in
a conferencing system.  A client would first query a conferencing
system for its capabilities.  This can be done by requesting a list
of the conference blueprints the system supports.  Each blueprint
contains a specific combination of capabilities and limitations of
the conference server in terms of supported media types (e.g., audio,
video, text, or combinations of these), participant roles, maximum
number of participants of each role, availability of floor control,
controls available for participants, availability and type of
sidebars, the definitions and names of media streams, etc.  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
client into a newly created conference object, referred to as a
conference reservation, that specifies the resources needed from the
system for this conference instance.  At this point the conference
reservation becomes independent from its blueprint.  The client can
also change the default values, within the system ranges, and add
additional information, such as the list of participants and the
conference start time, to the conference reservation.

At this point the client can ask the conference server to create new
conference reservations by attaching the conference reservation to
the request.  As a result, the server can allocate the needed
resources, create the additional conference objects for the child
conference reservations and allocate the conference object
instances rather than a single Conference.  If
identifiers for all - the original conference reservation and for
each child conference reservation.

From this point on, any authorized client uses is able to access and
modify each of the conference object ID provided and a CCP request objects independently.  By default,
changes to adjust an individual child conference reservation will affect
neither the parent conference reservation, every from which it was created,
nor its siblings.

On the other hand, some of the conference instance in sub-objects, such as the series will
be altered.  This includes all future occurrences, such as a
conference scheduled as an infinite series, subject to the
limitations
maximum number of participants and the available calendaring interface.

A conferencing system that supports the scheduling of a series of
conference instances should also participants list, can be able to support manipulation
within a specific range of the series.  A good example is a
conference reservation that has been scheduled to occur every Monday
at 09.00 GMT.  For the next three weeks only, the meeting has been
altered to occur at 10.00 GMT in an alternative venue.  With Figure 7
in mind, the client will construct a CCP request whose purpose is to
modify the existing conference reservation for the recurring
conference instance.  The client will include the conference object
ID provided
defined by the conferencing system to explicitly reference the
conference reservation within the conferencing system.  A CCP request
will contain all the required changes to as parent enforceable.  As a result, these
objects can be modified by accessing the parent conference
reservation
(e.g., change of venue). only.  The conferencing system matches the incoming CCP request changes to the
existing conference reservation but identifies that the associated
iCal object only refers these objects can be applied
automatically to a range each of the existing series.  The
conferencing system creates a child, by cloning the original
conference reservation, to represent the altered conference instances
within the series.  The cloned child object is not independent of the
original parent object, thus preventing any potential conflicts in
scheduling (e.g., a change reservations, subject to the whole series 'start time').  The
cloned conference reservation, representing the altered series of 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 instances, reservation, either
via the system determination that the 'start' time has its own associated been reached
or via client invocation, an active conference object ID
which is returned to cloned based on the client using a CCP response.  This
conference object ID reservation.  As in the adhoc example, the active
conference is then used by independent from the client parent and changes to make any future
alterations on the newly defined sub-series.  This process can
conference reservation will not impact the active conference.  Any
desired changes must be
repeated any number of times as targeted towards the newly returned active conference.  An
example of this interaction is shown in Section 9.1

7.4.  Scheduling a conference object
ID representing

The capability to schedule conferences forms an altered (cloned) series important part of the
conferencing system solution.  An individual conference instances,
can itself be manipulated using reservation
typically has a CCP request for specified 'start' and 'end' time, with the newly created
conference object ID .  This provides times
being specified relative to a flexible approach single specified 'fixed' time (e.g.,
'start' = 09.00 GMT, 'end'= 'start'+2), subject to the
scheduling system
considerations.  In most advanced conferencing solutions it is
possible to not only schedule an individual occurrence of recurring a
conference instances.

8.  Conferencing Mechanisms

8.1.  Call Signaling

The focus is the central component reservation, but also schedule a series of the conference.  Participants
interface with the focus using an appropriate call signaling protocol
(CSP).  Participants request related
conferences (e.g., a weekly meeting that starts on Thursday at 09.00
GMT).

To be able to establish or join achieve such functionality, a conferencing system needs
to be able to appropriately schedule and maintain conference using
reservations that form part of a recurring conference.  The mechanism
proposed in this document makes use of the CSP.  After checking 'Internet Calendaring and
Scheduling Core Object' specification defined in RFC2445[8] in union
with the applicable policies, a focus then either
accepts concepts introduced in Section 5 for the request, sends purpose of
achieving advanced conference scheduling capability.

Figure 7 illustrates a progress indication related to the
status simplified view of the request (e.g., for a parked call while awaiting
moderator approval to join) or rejects that request client interacting with a
conferencing system.  The client is using the call
signaling interface.

During an active conference, a Conference Control
Protocol
[Section 8.3] can be used to affect the conference state.  For
example, CCP requests (Section 8.3) to add and delete participants are communicated a new conference reservation to the focus and checked against
conferencing system by interfacing with the conference policies.  If
approved, the participants are added or deleted using the call
signaling to/from the focus.

server.  A conferencing system is responsible for implementing CCP request contains a Conference
Notification Service.  The Conference Notification Service provides
updates valid conference reservation and
reference by value to an 'iCal' object which contains scheduling
information about the conference instance state (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 authorized parties, create a new conference reservation is validated,
including participants.  A model for notifications using SIP the associated iCal object, and the resultant conference
reservation is
defined in [11]. created.  The conference user identifier and associated role are used by reservation is uniquely
represented within the conferencing system to filter the notifications such that they
contain only information that 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 allowed returned to the
client and can be sent used to that user.

8.3.  Conference Control Protocol

The conference control protocol provides for data manipulation and
state retrieval for the centralized conferencing data, represented by reference the conference object.  The details of the 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 protocol.  Figure 7 can also be applied when explaining how a
series of conferences are detailed scheduled 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 system.  The description
is almost identical with the WG reaches consensus on exception that 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 iCal definition that
is defined as included in a set of transactions issued over CCP request represents a
reliable transport protocol.  A transaction consists series of a Request
carrying recurring
conference instances (e.g., conference start time, end time, occur
weekly).  The conferencing system will treat this request the required information in an XML body and a corresponding
Response carrying an appropriate XML body.

CCCP requests are submitted to same as
the CCCP server and can first example.  The CCP request will be prioritized
and queued, based on the CCCP client Role and validated, along with the requested
primitives.  CCCP requires no single lock per document,
associated iCal object, 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] conference reservation is a client server protocol
used to change created.
The conference reservation and its conference object ID created for
this example represent the state entire series of a recurring conference object.  CSCP extends
instances rather than a single Conference.  If the
BFCP protocol [16] with new commands.  A client sends uses the server
conference object ID provided and a CCP request representing a sequence of commands.  Each command can set,
get, add, or delete a single field in to adjust the
conference object.  Changes
to the reservation, every conference object are performed on instance in the series will
be altered.  This includes all future occurrences, such as a hierarchal set
conference scheduled as an infinite series, subject to the
limitations of
elements and unique attributes within those elements. the available calendaring interface.

A conferencing system that supports the scheduling of a series of
changes can
conference instances should also be pipelined in able to support manipulation
within a single BFCP message.  The server
executes each action in series.  If one specific range of them fails, the server
returns an error for the action series.  A good example is a
conference reservation that failed and does not execute any
of has been scheduled to occur every Monday
at 09.00 GMT.  For the actions after that.  Each individual action is atomic but next three weeks only, the
pipelined series is not.

The item meeting has been
altered to which a command applies is specified by occur at 10.00 GMT in an alternative venue.  With Figure 7
in mind, the client will construct a unique ID and,
where appropriate, attribute name.  The ID CCP request whose purpose is an unsigned 32 bit
integer called to
modify the Element ID. existing conference reservation for the recurring
conference instance.  The server discovery of client will include the Element conference object
ID is outside of CSCP.  Typically this is done provided by using the conferencing system to explicitly reference the
conference notification service per Section 8.2.  Each field in reservation within the
data received in conferencing system.  A CCP request
will contain all 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 required changes to the conference reservation
(e.g., change of a "header" and a "body" contained within an
"envelope". venue).

The "header" contains meta-information relating to conferencing system matches the
message, and can be used incoming CCP request 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
existing conference reservation but identifies that the mechanism for associated
iCal object content
manipulation and state retrieval for the centralized conferencing
data.  In general, SOAP is a good fit for Conference Control,
essentially because of its remote procedure call characteristics and
its inherently synchronous and client-driven nature.

8.4.  Floor Control

A floor control protocol allows an authorized client to manage access only refers to a specific floor and to grant, deny or revoke access range of other
conference users to that floor.  Floor control is not a mandatory
mechanism for a the existing series.  The
conferencing system implementation but provides
advanced media input control features for creates a child, by cloning the original
conference users.  A
mechanism for floor control reservation, to represent the altered conference instances
within a conferencing system is defined
in the Binary Floor Control Protocol specification [16].  [Editor's
note: Evaluation series.  The cloned child object is not independent of an alternative proposal, as the
original parent object, thus preventing any potential conflicts in
scheduling (e.g., a stand alone draft,
for using Templates as change to the means for correlating Floor Control
identifiers whole series 'start time').  The
cloned conference reservation, representing the altered series of
conference instances, has been proposed.  If/when this work its own associated conference object ID
which is done, it needs returned to be introduced and referenced here].

Within this framework, a the client supporting floor control needs to
obtain information for connecting to using a floor control server to enable
it to issue floor requests. CCP response.  This connection information can be
retrieved using information provided
conference object ID is then used by mechanisms such as
negotiation using the SDP[2] offer/answer[5] exchange on the
signaling interface with the focus.  Section 11.3 provides a
discussion of client authentication of a floor control server.

As well as the client to make any future
alterations on the floor control server connection
information, a client wishing to interact with a floor control server
requires access to additional information. newly defined sub-series.  This information
associates floor control interactions with the appropriate floor
instance.  Once a connection has been established and authenticated
(see [16] for authentication details), a specific floor control
message requires detailed information to uniquely identify a
conference, a user and a floor.

The conference is uniquely identifed by process can be
repeated any number of times as the newly returned conference object
ID per
Section 6.2.1.  This representing an altered (cloned) series of conference object ID must instances,
can itself be included in all
floor control messages.  When the SDP model is used as described in
[23] this identifier maps to the 'confid' SDP attribute.

Each authorized user associated with manipulated using a CCP request for the newly created
conference object is uniquely
represented by a conference user ID per Section 6.3. .  This conference
user ID must be included in all floor control messages.  When using
SDP offer/answer exchange to negotiate provides a Floor control connection flexible approach to the
scheduling of recurring conference instances.

8.  Conferencing Mechanisms

8.1.  Call Signaling

The focus is the central component of the conference.  Participants
interface with the focus using the an appropriate call signaling protocol, the unique protocol
(CSP).  Participants request to establish or join a conference identifier is contained in using
the 'userid' SDP attribute, as
defined in [23]

A media session within CSP.  After checking the applicable policies, a conferencing system can have any number focus then either
accepts the request, sends a progress indication related to the
status of
floors (0 the request (e.g., for a parked call while awaiting
moderator approval to join) or more) rejects that are represented by request using the call
signaling interface.

During an active conference, a Conference Control Protocol
[Section 8.3] can be used to affect the conference identifer.
When using SDP offer/answer exchange state.  For
example, CCP requests to add and delete participants are communicated
to negotiate a floor control
connection with the focus and checked against the conference policies.  If
approved, the participants are added or deleted using the call
signaling interface, to/from the
unique conference identifier focus.

A conferencing system is contained in the 'floorid' SDP
attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 .  Each
'floorid' attribute, representing responsible for implementing a unique floor, has an 'm-stream'
tag containing one or more identifiers. Conference
Notification Service.  The identifiers represent
individual SDP media sessions (as defined using 'm=' from SDP) using Conference Notification Service provides
updates about the SDP 'Label' attribute as conference instance state to authorized parties,
including participants.  A model for notifications using SIP is
defined in [22].

9.  Conferencing Scenario Realizations

This section addresses how advanced conferencing scenarios, many of
which have been described in [14], [11].

The conference user identifier and associated role are realized using this
centralized used by the
conferencing framework.  The objective of this section is system to further illustrate the model, mechanisms and protocols presented
in filter the previous sections and also serves to validate notifications such that the model,
mechanisms and protocols are sufficient they
contain only information that is allowed to support advanced
conferencing scenarios. be sent to that user.

8.3.  Conference Control Protocol

The details shown in the messages are conference control protocol provides for illustrative purposes only data manipulation and don't reflect
state retrieval for the structure centralized conferencing data, represented by
the conference object.  The details of the conference control
protocol
messages, but rather provide a high level primitive view of the
necessary operations and general logic flow, including the data
manipulation aspects.  It should be noted that not all entities
impacted by the request are shown provided in the diagram (e.g., Focus), but
rather the emphasis is on the new entities introduced by this
centralized conferencing framework.

9.1.  Conference Creation

There are different ways to create a conference. separate documents [references TBD].

8.4.  Floor Control

A participant can
create a conference using call signaling means only, such as SIP and
detailed in [15].  For a conferencing floor control protocol allows an authorized client to have more flexibility
in defining the charaterisitics manage access
to a specific floor and capabilities to grant, deny or revoke access of a conference, a
conferencing client would implement a other
conference users to that floor.  Floor control protocol
client.  By using is not a conference control protocol, the client can
determine the capabilities of mandatory
mechanism for a conferencing system and its various
resources.

Figure 8 implementation but provides an example of one client "Alice" determining the
advanced media input control features for conference blueprints available users.  A
mechanism for floor control within a particular conferencing system
and creating a conference based on is defined
in the Binary Floor Control Protocol specification [15].

Within this framework, a client supporting floor control needs to
obtain information for connecting to a floor control server to enable
it to issue floor requests.  This connection information can be
retrieved using information provided by mechanisms such as
negotiation using the SDP[2] offer/answer[5] exchange on the
signaling interface with the focus.  Section 11.3 provides a
discussion of client authentication of a floor control server.

As well as the client to the floor control server connection
information, a client wishing to interact with a floor control server
associates floor control interactions with the appropriate floor
instance.  Once a connection has been established and authenticated
(see [15] for authentication details), a specific floor control
message requires detailed information to uniquely identify a
conference, a user and a floor.

The conference is uniquely identifed by the conference object ID per
Section 6.2.1.  This conference object ID must be included in all
floor control messages.  When the SDP model is used as described in
[17] this identifier maps to the 'confid' SDP attribute.

Each authorized user associated with a conference object is uniquely
represented by a conference user ID per Section 6.3.  This conference
user ID must be included in all floor control messages.  When using
SDP offer/answer exchange to negotiate a Floor control connection
with the focus using the call signaling protocol, the unique
conference identifier is contained in the 'userid' SDP attribute, as
defined in [17]

A media session within a conferencing system can have any number of
floors (0 or more) that are represented by the conference identifer.
When using SDP offer/answer exchange to negotiate a floor control
connection with the focus using the call signaling interface, the
unique conference identifier is contained in the 'floorid' SDP
attribute, as defined in [17] e.g., a=floorid:1 m-stream:10 .  Each
'floorid' attribute, representing a unique floor, has an 'm-stream'
tag containing one or more identifiers.  The identifiers represent
individual SDP media sessions (as defined using 'm=' from SDP) using
the SDP 'Label' attribute as defined in [16].

9.  Conferencing Scenario Realizations

This section addresses how advanced conferencing scenarios, many of
which have been described in [13], are realized using this
centralized conferencing framework.  The objective of this section is
to further illustrate the model, mechanisms and protocols presented
in the previous sections and also serves to validate that the model,
mechanisms and protocols are sufficient to support advanced
conferencing scenarios.

The details shown in the messages are for illustrative purposes only
and don't reflect the structure of the conference control protocol
messages, but rather provide a high level primitive view of the
necessary operations and general logic flow, including the data
manipulation aspects.  It should be noted that not all entities
impacted by the request are shown in the diagram (e.g., Focus), but
rather the emphasis is on the new entities introduced by this
centralized conferencing framework.

9.1.  Conference Creation

There are different ways to create a conference.  A participant can
create a conference using call signaling means only, such as SIP and
detailed in [14].  For a conferencing client to have more flexibility
in defining the charaterisitics and capabilities of a conference, a
conferencing client would implement a conference control protocol
client.  By using a conference control protocol, the client can
determine the capabilities of a conferencing system and its various
resources.

Figure 8 provides an example of one client "Alice" determining the
conference blueprints available for a particular conferencing system
and creating a conference based on the desired blueprint.

+--------------------------------+
|   Conferencing System          |
"Alice"                           |                  +------------+|
+--------+                         |                  |            ||
|        |CCP Request <blueprints> | +-----------+    |            ||
| Client |-------------------------->|Conference |    |Conference  ||
|        |<--------------------------|Control    |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server     |    |            ||
...      | +-----------+    +------------+|
blueprintZ, |                                |
confUserID> |                                |
"Alice"                            |
+--------+                         |                                |
|        |CCP Request <reserve,    |                  +------------+|
|        |     blueprintAConfObjID,| +-----------+    |            ||
| Client |-------------------------->|Conference |    |Conference  ||
|        |    confUserID>          | |Control    |~~~>|BlueprintA  ||
|        |<--------------------------|Server     |    |            ||
|        |CCP Response             | |           |    +------------+|
+--------+  <reservationConfObjID, | |           |          \|/     |
confID>     | |           |          /|\     |
| |           |           V      |
| |           |    +------------+|
| |           |~~~>|Conference  ||
| |           |    |Reservation ||
| +-----------+    +------------+|
"Alice"                            |                         |      |
+--------+                         |                         |      |
|        |CCP Request <add,        |                         V      |
|        |reservationConfObjID,    | +-----------+    +------------+|
| Client |-------------------------->|Conference |    |Active      ||
|        |     confID,confUserID>  | |Control    |~~~>|Conference  ||
|        |<--------------------------|Server     |    |            ||
|        |CCP Response             | |           |    +------------+|
+--------+   <activeConfObjID,     | |           |                  |
confID>              | +-----------+                  |
+--------------------------------+

Figure 8: Client Creation of Conference using Blueprints

Upon receipt of the Conference Control Protocol request for
blueprints, the conferencing system would first authenticate "Alice"
(and allocate a conference user identifier, if necessary) and then
ensure that "Alice" has the appropriate authority based on system
policies to receive any blueprints supported by that system.  Any
blueprints that "Alice" is authorized to use are returned in a
response, along with the conference user ID.

Upon receipt of the Conference Control Protocol response containing
the blueprints, "Alice" determines which blueprint to use for the
conference to be created.  "Alice" creates a conference object based
on the blueprint (i.e., clones) and modifies applicable fields, such
as membership list and start time.  "Alice" then sends a request to
the conferencing system to create a conference reservation based upon
the updated blueprint.

Upon receipt of the Conference Control Protocol request to "reserve"
a conference based upon the blueprint in the request, the
conferencing system ensures that the blueprint received is a valid
blueprint (i.e. the values of the various field are within range).
The conferencing system determines the appropriate read/write access
of any users to be added to a conference based on this blueprint
(using membership, roles, etc.).  The conferencing system uses the
received blueprint to clone a conference reservation.  The
conferencing system also reserves or allocates a conference ID to be
used for any subsequent protocol requests from any of the members of
the conference.  The conferencing system maintains the mapping
between this conference ID and the conference object ID associated
with the reservation through the conference instance.

Upon receipt of the conference control protocol response to reserve
the conference, "Alice" can now create an active conference using
that reservation or create additional reservations based upon the
existing reservations.  In this example, "Alice" has reserved a
meetme conference bridge.  Thus, "Alice" provides the conference
information, including the necessary conference ID, to desired blueprint.
participants.  When the first participant, including "Alice",
requests to be added to the conference, an active conference and
focus are created.  The focus is associated with the conference ID
received in the request.  Any participants that have the authority to
manipulate the conference would receive the conference object
identifier of the active conference object in the response.

9.2.  Participant Manipulations

There are different ways to affect a participant state in a
conference.  A participant can join and leave the conference using
call signaling means only, such as SIP.  This kind of operation is
called "1st party signaling" and does not affect the state of other
participants in the conference.

Limited operations for controlling other conference participants (a
so called "3rd party control") through the Focus, using call
signaling only, may also be available for some signaling protocols.
For example, "Conferencing for SIP User Agents" [14] shows how SIP
with REFER can be used to achieve this functionality.

In order to perform richer conference control a user client needs to
implement a conference control protocol client.  By using a
conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state of any of the
conference participants.

Figure 9 provides an example of one client "Alice" impacting the
state of another client "Bob".  This example assumes an established
conference.  In this example, "Alice" wants to add "Bob" to the
conference.

+--------------------------------+
|   Conferencing System          |
"Alice"                           |                  +---------+--+|
+--------+                         |                  |policies |  ||
|        |CCP Request <            | +-----------+    +---------+  ||
| Client |-------------------------->|Conference |    | Active     ||
|        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
+--------+  Add, "Bob" >           | |Server     |    |            ||
| +-----------+    +-------+    ||
|                  |"Alice"|    ||
"Carol"                           |                  '       '    '|
+--------+  NOTIFY <"Bob"="added"> |+------------+    '       '    '|
| Client |.          .             ||Service     |    +-------+    ||
+--------+--+          .           ||            |    |"Bob"  |    ||
|        |<----------------------|            |    +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+                  |
+--------+                      +--------------------------------+
"Bob"

Figure 9: Client Manipulation of Conference - Add a party

Upon receipt of the Conference Control Protocol request to "add" a
party ("Bob") in the specific conference as identified by the
conference object ID, the conferencing system ensures that "Alice"
has the appropriate authority based on the policies associated with
that specific conference object to perform the operation.  The
conferencing system must also determine whether "Bob" is already a
user of this conferencing system or whether he is a new user.

If "Bob" is a new user for this conferencing system, a Conference
User Identifier is created for Bob. Based upon the addressing
information provided for "Bob" by "Alice", the call signaling to add
"Bob" to the conference is instigated through the Focus.

Once the call signaling indicates that "Bob" has been successfully
added to the specific conference, per updates to the state, and
depending upon the policies, other participants (including "Bob") may
be notified of the addition of "Bob" to the conference via the

9.3.  Media Manipulations

There are different ways to manipulate the media in a conference.  A
participant can change its own media streams by, for example, sending
re-INVITE with new SDP content using SIP only.  This kind of
operation is called "1st party signaling" and they do not affect the
state of other participants in the conference.

In order to perform richer conference control a user client needs to
implement a conference control protocol client.  By using a
conference control protocol, the client can manipulate the state of
various resources, such as media mixers, which may indirectly affect
the state of any of the conference participants.

Figure 10 provides an example of one client "Alice" impacting the
media state of another client "Bob".  This example assumes an
established conference.  In this example, the client, "Alice" whose
Role is "moderator" of the conference, wants to mute "Bob" on a
medium-size multi-party conference, as his device is not muted (and
he's obviously not listening to the call) and background noise in his
office environment is disruptive to the conference.

+--------------------------------+
|   Conferencing System          |
"Alice"                           |                  +------------+|                  +---------+--+|
+--------+                         |                  |policies |  ||
|        |CCP Request <blueprints> <            | +-----------+    |    +---------+  ||
| Client |-------------------------->|Conference |    |Conference    |Active      ||
|        |<--------------------------|Control    |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
...      | +-----------+    +------------+|
blueprintZ, |                                |
confUserID> |                                |
"Alice"                            |
+--------+  Mute, "Bob" >          | |Server     |    |        |CCP Request <reserve,    |                  +------------+|
|        |     blueprintAConfObjID,| +-----------+    |            ||
| Client |-------------------------->|Conference |    |Conference            ||
|        |    confUserID>          | |Control    |~~~>|BlueprintA +-----------+    +-------+    ||
|        |<--------------------------|Server     |    |                  |"Alice"|    ||
|        |CCP Response             | |           |    +------------+|                  '       '    '|
+--------+  <reservationConfObjID, | |           |          \|/     |
confID>     | |           |          /|\     |
| |           |           V      |
| |           |    +------------+|
| |           |~~~>|Conference  ||
| |  NOTIFY <"Bob"=mute">   |+------------+    '       '    '|
|    |Reservation        |<-------------------------|Notification|<~~~|            ||
| +-----------+    +------------+|
"Alice"                            |                         |      |
+--------+                         |                         |      |
|        |CCP Request <add,        |                         V      |
|        |reservationConfObjID,    | +-----------+    +------------+|
| Client |-------------------------->|Conference |    |Active      ||
|        |     confID,confUserID>  | |Control    |~~~>|Conference  ||
|        |<--------------------------|Server     | |.          .             ||Service     |    +-------+    ||
+--------+--+          .           ||            |        |CCP Response             | |           |    +------------+|
+--------+   <activeConfObjID,     |    |"Bob"  |    ||
|        |<----------------------|            |
confID>    +-------+----+|
| +-----------+ Client |  NOTIFY <"Bob"=mute">|+------------+                  |
+--------+                      +--------------------------------+

Figure 8: 10: Client Creation Manipulation of Conference using Blueprints - Mute a party

Upon receipt of the Conference Control Protocol request for
blueprints, the conferencing system would first authenticate "Alice"
(and allocate to "mute" a
party ("Bob") in the specific conference user identifier, if necessary) and then
ensure as identified by the
conference object ID, the Conference Server ensures that "Alice" has
the appropriate authority based on system the policies to receive any blueprints supported by that system.  Any
blueprints that "Alice" is authorized to use are returned in a
response, along associated with the conference user ID.

Upon receipt of the Conference Control Protocol response containing
the blueprints, "Alice" determines which blueprint to use for the
conference to be created.  "Alice" creates a that
specific conference object based
on to perform the blueprint (i.e., clones) and modifies applicable fields, such operation.  "Bob's" status
is marked as membership list "recvonly" and start time.  "Alice" then sends a request to the conferencing system to create a conference reservation based upon the conference object is updated blueprint.

Upon receipt of the Conference Control Protocol request to "reserve"
a conference based upon the blueprint in the request, the
conferencing system ensures
reflect that the blueprint received "Bob's" media is a valid
blueprint (i.e. the values of not to be "mixed" with the various field are within range).
The conferencing system determines conference
media.

Depending upon the appropriate read/write access policies, other participants (including "Bob") may
be notified of any users to this change via the Conference Notification Service.

9.4.  Sidebar Manipulations

A sidebar can be added to viewed as a conference based on this blueprint
(using membership, roles, etc.).  The conferencing system uses separate Conference instance that only
exists within the
received blueprint to clone context of a parent conference reservation.  The
conferencing system also reserves or allocates a instance.  Although
viewed as an independent conference ID to be
used for any subsequent protocol requests from any of the members of
the conference.  The conferencing system maintains instance, it can not exist
without a parent.  A sidebar is created using the mapping
between this same mechanisms
employed for a standard conference ID and the as described in Section 7.1.

A conference object ID representing a sidebar is created by cloning the
parent associated with the reservation through the existing conference instance.

Upon receipt of and updating any
information specific to the sidebar.  A sidebar conference control protocol response object is
implicitly linked to reserve the conference, "Alice" can now create an active parent conference using
that reservation or create additional reservations based upon object (i.e. it is not an
independent object) and is associated with the
existing reservations.  In this example, "Alice" has reserved a
meetme parent conference bridge.  Thus, "Alice" provides
object identifier as as shown in Figure 11.  A conferencing system
manages and enforces the conference
information, including parent and appropriate localized
restrictions on the necessary sidebar conference ID, to desired
participants.  When object (e.g., no members from
outside the first participant, including "Alice",
requests to be added to parent conference instance can join, sidebar conference
can not exist if parent conference is terminated, etc.).

+--------------+
|  Conference  |
|    Object    |
|  Identifier  |
+--------------+
|
|
|
+---------------------+---------------------+
|                     |                     |
+-------+-------+     +-------+-------+     +-------+-------+
|    Sidebar    |     |    Sidebar    |     |    Sidebar    |
|  Conference   |     |  Conference   |     |  Conference   |
|    Object     |     |    Object     |     |    Object     |
|  Identifier   |     |   Identifier  |     |   Identifier  |
+-------+-------+     +-------+-------+     +---------------+

Figure 11: Conference Object Mapping.

Figure 11 illustrates the conference, an active relationship between a conference object
and
focus are created.  The focus is associated with the conference ID
received in the request.  Any participants that have the authority to
manipulate the Sidebar conference would receive the objects within a conferencing
system.  Each Sidebar conference object
identifier of the active has a unique conference
object Identifier as described in the response.

9.2.  Participant Manipulations

There are different ways to affect a participant state in Section 6.2.1.  The main conference
object identifier acts as a
conference. top level identifier for associated
sidebars.

A participant can join and leave the sidebar conference using
call signaling means only, such as SIP.  This kind object Identifier follows many of operation is
called "1st party signaling" and does not affect the state of other
participants concepts
outlined in the conference.

Limited operations for controlling other conference participants (a
so called "3rd party control") through the Focus, using call
signaling only, may also be available for some signaling protocols.
For example, "Conferencing for SIP User Agents" [15] shows how SIP
with REFER can be used to achieve this functionality.

In order to perform richer conference control a user client needs to
implement a conference control protocol client.  By using a cloning tree model described in Section 7.1.  A
Sidebar conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state object contains a subset of any members from the
original Conference object.  Properties of the sidebar conference participants.
object can be manipulated by a Conference Control Protocol
(Section 8.3) using the unique conference object identifier for the
sidebar.  It is also possible for the top level conference object to
enforce policy on the sidebar object (similar to parent enforceable
as discussed in Section 7.1).

9.4.1.  Internal Sidebar

Figure 9 12 provides an example of one client "Alice" impacting the
state of another client "Bob".  This example assumes an established
conference.  In this example, involved in
active conference with "Bob" and "Carol".  "Alice" wants to add "Bob" create a
sidebar to have a side discussion with "Bob" while still viewing the
video associated with the main conference.  Alternatively, the audio
from the main conference could be maintained at a reduced volume.
"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          |
|                  +---------+--+|
|                  |policies |  ||
|                  +---------+  ||
|                  |Active      ||
|                  |Conference  ||
"Alice"                            |                  +-------+    ||
+--------+                         |                  |"Alice"|    ||
|        |CCP Req <createSidebar,  |                  +-------+    ||
|        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
| Client |-------------------------->|Conference |    +-------+    ||
|        |    confUserID>          | |Control    |~~~>|"Carol"|    ||
|        |<--------------------------|Server     |    +-------+----+|
|        |CCP Response             | |           |           |      |
+--------+  <sidebarResvConfObjID, | |           |           |      |
confID>     | |           |           V      |
| |           |    +---------+--+|
| |           |    |policies |  ||
| |           |~~~>+---------+  ||
| |           |    |            ||
| +-----------+    |            ||
"Alice"                           |                  +---------+--+|                  | Sidebar    ||
+--------+                         |                  |policies                  |  || Reservation||
|        |CCP Request < <update,     | +-----------+    +---------+    |            ||
| Client |-------------------------->|Conference        |    sidebarResvConfObjID,| | Active           |    |            ||
| Client |-------------------------->|           |~~~>|            ||
|        |  Conference Object ID,  confID,confUserID,     | |           |    +------------+|
|        |  video=parent,          | |           |           |      |
|        |  audio=sidebar>         | |Conference |           |      |
|        |                         | |Control    |~~~>|Conference    |           V      |
|        |                         | |Server     |    +---------+--+|
|        |CCP Response             | |           |    |policies |  ||
|        |    <activeSideConfObjID,| |           |    +---------+  ||
|        |<--------------------------|           |    |Active      ||
+--------+  Add, "Bob" >    confID>              | |Server |           |    |Sidebar     ||
| |           |    |Conference  ||
| +-----------+    +-------+    ||
|                  |"Alice"|    ||
"Carol"
"Bob"                            |                  '       '    '|                  |       |    ||
+--------+  NOTIFY <"Bob"="added"> <"Bob"=added>   |+------------+    '       '    '|    +-------+    ||
|        |<-------------------------|Notification|<~~~|       |    ||
| Client |.          .             ||Service |    +-------+    ||
+--------+--+          .           ||                         ||Service     |    |"Bob"  |    ||
|        |<----------------------|
+--------+                         ||            |    +-------+----+|
|+------------+                  | Client |NOTIFY <"Bob"="added">|+------------+                  |
+--------+
+--------------------------------+
Figure 12: Client Creation of a Sidebar Conference

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"

Figure 9: Client Manipulation of Conference - Add to
be involved in the sidebar, thus she manipulates the membership.
"Alice" also only wants the video from the original conference and
wants the audio to be restricted to the participants in the sidebar.
Alternatively, "Alice" could manipulate the media values to recieve
the audio from the main conference at a party 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 conference control protocol request to "add" a
party ("Bob") in update the specific
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 determine validate the
updated information in the reservation, ensuring whether members like
"Bob" is 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 Conference
User Identifier
conference user identifier is created for Bob. Based upon the
addressing information provided for "Bob" by "Alice", the call signaling to add
"Bob" to the conference is instigated through the Focus.

Once the call signaling indicates that "Bob" has been successfully
added to the specific conference, per updates to the state, and
depending upon the policies, other participants (including "Bob") may
be notified of the addition of "Bob" to the conference via the

9.3.  Media Manipulations

There are different ways to manipulate the media in a conference.  A
participant can change its own media streams by, for example, sending
re-INVITE with new SDP content using SIP only.  This kind of
operations is called "1st party signaling" and they do not affect the
state of other participants in the conference.

In order "Alice", the call
signaling to perform richer conference control a user client needs add "Bob" to
implement a conference control protocol client.  By using a the conference control protocol, is instigated through the client can manipulate
Focus.

Depending upon the state of
various resources, such as media mixers, which may indirectly affect policies, the state of any participants in the sidebar (i.e.,
"Bob") may be notified of his addition to the sidebar via the
conference participants. notification service.

9.4.2.  External Sidebar

Figure 10 13 provides an example of one client "Alice" impacting the
media state of another client "Bob".  This example assumes involved in an
established conference.  In this example, the client,
active conference with "Bob", "Carol", "David" and "Ethel".  "Alice" whose
Role is "moderator" of the conference, wants
gets an important text message via a whisper from "Bob" that a
critical customer needs to mute talk to "Alice", "Bob" on and "Ethel".
"Alice" creates a
medium-size multi-party conference, as his device is not muted (and
he's obviously not listening sidebar to have a side discussion with the call) customer
"Frank" including the participants in the current conference with the
exception of "Carol" and background noise "David", who remain in his
office environment is disruptive to 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   Conferencing System          |
|                  +---------+--+|
|                  |policies |  ||
|                  +---------+  ||
|                  |Active      ||
|                  |Conference  ||
"Alice"                            |                  +-------+    ||
+--------+                         |                  |"Alice"|    ||
|        |CCP Req <createSidebar,  |                  +-------+    ||
|        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
| Client |-------------------------->|Conference |    +-------+    ||
|        |    confUserID>          | |Control    |~~~>|"Carol"|    ||
|        |<--------------------------|Server     |    +-------+    ||
|
"Alice"        |CCP Response             |                  +---------+--+| |           |    |"David"|    ||
+--------+  <sidebarResvConfObjID, | |           |    +-------+    ||
confID>     | |           |    |"Ethel"|    ||
| |           |    +-------+----+|
| |           |           |      |
| |           |           V      |
| |           |    +---------+--+|
| |           |    |policies |  ||
| |           |~~~>+---------+  ||
| +-----------+    |            ||
"Alice"                           |                  | Sidebar    ||
+--------+                         |                  | Reservation||
|        |CCP Request < <update,     | +-----------+    +---------+    |            ||
| Client |-------------------------->|Conference        |    |Active    sidebarResvConfObjID,| |           |    |            ||
| Client |-------------------------->|           |~~~>|            ||
|        |  Conference Object ID,  confID,confUserID,     | |           |    +------------+|
|        |  video=sidebar,         | |           |           |      |
|        |  audio=sidebar>         | |Conference |           |      |
|        |                         | |Control    |~~~>|Conference    |           V      |
|        |                         | |Server     |    +---------+--+|
|        |CCP Response             | |           |    |policies |  ||
|        |    <activeSideConfObjID,| |           |    +---------+  ||
|        |<--------------------------|           |    |Active      ||
+--------+  Mute, "Bob" >    confID>              | |Server |           |    |Sidebar     ||
| |           |    |Conference  ||
| +-----------+    +-------+    ||
|                  |"Alice"|    ||
"Bob"                            |                  '       '    '|                  +-------+    ||
+--------+  NOTIFY <"Bob"=mute"> <"Bob"=added,   |+------------+    '       '    '|    |"Bob"  |        |<-------------------------|Notification|<~~~|    ||
| Client |.          . |<-------------------------|Notification|<~~~+-------+    ||
+--------+         "Ethel"=added,  ||Service     |    +-------+    |"Ethel"|    ||
+--------+--+          .
"Fred"=added,>  ||            |    |"Bob"  |    +-------+    ||
"Ethel"                       +---|            |        |<----------------------|    |"Fred" |    ||
+--------+  NOTIFY <"Bob"=added,|  |+------------+    +-------+----+|
| Client |  NOTIFY <"Bob"=mute">|+------------+                  |
+--------+ <--------------------+  +--------------------------------+

Figure 10: 13: Client Manipulation Creation of Conference - Mute a party an External Sidebar

Upon receipt of the Conference Control Protocol request to "mute" "reserve"
a
party ("Bob") new sidebar conference, based upon the active conference received
in the specific 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 as identified by ID
and the conference object ID, the Conference Server ensures that "Alice" has
the appropriate authority based on the policies ID associated with that
specific conference object to perform the operation.  "Bob's" status
is marked as "recvonly" and sidebar reservation
through the Conference Template conference instance.

Upon receipt of the Conference
Object (if included) is updated to reflect that "Bob's" media is not conference control protocol response to be "mixed" with reserve
the conference, "Alice" can now create an active conference media.

Depending using
that reservation or create additional reservations based upon the policies, other participants (including "Bob") may
be notified of
existing reservations.  In this change via example, "Alice" wants only "Bob" and
"Ethel", along with the Conference Notification Service.

9.4.  Sidebar Manipulations

A sidebar can new participant "Fred" to be viewed as a separate Conference instance involved in the
sidebar, thus she manipulates the membership.  "Alice" sets the media
such that only
exists within the context of a parent conference instance.  Although
viewed as an independent conference instance, it can not exist
without a parent.  A participants in the sidebar is created using don't receive any media
from the same mechanisms
employed for main conference.  "Alice" sends a standard conference as described in Section 7.1.

A conference object representing a sidebar is created by cloning control
protocol request to update the
parent associated with information in the existing conference reservation and updating any
information specific to
create an active conference.

Upon receipt of the sidebar.  A sidebar conference object is
implicitly linked control protocol request to update the parent conference object (i.e. it is not an
independent object)
reservation and is associated with to create an active conference for the sidebar, as
identified by the parent conference object identifier as as shown in Figure 11.  A ID, the conferencing system
manages and enforces
ensures that "Alice" has the parent and appropriate localized
restrictions authority based on the sidebar
policies associated with that specific conference object (e.g., no members from
outside to perform
the parent conference instance can join, sidebar conference
can not exist if parent conference is terminated, etc.).

+--------------+
|  Conference  |
|    Object    |
|  Identifier  |
+--------------+
|
|
|
+---------------------+---------------------+
|                     |                     |
+-------+-------+     +-------+-------+     +-------+-------+
|    Sidebar    |     |    Sidebar    |     |    Sidebar    |
|  Conference   |     |  Conference   |     |  Conference   |
|    Object     |     |    Object     |     |    Object     |
|  Identifier   |     |   Identifier  |     |   Identifier  |
+-------+-------+     +-------+-------+     +---------------+

Figure 11: Conference Object Mapping.

Figure 11 illustrates operation.  The conferencing system must also validate the relationship between
updated information in the reservation, ensuring whether members like
"Fred" are already a conference object
and associated Sidebar conference objects within user of this conferencing system or whether he
is a new user.  Since "Fred" is a new user for this conferencing
system.  Each Sidebar conference object has
system, a unique conference
object Identifier as described in Section 6.2.1.  The main conference
object identifier acts as a top level user identifier is created for associated
sidebars.

A sidebar conference object Identifier follows many of "Fred".  Based
upon the concepts
outlined in addressing information provided for "Fred" by "Alice", the
call signaling to add "Fred" to the cloning tree model described in Section 7.1.  A
Sidebar conference object contains a subset of members from is instigated through
the
original Conference object.  Properties 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

9.5.  Floor control using sidebars

Floor control with sidebars can be manipulated by a Conference Control Protocol
(Section 8.3) using used to realize conferencing
scenario such as an analyst briefing.  In this scenario, the unique
conference object identifier for call has a panel of speakers who are allowed to talk in
the
sidebar.  It is also possible for main conference.  The other participants are the top level conference object analysts, who
are not allowed to speak unless they have the floor.  To request
enforce policy on the floor, they have to join a new sidebar object (similar with the
moderator and ask their question.  The moderator can also whisper to parent enforceable
as discussed
each analyst what their status/position in the floor control queue,
similar to the example in Section 7.1). Figure 12 15

Figure 14 provides an example of one client "Alice" the configuration involved for this
type of conference.  As in
active 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 "Carol".  "Alice" wants to create a "A3"
representing the analysts.  The sidebar to have 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 side discussion
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 "Bob" the active sidebar conference through the conference instance.
The analysts are permanently muted while still viewing the
video associated with in the main conference.  "Alice" initiates  The
analysts are moved to the sidebar by sending a request when they wish to speak.  Only one
analyst is given the conferencing system to create floor at a
conference reservation based upon given time.  All participants in the active
sidebar conference object. receive audio from the main conference.

+--------------------------------+
|   Conferencing System          |
|                  +---------+--+|
|                  |policies |  ||
|                  +---------+  ||
|                  |Active      ||
|                  |Conference  ||
"Alice"
|                  +-------+    ||
+--------+
|                  |"Alice"|    ||
|        |CCP Req <createSidebar,  |                  +-------+    ||
|        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
| Client |-------------------------->|Conference |Conference |    +-------+    ||
| |Control    |~~~>|"A1"   |    confUserID>    ||
| |Control    |~~~>|"Carol"| |Server     |    +-------+    ||
|        |<--------------------------|Server |    +-------+----+|           |        |CCP Response    |"A2"   |    ||
| |           |    +-------+    ||
| |
+--------+  <sidebarResvConfObjID,           |    |"A3"   |    ||
| |           |    +-------+----+|
| |           |           |      |
confID>
| |           |           V      |
| |           |    +---------+--+|
| |           |    |policies |  ||
| |           |~~~>+---------+  ||
| |           |    |    |Active      ||
| +-----------+    |    |Sidebar     ||
"Alice"                           |
"A1"                             | Sidebar                  |Conference  ||
+--------+                         |                  | Reservation||
|        |CCP  Floor Request <update,     | +-----------+    | <"A1",   |+------------+    +-------+    ||
|        |------------------------->|Floor Ctrl  |    sidebarResvConfObjID,| |           |    |    |"Carol"|    ||
|Client  | Client |-------------------------->|     activeSideConfObjID,||Server      |~~~>|            ||
|        |  confID,confUserID,     | |           |    +------------+|
|        |  video=parent,          | |           |           |      |
|        |  audio=sidebar>         | |Conference |           |       |    ||
+--------+     confID    >         ||            |    +-------+----+|
|+------------+           |      | |Control
|                         V      |
|        |                         | |Server     |                  +---------+--+|
|        |CCP Response             | |           |                  |policies |  ||
|        |    <activeSideConfObjID,| |           |                  +---------+  ||
|        |<--------------------------|           |                  |Active      ||
+--------+    confID>              | |
|                  |Sidebar     ||
| |
"A1"                             |                  |Conference  ||
| +-----------+    +-------+    ||
|                  |"Alice"|    ||
"Bob"                            |                  |       |    ||
+--------+  NOTIFY <"Bob"=added> Floor Granted <"A1",    |+------------+    +-------+    ||
|        |<-------------------------|Notification|<~~~|       |        |<-------------------------|Floor Ctrl  |<~~~|"Carol"|    ||
| Client |                         ||Service     |    |"Bob"     activeSideConfObjID,||Server      |    +-------+    ||
+--------+     confID    >         ||            |    +-------+----+|
|+------------+    |"A1"   |    ||
|+------------+    +-------+----+|
+--------------------------------+

Figure 12: Client Creation of a Sidebar Conference

Upon receipt of the Conference 14: Floor 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 with sidebars
When "A1" wishes to ask a conference ID question, he sends a Floor Request message
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. floor control server.  Upon receipt of the conference request, the floor
control protocol response to reserve server notifies the conference, moderator, "Alice" can now create an of the active conference using
that reservation or create additional reservations based upon sidebar
conference, whose serving as the
existing reservations.  In floor chair.  Note, that this example, "Alice" wants only "Bob" to
be involved
signaling flow is not shown in the sidebar, thus she manipulates the membership.
Alice also only wants diagram.  Since no other analysts
have yet requested the video from floor, "Alice" indicates to the original conference and
wants floor control
server that "A1" may be granted the audio to floor.

9.6.  Whispering or Private Messages

The case of private messages can be restricted handled as a sidebar with just
two participants, similar to the participants example in section Section 9.4.1,
but rather than using audio within the sidebar.
Alice sends a conference control protocol request sidebar, "Alice" could add an
additional text based media stream to update the
information sidebar.  The other
context, referred to as whisper, in the reservation and this document refers to create an active conference.

Upon receipt
situations involving one time media targetted to specific user(s).
An example of the conference control protocol request a whisper would be an announcement injected only to update the
reservation and to create an active
conference for the sidebar, as
identified by the chair or to a new participant joining a conference.

Figure 15 provides an example of one user "Alice" whose chairing a
fixed length conference object ID, the conferencing system
ensures with "Bob" and "Carol".  The configuration is
such that "Alice" has only the appropriate authority based on chair is providing a warning when there is only 10
minutes left in the
policies associated with conference.  At that specific conference object to perform time, "Alice" is moved into
a sidebar created by the operation.  The conferencing system must also validate the
updated information in and only "Alice"

+--------------------------------+
|   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 reservation, ensuring whether members like
"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
conference user identifier is created for Bob. Based upon the
addressing information provided for "Bob" by "Alice", the call
signaling to add "Bob" to the conference determines that there is instigated through the
Focus.

Depending upon the policies, the participants only 10 minutes
left in the sidebar (i.e.,
"Bob") may be notified of his addition to the sidebar via the conference notification service.

9.5.  Whispering or Private Messages

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
rather than using audio within the sidebar, which "Alice" could add an
additional text based media stream to the sidebar.  The other
context, referred to as whisper, in this document refers to
situations such as when a announcement server injects a message
targetted to specific user(s).  The details of this mechanism within
the context of the framework are TBD.

9.6.  Conference Announcements and Recordings

Each participant can require a different type of announcement and/or
recording service from the system.  For example, "Alice", the
conference chair, could be listening to a roll call while "Bob" may
be using a telephony user interface to create a sidebar.  Some
announcements would apply to all the participants such as "This
conference will end in 10 minutes".  Recording is often required to
capture the names of participants as they join a conference,
typically after the participant has entered an access code chairing, rather than
creating a reservation as
discussed was done for the sidebar in Section 9.7.  These recorded names are then announced to
all the participants as 9.4.1,
the new participant is added to conferencing system directly creates an active sidebar
conference, based on the active
conference.

An example of conference recording and announcements, along associated with
monitoring for DTMF, within "Alice".
As discussed previously, the context of this framework, sidebar conference is shown
in figure [TBD].

9.7.  Monitoring for DTMF NOT independent of
the active conference (i.e., parent).  The conferencing system also needs the capability
allocates a conference ID to monitor for DTMF
from each individual participant.  This would typically be used to
enter the identifier and/or access code for joining a specific
conference.

An example any subsequent manipulations
of DTMF monitoring, within the context of sidebar conference.  The conferencing system maintains the
mapping between this framework,
is shown in figure [TBD] in conference ID and the previous section.

9.8.  Observing a Conference

The capability to observe a conference allows a participant object ID
associated with the
appropriate authority to listen to active sidebar conference through the conference
instance.

Immediately upon creation of the conference, typically without
being an active participant and often as a hidden participant.  When
such a capability is available on a conferencing system, there is
often an sidebar conference, the
announcement media is provided to each participant as they join the
conference indicating "Alice".  Depending upon the call
policies, Alice may be monitored.  This capability is
useful in the context notified of conferences which might be experiencing
technical difficulties, thus allowing a technician to listen in her addition to
evaluate the type of problem.  This capability could also apply to
call center applications as it provides a mechanism for a supervisor sidebar via
the conference notification service.  "Alice" continues to observe how receive
the agent is handling a particular call.  Whether media from the
agent is aware main conference.

Upon completion of when the supervisor joins announcement, "Alice" is removed from the call should be
configurable.

An example of oberving a
siebar and the sidebar conference is shown in figure [TBD].

10.  Relationships between SIPPING and Centralized Conferencing
Frameworks

The SIPPING Conferencing Framework [9] provides an overview of a wide
range deleted.  Depending upon the
policies, "Alice" may be notified of centralized conferencing solutions known today in her removal from the
conferencing industry.  The document introduces a terminology and
logical entities in order to systemize sidebar via
the overview conference notification service.

9.7.  Conference Announcements and to show the
common core of many Recordings

Each participant can require a different type of these systems.  The logical entities and announcement and/or
recording service from the
listed scenarios in system.  For example, "Alice", the SIPPING Conferencing Framework are being used
conference chair, could be listening to illustrate how SIP [4] can a roll call while "Bob" may
be used as using a signaling means in these
conferencing systems.  SIPPING Conferencing Framework does not define
new conference control protocols telephony user interface to be used by the general
conferencing system.  It uses only basic SIP [4], the SIP
Conferencing for User Agents [15], and the SIPPING Conference Package
[9] for basic SIP conferencing realization.

This centralized conferencing framework document defines create a particular
centralized conferencing system and sidebar.  Some
announcements would apply to all the logical entities implementing
it.  It also defines a particular data model and refers participants such as "This
conference will end in 10 minutes".  Recording is often required to
capture the names of participants as they join a conference,
typically after the participant has entered an access code as
discussed in Section 9.8.  These recorded names are then announced to
all the set of
protocols (beyond call signaling means) being defined by participants as the XCON WG new participant is added to be used among the logical entities for implementing advanced
conferencing features.  The purpose active
conference.

An example of the XCON working group a conferencing recording and announcement , along with
collecting the DTMF, within the context of this framework framework, is shown
in Figure 16.

+--------------------------------+
|   Conferencing System          |
"Alice"                              | +-----------+                  |
+--------+                            | |Conference |                  |
|        |CCP Request <               | |Control    |                  |
| Client |--------------------------->| |Server     |                  |
|        |Bob's Conference ID,        | |           |                  |
+--------+ Join >                     | |           |                  |
| |           |                  |
| ~           ~                  |
~~~Announcement provided to achieve interoperability between the logical
entities "Alice"~~~
~~~ Digits collected from different vendors for controlling different aspects of

The logical entities defined in the two frameworks are not intended  "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 be mapped one-to-one.  The two frameworks differ in the
interpretation All Parties~~~
|                                |
+--------------------------------+

Figure 16: Recording and Announcements

Upon receipt of the internal Conference Control Protocol request from "Alice"
to join "Bob's" conference, the conferencing system decomposition and
the corresponding operations.  Nevertheless, the basic SIP [4], maps the
SIP Conferencing for User Agents [15], and
identifier received in the SIPPING Conference
Package [9] are fully compatible with both Framework documents.

11.  Security Considerations

There are a wide variety of potential attacks related to
conferencing, due request to the natural involvement of multiple endpoints
and the many, often user-invoked, capabilities provided by the conference object
representing "Bob's" active conference.  The conferencing system.  Examples of attacks include the following: system
determines that a password is required for this specific conference,
thus an
endpoint attempting announcement asking "Alice" to listen enter the password is provided
to conferences in which "Alice".  Once "Alice" enters the password, it is not
authorized to participate, an endpoint attempting validated
against the policies associated with "Bob's" active conference.  The
conferencing system then connects to disconnect or
mute other users, a server which prompts and theft of service, by an endpoint, in attempting
to create conferences it
records "Alice's" name.  The conferencing system must also determine
whether "Alice" is not allowed to create.

There are several issues surrounding security already a user of this conferencing
framework.  One set of issues involves securing the actual protocols
and the associated authorization mechanisms.  This first set of
issues should be addressed in the specifications specific to the
protocols described in Section 8.  The protocols used system or
whether she is a new user.

If "Alice" is a new user for
manipulation and retrieval of confidential information MUST support this conferencing system, a
confidentiality and integrity mechanism.  Similar requirements apply conference
user identifier is created for "Alice".  Based upon the floor control protocols.  Section 11.3 discusses an approach
for client authentication of a floor control server.

There are also security issues associated with addressing
information provided by "Alice", the authorization call signaling to
perform actions on the conferencing system add "Alice" to invoke specific
capabilities.  Section 5.3 discusses the policies associated with
the conference object to ensure is instigated through the Focus.

Once the call signaling indicates that only authorized entities are able "Alice" has been successfully
manipulate the data specific conference, per updates to access the capabilities.  The final set of
issues involves the privacy state, and security of the identity of a user in
depending upon the conference, which is discussed in Section 11.2

11.1.  Authorization

Many policy authorization decisions policies, other participants (e.g., "Bob") are based on
notified of the identity addition of "Alice" to the
user or conference via the role that a user may have.  There are several ways that a
user might authenticate its identity
conference notification service and an announcement is provided to
all the system. participants indicating that "Alice" has joined the
conference.

9.8.  Monitoring for DTMF

The conferencing system may know about specific users and assign passwords to the
users.  The users may also be authenticated by knowing a particular
conference ID and a PIN for it.  Sometimes, a PIN is not required and needs the conference ID is capability to monitor for DTMF
from each individual participant.  This would typically be used as a shared secret.  The call signaling
means can provide to
enter the identifier and/or access code for joining a trusted form specific
conference.

An example of DTMF monitoring, within the user identity or it might
just provide a hint context of the possible identity framework
elements, is shown in Figure 16.

9.9.  Observing and Coaching

The capability to observe a conference allows a participant with the user still needs
appropriate authority to provide some authentication listen to prove it has the identity that was
provided conference, typically without
being an active participant and often as a hint in hidden participant.  When
such a capability is available on a conferencing system, there is
often an announcement provided to each participant as they join the
conference indicating the call signaling.  This may be monitored.  This capability is
useful in the form context of
an IVR system or other means.  The goal for conferences which might be experiencing
technical difficulties, thus allowing a technician to listen in to
evaluate the conferencing system
is type of problem.

This capability could also apply to figure out a user identity and call center applications as it
provides a role mechanism for any attempt a supervisor to send observe how the agent is
handling a
request particular call with a customer.  This scenario can be
handled by by supervisor adding themselves to the conferencing system.

When existing active
conference, with a conferencing system presents listen only audio media path.  Whether the identity agent
is aware of authorized users,
it may choose to provide information about when the way supervisor joins the identity was
proven or verified by call should be
configurable.

Taking the system.  A user may also come 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
completely unauthenticated user into sidebar involving the agent and the
supervisor.  Both the agent and supervisor receive the system - this fact needs
also be communicated to interested parties. audio from the
main conference.  When guest users interact with the system, agent speaks, it is often heard by the customer
in the context
of a particular main conference.  In this case,  When the user may provide a PIN
or a password that supervisor speaks, it is specific to the conferences and authenticates heard only
by the user to take on a certain role agent in that the sidebar conference.  The guest
user can then perform actions that are allowed to any user with that
role.

An example of observing and coachin is used to mean the usual, that shown in figure Figure 17.  In
this example, call center agent "Bob" is to say a
reasonable sized, involved in number of bits, hard to predict shared secret.
Today users often have passwords a conference
with more than 30 bits of randomness
in them.  PIN customer "Carol".  Since "Bob" is a special password case - a shared secret new agent and "Alice" sees
that is
only numeric he has been on the call with "Carol" for longer than normal, she
decides to observe the call and often contains 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 fairly small number of bits (often
as few as 10 bits).  When conferencing systems are used Sidebar for audio on
the PSTN, there is often a need to authenticate using a PIN.
Typically if the user fails to provide the correct PIN a few times in
a row, the PSTN call is disconnected.  The rate Observing/Coaching

Upon receipt of making the calls
and getting to the point to enter a PIN makes it fairly hard Conference Control Protocol request from "Alice"
to do an
exhaustive search of the PIN space even for 4 digit PINs.  When using "reserve" a high speed interface to connect 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, it is
often possible system also reserves or allocates a
conference ID to do thousands of attempts per second and the PIN
space could quickly be searched.  Because of this, it is not
appropriate to use PINs used for authorization on any subsequent protocol requests from
any of the interfaces
that provide fast queries or many simultaneous queries.

11.2.  Security and Privacy members of Identity

This the conference.  The conferencing system has an idea of
maintains the identity of a user but mapping between this does not mean it 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 reveal now create an active conference using
that reservation or create additional reservations based upon the
existing reservations.  In this identity example, "Alice" wants only "Bob" to other users, due
be involved in the sidebar, thus she manipulates the membership.
"Alice" also wants the audio to
privacy considerations.  Users can select various options for
revealing their identity be received by herself and "Bob" from
the original conference, but wants any outgoing audio from herself to other users.  A user can
be "hidden" such
that other users can not see they are restricted to the participants in the sidebar, whereas "Bob's"
outgoing audio should go to the main conference,
or they can be "anonymous" such that users can see so that another user
is there, but not see both "Alice"
and the customer "Carol" hear the same audio from "Bob".  "Alice"
sends a conference control protocol request to update the identity information
in the reservation and to create an active conference.

Upon receipt of the user, or they can be
"public" where other users can see their identity.  If there are
multiple "anonymous" users, other parties will be able conference control protocol request to see them as
independent "anonymous" parties update the
reservation and will be able to tell how many
"anonymous" parties are in create an active conference for the conference.  Note, sidebar, as
identified by the conference object ID, the conferencing system
ensures that "Alice" has the visibility
to other participants is dependent appropriate authority based on their roles.  For example,
users' visibility (including "anonymous" and "hidden") may be
displayed the
policies associated with that specific conference object to perform
the moderator or administrator, subject operation.  Based upon the addressing information provided for
"Bob" by "Alice", the call signaling to a
conferencing system's local policies.  "Hidden" status add "Bob" to the sidebar with
the appropriate media characteristics is often used
by automated or machine participants instigated through the
Focus.

"Bob" is notified of a his addition to the sidebar via the conference (e.g., call
recording) and
notification service, thus he is also used in many call center situations.

11.3.  Floor Control Server Authentication

Clients can authenticate a floor control server using aware that "Alice" the TLS
certificates.  Requests submitted on a successfully created
connection supervisor is
available for coaching him through this call.

10.  Relationships between the client SIPPING and floor control server may
additionally require digest authentication within Centralized Conferencing
Frameworks

The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the BFCP protocol
conferencing industry.  The document introduces a terminology and
logical entities in order to authenticate systemize the floor control client overview and to show the server.  For this
common core of many of these systems.  The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used
to
take place, illustrate how SIP [4] can be used as a shared secret needs signaling means in these
conferencing systems.  SIPPING Conferencing Framework does not define
new conference control protocols to be exchanged between used by the floor
control client/server entities.  This can be achieved out of band
using a mechanism such as general
conferencing system.  It uses only basic SIP [4], the 'k=' SDP attribute.  The shared secret
can also be exchanged using un-specified 'out of band' mechanisms.

When using Digest authentication of floor control client messages SIP
Conferencing for User Agents [14], and the
exchange of an active 'Nonce' is also required. SIPPING Conference Package
[9] for basic SIP conferencing realization.

This can be achieved
using centralized conferencing framework document defines a BFCP request response interaction as defined in BFCP (A
request is submitted without particular
centralized conferencing system and the logical entities implementing
it.  It also defines a Nonce TLV particular data model and refers to the server generates an
error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing set of
protocols (beyond call signaling means) being defined by the valid nonce).  The BFCP 'Nonce' value
can also XCON WG
to be obtained 'out of band' using information provided in used among the
offer/answer exchange.  As with logical entities for implementing advanced
conferencing features.  The purpose of the other SDP Floor attributes
referenced in this section XCON working group and
this framework is to achieve interoperability between the logical
entities from different vendors for controlling different aspects of

The logical entities defined in [23], the 'nonce' attribute
can two frameworks are not intended
to be inserted mapped one-to-one.  The two frameworks differ in the SIP response e.g., a=nonce:dhsa8hd0dwqj.

[Editor's Note: May need more specifics on fetching from
interpretation of the
conference object internal conferencing system decomposition and
the credentials required for BFCP.  This includes corresponding operations.  Nevertheless, the conference id, user id, basic SIP [4], the
SIP Conferencing for User Agents [14], and password.]

12.  IANA Considerations

This is an informational draft, the SIPPING Conference
Package [9] are fully compatible with no IANA considerations required.

13.  Acknowledgements

This document is both Framework documents.

11.  Security Considerations

There are a result wide variety of architectural discussions among IETF
XCON working group participants.  The authors would like potential attacks related to
conferencing, due to thank
Henning Schulzrinne for the "Conference Object Tree" proposal natural involvement of multiple endpoints
and
general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri and Sean Olson for
their reviews and constructive input.

14.  Changes since last Version

Changes from WG 03 many, often user-invoked, capabilities provided by the
conferencing system.  Examples of attacks include the following: an
endpoint attempting to 04:

- Editorial nits listen to conferences in which it is not
authorized to participate, an endpoint attempting to disconnect or
mute other users, and clarifications.

- Section 4.  Template: Removed reference theft of service, by an endpoint, in attempting
to "user interface
abstractions".

- Section 5.2.  Conference Template: deleted references create conferences it is not allowed to user
interface abstraction (1st paragraph, last phrase create.

There are several issues surrounding security of this conferencing
framework.  One set of issues involves securing the actual protocols
and 4th paragraph).

- the associated authorization mechanisms.  This first set of
issues should be addressed in the specifications specific to the
protocols described in Section 9.6.  Conference Announcements 8.  The protocols used for
manipulation and Recording: text
expanded.  Moved discussion retrieval of DTMF to confidential information MUST support a new section.

- Added two new sections 9.7 (DTMF)
confidentiality and 9.8 (Observing integrity mechanism.  Similar requirements apply
for the floor control protocols.  Section 11.3 discusses an approach
for client authentication of a Conference), floor control server.

There are also security issues associated with some initial text.

Changes from WG 02 the authorization to 03:

- Updated
perform actions on the definition of Blueprint (per DP 4/4.1 discussions)

- Added definition for Sidebar.

- conferencing system to invoke specific
capabilities.  Section 5.2 Added text indicating discusses the policies associated with the
conference object to ensure that adding new elements or
modifying elements requires only authorized entities are able to
manipulate the definition data to access the capabilities.  The final set of
issues involves the privacy and security of the identity of a new template. (per
DP4.2 conclusion).

- user in
the conference, which is discussed in Section 7.3.  Added text reiterating 11.2

11.1.  Authorization

Many policy authorization decisions are based on the identity of the
user or the role that a user may have.  There are several ways that a
user might authenticate its identity to the blueprint comprises
both system.  The conferencing
system may know about specific users and assign passwords to the common
users.  The users may also be authenticated by knowing a particular
conference information ID and a template (per DP4/4.1
discussions.

- Section 7.3.  Added text per resolution of DP 4.3 indicating that PIN for it.  Sometimes, a
blueprint PIN is common conference information + one template not required and that
multiple templates is FFS.

- Section 8.3 - Updated Conference Control Protocol section to
include
the protocols on the table for WG discussion conference ID is used as a shared secret.  The call signaling
means can provide a trusted form of 31 Dec

- Section 9.4 - Sidebars - added Ascii art to show FW interactions

- Section 9.5 - Whisper - Added some text, reflecting past WG
discussions.  Basic definition the user identity or it might
just provide a hint of the possible identity and further details/example the user still
needed.

- Section 9.6 - Conf Anncs and Recordings - Added needs
to provide some basic text.
Further details/example still needed.

Changes from WG 01 authentication to 02:

- Editorial nits -i.e. consistent terminology, capatilization, etc.

- Revamped abstract prove it has the identity that was
provided as a hint in the call signaling.  This may be in the form of
an IVR system or other means.  The goal for the conferencing system
is to figure out a user identity and introduction

- Global removal a role for any attempt to send a
request to the conferencing system.

When a conferencing system presents the identity of XCON authorized users,
it may choose to provide information about the way the identity was
proven or verified by the system.  A user may also come as a qualifier (we had previously done
completely unauthenticated user into the system - this
in a previous version fact needs
also be communicated to interested parties.

When guest users interact with all the identifiers).

- Global change system, it is often in the context
of "call control signalling" a particular conference.  In this case, the user may provide a PIN
or a password that is specific to "call signaling"

- Moved the terminology section after conferences and authenticates
the Overview section:

- - Modified user to take on a certain role in that conference.  The guest
user can then perform actions that are allowed to any user with that
role.

The term password is used to mean the definitions usual, that is to be say a
reasonable sized, in number of bits, hard to predict shared secret.
Today users often have passwords with more concise and per some than 30 bits of
Henning's recommendations.

- randomness
in them.  PIN is a special password case - Added definitions for blueprint a shared secret that is
only numeric and conference reservation.

- Clarified the definition often contains a fairly small number of policy and added more explicit text bits (often
as few as 10 bits).  When conferencing systems are used for audio on
the PSTN, there is often a need to how policy authenticate using a PIN.
Typically if the user fails to provide the correct PIN a few times in
a row, the PSTN call is accomplished via disconnected.  The rate of making the data model and system
realization (section 4.3 calls
and 6.1)

- Removed getting to the Editor's note/text in section 4 about point to enter a PIN makes it fairly hard to do an
exhaustive search of the options PIN space even for
the schema; added 4 digit PINs.  When using
a reference high speed interface to connect to a TBD schema document.

- Section 5:

- - clarified the identifiers.  Kept conferencing system, it is
often possible to do thousands of attempts per second and the logical definition as
"identifiers", although most will PIN
space could quickly be realized as URIs.

- - deleted the section searched.  Because of this, it is not
appropriate to use PINs for authorization on conference instance.

- - removed any of the term "umbrella" from sections conference User interfaces
that provide fast queries or many simultaneous queries.

11.2.  Security and
conference object identifier sections

- - moved alot Privacy of Identity

This conferencing system has an idea of detail from Conference User Identifier and
conference Object Identifier sections into appendices, and added
additional detail, that will become the basis for separate documents.

- In section 6:

- - added a bit identity of explanation as a user but
this does not mean it can reveal this identity to other users, due to
privacy considerations.  Users can select various options for
revealing their identity to other users.  A user can be "hidden" such
that other users can not see they are participants in the conference,
or they can be "anonymous" such that users can see that another user
is there, but not see the intent identity of the cloning tree
model - it's not implementation binding, but rather user, or they can be
"public" where other users can see their identity.  If there are
multiple "anonymous" users, other parties will be able to illustrate the
data model see them as
independent "anonymous" parties and context for will be able to tell how many
"anonymous" parties are in the protocol interactions.

- - removed conference.  Note, that the term copying altogether.  Cloning visibility
to other participants is the model dependent on their roles.  For example,
users' visibility (including "anonymous" and
the idea is that the cloned object contains data indentical "hidden") may be
displayed to the
parent when it was created (whether it gets "copied" moderator or whatever from
the parent is an implementation issue).

- - introduce the blueprint concept in section 6.1 prior administrator, subject to its
implied usage in 6.2 and 6.3.

- - removed the usage of the term occurrence (which a
conferencing system's local policies.  "Hidden" status is just often used
by automated or machine participants of a child
reservation).

- Removed security related details from Floor Control section conference (e.g., call
recording) and
moved those to the security section.  As a result removed most of the
editorial notes from the front of the is also used in many call center situations.

11.3.  Floor control section and
integrated the remaining ones inline into that section, where the
resolution should be documented.

- Section 8:

- - Added new example 8.1 - conference creation

- - Added a placeholder for a more detailed example to Control Server Authentication

Clients can authenticate a floor control server using the sidebar
section to show TLS
certificates.  Requests submitted on a sidebar which has some media specifically
associated with successfully created
connection between the sidebar (i.e. audio), yet still use client and floor control server may
additionally require digest authentication within the main
conference for other media (visual presentation).

- Section 11: As a result of adding additional information BFCP protocol
to authenticate the floor control client to the
security section, divided server.  For this section into subsections for clarity.

Changes from WG 00 to 01::

- Section 2 (Conventions and Terminology).  Slight modifications
take place, a shared secret needs to
definitions be exchanged between the floor
control client/server entities.  This can be achieved out of Call (control) signaling, Conference Identifer,
Conference Instance, Conference Object.

- Section 2 (Conventions and Terminology).Renaming band
using a mechanism such as the 'k=' SDP attribute.  The shared secret
can also be exchanged using un-specified 'out of term
"Registered Template Definition" to "Registered Conference Document"
(per agreement at interim meeting).

- Section 3 (Next to band' mechanisms.
When using Digest authentication of floor control client messages the last paragraph on
exchange of an active 'Nonce' is also required.  This can be achieved
using a BFCP request response interaction as defined in BFCP (A
request is submitted without a Nonce TLV and the media model).
Clarified server generates an
error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing the text such that it doesn't read that valid nonce).  The BFCP 'Nonce' value
can also be obtained 'out of band' using information provided in the focus performs
media mixing.  Changed "focus" to "media mixer controlled by
offer/answer exchange.  As with the
focus" other SDP Floor attributes
referenced in the 2nd sentence this section and "performed" to "controlled" defined in [17], the
4th.

- Section 5.  Rearranged the sub-sections a bit for better flow.
First describe the Conference ID, then the Conference Instance,
followed by 'nonce' attribute
can be inserted in the Conference Object, SIP response e.g., a=nonce:dhsa8hd0dwqj.

12.  IANA Considerations

This is an informational draft, with the Conference Object
Identifer described in no IANA considerations required.

13.  Acknowledgements

This document is a subsection result of architectural discussions among IETF
XCON working group participants.  The authors would like to thank
Henning Schulzrinne for the Conference "Conference Object section.
Added a diagram showing the relationship between Conference
Identifer/Focus Tree" proposal and Conference Object Identifier, within
general feedback, Cullen Jennings for providing input for the context
of a Conference Instance
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson and Rohan
Mahy for their reviews and constructive input.

14.  Changes since last Version

NOTE TO THE RFC-Editor: Please remove this section prior to the Conference Object section.

- Section 6.1 (Cloning Tree).  Rewording
publication as an RFC.

Changes from WG 04 to clarify which operations
apply 05:

1) Removed all references to independent objects (and non-independent).

- "Conference Template":

to future conferences, introducing the concept of infinite series
(which would be limited by calendaring interface). 4:

- Section 7.3 (Conference Control Protocol). Updated to include
reference to SOAP option.

- Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit
about the XCON FW constructs used.

Changes "Common Conference Information" definition, merging details
from individual 02 to WG 00: "Conference Template" definition, which was removed.

- few minor editorial changes In definition of "conference blueprint"

- Section 2.  Removed second sentence In definition of "conference object"

- Removed definition of Conference ID,
as that's now included/described "Registered conference document"

Section 5:

- 1st paragraph.  Reworded.

- Figure2: added "boxes" for all the data listed in context the Conference
Template type in new Identifier
section. the diagram.

- Section 3.  Clarified that TBD in Paragraph following Figure 1 is "Conference Control
Protocol" (per Keith's comment 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 be more explicit). 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 4.1.  Identifiers.  Moved this 5, last paragraph, added reference to a new section (
draft-ietf-xcon-common-data-model.

4) Section 6). 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 for Identifiers ( 9.5.  Floor control with sidebars.

7) Section 6), thus all 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 beyond 4 are incremented to these.
The content will be in the new version.

- Section 4.  Since section 4.1 was removed, section 4.2 became the
body text for section 4. separate documents (references TBD).

10) Updated references.  Changed drafts to RFCs as appropriate and
removed unused references.

Changes from WG 03 to 04:

- Editorial nits and clarifications.

- Section 4.2.  Added "Floor Information" 4.  Template: Removed reference to Figure 2 as part of
Common "user interface
abstractions".

- Section 5.2.  Conference Information, also added "Floor Control" Template: deleted references to
Conference Template (per text user
interface abstraction (1st paragraph, last phrase and Cullen's draft). 4th paragraph).

- Section 4.5. 9.6.  Conference policies.  Reworded Announcements and Recording: text
expanded.  Moved discussion of DTMF to not introduce a new
terms, but use the general terms identified in the 1st paragraph.

- Section 5.2.  Removed "Instance" from "Active Conference Instance"
in Figure 4. section.

- Section 5.3. Added text clarifying that templates are retrieved two new sections 9.7 (DTMF) and 9.8 (Observing a Conference),
with some initial text.

Changes from server (not central repository) WG 02 to 03:

- Updated the definition of Blueprint (per DP3 conclusion). DP 4/4.1 discussions)

- Added definition for Sidebar.

- Section 5.4. 5.2 Added text indicating that there is a single time and that the
times are all relative adding new elements or
modifying elements requires the one time definition of a new template. (per DP1
DP4.2 conclusion).

- Section 5.4. 7.3.  Added text clarifying reiterating that changes to the blueprint comprises
both the common conference information and a series impact
"all future occurrences template (per DP1 discussion/conclusion). DP4/4.1
discussions.

- Section 6.3 - 7.3.  Added subsections for discussion text per resolution of CSCP DP 4.3 indicating that a
blueprint is common conference information + one template and NETCONF
as the CCP. that
multiple templates is FFS.

- Section 6.4 8.3 - Floor Control.  Removed Editor's notes 2 and 3.
Condensed the text only slightly, but added explicit references Updated Conference Control Protocol section to
new identifier section.
include the protocols on the table for WG discussion as of 31 Dec

- Section 6.4.1 Moved 9.4 - Sidebars - added Ascii art to new Identifier section ( Section 6) show FW interactions

- Section 7.1 9.5 - moved example to 7.2.  Included a new (more
appropriate example) in 7.1, although this may be too basic. Whisper - Added some text, reflecting past WG
discussions.  Basic definition and further details/example still
needed.

- Section 7.3 9.6 - added Conf Anncs and Recordings - Added some proposed text for Sidebars.

15.  Appendix A basic text.
Further details/example still needed.

Changes from WG 01 to 02:

- Conference Object Identifier

[Editors Note: This appendix will be incorporated in a separate
specification in the next release of this document Editorial nits -i.e. consistent terminology, capatilization, etc.

- Revamped abstract and will include
all relevant detail.]

The conference object URI can be viewed introduction
- Global removal of XCON as a key to accessing a
specific conference object.  It is used by the Conference Control
Protocol as described qualifier (we had previously done this
in Section 8.3 to access, manipulate and delete a conference object associated previous version with a specific conference instance.
A conference object identifier is provided to all the Conference Control
Client to enable such functions identifiers).

- Global change of "call control signalling" to be carried out.  This can either
be returned through the Conference Control Protocol while creating a
conference object, be provided by "call signaling"

- Moved the conference notification service
or through out-of-band mechanisms (e.g.  E-Mail).

[Editors Note: Previous terminology section after the Overview section:

- - Modified the definitions to be expanded and more detail
included.  It also needs to link up with other drafts concise and per some of
Henning's recommendations.

- - Added definitions for blueprint and explicitly
reference.]

A centralized conferencing system, as defined in conference reservation.

- Clarified the Conference
Framework [ref] has potential to expose a range definition of interfaces policy and
protocols.  It is also possible that future centralized conferencing
enhancements might place requirements added more explicit text as
to provide further additional
protocols how policy is accomplished via the data model and interfaces.  A conference object can consist system
realization (section 4.3 and be
associated with many identifiers that are 6.1)

- Removed the Editor's note/text in some way related section 4 about the options for
the schema; added a reference to a
conference object.  Good examples include TBD schema document.

- Section 5:

- - clarified the Binary Floor Control
Protocol (BFCP)[23] and call signaling protocols, such identifiers.  Kept the logical definition as SIP.  Each
use unique identifiers to represent a protocol instance associated
with a
"identifiers", although most will be realized as URIs.

- - deleted the section on conference object.

A conferencing system may maintain a relationship between instance.

- - removed the term "umbrella" from sections conference object URIs User 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 sections

- - moved alot of identifying detail from Conference User Identifier and
conference Object Identifier sections into appendices, and added
additional detail, that will become the interfaces basis for
these other protocols.  This implicit binding provides separate documents.

- In section 6:

- - added a structured
mapping bit of explanation as to the intent of the various protocols with cloning tree
model - it's not implementation binding, but rather to illustrate the associated conference
object identifier.  Figure 13 illustrates
data model and context for the relationship between protocol interactions.

- - removed the identifiers used for term copying altogether.  Cloning is the protocols within this framework model and
the
general conference object identifier.

+--------------+
|  Conference  |
|    Object    |
|  Identifier  |
+------+-------+
|
|
|
+-----------------+---------------+
|                                 |
+-------+---------+               +-------+-------+
|CSP Conference ID|               | BFCP 'confid' |
+-----------------+               +---------------+

Figure 13: Conference Object Mapping.

In Figure 13, idea is that the conference cloned object identifier acts as contains data indentical to the top level
key in
parent when it was created (whether it gets "copied" or whatever from
the identification process.  The call signaling protocols have parent is an associated conference ID representation in implementation issue).

- - introduce the form of URIs.  The
binary floor control protocol, as defined blueprint concept in [23], defines the
'conf-id' identifier which represents a conference instance within
floor control.  When created within section 6.1 prior to its
implied usage in 6.2 and 6.3.

- - removed the conferencing system, usage of the
'conf-id' has term occurrence (which is just a 1:1 mapping child
reservation).

- Removed security related details from Floor Control section and
moved those to the unique conference object
Identifier.  Operations associated with the Conference Control
Protocols are directly associated with security section.  As a result removed most of the conference object, thus
editorial notes from the primary identifier associated with these protocols is front of the
conference object identifier.  The mappings between additional
protocols/interface is not strictly 1:1 Floor control section and does allow for multiple
occurrences.  For example, multiple call signaling protocols will
each have a representation that is implicitly linked to
integrated the top level
conference object identifier, for example, H323 and SIP URIs remaining ones inline into that
represent a conference instance.  It section, where the
resolution should be noted that documented.

- Section 8:

- - Added new example 8.1 - conference creation

- - Added a
conferencing system is free to structure such relationships as
required and this information is just included as placeholder for a guideline that
can be used.

The following more detailed example illustrates to the representation and
relationships that might occur in sidebar
section to show a typical sidebar which has some media specifically
associated with the sidebar (i.e. audio), yet still use the main
conference instance.  The
table in Figure 14 lists for other media (visual presentation).

- Section 11: As 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 result of adding additional 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
security section, divided this section into subsections for clarity.

Changes from WG 00 to the tree representation in Figure 15 01::

- Section 2 (Conventions and Terminology).  Slight modifications to enable a complete representation
definitions of a conference instance within a
conferencing system.

This style Call (control) signaling, Conference Identifer,
Conference Instance, Conference Object.

- Section 2 (Conventions and Terminology).Renaming of association can be applied term
"Registered Template Definition" to any supplementary
protocols or conferencing mechanisms that are applied "Registered Conference Document"
(per agreement at interim meeting).

- Section 3 (Next to the
centralized conferencing model defined in this document as long as a
unique reference per conference instance is available last paragraph on the media model).
Clarified the text such that it doesn't read that can be
mapped to a conference object.

15.1.  Conference Object URI Definition

[Editors Note: When the appendix split from focus performs
media mixing.  Changed "focus" to "media mixer controlled by 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
focus" in the next release of this document 2nd sentence and will include
all relevant detail.]

Each user within a conferencing system is allocated a unique
conference user identifier.  The user identifier is used "performed" to "controlled" in
association with the conference object identifier defined in
4th.

- Section 15, and by 5.  Rearranged the conference control protocol to uniquely
identify sub-sections a user within the scope of conferencing system.  The
conference control protocol uses bit for better flow.
First describe the user identifier to uniquely
determine who is issuing commands.  Appropriate policies can Conference ID, 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 Conference Instance,
followed by the conference user identifier
in association Conference Object, with the user identity defined for BFCP and SIP Digest
user identity as defined Conference Object
Identifer described in RFC3261[4], which would be used when SIP
is a subsection of the call signaling protocol.  It should be noted that Conference Object section.
conferencing system is free to structure such relationships as
required diagram showing the relationship between Conference
Identifer/Focus and this information is just included as Conference Object Identifier, within the context
of a guideline that
can be used.

+---------------+
| Conference   |
|     User      |
|   Identifier  |
+-------+-------+
|
|
|
+---------------+---------------+
|                               |
+-------+-------+               +-------+-------+
|     BFCP      |               |   SIP Digest  |
|   'UserID'    |               |    Username   |
+---------------+               +-------+-------+

Figure 16: Instance to the Conference User Identifier

Within a conferencing system, a user is identified by a single
conference user identifier.  Any Object section.

- Section 6.1 (Cloning Tree).  Rewording to clarify which operations
apply to independent objects (and non-independent).

that contain a protocol specific user ID can be associated text with regards
to future conferences, introducing the
conference user identifier, as illustrated in Figure 16.  This
mechanism allows conferencing systems concept of infinite series
(which would be limited by calendaring interface).

- Section 7.3 (Conference Control Protocol).  Updated to manage and relate system
wide user identities in relation include
reference to specific conference objects and
helps SOAP option.

- Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit
about the XCON FW constructs used.

Changes from individual 02 to WG 00:

- few minor editorial changes

- Section 2.  Removed second sentence of definition of Conference ID,
as that's now included/described in the enforcement of system wide policies.

The following example illustrates the representation and
relationships context in new Identifier
section.

- Section 3.  Clarified that might occur TBD in Figure 1 is "Conference Control
Protocol" (per Keith's comment to be more explicit).

- Section 4.1.  Identifiers.  Moved this to a typical conference instance.  The
table new section (
Section 6).

- New section for Identifiers ( Section 6), thus all section
references beyond 4 are incremented in the new version.

- Section 4.  Since section 4.1 was removed, section 4.2 became the
body text for section 4.

- Section 4.2.  Added "Floor Information" to Figure 17 lists a typical representation 2 as part of user identifier
hierarchy
Common Conference Information, also added "Floor Control" to
Conference Template (per text 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 Cullen's draft).

- Section 4.5.  Conference policies.  Reworded to not introduce new
terms, but use the
representation introduced in Figure 16.  This results general terms identified in Figure 18.

+--------------+
| the 1st paragraph.

- Section 5.2.  Removed "Instance" from "Active Conference  |
|     User     |
|  Identifier  |
+--------------+
|    John      |
+------+-------+
|
|
|
+---------------------+---------------------+
|                     |                     |
+-------+--------+    +-------+-------+    +--------+-------+
|  BFCP User ID  |    |  SIP User ID  |    |  H323 User ID  |
+----------------+    +---------------+    +----------------+
|   HK37ihdaj    |    |    123674     |    |     928373     |
+----------------+    +-------+-------+    +----------------+ Instance"
in Figure 18: User ID Tree Representation

Further elements can be added to 4.

- Section 5.3.  Added text clarifying that templates are retrieved
from server (not central repository) (per DP3 conclusion).

- Section 5.4.  Added text that there is a single time and that the tree representation in Figure 15
times are all relative the one time (per DP1 conclusion).

- Section 5.4.  Added text clarifying that changes to enable a complete representation series impact
"all future occurrences (per DP1 discussion/conclusion).

- Section 6.3 - Added subsections for discussion of a conference instance within a
conferencing system.

16.1.  Conference User Definition

[Editors Note: When CSCP and NETCONF
as the appendix is split from CCP.

- Section 6.4 - Floor Control.  Removed Editor's notes 2 and 3.
Condensed the Framework
document, full definition will text only slightly, but added explicit references to
new identifier section.

- Section 6.4.1 Moved to new Identifier section ( Section 6)

- Section 7.1 - moved example to 7.2.  Included a new (more
appropriate example) in 7.1, although this may be included.

17. too basic.

- Section 7.3 - added some proposed text for Sidebars.

15.  References

17.1.

15.1.  Normative References

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

17.2.

15.2.  Informative References

[2]   Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.

[3]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

[4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

[5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.

[6]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.

[7]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.

[8]   Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.

[9]   Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005. Protocol (SIP)", RFC 4353, February 2006.

[10]  Levin, O. and R. Even, "High Level "High-Level Requirements for Tightly
Coupled SIP Conferencing",
draft-ietf-sipping-conferencing-requirements-01 (work in
progress), October 2004. RFC 4245, November 2005.

[11]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.

[12]  Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-03 (work in progress),
October 2005. Protocols", RFC 4376,
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",
draft-ietf-xcon-conference-scenarios-05 (work in progress),
September 2005.

[15] RFC 4597,
August 2006.

[14]  Levin, O., "Session Initiation Protocol Call Control -
Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005.

[16]

[15]  Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005.

[17]  Schulzrinne, H., "COMP: Conference Object Manipulation
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]

[16]  Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005.

[23]

[17]  Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol  (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00
draft-ietf-mmusic-sdp-bfcp-03 (work in progress),
December 2005.

[18]  Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing  (XCON)",
draft-ietf-xcon-common-data-model-02 (work in progress),
October 2004.

[24]
July 2006.

[19]  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)",
draft-jennings-xcon-cscp-02 (work in progress), December 2005.

[26]  Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-12
draft-ietf-simple-message-sessions-15 (work in progress), March
July 2006.

Mary Barnes
Nortel
2201 Lakeside Blvd
Richardson, TX

Email: mary.barnes@nortel.com

Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales  CF3 5EA

Email: cboulton@ubiquitysoftware.com

Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052

Email: oritl@microsoft.com

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 Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.