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

[Derek Piper]

	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