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.