[App_rpt-users] Echolink Link Status
Tony Langdon, VK3JED
vk3jed at vkradio.com
Sat Jan 22 17:44:40 EST 2011
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
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
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
More information about the App_rpt-users