draft-ietf-xcon-framework-03.txt   draft-ietf-xcon-framework-04.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: September 2, 2006 C. Boulton Expires: December 24, 2006 C. Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
June 22, 2006
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-03 draft-ietf-xcon-framework-04
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 35 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 September 2, 2006. This Internet-Draft will expire on December 24, 2006.
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 45 skipping to change at page 2, line 45
8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34
9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38
9.6. Conference Announcements and Recordings . . . . . . . . . 39 9.6. Conference Announcements and Recordings . . . . . . . . . 39
9.7. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 39
9.8. Observing a Conference . . . . . . . . . . . . . . . . . . 39
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 40 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 41 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 42
11.3. Floor Control Server Authentication . . . . . . . . . . . 42 11.3. Floor Control Server Authentication . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 14. Changes since last Version . . . . . . . . . . . . . . . . . . 43
15. Appendix A - Conference Object Identifier . . . . . . . . . . 47 15. Appendix A - Conference Object Identifier . . . . . . . . . . 48
15.1. Conference Object URI Definition . . . . . . . . . . . . . 50 15.1. Conference Object URI Definition . . . . . . . . . . . . . 51
16. Appendix B - Conference User Identifier . . . . . . . . . . . 50 16. Appendix B - Conference User Identifier . . . . . . . . . . . 51
16.1. Conference User Definition . . . . . . . . . . . . . . . . 52 16.1. Conference User Definition . . . . . . . . . . . . . . . . 53
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
17.1. Normative References . . . . . . . . . . . . . . . . . . . 52 17.1. Normative References . . . . . . . . . . . . . . . . . . . 53
17.2. Informative References . . . . . . . . . . . . . . . . . . 52 17.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 57
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 9, line 9 skipping to change at page 9, line 9
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 template: The conference template refers to the data type Conference template: The conference template refers to the data type
(i.e. the XML schema) which is used to represent the media or (i.e. the XML schema) which is used to represent the media or
application specific part of the conference object. This application specific part of the conference object. This
information represents enhanced conferencing features or information represents enhanced conferencing features or
capabilities, such as media mixers, and/or user interface capabilities, such as media mixers.
abstractions.
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 signalling Focus: A focus is a logical entity that maintains the call signalling
interface with each participating client and the conference object interface with each participating client and the conference object
skipping to change at page 12, line 9 skipping to change at page 12, line 9
different stages of the conference life-cycle. different stages of the conference life-cycle.
New centralized conferencing specifications can extend the basic New centralized conferencing specifications can extend the basic
conference-type and introduce additional data elements to be used conference-type and introduce additional data elements to be used
within the common conference information type. within the common conference information type.
5.2. Conference Template 5.2. Conference Template
The concept of a conference template is introduced to separate the The concept of a conference template is introduced to separate the
complexity and the details of the "mixer" and other enhanced complexity and the details of the "mixer" and other enhanced
conferencing features from the common conference information and to conferencing features from the common conference information.
allow for easy user interface abstraction for advanced conferencing
systems.
Each conference template needs to be registered with IANA. The IANA Each conference template needs to be registered with IANA. The IANA
registration needs to point to an RFC having the text description of registration needs to point to an RFC having the text description of
the feature behavior and the XML definition allowing the feature the feature behavior and the XML definition allowing the feature
presentation, configuration, and management. The RFCs defining these presentation, configuration, and management. The RFCs defining these
templates are referred to as a registered conference document. templates are referred to as a registered conference document.
Typically, a conference template would contain the information about Typically, a conference template would contain the information about
the specific media mixing details, the associated client roles and the specific media mixing details, the associated client roles and
the available floor controls. This information would allow the available floor controls. This information would allow
authorized clients to manipulate the mixer's behavior via the focus, authorized clients to manipulate the mixer's behavior via the focus,
and the resultant distribution of the media to all or individual and the resultant distribution of the media to all or individual
participants. By doing so, a client can change its own state and/or participants. By doing so, a client can change its own state and/or
state of other participants in the conference. state of other participants in the conference.
A conference template can also include an abstract user interface
definition in terms of sliders, radio boxes, etc. for simplifying
user interaction with a specific non-trivial feature.
The addition of new elements or the modification of the controls The addition of new elements or the modification of the controls
within an element of an existing template requires the definition of within an element of an existing template requires the definition of
a new template. a new template.
5.3. Conference policies 5.3. Conference policies
Conference policies collectively refers to a set of rights, Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed permissions and limitations pertaining to operations being performed
on a certain conference object. on a certain conference object.
skipping to change at page 16, line 43 skipping to change at page 16, line 41
based on conferencing system and conferencing client actions, and based on conferencing system and conferencing client actions, and
describe the resultant protocol implications describe the resultant protocol implications
Any conference object in a conferencing system is created by either Any conference object in a conferencing system is created by either
being explicitly cloned from an existing parent object or being being explicitly cloned from an existing parent object or being
implicitly cloned from a default system conference blueprint. A implicitly cloned from a default system conference blueprint. A
conference blueprint is a static conference object used to describe a conference blueprint is a static conference object used to describe a
typical conference setting supported by the system. Each system can typical conference setting supported by the system. Each system can
maintain multiple blueprints, typically each describing a different maintain multiple blueprints, typically each describing a different
conferencing type using the common conference information format, conferencing type using the common conference information format,
along with any number of template definitions This document uses the along with any number of template definitions. This document uses
"cloning" metaphor instead of the "inheritance" metaphor because it the "cloning" metaphor instead of the "inheritance" metaphor because
more closely fits the idea of object replication, rather than a data it more closely fits the idea of object replication, rather than a
type re-usage and extension concept. data type re-usage and extension concept.
The cloning operation needs to specify whether the link between the The cloning operation needs to specify whether the link between the
parent and the child needs to be maintained in the system or not. If parent and the child needs to be maintained in the system or not. If
no link between the parent and the child exists, the objects become no link between the parent and the child exists, the objects become
independent and are not impacted by any operations on the parent independent and 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 conference object URI assigned by the system, as described in
Section 15 /[ref:TBD]. By default, the newly created object contains Section 15 /[ref:TBD]. By default, the newly created object contains
all the data existing in the parent object. The newly created object all the data existing in the parent object. The newly created object
can expand the data it contains, within the schema types supported by can expand the data it contains, within the schema types supported by
the parent. It can also restrict the read/write access to its the parent. It can also restrict the read/write access to its
objects. However, unless the object is independent, it cannot relax objects. However, unless the object is independent, it cannot modify
the access relative to its parent's access. the access restrictions 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 20, line 50 skipping to change at page 25, line ?
reservation becomes independent from its blueprint. The client can reservation becomes independent from its blueprint. The client can
also change the default values, within the system ranges, and add also change the default values, within the system ranges, and add
additional information, such as the list of participants and the additional information, such as the list of participants and the
conference start time, to the conference reservation. conference start time, to the conference reservation.
At this point the client can ask the conference server to create new At this point the client can ask the conference server to create new
conference reservations by attaching the conference reservation to conference reservations by attaching the conference reservation to
the request. As a result, the server can allocate the needed the request. As a result, the server can allocate the needed
resources, create the additional conference objects for the child resources, create the additional conference objects for the child
conference reservations and allocate the conference object conference reservations and allocate the conference object
identifiers for all - the original conference reservation and for
each child conference reservation.
From this point on, any authorized client is able to access and
modify each of the conference objects independently. By default,
changes to an individual child conference reservation will affect
neither the parent conference reservation, from which it was created,
nor its siblings.
On the other hand, some of the conference sub-objects, such as the
maximum number of participants and the participants list, can be
defined by the system as parent enforceable. As a result, these
objects can be modified by accessing the parent conference
reservation only. The changes to these objects can be applied
automatically to each of the child reservations, subject to local
policy.
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
Figure 6: Advanced Conference Definition, Creation, and Lifetime.
When the time comes to schedule the conference reservation, either
via the system determination that the 'start' time has been reached
or via client invocation, an active conference is cloned based on the
conference reservation. As in the adhoc example, the active
conference is independent from the parent and changes to the
conference reservation will not impact the active conference. Any
desired changes must be targeted towards the active conference. An
example of this interaction is shown in Section 9.1
7.4. Scheduling a conference
The capability to schedule conferences forms an important part of the
conferencing system solution. An individual conference reservation
typically has a specified 'start' and 'end' time, with the times
being specified relative to a single specified 'fixed' time (e.g.,
'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
considerations. In most advanced conferencing solutions it is
possible to not only schedule an individual occurrence of a
conference reservation, but also schedule a series of related
conferences (e.g., a weekly meeting that starts on Thursday at 09.00
GMT).
To be able to achieve such functionality, a conferencing system needs
to be able to appropriately schedule and maintain conference
reservations that form part of a recurring conference. The mechanism
proposed in this document makes use of the 'Internet Calendaring and
Scheduling Core Object' specification defined in RFC2445[8] in union
with the concepts introduced in Section 5 for the purpose of
achieving advanced conference scheduling capability.
Figure 7 illustrates a simplified view of a client interacting with a
conferencing system. The client is using the Conference Control
Protocol (Section 8.3) to add a new conference reservation to the
conferencing system by interfacing with the conference control
server. A CCP request contains a valid conference reservation and
reference by value to an 'iCal' object which contains scheduling
information about the conference (e.g., start time, end time).
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+
Figure 7: Resource Scheduling
A CCP request to create a new conference reservation is validated,
including the associated iCal object, and the resultant conference
reservation is created. The conference reservation is uniquely
represented within the conferencing system by a conference object
identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and
defined in [ref:TBD]. This unique URI is returned to the client and
can be used to reference the conference reservation, if any future
manipulations are required (e.g., alter start time), using a CCP
request.
The previous example explains how a client creates a basic conference
reservation using an iCal reference in association with a conference
control protocol. Figure 7 can also be applied when explaining how a
series of conferences are scheduled in the system. The description
is almost identical with the exception that the iCal definition that
is included in a CCP request represents a series of recurring
conference instances (e.g., conference start time, end time, occur
weekly). The conferencing system will treat this request the same as
the first example. The CCP request will be validated, along with the
associated iCal object, and the conference reservation is created.
The conference reservation and its conference object ID created for
this example represent the entire series of recurring conference
instances rather than a single Conference. If the client uses the instances rather than a single Conference. If the client uses the
conference object ID provided and a CCP request to adjust the conference object ID provided and a CCP request to adjust the
conference reservation, every conference instance in the series will conference reservation, every conference instance in the series will
be altered. This includes all future occurrences, such as a be altered. This includes all future occurrences, such as a
conference scheduled as an infinite series, subject to the conference scheduled as an infinite series, subject to the
limitations of the available calendaring interface. limitations of the available calendaring interface.
A conferencing system that supports the scheduling of a series of A conferencing system that supports the scheduling of a series of
conference instances should also be able to support manipulation conference instances should also be able to support manipulation
within a specific range of the series. A good example is a within a specific range of the series. A good example is a
skipping to change at page 26, line 13 skipping to change at page 26, line 13
ID representing an altered (cloned) series of conference instances, ID representing an altered (cloned) series of conference instances,
can itself be manipulated using a CCP request for the newly created can itself be manipulated using a CCP request for the newly created
conference object ID . This provides a flexible approach to the conference object ID . This provides a flexible approach to the
scheduling of recurring conference instances. scheduling of recurring conference instances.
8. Conferencing Mechanisms 8. Conferencing Mechanisms
8.1. Call Signaling 8.1. Call Signaling
The focus is the central component of the conference. Participants The focus is the central component of the conference. Participants
interface with the focus using an appropriate call signaling interface with the focus using an appropriate call signaling protocol
protocol. Participants request to establish or join a conference (CSP). Participants request to establish or join a conference using
using the call interface. After checking the applicable policies, a the CSP. After checking the applicable policies, a focus then either
focus then either accepts the request, sends a progress indication accepts the request, sends a progress indication related to the
related to the status of the request (e.g., for a parked call while status of the request (e.g., for a parked call while awaiting
awaiting moderator approval to join) or rejects that request using moderator approval to join) or rejects that request using the call
the call signaling interface. signaling interface.
During an active conference, a Conference Control Protocol During an active conference, a Conference Control Protocol
[Section 8.3] can be used to affect the conference state. For [Section 8.3] can be used to affect the conference state. For
example, CCP requests to add and delete participants are communicated example, CCP requests to add and delete participants are communicated
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
skipping to change at page 27, line 52 skipping to change at page 27, line 52
attribute that can be used in BFCP requests. attribute that can be used in BFCP requests.
8.3.3. SOAP 8.3.3. SOAP
The SOAP protocol is fundamentally an XML messaging scheme, capable The SOAP protocol is fundamentally an XML messaging scheme, capable
of supporting remote procedure calls. SOAP defines a simple message of supporting remote procedure calls. SOAP defines a simple message
format composed of a "header" and a "body" contained within an format composed of a "header" and a "body" contained within an
"envelope". The "header" contains meta-information relating to the "envelope". The "header" contains meta-information relating to the
message, and can be used to indicate such things as store-and-forward message, and can be used to indicate such things as store-and-forward
behaviour or transactional characteristics. In addition, SOAP behaviour or transactional characteristics. In addition, SOAP
encoding is optimized for ease of automated deserialization. encoding is optimized for ease of automated deserialization of the
message body.
SOAP [17] and [18] is proposed as the mechanism for object content SOAP [17] and [18] is proposed as the mechanism for object content
manipulation and state retrieval for the centralized conferencing manipulation and state retrieval for the centralized conferencing
data. In general, SOAP is a good fit for Conference Control, data. In general, SOAP is a good fit for Conference Control,
essentially because of its remote procedure call characteristics and essentially because of its remote procedure call characteristics and
its inherently synchronous and client-driven nature. its inherently synchronous and client-driven nature.
8.4. Floor Control 8.4. Floor Control
A floor control protocol allows an authorized client to manage access A floor control protocol allows an authorized client to manage access
skipping to change at page 28, line 51 skipping to change at page 29, line 4
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
[23] this identifier maps to the 'confid' SDP attribute. [23] this identifier maps to the 'confid' SDP attribute.
Each authorized user associated with a conference object is uniquely Each authorized user associated with a conference object is uniquely
represented by a conference user ID per Section 6.3. This conference represented by a conference user ID per Section 6.3. This conference
user ID must be included in all floor control messages. When using user ID must be included in all floor control messages. When using
SDP offer/answer exchange to negotiate a Floor control connection SDP offer/answer exchange to negotiate a Floor control connection
with the focus using the call signaling interface, the unique with the focus using the call signaling 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 [23] defined in [23]
A media session witin 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 [23] e.g., a=floorid:1 m-stream:10 . Each attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 . Each
'floorid' attribute, representing a unique floor, has an 'm-stream' 'floorid' attribute, representing a unique floor, has an 'm-stream'
tag containing one or more identifiers. The identifiers represent tag containing one or more identifiers. The identifiers represent
individual SDP media sessions (as defined using 'm=' from SDP) using individual SDP media sessions (as defined using 'm=' from SDP) using
the SDP 'Label' attribute as defined in [22]. the SDP 'Label' attribute as defined in [22].
skipping to change at page 31, line 42 skipping to change at page 31, line 45
the conference, "Alice" can now create an active conference using the conference, "Alice" can now create an active conference using
that reservation or create additional reservations based upon the that reservation or create additional reservations based upon the
existing reservations. In this example, "Alice" has reserved a existing reservations. In this example, "Alice" has reserved a
meetme conference bridge. Thus, "Alice" provides the conference meetme conference bridge. Thus, "Alice" provides the conference
information, including the necessary conference ID, to desired information, including the necessary conference ID, to desired
participants. When the first participant, including "Alice", participants. When the first participant, including "Alice",
requests to be added to the conference, an active conference and requests to be added to the conference, an active conference and
focus are created. The focus is associated with the conference ID focus are created. The focus is associated with the conference ID
received in the request. Any participants that have the authority to received in the request. Any participants that have the authority to
manipulate the conference would receive the conference object manipulate the conference would receive the conference object
identifier of the active conference in the response. identifier of the active conference object in the response.
9.2. Participant Manipulations 9.2. Participant Manipulations
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
skipping to change at page 32, line 33 skipping to change at page 32, line 35
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
"Alice" | +---------+--+| "Alice" | +---------+--+|
+--------+ | |policies | || +--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ || | |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | | Active || | Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Conference || | | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | | || +--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
"Bud" | ' ' '| "Carol" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ | | Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
"Bob" "Bob"
Figure 9: Client Manipulation of Conference - Add a party Figure 9: Client Manipulation of Conference - Add a party
skipping to change at page 35, line 49 skipping to change at page 35, line 49
outlined in the cloning tree model described in Section 7.1. A outlined in the cloning tree model described in Section 7.1. A
Sidebar conference object contains a subset of members from the Sidebar conference object contains a subset of members from the
original Conference object. Properties of the sidebar conference original Conference object. Properties of the sidebar conference
object can be manipulated by a Conference Control Protocol object can be manipulated by a Conference Control Protocol
(Section 8.3) using the unique conference object identifier for the (Section 8.3) using the unique conference object identifier for the
sidebar. It is also possible for the top level conference object to sidebar. It is also possible for the top level conference object to
enforce policy on the sidebar object (similar to parent enforceable enforce policy on the sidebar object (similar to parent enforceable
as discussed in Section 7.1). as discussed in Section 7.1).
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 "Bud". "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. "Alice" initiates the video associated with the main conference. "Alice" initiates the
sidebar by sending a request to the conferencing system to create a sidebar by sending a request to the conferencing system to create a
conference reservation based upon the active conference object. conference reservation based upon the active conference object.
+--------------------------------+ +--------------------------------+
| Conferencing System | | Conferencing System |
| +---------+--+| | +---------+--+|
| |policies | || | |policies | ||
| +---------+ || | +---------+ ||
| |Active || | |Active ||
| |Conference || | |Conference ||
"Alice" | +-------+ || "Alice" | +-------+ ||
+--------+ | |"Alice"| || +--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ || | |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | || | | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ || | Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Bud" | || | | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+| | |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | | | |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | | +--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V | confID> | | | V |
| | | +---------+--+| | | | +---------+--+|
| | | |policies | || | | | |policies | ||
| | |~~~>+---------+ || | | |~~~>+---------+ ||
| | | | || | | | | ||
| +-----------+ | || | +-----------+ | ||
"Alice" | | Sidebar || "Alice" | | Sidebar ||
skipping to change at page 39, line 14 skipping to change at page 39, line 14
context, referred to as whisper, in this document refers to context, referred to as whisper, in this document refers to
situations such as when a announcement server injects a message situations such as when a announcement server injects a message
targetted to specific user(s). The details of this mechanism within targetted to specific user(s). The details of this mechanism within
the context of the framework are TBD. the context of the framework are TBD.
9.6. Conference Announcements and Recordings 9.6. Conference Announcements and Recordings
Each participant can require a different type of announcement and/or Each participant can require a different type of announcement and/or
recording service from the system. For example, "Alice", the recording service from the system. For example, "Alice", the
conference chair, could be listening to a roll call while "Bob" may conference chair, could be listening to a roll call while "Bob" may
be using a telephony user interface to create a sidebar. The be using a telephony user interface to create a sidebar. Some
conferencing system would also need to have the capability to monitor announcements would apply to all the participants such as "This
for DTMF from each individual participant. conference will end in 10 minutes". Recording is often required to
capture the names of participants as they join a conference,
typically after the participant has entered an access code as
discussed in Section 9.7. These recorded names are then announced to
all the participants as the new participant is added to the active
conference.
Further details of conference announcements and recordings, within An example of conference recording and announcements, along with
the context of this framework, are TBD. monitoring for DTMF, within the context of this framework, is shown
in figure [TBD].
9.7. Monitoring for DTMF
The conferencing system also needs the capability to monitor for DTMF
from each individual participant. This would typically be used to
enter the identifier and/or access code for joining a specific
conference.
An example of DTMF monitoring, within the context of this framework,
is shown in figure [TBD] in the previous section.
9.8. Observing a Conference
The capability to observe a conference allows a participant with the
appropriate authority to listen to the conference, typically without
being an active participant and often as a hidden participant. When
such a capability is available on a conferencing system, there is
often an announcement provided to each participant as they join the
conference indicating the call may be monitored. This capability is
useful in the context of conferences which might be experiencing
technical difficulties, thus allowing a technician to listen in to
evaluate the type of problem. This capability could also apply to
call center applications as it provides a mechanism for a supervisor
to observe how the agent is handling a particular call. Whether the
agent is aware of when the supervisor joins the call should be
configurable.
An example of oberving a conference is shown in figure [TBD].
10. Relationships between SIPPING and Centralized Conferencing 10. Relationships between SIPPING and Centralized Conferencing
Frameworks Frameworks
The SIPPING Conferencing Framework [9] provides an overview of a wide The SIPPING Conferencing Framework [9] provides an overview of a wide
range of centralized conferencing solutions known today in the range of centralized conferencing solutions known today in the
conferencing industry. The document introduces a terminology and conferencing industry. The document introduces a terminology and
logical entities in order to systemize the overview and to show the logical entities in order to systemize the overview and to show the
common core of many of these systems. The logical entities and the common core of many of these systems. The logical entities and the
listed scenarios in the SIPPING Conferencing Framework are being used listed scenarios in the SIPPING Conferencing Framework are being used
skipping to change at page 41, line 8 skipping to change at page 41, line 42
means can provide a trusted form of the user identity or it might means can provide a trusted form of the user identity or it might
just provide a hint of the possible identity and the user still needs just provide a hint of the possible identity and the user still needs
to provide some authentication to prove it has the identity that was to provide some authentication to prove it has the identity that was
provided as a hint in the call signaling. This may be in the form of provided as a hint in the call signaling. This may be in the form of
an IVR system or other means. The goal for the conferencing system an IVR system or other means. The goal for the conferencing system
is to figure out a user identity and a role for any attempt to send a is to figure out a user identity and a role for any attempt to send a
request to the conferencing system. request to the conferencing system.
When a conferencing system presents the identity of authorized users, When a conferencing system presents the identity of authorized users,
it may choose to provide information about the way the identity was it may choose to provide information about the way the identity was
proven to or verified by the system. A user may also come as a proven or verified by the system. A user may also come as a
completely unauthenticated user into the system - this fact needs completely unauthenticated user into the system - this fact needs
also be communicated to interested parties. also be communicated to interested parties.
When guest users interact with the system, it is often in the context When guest users interact with the system, it is often in the context
of a particular conference. In this case, the user may provide a PIN of a particular conference. In this case, the user may provide a PIN
or a password that is specific to the conferences and authenticates or a password that is specific to the conferences and authenticates
the user to take on a certain role in that conference. The guest the user to take on a certain role in that conference. The guest
user can then perform actions that are allowed to any user with that user can then perform actions that are allowed to any user with that
role. role.
skipping to change at page 41, line 40 skipping to change at page 42, line 26
a high speed interface to connect to a conferencing system, it is a high speed interface to connect to a conferencing system, it is
often possible to do thousands of attempts per second and the PIN often possible to do thousands of attempts per second and the PIN
space could quickly be searched. Because of this, it is not space could quickly be searched. Because of this, it is not
appropriate to use PINs for authorization on any of the interfaces appropriate to use PINs for authorization on any of the interfaces
that provide fast queries or many simultaneous queries. that provide fast queries or many simultaneous queries.
11.2. Security and Privacy of Identity 11.2. Security and Privacy of Identity
This conferencing system has an idea of the identity of a user but This conferencing system has an idea of the identity of a user but
this does not mean it can reveal this identity to other users, due to this does not mean it can reveal this identity to other users, due to
privacy considerations. Users can set select various options for privacy considerations. Users can select various options for
revealing their identity to other users. A user can be "hidden" such revealing their identity to other users. A user can be "hidden" such
that other users can not see they are involved in the conference, or that other users can not see they are participants in the conference,
they can be "anonymous" such that users can see that another user is or they can be "anonymous" such that users can see that another user
there, but not see the identity of the user, or they can be "public" is there, but not see the identity of the user, or they can be
where other users can see their identity. If there are multiple "public" where other users can see their identity. If there are
"anonymous" users, other parties will be able to see them as multiple "anonymous" users, other parties will be able to see them as
independent "anonymous" parties and will be able to tell how many independent "anonymous" parties and will be able to tell how many
"anonymous" parties are in the conference. Note, that the visibility "anonymous" parties are in the conference. Note, that the visibility
to other participants is dependent on their roles. For example, to other participants is dependent on their roles. For example,
users' visibility (including "anonymous" and "hidden") may be users' visibility (including "anonymous" and "hidden") may be
displayed to the moderator or administrator, subject to a displayed to the moderator or administrator, subject to a
conferencing system's local policies. "Hidden" status is often used conferencing system's local policies. "Hidden" status is often used
by robot participants of a conference (e.g., call recording) and is by automated or machine participants of a conference (e.g., call
also used in many call center situations. recording) and is also used in many call center situations.
11.3. Floor Control Server Authentication 11.3. Floor Control Server Authentication
Clients can authenticate a floor control server using the TLS Clients can authenticate a floor control server using the TLS
certificates. Requests submitted on a successfully created certificates. Requests submitted on a successfully created
connection between the client and floor control server may connection between the client and floor control server may
additionally require digest authentication within the BFCP protocol additionally require digest authentication within the BFCP protocol
to authenticate the floor control client to the server. For this to to authenticate the floor control client to the server. For this to
take place, a shared secret needs to be exchanged between the floor take place, a shared secret needs to be exchanged between the floor
control client/server entities. This can be achieved out of band control client/server entities. This can be achieved out of band
skipping to change at page 42, line 45 skipping to change at page 43, line 31
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 and Avshalom Houri for their reviews Novo, Roni Even, Umesh Chandra, Avshalom Houri and Sean Olson for
and constructive input. their reviews and constructive input.
14. Changes since last Version 14. Changes since last Version
Changes from WG 03 to 04:
- Editorial nits and clarifications.
- Section 4. Template: Removed reference to "user interface
abstractions".
- Section 5.2. Conference Template: deleted references to user
interface abstraction (1st paragraph, last phrase and 4th paragraph).
- Section 9.6. Conference Announcements and Recording: text
expanded. Moved discussion of DTMF to a new section.
- Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference),
with some initial text.
Changes from WG 02 to 03: Changes from WG 02 to 03:
- Updated the definition of Blueprint (per DP 4/4.1 discussions) - Updated the definition of Blueprint (per DP 4/4.1 discussions)
- Added definition for Sidebar. - Added definition for Sidebar.
- Section 5.2 Added text indicating that adding new elements or - Section 5.2 Added text indicating that adding new elements or
modifying elements requires the definition of a new template. (per modifying elements requires the definition of a new template. (per
DP4.2 conclusion). DP4.2 conclusion).
skipping to change at page 47, line 40 skipping to change at page 48, line 40
enhancements might place requirements to provide further additional enhancements might place requirements to provide further additional
protocols and interfaces. A conference object can consist and be protocols and interfaces. A conference object can consist and be
associated with many identifiers that are in some way related to a associated with many identifiers that are in some way related to a
conference object. Good examples include the Binary Floor Control conference object. Good examples include the Binary Floor Control
Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each
use unique identifiers to represent a protocol instance associated use unique identifiers to represent a protocol instance associated
with a conference object. with a conference object.
A conferencing system may maintain a relationship between the A conferencing system may maintain a relationship between the
conference object URIs and the identifiers associated with each of conference object URIs and the identifiers associated with each of
the complementary centralized conferencing protocols (e.g., call the complementary centralized conferencing protocols (e.g., CSP,
signaling protocols, BFCP, etc.). To facilitate the maintenance of BFCP, etc.). To facilitate the maintenance of these relationships,
these relationships, the conference object URI acts as a top level the conference object URI acts as a top level identifier within the
identifier within the conferencing system for the purpose of conferencing system for the purpose of identifying the interfaces for
identifying the interfaces for these other protocols. This implicit these other protocols. This implicit binding provides a structured
binding provides a structured mapping of the various protocols with mapping of the various protocols with the associated conference
the associated conference object identifier. Figure 13 illustrates object identifier. Figure 13 illustrates the relationship between
the relationship between the identifiers used for the protocols the identifiers used for the protocols within this framework and the
within this framework and the general conference object identifier. general conference object identifier.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+------+-------+ +------+-------+
| |
| |
| |
+-----------------+---------------+ +-----------------+---------------+
skipping to change at page 49, line 8 skipping to change at page 50, line 8
can be used. can be used.
The following example illustrates the representation and The following example illustrates the representation and
relationships that might occur in a typical conference instance. The relationships that might occur in a typical conference instance. The
table in Figure 14 lists a typical conference instance and related table in Figure 14 lists a typical conference instance and related
properties. properties.
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
| Conf Obj URI | CSP URI | BFCP Conf-ID | | Conf Obj URI | CSP URI | BFCP Conf-ID |
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
| xcon:Ji092i | sip:Ji092i@example.com | Ji092i | | confid:Ji092i | sip:Ji092i@example.com | Ji092i |
| | tel:+44(0)2920930033 | | | | tel:+44(0)2920930033 | |
| | h323:Ji092i@example.com| | | | h323:Ji092i@example.com| |
+----------------------+------------------------+----------------------+ +----------------------+------------------------+----------------------+
Figure 14: Conference Table Representation Figure 14: Conference Table Representation
The information from Figure 14 can then be applied to the The information from Figure 14 can then be applied to the
representation introduced in Figure 13. This results in Figure 15. representation introduced in Figure 13. This results in Figure 15.
+--------------+ +--------------+
skipping to change at page 54, line 46 skipping to change at page 55, line 46
October 2004. October 2004.
[24] Campbell, B., "The Message Session Relay Protocol", [24] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-14 (work in progress), draft-ietf-simple-message-sessions-14 (work in progress),
February 2006. February 2006.
[25] Jennings, C., "Conference State Change Protocol (CSCP)", [25] Jennings, C., "Conference State Change Protocol (CSCP)",
draft-jennings-xcon-cscp-02 (work in progress), December 2005. draft-jennings-xcon-cscp-02 (work in progress), December 2005.
[26] Enns, R., "NETCONF Configuration Protocol", [26] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-11 (work in progress), February 2006. draft-ietf-netconf-prot-12 (work in progress), March 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. 34 change blocks. 
230 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/