[AG-TECH] AG 2.0 and VRVS vic and rat and other ramblings

Douglas Baggett dbaggett at cise-nsf.gov
Thu Oct 21 14:37:03 CDT 2004


Thanks for the good description! Of course I don't want you to get the 
wrong idea from my post. I think the direction of the middleware 
framework is the correct direction and it seems to be coming along. As a 
grid operator I look at what is used every day. We all know that 
video/audio conferencing is THE major application that is being used. 
 From the grid operator's perspective of trying to satisfy users with a 
better system, the video and audio are THE most important application. I 
understand completely that the audio and video are not the thrust of the 
work being done, the middleware portion is.

Please correct me but it seems what you are saying in your post is that 
the framework when completed should provide a consistent interface where 
compatible video/audio applications could be plugged in AND assuming 
everybody in a particular meeting is using compatible software we would 
be able to take advantage of the development that's being done in video 
and audio.

I stand corrected on the open source issue. I thought VRVS was open 
source (which means I suppose that vic and rat must be under some sort 
of license that is similar to the BSD license possibly?).

It looks like we have some smart people in related projects of lesser 
scope (VRVS, OpenMash, ect...) that are concentrating on the particular 
application of video and audio. It's seems to me to only make sense to 
work with those folks in improving the video/audio aspect of the AG that 
is not nessessarily being developed by the core AG team so that we can 
use them with the middleware ( I don't want to belittle ANYTHING that 
people like Bob Olson, yourself and others have done to fix vic and rat 
and add features where nessessary). :)

I also don't want to imply that there isn't any talk between AG and the 
other communities. It's just as a node operator I don't see much 
movement with audio/video. It's been almost 3 years since I set up our 
node and Vic and Rat work almost exactly the same as it did back in 
2001. There have been some great fixes...many thanks for that (Really!)

What led me to ask the first question was how well the VRVS version of 
Vic worked and the fact that they were working on adding MPEG4 and HDTV. 
And of course the fact that InSors also added support for H.264 (but 
only between InSors clients). I'm sure we (the node community) would 
love to see these improvements, but the question is how to get the 
development process going so we can see the features developed/deployed 
in a way that everybody can take advantage of them. Especially in a way 
that can take advantage of the AG 2.x framework in the way you've 

Do you think that once the middleware portion is complete and robust 
that we will see the community dump vic and rat for something better? 
(like some of the software you mentioned?) Should the community talk 
about what we should move to when the middleware is ready for it so 
there is some common video denominator during meetings?

-Doug B

Ivan R. Judson wrote:

>Hi Doug,
>I think it's important to understand the layering of the software in the
>overall architecture and then to understand where each project fits into
>that layering.
>The bottom layer is the streaming media, and almost all large scale systems
>are using RTP/RTCP now for that. Including vrvs, sip, h323 and the AG.
>Above that you can label the layer, session coordination. This is where
>H.245, SIP and the AG differ. They each have a different solution to the
>problem, SIP is the forthcoming replacement for H.323's H.245 signalling
>protocol. SIP is a nice ietf standards based solution that's an open
>protocol (unlike H.323 - you have to buy the spec). Rumour is that VRVS is
>closely related to SIP, if so, the question is why have 3 solutions doing
>*exactly* the same thing?
>The AG is taking a completely different approach by leveraging the Web
>Services technology for this, WSDL/SOAP. This allows us to seemlessly
>integrate things like Grid Services into our collaboration system, you just
>can't get that with the SIP/H.323/VRVS solution. Closely related to this
>observation is the fact that as far as I can tell, we're the only ones
>building a "collaboration platform/framework", the other solutions are
>either commercial products (H323/SIP), or research turned production (VRVS).
>One significant and often overlooked point is that the AG is the only Open
>System in your list. The others are all closed to the end-user and
>Media tool work is big and hairy problem and the AG effort is currently not
>supported to do it. We'd be happy to get support to do some media tool
>development, but there are better solutions available than continuing to use
>ancient media tools. 
>A nice set of platform enhanced tools for each of the major platforms (OS X,
>Windows, Linux) would be a big benefit, and if built upon the same
>underlying infrastrcture (use RTP, use it right) the tools can interoperate.
>The advantate to this would be I could use Microsoft's msvideo codec or
>Apples H.264 when it comes out. You know they are going to make it faster
>than an opensource version. The only gotcha is that then you have to have
>either one least common denominator among all platforms, or a solution to
>transcode on the fly, otherwise the community fragments around platforms.
>One key effort that is important to note is that the inSORS solution was
>derived from the AG1.x software, but has been tracking (via plug-ins) the
>AG2.x software. Although there has been divergence to a small degree, we're
>working with inSORS to re-converge in our 3.X software so that we're
>interoperable at the basic level (text, audio, video).
>I don't believe we're going to see the AG community fracture, both the
>research and commercial participants in the community understand the value
>of a cohesive AG community. But I do think the differences between the AG
>and the other systems you've listed are going to become very evident in the
>next twelve months.
>>-----Original Message-----
>>From: owner-ag-tech at mcs.anl.gov 
>>[mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Douglas Baggett
>>Sent: Thursday, October 21, 2004 12:02 PM
>>To: ag-tech at mcs.anl.gov
>>Cc: Thompson, Kevin L.; jkoss at nsf.gov; dgatchel at nsf.gov
>>Subject: [AG-TECH] AG 2.0 and VRVS vic and rat and other ramblings
>>I've been evaluating which software to use for my desktop 
>>users and have been quite impressed with the work the VRVS 
>>people have done with vic/rat and software installation and 
>>ease of use. My question has to do with the differences and 
>>advantages/disadvantages with going with VRVS for desktop use 
>>to access grid meetings vs standard AG 2.x  vs Insors (any 
>>suggestions or experiences greatly appreciated!). Also, have 
>>there been any discussions with the VRVS folks about the 
>>changes they've made to vic and rat and possibly taking 
>>advantage of their work (and of course helping them as well 
>>in the opposite direction) to improve the version of vic and 
>>rat used in AG? Just a cursory search of the mailing list 
>>reveals some other vic forks (other than VRVS) as well to add 
>>MPEG4 and other stuff (OpenMash and others). 
>>The added fact that InSors develops their own video software 
>>seems like we are headed down a road where the least common 
>>denominator will start to influence what kind of advanced 
>>video features are available. It looks like MANY people want 
>>the same set of features (MPEG4, H.264, possibly HDTV....) 
>>but people are going down their own road, which leads to 
>>incompatible versions of vic using higher quality codecs and 
>>Thanks for all the great work! 
>>Douglas Baggett
>>CISE IT Support
>>National Science Foundation      
>>M-F 8-4pm EST                     

Douglas Baggett
CISE IT Support
National Science Foundation     
M-F 8-4pm EST                    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20041021/1ea339af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3186 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20041021/1ea339af/attachment.bin>

More information about the ag-tech mailing list