2.7.18 Centralized Conferencing (xcon)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional XCON Web Page

Last Modified: 2005-02-02

Chair(s):

Adam Roach <adam@nostrum.com>
Alan Johnston <alan.johnston@mci.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: xcon@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/xcon
Archive: http://www.ietf.org/mail-archive/web/xcon/index.html

Description of Working Group:

The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong
security and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization (known as a focus) so they can enforce specific media and
membership relationships, and provide an accurate roster of
participants. The media mixing or combining function of a
tightly-coupled conference need not be performed centrally, however.

The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.

Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be invisible to all but the conference owner, or to be
visible but participate anonymously with respect to some or all of
the other participants.

Authorization rules allow for participants and non-participants
to have roles (ex: speaker, moderator, owner), and to be otherwise
authorized to perform membership and media manipulation for or on
behalf of other participants. In order to preserve these properties,
the protocols used will require implementation of channel security
and authentication services.

Due to the centralized architecture of the WG, XCON's mechanisms will
place requirements on the signaling protocol used between the focus and
the participants. At a high level, the signaling protocol must be able
to establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in
both a centralized and distributed mixing architecture. SIP will be the
reference session signaling protocol used for examples; however, none
of
the XCON solutions themselves will be signaling protocols, nor will
XCON
extend existing signaling protocols. Other signaling protocols than SIP
may be used between the focus and participants, including non-IETF
protocols, but the requirements and possible extensions needed for
other
signaling protocols to utilize the full functionality of the XCON
architecture is outside the scope of XCON.

The deliverables for the group will be:
- A mechanism for membership and authorization control
- A mechanism to manipulate and describe media "mixing" or "topology"
  for multiple media types (audio, video, text)
- A mechanism for notification of conference related events/changes (for
  example a floor change)
- A basic floor control protocol

The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.

The following items are specifically out-of-scope:
- Voting
- Fully distributed conferences
- Loosely-coupled conferences (no central point of control)
- Far-end device control
- Protocol used between the conference controller and the mixer(s)
- Capabilities negotiation of the mixer(s)
- Master-slave cascaded conferences

The working group will coordinate closely with the SIPPING and
MMUSIC working groups. In addition the working group will cooperate
with other groups as needed, including SIP, MSEC, AVT, and the W3C
SMIL working groups. In addition, the working group will consider
a number of existing drafts as input to the working group.

Goals and Milestones:

Oct 03  Submit Requirements for Membership Manipulation for publication as Informational
Oct 03  Submit Requirements for Basic Floor Control for publication as Informational
Nov 03  Submit Conferencing Scenarios document for publication as Informational
Nov 03  Submit Use Cases for Media Topology Control for publication as Informational
Dec 03  Submit Requirements for Media Topology Control for publication as Informational
Feb 04  Submit Basic Floor Control Protocol for publication as PS
Mar 04  Submit Notification Event package extension for conference related events for publication as PS
May 04  Submit Membership Manipulation Protocol for publication as PS
Jul 04  Submit Protocol for Media Topology Control for publication

