draft-ietf-xcon-framework-06.txt   draft-ietf-xcon-framework-07.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational C. Boulton Expires: July 26, 2007 C. Boulton
Expires: June 7, 2007 Ubiquity Software Corporation Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
December 4, 2006 January 22, 2007
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-06 draft-ietf-xcon-framework-07
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 June 7, 2007. This Internet-Draft will expire on July 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
a centralized unicast conference. The Centralized Conferencing a centralized unicast conference. The Centralized Conferencing
Framework defines logical entities and naming conventions, along with Framework defines logical entities and naming conventions, along with
a conferencing data model. The framework also outlines a set of a 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
protocols, for building advanced conferencing applications. The protocols, for building advanced conferencing applications. The
framework binds all the defined components together for the benefit framework binds all the defined components together for the benefit
of builders of conferencing systems. of builders of conferencing systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Centralized Conferencing Data Model . . . . . . . . . . . . . 9 5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10
5.1. Common Conference Information . . . . . . . . . . . . . . 11 5.1. Common Conference Information . . . . . . . . . . . . . . 11
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12 5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 12 6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 12 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 12
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 45 9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 45
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 50 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 50
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 51 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 51
11.3. Floor Control Server Authentication . . . . . . . . . . . 51 11.3. Floor Control Server Authentication . . . . . . . . . . . 51
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
14. Changes since last Version . . . . . . . . . . . . . . . . . . 52 14. Changes since last Version . . . . . . . . . . . . . . . . . . 52
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
15.1. Normative References . . . . . . . . . . . . . . . . . . . 58 15.1. Normative References . . . . . . . . . . . . . . . . . . . 59
15.2. Informative References . . . . . . . . . . . . . . . . . . 58 15.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . . . . 62
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
a centralized unicast conference. Other than references to general a centralized unicast conference. Other than references to general
functionality (e.g., establishment and teardown), details of these functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document call signaling protocols are outside the scope of this document
skipping to change at page 8, line 16 skipping to change at page 8, line 16
conference setting supported by the system. A conference conference setting supported by the system. A conference
blueprint is the basis for creation of dynamic conference objects. blueprint is the basis for creation of dynamic conference objects.
A system may maintain multiple blueprints. Each blueprint is A system may maintain multiple blueprints. Each blueprint is
comprised of the initial values and ranges for the elements in the comprised of the initial values and ranges for the elements in the
object, conformant to the data schemas for the common conference object, conformant to the data schemas for the common conference
information. 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 upon request, unique URI(s) to identify and represent a generates unique URI(s) to identify and represent a conference
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 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
object, which is created from either a system default or client object, which is created from either a system default or client
selected blueprint. selected blueprint.
Conference state: The conference state reflects the state of a Conference state: The conference state reflects the state of a
conference instance and is represented using a specific, well- conference instance and is represented using a specific, well-
defined schema. defined schema.
Conferencing system: Conferencing system refers to a conferencing Conferencing system: Conferencing system refers to a conferencing
solution based on the data model discussed in this framework solution based on the data model discussed in this framework
document and built using the protocol specifications referenced in document and built using the protocol specifications referenced in
this framework document. this framework document.
Conference user identifier (ID): A unique identifier for a user
within the scope of a conferencing system. A user may have
multiple conference user identifiers within a conferencing system
(e.g., to represent different roles).
Floor: Floor refers to a set of data or resources associated with a 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
signalling interface with each participating client and the signalling interface with each participating client and the
skipping to change at page 26, line 42 skipping to change at page 26, line 42
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
[16] this identifier maps to the 'confid' SDP attribute. [16] this identifier maps to the 'confid' SDP attribute.
Each authorized user associated with a conference object is uniquely Each authorized user associated with a conference object is uniquely
represented by a conference user ID per Section 6.3. This conference represented by a conference user ID per Section 6.3. This conference
user ID must be included in all floor control messages. When using user ID must be included in all floor control messages. When using
SDP offer/answer exchange to negotiate a Floor control connection SDP offer/answer exchange to negotiate a Floor control connection
with the focus using the call signaling protocol, the unique with the focus using the call signaling protocol, the unique
conference identifier is contained in the 'userid' SDP attribute, as conference user identifier is contained in the 'userid' SDP
defined in [16] attribute, as defined in [16]
A media session within a conferencing system can have any number of A media session within a conferencing system can have any number of
floors (0 or more) that are represented by the conference identifer. floors (0 or more) that are represented by the conference identifer.
When using SDP offer/answer exchange to negotiate a floor control When using SDP offer/answer exchange to negotiate a floor control
connection with the focus using the call signaling interface, the connection with the focus using the call signaling interface, the
unique conference identifier is contained in the 'floorid' SDP unique conference identifier is contained in the 'floorid' SDP
attribute, as defined in [16] e.g., a=floorid:1 m-stream:10 . Each attribute, as defined in [16] 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
skipping to change at page 27, line 17 skipping to change at page 27, line 17
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 [12], are realized using this which have been described in [12], are realized using this
centralized conferencing framework. The objective of this section is centralized conferencing framework. The objective of this section is
to further illustrate the model, mechanisms and protocols presented to further illustrate the model, mechanisms and protocols presented
in the previous sections and also serves to validate that the model, in the previous sections and also serves to validate that the model,
mechanisms and protocols are sufficient to support advanced mechanisms and protocols are sufficient to support advanced
conferencing scenarios. conferencing scenarios.
The details shown in the messages are for illustrative purposes only The scenarios provide a high level primitive view of the necessary
and don't reflect the structure of the conference control protocol operations and general logic flow. The details shown in the
messages, but rather provide a high level primitive view of the scenarios are for illustrative purposes only and don't necessarily
necessary operations and general logic flow, including the data reflect the actual structure of the conference control protocol
manipulation aspects. It should be noted that not all entities messages nor the detailed data, including states, which are defined
in separate documents. It should be noted that not all entities
impacted by the request are shown in the diagram (e.g., Focus), but impacted by the request are shown in the diagram (e.g., Focus), but
rather the emphasis is on the new entities introduced by this rather the emphasis is on the new entities introduced by this
centralized conferencing framework. centralized conferencing framework.
9.1. Conference Creation 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 [13]. For a conferencing client to have more flexibility detailed in [13]. 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
skipping to change at page 34, line 15 skipping to change at page 34, line 15
9.4.1. Internal Sidebar 9.4.1. Internal Sidebar
Figure 12 provides an example of one client "Alice" involved in Figure 12 provides an example of one client "Alice" involved in
active conference with "Bob" and "Carol". "Alice" wants to create a active conference with "Bob" and "Carol". "Alice" wants to create a
sidebar to have a side discussion with "Bob" while still viewing the sidebar to have a side discussion with "Bob" while still viewing the
video associated with the main conference. Alternatively, the audio video associated with the main conference. Alternatively, the audio
from the main conference could be maintained at a reduced volume. from the main conference could be maintained at a reduced volume.
"Alice" initiates the sidebar by sending a request to the "Alice" initiates the sidebar by sending a request to the
conferencing system to create a conference reservation based upon the conferencing system to create a conference reservation based upon the
active conference object. "Alice" and "Bob" would remain on the active conference object. "Alice" and "Bob" would remain on the
roster of the main conference such that the other participants would roster of the main conference, such that other participants could be
be unaware of the sidebar. aware of their participation in the main conference, while an
internal-sidebar conference is occurring.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
| |Conference || | |Conference ||
"Alice" | +-------+ || "Alice" | +-------+ ||
+--------+ | |"Alice"| || +--------+ | |"Alice"| ||
skipping to change at page 36, line 36 skipping to change at page 36, line 36
the audio from the main conference at a reduced volume. "Alice" the audio from the main conference at a reduced volume. "Alice"
sends a conference control protocol request to update the information sends a conference control protocol request to update the information
in the reservation and to create an active conference. in the reservation and to create an active conference.
Upon receipt of the conference control protocol request to update the Upon receipt of the conference control protocol request to update the
reservation and to create an active conference for the sidebar, as reservation and to create an active conference for the sidebar, as
identified by the conference object ID, the conferencing system identified by the conference object ID, the conferencing system
ensures that "Alice" has the appropriate authority based on the ensures that "Alice" has the appropriate authority based on the
policies associated with that specific conference object to perform policies associated with that specific conference object to perform
the operation. The conferencing system must also validate the the operation. The conferencing system must also validate the
updated information in the reservation, ensuring whether members like updated information in the reservation, ensuring that a member like
"Bob" are already a user of this conferencing system or whether he is "Bob" is already a user of this conferencing system.
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., Depending upon the policies, the initiator of the request (i.e.,
"Bob") may be notified of his addition to the sidebar via the "Alice") and the participants in the sidebar (i.e., "Bob") may be
conference notification service. notified of his addition to the sidebar via the conference
notification service.
9.4.2. External Sidebar 9.4.2. External Sidebar
Figure 13 provides an example of one client "Alice" involved in an Figure 13 provides an example of one client "Alice" involved in an
active conference with "Bob", "Carol", "David" and "Ethel". "Alice" active conference with "Bob", "Carol", "David" and "Ethel". "Alice"
gets an important text message via a whisper from "Bob" that a gets an important text message via a whisper from "Bob" that a
critical customer needs to talk to "Alice", "Bob" and "Ethel". critical customer needs to talk to "Alice", "Bob" and "Ethel".
"Alice" creates a sidebar to have a side discussion with the customer "Alice" creates a sidebar to have a side discussion with the customer
"Fred" including the participants in the current conference with the "Fred" including the participants in the current conference with the
exception of "Carol" and "David", who remain in the active exception of "Carol" and "David", who remain in the active
skipping to change at page 39, line 14 skipping to change at page 39, line 10
policies associated with that specific conference object to perform policies associated with that specific conference object to perform
the operation. The conferencing system must also validate the the operation. The conferencing system must also validate the
updated information in the reservation, ensuring whether members like updated information in the reservation, ensuring whether members like
"Fred" are already a user of this conferencing system or whether he "Fred" are already a user of this conferencing system or whether he
is a new user. Since "Fred" is a new user for this conferencing is a new user. Since "Fred" is a new user for this conferencing
system, a conference user identifier is created for "Fred". Based system, a conference user identifier is created for "Fred". Based
upon the addressing information provided for "Fred" by "Alice", the upon the addressing information provided for "Fred" by "Alice", the
call signaling to add "Fred" to the conference is instigated through call signaling to add "Fred" to the conference is instigated through
the Focus. the Focus.
Depending upon the policies, the participants in the sidebar (i.e., Depending upon the policies, the initiator of the request (i.e.,
"Bob" and "Ethel") may be notified of his addition to the sidebar via "Alice") and the participants in the sidebar (i.e., "Bob" and
the conference notification service. "Ethel") may be notified of his addition to the sidebar via the
conference notification service.
9.5. Floor control using sidebars 9.5. Floor control using sidebars
Floor control with sidebars can be used to realize conferencing Floor control with sidebars can be used to realize conferencing
scenario such as an analyst briefing. In this scenario, the scenario such as an analyst briefing. In this scenario, the
conference call has a panel of speakers who are allowed to talk in conference call has a panel of speakers who are allowed to talk in
the main conference. The other participants are the analysts, who the main conference. The other participants are the analysts, who
are not allowed to speak unless they have the floor. To request are not allowed to speak unless they have the floor. To request
access to the floor, they have to join a new sidebar with the access to the floor, they have to join a new sidebar with the
moderator and ask their question. The moderator can also whisper to moderator and ask their question. The moderator can also whisper to
skipping to change at page 39, line 47 skipping to change at page 39, line 44
the active conference (i.e., parent). The analysts are provided the the active conference (i.e., parent). The analysts are provided the
conference object ID associated with the active sidebar when they conference object ID associated with the active sidebar when they
join the main conference. The conferencing system also allocates a join the main conference. The conferencing system also allocates a
conference ID to be used for any subsequent manipulations of the conference ID to be used for any subsequent manipulations of the
sidebar conference. The conferencing system maintains the mapping sidebar 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 active sidebar conference through the conference instance. with the active sidebar conference through the conference instance.
The analysts are permanently muted while in the main conference. The The analysts are permanently muted while in the main conference. The
analysts are moved to the sidebar when they wish to speak. Only one analysts are moved to the sidebar when they wish to speak. Only one
analyst is given the floor at a given time. All participants in the analyst is given the floor at a given time. All participants in the
sidebar conference receive audio from the main conference. main conference receive audio from the sidebar conference, as well as
audio provided by the panelists in the main conference.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
| |Conference || | |Conference ||
| +-------+ || | +-------+ ||
| |"Alice"| || | |"Alice"| ||
skipping to change at page 46, line 19 skipping to change at page 46, line 19
Taking the supervisor capability one step further introduces a Taking the supervisor capability one step further introduces a
scenario whereby the agent can hear the supervisor, as well as the scenario whereby the agent can hear the supervisor, as well as the
customer. The customer can still only hear the agent. This scenario customer. The customer can still only hear the agent. This scenario
would involve the creation of a sidebar involving the agent and the would involve the creation of a sidebar involving the agent and the
supervisor. Both the agent and supervisor receive the audio from the supervisor. Both the agent and supervisor receive the audio from the
main conference. When the agent speaks, it is heard by the customer main conference. When the agent speaks, it is heard by the customer
in the main conference. When the supervisor speaks, it is heard only in the main conference. When the supervisor speaks, it is heard only
by the agent in the sidebar conference. by the agent in the sidebar conference.
An example of observing and coachin is shown in figure Figure 17. In An example of observing and coaching is shown in figure Figure 17.
this example, call center agent "Bob" is involved in a conference In this example, call center agent "Bob" is involved in a conference
with customer "Carol". Since "Bob" is a new agent and "Alice" sees with customer "Carol". Since "Bob" is a new agent and "Alice" sees
that he has been on the call with "Carol" for longer than normal, she that he has been on the call with "Carol" for longer than normal, she
decides to observe the call and coach "Bob" as necessary. decides to observe the call and coach "Bob" as necessary.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
skipping to change at page 52, line 17 skipping to change at page 52, line 17
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
13. Acknowledgements 13. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan
Mahy, Brian Rosen and Pierre Tane for their reviews and constructive Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes for
input. their reviews and constructive input.
14. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 06 to 07 (WGLC comments):
1) Section 4: Added definition for Conference User Identifier,
including concept of a single user having multiple identifiers.
2) Section 9: Clarified text to indicate that details of message
flows are illustrative and exact states, etc. will be defined by the
detailed data model, etc.
3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster
of main conference while in sidebar.Clarified text that Bob must
already be a user of the conferencing system for internal sidebar
scenario.
4) Section 9.4.1/9.4.2: Clarified text in last paragraph to indicated
that notifications may also go to the initial requestor.
5) Section 9.5: Clarified text to explicitly state that sidebar
participants also receive the audio from the main conference.
6) Fixed Editorial nits including updating references to published
RFC numbers and miscellaneous typos.
Changes from WG 05 to 06: Changes from WG 05 to 06:
1) Section 9.4.2: Added a statement that whether the hold state is 1) Section 9.4.2: Added a statement that whether the hold state is
visible to other participants is subject to user and local policy. visible to other participants is subject to user and local policy.
2) Fixed Editorial nits including updating references to published 2) Fixed Editorial nits including updating references to published
RFC numbers, adding references for userid and uri definitions, RFC numbers, adding references for userid and uri definitions,
removing unused references, fixing names in detailed scenarios removing unused references, fixing names in detailed scenarios
(section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as (section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as
moderator), aligning with data model (section 9.5: "allowed to join" moderator), aligning with data model (section 9.5: "allowed to join"
skipping to change at page 59, line 34 skipping to change at page 60, line 7
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376,
February 2006. February 2006.
[12] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, [12] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597,
August 2006. August 2006.
[13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) [13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", BCP 119, Call Control - Conferencing for User Agents", BCP 119,
RFC 4579, August 2006. RFC 4579, August 2006.
[14] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [14] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
draft-ietf-xcon-bfcp-06 (work in progress), December 2005. Protocol (BFCP)", RFC 4582, November 2006.
[15] Levin, O. and G. Camarillo, "The Session Description Protocol [15] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006. (SDP) Label Attribute", RFC 4574, August 2006.
[16] Camarillo, G., "Session Description Protocol (SDP) Format for [16] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
draft-ietf-mmusic-sdp-bfcp-03 (work in progress), November 2006.
December 2005.
[17] Novo, O., "A Common Conference Information Data Model for [17] Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing (XCON)", Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-03 (work in progress), draft-ietf-xcon-common-data-model-03 (work in progress),
October 2006. October 2006.
[18] Campbell, B., "The Message Session Relay Protocol", [18] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-16 (work in progress), draft-ietf-simple-message-sessions-18 (work in progress),
October 2006. December 2006.
[19] Boulton, C. and M. Barnes, "A Universal Resource Identifier [19] Boulton, C. and M. Barnes, "A Universal Resource Identifier
(URI) for Centralized Conferencing (XCON)", (URI) for Centralized Conferencing (XCON)",
draft-boulton-xcon-uri-00 (work in progress), October 2006. draft-boulton-xcon-uri-00 (work in progress), October 2006.
[20] Boulton, C. and M. Barnes, "A User Identifier for Centralized [20] Boulton, C. and M. Barnes, "A User Identifier for Centralized
Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in
progress), October 2006. progress), October 2006.
Authors' Addresses Authors' Addresses
skipping to change at page 61, line 7 skipping to change at page 62, line 7
Orit Levin Orit Levin
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: oritl@microsoft.com Email: oritl@microsoft.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 25 change blocks. 
53 lines changed or deleted 79 lines changed or added

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