draft-ietf-xcon-framework-05.txt   draft-ietf-xcon-framework-06.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Informational C. Boulton Intended status: Informational C. Boulton
Expires: March 15, 2007 Ubiquity Software Corporation Expires: June 7, 2007 Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
September 11, 2006 December 4, 2006
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-05 draft-ietf-xcon-framework-06
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 March 15, 2007. This Internet-Draft will expire on June 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
skipping to change at page 2, line 33 skipping to change at page 2, line 33
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15
7. Conferencing System Realization . . . . . . . . . . . . . . . 15 7. Conferencing System Realization . . . . . . . . . . . . . . . 15
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 22
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 25
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 25
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 27 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 27
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 27 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 27
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 29 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 29
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 31 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 31
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 32 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 32
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 34 9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 34
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 36 9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 36
9.5. Floor control using sidebars . . . . . . . . . . . . . . . 39 9.5. Floor control using sidebars . . . . . . . . . . . . . . . 39
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 41 9.6. Whispering or Private Messages . . . . . . . . . . . . . . 41
9.7. Conference Announcements and Recordings . . . . . . . . . 43 9.7. Conference Announcements and Recordings . . . . . . . . . 43
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Normative References . . . . . . . . . . . . . . . . . . . 58 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58
15.2. Informative References . . . . . . . . . . . . . . . . . . 58 15.2. Informative References . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in
a centralized unicast conference. Other than references to general a centralized unicast conference. Other than references to general
functionality (e.g., establishment and teardown), details of these functionality (e.g., establishment and teardown), details of these
call signaling protocols are outside the scope of this document call signaling protocols are outside the scope of this document
skipping to change at page 4, line 50 skipping to change at page 4, line 50
by maintaining a separate call signaling interface with each. by maintaining a separate call signaling interface with each.
Consequently, in this centralized conferencing model, the call Consequently, in this centralized conferencing model, the call
signaling graph is always a star. signaling graph is always a star.
The most basic conference supported in this model would be an ad-hoc The most basic conference supported in this model would be an ad-hoc
unmanaged conference, which would not necessarily require any of the unmanaged conference, which would not necessarily require any of the
functionality defined within this framework. For example, it could functionality defined within this framework. For example, it could
be supported using basic SIP signaling functionality with a be supported using basic SIP signaling functionality with a
participant serving as the Focus; the SIPPING Conferencing Framework participant serving as the Focus; the SIPPING Conferencing Framework
[9] together with the SIP Call Control Conferencing for User Agents [9] together with the SIP Call Control Conferencing for User Agents
[14] documents address these types of scenarios. [13] 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
[9]. These requirements are applicable for conferencing systems [8]. These requirements are applicable for conferencing systems
using various call signaling protocols, including SIP. Additional using various call signaling protocols, including SIP. Additional
conferencing requirements are provided in [12], and [13]. conferencing requirements are provided in [11], and [12].
The centralizing conferencing system proposed by this framework is The centralizing conferencing system proposed by this framework is
built around a fundamental concept of a conference object. A built around a fundamental concept of a conference object. A
conference object provides the data representation of a conference conference object provides the data representation of a conference
during each of the various stages of a conference (e.g., creation, during each of the various stages of a conference (e.g., creation,
reservation, active, completed, etc.). A conference object is reservation, active, completed, etc.). A conference object is
accessed via the logical functional elements, with whom a accessed via the logical functional elements, with whom a
conferencing client interfaces, using the various protocols conferencing client interfaces, using the various protocols
identified in Figure 1. The functional elements defined for a identified in Figure 1. The functional elements defined for a
conferencing system described by the framework are a Conference conferencing system described by the framework are a Conference
skipping to change at page 9, line 28 skipping to change at page 9, line 28
operations (e.g., join, leave, update the conference instance) and operations (e.g., join, leave, update the conference instance) and
for media negotiation/maintenance between a conference participant for media negotiation/maintenance between a conference participant
and the focus. and the focus.
Media graph: The media graph is the logical representation of the Media graph: The media graph is the logical representation of the
flow of media for a conference. flow of media for a conference.
Media mixer: A media mixer is the logical entity with the capability Media mixer: A media mixer is the logical entity with the capability
to combine media inputs of the same type, transcode the media and to combine media inputs of the same type, transcode the media and
distribute the result(s) to a single or multiple outputs. In this distribute the result(s) to a single or multiple outputs. In this
context, the term "media" means any type of data being delivered context, the term "media" means any type of data being delivered
over the network using appropriate transport means, such as RTP/ over the network using appropriate transport means, such as RTP/
RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol RTCP (defined in RFC 3550[6]) or Message Session Relay Protocol
(defined in [19]). (defined in [18]).
Role: A role provides the context for the set of conference Role: A role provides the context for the set of conference
operations that a participant can perform. A default role (e.g., operations that a participant can perform. A default role (e.g.,
standard conference participant) will always exist, providing a standard conference participant) will always exist, providing a
user with a set of basic conference operations. Based on system user with a set of basic conference operations. Based on system
specific authentication and authorization, a user may take on specific authentication and authorization, a user may take on
alternate roles, such as conference moderator, allowing access to alternate roles, such as conference moderator, allowing access to
a wider set of conference operations. a wider set of conference operations.
Sidebar: A sidebar is a separate Conference instance that only Sidebar: A sidebar is a separate Conference instance that only
exists within the context of a parent conference instance. The exists within the context of a parent conference instance. The
objective of a sidebar is to be able to provide additional or objective of a sidebar is to be able to provide additional or
skipping to change at page 11, line 17 skipping to change at page 11, line 17
membership, and by the ranges and limitations on other data elements. membership, and by the ranges and limitations on other data elements.
Additional policy considerations for a system realization based on Additional policy considerations for a system realization based on
this data model are discussed in Section 5.2. The integration of the this data model are discussed in Section 5.2. The integration of the
data in this model meets the requirement of many conference control data in this model meets the requirement of many conference control
operations to enable synchronized access to the integral conference operations to enable synchronized access to the integral conference
policies, to the conference state as a whole, and for receiving policies, to the conference state as a whole, and for receiving
notifications about changes to either using the same interface. notifications about changes to either using the same interface.
The exact XML schema of the conference object, including the The exact XML schema of the conference object, including the
organization of the common conference information is detailed in a organization of the common conference information is detailed in a
separate document [18]. separate document [17].
5.1. Common Conference Information 5.1. Common Conference Information
There is a core set of data in the common conference information that There is a core set of data in the common conference information that
is utilized in any conference, independent of the specific conference is 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 common floor control applied, etc.). This core set of data in the common
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 common conference information may be cycle. This core set of common conference information may be
represented using the conference-type as defined in [11]. Typically, represented using the conference-type as defined in [10]. Typically,
participants with read-only access to the conference information participants with read-only access to the conference information
would be interested in this core set of common conference information would be interested in this core set of common conference information
only. only.
In order to support more complex media manipulations and enhanced In order to support more complex media manipulations and enhanced
conferencing features the common conference information contains conferencing features the common conference information contains
additional data, beyond that defined in [11]. The data model defined additional data, beyond that defined in [10]. The data model defined
in [18] would be the basis for conferencing systems supporting in [17] would be the basis for conferencing systems supporting
enhanced conferencing features. The additional information defined enhanced conferencing features. The additional information defined
in [18] provides the details of the specific media mixing details, in [17] provides the details of the specific media mixing details,
the associated client roles and the available floor controls. This the associated client roles and the available floor controls. This
information would allow authorized clients to manipulate the mixer's information would allow authorized clients to manipulate the mixer's
behavior via the focus, and the resultant distribution of the media behavior via the focus, and the resultant distribution of the media
to all or individual participants. By doing so, a client can change to all or individual participants. By doing so, a client can change
its own state and/or state of other participants in the conference. its own state and/or state of other participants in the conference.
New centralized conferencing specifications can extend the basic New centralized conferencing specifications can extend the basic
conference-type as defined in [18] and introduce additional data conference-type as defined in [17] and introduce additional data
elements to be used within the common conference information type. elements to be used within the common conference information type.
5.2. Conference policies 5.2. Conference policies
Conference policies collectively refers to a set of rights, Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed permissions and limitations pertaining to operations being performed
on a certain conference object. on a certain conference object.
The set of rights describes the read/write access privileges for the The set of rights describes the read/write access privileges for the
conference object as a whole. This access would usually be granted conference object as a whole. This access would usually be granted
and defined in terms of giving the read-only or read-write access to and defined in terms of giving the read-only or read-write access to
clients with certain roles in the conference. As such, the policies clients with certain roles in the conference. As such, the policies
represented by the set of rights aren't explicitly defined within the represented by the set of rights aren't explicitly defined within the
data model, but rather are reflected in the system realization data model, but rather are reflected in the system realization
(Section 7). (Section 7).
The permissions and limits, however, are specified as an integral The permissions and limits, however, are specified as an integral
part of the conference object type, with data objects containing the part of the conference object type, with data objects containing the
allowed ranges for other data objects (e.g., maximum number of allowed ranges for other data objects (e.g., maximum number of
participants) and lists of clients allowed to perform certain participants) and lists of clients allowed to perform certain
operations on a conference object. For example, the "allowed to operations on a conference object. For example, the "allowed-users-
join" list of participants is consulted to decide who is allowed to list" of participants is consulted to decide who is allowed to join.
join. The entries in the list can specify the identity of an The entries in the list can specify the identity of an individual
individual user (joe@example.com), a role, a domain (*@example.com), user (joe@example.com), a role, a domain (*@example.com), etc. For
etc. For further details, refer to the detailed data model [18]. further details, refer to the detailed data model [17].
A more general rule mechanism, beyond the functionality provided by A more general rule mechanism, beyond the functionality provided by
the permissions and limits, is an item for future study. the permissions and limits, is an item for future study.
6. Centralized Conferencing Constructs and Identifiers 6. Centralized Conferencing Constructs and Identifiers
This section provides details of the identifiers associated with the This section provides details of the identifiers associated with the
centralized conferencing framework constructs and the identifiers centralized conferencing framework constructs and the identifiers
necessary to address and manage the clients associated with a necessary to address and manage the clients associated with a
conferencing system. An overview of the allocation, characteristics conferencing system. An overview of the allocation, characteristics
and functional role of the identifiers is provided. and functional role of the identifiers is provided.
6.1. Conference Identifier 6.1. Conference Identifier
The conference identifier (conference ID) is a call signaling The conference identifier (conference ID) is a call signaling
protocol-specific URI that identifies a specific conference focus and protocol-specific URI that identifies a specific conference focus and
its associated conference instance. A conference factory is one its associated conference instance. A conference factory is one
method for generating a unique conference ID, to identify and address method for generating a unique conference ID, to identify and address
a conference focus, using a call signaling interface. Details on the a conference focus, using a call signaling interface. Details on the
use of a conference factory for SIP signaling can be found in [14]. use of a conference factory for SIP signaling can be found in [13].
The conference identifier can also be obtained using the conference The conference identifier can also be obtained using the conference
control protocol [Section 8.3] or other, including proprietary, out- control protocol [Section 8.3] or other, including proprietary, out-
of-band mechanisms. of-band mechanisms.
6.2. Conference Object 6.2. Conference Object
A Conference object provides the logical representation of a A Conference object provides the logical representation of a
conference instance in a certain stage, such as a conference conference instance in a certain stage, such as a conference
blueprint representing a conferencing system's capabilities, the data blueprint representing a conferencing system's capabilities, the data
representing a conference reservation, and the conference state representing a conference reservation, and the conference state
skipping to change at page 15, line 15 skipping to change at page 15, line 15
6.2.1. Conference Object Identifier 6.2.1. Conference Object Identifier
In order to make each conference object externally accessible, the In order to make each conference object externally accessible, the
conferencing system allocates a unique URI per distinct conference conferencing system allocates a unique URI per distinct conference
object in the system. A conference control protocol includes the object in the system. A conference control protocol includes the
conference object identifier in requests for directly manipulating a conference object identifier in requests for directly manipulating a
particular conference object and for obtaining its current state. particular conference object and for obtaining its current state.
The conference object identifier logically maps to other protocol The conference object identifier logically maps to other protocol
specific identifiers associated with the conference instance, such as specific identifiers associated with the conference instance, such as
the BFCP 'confid'. A full description and semantics of how the the BFCP 'confid'. A full description and semantics of how the
conference object identifier is created and used as defined in [ref conference object identifier is created and used as defined in [19].
conf-uri: TBD].
6.3. Conference User Identifier 6.3. Conference User Identifier
Each user within a conferencing system is allocated a unique Each user within a conferencing system is allocated a unique
conference user identifier. The user identifier is used in conference user identifier. The user identifier is used in
association with the conference object identifier to uniquely association with the conference object identifier to uniquely
identify a user within the scope of conferencing system. There is identify a user within the scope of conferencing system. There is
also a requirement for identifying conferencing system users who may also a requirement for identifying conferencing system users who may
not be participating in a conference instance. Examples of these not be participating in a conference instance. Examples of these
users would be a non participating 'Floor Control Chair' or 'Media users would be a non participating 'Floor Control Chair' or 'Media
Policy Controller'. The conference user identifier is required in Policy Controller'. The conference user identifier is required in
conference control protocol requests to uniquely determine who is conference control protocol requests to uniquely determine who is
issuing commands, so that appropriate policies can be applied to the issuing commands, so that appropriate policies can be applied to the
requested command. The conference user identifer is logically requested command. The conference user identifer is logically
associated with the other user identifiers assigned to the associated with the other user identifiers assigned to the
conferencing client for other protocol interfaces, such as an conferencing client for other protocol interfaces, such as an
authenticated SIP user. A full description and semantics of the authenticated SIP user. A full description and semantics of the
conference user identifier is provided in [ref conf-userid: TBD]. conference user identifier is provided in [20].
7. Conferencing System Realization 7. Conferencing System Realization
Implementations based on this centralized conferencing framework can Implementations based on this centralized conferencing framework can
range from systems supporting ad-hoc conferences, with default range from systems supporting ad-hoc conferences, with default
behavior only, to sophisticated systems with the ability to schedule behavior only, to sophisticated systems with the ability to schedule
recurring conferences, each with distinct characteristics, being recurring conferences, each with distinct characteristics, being
integrated with external resource reservation tools, and providing integrated with external resource reservation tools, and providing
snapshots of the conference information at any of the stages of the snapshots of the conference information at any of the stages of the
conference life-cycle. conference life-cycle.
skipping to change at page 16, line 21 skipping to change at page 16, line 20
the Conference Object in terms of the stages of a conference, to the Conference Object in terms of the stages of a conference, to
support scheduled and other advanced conference capabilities. The support scheduled and other advanced conference capabilities. The
scheduling of a conference based on these concepts and mechanisms is scheduling of a conference based on these concepts and mechanisms is
then detailed in Section 7.4 then detailed in Section 7.4
As discussed in Section 5.2, there are conference policies implicit As discussed in Section 5.2, there are conference policies implicit
in and derivable from the data in the conference objects and there in and derivable from the data in the conference objects and there
are also policies applying to the conference objects as a whole. In are also policies applying to the conference objects as a whole. In
the examples in this section, these latter policies are shown the examples in this section, these latter policies are shown
logically associated with the conference objects, however, it is an logically associated with the conference objects, however, it is an
implementation specific mechansim as to how these policies are implementation specific mechanism as to how these policies are
managed and applied to the conference objects. managed and applied to the conference objects.
7.1. Cloning Tree 7.1. Cloning Tree
The concept defined in this section is a logical representation only, The concept defined in this section is a logical representation only,
as it is reflected through the centralized conferencing mechanisms: as it is reflected through the centralized conferencing mechanisms:
the URIs and the protocols. Of course, the actual system realization the URIs and the protocols. Of course, the actual system realization
can differ from the presented model. The intent is to illustrate the can differ from the presented model. The intent is to illustrate the
role of the logical elements in providing an interface to the data, role of the logical elements in providing an interface to the data,
based on conferencing system and conferencing client actions, and based on conferencing system and conferencing client actions, and
skipping to change at page 17, line 6 skipping to change at page 17, line 4
object replication, rather than a data type re-usage and extension object replication, rather than a data type re-usage and extension
concept. concept.
The cloning operation needs to specify whether the link between the The cloning operation needs to specify whether the link between the
parent and the child needs to be maintained in the system or not. If parent and the child needs to be maintained in the system or not. If
no link between the parent and the child exists, the objects become no link between the parent and the child exists, the objects become
independent and are not impacted by any operations on the parent independent and are not impacted by any operations on the parent
object nor subject to any limitations of the parent object. object nor subject to any limitations of the parent object.
Once the new object is created, it can be addressed by a unique Once the new object is created, it can be addressed by a unique
conference object URI assigned by the system, as described in [ref conference object URI assigned by the system, as described in [19].
conf-uri:TBD]. By default, the newly created object contains all the By default, the newly created object contains all the data existing
data existing in the parent object. The newly created object can in the parent object. The newly created object can expand the data
expand the data it contains, within the schema types supported by the it contains, within the schema types supported by the parent. It can
parent. It can also restrict the read/write access to its objects. also restrict the read/write access to its objects. However, unless
However, unless the object is independent, it cannot modify the the object is independent, it cannot modify the access restrictions
access restrictions imposed by the parent object. imposed by the parent object.
Any piece of data in the child object can be independently accessed Any piece of data in the child object can be independently accessed
and, by default, can be independently modified without affecting the and, by default, can be independently modified without affecting the
parent data. parent data.
Unless the object is independent, the parent object can enforce a Unless the object is independent, the parent object can enforce a
different policy by marking certain data elements as "parent different policy by marking certain data elements as "parent
enforceable". The values of these data elements can not be changed enforceable". The values of these data elements can not be changed
by directly accessing the child object; neither can they be expanded by directly accessing the child object; neither can they be expanded
in the child object alone. in the child object alone.
skipping to change at page 22, line 25 skipping to change at page 22, line 25
considerations. In most advanced conferencing solutions it is considerations. In most advanced conferencing solutions it is
possible to not only schedule an individual occurrence of a possible to not only schedule an individual occurrence of a
conference reservation, but also schedule a series of related conference reservation, but also schedule a series of related
conferences (e.g., a weekly meeting that starts on Thursday at 09.00 conferences (e.g., a weekly meeting that starts on Thursday at 09.00
GMT). GMT).
To be able to achieve such functionality, a conferencing system needs To be able to achieve such functionality, a conferencing system needs
to be able to appropriately schedule and maintain conference to be able to appropriately schedule and maintain conference
reservations that form part of a recurring conference. The mechanism reservations that form part of a recurring conference. The mechanism
proposed in this document makes use of the 'Internet Calendaring and proposed in this document makes use of the 'Internet Calendaring and
Scheduling Core Object' specification defined in RFC2445[8] in union Scheduling Core Object' specification defined in RFC2445[7] in union
with the concepts introduced in Section 5 for the purpose of with the concepts introduced in Section 5 for the purpose of
achieving advanced conference scheduling capability. achieving advanced conference scheduling capability.
Figure 7 illustrates a simplified view of a client interacting with a Figure 7 illustrates a simplified view of a client interacting with a
conferencing system. The client is using the Conference Control conferencing system. The client is using the Conference Control
Protocol (Section 8.3) to add a new conference reservation to the Protocol (Section 8.3) to add a new conference reservation to the
conferencing system by interfacing with the conference control conferencing system by interfacing with the conference control
server. A CCP request contains a valid conference reservation and server. A CCP request contains a valid conference reservation and
reference by value to an 'iCal' object which contains scheduling reference by value to an 'iCal' object which contains scheduling
information about the conference (e.g., start time, end time). information about the conference (e.g., start time, end time).
skipping to change at page 23, line 48 skipping to change at page 23, line 48
| Client | | Client |
+-------------+ +-------------+
Figure 7: Resource Scheduling Figure 7: Resource Scheduling
A CCP request to create a new conference reservation is validated, A CCP request to create a new conference reservation is validated,
including the associated iCal object, and the resultant conference including the associated iCal object, and the resultant conference
reservation is created. The conference reservation is uniquely reservation is created. The conference reservation is uniquely
represented within the conferencing system by a conference object represented within the conferencing system by a conference object
identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and
defined in [ref conf-uri:TBD]. This unique URI is returned to the defined in [19]. This unique URI is returned to the client and can
client and can be used to reference the conference reservation, if be used to reference the conference reservation, if any future
any future manipulations are required (e.g., alter start time), using manipulations are required (e.g., alter start time), using a CCP
a CCP request. request.
The previous example explains how a client creates a basic conference The previous example explains how a client creates a basic conference
reservation using an iCal reference in association with a conference reservation using an iCal reference in association with a conference
control protocol. Figure 7 can also be applied when explaining how a control protocol. Figure 7 can also be applied when explaining how a
series of conferences are scheduled in the system. The description series of conferences are scheduled in the system. The description
is almost identical with the exception that the iCal definition that is almost identical with the exception that the iCal definition that
is included in a CCP request represents a series of recurring is included in a CCP request represents a series of recurring
conference instances (e.g., conference start time, end time, occur conference instances (e.g., conference start time, end time, occur
weekly). The conferencing system will treat this request the same as weekly). The conferencing system will treat this request the same as
the first example. The CCP request will be validated, along with the the first example. The CCP request will be validated, along with the
skipping to change at page 25, line 34 skipping to change at page 25, line 34
to the focus and checked against the conference policies. If to the focus and checked against the conference policies. If
approved, the participants are added or deleted using the call approved, the participants are added or deleted using the call
signaling to/from the focus. signaling to/from the focus.
8.2. Notifications 8.2. Notifications
A conferencing system is responsible for implementing a Conference A conferencing system is responsible for implementing a Conference
Notification Service. The Conference Notification Service provides Notification Service. The Conference Notification Service provides
updates about the conference instance state to authorized parties, updates about the conference instance state to authorized parties,
including participants. A model for notifications using SIP is including participants. A model for notifications using SIP is
defined in [11]. defined in [5] with the specifics to support conferencing defined in
[10].
The conference user identifier and associated role are used by the The conference user identifier and associated role are used by the
conferencing system to filter the notifications such that they conferencing system to filter the notifications such that they
contain only information that is allowed to be sent to that user. contain only information that is allowed to be sent to that user.
8.3. Conference Control Protocol 8.3. Conference Control Protocol
The conference control protocol provides for data manipulation and The conference control protocol provides for data manipulation and
state retrieval for the centralized conferencing data, represented by state retrieval for the centralized conferencing data, represented by
the conference object. The details of the conference control the conference object. The details of the conference control
protocol are provided in separate documents [references TBD]. protocol are provided in separate documents.
8.4. Floor Control 8.4. Floor Control
A floor control protocol allows an authorized client to manage access A floor control protocol allows an authorized client to manage access
to a specific floor and to grant, deny or revoke access of other to a specific floor and to grant, deny or revoke access of other
conference users to that floor. Floor control is not a mandatory conference users to that floor. Floor control is not a mandatory
mechanism for a conferencing system implementation but provides mechanism for a conferencing system implementation but provides
advanced media input control features for conference users. A advanced media input control features for conference users. A
mechanism for floor control within a conferencing system is defined mechanism for floor control within a conferencing system is defined
in the Binary Floor Control Protocol specification [15]. in the Binary Floor Control Protocol specification [14].
Within this framework, a client supporting floor control needs to Within this framework, a client supporting floor control needs to
obtain information for connecting to a floor control server to enable obtain information for connecting to a floor control server to enable
it to issue floor requests. This connection information can be it to issue floor requests. This connection information can be
retrieved using information provided by mechanisms such as retrieved using information provided by mechanisms such as
negotiation using the SDP[2] offer/answer[5] exchange on the negotiation using the SDP[2] offer/answer[4] exchange on the
signaling interface with the focus. Section 11.3 provides a signaling interface with the focus. Section 11.3 provides a
discussion of client authentication of a floor control server. discussion of client authentication of a floor control server.
As well as the client to the floor control server connection As well as the client to the floor control server connection
information, a client wishing to interact with a floor control server information, a client wishing to interact with a floor control server
requires access to additional information. This information requires access to additional information. This information
associates floor control interactions with the appropriate floor associates floor control interactions with the appropriate floor
instance. Once a connection has been established and authenticated instance. Once a connection has been established and authenticated
(see [15] for authentication details), a specific floor control (see [14] for authentication details), a specific floor control
message requires detailed information to uniquely identify a message requires detailed information to uniquely identify a
conference, a user and a floor. conference, a user and a floor.
The conference is uniquely identifed by the conference object ID per The conference is uniquely identifed by the conference object ID per
Section 6.2.1. This conference object ID must be included in all Section 6.2.1. This conference object ID must be included in all
floor control messages. When the SDP model is used as described in floor control messages. When the SDP model is used as described in
[17] 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 identifier is contained in the 'userid' SDP attribute, as
defined in [17] 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 [17] 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
the SDP 'Label' attribute as defined in [16]. the SDP 'Label' attribute as defined in [15].
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 [13], 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 details shown in the messages are for illustrative purposes only
and don't reflect the structure of the conference control protocol and don't reflect the structure of the conference control protocol
messages, but rather provide a high level primitive view of the messages, but rather provide a high level primitive view of the
necessary operations and general logic flow, including the data necessary operations and general logic flow, including the data
manipulation aspects. It should be noted that not all entities manipulation aspects. It should be noted that not all entities
impacted by the request are shown in the diagram (e.g., Focus), but impacted by the request are shown in the diagram (e.g., Focus), but
rather the emphasis is on the new entities introduced by this rather the emphasis is on the new entities introduced by this
centralized conferencing framework. centralized conferencing framework.
9.1. Conference Creation 9.1. Conference Creation
There are different ways to create a conference. A participant can There are different ways to create a conference. A participant can
create a conference using call signaling means only, such as SIP and create a conference using call signaling means only, such as SIP and
detailed in [14]. 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
conferencing client would implement a conference control protocol conferencing client would implement a conference control protocol
client. By using a conference control protocol, the client can client. By using a conference control protocol, the client can
determine the capabilities of a conferencing system and its various determine the capabilities of a conferencing system and its various
resources. resources.
Figure 8 provides an example of one client "Alice" determining the Figure 8 provides an example of one client "Alice" determining the
conference blueprints available for a particular conferencing system conference blueprints available for a particular conferencing system
and creating a conference based on the desired blueprint. and creating a conference based on the desired blueprint.
skipping to change at page 30, line 8 skipping to change at page 30, line 8
There are different ways to affect a participant state in a There are different ways to affect a participant state in a
conference. A participant can join and leave the conference using conference. A participant can join and leave the conference using
call signaling means only, such as SIP. This kind of operation is call signaling means only, such as SIP. This kind of operation is
called "1st party signaling" and does not affect the state of other called "1st party signaling" and does not affect the state of other
participants in the conference. participants in the conference.
Limited operations for controlling other conference participants (a Limited operations for controlling other conference participants (a
so called "3rd party control") through the Focus, using call so called "3rd party control") through the Focus, using call
signaling only, may also be available for some signaling protocols. signaling only, may also be available for some signaling protocols.
For example, "Conferencing for SIP User Agents" [14] shows how SIP For example, "Conferencing for SIP User Agents" [13] shows how SIP
with REFER can be used to achieve this functionality. with REFER can be used to achieve this functionality.
In order to perform richer conference control a user client needs to In order to perform richer conference control a user client needs to
implement a conference control protocol client. By using a implement a conference control protocol client. By using a
conference control protocol, the client can affect its own state, conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state of any of the media mixers) which may indirectly affect the state of any of the
conference participants. conference participants.
Figure 9 provides an example of one client "Alice" impacting the Figure 9 provides an example of one client "Alice" impacting the
skipping to change at page 37, line 7 skipping to change at page 37, line 7
"Bob") may be notified of his addition to the sidebar via the "Bob") may be notified of his addition to the sidebar via the
conference notification service. conference notification service.
9.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
"Frank" 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
conference. "Alice" initiates the sidebar by sending a request to conference. "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", "Bob" and "Ethel" would the active conference object. "Alice", "Bob" and "Ethel" would
remain on the roster of the main conference in a hold state. remain on the roster of the main conference in a hold state. Whether
or not the hold state of these participants is visible to other
participants depends upon the individual and local policy.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
| |Conference || | |Conference ||
"Alice" | +-------+ || "Alice" | +-------+ ||
+--------+ | |"Alice"| || +--------+ | |"Alice"| ||
skipping to change at page 41, line 6 skipping to change at page 41, line 6
+--------+ Floor Granted <"A1", |+------------+ +-------+ || +--------+ Floor Granted <"A1", |+------------+ +-------+ ||
| |<-------------------------|Floor Ctrl |<~~~|"Carol"| || | |<-------------------------|Floor Ctrl |<~~~|"Carol"| ||
| Client | activeSideConfObjID,||Server | +-------+ || | Client | activeSideConfObjID,||Server | +-------+ ||
+--------+ confID > || | |"A1" | || +--------+ confID > || | |"A1" | ||
|+------------+ +-------+----+| |+------------+ +-------+----+|
+--------------------------------+ +--------------------------------+
Figure 14: Floor Control with sidebars Figure 14: Floor Control with sidebars
When "A1" wishes to ask a question, he sends a Floor Request message When "A1" wishes to ask a question, he sends a Floor Request message
to the floor control server. Upon receipt of the request, the floor to the floor control server. Upon receipt of the request, the floor
control server notifies the moderator, "Alice" of the active sidebar control server notifies the moderator, "Carol" of the active sidebar
conference, whose serving as the floor chair. Note, that this conference, whose serving as the floor chair. Note, that this
signaling flow is not shown in the diagram. Since no other analysts signaling flow is not shown in the diagram. Since no other analysts
have yet requested the floor, "Alice" indicates to the floor control have yet requested the floor, "Carol" indicates to the floor control
server that "A1" may be granted the floor. server that "A1" may be granted the floor.
9.6. Whispering or Private Messages 9.6. Whispering or Private Messages
The case of private messages can be handled as a sidebar with just The case of private messages can be handled as a sidebar with just
two participants, similar to the example in section Section 9.4.1, two participants, similar to the example in section Section 9.4.1,
but rather than using audio within the sidebar, "Alice" could add an but rather than using audio within the sidebar, "Alice" could add an
additional text based media stream to the sidebar. The other additional text based media stream to the sidebar. The other
context, referred to as whisper, in this document refers to context, referred to as whisper, in this document refers to
situations involving one time media targetted to specific user(s). situations involving one time media targetted to specific user(s).
skipping to change at page 49, line 6 skipping to change at page 49, line 6
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIPPING Conferencing Framework are being used
to illustrate how SIP [4] can be used as a signaling means in these to illustrate how SIP [3] can be used as a signaling means in these
conferencing systems. SIPPING Conferencing Framework does not define conferencing systems. SIPPING Conferencing Framework does not define
new conference control protocols to be used by the general new conference control protocols to be used by the general
conferencing system. It uses only basic SIP [4], the SIP conferencing system. It uses only basic SIP [3], the SIP
Conferencing for User Agents [14], and the SIPPING Conference Package Conferencing for User Agents [13], and the SIPPING Conference Package
[9] for basic SIP conferencing realization. [10] for basic SIP conferencing realization.
This centralized conferencing framework document defines a particular This centralized conferencing framework document defines a particular
centralized conferencing system and the logical entities implementing centralized conferencing system and the logical entities implementing
it. It also defines a particular data model and refers to the set of it. It also defines a particular data model and refers to the set of
protocols (beyond call signaling means) being defined by the XCON WG protocols (beyond call signaling means) being defined by the XCON WG
to be used among the logical entities for implementing advanced to be used among the logical entities for implementing advanced
conferencing features. The purpose of the XCON working group and conferencing features. The purpose of the XCON working group and
this framework is to achieve interoperability between the logical this framework is to achieve interoperability between the logical
entities from different vendors for controlling different aspects of entities from different vendors for controlling different aspects of
advanced conferencing applications. advanced conferencing applications.
The logical entities defined in the two frameworks are not intended The logical entities defined in the two frameworks are not intended
to be mapped one-to-one. The two frameworks differ in the to be mapped one-to-one. The two frameworks differ in the
interpretation of the internal conferencing system decomposition and interpretation of the internal conferencing system decomposition and
the corresponding operations. Nevertheless, the basic SIP [4], the the corresponding operations. Nevertheless, the basic SIP [3], the
SIP Conferencing for User Agents [14], and the SIPPING Conference SIP Conferencing for User Agents [13], and the SIPPING Conference
Package [9] are fully compatible with both Framework documents. Package [10] are fully compatible with both Framework documents.
11. Security Considerations 11. Security Considerations
There are a wide variety of potential attacks related to There are a wide variety of potential attacks related to
conferencing, due to the natural involvement of multiple endpoints conferencing, due to the natural involvement of multiple endpoints
and the many, often user-invoked, capabilities provided by the and the many, often user-invoked, capabilities provided by the
conferencing system. Examples of attacks include the following: an conferencing system. Examples of attacks include the following: an
endpoint attempting to listen to conferences in which it is not endpoint attempting to listen to conferences in which it is not
authorized to participate, an endpoint attempting to disconnect or authorized to participate, an endpoint attempting to disconnect or
mute other users, and theft of service, by an endpoint, in attempting mute other users, and theft of service, by an endpoint, in attempting
skipping to change at page 51, line 50 skipping to change at page 51, line 50
using a mechanism such as the 'k=' SDP attribute. The shared secret using a mechanism such as the 'k=' SDP attribute. The shared secret
can also be exchanged using un-specified 'out of band' mechanisms. can also be exchanged using un-specified 'out of band' mechanisms.
When using Digest authentication of floor control client messages the When using Digest authentication of floor control client messages the
exchange of an active 'Nonce' is also required. This can be achieved exchange of an active 'Nonce' is also required. This can be achieved
using a BFCP request response interaction as defined in BFCP (A using a BFCP request response interaction as defined in BFCP (A
request is submitted without a Nonce TLV and the server generates an request is submitted without a Nonce TLV and the server generates an
error response with either an Error Code 7 (DIGEST TLV Required) or 6 error response with either an Error Code 7 (DIGEST TLV Required) or 6
(Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value
can also be obtained 'out of band' using information provided in the can also be obtained 'out of band' using information provided in the
offer/answer exchange. As with the other SDP Floor attributes offer/answer exchange. As with the other SDP Floor attributes
referenced in this section and defined in [17], the 'nonce' attribute referenced in this section and defined in [16], the 'nonce' attribute
can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj.
12. IANA Considerations 12. IANA Considerations
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
13. Acknowledgements 13. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson and Rohan Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan
Mahy for their reviews and constructive input. Mahy, Brian Rosen and Pierre Tane for their reviews and constructive
input.
14. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 05 to 06:
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.
2) Fixed Editorial nits including updating references to published
RFC numbers, adding references for userid and uri definitions,
removing unused references, fixing names in detailed scenarios
(section 9.4.2: "Frank" -> "Fred", section 9.5: "Alice" -> "Carol" as
moderator), aligning with data model (section 9.5: "allowed to join"
list -> "allowed-users-list") and miscellaneous typos.
Changes from WG 04 to 05: Changes from WG 04 to 05:
1) Removed all references to "Conference Template": 1) Removed all references to "Conference Template":
Section 4: Section 4:
- Updated "Common Conference Information" definition, merging details - Updated "Common Conference Information" definition, merging details
from "Conference Template" definition, which was removed. from "Conference Template" definition, which was removed.
- In definition of "conference blueprint" - In definition of "conference blueprint"
skipping to change at page 58, line 31 skipping to change at page 58, line 43
15.1. Normative References 15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 15.2. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[8] Dawson, F. and Stenerson, D., "Internet Calendaring and [7] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445, Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998. November 1998.
[8] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
[9] Rosenberg, J., "A Framework for Conferencing with the Session [9] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006. Initiation Protocol (SIP)", RFC 4353, February 2006.
[10] Levin, O. and R. Even, "High-Level Requirements for Tightly [10] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Coupled SIP Conferencing", RFC 4245, November 2005. Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[12] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, [11] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376,
February 2006. February 2006.
[13] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, [12] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597,
August 2006. August 2006.
[14] Levin, O., "Session Initiation Protocol Call Control - [13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Conferencing for User Agents", Call Control - Conferencing for User Agents", BCP 119,
draft-ietf-sipping-cc-conferencing-07 (work in progress), RFC 4579, August 2006.
June 2005.
[15] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [14] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005. draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[16] Levin, O. and G. Camarillo, "The SDP (Session Description [15] Levin, O. and G. Camarillo, "The Session Description Protocol
Protocol) Label Attribute", (SDP) Label Attribute", RFC 4574, August 2006.
draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005.
[17] 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",
draft-ietf-mmusic-sdp-bfcp-03 (work in progress), draft-ietf-mmusic-sdp-bfcp-03 (work in progress),
December 2005. December 2005.
[18] 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-02 (work in progress), draft-ietf-xcon-common-data-model-03 (work in progress),
July 2006. October 2006.
[19] Campbell, B., "The Message Session Relay Protocol", [18] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-15 (work in progress), draft-ietf-simple-message-sessions-16 (work in progress),
July 2006. October 2006.
[19] Boulton, C. and M. Barnes, "A Universal Resource Identifier
(URI) for Centralized Conferencing (XCON)",
draft-boulton-xcon-uri-00 (work in progress), October 2006.
[20] Boulton, C. and M. Barnes, "A User Identifier for Centralized
Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in
progress), October 2006.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
 End of changes. 61 change blocks. 
99 lines changed or deleted 114 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/