2.7.18 Centralized Conferencing (xcon)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Adam Roach <adam@dynamicsoft.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://www1.ietf.org/mail-archive/working-groups/xcon/current/
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
  • - draft-ietf-xcon-cpcp-reqs-02.txt
  • - draft-ietf-xcon-conference-scenarios-00.txt
  • - draft-ietf-xcon-floor-control-req-00.txt
  • No Request For Comments

    Current Meeting Report

    The following drafts were discussed:
    draft-ietf-xcon-conference-scenarios-00.txt - Chairs
      Presented by working group chairs for Nermeen Ismail and Roni Even. Plan to 
    submit 01 version for WG last call.
    draft-ietf-xcon-floor-control-req-00.txt - Joerg Ott
      Includes some proposed policies that the authors aren't certain about. 
    Would like others to comment.
      Cullen Jennings suggested that it is impossible to know with 
    certainty who a participant is, and this provides a different way of 
    looking at privacy requirements.
      Brian Rosen voiced a requirement for the ability for a floor holder to 
    pass the floor - different from automated floor control.
      Dave Lindbergh commented this is focused on parlimentary model. Wanted to 
    know if pannel discussion or roundtable is supported. Joerg Ott said this is 
    was possible, depending on floor policy.
      Keith Drage requested a better abstract before going to WGLC. Also, said 
    there may be need to add floor policy to conference framework. Wants 
    clarity on whether floor policy is to be covered by this doc or the 
    conference policy requirements.
      The chairs said plan is for WGLC within the next 2-3 weeks.
    - draft-ietf-xcon-cpcp-reqs-02.txt - Hisham  Khartabil
      Update of additions/removals. Rohan stated it seemed CPCP is intended for 
    humans, but he thought this will only be used by automata. He doesn't 
    think he is being understood. He said it should be possible to mark an 
    entity that should be hidden, but there may not need to be any  complex 
    policy to control this. This is for things that would be annoying to see, 
    such as automata like recorders. This policy would affect conference 
    policy notifications.
      Eric Burger thought that would be useful *if* those special kinds of 
    roles are implemented by regular participants - but that is not the only way 
    to implement those functions. Roni Even thought this might be a media 
    policy. But Rohan didn't.
      Dave Lindbergh thinks there are different kinds of conferences. For some 
    hidden participants are fine, for others not. It may be important for 
    security to know if there are hidden participants.
      * There was no concensus. Further discussion to the list.
      There was extensive discussion on the definition of start time and 
    end-time. Cullen Jennins argued that the time the first participant 
    arrives cannot be the start time, because the start time is inserted in 
    policy a priori. Eric disagreed. There seemed to be lack of 
    understanding between them.
      Rohan Mahy said there are four parameters, not two: 
    cannot-start-before, cannot-continue-after, start-policy, 
      Roni Even said this has nothing to do with resource reservation. Eric 
    Burger said this is definitely tied to resource reservation, or else there is 
    no point. Cullen thought reservations are way out of scope.
      He said that the following are both important numbers: when mixing can 
    begin, when dialouts happen. Suggests not calling it start-time.
      * Some concensus for: don't-mix-before-time, dialout-time.
      Also need policy to say mixing won't happen until key participant 
    arrives. Someone also brought up case the dialout doesn't happen until a key 
    participant arrives.
      * Cullen and Rohan were asked to send text. (Roni Evan points out that 
    dial-out might not happen until a key participant arrives, so the policy 
    needs to account for such a case).
      Discusson on conference ends policy. Outcome was conclusion this is tied to 
    key participants via some sort of policy.
      Keith Drage requested clarification on where media policy will be 
    defined, because this document currently doesn't. Roni Even said this in 
    intended to be done in a separate document even though it may be 
    realized by same protocol. Keith felt this needs to be clarified because the 
    conf framework says that cpcp will include media policy.
      Brian Rosen said there is a need to define Role. More work needed here - 
    role is mentioned but not really defined. This relates to anonymity: one 
    might not expose identity, but they might want to expose roles.
      * The document will be revised based on the open issues discussed 
    above, and then enter a last-call period.
    draft-koskelainen-xcon-xcap-cpcp-usage-02.txt - Hisham  Khartabil
      Alan Johnston asked if others felt it was ok to have multiple 
    conference URIs for one conference, or whether it would be better to have 
    only one plus aliases. Alan thought framework said should be only one. 
    Somebody said intent was not to be sip-biased. Hisham didn't think that we 
    need a single URI for identification; that there can be several 
    different URIs that identify the conference equally.  Brian Rosen said 
    these should all be requested aliases while the true uri would be 
    assigned and must be a gruu (and consequently not specified in the 
    policy). Cullen Jennngs thought that like IM, we may need a special uri 
    scheme that isn't bound to any of the protocols.
      Rohan Mahy said that typically there is an address (e.g. phone number) of a 
    server plus an access code to enter the conference. In that case that 
    isn't a conference uri, but something else. Brian things there may be need 
    for extension to carry this address used for conference access.
      Alan indicated that clarification might be necessary about what it would 
    mean to have several SIP URIs identifying the same conference.
      There was a long discussion of the suitability of xcap as a 
    mechanism for cpcp, what http methods are most suitable for xcap, and 
    whose problem it is if xcap is/isn't appropriate for the job.
      Orit Levin proposed splitting the document in two. Keep xml document 
    separate from the protocol. Aki thought splitting schema from protocol is a 
    bad idea. Brian Rosen didn't want majority of work held up based on 
    disagreement over protocol issues. Rohan said work is supposed to apply to 
    multiple communities, but sipping community wants to use xcap and we 
    shouldn't make it hard to do. He suggested not splitting document, but 
    partitioning it so that there is a separate section on application to 
    xcap. Orit didn't want to encourage "vandals" to implement this using 
    other protocols. She would still prefer to split the document. Jonathan 
    said it is normal case that there is a 
    mandatory-to-implement protocol to ensure interop, without precluding 
    other protocols. Keith Drage said if there are multiple equal 
    protocols you should split the document, but if one is special then it 
    ought to be in the document. Aki is ok with restructuring the doc, but 
    wonders why - he hasn't seen any other transport being proposed. Lisa was in 
    favor of splitting because will need something else for xmpp to use this.
      * The chairs attempted to summarize: some sort of cencensus about 
    restructions/splitting the document so as to have xcap being *a* way to 
    manipulate the document.
      * Alison asked about need for stronger statement regarding role of xcap 
    before the next meeting. Wants a statement about it in the 
    deliverables, that there will be an xcap transport based proposed 
      * Took hum of people wanting to take forward work using an xcap usage for 
    conference control. Hum was positive.
      * Agreed to take as WG item if document is suitably reorganized. No 
    agreement whether that will require a split.
    - draft-burger-xcon-mmodels-00.txt - Eric Burger
      Presented in "lecture mode" with questions postponed in order to save 
    time. He enumerated three media manipulation models: low level device 
    control, application level device control, dynamic device control, and he 
    listed pros and cons of each.
      Rohan says this is fear mongering - that low level device control graph 
    model doesn't have the problems asserted. Says H.248 is much worse than the 
    graph model. He said that Eric hasn't demonstrated that his proposal meets 
    the scenarios.
    draft-jennings-xcon-media-control-00.txt - Cullen Jennings
      This presented an alternative approach to media control, based on 
    templates. Alan Johnston said he liked this approach. Roni Even thought 
    model was good, but remains to be seen how many templates are needed. But he 
    is concerned whether complex cases can be handled. Brian Rosen 
    responded that the issue is whether a small number of templates can 
    handle a large number of the cases. If a small number don't cover 
    *enough* of the cases then this isn't a good approach. Need to do work to 
    verify this.
      Rohan doesn't think we have enough info to move forward. Thinks Eric's 
    draft doesn't have enough content. Cullen thinks there is enough so 
    people can see how they would build templates for particular cases, but 
    Rohan disagreed - said it will break down for hard cases, that there is a 
    big problem naming things.
      The chairs took several hums to determine the way forward with this 
    work. Four options were offered:
      - flow graph approach: nobody
      - template approach: several
      - both are incorrect: a few
      - don't have enough info - wait: many
      * Consensus determined to be that we should attempt to understand the 
    issues better before making a decision.


    Requirements for Floor Control Protocol
    Centralized Conferencing Media Control Models
    Parametric Templates