draft-ietf-xcon-framework-02.txt   draft-ietf-xcon-framework-03.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: April 4, 2006 C. Boulton Expires: September 2, 2006 C. Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
Oct 2005 Mar 2006
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-02 draft-ietf-xcon-framework-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2006. This Internet-Draft will expire on September 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
a centralized unicast conference. The Centralized Conferencing a centralized unicast conference. The Centralized Conferencing
Framework defines logical entities and naming conventions, along with Framework defines logical entities and naming conventions, along with
a conferencing data model. The framework also outlines a set of a conferencing data model. The framework also outlines a set of
conferencing protocols, which are complementary to the call signaling conferencing protocols, which are complementary to the call signaling
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12 5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 13 6. Centralized Conferencing Constructs and Identifiers . . . . . 13
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15
7. Conferencing System Realization . . . . . . . . . . . . . . . 15 7. Conferencing System Realization . . . . . . . . . . . . . . . 15
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.3.1. CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.3.1. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.2. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.3. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.4. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.5. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 30 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 30 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 32 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 34 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 35 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34
9.5. Whispering or Private Messages . . . . . . . . . . . . . . 37 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38
9.6. Conference Announcements and Recordings . . . . . . . . . 37 9.6. Conference Announcements and Recordings . . . . . . . . . 39
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 39 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 41
11.3. Floor Control Server Authentication . . . . . . . . . . . 40 11.3. Floor Control Server Authentication . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
14. Changes since last Version . . . . . . . . . . . . . . . . . . 40 14. Changes since last Version . . . . . . . . . . . . . . . . . . 43
15. Appendix A - Conference Object Identifier . . . . . . . . . . 44 15. Appendix A - Conference Object Identifier . . . . . . . . . . 47
15.1. Conference Object URI Definition . . . . . . . . . . . . . 47 15.1. Conference Object URI Definition . . . . . . . . . . . . . 50
16. Appendix B - Conference User Identifier . . . . . . . . . . . 47 16. Appendix B - Conference User Identifier . . . . . . . . . . . 50
16.1. Conference User Definition . . . . . . . . . . . . . . . . 49 16.1. Conference User Definition . . . . . . . . . . . . . . . . 52
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
17.1. Normative References . . . . . . . . . . . . . . . . . . . 49 17.1. Normative References . . . . . . . . . . . . . . . . . . . 52
17.2. Informative References . . . . . . . . . . . . . . . . . . 49 17.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . . . . 56
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
a centralized unicast conference. Other than references to general a centralized unicast conference. Other than references to general
functionality (e.g., establishment and teardown), details of these functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document call signaling protocols are outside the scope of this document
skipping to change at page 8, line 9 skipping to change at page 8, line 9
the core set of information for a conference object. This core the core set of information for a conference object. This core
information includes a common set of definitions for basic information includes a common set of definitions for basic
conference features, such as conference identifiers, membership, conference features, such as conference identifiers, membership,
signaling, capabilities and media types, applicable to a wide signaling, capabilities and media types, applicable to a wide
range of conferencing applications. range of conferencing applications.
Conference blueprint: A conference blueprint is a static conference Conference blueprint: A conference blueprint is a static conference
object within a conferencing system, which describes a typical object within a conferencing system, which describes a typical
conference setting supported by the system. A conference conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects. blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints, each comprised of the A system may maintain multiple blueprints. Each blueprint is
common conference information, along with any number of templates. 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.
Conference control protocol (CCP): A conference control protocol Conference control protocol (CCP): A conference control protocol
provides the interface for data manipulation and state retrieval provides the interface for data manipulation and state retrieval
for the centralized conferencing data, represented by the for the centralized conferencing data, represented by the
conference object. conference object.
Conference factory: A conference factory is a logical entity, that Conference factory: A conference factory is a logical entity, that
generates upon request, unique URI(s) to identify and represent a generates upon request, unique URI(s) to identify and represent a
conference focus. conference focus.
Conference identifier (ID): A conference identifier is a call Conference identifier (ID): A conference identifier is a call
signaling protocol-specific URI that identifies a conference focus signaling protocol-specific URI that identifies a conference focus
and its associated conference instance. and its associated conference instance.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
negotiation/maintenance between a conference participant and the negotiation/maintenance between a conference participant and the
focus. focus.
Media graph: The media graph is the logical representation of the Media graph: The media graph is the logical representation of the
flow of media for a conference. flow of media for a conference.
Media mixer: A media mixer is the logical entity with the capability Media mixer: A media mixer is the logical entity with the capability
to combine media inputs of the same type, transcode the media and to combine media inputs of the same type, transcode the media and
distribute the result(s) to a single or multiple outputs. In this distribute the result(s) to a single or multiple outputs. In this
context, the term "media" means any type of data being delivered context, the term "media" means any type of data being delivered
over the network using appropriate transport means, such as RTP/ over the network using appropriate transport means, such as RTP/
RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol
(defined in [25]). (defined in [24]).
Registered conference document : A standards track document (i.e., Registered conference document : A standards track document (i.e.,
RFC) that defines and registers a conference template schema with RFC) that defines and registers a conference template schema with
the appropriate organization (e.g., IANA). A registered the appropriate organization (e.g., IANA). A registered
conference document also includes any complementary textual conference document also includes any complementary textual
information. information.
Role: A role provides the context for the set of conference Role: A role provides the context for the set of conference
operations that a participant can perform. A default role (e.g., operations that a participant can perform. A default role (e.g.,
standard conference participant) will always exist, providing a standard conference participant) will always exist, providing a
user with a set of basic conference operations. Based on system user with a set of basic conference operations. Based on system
specific authentication and authorization, a user may take on specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to alternate roles, such as conference moderator, allowing access to
a wider set of conference operations. a wider set of conference operations.
Sidebar: TBD. Sidebar: A sidebar is a separate Conference instance that only exists
within the context of a parent conference instance.
Whisper: TBD. Whisper: TBD.
5. Centralized Conferencing Data Model 5. Centralized Conferencing Data Model
The centralized conference data model is logically represented by the The centralized conference data model is logically represented by the
conference object. A conference object is of type 'Conference object conference object. A conference object is of type 'Conference object
type', which is comprised of two distinct components: the 'Common type', which is comprised of two distinct components: the 'Common
conference information type' and the 'Conference template type', as conference information type' and the 'Conference template type', as
illustrated in Figure 2. Each of these types is extensible for illustrated in Figure 2. Each of these types is extensible for
skipping to change at page 12, line 31 skipping to change at page 12, line 31
the available floor controls. This information would allow the available floor controls. This information would allow
authorized clients to manipulate the mixer's behavior via the focus, authorized clients to manipulate the mixer's behavior via the focus,
and the resultant distribution of the media to all or individual and the resultant distribution of the media to all or individual
participants. By doing so, a client can change its own state and/or participants. By doing so, a client can change its own state and/or
state of other participants in the conference. state of other participants in the conference.
A conference template can also include an abstract user interface A conference template can also include an abstract user interface
definition in terms of sliders, radio boxes, etc. for simplifying definition in terms of sliders, radio boxes, etc. for simplifying
user interaction with a specific non-trivial feature. user interaction with a specific non-trivial feature.
The addition of new elements or the modification of the controls
within an element of an existing template requires the definition of
a new template.
5.3. Conference policies 5.3. Conference policies
Conference policies collectively refers to a set of rights, Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed permissions and limitations pertaining to operations being performed
on a certain conference object. on a certain conference object.
The set of rights describes the read/write access privileges for the The set of rights describes the read/write access privileges for the
conference object as a whole. This access would usually be granted conference object as a whole. This access would usually be granted
and defined in terms of giving the read-only or read-write access to and defined in terms of giving the read-only or read-write access to
clients with certain roles in the conference. As such, the policies clients with certain roles in the conference. As such, the policies
skipping to change at page 20, line 12 skipping to change at page 20, line 12
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime. Figure 5: Conference Ad-hoc Creation and Lifetime.
7.3. Advanced Example 7.3. Advanced Example
Figure 6 illustrates how a recurring conference can be specified Figure 6 illustrates how a recurring conference can be specified
according to system capabilities, scheduled, reserved, and managed in according to system capabilities, scheduled, reserved, and managed in
a conferencing system. A client would first query a conferencing a conferencing system. A client would first query a conferencing
system for its capabilities. This can be done by requesting a list system for its capabilities. This can be done by requesting a list
of the conference blueprints the system supports. Each blueprint of the conference blueprints the system supports.
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.
A client may need to query any templates in the blueprints that it Each blueprint contains a specific combination of capabilities and
doesn't understand and then make a decision on compatibility. limitations of the conference server in terms of supported media
Interface hints need to be included as per [21]. The client then types (e.g., audio, video, text, or combinations of these),
selects which specific templates to use and retrieves the templates participant roles, maximum number of participants of each role,
from the server itself, rather than from a centralized repository. 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 The selected blueprint with its default values is cloned by the
client into a newly created conference object, referred to as a client into a newly created conference object, referred to as a
conference reservation, that specifies the resources needed from the conference reservation, that specifies the resources needed from the
system for this conference instance. At this point the conference system for this conference instance. At this point the conference
reservation becomes independent from its blueprint. The client can reservation becomes independent from its blueprint. The client can
also change the default values, within the system ranges, and add also change the default values, within the system ranges, and add
additional information, such as the list of participants and the additional information, such as the list of participants and the
conference start time, to the conference reservation. conference start time, to the conference reservation.
skipping to change at page 25, line 48 skipping to change at page 26, line 48
contain only information that is allowed to be sent to that user. contain only information that is allowed to be sent to that user.
8.3. Conference Control Protocol 8.3. Conference Control Protocol
The conference control protocol provides for data manipulation and The conference control protocol provides for data manipulation and
state retrieval for the centralized conferencing data, represented by state retrieval for the centralized conferencing data, represented by
the conference object. The details of the conference control the conference object. The details of the conference control
protocol are detailed in separate documents [references TBD]. protocol are detailed in separate documents [references TBD].
[Editor's note: The remaining paragraphs and subsections of this [Editor's note: The remaining paragraphs and subsections of this
section should be removed from this document once the WG reaches section, detailing the various protocol options should be pruned from
consensus and a high level overview of the requirements for the this document, once the WG reaches consensus on the conference
conference control protocol should be provided here. However, until control protocol.]
the WG reaches that consensus (and agrees the fundamental
requirements) it seems premature to remove these details from this
document.]
The proposals for the conference control protocol under discussion
span from data manipulation (management-like) protocols (CPCP and
NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the
proposed protocols are in the sections below. The following
paragraphs summarize the fundamental issues around the selection of
the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG
mailing list].
It is recognized that semantic manipulations make for a cleaner
protocol design, with the disadvantage that extensions to the
underlying data model require extensions to the protocol used to
manipulate it. Syntactic manipulations allow for extensions to the
data model without requiring protocol extensions, with the
disadvantage that the server generally has to infer intent from data
manipulations instead of having intent explicitly signaled.
It is worth noting that one portion of the data to be manipulated,
the Common Conference Information, will not be extended, and would
naturally lend itself to semantic manipulation. Another part of the
data, the Conference Template, is intended to be extended, and would
naturally lend itself to syntactic manipulation. However, there has
been a stated desire to use a single protocol (and presumably a
single mode of operation within this protocol) to manipulate all
conference object state (common and template).
The third statement in the paragraph above makes the first two
solution options mutually exclusive. A proposal was made that by
allowing more than one protocol, a hybrid approach could be taken
such that CPCP and CSCP can both be used, since they are based on
other protocols that are likely to be supported by the clients (XCAP
and BFCP, respectively). However, the very rough consensus of the WG
supports a single protocol for Conference Control and SOAP has most
recently been put forth as that protocol. A basic overview of SOAP
in the context of Conference control is provided in Section 8.3.5
8.3.1. CPCP
A Conference Policy Control Protocol (CPCP) is a data manipulation
protocol being proposed as a standard means of storing and
manipulating the conference policy. According to CPCP, the
conference policy is comprised of the rules associated with a
specific conference instance. Requirements for the CPCP are defined
in the CPCP Requirements document [13]. The Conference Policy
Control Protocol document [17] defines the XML Schema for the
conference policy data elements.
The privileges as to which users are allowed to read and/or
manipulate a specific conference instance are defined in a separate
Extensible Markup Language (XML) Schema[19]. This schema is based on
the common policy model being used for geographic privacy information
and for presence information.
A separate document [18] proposes XCAP as one protocol mechanism for
storing and manipulating this conferencing policy data. XCAP is a
HTTP 1.1 based protocol that allows clients to read, write, modify
and delete application data stored in XML format on a server. One of
the main advantages of XCAP is that it maps XML document elements and
attributes to HTTP URIs that can be directly accessed by HTTP.
8.3.2. CCCP 8.3.1. CCCP
A Centralized Conferencing Control Protocol [20] is a semantic- A Centralized Conferencing Control Protocol [19] is a semantic-
oriented protocol defined to allow participants or otherwise oriented protocol defined to allow participants or otherwise
authorized entities to directly manipulate an active conference authorized entities to directly manipulate an active conference
instance. CCCP is defined as a set of transactions issued over a instance. CCCP is defined as a set of transactions issued over a
reliable transport protocol. A transaction consists of a Request reliable transport protocol. A transaction consists of a Request
carrying the required information in an XML body and a corresponding carrying the required information in an XML body and a corresponding
Response carrying an appropriate XML body. Response carrying an appropriate XML body.
CCCP requests are submitted to the CCCP server and can be prioritized CCCP requests are submitted to the CCCP server and can be prioritized
and queued, based on the CCCP client Role and the requested and queued, based on the CCCP client Role and the requested
primitives. CCCP requires no single lock per document, and the CCCP primitives. CCCP requires no single lock per document, and the CCCP
server can locally implement an optimization strategy independent of server can locally implement an optimization strategy independent of
CCCP client behavior. CCCP client behavior.
8.3.3. CSCP 8.3.2. CSCP
A Conference State Change protocol [26] is a client server protocol A Conference State Change protocol [25] is a client server protocol
used to change the state of a conference object. CSCP extends the used to change the state of a conference object. CSCP extends the
BFCP protocol [16] with new commands. A client sends the server a BFCP protocol [16] with new commands. A client sends the server a
request representing a sequence of commands. Each command can set, request representing a sequence of commands. Each command can set,
get, add, or delete a single field in the conference object. Changes get, add, or delete a single field in the conference object. Changes
to the conference object are performed on a hierarchal set of to the conference object are performed on a hierarchal set of
elements and unique attributes within those elements. A series of elements and unique attributes within those elements. A series of
changes can be pipelined in a single BFCP message. The server changes can be pipelined in a single BFCP message. The server
executes each action in series. If one of them fails, the server executes each action in series. If one of them fails, the server
returns an error for the action that failed and does not execute any returns an error for the action that failed and does not execute any
of the actions after that. Each individual action is atomic but the of the actions after that. Each individual action is atomic but the
pipelined series is not. pipelined series is not.
The item to which a command applies is specified by a unique ID and, The item to which a command applies is specified by a unique ID and,
where appropriate, attribute name. The ID is an unsigned 32 bit where appropriate, attribute name. The ID is an unsigned 32 bit
integer called the Element ID. The server discovery of the Element integer called the Element ID. The server discovery of the Element
ID is outside of CSCP. Typically this is done by using the ID is outside of CSCP. Typically this is done by using the
conference notification service per Section 8.2. Each field in the conference notification service per Section 8.2. Each field in the
data received in the notification contains a unique field ID data received in the notification contains a unique field ID
attribute that can be used in BFCP requests. attribute that can be used in BFCP requests.
8.3.4. NETCONF 8.3.3. SOAP
The Network Configuration (NETFCONF) protocol [27] defines a simple
mechanism through which a network device can be managed,
configuration data information can be retrieved, and new
configuration data can be uploaded and manipulated. The protocol
allows the device to expose a full, formal, application programming
interface (API).
NETCONF is proposed as the mechanism for object content manipulation
and state retrieval for the centralized conferencing data. NETCONF
provides a flexible configuration retrieval mechanism, with
extensibility. It allows for incremental configuration and commits.
NETCONF supports stored configurations (e.g., for startup, running,
etc.). It also supports XPath and subtree filtering. With NETCONF,
there are no constraints on the configuration content.
8.3.5. SOAP
The SOAP protocol is fundamentally an XML messaging scheme, capable The SOAP protocol is fundamentally an XML messaging scheme, capable
of supporting remote procedure calls. SOAP defines a simple message of supporting remote procedure calls. SOAP defines a simple message
format composed of a "header" and a "body" contained within an format composed of a "header" and a "body" contained within an
"envelope". The "header" contains meta-information relating to the "envelope". The "header" contains meta-information relating to the
message, and can be used to indicate such things as store-and-forward message, and can be used to indicate such things as store-and-forward
behaviour or transactional characteristics. In addition, SOAP behaviour or transactional characteristics. In addition, SOAP
encoding is optimized for ease of automated deserialization. encoding is optimized for ease of automated deserialization.
SOAP is proposed as the mechanism for object content manipulation and SOAP [17] and [18] is proposed as the mechanism for object content
state retrieval for the centralized conferencing data. In general, manipulation and state retrieval for the centralized conferencing
SOAP is a good fit for Conference Control, essentially because of its data. In general, SOAP is a good fit for Conference Control,
remote procedure call characteristics and its inherently synchronous essentially because of its remote procedure call characteristics and
and client-driven nature. its inherently synchronous and client-driven nature.
8.4. Floor Control 8.4. Floor Control
A floor control protocol allows an authorized client to manage access A floor control protocol allows an authorized client to manage access
to a specific floor and to grant, deny or revoke access of other to a specific floor and to grant, deny or revoke access of other
conference users to that floor. Floor control is not a mandatory conference users to that floor. Floor control is not a mandatory
mechanism for a conferencing system implementation but provides mechanism for a conferencing system implementation but provides
advanced media input control features for conference users. A advanced media input control features for conference users. A
mechanism for floor control within a conferencing system is defined mechanism for floor control within a conferencing system is defined
in the Binary Floor Control Protocol specification [16]. [Editor's in the Binary Floor Control Protocol specification [16]. [Editor's
skipping to change at page 29, line 29 skipping to change at page 28, line 45
requires access to additional information. This information requires access to additional information. This information
associates floor control interactions with the appropriate floor associates floor control interactions with the appropriate floor
instance. Once a connection has been established and authenticated instance. Once a connection has been established and authenticated
(see [16] for authentication details), a specific floor control (see [16] for authentication details), a specific floor control
message requires detailed information to uniquely identify a message requires detailed information to uniquely identify a
conference, a user and a floor. conference, a user and a floor.
The conference is uniquely identifed by the conference object ID per The conference is uniquely identifed by the conference object ID per
Section 6.2.1. This conference object ID must be included in all Section 6.2.1. This conference object ID must be included in all
floor control messages. When the SDP model is used as described in floor control messages. When the SDP model is used as described in
[24] this identifier maps to the 'confid' SDP attribute. [23] this identifier maps to the 'confid' SDP attribute.
Each authorized user associated with a conference object is uniquely Each authorized user associated with a conference object is uniquely
represented by a conference user ID per Section 6.3. This conference represented by a conference user ID per Section 6.3. This conference
user ID must be included in all floor control messages. When using user ID must be included in all floor control messages. When using
SDP offer/answer exchange to negotiate a Floor control connection SDP offer/answer exchange to negotiate a Floor control connection
with the focus using the call signaling interface, the unique with the focus using the call signaling interface, the unique
conference identifier is contained in the 'userid' SDP attribute, as conference identifier is contained in the 'userid' SDP attribute, as
defined in [24] defined in [23]
A media session witin a conferencing system can have any number of A media session witin a conferencing system can have any number of
floors (0 or more) that are represented by the conference identifer. floors (0 or more) that are represented by the conference identifer.
When using SDP offer/answer exchange to negotiate a floor control When using SDP offer/answer exchange to negotiate a floor control
connection with the focus using the call signaling interface, the connection with the focus using the call signaling interface, the
unique conference identifier is contained in the 'floorid' SDP unique conference identifier is contained in the 'floorid' SDP
attribute, as defined in [24] e.g., a=floorid:1 m-stream:10 . Each attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 . Each
'floorid' attribute, representing a unique floor, has an 'm-stream' 'floorid' attribute, representing a unique floor, has an 'm-stream'
tag containing one or more identifiers. The identifiers represent tag containing one or more identifiers. The identifiers represent
individual SDP media sessions (as defined using 'm=' from SDP) using individual SDP media sessions (as defined using 'm=' from SDP) using
the SDP 'Label' attribute as defined in [23]. the SDP 'Label' attribute as defined in [22].
9. Conferencing Scenario Realizations 9. Conferencing Scenario Realizations
This section addresses how advanced conferencing scenarios, many of This section addresses how advanced conferencing scenarios, many of
which have been described in [14], are realized using this which have been described in [14], are realized using this
centralized conferencing framework. The objective of this section is centralized conferencing framework. The objective of this section is
to further illustrate the model, mechanisms and protocols presented to further illustrate the model, mechanisms and protocols presented
in the previous sections and also serves to validate that the model, in the previous sections and also serves to validate that the model,
mechanisms and protocols are sufficient to support advanced mechanisms and protocols are sufficient to support advanced
conferencing scenarios. conferencing scenarios.
The details shown in the messages are for illustrative purposes only
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 9.1. Conference Creation
There are different ways to create a conference. A participant can There are different ways to create a conference. A participant can
create a conference using call signaling means only, such as SIP and create a conference using call signaling means only, such as SIP and
detailed in [15]. For a conferencing client to have more flexibility detailed in [15]. For a conferencing client to have more flexibility
in defining the charaterisitics and capabilities of a conference, a in defining the charaterisitics and capabilities of a conference, a
conferencing client would implement a conference control protocol conferencing client would implement a conference control protocol
client. By using a conference control protocol, the client can client. By using a conference control protocol, the client can
determine the capabilities of a conferencing system and its various determine the capabilities of a conferencing system and its various
resources. resources.
Figure 8 provides an example of one client "Alice" determining the Figure 8 provides an example of one client "Alice" determining the
conference blueprints available for a particular conferencing system conference blueprints available for a particular conferencing system
and creating a conference based on the desired blueprint. It should and creating a conference based on the desired blueprint.
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.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +------------+| "Alice" | +------------+|
+--------+ | | || +--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | || | |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference || | Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)|| | |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | || +--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+| ... | +-----------+ +------------+|
skipping to change at page 32, line 19 skipping to change at page 31, line 19
Upon receipt of the Conference Control Protocol response containing Upon receipt of the Conference Control Protocol response containing
the blueprints, "Alice" determines which blueprint to use for the the blueprints, "Alice" determines which blueprint to use for the
conference to be created. "Alice" creates a conference object based conference to be created. "Alice" creates a conference object based
on the blueprint (i.e., clones) and modifies applicable fields, such on the blueprint (i.e., clones) and modifies applicable fields, such
as membership list and start time. "Alice" then sends a request to as membership list and start time. "Alice" then sends a request to
the conferencing system to create a conference reservation based upon the conferencing system to create a conference reservation based upon
the updated blueprint. the updated blueprint.
Upon receipt of the Conference Control Protocol request to "reserve" Upon receipt of the Conference Control Protocol request to "reserve"
a conference based upon the blueprint in the request, the a conference based upon the blueprint in the request, the
conferencing system ensures that blueprint received is a valid conferencing system ensures that the blueprint received is a valid
blueprint (i.e. the values of the various field are within range). blueprint (i.e. the values of the various field are within range).
The conferencing system determines the appropriate read/write access The conferencing system determines the appropriate read/write access
of any users to be added to a conference based on this blueprint of any users to be added to a conference based on this blueprint
(using membership, roles, etc.). The conferencing system uses the (using membership, roles, etc.). The conferencing system uses the
received blueprint to clone a conference reservation. The received blueprint to clone a conference reservation. The
conferencing system also reserves or allocates a conference ID to be conferencing system also reserves or allocates a conference ID to be
used for any subsequent protocol requests from any of the members of used for any subsequent protocol requests from any of the members of
the conference. The conferencing system maintains the mapping the conference. The conferencing system maintains the mapping
between this conference ID and the conference object ID associated between this conference ID and the conference object ID associated
with the reservation through the conference instance. with the reservation through the conference instance.
skipping to change at page 33, line 23 skipping to change at page 32, line 23
conference control protocol, the client can affect its own state, conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state of any of the media mixers) which may indirectly affect the state of any of the
conference participants. conference participants.
Figure 9 provides an example of one client "Alice" impacting the Figure 9 provides an example of one client "Alice" impacting the
state of another client "Bob". This example assumes an established state of another client "Bob". This example assumes an established
conference. In this example, "Alice" wants to add "Bob" to the conference. In this example, "Alice" wants to add "Bob" to the
conference. conference.
It should be noted that not all entities impacted by the request are
shown in the diagram (e.g., Focus), but rather the emphasis is on the
new entities introduced by this centralized conferencing framework.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | | Active || | Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Conference || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | | || +--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
skipping to change at page 34, line 47 skipping to change at page 34, line 5
the state of any of the conference participants. the state of any of the conference participants.
Figure 10 provides an example of one client "Alice" impacting the Figure 10 provides an example of one client "Alice" impacting the
media state of another client "Bob". This example assumes an media state of another client "Bob". This example assumes an
established conference. In this example, the client, "Alice" whose established conference. In this example, the client, "Alice" whose
Role is "moderator" of the conference, wants to mute "Bob" on a Role is "moderator" of the conference, wants to mute "Bob" on a
medium-size multi-party conference, as his device is not muted (and medium-size multi-party conference, as his device is not muted (and
he's obviously not listening to the call) and background noise in his he's obviously not listening to the call) and background noise in his
office environment is disruptive to the conference. office environment is disruptive to the conference.
It should be noted that only entities impacted by the request are
shown in the diagram (e.g., there is no Focus shown).
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Active || | Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Conference || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | | || +--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
skipping to change at page 36, line 48 skipping to change at page 35, line 48
A sidebar conference object Identifier follows many of the concepts A sidebar conference object Identifier follows many of the concepts
outlined in the cloning tree model described in Section 7.1. A outlined in the cloning tree model described in Section 7.1. A
Sidebar conference object contains a subset of members from the Sidebar conference object contains a subset of members from the
original Conference object. Properties of the sidebar conference original Conference object. Properties of the sidebar conference
object can be manipulated by a Conference Control Protocol object can be manipulated by a Conference Control Protocol
(Section 8.3) using the unique conference object identifier for the (Section 8.3) using the unique conference object identifier for the
sidebar. It is also possible for the top level conference object to sidebar. It is also possible for the top level conference object to
enforce policy on the sidebar object (similar to parent enforceable enforce policy on the sidebar object (similar to parent enforceable
as discussed in Section 7.1). as discussed in Section 7.1).
[Editor's Note: this needs more detail - especially around cloning Figure 12 provides an example of one client "Alice" involved in
tree, including an example scenario such as a sidebar which still active conference with "Bob" and "Bud". "Alice" wants to create a
receives the visual media from the main conference, but has audio sidebar to have a side discussion with "Bob" while still viewing the
within the sidebar. The example would use some of the mechanisms video associated with the main conference. "Alice" initiates the
shown in previous sections (e.g. create a new sidebar conference, sidebar by sending a request to the conferencing system to create a
cloned from the existing active conference, manipulate the media, add conference reservation based upon the active conference object.
participants.]
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Bud" | ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=parent, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
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" 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.
Alice sends a conference control protocol request to update the
information in the reservation and to create an active conference.
Upon receipt of the conference control protocol request to update the
reservation and to create an active conference for the sidebar, as
identified by the conference object ID, the conferencing system
ensures that "Alice" has the appropriate authority based on the
policies associated with that specific conference object to perform
the operation. The conferencing system must also validate the
updated information in the reservation, ensuring whether members like
"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 is instigated through the
Focus.
Depending upon the policies, the participants 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 9.5. Whispering or Private Messages
[Editor's Note: TBD. Once we get full agreement on terminology and The case of private messages can be handled as a sidebar with just
the basic ideas in the other sections, we'll tackle this.] two participants, similar to the example in section Section 9.4, but
rather than using audio within the sidebar, "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 9.6. Conference Announcements and Recordings
[Editor's note: TBD. Use Cullen's comments on the previous version Each participant can require a different type of announcement and/or
of the doc .] 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. The
conferencing system would also need to have the capability to monitor
for DTMF from each individual participant.
Further details of conference announcements and recordings, within
the context of this framework, are TBD.
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIPPING Conferencing Framework are being used
skipping to change at page 40, line 25 skipping to change at page 42, line 27
using a mechanism such as the 'k=' SDP attribute. The shared secret using a mechanism such as the 'k=' SDP attribute. The shared secret
can also be exchanged using un-specified 'out of band' mechanisms. can also be exchanged using un-specified 'out of band' mechanisms.
When using Digest authentication of floor control client messages the When using Digest authentication of floor control client messages the
exchange of an active 'Nonce' is also required. This can be achieved exchange of an active 'Nonce' is also required. This can be achieved
using a BFCP request response interaction as defined in BFCP (A using a BFCP request response interaction as defined in BFCP (A
request is submitted without a Nonce TLV and the server generates an request is submitted without a Nonce TLV and the server generates an
error response with either an Error Code 7 (DIGEST TLV Required) or 6 error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value
can also be obtained 'out of band' using information provided in the can also be obtained 'out of band' using information provided in the
offer/answer exchange. As with the other SDP Floor attributes offer/answer exchange. As with the other SDP Floor attributes
referenced in this section and defined in [24], the 'nonce' attribute referenced in this section and defined in [23], the 'nonce' attribute
can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj.
[Editor's Note: May need more specifics on fetching from the [Editor's Note: May need more specifics on fetching from the
conference object the credentials required for BFCP. This includes conference object the credentials required for BFCP. This includes
the conference id, user id, and password.] the conference id, user id, and password.]
12. IANA Considerations 12. IANA Considerations
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
skipping to change at page 40, line 48 skipping to change at page 43, line 7
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews
and constructive input. and constructive input.
14. Changes since last Version 14. Changes since last Version
Changes from WG 01 to 02:: Changes from WG 02 to 03:
- Updated the definition of Blueprint (per DP 4/4.1 discussions)
- Added definition for Sidebar.
- Section 5.2 Added text indicating that adding new elements or
modifying elements requires the definition of a new template. (per
DP4.2 conclusion).
- Section 7.3. Added text reiterating that the blueprint comprises
both the common conference information and a template (per DP4/4.1
discussions.
- Section 7.3. Added text per resolution of DP 4.3 indicating that a
blueprint is common conference information + one template and that
multiple templates is FFS.
- Section 8.3 - Updated Conference Control Protocol section to
include the protocols on the table for WG discussion as of 31 Dec
2005 deadline.
- Section 9.4 - Sidebars - added Ascii art to show FW interactions
- Section 9.5 - Whisper - Added some text, reflecting past WG
discussions. Basic definition and further details/example still
needed.
- Section 9.6 - Conf Anncs and Recordings - Added some basic text.
Further details/example still needed.
Changes from WG 01 to 02:
- Editorial nits -i.e. consistent terminology, capatilization, etc. - Editorial nits -i.e. consistent terminology, capatilization, etc.
- Revamped abstract and introduction - Revamped abstract and introduction
- Global removal of XCON as a qualifier (we had previously done this - Global removal of XCON as a qualifier (we had previously done this
in a previous version with all the identifiers). in a previous version with all the identifiers).
- Global change of "call control signalling" to "call signaling" - Global change of "call control signalling" to "call signaling"
skipping to change at page 44, line 49 skipping to change at page 47, line 34
included. It also needs to link up with other drafts and explicitly included. It also needs to link up with other drafts and explicitly
reference.] reference.]
A centralized conferencing system, as defined in the Conference A centralized conferencing system, as defined in the Conference
Framework [ref] has potential to expose a range of interfaces and Framework [ref] has potential to expose a range of interfaces and
protocols. It is also possible that future centralized conferencing protocols. It is also possible that future centralized conferencing
enhancements might place requirements to provide further additional enhancements might place requirements to provide further additional
protocols and interfaces. A conference object can consist and be protocols and interfaces. A conference object can consist and be
associated with many identifiers that are in some way related to a associated with many identifiers that are in some way related to a
conference object. Good examples include the Binary Floor Control conference object. Good examples include the Binary Floor Control
Protocol (BFCP)[24] and call signaling protocols, such as SIP. Each Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each
use unique identifiers to represent a protocol instance associated use unique identifiers to represent a protocol instance associated
with a conference object. with a conference object.
A conferencing system may maintain a relationship between the A conferencing system may maintain a relationship between the
conference object URIs and the identifiers associated with each of conference object URIs and the identifiers associated with each of
the complementary centralized conferencing protocols (e.g., call the complementary centralized conferencing protocols (e.g., call
signaling protocols, BFCP, etc.). To facilitate the maintenance of signaling protocols, BFCP, etc.). To facilitate the maintenance of
these relationships, the conference object URI acts as a top level these relationships, the conference object URI acts as a top level
identifier within the conferencing system for the purpose of identifier within the conferencing system for the purpose of
identifying the interfaces for these other protocols. This implicit identifying the interfaces for these other protocols. This implicit
binding provides a structured mapping of the various protocols with binding provides a structured mapping of the various protocols with
the associated conference object identifier. Figure 12 illustrates the associated conference object identifier. Figure 13 illustrates
the relationship between the identifiers used for the protocols the relationship between the identifiers used for the protocols
within this framework and the general conference object identifier. within this framework and the general conference object identifier.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+------+-------+ +------+-------+
| |
| |
| |
+-----------------+---------------+ +-----------------+---------------+
| | | |
+-------+---------+ +-------+-------+ +-------+---------+ +-------+-------+
|CSP Conference ID| | BFCP 'confid' | |CSP Conference ID| | BFCP 'confid' |
+-----------------+ +---------------+ +-----------------+ +---------------+
Figure 12: Conference Object Mapping. Figure 13: Conference Object Mapping.
In Figure 12, the conference object identifier acts as the top level In Figure 13, the conference object identifier acts as the top level
key in the identification process. The call signaling protocols have key in the identification process. The call signaling protocols have
an associated conference ID representation in the form of URIs. The an associated conference ID representation in the form of URIs. The
binary floor control protocol, as defined in [24], defines the binary floor control protocol, as defined in [23], defines the
'conf-id' identifier which represents a conference instance within 'conf-id' identifier which represents a conference instance within
floor control. When created within the conferencing system, the floor control. When created within the conferencing system, the
'conf-id' has a 1:1 mapping to the unique conference object 'conf-id' has a 1:1 mapping to the unique conference object
Identifier. Operations associated with the Conference Control Identifier. Operations associated with the Conference Control
Protocols are directly associated with the conference object, thus Protocols are directly associated with the conference object, thus
the primary identifier associated with these protocols is the the primary identifier associated with these protocols is the
conference object identifier. The mappings between additional conference object identifier. The mappings between additional
protocols/interface is not strictly 1:1 and does allow for multiple protocols/interface is not strictly 1:1 and does allow for multiple
occurrences. For example, multiple call signaling protocols will occurrences. For example, multiple call signaling protocols will
each have a representation that is implicitly linked to the top level each have a representation that is implicitly linked to the top level
conference object identifier, for example, H323 and SIP URIs that conference object identifier, for example, H323 and SIP URIs that
represent a conference instance. It should be noted that a represent a conference instance. It should be noted that a
conferencing system is free to structure such relationships as conferencing system is free to structure such relationships as
required and this information is just included as a guideline that required and this information is just included as a guideline that
can be used. can be used.
The following example illustrates the representation and The following example illustrates the representation and
relationships that might occur in a typical conference instance. The relationships that might occur in a typical conference instance. The
table in Figure 13 lists a typical conference instance and related table in Figure 14 lists a typical conference instance and related
properties. properties.
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
| Conf Obj URI | CSP URI | BFCP Conf-ID | | Conf Obj URI | CSP URI | BFCP Conf-ID |
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
| xcon:Ji092i | sip:Ji092i@example.com | Ji092i | | xcon:Ji092i | sip:Ji092i@example.com | Ji092i |
| | tel:+44(0)2920930033 | | | | tel:+44(0)2920930033 | |
| | h323:Ji092i@example.com| | | | h323:Ji092i@example.com| |
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
Figure 13: Conference Table Representation Figure 14: Conference Table Representation
The information from Figure 13 can then be applied to the The information from Figure 14 can then be applied to the
representation introduced in Figure 12. This results in Figure 14. representation introduced in Figure 13. This results in Figure 15.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------+ +--------------+
| xcon:Ji092i | | xcon:Ji092i |
+------+-------+ +------+-------+
| |
| |
skipping to change at page 47, line 4 skipping to change at page 49, line 42
+-----------------------+ +---------------+ +-----------------------+ +---------------+
|h323:Ji092i@example.com| | Ji092i | |h323:Ji092i@example.com| | Ji092i |
|tel:+44(0)2920930033 | +-------+-------+ |tel:+44(0)2920930033 | +-------+-------+
|sip:Ji092i@example.com | | |sip:Ji092i@example.com | |
+-----------------------+ +-------|-------+ +-----------------------+ +-------|-------+
| BFCP 'floorid | | BFCP 'floorid |
+---------------+ +---------------+
| UEK78d | | UEK78d |
| 09cnJk | | 09cnJk |
+---------------+ +---------------+
Figure 14: Conference Tree Representation
Further elements can be added to the tree representation in Figure 14 Figure 15: Conference Tree Representation
Further elements can be added to the tree representation in Figure 15
to enable a complete representation of a conference instance within a to enable a complete representation of a conference instance within a
conferencing system. conferencing system.
This style of association can be applied to any supplementary This style of association can be applied to any supplementary
protocols or conferencing mechanisms that are applied to the protocols or conferencing mechanisms that are applied to the
centralized conferencing model defined in this document as long as a centralized conferencing model defined in this document as long as a
unique reference per conference instance is available that can be unique reference per conference instance is available that can be
mapped to a conference object. mapped to a conference object.
15.1. Conference Object URI Definition 15.1. Conference Object URI Definition
skipping to change at page 47, line 43 skipping to change at page 50, line 38
determine who is issuing commands. Appropriate policies can then be determine who is issuing commands. Appropriate policies can then be
applied to the requested command. applied to the requested command.
As with the conference object identifier, a number of supplementary As with the conference object identifier, a number of supplementary
user identifiers defined in other protocols are used within a user identifiers defined in other protocols are used within a
conference instance. Such user identifiers can be associated with conference instance. Such user identifiers can be associated with
this conference user identifier and enable the conferencing system to this conference user identifier and enable the conferencing system to
correlate and map these multiple authenticated user identities to the correlate and map these multiple authenticated user identities to the
single user identifier. single user identifier.
Figure 15 illustrates an example using the conference user identifier Figure 16 illustrates an example using the conference user identifier
in association with the user identity defined for BFCP and SIP Digest in association with the user identity defined for BFCP and SIP Digest
user identity as defined in RFC3261[4], which would be used when SIP user identity as defined in RFC3261[4], which would be used when SIP
is the call signaling protocol. It should be noted that a is the call signaling protocol. It should be noted that a
conferencing system is free to structure such relationships as conferencing system is free to structure such relationships as
required and this information is just included as a guideline that required and this information is just included as a guideline that
can be used. can be used.
+---------------+ +---------------+
| Conference | | Conference |
| User | | User |
skipping to change at page 48, line 20 skipping to change at page 51, line 20
| |
| |
| |
+---------------+---------------+ +---------------+---------------+
| | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
| BFCP | | SIP Digest | | BFCP | | SIP Digest |
| 'UserID' | | Username | | 'UserID' | | Username |
+---------------+ +-------+-------+ +---------------+ +-------+-------+
Figure 15: Conference User Identifier Figure 16: Conference User Identifier
Within a conferencing system, a user is identified by a single Within a conferencing system, a user is identified by a single
conference user identifier. Any additional conferencing mechanisms conference user identifier. Any additional conferencing mechanisms
that contain a protocol specific user ID can be associated with the that contain a protocol specific user ID can be associated with the
conference user identifier, as illustrated in Figure 15. This conference user identifier, as illustrated in Figure 16. This
mechanism allows conferencing systems to manage and relate system mechanism allows conferencing systems to manage and relate system
wide user identities in relation to specific conference objects and wide user identities in relation to specific conference objects and
helps in the enforcement of system wide policies. helps in the enforcement of system wide policies.
The following example illustrates the representation and The following example illustrates the representation and
relationships that might occur in a typical conference instance. The relationships that might occur in a typical conference instance. The
table in Figure 16 lists a typical representation of user identifier table in Figure 17 lists a typical representation of user identifier
hierarchy and associations. hierarchy and associations.
+----------------+----------------+---------------+----------------+ +----------------+----------------+---------------+----------------+
| Conf User ID | BFCP User ID | SIP User ID | H323 User ID | | Conf User ID | BFCP User ID | SIP User ID | H323 User ID |
+----------------+----------------+---------------+----------------+ +----------------+----------------+---------------+----------------+
| John | HK37ihdaj | 123674 | 928373 | | John | HK37ihdaj | 123674 | 928373 |
+----------------+----------------+---------------+----------------+ +----------------+----------------+---------------+----------------+
Figure 16: User Identitier Representation Figure 17: User Identitier Representation
The information from Figure 16 can then be applied to the The information from Figure 17 can then be applied to the
representation introduced in Figure 15. This results in Figure 17. representation introduced in Figure 16. This results in Figure 18.
+--------------+ +--------------+
| Conference | | Conference |
| User | | User |
| Identifier | | Identifier |
+--------------+ +--------------+
| John | | John |
+------+-------+ +------+-------+
| |
| |
| |
+---------------------+---------------------+ +---------------------+---------------------+
| | | | | |
+-------+--------+ +-------+-------+ +--------+-------+ +-------+--------+ +-------+-------+ +--------+-------+
| BFCP User ID | | SIP User ID | | H323 User ID | | BFCP User ID | | SIP User ID | | H323 User ID |
+----------------+ +---------------+ +----------------+ +----------------+ +---------------+ +----------------+
| HK37ihdaj | | 123674 | | 928373 | | HK37ihdaj | | 123674 | | 928373 |
+----------------+ +-------+-------+ +----------------+ +----------------+ +-------+-------+ +----------------+
Figure 17: User ID Tree Representation Figure 18: User ID Tree Representation
Further elements can be added to the tree representation in Figure 14 Further elements can be added to the tree representation in Figure 15
to enable a complete representation of a conference instance within a to enable a complete representation of a conference instance within a
conferencing system. conferencing system.
16.1. Conference User Definition 16.1. Conference User Definition
[Editors Note: When the appendix is split from the Framework [Editors Note: When the appendix is split from the Framework
document, full definition will be included. document, full definition will be included.
17. References 17. References
skipping to change at page 50, line 50 skipping to change at page 53, line 50
October 2005. October 2005.
[13] Koskelainen, P. and H. Khartabil, "Requirements for Conference [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), August 2004. progress), August 2004.
[14] Even, R. and N. Ismail, "Conferencing Scenarios", [14] Even, R. and N. Ismail, "Conferencing Scenarios",
draft-ietf-xcon-conference-scenarios-05 (work in progress), draft-ietf-xcon-conference-scenarios-05 (work in progress),
September 2005. September 2005.
[15] Johnston, A. and O. Levin, "Session Initiation Protocol Call [15] Levin, O., "Session Initiation Protocol Call Control -
Control - Conferencing for User Agents", Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-07 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005. June 2005.
[16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-05 (work in progress), July 2005. draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[18] Khartabil, H., "An Extensible Markup Language (XML) [17] Schulzrinne, H., "COMP: Conference Object Manipulation
Configuration Access Protocol (XCAP) Usages for Conference Protocol", draft-schulzrinne-xcon-comp-00 (work in progress),
Policy Manipulation and Conference Policy Privelges January 2006.
Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress),
October 2004.
[19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a [18] Boulton, C. and M. Barnes, "Centralized Conferencing
Conference Policy", Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in
draft-ietf-xcon-conference-policy-privileges-01 (work in progress), January 2006.
progress), October 2004.
[20] Levin, O. and G. Kimchi, "Centralized Conference Data Model", [19] Levin, O., "Centralized Conference Control Protocol",
draft-levin-xcon-cccp-02 (work in progress), February 2005. draft-levin-xcon-cccp-04 (work in progress), January 2006.
[21] Jennings, C. and B. Rosen, "Media Conference Server Control for [20] Jennings, C. and B. Rosen, "Media Conference Server Control for
XCON", draft-jennings-xcon-media-control-03 (work in progress), XCON", draft-jennings-xcon-media-control-03 (work in progress),
July 2005. July 2005.
[22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", [21] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
draft-rosen-xcon-conf-sidebars-01 (work in progress), draft-rosen-xcon-conf-sidebars-01 (work in progress),
July 2004. July 2004.
[23] Levin, O. and G. Camarillo, "The SDP (Session Description [22] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress), draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005. January 2005.
[24] Camarillo, G., "Session Description Protocol (SDP) Format for [23] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), draft-camarillo-mmusic-sdp-bfcp-00 (work in progress),
October 2004. October 2004.
[25] Campbell, B., "The Message Session Relay Protocol", [24] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-12 (work in progress), draft-ietf-simple-message-sessions-14 (work in progress),
October 2005. February 2006.
[26] Jennings, C. and A. Roach, "Conference State Change Protocol [25] Jennings, C., "Conference State Change Protocol (CSCP)",
(CSCP)", draft-jennings-xcon-cscp-01 (work in progress), draft-jennings-xcon-cscp-02 (work in progress), December 2005.
July 2005.
[27] Enns, R., "NETCONF Configuration Protocol", [26] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-09 (work in progress), October 2005. draft-ietf-netconf-prot-11 (work in progress), February 2006.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
skipping to change at page 54, line 41 skipping to change at page 56, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 66 change blocks. 
226 lines changed or deleted 287 lines changed or added

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