Internet-Drafts:

  • draft-ietf-xcon-cpcp-reqs-04.txt
  • draft-ietf-xcon-floor-control-req-03.txt
  • draft-ietf-xcon-cpcp-xcap-03.txt
  • draft-ietf-xcon-bfcp-03.txt
  • draft-ietf-xcon-conference-policy-privileges-01.txt
  • draft-ietf-xcon-cpcp-01.txt

    No Request For Comments

    Current Meeting Report


    Tuesday, March  8 at 1645-1745
    ===============================

    CHAIRS: Alan Johnston <alan.johnston@mci.com>
            Adam Roach <adam@nostrum.com>

    SCRIBE: Spencer Dawkins <spencer@mcsr-labs.org>

    AGENDA:

    TUESDAY, March 8, 2005
    ----------------------
    1645-1745 Afternoon Sessions III

    1645-1650 Agenda Bash
    • No agenda bashing took place
    1650-1700 WG Status various
    Chairs 15 min
    • Need authors! Not all of our work items have authors.
    • Need more mailing list discussion
    • Do we still care enough about this work to continue?
    • Conference Scenarios WGLC starts as soon as document reissued
    • Notification Event is deliverable, but not yet started - once framework is reasonable, this work should start - but SIPPING is already working in the area now - we're designing in piecemeal and it's not working, we're going to be stuck with what comes out of SIPPING conference package, and this is an unfortunate fact of life. WG can consider multiple models.
    • Floor control requirements document going to IESG with protocol specification. Some authentication concerns about SHA-1.
    • Conference state manipulation mechanism still under discussion. CCCP and CSCP are active proposals, will revive and reissue requirements document.
    1700-1745 Framework draft-barnes-xcon-framework-02.txt
    Mary Barnes 45 min
    • This is second total rewrite, so if you haven't read this document lately, please do so
    • Remains protocol agnostic
    • Simplified terminology, defined "focus", added new terms and removed unused terms, used Conferencing System instead of XCON server, etc.
    • Updated Template terminology - this is getting closer, but might still be an issue. Templates are human-readable, clients can query them
    • For each conference type, we might have two types of templates, one semantic and the other syntactic, could we mention this in the framework?
    • Simplified data model - policy is part of the Conference Object - Common Conference Information plus Conference Template, supports each instance of a conference
    • Where are policies for maniputlation? In the document we're manipulating?
    • Introduced a "Cloning Tree" as model for system realization
    • Introduced use of iCal for scheduling
    • Added background to set context - no duplication of SIPPING conferencing framework
    • SIP used only as example protocol
    • Current version defines baseline terminology
    • Model is simplified in 02 version.
    • Conference Object Type not changed too much from 01 version.
    • Cloning Tree - can clone another parent tree, can create children of each parent conference
    • Issue 1 - referring to sets of meetings. iCal is required mechanism, used to describe "time". Cloning tree is used to create conference object for reservation.
    • Is it necessary to be able to identify "all future occurances" of a conference? Should be supportable if so.
    • Conference time is iCal time, all other times are deltas from iCal time? When does dialout happen, when does mixing happen, etc. We've never come up with a conference start time that worked - modern systems make URIs valid immediately and forever.
    • "Start time" is the time the user reserved for the conference to start.
    • Need to distinguish between conferences that repeat - need to take this into account when we're doing delta times. Time for series, time for conference, then delta times. Many delta times may be set at the root of the tree anyway (mixing always starts 10 minutes early).
    • One time that has a timezone, for any occurance of a conference.
    • What will iCal actually send us as a time? Will it be useable without modifications?
    • We cycled CPL for two years trying to use a subset of iCal - is this a bad idea? iCal has more interoperability than anything we'll design here.
    • iCal will give us user-visible time - T0 needs to be the most natural thing a user will refer to.
    • Issue 2 - Groups of RTP streams for floor control - do we need this? Stream name specific to a role? Mailing list indicates that we don't;.
    • Issue 3 - Querying templates - discussed getting template descriptions without coming to consensus or closure. Will clients be able to interact with templates they don't understand based on variable descriptions? This is our server, not IANA's server.
    • Will this be an XML schema or a "blueprint" per current framework? One is a schema, the other is an object. Have to get values from a blueprint, not from a schema.
    • What about the non-constant portion? Difficult to add values to a schema.
    • We like blueprints, but schemas would also be useful - not sufficient
    • Needs to be some mechanism for communication between frameworks and schemas
    • Can we punt on these details pending other discussions on actual data representations?
    • If you don't have a schema, you need it when you join the conference.
    • We agreed on this in the room
    • Clients will query any templates they don't understand and then make a decision on compatibility? We agreed on this, too.
    • Should we include User Interface "hints"? We proposed "yes", but don't even know if the device has a screen, a display, etc... Not display description language, not postscript ... how you choose to represent this based on hints is up to you. We'll do this until we have more experience working through examples.
    • Issue 4 - XML Schema Structure - Is template at the top level? Common conference information? Template and common conference information as two separate objects? Editors prefer Common conference information at top level.
    • What does "navigate" mean? Do all templates contain common conference information? How do you find the common state?
    • XML extension is always ugly - prefer two separate objects.
    • Need more research and discussion on the list - we could revisit at Thursday meeting if we talk fast.
    • Issue 5 - State and Policy Manipulation Protocols - Syntactic? Semantic with explicit operations? Both?
    • We wanted a single protocol, but might be able to combine both approaches.
    • Proposal is for Semantic operations - protocols proposed include CPCP, CCCP, CSCP, Netconf.
    • It's a little early to analyze pros and cons - can we declare this as something we'll revisit when we're smarter?
    • Why do we need a single protocol if we have two separate things we want to do? This can be nice, but is a second priority.
    • Issues from WG Review:
    • Section 4.1 is confusing - reword to point to section 5 (which helps the reader understand).
    • Some text is definitely wrong (cardinalities don't match)
    • Include floors in Figure 2.
    • Section 4.5 - data access rights seems very much like common conference rules - didn't rules go away? Terms are causing more confusion than we're curing. Just be clearer and more explicit. General rules still FFS/out of scope
    • Bootstrapping problem with data access rights? No, these are separated out now.
    • Document is still inconsistent about whether CPCP is really gone, etc. This will be carried as an open issue - need further discussion, still unclear.
    • Section 6.4 - needs additional work - what's in there now is trying to align with BFCP and this isn't helping.
    • Section 6.4.1 and Section 7.1 are also issues.
    • Adopt this draft as WG item? humming was unanimously "yes"

    Slides

    Agenda
    XCON Framework Overview & Issues
    Binary Floor Control Protocol (BFCP)
    SIP Event Package for Conference Floor State
    XCON data modeling – NETCONF, RDF and others
    Conference State Control Protocol (CSCP)
    draft-levin-xcon-cccp-02.txt
    Media Control