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:[email protected]] > Sent: 08 March 2006 16:27 > To: '[email protected]'; > '[email protected]'; 'AG-TECH mailing list' > Cc: '[email protected]' > 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:[email protected]] > > Sent: Wednesday, March 08, 2006 9:18 AM > > To: Ivan R. Judson; [email protected]; AG-TECH > mailing list > > Cc: [email protected] > > 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: [email protected] > > > [mailto:[email protected]] On Behalf Of Ivan R. Judson > > > Sent: 08 March 2006 15:15 > > > To: [email protected]; 'AG-TECH mailing list' > > > Cc: [email protected] > > > 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: [email protected] > > > [mailto:[email protected]] On Behalf > > > > Of Andrew A Rowley > > > > Sent: Wednesday, March 08, 2006 4:49 AM > > > > To: AG-TECH mailing list > > > > Cc: [email protected] > > > > 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: [email protected] > > > > > > > > > > > >
