Last Modified: 2004-06-14
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|
Work Group: XCON
Time: 9:00 - 11:30am
Scribe: Paul Kyzivat
- Workgroup Status - Alan Johnston
Discussion of whether to split CPCP into two docs. Hisham Khartabil expressed opinion that this split is unnecessary.
A proposal was made to split the conference package responsibilities - roster in SIPPING, media and policy moved to XCON. This will permit wrapping up conference work in SIPPING. Jonathan Rosenberg raised concern that this be done carefully or there may be risk that the framework doesn't work fully. But he wasn't opposed to the split. Cullen Jennings thought it might be premature to finish the framework until the XCON work is further along. Some skepticism by others. There will be more discussion on this subject later.
- Updates to the SIP Conferencing Package
(draft-ietf-sipping-conference-package-05) Orit Levin
Orit explained that she had made at media level as a strawhorse - she isn't confident in them yet and requested feedback.
An issue raised by Jonathan Lennox that there is no way to remove a sidebar in a partial notify. Orit said there is intended to be, and agreed to investigate.
Jonathan raised issue of whether sidebar should be defined in SIPPING or in XCON. It is currently unclear whether sidebars are a special type of conference or just a mixing policy. This might suggest delaying the completion of the SIPPING work until XCON is more advanced.
Orit explained the newly added element of user-type, called user-status-type. Cullen Jennings objected - claiming this is really a session level info, not user level. Orit thought it would be up to focus to figure out how to set this if there are multiple sessions for a user. Jonathan thought two sessions could be represented as two users. Roni Even seemed to agree with Jonathan. Cullen prefered users to have (potentially multiple) sessions which in turn have media streams. Jonathan thought this may be an artifact of non-uniqueness of the uri, and explained a way to treat those as separate users.
Alan Johnston asked for the SIPPING conference design team to get together this week and thrash out this issue.
(draft-rosen-xcon-conf-sidebars-01) Alan Johnston
Rohan Mahy said this document doesn't address case where user with single audio/video session wants audio in a sidebar but video to remain in the main conference. Alan thought it is possible, via CPCP but not SIP. He also thought this needs to work even when SIP isn't used - where there is only PSTN plus CPCP over HTTP. He wanted more examples of that. Alan agreed that this doc is SIP specific and perhaps doesn't need to be.
Eric Burger wasn't happy with this direction - he thought it was just recreating H.245. He thought sidebars should be separate conferences, that you establish a new dialog to, that just happen to have media from the main conference. Rohan disagreed - claiming this has no advantages and imposes extra requirements on endpoints, while Eric thought this didn't require any uncommon behavior. Eric was requested to send text. Dave Oran asked if/how it is possible to have different keying for media in sidebar vs not - that this should be possible and may help determine the proper architecture.
Brian Rosen asked (via IM) *why* you would want separate keying for a sidebar. Dave asserted the user expectation is for extra privacy in a sidebar. Rohan thought this is possible, but out of scope. But Alan and Dave felt this is in scope - that only multicast keying is out of scope. Alan agreed that expectations are there and should be met somehow.
- Media Policy
(draft-jennings-xcon-media-control-01) Cullen Jennings
This was a status update by the design team. The team has investigated both Rohan's flow graph approach and the Jennings/Rosen template approach. They ecided to keep both approaches. They are currently working on a set of example templates, but aren't done yet, and request permission to continue work for another round.
Dave Oran asked why an inheritance model is used for roles, vs a flat model - asserting that an inheritance model is more complex. Cullen agreed to investigate.
- Conference Policy Control Protocol (CPCP)
(draft-ietf-xcon-cpcp-xcap-01) Hisham Khartabil
Hisham raised some issues in tying this work into the conferencing framework. Jonathan asserted this is a non-issue - that the framework can and should change to accomodate this work. Hisham agreed to send text for revising the framework.
There was an extended discussion of identity and the role of pins and passwords in it. The policy syntax has list of conditions including <pin> and <password>. Cullen argued that <pin> and <password> should simply be alternative ways of authenticating, not a separate mechanism. Dave Oran didn't see clear distinction between what identity for authentication and identity displayed for the user. Rohan was concerned about what happens if someone admitted based on identity and pw, and then the rules are changed to remove or change the pw check. Is the user bumped then?
Cullen thought the pin/pw stuff raises many issues that must be resolved. There was considerable further discussion on this subject, evidencing confusion about the semantics.
Open Issues - problem interpretting the <id> element. Do we need to say more about interpreting <id> elements? Needs to tie to specific signaling protocols -- SIP and H.323? SIP and XMPP? Anything we have text for? There was a proposal to do for SIP, and allowing fill in for others.
A question was raised whether a way is needed to permit subscription to conference state while restricting what can be received. Cullen asserted this can't be decided until we know what the conference state includes. There was also a question about the need for polite blocking. There were some comments that this is not needed, but no humm was taken.
There were similar question about floor control events, and conference info events. Hisham proposed to leave as is unless someone complains.
There was discussion of the newly proposed REFER list. After discussion it seemed people would probably agree if the intended usage was better explained.
An issue was raised regarding media stream security policy - how to specify specific means of security without becoming media dependent. A proposal was made to simply specify that media must be secure and leave it to the focus to decide how. Some discussion of whether this is conference or media policy, or both. There was no clear decision on this point.
[End of Session]
Part 2 Minutes - IETF60
Authenticating a user -- is this really useful? We have the necessary tools in conditions. This will be removed in the next draft.
Meta Policy -- many conditions are defined -- should there be a separate document? Simplifies conference policy document, but many conditions would be repeated in both documents. Should there be separate actions defining read access?
<time> vs <validity> - these are separate things -- is it OK if a rule is only valid for part of a conference lifetime?
Providing anonymity -- should there be rules allowing specific users to be anonymous?
Is there a difference between <anonymous> and <pseudonym>? Do we need both? The focus can generate an anonymous attribute on behalf of the user, and other users will know that an anonymous user is present. We're providing pseudonym-ity anyway -- true anonymity is hard to provide, because someone (ISP, focus, etc.) knows the identity in order to connect the user to the conference at all.
External lists -- what does it mean for an <id> element to carry an XCAP URI? Should the use of external lists be more explicit (<external> element or "external" attribute)?
Unauthenticated Identities -- do we need to list users that need to be authenticated? "anyone who claims to be firstname.lastname@example.org can join the conference." But this isn't needed to identify people who come through gateways (PIN codes, etc. would work). Why do we want to have policies controlling unauthenticated identities at all? Why would we limit the number of unauthenticated participants who all claim to be an allowed participant in the conference? Authorization without authentication is just silly. Does policy matter for inactive (listen-only) participants?
Floor-id uses floor URI -- needs to reflect current floor control protocol.
1030 - 1130 Binary Floor Control Protocol (BFCP)
Gonzalo Camarillo (60 minutes) draft-ietf-xcon-bfcp-00.txt
This revision adds context text, supports third-party floor control, has clarifications, and incorporates comments from the mailing list.
Replay protection -- implement in protocol, or continue to rely on TLS? We implemented integrity in the protocol -- should we rely on TLS for both replay protection and integrity? Security antennae will quiver if we do only one... we will do both, or neither.
Do we need more than a simple flag for privacy (it's all or nothing now) -- disclose identity to chairs, but not to others? - Why is this request-by-request? Rohan asked for this in the interim meeting, but there's already a loose coupling between identities and floor requests. But this mechanism doesn't help speakers be anonymous -- the next speaker is probably the one who requested the floor, anyway. This is feature creep in a small protocol. How can you identify a user at all? There is text in the draft in how to do this correlation. If a user requests the floor anonymously and then performs an action that is visible, there's no meaningful anonymity anyway. If you want to be anonymous, be anonymous all the time. This is complexity and not needed. Is this forward secrecy, or "we'll never know who that was"? There are privacy issues lurking somewhere in here, especially if people can see requests (when not using TLS). If you're speaking in a voice call, you're giving up your anonymity on your own, and we need to make sure we're not putting a legal onus on a chair to preserve your anonymity.
Can a server add mandatory TLVs? We would need a capability negotiation mechanism, or a way for clients to complain about unknown TLVs.
Does CPCP allow users to authorize 3rd party floor requests?
Can we use the BFCP fixed header with non-TLV payload types (XML notifications, etc.)? This is too much feature creep for a very simple protocol -- we should be removing features, not adding this one.
Can users modify ongoing floor requests? Do we need this feature? Nope.
Is BFCP a transport or a payload type in SDP? Payload type would require MIME registration. Is there a working group where someone might care? Gonzalo will present this in AVT. Is this control, or application? It's application, and the applications guys recommended that we not start a new top-level registry.
Floor-stream mapping for non-CPCP clients? Label the media streams? Add floor-ids to all the SDP m-lines? Or do something else? Will be synchronized with the media policy team.
CPCP over MSRP -- Tim Melanchuk
Some discussion of non-XCAP protocol for CPCP, providing message transport and the messages themselves. These could be XML over TCP + TLS, leveraging SIP session establishments. MSRP is defined for instant messages but could be used in other contexts.
Many details to work through -- is there a need in XCON?
If you were using XCAP for this, you could use a URI to refer to policy pieces -- how would you do this using MSRP? Let's not tunnel XCAP over MSRP, okay?
Why reuse SIP session establishment? Offer/answer, same SIP URIs as rest of application.
Like this idea, has been proposed for video applications in the past, but may not be right here. Why is notion of a session needed? This is a transactional problem. SIP is really good at rendezvous problem, but that's not what we're doing here, either.
Is this a general RPC mechanism? I vote "no".
We need to start from requirements and not just have ideas. What is the problem this proposal solves?
Reusing SIP session establishment really is valuable, and "MPC" looks a lot more like a session than this example.
Support this approach, because this is a better RPC mechanism than XCAP.
No, if you want RPC, do SOAP!
XCAP was chosen as one way, among other ways, to transport CPCP. It's not the One True Way.
Keep on working on this idea -- the more, the merrier.