[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-xcon-framework

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/