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

[Andrew A Rowley]

Hi,

If the recorder has problems with this, you could add it to a different field that is not as visible, but still accessible from vic and rat.

Looking at this, it might be a good idea to write a tool that listens for the packets and reports where the packets for each participant are coming from.  This would give the same information.

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 

> -----Original Message-----
> From: Derek Piper [mailto:dcpiper at indiana.edu]
> Sent: 08 March 2006 16:47
> To: Ivan R. Judson
> Cc: michael.daw at manchester.ac.uk; Andrew.Rowley at manchester.ac.uk; 'AG-TECH
> mailing list'; ag-dev at mcs.anl.gov
> Subject: Re: [AG-TECH] RE: [AG-DEV] Bridge Information
> 
> 
> 	To add my 2 cents, even if not wanted - I agree with Ivan that doing
> SDES stuff for the sake of notifying if bridged or not is at best
> marginally useful for the effort.
> 	What about this too. We record your unicast packets but then later
> replay them via multicast. Now, not simply replaying the RTCP is
> something I'm working on but if there's indications in the name field
> for these indications we have to strip them out. We'd have to strip them
> out regardless so as not to have ' (U)' at the end of someone's name
> when we save participant data.
> 	Sounds too messy imho.
> 	Besides, you can tell where packets are coming from if the IP
> matches
> that of your bridge server...
> 
> 	Derek
> 
> Ivan R. Judson wrote:
> > 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
> >>>
> >>>
> >>>
> >
> >
> 
> --
> Derek Piper - dcpiper at indiana.edu - (812) 856 0111
> IRI 323, School of Informatics
> Indiana University, Bloomington, Indiana