2.8.23 Centralized Conferencing (xcon)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-22


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-conference-scenarios-02.txt
  • draft-ietf-xcon-floor-control-req-02.txt
  • draft-ietf-xcon-cpcp-xcap-03.txt
  • draft-ietf-xcon-bfcp-2.txt
  • draft-ietf-xcon-conference-policy-privileges-01.txt
  • draft-ietf-xcon-cpcp-01.txt

    No Request For Comments

    Current Meeting Report

    XCON Day 1 11/8/04 1930 Lincoln East
    Eric Burger, Scribe

    Will WGLC Conference Scenarios
    Framework Document: First Draft
    Media Policy underway
    Conference Policy WGLC closed; ready for IESG
    Notification Event Package: not started yet
    Floor Control WGLC closed; ready for IESG
    CCCP document
    Need call flows
    Sidebars will end up incorporated in various documents

    Conferencing Framework Document (Mary Barnes)
    Should it reference SDP-NEW?
    Cullen: Confused SDPng with SDP-NEW (RFC2327bis). Recognized the error of his ways. SDP-NEW is OK.

    Would it be helpful to talk about the insides of the bridge (physical implementations)? Maybe.

    Referencing Data Model Slide:
    Roni: Is this the real data model? Having trouble understanding whether data lives in Focus, Conference Policy, or Conference State elements. Clients only see view from Focus.
    Thought is that only conference-aware participants care about distributed data elements, and they are aware of the different data elements, thus it might work as is. More discussion when we get to CCCP (or, "Back to the USSR").

    Hisham: Are we defining red data interfaces (on Basic Data model slide)?
    A: No. Only shown on slide to show relationships. Will not be doing protocols for exchange here.

    JDR: Does this deprecate SIPPING Conferencing Framework?
    A: Not intent

    JDR: But this does everything the SIPPING Conferencing Framework document does, including the stuff taken out to defer to XCON. Compares the concept to ICE: when we say X, which is Y in SIP. However, cannot see difference between SIPPING and XCON Conferencing Framework. Even the titles are confusing.
    Rohan: no problem having two WGs doing similar documents; different communities of interest
    Keith: not waiting on this document in 3GPP
    Mary: Goal is to have document that developers don't need to read SIPPING document
    JDR: vehemently disagrees
    Keith: sees split in the other direction: SIPPING document should reference XCON document

    Keith: charter isn't all conferencing; framework is only to develop those protocols that are necessary
    Orit: framework does not define protocols; SIPPING Conference Framework works for SIPPING conferencing framework

    Chairs: Do we need an XCON Framework Document? Consensus is we do.

    Resistance left room, so everything is OK :)

    Conferencing Data Model (Orit Levin)
    Entertaining animations of data flow :)
    Separating Policy from Actions
    Markus, Hisham, Aki, Henning: looks like good separation; better model: more control, better semantics
    Henning: 2 problems to address: description of a conference (may be partially filled-in) and templates; thinks of it as a master document that gets modified
    JDR: State gets manipulated via SIP, et al. However, Policy can also manipulate state. Moreover, changing Policy can trigger changes in state.
    JDR: Policy is something independent of State. E.g., Membership is state: if you apply Membership to a new clone, members are not members. E.g., Dial-out list is Policy; if you apply list to a new clone, need to dial-out. "Only Henning completely understands what he means by Policy" -- Orit
    Aki: likes to use terminology from virtual machines & operating systems.
    Adam says, "Send text to Orit."
    Things like Booting a member from a conference becomes easier. Right now, all we get is "Boot Member"; Cullen points out that could be "Boot Temporarily", "Boot from this conference", "Boot from all conferences", "Keep out forever". Current documents don't help here. This is a good approach.
    Henning: Concepts are good, but need better words to describe them.

    Chairs Discussion on Framework Changes
    1. Conference Policy has Two Parts: Split (Templates & Rules? Whatever we want to call them)
    Cullen: are we talking something new, or just "getting our act together"?
    JDR: This is the kind of stuff we need in framework document. How to carve up policy in a sane way. What gets modified by CPCP, mumble, and fratz. That belongs there.
    Orit: Chair slide looks a bit misleading (Change #1); concepts good.
    Hisham: Not really splitting Policy, but splitting stuff inside into two groups.
    A: Correct; just working on terminology.
    A: Do we agree on terminology? No real consensus yes or no.
    Cullen: Does this mean we would have to change all the existing documents?
    A: Yes
    Henning can take the terminology to the list. Aki, too.

    2. Media isn't a separate thing from State and Policy.
    Conference Policy is not separate from Media Policy.
    Weak consensus taken

    3. Conference State Manipulated Directly, not via Policy
    JDR: We should figure out what we want to accomplish before working on the solution.
    Markus: OK, so it is all document manipulation. Are we doing anything worthwhile, or are we just creating yet another way of doing state manipulation?
    A: Some semantics associated with states.
    Hisham & JDR: Need use cases. E.g., how do I get Focus to INVITE me, instead of me INVITING the conference? Take out "by manipulating Conference Package stuff" from proposal
    JDR: don't want to confuse commands with document editing. E.g., "Kick everyone out" is when executed. Document editing (kick out current participants) enables new participants to join, still.
    Orit: agrees
    Aki: Really want protocol with explicit actions.
    Henning: Need to be able to monitor entire state of conference. Every command has to make a visible change into the conference state representation.

    Consensus to go into this direction.

    Conference Policy (Hisham Khartabil)
    Postponed because out of time.


    FRIDAY, November 12, 2004, 0900-1130

    0900 - 0940 Floor Control - Gonzalo Camarillo (40 minutes)

    * Need to review and make sure section 3 is consistent with the conferencing framework - Alan will, others are welcome to comment
    * Open issues
    o How to perform authentication - Digest and TLS - what's mandatory? If you do basic, this is MUST use TLS, not may. Adding nonce to SDP is only to save one RTT. This affects IANA and security considerations. Current text is servers MUST implement TLS, clients SHOULD (or something equivalent). This should make the security types happy. Wouldn't the signaling protocol mechanisms suffice? What's the difference between authentication and conference admission? Can't use a shared secret for both, so need two mechanisms.
    o Clients initiate transactions, with no timeouts defined now. Define an application-level error recovery mechanism? Need to make sure we don't cause problems when trying to do more than TCP does - we won't define these mechanisms
    o Clients with several ongoing floor requests at once? We get this for free in the protocol, servers can reject them now if desired. What about requests based on media types?
    * To be done -IANA considerations, security considerations, SDP format for BFCP (in MMUSIC)
    * Need volunteers to review this draft - actually, the next version of the draft
    o Ben Cambell, Dave Morgan, Bob Hughes, Christer, ?
    * What about multiple floors with one media stream (sidebars, etc).


    * From SIPPING, needs to be discussed here.
    o Requirement for "richer information than BFCP" - we need to see use cases
    o Support UAs that don't implement BFCP - will all floor control protocols allow requests for information?
    o Information about the status of a floor - up to the server to decide when to send notifications, decide what information to include, etc. - event package would allow throttling if needed

    * Are these reasons compelling?
    o We just need to see use cases before barreling off.
    o Two mechanisms doesn't simplify things, because you have to implement both
    o Throttling is important - can we do this with floor control policy? Out of band?
    o I already have a SIP UA and know how to do SUBSCRIBE/NOTIFY - this draft adds like, one XML body for these UAs
    o Could probably implement a reference implementation today that meets these requirements using BFCP
    * Conclusion - we just need to see use cases, and will discuss in XCON, not SIPPING
    * We may end up with a parallel SIP-based mechanism anyway - TLS is not a SHOULD for SIP clients, but is for BFCP, and that's a big deal

    0940 - 1040 Media Policy - Alan Johnston (60 minutes)

    * Core draft has not been updated
    * Design team has been working on templates, not yet complete (4 of 10 are started)
    * Want to disband design team and continue discussion on the list
    * Need a good framework and terminology
    * Have a preliminary division of work, but won't make decisions until we look at framework and decide on terminology
    * XCON will likely have an Interim Meeting in January (watch the list for info on this, expect East Coast, 1.5 or 2 days)
    o Don't have AD approval to do a lot of work in an ad hoc and have work go forward without list discussion - process point
    o Not a proposal yet (either the design team proposal or the interim meeting proposal!)
    o Please discuss this on the list, that's the way we do things on the list
    o Allison would prefer that we work out document structure before working on terminology
    o Need a heads-up on the list that this is coming, people are commenting on the current drafts and we're thinking about big changes
    o This doesn't look like huge changes to the existing charter - no change at all, we're changing how we do the work
    * 3GPP is expecting floor control out of us
    o Could we get an e-mail on the list about exactly what they expect from us?
    o Floor control is at least one of the deliverables they need from us
    o Probably send to IESG after volunteer review
    o 3GPP likely to give us a list of document names, we need a list of document contents!
    o We also need to finalize conference event package - not in this working group - what does floor control without an event package mean? At least the event package is in WGLC in SIPPING now, so this should be OK.
    o Can we formulate conference rules quickly and not wait for terminology?
    o 3GPP also needs templates, etc.
    o We'll get clarifications and post them as quickly as possible
    o 3GPP will eventually need everything in the XCON charter, but probably don't need it all now - if we do this in usable stages, that should be good enough for them. Probably can't wait for everything to finish in order to finalize the rules.
    o We've had good experience with 3GPP use of our technology so far, and what they're asking for isn't unreasonable
    o Allison thinks they can give us functionalities again, since we're restructuring all our drafts. Keith and Stephen should be able to discuss this with us. We can have a teleconference (if you want to participate, please contact us and let us know).
    o Believe 3GPP will be flexible - give them the basics, chat and messaging applications would matter. Basic rules would be enough.


    XCON Framework Status, Issues and Plans
    Media Design Team Status