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

[Ivan R. Judson]

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
> >
> >
> >