[App_rpt-users] Echolink Link Status

[Tony Langdon, VK3JED]

At 09:14 AM 1/23/2011, Jim Duuuude wrote:
>Our architecture for Echolink differs a great deal from most others. 
>Since there is no sane
>reason in the universe to do otherwise, our Echolink presence is 
>both more-or-less a "conference",
>since it will ALWAYS accept multiple inbound connections and tie 
>them together (as any connection
>is on an app_rpt node), and have the ability to support multiple 
>outbound connections (also tied together
>with everything else on the app_rpt node) simultaneously. There is 
>no reason to create "artificial"
>limitations of this nature.

Actually, there are reasons to create such limitations, but always 
under the sysop's discretion.  A few examples might help.

1.  Connecting to a node that blocks conferences.  Do you advertise 
Asterisk as a conference all the time?  Some of the time (i.e. only 
when there's more than one connection, which is what Echolink and 
thelinkbox do).

2.  Conferences are not welcome on other conferences (i.e. 
multiconferencing).  Do you have the ability to prevent Asterisk from 
multiconferencing?  Why is this a problem, you may ask?  Several 
years ago (actually, just before Hurricane Katrina), I realised that 
the most common cause of unintentional interference was caused by 
stations (-L, -R or PC user) having multiconferencing 
enabled.  Someone would connect to these stations and then put out a 
call without taking time to listen to what's going on.  In some 
cases, these people would actually connect and get out a call in 
between overs, blocking emergency or priority traffic in the 
process.  As a result of these observations, some conferences have 
been running scripts that disconnect any station found to have 
multiconferencing enabled.

3.  The number of stations allowed to be in conference is sometimes 
important, i.e. when upstream bandwidth is limited.  It's better to 
block the next connection, than have everyone breaking up.

All of these would need to be sysop configurable variables, and in 
that way, I agree that the software shouldn't contain any hard coded 
limitations, but sometimes, sysops need to be able to add their own 
limites to suit their situation.


>Since the Echolink reporting system is really designed for 
>implementation that basically do
>"one thing at a time", there is only a concept of a single status 
>message. To make a (rather
>feeble) attempt at "fitting into the mold", I decided to report the 
>"inbound" status when there
>are no outbound connections active. If outbound connections are 
>active, it reports the information
>for the last one connected (if multiple outbound connections are active).

I had the same issues with EchoIRLP, because IRLP had no concept of 
multiple connections, so reporting the "connected station" was an 
exercise in reporting the most recently connected station, and hoping 
it made some kind of sense! :)


>Therefore, by definition, the node can *never* be "busy" according 
>to the Echolink reporting
>definition of "busy".
>
>And yes, the "20" means "of 20 maximum connections". However, the 
>connection limit was never
>implemented (after all, I try to avoid artifical limits on things). 
>If and when there is a compelling reason
>do to so, I will. Currently, the system will take as many 
>connections as there is bandwidth and CPU power for.

Or better still, put that in the hands of the sysop, since this is 
most likely to be site dependent.

73 de VK3JED / VK3IRL
http://vkradio.com