[AG-TECH] Bridge Cascade system - open discussion
Bonnett, PG (Paul)
P.G.Bonnett at rl.ac.uk
Mon Nov 27 06:28:15 CST 2006
AG3 has has made it simpler for us manage our rooms at CCLRC (both RAL &
Daresbury); most notably with the ability to 'lock' a system into using
Unicast. I openly, the following is based on my perception of how AG3
works; and may not be entirely correct.
Last week, it became apparent that the MO for the way AG3 selects a
bridge was working against us.
It would appear that now anyone can create a bridge which AG3 will find
and select dependent on the time it takes to ping.
This may not however be the best selection method for a site.
Like probably many other sites, we have strict firewall rules &
guidelines to which we must adhere, and changes require time to be
processed by 'other departments. We have therefore selected 5 'known'
bridges around the globe that we expect to use regularly, or as
fallbacks, and only these pass through unhindered. AG3 selects the
'closest' bridge it finds to route through currently.
Last week on at least one occasion, the bridge list could not be seen
from our sites, so there was no bridge at all available to our AG3
systems and we had to revert back to AG2.4 until later in the day.
I would like to suggest an enhancement to the current system (if Unicast
is selected), where the client operation would:
1. Check for bridges against a saved list, and either works from the new
list (if available) or the saved one.
2. Compares the 'current' list to a list (perhaps tagged in
preferences?) of preferred bridges, and tries to connect to the #1
3. If preference #1 fails or is not on the new list, then #2 is selected
(and so on in a cascade fashion)
4. Perhaps this concept could also be adopted in the event of a
heartbeat failure' from the bridge, so the client would automatically
drop down to the next bridge, instead of just flagging up a failure.
I know the purists will say that Unicast is a fallback to Multicast, but
to some sites like ours it is our mainstay, and will continue to be for
the foreseeable future. To us, the most important thing is for the
meeting to take place with minimum of fuss & interruption; in some cases
self operated by 'less knowledgeable people. I feel this would make the
system simpler to manage & operate.
Does this make sense? Would it be difficult to implement? Can anyone
else see flaws?
Access Grid Videoconference Support & Development
Rutherford Appleton Laboratories
R1 Room 2.21
Oxfordshire, OX11 0QX
Tel: 01235 778329
P.Bonnett at rl.ac.uk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ag-tech