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: [email protected] > -----Original Message----- > From: Derek Piper [mailto:[email protected]] > Sent: 08 March 2006 16:47 > To: Ivan R. Judson > Cc: [email protected]; [email protected]; 'AG-TECH > mailing list'; [email protected] > 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:[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] > >>> > >>> > >>> > > > > > > -- > Derek Piper - [email protected] - (812) 856 0111 > IRI 323, School of Informatics > Indiana University, Bloomington, Indiana
