Regardless of the “eannmode” setting, echolink callsigns are never announced, only node numbers. I’ve seen this problem in various bug reports over the years, but there doesn’t appear to be a solution. Environmental perhaps? Anyone fix this? We just migrated from irlp, and users miss this feature as the 3* echolink node numbers are generally meaningless.
thanks,
-craig
Additionally, it appears the echolink database acquired/used by allstar is out of date.
“echolink dbdump” doesn’t list my callsign or node number, even after staying logged in for 20 mintues or so.
One time it found my echolink node number, but was associated with someone elses’ callsign.
I’ve tried a few different echolink servers in allstar echolink config file as well.
I even did a stacktrace on “asterisk -rx “echolink dbdump””, and couldn’t find a local copy of the db it uses. That aparently just does a db download from the echolink server over a socket connection.
Completely stumped as to why allstarlink cannot get a good copy of the echolink database.
Honestly I never knew you could set it to announce call signs. I only heard nose numbers and I disable that completely due to all of the drivebys that connect, wait 3.5 seconds and disconnect. Very annoying. But let me know how you set call signs to announce. That is new to me.
KA4EPS
eannmode=2 ;0=no announcements, 1=node number(Allstar-xlated), 2=callsign, 3=both
echolinkdefault=1 ;0=off, 1=on, 2=on after command & shortly after, 3=follow local telemetry
echolinkdynamic=1 ;0=disallow user change setting via COP command, 1=Allow users to change
Some things to look at…
Check directory write permissions for the directory in question
You can change EL servers and my list may be out of date, but any of them can have a issue from time to time.
You can list 3 in your conf file, it will use them ‘in order’ to connect till it does not make a connection, then goes to the next when that fails ‘connect’.
server1=naeast.echolink.org
server2=nasouth.echolink.org
server3=servers.echolink.org
for a test, you might try this one in slot 1 and restart asterisk
server5.echolink.org
or just change the order for now.
Most often, when you think it is a driveby type connection, it is not a intentional thing.
Many on a cell connection are forced using bad proxies and relay’s that do not connect properly and while you see the connection, the user does not see ‘connection acknowledgement’.
So, he waits a brief period and tries something else on some other node not understanding what is going on.
If they would try to connect on wifi direct, it normally has no issues at all. Obviously, these connections are less transparent than they need to be for understanding. Complicating the issue with multiple tries on many nodes = more driveby’s.
These relay’s and proxies need fixed.
Turn your wifi off and try it on your cell phone with your own node using relay’s and proxies for better understanding.
That’s interesting. I never thought about that scenario. Perhaps having a delay of telemetry announcement to ignore those cases would be helpful. Something to think about. But for me, having no telemetry works fine.
While it is simply a observation from my standpoint, I think it has more to do with iphone users and tcp port 5200 in these relays/proxies.
It may not be a complete observation. But something is not correct.