One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Tom – WB8LCD and articles are submitted by cabinet members.
Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.
You can receive the Journal and other Ohio Section news by joining the mailing list Tom has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!
If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the Ohio section will need to use the mailing list link above. Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
- Go to www.arrl.org and click the Login button.
- Login
- When logged in successfully, it will say “Hello <Name>” in place of the Login button where <Name> is your name. Click your Name. This will take you to the “My Account” page.
- On the left hand side, under the “Communication” heading (second from the bottom), click Opt In/Out
- To the right of the “Opt In/Out” heading, click Edit
- Check the box next to “Division and Section News.” If it is already checked, you are already receiving the Ohio Section Journal.
- Click Save
- There should now be a green check mark next to “Division and Section News.” You’re all set!
Now without further ado…
Read the full edition at:
THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net
Hey gang,
Hamshack Hotline is a private free to use VoIP telecommunications phone service put together for the ham radio community by hams. It is a way to enhance communication between ham shacks and even Emergency Operation Centers. I, and other Technical Specialists, have written many articles in the OSJ about this service. It’s a great use of technology to enhance communication, even if it doesn’t use RF.
Cracks started to show problems when Hamshack Hotline had a falling out with members of their board and support platform moderators. It’s their project and they can run it however they want. I no longer recommend nor support this project. Unfortunately, they are the largest ham-based telco provider.
Hamshack Hotline has many features including “RF Links” which are extensions that dial into a AllStar Link node. Termed RF links typically because the ASL node is connected to a repeater or simplex radio.
After linking my multimode system to Hamshack Hotline, some HH users reported being disconnected after 30-40 seconds. I didn’t experience disconnects using my extension and neither did the majority of users. Doing some troubleshooting, I had those users try other RF link extensions to see if they were disconnected after the same length of time. Users confirmed the same experience on other RF links. It wasn’t only limited to my configuration.
Back in March 2021, I opened a ticket with the HHOPS helpdesk identifying symptoms my users were experiencing. This ended up being an exercise in futility. Included in my what-I-do-know details, I listed callsigns and extensions of users on HH whom experienced disconnects. Those details could possibly be correlated to a specific HH server, device type, device model, or manufacturer. It was like I traveled to another dimension. The support person thought I owned all those extensions (and callsigns? – I guess) experiencing the issue. What a total waste of time. Ticket was closed by the helpdesk as an issue with the devices experiencing the problem.
Fast forward to March 2023, I get a support ticket from Hamshack Hotline saying my node is sending out “SMS beacons” across the network. “This can cause all phones that are sms RFC compliant to drop the call after approximately 30-45 seconds into the call.” Guess they found the cause of what I originally reported two years earlier. SMS (same standard as SMS text messaging) beacons sent by AllStar Link nodes caused phones on HH to hangup. It went on to indicate changes on a HamVoIP based AllStar node is a two-line configuration change. Changes for other software, such as native AllStar Link, is more involved.
I run a hub on Virtual Private Servers (VPS) in the, so-called, cloud. My system runs native AllStar Link. I’m unable to run HamVoIP since that distribution is for Raspberry Pi/ARM processors only. Additionally, recent major updates have further separated HamVoIP from AllStar Link. They’re almost two different systems. Not to mention HamVoIP has been accused of license violations. These made me uneasy about the future of the HamVoIP project and I’ve contributed to the ASL project. As a result, I moved my personal node from HamVoIP to native ASL.
Following provided instructions by Hamshack Hotline, reached out to them because I’m not running HamVoIP on my hub. I was put in touch with another person that had the “fix” for ASL. Two things were needed to disable SMS beacons: (1) create a private node for Hamshack Hotline connections. A private node in ASL are the reserved node numbers 1000 through 1999. I did this anyway on my hub. (2) Disable pushing CALLERID to the RPT module. RPT is the module that handles ham radio functionality in Asterisk. As one would expect, CALLERID contains unique data about the caller. When used with RPT, this is typically extension, node, or callsign information.
Having a decent level of experience working with Allstar configuring hubs, nodes, IAX clients, softphones, and desk phones, I knew messages were pushed to other connected nodes and devices. These exchanges show up as a list of connected nodes on a status page such as Allmon or Supermon, within apps, on a display, in logs, in the Asterisk CLI (command line interface), on the ASL website, etc. I didn’t have the need to know this exchange was done via SMS messages, but knew there was some mechanism used for reporting information to other connected nodes. I had seen references it was an “SMS message,” but never confirmed.
While working with the person provided by Hamshack Hotline, the comment was made: ‘this is ham radio, I don’t know why we’re using SMS text messages.’ Taken aback, said ‘that’s how the network knows about other connected nodes.’ This person, who came up with (at least) part of the solution to fix this SMS beacon issue, didn’t know or understand Asterisk clients exchanged information with other nodes. I’m always irked by required mandatory changes where they don’t understand what they are changing, the broader impact of said changes or to even ask the question and address concerns. I blew it off and gave their solution a whirl.
Below are Asterisk and AllStar Link extensions.conf examples. These are from various documentation sources showing different ways ID information is passed to the RPT module. 50394 is my hub node and used as an example node number.
AllStar Nodes:
- exten => ${NODE},1,rpt,${NODE}
VoIP clients (IAXrpt, DVSwitch, Zopier, phones):
- exten => ${NODE},n,Rpt,${NODE}|P|${CALLERID(name)}
- exten => ${NODE},1,rpt(${NODE}|X)
- exten=50394,1,Rpt,50394|X
- exten => 50394,n,Rpt,50394|S|${CALLERID(name)}
- exten => 50394,n,Rpt,50394|Pv|${CALLERID(name)}
As I’m working through the provided Hamshack Hotline configuration changes for ASL, I realize their proposed changes will cause problems. Omitting CALLERID means the connection exists but there is no indication of the call in RPT or facilities that use RPT. Users would will no longer see their connection on dashboards and sysops no longer have the control to disconnect individual HH users.
Lack of control and visibility is big problem for me as the sysop of a hub to see who is connected in case of problems. Users will dead key/forget to unmute, not press the # key when they are done talking, or some another innocent mistake – most of those happen during a single net – or someone is being a lid. I’ve used logs to validate reports and contacted users providing information about a situation which they’re likely unaware.
I raised my concerns to Hamshack Hotline about the solution not being good for sysops to control their systems. I was blamed (again) that my system ‘wasn’t working like the others’ because ‘no one else is having the same problems with these changes.’ My guess, results were confused with the HamVoIP distribution or that ASL v1 didn’t act the same as v2 (which I am using). Not having the time and being frustrated (but still respectful), I did not investigate further. Hindsight being 20/20, I had some false hope my feedback would be used to devise a better solution. I can’t be the only one voicing similar concern. In reality, they didn’t care.
Last day of Hamvention, traveling back home, I get a message from Hamshack Hotline that my RF link extension is in violation, been disabled, and in danger of termination if not corrected. Somewhere between March and mid-May, it became mandatory to participate as a HH RF link, I needed to provide a “clean” transmission (without SMS beacons). The insanity wheel began to spin all over again: here’s the solution. I’m on ASL. Contact this guy for the ASL workarounds. That doesn’t meet my requirements. Too bad. Ugggh.
Finally, a Hamshack Hotline Sr. Engineer provided some details but stopped short of offering alternative solutions or a middle ground compromise. He indicated specific issues were caused by different “flavors” and versions of AllStar Link. There can be multiple reasons that cause SMS messages to be sent, not only registering CALLERID with RPT. Admitted there was pushback from others complaining about call signs not showing up in “third party” software such as Allmon and Supermon.
Hamshack Hotline tracked the issue to “SMS RFC COMPLIANT” phones. “Newer phones are compliant.” Beacons being sent from Asterisk/ASL are (apparently) not RFC compliant. When a non-compliant SMS message is sent to a compliant phone, that phone simply hangs up or drops the call. “Older discontinued Cisco SPA phones are no longer RFC compliant” because the SMS RFC “changed” after the time those phone models were discontinued. Hamshack Hotline changed models of phones they support. Newer models follow the current SMS RFC specification. Lastly, did state I could submit a new RF link extension request if I ever change AllStar flavors.
It’s not only “third party” applications but the Asterisk RPT module doesn’t show the connection either. I provided examples of this. Presumably he is talking about HamVoIP being a working “flavor” of AllStar, which I cannot run on my servers. Hamshack Hotline admitted concerns were had by others and from all accounts, did nothing about those concerns. I mean at a minimum, reach out to the AllStar Link project in the hope of solving this problem globally for all current and future users whom want a HH RF link extension. ASL is open source and on GitHub. HH could even create a fix and do a pull request (request their code changes are brought into the main code repository) all on their own. I see no evidence this was attempted.
A middle ground solution could have been proposed to simply disconnect the ASL private node assigned to Hamshack Hotline extensions. It’s not great as other HH users could be confused as to why they no longer hear the net or conversations. I still lose logging. Suggest running HamVoIP on a separate Raspberry Pi and connect it over the Internet to the main ASL hub. Not great either as I am using VPS’ in a commercial datacenter for reliability, resiliency, and access to better resources. Though it wouldn’t be my first device not in the same datacenter. I’ve also heard of Raspberry Pi installations hosted in data centers for rent. Somehow, HH could make a note stating users may experience disconnects when using my node. Regardless, no alternatives were suggested or offered.
As I had family issues to tend after Dayton, my patience was razor thin but I don’t think it would have made one bit of difference. We came to an impasse. The Sr. Engineer stated my RF link extension would be reclaimed. I responded back to reclaim my phone extension as well. I have no desire to be a part of or further support Hamshack Hotline. This experience and complaints from users whom have received similar treatment, I do not recommend the use of Hamshack Hotline.
There are currently two alternative ham radio telco solutions, Hams Over IP and AmateurWire. Based on prior knowledge, I’d imagine these systems could encounter a similar situation. I reached out to both for comment. Roger from AmateurWire responded indicating users have not complained about any similar issue but they have a smaller userbase of about 200 extensions. He indicated the situation would not be handled the same as Hamshack Hotline.
Thanks for reading and 73… de Jeff – K8JTK