[AG-TECH] RE: [AG-DEV] Bridge Information

[Michael Daw]

Good, out of the box thinking. (Time to come out of the closet too, Ivan - you're amongst friends...!)

I'm interested in hearing insors' response.

> -----Original Message-----
> From: Ivan R. Judson [mailto:judson at mcs.anl.gov] 
> Sent: 08 March 2006 16:27
> To: 'michael.daw at manchester.ac.uk'; 
> 'Andrew.Rowley at manchester.ac.uk'; 'AG-TECH mailing list'
> Cc: 'ag-dev at mcs.anl.gov'
> Subject: RE: [AG-TECH] RE: [AG-DEV] Bridge Information
> 
> 
> I quite agree with you, however, I think this is a great opportunity.
> 
> AGTk/inSORS interop is a sticky problem, and interoperability 
> at the media
> level is only part of the answer. Interop needs to be addressed
> top-to-bottom so that people can actually work together seamlessly.
> 
> Your (the escience folks) help in making this statement to 
> inSORS (you are
> customers and customers rule the commercial world), would go 
> a long way to
> showing there's 1) need, and 2) desire for a *good* solution 
> to interop.
> 
> Fixing this at the media level gives them an excuse to avoid 
> doing the right
> thing, not a reason to support the broader community. (the 
> business case
> behind this seems obvious to me but perhaps hasn't been made 
> clearly -- the
> more they (inSORS) interop, the more customers they have open 
> to them who
> will willingly switch from AGTk to inSORS).
> 
> Since obviously we are working with inSORS, I know this stuff has and
> continues to be discussed. The critical missing driver is 
> what I'm asking
> for, customers to request the features (in this case top to 
> bottom interop),
> including text, audio, video, venue servers (AG client to 
> insors venues, and
> vice versa), etc. Then features can roll out in either system 
> and market
> forces and competition will drive the acceleration :-).
> 
> --Ivan, your closet MBA
> 
> > -----Original Message-----
> > From: Michael Daw [mailto:michael.daw at manchester.ac.uk]
> > Sent: Wednesday, March 08, 2006 9:18 AM
> > To: Ivan R. Judson; Andrew.Rowley at manchester.ac.uk; AG-TECH 
> mailing list
> > Cc: ag-dev at mcs.anl.gov
> > Subject: RE: [AG-TECH] RE: [AG-DEV] Bridge Information
> >
> > But we need to retain interoperability between insors and AG toolkit
> > clients, hence hitting this at the level of media rather than venue
> > client.
> >
> > > -----Original Message-----
> > > From: owner-ag-tech at mcs.anl.gov
> > > [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Ivan R. Judson
> > > Sent: 08 March 2006 15:15
> > > To: Andrew.Rowley at manchester.ac.uk; 'AG-TECH mailing list'
> > > Cc: ag-dev at mcs.anl.gov
> > > Subject: [AG-TECH] RE: [AG-DEV] Bridge Information
> > >
> > >
> > > Touching a bunch of packets (filtering for the SDES Name 
> packet and
> > > modifying it) seems extremely intensive to meet the end goal.
> > >
> > > Are you trying to determine if the local client is bridged or
> > > if any of the
> > > remote clients are bridged?
> > >
> > > Seems like it's a bit of information the venueclient already
> > > has and should
> > > be able to simply show the user on the local end. It might be
> > > something
> > > simple like updating something in the venue to share that so
> > > you can see the
> > > state of all non-local clients.
> > >
> > > Does that make sense?
> > >
> > > -Ivan
> > >
> > > > -----Original Message-----
> > > > From: owner-ag-dev at mcs.anl.gov
> > > [mailto:owner-ag-dev at mcs.anl.gov] On Behalf
> > > > Of Andrew A Rowley
> > > > Sent: Wednesday, March 08, 2006 4:49 AM
> > > > To: AG-TECH mailing list
> > > > Cc: ag-dev at mcs.anl.gov
> > > > Subject: [AG-DEV] Bridge Information
> > > >
> > > > Hi,
> > > >
> > > > I have another idea that someone might like to implement (I
> > > will try if I
> > > > have time at some point).  Currently, it is difficult to
> > > work out if a
> > > > client is bridged or if they are using multicast.  The
> > > bridge forwards the
> > > > traffic from the client without modification.
> > > >
> > > > One idea that would make it easier to determine if someone
> > > was bridged or
> > > > not would be to add some information to the RTCP packets
> > > when they arrive
> > > > in the bridge program (quickbridge, InSORS bridging
> > > software or other
> > > > software), such as adding " (B)" to the end of the NAME
> > > SDES packet.  This
> > > > would be fairly simple to do I think - when a packet comes
> > > in with an RTCP
> > > > header:
> > > > 1. Search the RTCP packet for the SDES header
> > > > 2. Search for the SDES NAME packet
> > > > 3. If the NAME field exists:
> > > > 3.1  Add 4 to the length of the SDES header (note that
> > > padding does not
> > > > need to be altered in this case)
> > > > 3.2  Add 4 to the length of the NAME field
> > > > 3.3  Shift the bytes after the name field up by 4
> > > > 3.4  Add " (B)" to the name field.
> > > >
> > > > I guess the main problem here would be if the packets were
> > > encrypted.  In
> > > > this case, the RTCP packet would not be detected, and
> > > therefore nothing
> > > > would happen.  Alternatively, the bridge could be given the
> > > encryption
> > > > key.
> > > >
> > > > An alternative to modifying the bridge would be to modify
> > > the actual RTP
> > > > tools (VIC, RAT, InSORS, etc) to add the " (B)" to the name
> > > when a unicast
> > > > connection was being made (or " (U)" if that is more
> > > generic).  This may
> > > > actually be the easier option.
> > > >
> > > > Just an idea...
> > > >
> > > > Andrew :)
> > > >
> > > > ============================================
> > > > Access Grid Support Centre,
> > > > RSS Group,
> > > > Manchester Computing,
> > > > Kilburn Building,
> > > > University of Manchester,
> > > > Oxford Road,
> > > > Manchester,
> > > > M13 9PL,
> > > > UK
> > > > Tel: +44(0)161-275 0685
> > > > Email: Andrew.Rowley at manchester.ac.uk
> > >
> > >
> > >
> 
> 
>