draft-ietf-xcon-framework-08.txt   draft-ietf-xcon-framework-09.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational C. Boulton Intended status: Standards Track C. Boulton
Expires: November 15, 2007 Ubiquity Software Corporation Expires: February 2, 2008 Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
May 14, 2007
A Framework for Centralized Conferencing A Framework for Centralized Conferencing
draft-ietf-xcon-framework-08 draft-ietf-xcon-framework-09
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 35
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 November 15, 2007. This Internet-Draft will expire on February 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange
a centralized unicast conference. The Centralized Conferencing media in a centralized unicast conference. The Centralized
Framework defines logical entities and naming conventions, along with Conferencing Framework defines logical entities and naming
a high level conferencing data model. The framework also outlines a conventions, along with a high level conferencing data model. The
set of conferencing protocols, which are complementary to the call framework also outlines a set of conferencing protocols, which are
signaling protocols, for building advanced conferencing applications. complementary to the call signaling protocols, for building advanced
The framework binds all the defined components together for the conferencing applications. The framework binds all the defined
benefit of builders of conferencing systems. components together for the benefit of builders of conferencing
systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10 4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
4.1. Conference Information . . . . . . . . . . . . . . . . . . 12 4.1. Conference Information . . . . . . . . . . . . . . . . . . 12
4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12 4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
5. Centralized Conferencing Constructs and Identifiers . . . . . 13 5. Centralized Conferencing Constructs and Identifiers . . . . . 13
skipping to change at page 3, line 40 skipping to change at page 3, line 40
8.2. Participant Manipulations . . . . . . . . . . . . . . . . 30 8.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
8.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32 8.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
8.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33 8.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35 8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37 8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40 8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40
8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42 8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
8.7. Conference Announcements and Recordings . . . . . . . . . 44 8.7. Conference Announcements and Recordings . . . . . . . . . 44
8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46 8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46 8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
9. Relationships between SIPPING and Centralized Conferencing 9. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 51 10.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 51
10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52 10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52
10.3. Floor Control Server Authentication . . . . . . . . . . . 52 10.3. Floor Control Server Authentication . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
13. Changes since last Version . . . . . . . . . . . . . . . . . . 53 13. Changes since last Version . . . . . . . . . . . . . . . . . . 53
14. Informative References . . . . . . . . . . . . . . . . . . . . 60 14. Informative References . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . . . . . 63
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, Q.931 or ISUP, to exchange
a centralized unicast conference. Other than references to general media in a centralized unicast conference. Other than references to
functionality (e.g., establishment and teardown), details of these general functionality (e.g., establishment and teardown), details of
call signaling protocols are outside the scope of this document. these call signaling protocols are outside the scope of this
document.
The Centralized Conferencing Framework defines logical entities and The Centralized Conferencing Framework defines logical entities and
naming conventions, along with a high level conferencing data model. naming conventions, along with a high level conferencing data model.
The framework also outlines a set of conferencing protocols, which The framework also outlines a set of conferencing protocols, which
are complementary to the call signaling protocols, for building are complementary to the call signaling protocols, for building
advanced conferencing applications. advanced conferencing applications.
The Centralized Conferencing Framework is compatible with the The Centralized Conferencing Framework is compatible with the
functional model presented in the SIPPING Conferencing Framework [8]. functional model presented in the SIP Conferencing Framework [8].
Section 9 of this document discusses the relationship between the Section 9 of this document discusses the relationship between the
Centralized Conferencing Framework and the SIPPING Conferencing Centralized Conferencing Framework and the SIP Conferencing
framework, in the context of the Centralized Conferencing model framework, in the context of the Centralized Conferencing model
presented in this document. presented in this document.
2. Terminology 2. Terminology
This Centralized Conferencing Framework document generalizes, when This Centralized Conferencing Framework document generalizes, when
appropriate, the SIPPING Conferencing Framework [8] terminology and appropriate, the SIP Conferencing Framework [8] terminology and
introduces new concepts, as listed below. Further details and introduces new concepts, as listed below. Further details and
clarification of the new terms and concepts are provided in the clarification of the new terms and concepts are provided in the
subsequent sections of this document. subsequent sections of this document.
Active conference: The term active conference refers to a conference Active conference: The term active conference refers to a conference
object that has been created and activated via the allocation of object that has been created and activated via the allocation of
its identifiers (e.g., conference object identifier and conference its identifiers (e.g., conference object identifier and conference
identifier) and the associated focus. An active conference is identifier) and the associated focus. An active conference is
created based on either a system default conference blueprint or a created based on either a system default conference blueprint or a
specific conference reservation. specific conference reservation.
Call Signaling protocol: The call signaling protocol is used between Call Signaling protocol: The call signaling protocol is used between
a participant and a focus. In this context, the term "call" means a participant and a focus. In this context, the term "call" means
a channel or session used for media streams. a channel or session used for media streams.
Conference information: The conference information includes
definitions for basic conference features, such as conference
identifiers, membership, signaling, capabilities and media types,
applicable to a wide range of conferencing applications. The
conference information also includes the media and application
specific data for enhanced conferencing features or capabilities,
such as media mixers. The conference information is the data type
(i.e., the XML schema) for a conference object.
Conference blueprint: A conference blueprint is a static conference Conference blueprint: A conference blueprint is a static conference
object within a conferencing system, which describes a typical object within a conferencing system, which describes a typical
conference setting supported by the system. A conference conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects. blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints. Each blueprint is A system may maintain multiple blueprints. Each blueprint is
comprised of the initial values and ranges for the elements in the comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the conference object, conformant to the data schemas for the conference
information. information.
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 unique URI(s) to identify and represent a conference generates unique URI(s) to identify and represent a conference
focus. focus.
Conference identifier (ID): A conference identifier is a call Conference identifier (ID): A conference identifier is a call
signaling protocol-specific URI that identifies a conference focus signaling protocol-specific URI that identifies a conference focus
and its associated conference instance. and its associated conference instance.
Conference information: The conference information includes
definitions for basic conference features, such as conference
identifiers, membership, signaling, capabilities and media types,
applicable to a wide range of conferencing applications. The
conference information also includes the media and application
specific data for enhanced conferencing features or capabilities,
such as media mixers. The conference information is the data type
(i.e., the XML schema) for a conference object.
Conference instance: A conference instance refers to an internal Conference instance: A conference instance refers to an internal
implementation of a specific conference, represented as a set of implementation of a specific conference, represented as a set of
logical conference objects and associated identifiers. logical conference objects and associated identifiers.
Conference object: A conference object represents a conference at a Conference object: A conference object represents a conference at a
certain stage (e.g., description upon conference creation, certain stage (e.g., description upon conference creation,
reservation, activation, etc.), which a conferencing system reservation, activation, etc.), which a conferencing system
maintains in order to describe the system capabilities and to maintains in order to describe the system capabilities and to
provide access to the services available for each object provide access to the services available for each object
independently. The conference object schema is based on the independently. The conference object schema is based on the
conference information. conference information.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
multiple conference user identifiers within a conferencing system multiple conference user identifiers within a conferencing system
(e.g., to represent different roles). (e.g., to represent different roles).
Floor: Floor refers to a set of data or resources associated with a Floor: Floor refers to a set of data or resources associated with a
conference instance, for which a conference participant, or group conference instance, for which a conference participant, or group
of participants, is granted temporary access. of participants, is granted temporary access.
Floor chair: A floor chair is a floor control protocol compliant Floor chair: A floor chair is a floor control protocol compliant
client, either a human participant or automated entity, who is client, either a human participant or automated entity, who is
authorized to manage access to one floor and can grant, deny or authorized to manage access to one floor and can grant, deny or
revoke access. The floor chair does not have to be a participant revoke access. The floor chair does not have to be a participant
in the conference instance. in the conference instance.
Focus: A focus is a logical entity that maintains the call Focus: A focus is a logical entity that maintains the call signaling
signalling interface with each participating client and the interface with each participating client and the conference object
conference object representing the active state. As such, the representing the active state. As such, the focus acts as an
focus acts as an endpoint for each of the supported signaling endpoint for each of the supported signaling protocols and is
protocols and is responsible for all primary conference membership responsible for all primary conference membership operations
operations (e.g., join, leave, update the conference instance) and (e.g., join, leave, update the conference instance) and for media
for media negotiation/maintenance between a conference participant negotiation/maintenance between a conference participant and the
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[5]) or Message Session Relay Protocol RTCP (defined in RFC 3550[5]) or Message Session Relay Protocol
(defined in [17]). (defined in [17]).
Role: A role provides the context for the set of conference Role: A role provides the context for the set of conference
skipping to change at page 7, line 18 skipping to change at page 7, line 18
conference participants, with a central endpoint, called a conference conference participants, with a central endpoint, called a conference
Focus. The Focus has direct peer relationships with the participants Focus. The Focus has direct peer relationships with the participants
by maintaining a separate call signaling interface with each. by maintaining a separate call signaling interface with each.
Consequently, in this centralized conferencing model, the call Consequently, in this centralized conferencing model, the call
signaling graph is always a star. signaling graph is always a star.
The most basic conference supported in this model would be an ad-hoc The most basic conference supported in this model would be an ad-hoc
unmanaged conference, which would not necessarily require any of the unmanaged conference, which would not necessarily require any of the
functionality defined within this framework. For example, it could functionality defined within this framework. For example, it could
be supported using basic SIP signaling functionality with a be supported using basic SIP signaling functionality with a
participant serving as the Focus; the SIPPING Conferencing Framework participant serving as the Focus; the SIP Conferencing Framework [8]
[8] together with the SIP Call Control Conferencing for User Agents together with the SIP Call Control Conferencing for User Agents [12]
[12] documents address these types of scenarios. documents address these types of scenarios.
In addition to the basic features, however, a conferencing system In addition to the basic features, however, a conferencing system
supporting the centralized conferencing model proposed in this supporting the centralized conferencing model proposed in this
framework document can offer richer functionality, by including framework document can offer richer functionality, by including
dedicated conferencing applications with explicitly defined dedicated conferencing applications with explicitly defined
capabilities, reserved recurring conferences, along with providing capabilities, reserved recurring conferences, along with providing
the standard protocols for managing and controlling the different the standard protocols for managing and controlling the different
attributes of these conferences. attributes of these conferences.
The core requirements for centralized conferencing are outlined in The core requirements for centralized conferencing are outlined in
[7]. These requirements are applicable for conferencing systems [7]. These requirements are applicable for conferencing systems
using various call signaling protocols, including SIP. Additional using various call signaling protocols, including SIP. Additional
conferencing requirements are provided in [10], and [11]. conferencing requirements are provided in [10], and [11].
The centralizing conferencing system proposed by this framework is The centralized conferencing system proposed by this framework is
built around a fundamental concept of a conference object. A built around a fundamental concept of a conference object. A
conference object provides the data representation of a conference conference object provides the data representation of a conference
during each of the various stages of a conference (e.g., creation, during each of the various stages of a conference (e.g., creation,
reservation, active, completed, etc.). A conference object is reservation, active, completed, etc.). A conference object is
accessed via the logical functional elements, with whom a accessed via the logical functional elements, with whom a
conferencing client interfaces, using the various protocols conferencing client interfaces, using the various protocols
identified in Figure 1. The functional elements defined for a identified in Figure 1. The functional elements defined for a
conferencing system described by the framework are a Conference conferencing system described by the framework are a Conference
Control Server, Floor Control Server, any number of Foci and a Control Server, Floor Control Server, any number of Foci and a
Notification Service. A Conference Control Protocol (CCP) provides Notification Service. A Conference Control Protocol (CCP) provides
the interface between a conference and media control client and the the interface between a conference and media control client and the
conference control server. A floor control protocol (e.g., BFCP) conference control server. A floor control protocol (e.g., BFCP)
provides the interface between a floor control client and the floor provides the interface between a floor control client and the floor
control server. A call signaling protocol (e.g., SIP, H.323, PSTN, control server. A call signaling protocol (e.g., SIP, H.323, Jabber,
etc.) provides the interface between a call signaling client and a Q.931, ISUP, etc.) provides the interface between a call signaling
Focus. A notification protocol (e.g. SIP Notify) provides the client and a Focus. A notification protocol (e.g. SIP Notify [4])
interface between the conferencing client and the Notification provides the interface between the conferencing client and the
Service. Notification Service.
A conferencing system can support a subset of the conferencing A conferencing system can support a subset of the conferencing
functions depicted in the conferencing system logical decomposition functions depicted in the conferencing system logical decomposition
in Figure 1 and described in this document. However, there are some in Figure 1 and described in this document. However, there are some
essential components that would typically be used by most other essential components that would typically be used by most other
advanced functions, such as the Notification Service. For example, advanced functions, such as the Notification Service. For example,
the notification service is used to correlate information, such as the notification service is used to correlate information, such as
list of participants with their media streams, between the various list of participants with their media streams, between the various
other components. other components.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
to address and manage the conference objects, instances and users to address and manage the conference objects, instances and users
associated with a conferencing system. Section 6 of this document associated with a conferencing system. Section 6 of this document
describes how a conferencing system is logically built using the describes how a conferencing system is logically built using the
defined high level data model and how the conference objects are defined high level data model and how the conference objects are
maintained. Section 7 describes the fundamental conferencing maintained. Section 7 describes the fundamental conferencing
mechanisms and provides a high level overview of the protocols. mechanisms and provides a high level overview of the protocols.
Section 8 then provides realizations of various conferencing Section 8 then provides realizations of various conferencing
scenarios, detailing the manipulation of the conference objects using scenarios, detailing the manipulation of the conference objects using
the defined protocols. Section 9 of this document summarizes the the defined protocols. Section 9 of this document summarizes the
relationship between this Centralized Conferencing Framework and the relationship between this Centralized Conferencing Framework and the
SIPPING Conferencing Framework. SIP Conferencing Framework.
4. Centralized Conferencing Data 4. Centralized Conferencing Data
The centralized conference data is logically represented by the The centralized conference data is logically represented by the
conference object. A conference object is of type 'Conference conference object. A conference object is of type 'Conference
information type', as illustrated in Figure 2. The conference information type', as illustrated in Figure 2. The conference
information type is extensible. information type is extensible.
+------------------------------------------------------+ +------------------------------------------------------+
| C o n f e r e n c e o b j e c t | | C o n f e r e n c e o b j e c t |
skipping to change at page 12, line 20 skipping to change at page 12, line 20
4.1. Conference Information 4.1. Conference Information
There is a core set of data in the conference information that is There is a core set of data in the conference information that is
utilized in any conference, independent of the specific conference utilized in any conference, independent of the specific conference
media nature (e.g., the mixing algorithms performed, the advanced media nature (e.g., the mixing algorithms performed, the advanced
floor control applied, etc.). This core set of data in the floor control applied, etc.). This core set of data in the
conference information contains the definitions representing the conference information contains the definitions representing the
conference object capabilities, membership, roles, call signaling and conference object capabilities, membership, roles, call signaling and
media status relevant to different stages of the conference life- media status relevant to different stages of the conference life-
cycle. This core set of conference information may be represented cycle. This core set of conference information may be represented
using the conference-type as defined in [9]. Typically, participants using the conference-type as defined in the SIP conference event
with read-only access to the conference information would be package [9]. Typically, participants with read-only access to the
interested in this core set of conference information only. conference information would be interested in this core set of
conference information only.
In order to support more complex media manipulations and enhanced In order to support more complex media manipulations and enhanced
conferencing features the conference information, as reflected by the conferencing features, the conference information, as defined in the
data model defined in [16], contains additional data beyond that data model [16], contains additional data beyond that defined in the
defined in [9]. The information defined in [16] provides specific SIP conference event package [9]. The information defined in the
media mixing details, available floor controls and other data data model [16] provides specific media mixing details, available
necessary to support enhanced conferencing features. This floor controls and other data necessary to support enhanced
information allows authorized clients to manipulate the mixer's conferencing features. This information allows authorized clients to
behavior via the focus, with the resultant distribution of the media manipulate the mixer's behavior via the focus, with the resultant
to all or individual participants. By doing so, a client can change distribution of the media to all or individual participants. By
its own state and/or state of other participants in the conference. doing so, a client can change its own state and/or the state of other
participants in the conference.
New centralized conferencing specifications can extend the basic New centralized conferencing specifications can extend the basic
conference-type as defined in [16] and introduce additional data conference-type as defined in the data model [16] and introduce
elements to be used within the conference information type. additional data elements to be used within the conference information
type.
4.2. Conference policies 4.2. Conference policies
Conference policies collectively refers to a set of rights, Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed permissions and limitations pertaining to operations being performed
on a certain conference object. on a certain conference object.
The set of rights describes the read/write access privileges for the The set of rights describes the read/write access privileges for the
conference object as a whole. This access would usually be granted conference object as a whole. This access would usually be granted
and defined in terms of giving the read-only or read-write access to and defined in terms of giving the read-only or read-write access to
skipping to change at page 13, line 46 skipping to change at page 13, line 49
during an active conference. Each conference object is independently during an active conference. Each conference object is independently
addressable through the conference control protocol interface addressable through the conference control protocol interface
[Section 7.3]. [Section 7.3].
Figure 3 illustrates the relationships between the conference Figure 3 illustrates the relationships between the conference
identifier, the focus and the conference object ID within the context identifier, the focus and the conference object ID within the context
of a logical conference instance, with the conference object of a logical conference instance, with the conference object
corresponding to an active conference. corresponding to an active conference.
A conference object representing a conference in the active state can A conference object representing a conference in the active state can
have multiple call signaling conference identifiers; for example, for have multiple call signaling conference identifiers; for example, one
each call signaling protocol supported. There is a one-to-one for each call signaling protocol supported. There is a one-to-one
mapping between an active conference object and a conference focus. mapping between an active conference object and a conference focus.
The focus is addressed by explicitly associating unique conference The focus is addressed by explicitly associating unique conference
IDs for each signaling protocol supported by the active conference IDs for each signaling protocol supported by the active conference
object. object.
.................................................................... ....................................................................
. Conference Instance . . Conference Instance .
. . . .
. . . .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
skipping to change at page 14, line 24 skipping to change at page 14, line 27
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
. ^ ^ . . ^ ^ .
. | | . . | | .
. v | . . v | .
. ................................................... | . . ................................................... | .
. . Focus . | . . . Focus . | .
. . . | . . . . | .
. . +----------------------------------+ . | . . . +----------------------------------+ . | .
. . |Conference Identifier (Protocol Y)| . | . . . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | . . . +------------------------------------+ | . | .
. . | Conference Identifier (PSTN) | | . | . . . | Conference Identifier (ISUP) | | . | .
. . +--------------------------------------+ |-+ . | . . . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | . . . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | . . . | |-+| . | .
. . | |^ | . | . . . | |^ | . | .
. . +--------------------------------------+| | . | . . . +--------------------------------------+| | . | .
. ............^...............................|.|.... | . . ............^...............................|.|.... | .
. | | | | . . | | | | .
................|...............................|.|......|.......... ................|...............................|.|......|..........
| | | | | | | |
|SIP | | |Conference |SIP | | |Conference
| PSTN | |Y |Control | ISUP | |Y |Control
| | | |Protocol | | | |Protocol
| +---------------+ | | | +---------------+ | |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----------------+ +--------------+ +---------------+ +----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference | | Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client | | Client | | Client | | Client |
| 1 | | 2 | | X | | 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+ +----------------+ +--------------+ +---------------+
skipping to change at page 15, line 33 skipping to change at page 15, line 34
may have a pre-configured conference object identifier to access the may have a pre-configured conference object identifier to access the
conferencing system or other signaling protocols may be used and the conferencing system or other signaling protocols may be used and the
conferencing system maps those to a specific conference object conferencing system maps those to a specific conference object
identifier. Once a conference is established, a conference object identifier. Once a conference is established, a conference object
identifier is required for the user to manipulate any of the identifier is required for the user to manipulate any of the
conferencing data or take advantage of any of the advanced conferencing data or take advantage of any of the advanced
conferencing features. The same notion applies to users joining a conferencing features. The same notion applies to users joining a
conference using other signaling protocols. They are able to conference using other signaling protocols. They are able to
initially join a conference using any of the other signaling initially join a conference using any of the other signaling
protocols supported by the specific conferencing system, but the protocols supported by the specific conferencing system, but the
conference object identifer must be used to manipulate any of the conference object identifier must be used to manipulate any of the
conferencing data or take advantage of any of the advanced conferencing data or take advantage of any of the advanced
conferencing features. As mentioned previously, the mechanism by conferencing features. As mentioned previously, the mechanism by
which the user learns of the conference object identifier varies and which the user learns of the conference object identifier varies and
could be via the conference control protocol, using the data model could be via the conference control protocol, using the data model
and conference package or entirely out of band such as E-Mail or a and conference package or entirely out of band such as E-Mail or a
web interface. web interface.
The conference object identifier logically maps to other protocol The conference object identifier logically maps to other protocol
specific identifiers associated with the conference instance, such as specific identifiers associated with the conference instance, such as
the BFCP 'confid'. The conference object identifier is defined in the BFCP 'confid'. The conference object identifier is defined in
skipping to change at page 16, line 11 skipping to change at page 16, line 13
association with the conference object identifier to uniquely association with the conference object identifier to uniquely
identify a user within the scope of conferencing system. There is identify a user within the scope of conferencing system. There is
also a requirement for identifying conferencing system users who may also a requirement for identifying conferencing system users who may
not be participating in a conference instance. Examples of these not be participating in a conference instance. Examples of these
users would be a non participating 'Floor Control Chair' or 'Media users would be a non participating 'Floor Control Chair' or 'Media
Policy Controller'. The conference user identifier is required in Policy Controller'. The conference user identifier is required in
conference control protocol requests to uniquely determine who is conference control protocol requests to uniquely determine who is
issuing commands, so that appropriate policies can be applied to the issuing commands, so that appropriate policies can be applied to the
requested command. requested command.
A typical mode for distributing the user identifer is out of band A typical mode for distributing the user identifier is out of band
during conferencing client configuration, thus the mechanism is during conferencing client configuration, thus the mechanism is
outside the scope of the centralized conferencing framework and outside the scope of the centralized conferencing framework and
protocols. However, a conferencing system must also be capable of protocols. However, a conferencing system must also be capable of
allocating and distributing a user identifier during the first allocating and distributing a user identifier during the first
signaling interaction with the conferencing system, such as an signaling interaction with the conferencing system, such as an
initial request for blueprints or adding a new user to an existing initial request for blueprints or adding a new user to an existing
conference using the conference control protocol. When a user joins conference using the conference control protocol. When a user joins
a conference using a signaling specific protocol, such as SIP for a a conference using a signaling specific protocol, such as SIP for a
dial-in conference, a conference user identifier must be assigned if dial-in conference, a conference user identifier must be assigned if
one is not already associated with that user. While this conference one is not already associated with that user. While this conference
user identifier isn't required for the participant to join the user identifier isn't required for the participant to join the
conference, it is required to be allocated and assigned by the conference, it is required to be allocated and assigned by the
conferencing system such that it is available for use for any conferencing system such that it is available for use for any
subsequent conference control protocol operations and/or subsequent conference control protocol operations and/or
notifications associated with that conference. For example, the notifications associated with that conference. For example, the
conference user identifer would be sent in any notifications that may conference user identifier would be sent in any notifications that
be sent to existing participants, such as the moderator, when this may be sent to existing participants, such as the moderator, when
user joins. this user joins.
The conference user identifier is logically associated with the other The conference user identifier is logically associated with the other
user identifiers assigned to the conferencing client for other user identifiers assigned to the conferencing client for other
protocol interfaces, such as an authenticated SIP user. The protocol interfaces, such as an authenticated SIP user. The
conference user identifier is defined in [16]. conference user identifier is defined in [16].
6. Conferencing System Realization 6. Conferencing System Realization
Implementations based on this centralized conferencing framework can Implementations based on this centralized conferencing framework can
range from systems supporting ad-hoc conferences, with default range from systems supporting ad-hoc conferences, with default
skipping to change at page 17, line 51 skipping to change at page 18, line 5
typical conference setting supported by the system. Each system can typical conference setting supported by the system. Each system can
maintain multiple blueprints, typically each describing a different maintain multiple blueprints, typically each describing a different
conferencing type using the conference information format. This conferencing type using the conference information format. This
document uses the "cloning" metaphor instead of the "inheritance" document uses the "cloning" metaphor instead of the "inheritance"
metaphor because it more closely fits the idea of object replication, metaphor because it more closely fits the idea of object replication,
rather than a data type re-usage and extension concept. rather than a data type re-usage and extension concept.
The cloning operation needs to specify whether the link between the The cloning operation needs to specify whether the link between the
parent and the child needs to be maintained in the system or not. If parent and the child needs to be maintained in the system or not. If
no link between the parent and the child exists, the objects become no link between the parent and the child exists, the objects become
independent and are not impacted by any operations on the parent independent and the child is not impacted by any operations on the
object nor subject to any limitations of the parent object. parent object nor subject to any limitations of the parent object.
Once the new object is created, it can be addressed by a unique Once the new object is created, it can be addressed by a unique
conference object URI assigned by the system, as described in conference object URI assigned by the system, as described in
Section 5.2.1. By default, the newly created object contains all the Section 5.2.1. By default, the newly created object contains all the
data existing in the parent object. The newly created object can data existing in the parent object. The newly created object can
expand the data it contains, within the schema types supported by the expand the data it contains, within the schema types supported by the
parent. It can also restrict the read/write access to its objects. parent. It can also restrict the read/write access to its objects.
However, unless the object is independent, it cannot modify the However, unless the object is independent, it cannot modify the
access restrictions imposed by the parent object. access restrictions imposed by the parent object.
skipping to change at page 19, line 37 skipping to change at page 19, line 37
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
| | | |
| | | |
| --------------------------- | ---------------------------
| | | |
V V V V
+---+-----------------------+ +---+-----------------------+ +---+-----------------------+ +---+-----------------------+
| p | | | p | | | p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 | | o | C H I L D 1 | | o | C H I L D 2 |
| i | | | l | | | l | | | 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 O N F E R E N C E | | i | C O N F E R E N C E |
| i | | | c | | | c | | | c | |
| c | O B J E C T | | i | O B J E C T | | i | O B J E C T | | i | O B J E C T |
| i | | | e | | | e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+
Figure 4: The Cloning Tree. Figure 4: The Cloning Tree.
Using the defined cloning model and its tools, the following sections Using the defined cloning model and its tools, the following sections
show examples of how different systems based on this framework can be show examples of how different systems based on this framework can be
realized. realized.
6.2. Ad-hoc Example 6.2. Ad-hoc Example
skipping to change at page 20, line 23 skipping to change at page 20, line 23
body. body.
The selected blueprint with its default values is copied by the The selected blueprint with its default values is copied by the
server into a newly created conference object, referred to as an server into a newly created conference object, referred to as an
'Active Conference'. At this point the conference object becomes 'Active Conference'. At this point the conference object becomes
independent from its blueprint. A new conference object identifier, independent from its blueprint. A new conference object identifier,
a new conference identifier and a new focus are allocated by the a new conference identifier and a new focus are allocated by the
server. server.
During the conference lifetime, an authorized client can manipulate During the conference lifetime, an authorized client can manipulate
the conference object, such as adding participants, using the the conference object, by performing operations such as adding
Conference Control Protocol. participants, using the Conference Control Protocol.
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | System Default | | o | System Default |
| l | | | l | |
| i | Conference | | i | Conference |
| c | | | c | |
| i | Blueprint | | i | Blueprint |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
skipping to change at page 49, line 44 skipping to change at page 49, line 44
policies associated with that specific conference object to perform policies associated with that specific conference object to perform
the operation. Based upon the addressing information provided for the operation. Based upon the addressing information provided for
"Bob" by "Alice", the call signaling to add "Bob" to the sidebar with "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with
the appropriate media characteristics is instigated through the the appropriate media characteristics is instigated through the
Focus. Focus.
"Bob" is notified of his addition to the sidebar via the conference "Bob" is notified of his addition to the sidebar via the conference
notification service, thus he is aware that "Alice" the supervisor is notification service, thus he is aware that "Alice" the supervisor is
available for coaching him through this call. available for coaching him through this call.
9. Relationships between SIPPING and Centralized Conferencing 9. Relationships between SIP and Centralized Conferencing Frameworks
Frameworks
The SIPPING Conferencing Framework [8] provides an overview of a wide The SIP Conferencing Framework [8] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIP Conferencing Framework are used to
to illustrate how SIP [2] can be used as a signaling means in these illustrate how SIP [2] can be used as a signaling means in these
conferencing systems. SIPPING Conferencing Framework does not define conferencing systems. The SIP Conferencing Framework does not define
new conference control protocols to be used by the general new conference control protocols to be used by the general
conferencing system. It uses only basic SIP [2], the SIP conferencing system. It uses only basic SIP [2], the SIP
Conferencing for User Agents [12], and the SIPPING Conference Package Conferencing for User Agents [12], and the SIP Conference Package [9]
[9] for basic SIP conferencing realization. for basic SIP conferencing realization.
This centralized conferencing framework document defines a particular This centralized conferencing framework document defines a particular
centralized conferencing system and the logical entities implementing centralized conferencing system and the logical entities implementing
it. It also defines a particular data model and refers to the set of it. It also defines a particular data model and refers to the set of
protocols (beyond call signaling means) being defined by the XCON WG protocols (beyond call signaling means) to be used among the logical
to be used among the logical entities for implementing advanced entities for implementing advanced conferencing features. The
conferencing features. The purpose of the XCON working group and purpose of the XCON working group and this framework is to achieve
this framework is to achieve interoperability between the logical interoperability between the logical entities from different vendors
entities from different vendors for controlling different aspects of for controlling different aspects of advanced conferencing
advanced conferencing applications. applications.
The logical entities defined in the two frameworks are not intended The logical entities defined in the two frameworks are not intended
to be mapped one-to-one. The two frameworks differ in the to be mapped one-to-one. The two frameworks differ in the
interpretation of the internal conferencing system decomposition and interpretation of the internal conferencing system decomposition and
the corresponding operations. Nevertheless, the basic SIP [2], the the corresponding operations. Nevertheless, the basic SIP [2], the
SIP Conferencing for User Agents [12], and the SIPPING Conference SIP Conferencing for User Agents [12], and the SIP Conference Package
Package [9] are fully compatible with both Framework documents. [9] are fully compatible with both Framework documents.
10. Security Considerations 10. Security Considerations
There are a wide variety of potential attacks related to There are a wide variety of potential attacks related to
conferencing, due to the natural involvement of multiple endpoints conferencing, due to the natural involvement of multiple endpoints
and the many, often user-invoked, capabilities provided by the and the many, often user-invoked, capabilities provided by the
conferencing system. Examples of attacks include the following: an conferencing system. Examples of attacks include the following: an
endpoint attempting to listen to conferences in which it is not endpoint attempting to listen to conferences in which it is not
authorized to participate, an endpoint attempting to disconnect or authorized to participate, an endpoint attempting to disconnect or
mute other users, and theft of service, by an endpoint, in attempting mute other users, and theft of service by an endpoint in attempting
to create conferences it is not allowed to create. to create conferences it is not allowed to create.
There are several issues surrounding security of this conferencing There are several issues surrounding security of this conferencing
framework. One set of issues involves securing the actual protocols framework. One set of issues involves securing the actual protocols
and the associated authorization mechanisms. This first set of and the associated authorization mechanisms. This first set of
issues should be addressed in the specifications specific to the issues should be addressed in the specifications specific to the
protocols described in Section 7. The protocols used for protocols described in Section 7. The protocols used for
manipulation and retrieval of confidential information MUST support a manipulation and retrieval of confidential information need to
confidentiality and integrity mechanism. Similar requirements apply support a confidentiality and integrity mechanism. Similar
for the floor control protocols. Section 10.3 discusses an approach requirements apply for the floor control protocols. Section 10.3
for client authentication of a floor control server. discusses an approach for client authentication of a floor control
server.
There are also security issues associated with the authorization to There are also security issues associated with the authorization to
perform actions on the conferencing system to invoke specific perform actions on the conferencing system to invoke specific
capabilities. Section 4.2 discusses the policies associated with the capabilities. Section 4.2 discusses the policies associated with the
conference object to ensure that only authorized entities are able to conference object to ensure that only authorized entities are able to
manipulate the data to access the capabilities. The final set of manipulate the data to access the capabilities. The final set of
issues involves the privacy and security of the identity of a user in issues involves the privacy and security of the identity of a user in
the conference, which is discussed in Section 10.2 the conference, which is discussed in Section 10.2
10.1. Authorization 10.1. Authorization
skipping to change at page 52, line 33 skipping to change at page 52, line 33
"anonymous" parties are in the conference. Note, that the visibility "anonymous" parties are in the conference. Note, that the visibility
to other participants is dependent on their roles. For example, to other participants is dependent on their roles. For example,
users' visibility (including "anonymous" and "hidden") may be users' visibility (including "anonymous" and "hidden") may be
displayed to the moderator or administrator, subject to a displayed to the moderator or administrator, subject to a
conferencing system's local policies. "Hidden" status is often used conferencing system's local policies. "Hidden" status is often used
by automated or machine participants of a conference (e.g., call by automated or machine participants of a conference (e.g., call
recording) and is also used in many call center situations. recording) and is also used in many call center situations.
10.3. Floor Control Server Authentication 10.3. Floor Control Server Authentication
Clients can authenticate a floor control server using the TLS The floor control protocol contains mechanisms that clients can use
certificates. Requests submitted on a successfully created to authenticate servers and that servers can use to authenticate
connection between the client and floor control server may clients, as described in section 9 of RFC 4582 [13]. The precise
additionally require digest authentication within the BFCP protocol mechanisms used for such authentication can vary depending on the
to authenticate the floor control client to the server. For this to call control protocol used. Clients using call control protocols
take place, a shared secret needs to be exchanged between the floor that employ an SDP offer/answer model, such as SIP, use the mechanism
control client/server entities. This can be achieved out of band described in section 8 of RFC 4583 [15]. Clients using other call
using a mechanism such as the 'k=' SDP attribute. The shared secret control protocols make use of the mechanisms described in the BFCP
can also be exchanged using un-specified 'out of band' mechanisms. Connection Establishment document [18].
When using Digest authentication of floor control client messages the
exchange of an active 'Nonce' is also required. This can be achieved
using a BFCP request response interaction as defined in BFCP (A
request is submitted without a Nonce TLV and the server generates an
error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value
can also be obtained 'out of band' using information provided in the
offer/answer exchange. As with the other SDP Floor attributes
referenced in this section and defined in [15], the 'nonce' attribute
can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj.
11. IANA Considerations 11. IANA Considerations
This is an informational draft, with no IANA considerations required. This document requires no action on the part of IANA.
12. Acknowledgements 12. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan
Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and
Gonzalo Camarillo for their reviews and constructive input. Gonzalo Camarillo for their reviews and constructive input.
13. Changes since last Version 13. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 08 to 09 (chair PROTO review comments):
1) Changed Intended Status to standards track.
2) Updated IANA section per 1).
3) Removed normative language (i.e., "must" in CAPS in section 10)
4) Updated section 10.3 (Floor Control authentication) to be more
general based on changes to the final BFCP authentication mechanism.
5) Miscellaneous editorial nits - it is amazing after all these
reviews, how many were still there!
Changes from WG 07 to 08 (post-WGLC comments, reflecting IETF-68 Changes from WG 07 to 08 (post-WGLC comments, reflecting IETF-68
discussions on policy): discussions on policy):
1) added Intended Status as Informational. 1) added Intended Status as Informational.
2) Removed data model from Title and clarified reference to data 2) Removed data model from Title and clarified reference to data
model in this document as "high level data model". Renamed section 5 model in this document as "high level data model". Renamed section 5
from "Centralized Conferencing Data Model" to "Centralized from "Centralized Conferencing Data Model" to "Centralized
Conferencing Data". Conferencing Data".
skipping to change at page 62, line 5 skipping to change at page 62, line 6
November 2006. November 2006.
[16] Novo, O., "Conference Information Data Model for Centralized [16] Novo, O., "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-05 Conferencing (XCON)", draft-ietf-xcon-common-data-model-05
(work in progress), April 2007. (work in progress), April 2007.
[17] Campbell, B., "The Message Session Relay Protocol", [17] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress), draft-ietf-simple-message-sessions-19 (work in progress),
February 2007. February 2007.
[18] Camarillo, G., "Connection Establishment in the Binary Floor
Control Protocol (BFCP)", draft-ietf-xcon-bfcp-connection-05
(work in progress), July 2007.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
 End of changes. 42 change blocks. 
124 lines changed or deleted 134 lines changed or added

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