[AG-TECH] Idea for creating "observer only" venues

[Ivan R. Judson]

Good question Tom,

implicit in this discussion is that all you want to "control" is the media
streams. During a discussion about this topic for a real event it became
clear that the media streams are, in fact, only one part of the problem.
Shared Applications become suddenly something to be dealt with. Forwarding
streams from one group to another is effectively a solved problem, c.f.
rtpforward, quickbridge, reflector, et al. Solving the "I want participants
in the collaboration with limited permissions" -- which is what we really
want is what I was pointing out previously. Because what's the point of
hearing a talking head via the AG if you can't see the slides, or see the
demo, or know what the content they're pointing at is?

The problem seems to be deeper than just media streams, for the media
streams I'm happy with an authorization level solution using any of the
aforementioned technologies, until ssm and/or ipv6 become leverageable. Then
we get more creative options :-)

--Ivan 

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Tom Coffin
> Sent: Monday, October 25, 2004 7:06 AM
> To: ag-tech at mcs.anl.gov
> Subject: Re: [AG-TECH] Idea for creating "observer only" venues
> 
> 
> for passive viewing - why not just have a venue which starts 
> up a broadcasting application instead of rat?
> 
> active participants could use a venue with usual tools.
> 
> ____________________________________________
> At 04:54 PM 10/24/2004, Frank Sweetser wrote:
> >On Fri, Oct 22, 2004 at 08:20:36PM -0500, Ivan R. Judson wrote:
> > >
> > >
> > > Seems like just using some authorization facility would 
> be easier. 
> > > Just don't allow those participants to "write" to the venue.
> > >
> > > The authorization stuff that's in 2.X is admittedly 
> incomplete and 
> > > the SOAP latency makes it hard to use, but it's proven 
> itself when 
> > > it comes to the design and structure. In 3.X we'll have 
> to make sure 
> > > it's fast enough to be usable because with it you could 
> do what I'm 
> > > describing, which is what you really want. you don't 
> really want to 
> > > bridge venues this way, it's plumbing at the wrong level 
> of the system, IMHO.
> >
> >In principle I agree with you.  However, the problem I see 
> is handling 
> >the media streams.  If a person is allowed into a given 
> venue, there's 
> >currently no way to forcibly make their rat (for example) 
> recieve only, 
> >and completely disable the talk option.  Since the actual media data 
> >doesn't go through the venue server, there's really 
> currently no way to 
> >enforce read only vs read write with respect to video or audio.
> >
> >--
> >Frank Sweetser fs at wpi.edu
> >WPI Network Engineer
> >GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC
> 
> 
> 
> ___________________________________________________________
> Tom Coffin .......................... tcoffin at ncsa.uiuc.edu
> 
>