Centralized Conferencing BOF July 15, 2003 ----------------------------- Chairs: Adam Roach, Alan Johnston Secretary: Dean Willis Meeting called to order at 1700 BOF Scope and Mission, Chairs ----------------------------- Slides presented. Mission and related documents discussed in slides. Point from floor on terms : A "Focus" is a logical instance per conference, not a server or other physical element. Question on Media Policy: Would it be fair to say that the policy is independent of the actual mixing? Ans: In general yes. Question on Media Policy: What level of detail do we anticipate in the media policy? Further discussion of media policy follows. Ans: Dealing with codec inssues will be part of media policy. The drafts go into detail about how streams are combined, like mono and stereo. It is still an open issue as to whether this level of detail is required in the work, and we will talk about it as the group works. Question on Floor Control: A metaquestion. It is unclear since some of these things have requirements documents, others have solutions documents. Ans. In this case, there is an XML-Soap document we didn't reference because it is a complete standalone, but could be suitably adapted. Question on floor control: Wilol be consider wireless requirements, like small messages? Ans. Probably. Example use scenario from slides discussed. Point: Suggest that finding out what the conference is is not media policy, but conference policy. Discussion followed on whether these are two different data elements. There appears to be little solid consensus on this. Eric Burger volunteered to send text that would try and clarify the terminology. Discussion continued. Example topologies presented in slides. Question: How are you going to diferentiate between cascaded conference and fully distributed conference? Discussion followed. NO conclusion. Request from AD: Focus on charter instead of solutions and terminology. Slides review relationships with other groups. Proposed Charter deliverables reviewd. Comment: We would not develop a new protocol for mechanism for change notification -- would reuse. Discussion on "layout" or "topology" terms -- is this really a discussion of roles, or a graphical layout thing like HTML rendering? Is role-mapping notification? Bullet #2 (layout) is a classic control protocol. It might be described as markup language, it is about how users perceive -- not rendered but consumed. The current document is sortof like that. It is not yet clear that this is the right direction. Another comment on #2: It would be presumptuous to say that we don't do conferencing layout will and W3C does. They've had 4 years and haven't started. We need to develop our requirements, and if necessary liase. Answer: We will send this charter out to other standards bodies and see if they have comments. Question: Can you describe to what degree the deliverables of this WG will include multicast? Deferred to deliverables slide. Comment: Conference and media control as we have in mind are nicely realted and must be addressed together, they are very tightly related and if we do not address them together we fail. (ed: Comment continued for a long time, much of it not captured here). Non-Deliverables discussed Comment: Suggested that exclusion of multicast for security concerns is innapropriate, that multicast can be done securely. Answer: The non deliverable is for the security concerns wrt multicast, not multicast itself. Debate followed. Ans: There seems to be some consensus to redo the charter to allow multicast security concerns to be addressed later by addition as explicit charter goals. Further comment: Perhaps we could factor the problem by declaring key management for multcast out of scope. Therefore, we would not presume, in our work, any specific key management regimen. This especially applies to mixed uni/multi conferences. Comment: It's good to narrow focus and multicast is hard. But multicast also has iteraction with media policy, and we should solve unicast first. Counterarguments continue. Question from enterprise/consumer point of view. Concerned that some of the non-deliverables. Important that we define a complete system, including mixers (currently out-of-scope), master-slave cascading, and far-end device control. Ans: In terms of mixers, one can use many things like H.248, etc.. Counter: We need to standardize for compatibility. Question: Very unpleasant to accept that centralized conferencing implies unicast. Would like to see conference as a group communications, perhaps with hundreds of members. Restricting this to unicast is unnatrual. We should assume multicast from the start, although we might consider a shim layer to emulate multicast using unicast. Question: Interested in overlap between this and what SIP would normally do. There seems to be some overlap here. Restatement: Do you intend SIP to do media signaling, or just invitation/negotiation. Ans: If a change in media policy adds another stream, that gets negotiated using SIP. SIP is used as the signaling policy between focus and participants to do media negotiation. It may also be used for notification of events. Comment: SHOW THE CHARTER! Comment: we will keep distributed model in mind here, but not address it. Discussion of scope: SIP affects only the user-to-focus relationship. Comment: Having worked on distributed and multicast conferencing, this appears to be a good and useful project. It's academically boring, which means it can be built by engineers. Comment: Outbound call-list notification appears to be just a list of names of who is on the conference. Comment: Unclear from charter what multimedia signaling protocol will be used. That's because the charter says "any". Poll on sense of the room as to whether charter should be taken forward. Strong consensus with only a few objectors noted.