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

Actually, at this moment tis ENTIRELY cosmetic.. :-) JIM Date: Sat, 22 Jan 2011 18:16:42 -0600 From: kt9ac@ameritech.net To: telesistant@hotmail.com CC: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Echolink Link Status Thanks for all your hard work Jim! If anyone is worried about how our nodes look on Echolink (the [0/20] thing), inside /etc/asterisk/echolink.conf is a line called "maxstns" that we can change. I set mine to 1 and still was able to outbound connect to two Echolink nodes at the same time, so its mostly cosmetic. Tony On 01/22/2011 04:14 PM, 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. 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). 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. JIM WB6NIL > Date: Sat, 22 Jan 2011 14:26:22 -0600 > From: kt9ac@ameritech.net > To: app_rpt-users@ohnosec.org > Subject: Re: [App_rpt-users] Echolink Link Status > > Just updated my test system to 0.281 and verified that when idle it > shows a [0/20] next to my QTH. When connected, shows the "In conference > with..." status. > > Does this mean we can host 20 connections from Echolink per Allstar > node? Also, when would the "ON" versus "BUSY" flag change. > > I don't use Echolink a lot, but its interesting... > > Thanks, > Tony > > On 01/21/2011 11:26 PM, K&R Yoksh wrote: > > > > ----- Original Message ----- > >> Date: Fri, 21 Jan 2011 18:27:15 -0800 > >> From: Jim Duuuude > >> Subject: Re: [App_rpt-users] Echolink Link Status > >> > >> Chan_echolink now supports proper display/reporting to the echolink > >> server stuff. > > > > Hello Jim (and the group), > > > > Many thanks for this great addition! > > > > 73. > > > > Kyle > > K0KN > > > > _______________________________________________ > > App_rpt-users mailing list > > App_rpt-users@ohnosec.org > > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > > > _______________________________________________ > App_rpt-users mailing list > App_rpt-users@ohnosec.org > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users