[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@manchester.ac.uk]
Sent: Wednesday, March 08, 2006 9:18 AM
To: Ivan R. Judson; Andrew.Rowley@manchester.ac.uk; AG-TECH mailing list
Cc: ag-dev@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@mcs.anl.gov
[mailto:owner-ag-tech@mcs.anl.gov] On Behalf Of Ivan R. Judson
Sent: 08 March 2006 15:15
To: Andrew.Rowley@manchester.ac.uk; 'AG-TECH mailing list'
Cc: ag-dev@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@mcs.anl.gov

[mailto:owner-ag-dev@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@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@manchester.ac.uk






--
Derek Piper - dcpiper@indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana