One document matched: draft-barnes-xcon-framework-01.txt
Differences from draft-barnes-xcon-framework-00.txt
XCON Working Group M. Barnes
Internet-Draft Nortel Networks
Expires: June 24, 2005 C. Boulton
Ubiquity Software Corporation
O. Levin
Microsoft Corporation
December 24, 2004
A Framework and Data Model for Centralized Conferencing
draft-barnes-xcon-framework-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document introduces a framework and data model for Centralized
Conferencing (XCON) applicable to participants using different call
signaling protocols and sending media over varying network
topologies. The XCON framework outlines the conferencing protocols,
Barnes, et al. Expires June 24, 2005 [Page 1]
Internet-Draft XCON Framework December 2004
which are complementary to the call signaling protocols, for building
advanced conferencing applications. It also introduces the concept
of an XCON conferencing data model which binds all the defined
components together.
The XCON framework is compatible with the functional model presented
in the SIP Conferencing framework.
This work is being discussed on the xcon@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Conference Info . . . . . . . . . . . . . . . . . . . . . 8
4.2.1 Mixing Pattern . . . . . . . . . . . . . . . . . . . . 8
4.3 Conference Rules . . . . . . . . . . . . . . . . . . . . . 9
5. Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Template . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Conference Policy . . . . . . . . . . . . . . . . . . . . 10
5.4 Reservation . . . . . . . . . . . . . . . . . . . . . . . 10
5.5 Conference State . . . . . . . . . . . . . . . . . . . . . 10
5.6 Policy and State Dependencies . . . . . . . . . . . . . . 11
6. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 12
6.1 Call Control Signaling . . . . . . . . . . . . . . . . . . 12
6.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 12
6.3 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5 Floor Control . . . . . . . . . . . . . . . . . . . . . . 13
7. Conferencing Operations . . . . . . . . . . . . . . . . . . . 14
7.1 Conference Creation and Deletion . . . . . . . . . . . . . 15
7.2 Participant Manipulations . . . . . . . . . . . . . . . . 15
7.3 Media Manipulations . . . . . . . . . . . . . . . . . . . 15
7.4 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 15
7.5 Whispering or Private Messages . . . . . . . . . . . . . . 15
7.6 Conference Announcements and Recordings . . . . . . . . . 15
8. Relationships between SIPPING and XCON Frameworks . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
12.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Barnes, et al. Expires June 24, 2005 [Page 2]
Internet-Draft XCON Framework December 2004
Intellectual Property and Copyright Statements . . . . . . . . 19
Barnes, et al. Expires June 24, 2005 [Page 3]
Internet-Draft XCON Framework December 2004
1. Introduction
This document introduces a framework and data model for Centralized
Conferencing (XCON) applicable to participants using different
signaling protocols and sending media over varying network
topologies. The framework is protocol agnostic and is equally
applicable to SIP, H.323, Jabber, HTML, PSTN, etc. and mixed
conferencing systems.
The XCON framework provides an expanded functional model by outlining
the complementary (to call signaling interface) conferencing
protocols between primary components for building rich conferencing
applications and by introducing the data model which binds all the
defined components together.
2. Conventions and Terminology
The XCON framework document uses when appropriate and expands on the
terminology introduced in the SIP conferencing framework [3]. The
following additional terms are defined for use within the XCON
conference framework.
Conference Information: The XML definition of all conference
components pertaining to the conference membership, media mixing,
etc. including capabilities and limitations of each.
Media Pattern: An abstract definition of mixer behavior registered
with IANA and used by an XCON system for representing its
supported media mixing modes (as a part of the conference
information definition). The IANA registration MUST include the
text description of the mixer behavior and optionally the XML
definition to allow configuration, state presentation, and the
mapping of input/outputs, media controls, sliders, radio boxes,
etc. - if applicable.
Conference Rules: The XML definition of rules pertaining to a
conference creation and to the conference (information)
manipulation at different stages of the conference lifetime.
Conference Policy: A dynamically created data object which contains a
set of rules defined at the onset of a conference and that can be
modified during the conference lifetime.
Conference Policy Control Protocol (CPCP): A protocol used by clients
to manipulate the conference policy, most frequently outside the
scope of an active conference.
Conference Template: One of the static data objects created by and
kept in an XCON system that reflects the capabilities of the
system and is used to specify a tailored conference instance. A
template provides the conference creator the default conference
information required for successful conference creation with
desired values (falling within boundary ranges) and default values
Barnes, et al. Expires June 24, 2005 [Page 4]
Internet-Draft XCON Framework December 2004
if not explicitly specified.
Conference Reservation: A dynamically created (using Conference
Template) data object which represents the status and the
capabilities of an allocated conference instance and can have
re-occurring properties.
Conference State: A dynamic data object which represents the status
of an active conference instance, is created on the conference
focus onset, and is maintained by the focus in conjunction with
information provided by other XCON components.
Centralized Conference Control Protocol (CCCP): A protocol used by
clients to manipulate the conference state during an active
conference instance.
Floor: A term used to apply to a set of data or resources associated
with a conference instance, for which a conference participant (or
group of participants) is granted temporary input access.
Floor Chair: A Floor control protocol compliant client (human
participant or automated entity) who is authorized to manage
access to one floor (grants, denies, or revokes a floor). The
floor chair does not have to be a participant in the conference
instance.
Multimedia stream: In the context of this framework document, this
term is used to refer to the media composition of a conference
instance, which is established via the signaling protocol between
a focus and a participant. The multimedia stream is the union of
a set of media such as voice, video, session-mode instant
messaging, and interactive text that contribute to the conference
instance mix. [Editor's Note: may need to revisit this definition
based on Keith's L.'s mailing list comments on the previous
version of the doc.]
Sidebar: TBD.
Signaling Interface (I/F): The session signaling protocol used
between a participant and a focus instance.
State: See "Conference State".
Template: See "Conference Template".
Whisper: TBD.
3. Overview
The fundamental requirements for conferencing are outlined in [1].
These requirements are applicable for conferencing systems using
various signaling protocols, including SIP.
The centralized conferencing model proposed in this document is based
on the following fundamental data types:
o Conference Information
o Conference Rules
Barnes, et al. Expires June 24, 2005 [Page 5]
Internet-Draft XCON Framework December 2004
The realization of a conference in the XCON system can be represented
using the following data objects (being composed of the data types
above):
o Conference Template
o Conference Policy
o Conference Reservation
o Conference State
Figure 1 illustrates the composition of a conference instance
life-cycle from creation to full state using the data objects
presented.
+---+-----------------------+
| | |
| R | |
| U | |
| L | T E M P L A T E |
| E | |
| S | |
| | |
+---+-----------------------+
|
|
V
+---+-----------------------+
| | |
| R | |
| U | |
| L | R E S E R V A T I O N|
| E | |
| S | |
| | |
+---+-----------------------+
|
|
V
+---------------------------+
+-+-------------------------+ |
+-+-+-----------------------+ | |
| | | | |
| R | | | |
| U | | | |
| L | I N S T A N C E | | |
| E | | | |
| S | | |-+
| | |-+
Barnes, et al. Expires June 24, 2005 [Page 6]
Internet-Draft XCON Framework December 2004
+---+-----------------------+
Figure 1: Conference Definition, Creation, and Lifetime
[Editors note: Add text around figure 1.
Figure 2 illustrates the decomposition of Conference info.
+----------------------------------------------------+
| C O N F E R E N C E I N F O R M A T I O N |
| T Y P E |
| +----------------------------------------------+ |
| | Conference Description | |
| +----------------------------------------------+ |
| +----------------------------------------------+ |
| | Membership (Roles, Capacity, Names) | |
| +----------------------------------------------+ |
| +----------------------------------------------+ |
| | Signaling (Protocol, Direction, Status) | |
| +----------------------------------------------+ |
| +----------------------------------------------+ |
| | Sidebars, Etc. | |
| +----------------------------------------------+ |
| +------------+ +-----------+ +-------------+ |
| | User Input | | Audio Mix | | Video Tiles | |
| | Pattern | | Pattern | | Pattern | |
| +------------+ +-----------+ +-------------+ ... |
+----------------------------------------------------+
Figure 2: Conference Info Decomposition
[Editors note: Add text around figure 2.
Section 4 of this document describes the fundamental XCON data
types. Section 5 of this document describes XCON data objects based
upon these data types. Section 7 then describes the manipulation of
these data objects in support of the conferencing operations, using
XCON defined protocols. Section 6 describes the fundamental
conferencing mechanisms and provides a high level overview of the
XCON protocols. Section 8 of this document provides a summary of the
relationship between the XCON framework and the SIPPING Conferencing
framework, in the context of the XCON data model, highlighting the
XCON and other signaling interfaces.
4. XCON Data Model
Barnes, et al. Expires June 24, 2005 [Page 7]
Internet-Draft XCON Framework December 2004
4.1 General
The information related to any conference can be segmented into two
main data types: the conference information and the conference rules.
o Conference information: The definition of all conference
components pertaining to the conference membership, media mixing,
etc. including capabilities and limitations of each.
o Conference rules: The set of permissions pertaining to a
conference creation and to the conference (information)
manipulation at different stages of the conference lifetime.
The XCON data model defined in this framework has no strict
separation between conference membership, conference media
information and the related policies. This meets the requirement in
many conference control operations to enable synchronized access to
the conference policy as a whole, to the conference state as a whole,
and for receiving notifications about changes to either.
4.2 Conference Info
The basic conference-info type definition has been introduced in [4]
and is being extended by XCON [TBD]. This definition contains all
relevant data components required for representing a conference
instance, including its membership, roles, capabilities and
limitations at different stages in its life-cycle. The conference
information is used for describing an XCON conferencing systems
capabilities through the concept of a template (see Section 5.2), for
conference reservations (see Section 5.4), for describing the
conference state (see Section 5.5), and for providing snapshots of
the conference information at any of the stages of the conference
life-cycle.
The Conference-info also includes the definition of the conference
mixing patterns.
4.2.1 Mixing Pattern
The concept of a "Mixing Pattern" is introduced in order to abstract
the complexity and the details of the mixers' implementation by each
conferencing server.
Each Mixing Pattern type needs to be registered with IANA. The IANA
registration MUST include the text description of the mixer behavior
and optionally the XML definition to allow configuration, state
presentation, and the mapping of input/outputs, media controls,
sliders, radio boxes, etc. - if applicable.
Barnes, et al. Expires June 24, 2005 [Page 8]
Internet-Draft XCON Framework December 2004
4.3 Conference Rules
Conference rules are defined in terms of TBD
The XCON CPCP [9] contains an example of a conference policy schema.
5. Data Objects
5.1 General
Any XCON system and any XCON conference instance can be represented
using the objects described below.
o Conference Template is a static data object created by and kept in
an XCON system that reflects the capabilities of the system. A
template provides the conference creator the default conference
information required for successful conference creation with
desired values (falling within boundary ranges). An XCON client
has the ability to query an XCON compliant server to obtain a list
of supported templates.
o Conference Policy is a dynamically created data object which
contains a set of rules defined at the onset of a conference and
that can be modified during the lifetime of a conference instance.
o Conference Reservation is a dynamically created data object which
represents the status and the capabilities of an allocated
conference instance and can have re-occurring properties. A
conference reservation is created using the rule-set defined by a
conference template.
o Conference State is a dynamic data object which represents the
status of an active conference instance, is created on the
conference focus onset, and is maintained by the focus.
Conference state can is crated from a migration from a Conference
Reservation (creation of focus). This can either be the result of
a client specified Conference reservation or due to the dynamic
creation of a conference reservation (Ad-Hoc Conference)
containing a set of pre-defined default values.
5.2 Template
A conference template is a static semantic XML representation of an
XCON conference. It provides relevant information that enables an
authorized creating entity the ability to define the required
granularity of conference configuration detail. An XCON conference
server SHOULD/MUST support a minimum set of templates as defined in
[ref to template draft]. If proprietary modifications are required
to a template, the guidelines for creating/modifying templates, as
defined in [ref], MUST be obeyed to maintain semantic continuity.
This provides conference clients that receive unknown template
features the ability to render information (e.g. an additional radio
Barnes, et al. Expires June 24, 2005 [Page 9]
Internet-Draft XCON Framework December 2004
button can be rendered to the user and it's value conveyed and
selected by the client, even though it is not part of a standard
template.
[Editors Note: To be developed and aligned with XCON working group
consensus.]
5.3 Conference Policy
Conference policy is a set of rules that are defined at the onset of
a conference and MAY be modified during the conference lifetime.
At the conference onset, the Conference policy would typically be
applied to the template (see Section 5.2) resulting in creation of
the conference reservation (see Section 5.4) and/or state (see
Section 5.5) object(s). During the conference reservation and/or
state lifetime, any requested conference manipulation is checked
against the conference policy object.
The XCON CPCP [9] contains an example of a conference policy schema.
5.4 Reservation
The concept of a "reservation" is introduced [ref]. A reservation
can be described as being an instantiated conference template (as
defined in Section 5.2) that is 'pre-state'. 'Pre-State' means that
the creating client has uploaded the customized template to the
conference server. The server has verified that no semantics of the
template and no Conference Policy has been violated. The desired
conference is then considered instantiated and recognized as a
conference waiting to commence (TODO - clear definition of
reservation --> conference instance state change required). This
means that a semantically valid XCON conference template has been
utilized for creating a conference reservation. The proposed
reservation is then uploaded to the conference server using the
specified interface mechanism (TODO: expansion required when
appropriate detail available). All variable values specified for the
instantiated conference definition fall in the ranges supplied by the
constraints of the templates XML definition and default values are
used if not specified. An attempt to instantiate a conference value
within a template that does not comply will be rejected.
[Editors Note: To be developed and aligned with XCON working group
consensus.]
5.5 Conference State
Conference state is the set of dynamic information describing a
Barnes, et al. Expires June 24, 2005 [Page 10]
Internet-Draft XCON Framework December 2004
conference instance in progress. This information can include the
focus information, participants' information, associated media
sessions in progress, the current loudest speaker, the current chair,
etc. The basic XML schema is defined the SIPPING Conference Package
[4].
There are different ways to affect the conference state.
A participant can join and leave the conference using the signaling
interface only. A participant can change its own media streams using
the signaling interface only. This kind of operations is called "1st
party signaling" and does not affect the state of other participants
in the conference instance.
Limited operations for controlling other conference participants (a
so called "3rd party control") through the focus are possible using
some signaling interfaces. In SIP for example, REFER can be used for
this purpose as described in [5].
In order to perform richer conference control a user agent client
needs to implement a CCCP client interface. Using CCCP, a client can
directly affect its own conference state, conference state of other
participants, and the state of the Focus/MCUs/"mixers", etc. which
may also indirectly affect the state of other participants.
Conference control using CCCP is logically performed on the
conference state. Using CCCP requests, a client can directly
manipulate the conference state data object. The CCCP server
receives the state change requests and interacts with the focus to
ensure that the required operations (e.g. signaling) are carried
out.
Changes in the conference state are reported to conference
participants and authorized parties using well-defined event
mechanisms subject to each interested parties privileges. For
example, for SIP entities it is the Event Notification mechanism
defined in RFC 3265 [16].
5.6 Policy and State Dependencies
Changes in the conference policy can automatically cause changes in
the conference state, while changes in the conference state never
change conference policy.
There are many examples of how a change in conference policy can
change the state - changing the end time of a conference causes the
conference to end early, reducing the maximum number of participants
could cause some to be removed.
Barnes, et al. Expires June 24, 2005 [Page 11]
Internet-Draft XCON Framework December 2004
A change in conference state never changes the conference policy
because by definition the conference policy must authorize any change
in state. If a request fails due to a policy, this will be indicated
in the response reason. The user may then attempt to change the
policy, and then retry the state change request.
For example, a user may request a participant to be added to a
conference. The focus must check the policy to see if the user's
role and/or URI allow the user to participate in the conference. For
example, the policy might say that only members of example.com may
join the conference.
6. Conferencing Mechanisms
6.1 Call Control Signaling
The focus is the central component of the conference. Participants
interface with the focus using an appropriate Call Control Signaling
protocol. Participants request to establish or join a conference
using the Call control signaling interface. A focus then either
accepts (after checking the policy), sends a progress indication
(e.g. for a parked call while awaiting moderator approval to join)
or rejects that request using the call control signaling interface.
In the case of an active conference, CCCP would be used to affect the
conference state. For example, CCCP requests to add and delete
participants will be communicated to the focus and checked against
the conference policy rules. If approved, the participants will be
added or deleted using the call signaling to/from the conference
instance by the focus.
6.2 Notifications
The focus is responsible for implementing a Conference Notification
Service. The role of the Conference Notification Service is to
provide updates on the Conference State to authorized parties (e.g.
participants) as defined in [4].
6.3 CPCP
A Conference Policy Control Protocol (CPCP) is proposed as a
standardized means of storing and manipulating the Conference Policy.
The conference policy is comprised of the rules associated with a
specific conference instance. These rules can be modified during the
life-cycle of a conference instance. Requirements for the CPCP are
defined in the CPCP Requirements document [8]. The Conference Policy
Control Protocol document [9] defines the XML Schema for the
conference policy data elements.
Barnes, et al. Expires June 24, 2005 [Page 12]
Internet-Draft XCON Framework December 2004
The privileges as to which users are allowed to read and/or
manipulate a specific Conference Policy instance are defined in a
separate Extensible Markup Language (XML) Schema[11]. This schema is
based on the common policy model being used for geographic privacy
information and for presence information.
A separate document [10] proposes XCAP as one protocol mechanism for
storing and manipulating this conferencing policy data. XCAP is a
HTTP 1.1 based protocol that allows clients to read, write, modify
and delete application data stored in XML format on a server. One of
the main advantages of XCAP is that it maps XML document elements and
attributes to HTTP URIs that can be directly accessed by HTTP.
6.4 CCCP
A Centralized Conferencing Control Protocol [12] is defined to allow
participants or otherwise authorized entities to directly manipulate
an active conference. CCCP is defined as a set of transactions
issued over a reliable transport protocol. A transaction consists of
a Request carrying the required information in an XML body and a
corresponding Response carrying an appropriate XML body.
CCCP requests are submitted to the focus and can be prioritized and
queued, or even interleaved based on the requestor's role and the
corresponding affected XML element(s). CCCP requires no single lock
per document, and the CCCP server functionality supported by the
focus, can locally define an optimization strategy independent of
CCCP client behavior.
6.5 Floor Control
A mechanism for floor control within an XCON conferencing system is
defined in the 'Binary Floor Control Protocol' specification [7].
Floor control is not a mandatory mechanism for an XCON server
implementation but provides advanced media input control features for
participants.
An XCON compliant client supporting floor control needs to obtain
information for connecting to a floor control server to enable it to
issue floor requests. This connection information can be retrieved
using information provided by mechanisms such as negotiation using
the SDP[18] offer/answer[21] exchange on the signaling interface with
the focus.
As well as the Client --> Floor Server connection information, a
client wishing to interact with a Floor Control server requires
access to additional information. This information associates Floor
Control interactions with the appropriate Floor instance. Once a
Barnes, et al. Expires June 24, 2005 [Page 13]
Internet-Draft XCON Framework December 2004
connection has been established and authenticated (see [7] for
authentication details), a specific floor control message requires
detailed information to uniquely identify a user, a floor and a
conference instance. This information, defined in the next set of
bullet points, can be obtained using methods such as negotiation
using the SDP[18] offer/answer[21] exchange on the signaling
interface with the focus:
o Conference ID - Each XCON conference instance has a unique
conference identifier. This is obtained from the Conference
server and MUST be included in all Floor messages. When using
SDP[18] offer/answer[21] exchange to negotiate a Floor control
connection with the focus using the signaling interface, the
unique conference identifier is contained in the 'confid' SDP
attribute, as defined in [20] e.g. a=confid:2874.
o User ID - Each user within an XCON conference (as represented by
Conference ID) has a unique identifier within that instance. This
is obtained from the Conference server and MUST be included in all
Floor messages. When using SDP offer/answer exchange to negotiate
a Floor control connection with the focus using the signaling
interface, the unique conference identifier is contained in the
'userid' SDP attribute, as defined in [20] e.g. a=userid:8937.
o Floor ID - A media session with an XCON conferencing server can
have any number of 'Floors' (0 or more) that are represented by a
unique identifier within the conference instance (as represented
by Conference ID). When using SDP offer/answer exchange to
negotiate a Floor control connection with the focus using the
signaling interface, the unique conference identifier is contained
in the 'floorid' SDP attribute, as defined in [20] e.g.a=floorid:1
m-stream:10 . Each 'floorid' attribute, representing a unique
floor, has an 'm-stream' tag containing one or more identifiers.
The identifiers represent individual SDP media sessions instance
(as defined using 'm=' from SDP[18]) using the SDP 'Label'
attribute as defined in [19].
7. Conferencing Operations
This section addresses how the scenarios identified in [2] can be
realized with the functionality provided by the XCON protocols.
The SIP specific mechanisms for some of these operations are
described in [3].
[Editor's note: This whole section needs additional work based upon
the new agreed model, new terminology and needs to reflect the rework
done in the other WG documents. In the end, some XML snippets would
also likely be useful.]
Barnes, et al. Expires June 24, 2005 [Page 14]
Internet-Draft XCON Framework December 2004
7.1 Conference Creation and Deletion
When a conference is first initiated via the Call Signaling Interface
from a client, the focus uses a template to create the initial
conference instance, applying the rules associated with the
particular conference.
There are several ways in which a conference can be created: ad-hoc
using the Call Control Signaling (with default template implicitly)
or by CCCP with pointing to a specific template and applying rules to
it. TBD more.
7.2 Participant Manipulations
Participants manipulate an active conference using Call Control
Signaling and/or a CCCP protocol. The Call Control signaling impacts
the conference indirectly based on the actions taken by the Focus
based upon the signaling (e.g. add a party to the conference). CCCP
allows a participant to directly impact the conference state, however
the focus still ensures that any manipulations comply with the rules.
7.3 Media Manipulations
CCCP can be used to manipulate the media during an active conference.
As a result, focus will use signaling interface towards the
participants forcing the requested conference state.
7.4 Sidebar Manipulations
7.5 Whispering or Private Messages
7.6 Conference Announcements and Recordings
[Editor's note: this needs a lot of revamping based on new model,
also taking into consideration Cullen's comments on the previous
version of doc ].
8. Relationships between SIPPING and XCON Frameworks
The following diagram is intended to show at a high level the
relationship between the fundamental model introduced in [3] and the
basic data elements required for supporting the XCON data model.
Further detail of the XCON data model is provided in Section 4 of
this document.
[Editor's note: Insert here a diagram similar to the one in the
Barnes, et al. Expires June 24, 2005 [Page 15]
Internet-Draft XCON Framework December 2004
powerpoint charts (an updated/modified version of what was presented
at IETF-61)]
9. Security Considerations
The framework put forth in this draft introduces signaling interfaces
which have a variety of potential threats. Each of the specific
protocols defined in support of this framework must adequately
address those threats.
10. IANA Considerations
This is an informational draft, with no IANA considerations required.
11. Acknowledgements
This document is the result of XCON working group architectural
discussions among Hisham Khartabil, Roni Even, Adam Roach, Alan
Johnston, Brian Rosen, Paul Kyzivat, Cullen Jennings, Keith Lantz,
Henning Schulzrinne, and the authors.
12. References
12.1 Normative References
12.2 Informative References
[1] Levin, O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing",
draft-ietf-sipping-conferencing-requirements-01 (work in
progress), October 2004.
[2] Even, R., "Conferencing Scenarios",
draft-ietf-xcon-conference-scenarios-02 (work in progress),
July 2004.
[3] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in
progress), October 2004.
[4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-08 (work in progress),
December 2004.
[5] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
Barnes, et al. Expires June 24, 2005 [Page 16]
Internet-Draft XCON Framework December 2004
draft-ietf-sipping-cc-conferencing-06 (work in progress),
November 2004.
[6] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-02 (work in progress),
October 2004.
[7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-01 (work in progress), October 2004.
[8] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), August 2004.
[9] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[10] Khartabil, H., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usages for Conference
Policy Manipulation and Conference Policy Privelges
Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress),
October 2004.
[11] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Conference Policy",
draft-ietf-xcon-conference-policy-privileges-01 (work in
progress), October 2004.
[12] Levin, O. and G. Kimchi, "Centralized Conference Control
Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in progress),
October 2004.
[13] Jennings, C., "Media Mixer Control for XCON",
draft-jennings-xcon-media-control-01 (work in progress), July
2004.
[14] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
draft-rosen-xcon-conf-sidebars-01 (work in progress), July
2004.
[15] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Barnes, et al. Expires June 24, 2005 [Page 17]
Internet-Draft XCON Framework December 2004
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[18] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[19] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-00 (work in progress),
September 2004.
[20] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), October
2004.
[21] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Authors' Addresses
Mary Barnes
Nortel Networks
2380 Performance Drive
Richardson, TX
EMail: mary.barnes@nortelnetworks.com
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
EMail: cboulton@ubiquitysoftware.com
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: oritl@microsoft.com
Barnes, et al. Expires June 24, 2005 [Page 18]
Internet-Draft XCON Framework December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Barnes, et al. Expires June 24, 2005 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:40 |