New version of report

[Ivan R. Judson]

Hi everyone,

I am working on a reply to the current concerns, but am currently
running exhibits at a conference here in Chicago, followed closely by
the birth of my son.  I will try to get something to you as soon as
possible; but it might be another 10 days or so.

A technical point that merits mention is AGNodes generate 1 audio stream
and 4 video streams, that makes voice switched video more difficult.
Second, the AG is designed for real continuous presence of all streams,
which is why there's a large format display. (this is to say your
comment is definitely fair). AG 2.0 addresses these concerns with
network services which allow the streams to be processed to provide
things like video stream selection, audio stream mixing, transcoding
8KHz to/from 16KHz, among others.  These specific services provide the
mechanisms to get the data formats to interoperate with H.323. However,
the call signalling is still a critical integration issue; this is why
the OpenMCU is useful. It allows the AG to interoperate in a very
seamless way with H.323 endpoints (polycoms, tandbergs, and yes even
netmeeting :-). 

I'm particularly interested in why the OpenMCU isn't the solution the
VRVS team would like to see.  Indeed, Philippe and I have exchanged some
email back at the beginning of September, but I don't recall there ever
being any conclusion about the right technical solution then, so I'm
wondering what's changed.  Also, if this isn't the right technical
solution, I'd like to hear what is and why. It's very hard to have a
conversation about this without all the bits and pieces of information.

I'm mostly concerned at what interoperability means; from the AG
perspective we think it means that each participant can interact with
the other participants with the richest collaboration provided by their
endpoint, be it vrvs, H.323, AG node, or laptop.

I'm sorry about the timing on these things. I'll be working on a more
coherent reply as soon as I can.

--Ivan

PS -- I'm not particularly attached to the recommendation in the report,
but I'd definitely like to avoid removing too many concrete
recommendations or the report will sound too fuzzy to actually have high
value; I think there should be a range of recommendations from very high
level to very concrete.

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: Alan J. Flavell [mailto:flavell at a5.ph.gla.ac.uk] 
> Sent: Wednesday, September 25, 2002 8:53 AM
> To: Michael Daw
> Cc: Sue Rogers; Phillippe Galvez; Peter Clarke; Kate 
> Caldwell; John Brooke; Ivan R. Judson; Henry Hughes; Stephen Booth
> Subject: Re: New version of report
> 
> 
> 
> A question that's come up in this further discussion relates 
> to item 2.5 , in which reference was made to OpenMCU and 
> OpenH323 as a "possible solution" for AG/H.323 interworking issues.
> 
> Is there someone who can speak to this particular 
> proposition, please? There is no mention of OpenMCU nor 
> Openh323 in the later chapters, so it looks as if this got 
> itself into the Recommendations chapter in the final drafting.
> 
> It may very well be that a UK contribution to OpenH323 would 
> be desirable - for some other reasons, but the VRVS team 
> evidently consider that it isn't a solution to the issue for 
> which chapter 2 is offering it, and their reasoning looks right to me.
> 
> The key issue at the moment is that the AG doesn't associate 
> particular audio streams with particular video windows, thus 
> making voice switching of video sources an impossibility.  
> However, H.323 normally expects video switching (even in 
> "continuous presence" mode, H.323 doesn't implement more than 
> a small-ish number of simultaneous windows, much fewer than 
> considered normal on AG - is that a fair comment?).
> 
> As I think we discussed already, it would be beneficial for 
> the AG itself if this lack of audio/video association could 
> be addressed, for example in terms of highlighting the active 
> window so as to call other sites' attention to it.  Once that 
> had been done (a development in the AG software itself, I 
> think), then at least the information needed to implement 
> video switching would be available in some form, and then one 
> could proceed to work out how to implement video switching for H.323.
> 
> 
> So my questions would be:
> 
> o can we take out the specific recommendation of OpenH323/MCU 
> as "possible solution" at this specific point, as it's looking (pardon
> me) to be technically unsound?  (unless someone can see the 
> flaw in this argument?)
> 
> o can someone offer a good supporting argument for putting UK 
> resources into OpenH323 so that the proposal doesn't go 
> missing entirely?
> 
> best regards
>