[AG-DEV] Bridge Information

Andrew A Rowley Andrew.Rowley at manchester.ac.uk
Wed Mar 8 09:52:40 CST 2006


Hi,

Good idea if you are using AG2, but not so great if you are in a mixed AG2/InSORS meeting as most of the UK meetings are...

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: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev 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: 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
> 




More information about the ag-dev mailing list