2.7.2 Interim Meeting - 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


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

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
the XCON solutions themselves will be signaling protocols, nor will
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
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


  • 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

    Interim Meeting Report

    Interim XCON Meeting
    Wednesday, January 5th, 1300 - 1515

    Current status of the framework doc:
    - Total rewrite from -00 version based on IETF 61 discussion.
    - Terminology and descriptions remain call signaling protocol
    agnostic. SIP is used only as an example protocol.
    - Centers on data model (types and objects).
    - No duplication of content from SIPPING Conferencing Framework.
    - Current version intended to provide the baseline terminology,
    model and high level interfaces (including protocols). More work
    required to describe detailed functionality once basics are agreed.

    Block diagram available in Mary's Powerpoint slides
    Much debate about various arrows, to be resolved "offline".

    On the topic of templates: Orit summarized the position taken in the
    framework draft, where a template <IS> an object -- one that can be
    "copied" (instantiated) but not modified. That is, the templates
    themselves are created at system boot time and subsequently used to
    instantiate conferences, which may be subsequently modified.

    Issue: What do we call a conference-specific instance? "State" can be
    confusing because each of the conference objects has its own "state". A
    variety of suggestions were lofted -- including "occurrence" -- all with
    implications that would be incompatible with various resolutions of the
    ongoing Thing A/B/C debate. Correspondingly, Keith L., et al. opined that
    we need to resolve the data/object model before deciding on specific
    labels. This suggestion was more or less accepted, however grudgingly,
    and much of the remaining discussion focused on the much loved topic of
    recurring meetings.

    Cullen, et al.: One of the key "realities" we need to deal with is being
    able to distinguish between two concurrent/overlapping instances of the
    same recurring meeting -- e.g. when one occurrence scheduled from 10-11
    runs over into a second occurrence scheduled from 11-12. If you want
    to disallow the 11-12 participants from joining the late running 10-11
    occurrence, you can't use the same URI for the second occurrence. But,
    is this a real concern? If these are really just two occurrences of the
    same recurring meeting, do we really need to worry about it? It's not
    the same as allowing two people to assign the same PIN to two entirely
    different meetings -- one from 10-11 and one from 11-12 -- then allowing
    participants in one meeting to enter the other. That should not be

    This led to a discussion of how to name individual instances (specifically
    the "current" instance) of a recurring conference and all instances
    (the series) ... which in turn led (somehow ;-) ) to the hypothesis
    that we will probably end up with multiple namespaces -- e.g. xcon:<x>
    or cpcp:<x>, in addition to sip:<x> for foci).

    At least one consensus emerged from this discussion (!): We need to
    be able to identify (a) a single occurrence/instance of a recurring
    meeting and (b) all instances of a recurring meeting. N.B. This is a
    necessary, but may not be sufficient. That is, it may also be necessary
    to be able to easily identify (e.g. via a URI) the "next" occurrence
    or "all FUTURE occurrences" or even "all occurrences between date X
    and date Y". Providing a URI for the last is particularly problematic,
    however. Correspondingly, resolution on those extensions to the consensus
    is TBD.

    Henning then reintroduced the notion of separating time completely from
    the conference service. This begs the perennial question, however, as to
    how one can deliver a usable XCON-enabled conferencing service -- that
    is, one that supports resource reservation -- if (a) XCON itself doesn't
    produce anything that deals with time and (b) existing calendaring vendors
    (e.g. Microsoft and Lotus) don't extend their systems to understand
    conferencing resources. vCal was offered as one possible way to fill
    this gap, but there was nothing approximating a consensus answer to
    the question.


    Wednesday, January 5th, 1530 - 1800

    Floor Control

    Alan: Requirements & BFCP docs have been revised. WGLC real soon now.

    Henning: Is BFCP the ONLY solution, or is it one of many possible protocols
    for the floor control problem?

    Adam: We probably will not pursue alternatives.

    Cullen: Gonzalo posted set of open issues on BFCP, around SDP. Those are in
    a separate MMUSIC document.

    Alan: Floor control is a separable problem, and users other than XCON can
    use it.

    Back to the Framework
    Do we need a different definition of Focus, given the SIPPING definition
    is a sip: URI? Not really, since SIPPING says *usually* a sip: URI,
    but actually a "conference" URI. We will look into this tomorrow 1/6.

    Multimedia Stream definition has not changed. However, everything seems
    to be in the context of RTP streams, so we don't see multimedia streams,
    only individual sets of RTP streams.

    Consensus achieved on removing the term "multimedia stream". However,
    Roni points out that we do need to address aggregates of streams.
    Eric calls them "bundles".

    XCON Server, Systems, or ???:
    Henning points out that WG names aren't meaningful.
    Will address and name appropriately later.

    Schemas & Templates:

    Can you have limits in the template thing?

    People think so, but Orit points out that one cannot express that in XML

    Roni points out that we're looking at something that looks like H.248

    Cullen: just wants to make sure you can easily fill in parameters when it is
    time to instantiate conference.

    Is this a hierarchy of types or a collection?

    What is the document? Brian: it is something you read, like a RFC. It might
    contain an XML schema, but the important stuff will probably be in English

    What do you get back when you ask the server, "What do you support?" You get
    back the name of the document (template you registered). Then you can
    instantiate objects.

    Henning: why does the client ever need to see XML?

    Henning: why not just use XForms? Gives us everything we need, like things
    to fill in, ranges, default values, etc.
    XCAP model is exactly wrong: everything is a part of an XML document.
    Henning would rather have each template thing as a protocol element. If you
    want to change something, you send a new, complete document.

    Admin Interrupt: let's defer to when we agree on

    Agree: RFC (document) with text description, with XML Schema. Get a thing
    that has things to fill in. Client can query for list of templates. IANA
    registry is a triplet {name, RFC, XML Schema} Figure out later if lots of
    XML gets transmitted.

    Disagree: is this something like a user interface or a data interchange

    How is XML extended and nested?
    Brian: extensions in XML are ugly and hard to do. Therefore, have variable
    stuff in top-level description.
    Orit: extensions are easy. Therefore, have template in top-level; simple
    clients can ignore stuff it does not understand.

    For extensions: Is it better to have one object inherit from another, or
    have separate objects?

    No conclusion - will be taken to the list.

    Recurring Conferences
    Cullen: Time is this opaque thing the XCON client sends around, like, "I
    want a recurring conference on Tuesdays at 8am PST." It is up to the
    calendaring system to figure out time zones, etc.
    General consensus on the concept of shipping opaque iCal stuff.

    Roni: Who guarantees resources are reserved? Eric: that's an implementation
    / business issue.

    Henning: Make reservation, passing iCal object (with time range), which may
    be a series. Get back a "handle" (GRUU) that identifies series. Then one
    can query system to get a URI for referencing a specific instance.

    With that URI, one then can do conference-specific manipulation, like number
    of ports, etc.

    Will not extend, modify, fold, spindle, or mutilate iCal.

    Allison: be careful not to overstep bounds into iCal or ACAP territory.

    Discussion on "When the state (or the instance) begins - with the focus
    creation" statement. Agree, as on the mailing list, that if you can address
    it with a URI, and someone responds, it "exists". The converse is really a
    philosophical thing: if you cannot reference conference state (i.e., with a
    URI), then the state does not exist from a protocol point of view, even if
    the implementation does allocate resources, create state, etc. Implementers
    are free to do what they want, but we do not care from a protocol

    Cullen will become iCal expert (RFC2445 for those that care) and will tell
    us how to specify a particular instance / set of selected instances.

    Policy Rules
    Should be able to easily go through CPCP and pull out policy rules. Not
    really clear, but not good to do without Hisham's and Aki's input.

    How is a Conference Created?
    Lost idea of Conference Factory URI. Need it back, i.e., the place to send
    the conference creation / reservation request.

    Floor control: Template/document defines what a floor is, what it means to
    hold it, and what it does, especially with respect to media streams.


    Wednesday, January 5th, 1930 - 2230

    Mary presents on ....

    Discussion about if we do sipping event package work in xcon or not.

    Moved to framework document. Should there be one document that provides an
    overall view of what is going on in conferencing.

    Move so that we have to read two documents. One document that talks about
    the signaling framework and another (the xcon one) that talks about the xcon
    part of it.

    Keith: The sipping and xcon framework documents are peers

    AD: The sipping framework is not going to have anything about xcon in it.
    There are a few definitions of things like focus in sipping that are sip
    specific. xcon might define focus a little differently. XCON might want
    things like a loosely coupled vs. tightly coupled conference. XCON can say
    there is notification - but not get into detail about it because XCON is
    agnostic about signaling. Don't get into details of signaling protocols -
    assume they have reasonable things.

    Switch to Henning presenting ....
    - see his slides
    - add that a conference state but this can be active or latent
    - reservation has the connotation that something was reserved
    - looked at tree model

    What is the advantage of hierarchy. Provides more inheritance model: such as
    corporate policy, restrictions provided by device, and time.

    Question is if this needs to be exposes in the model. Answer is that if you
    edit an intermediate it has an effect on the children.

    Q. how do sidebars work? Henning: working on inheritance based idea - still
    needs work

    Introduce idea of BUS for a mixer .... Some discussion. Brian things this is
    probably not going to help too much.

    seemed to have agreement that .... When a conference is finished, it may go
    back to latent state before being purged at some later state.

    Back to Orit....
    - see her slides
    This is about changing the value of things in some object that has a name.
    Proposal would allow creation of new types of keys.

    Keith asked about why not xpath? Orit: Implantation complexity 2) can't pre
    validate the document 3) this one allows keys that logically identify
    something but not necessarily a xpath expression

    Henning: 80% of reinventing soap but with not of the benefits of something
    that exists.

    Henning example if you are editing "joining behavior" what would happen.
    Infinite number of error conditions.

    Can combine multiple requests and can they are atomic.

    Back to Henning .....
    - see his slide on Control Protocol
    - have get/set/add

    Brian - need to add list manipulation too

    Keith ask clarification on "transaction semantics". Henning: want each
    command to be a single change.

    Orit want to make the server not the client smart. Orit wants a full RPC

    Issues is semantic vs syntactic (ie. addUser vs. get/set) not SOAP vs
    something else

    Henning, Brian, I, agree - doing the semantic approach breaks any chance of
    doing user interfaces that client did not know about


    Thursday, January 6th, 0800 - 1000


    - Orit presenting 1 slide on CCCP Scope -- highlighting that CCCP works
    on all levels of conf life-cycle (Occurrence/Reservation/Template)
    - EB: raises concerns on mapping of CCCP to Henning's model
    - CJ: also concerned that the slide is going back on yesterday's
    discussion regarding new approach.
    - HS: Asked -- what are we going to model for a conference (at what level)
    - OL: re-iterate that she is presenting how CCCP maps to Henning's model.

    - AJ: Can CCCP manipulate conference state?
    - BR: do you need to map a rule to an object?
    - HS: in his model it inherits it -- unless there is a forced override
    at a higher level.
    - BR: Brian states that 'Rules limit exactly what can be done to the
    object' -- only permitted action is 'Allow'.
    - HS: reluctant if you need ACL for every variable -- seems excessive
    - CJ: thought there was one ACL that allowed a user to modify rules.
    - BR: Agrees with Henning.
    - HS: ACL to object controls privilege access to whole object hierarchy.
    Forced global would then control the hierarchy manipulation at the
    lower levels.
    - BR: Does not agree -- thinks it is simpler.


    - AJ: shows the room a slide on 'Rules' -- see separate slide.
    Emphasizes that we should not invent general rule syntax BUT should
    reuse common policy. Rule support in XCON will be optional.
    - BR: does not think that it fits.
    - CJ: Simple system that does not support rules -- would I be able to
    limit 'who is allowed to join?'
    - AJ: No -- simple conf system will not have identity based admissions
    (apart from at pass code level).
    - RE: Is policy a rule or a variable?
    - HS: use variable control through hierarchy and force global inheritance
    of change unless not required --
    - OL: and... if you would then like to allow some people to change it
    you add a complimentary rule.
    - BR: Asked question: How to you increase for a particular conference
    instance e.g. 50 to 100 ports in this model.
    - HS: You would create another upper layer branch and hook the conference
    instance to that leaf.
    - BR: so you would have to create that blob for every participant
    - HS: add more leaves to the tree to represent the change
    - BR: Does not agree and believes it should be rule based on the
    conference object
    - Various: It's an implementation choice rule based/inheritance based
    - BR: Advocating rule based mechanism
    - CJ: Wants clarification on ACL based model.

    - **CONCENSUS** The room agreed that an ACL per object (not on a per
    field basis) is required for the ability for manipulation.

    - OL: Question to Brian -- why are you against having both methods?
    - BR: Believes that every system implements rules -- not just advanced
    - EB: Loathed to defined the conference service (rules etc) - the
    IETF does not define service. Just provide the ability/tools to
    create/provide services.
    - BR: Implement any kind of limits of what users are allowed to do but
    the created object reflects the ability of the ranges. Ranges reflect
    what that user can do and should be accurate -- e.g. number of ports
    0-100 for a conference BUT if for one user, the range is 0-50 ports
    (has been altered from the base) and to the object MUST reflect.
    - Do we need to standardize ACL?
    - CJ: Yes BUT the thought is that we do not necessarily need protocol
    - OL: We need to consolidate data in a single schema -- Asks that if we
    have everything in an object (no syntax for rules), what would be the
    format for expressing it as a data object and not a rule?
    - EB: Confusion -- clarification of difference between policy and state
    is important (is Cullen in the conference (state) as apposed to is
    Cullen allowed in the conference (rule)).

    - **CONSENSUS** -- vote in the room on Henning's Hierarchical inheritance
    model to see if it is acceptable for progression. It was decided that
    it was not a sufficient time and not sufficient detail for such a vote
    at this time.

    - KD: Before we decide if rules are needed -- we need to define exactly
    what rules are -- then we can decide if a protocol is needed.
    - OL: we should not define the syntax for the rules
    - AR: why is this not just a pivot of common policy
    - OL: thinks it's different -- can be implemented in many different ways
    in different implementations.
    - HS: only one part of common policy as time/location based do not make
    sense. So it is just a subset. So if we are only using 10%, a simple
    list model would be easy to explain. E.g. how would sphere make sense?
    - CJ: This is simply a bunch of lists rather than a table. The properties
    are not variable and are fixed but they can be extended. Adding a
    new property is equivalent to setting up a new conference.


    Thursday, January 6th, 1030 - 1200

    10:30 - 12:00 XCON framework document

    Mary presented the XCON framework continuationfrom where we left on wed jan

    - The slides were modified (XCON framework slides)
    - Cullen - didnt we remove the Rules ??
    - can CPCP manipulate the state?

    - What are CPCP and CCCP functioanlity ? (Keith D)
    - CPCP is document editing system and CCCP is semantic based (Alan)
    - Rules and conference-info needs to be collapsed into one (merge).
    - We still have 2 protocols - CPCP and CCCP (Alan) -
    - Do we need 2 protocols CPCP and CCCP - Cullen?
    - Hening - we need to come with new names for these 2 protocols
    - we need to agree on what we call this protocols - Mary
    - Open issue is do we need a data manipulation protocol and semantic
    protocol - can we elimate CPCP (Cullen) ?
    - CPCP box has been changed to Data Manipulation in the slides - no
    consensus yet
    - Henning proposal - Conference Info is called conference object and a
    protocol to manipulate conference Object.

    - There was agreement on what we call the whole conference components -
    conference objects. Hennings tree nodes will be called conference

    - The type definition of the variable part of the conferece object is
    conference template.

    - The type defintion of the fixed part of the conference object is common
    conference information.

    - Registered conference Document is the schema which is registered with the

    - A new definition of focus -
    The focus is a call signaling endpoint that is addressed by a unique
    conference identifier. The focus maintains a call signaling

    - XCON client will be just called client - Cullens proposal is <protocol>

    - We dont want to define new data structures for time in XCON. We should use
    the iCal object to define the notion of time.

    - XCON wont define any ical extension - ical proposed as the required
    mechanism - The action point is we have to look more in detail how ical

    - For Policy - use ranges to control limit on values. Use list formats
    (described in previous minutes) to control membership and permissions.

    - Add text (in the framework document) in the framework document to discuss
    how is a conference created.

    - For floor control the text (in the framework document) should be
    consistent with the BFCP doc and security mechanism need to be addressed.

    - Way forward
    Next revision needs to be out before adopting as working group item.

    Henning Schulzrinne <hgs@cs.columbia.edu>
    Cullen Jennings <fluffy@cisco.com>
    Keith Lantz <klantz@cisco.com>
    Miguel Garcia <Miguel.An.Garcia@nokia.com>
    Asher Shiratzky <Ashers@radvision.com>
    Roni Evan <roni.even@polycom.co.il>
    Mary Barnes <mary.barnes@nortelnetworks.com>
    Orit Levin <oritl@microsoft.com>
    Eric Burger <eburger@brooktrout.com>
    Tim Melanchuk <timm@convedia.com>
    Chris Boulton <cboulton@ubiquity.net>
    Keith Drage <drage@lucent.com>
    Dave Morgan <Dave.Morgan@fmr.com>
    Haipeng Jin <haipengj@qualcomm.com>
    Allison Mankin <mankin@psg.com>
    Mark Zeren <MZeren@artisoft.com>
    Adam Roach <adam@nostrum.com>
    Alan Johnston <alan.johnston@mci.com>
    Umesh Chandra <Umesh.Chandra@nokia.com>
    Avshalom Houri <avshalom@il.ibm.com>
    Yaron Reinharts <yaronr@il.ibm.com>
    Brian Rosen <br@brianrosen.net>
    Martin Dolly <mdolly@att.com>


    XCON Framework Overview & Issues
    XCON architecture and protocol musings