Last Modified: 2004-01-22
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.
|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|
XCON IETF-59 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, end-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 standard. * 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.