28Sept2022
Building an AutoPatch. It's still useful!
A quick intro
I live on the rural northern California coast. As technology has marched on, and AT&T has been allowed to let all the copper communications lines fall into disrepair and failure, we find ourselves dependent on a very fragile infrastructure. In our case, hundreds of miles of coast are connected inland by a single fiber run. All land lines, cell phones, and network connections from various providers tie into this single point. And it's failed, taken out by a truck hitting a single pole on a secondary road, causing all communications to fail. No 911, no internet. And we've had smaller outages since, when construction folks dug into local communications lines, isolating smaller numbers of people.
Thankfully, some other advances have arrived, one being Starlink. A fast bi-directional satellite connection to the internet. Not dependent on local infrastructure, except what we control ourselves. With that key piece, some local Hams thought it might be a good idea to see if we could build a simple and inexpensive autopatch, so we'd have some ability to communicate to non-hams, via our radios, when the network again goes down.
One such Ham, Jonathan, KK6RPX, had gone as far as to grab a AVRTX RI-2020 radio interface, and was hoping to get AllStarLink working with it. But, projects kept stacking up, so he asked me if I could take a crack at it, being the old software guy I am. As always, I'm indebted to the many people who've worked on parts of this technology, and shared their learnings. Here's my how-to on getting this working...
Prerequisites:
- A computer that can run the AllStarLink software (PC or Raspberry Pi, or other Debian boxes). I used the 2.0 Beta software.
- A soundcard to radio adapter (I used an avrtx RI-2020, but I don't know if you can buy those anymore, I'll update this as we try other devices)
- A voip provider (I used voip.ms)
I won't get into the politics, since frankly I don't understand them, but there's some kind of disagreement surrounding the AllStarLink software. It seems to have killed all new development. But, what's available seems to work, and for the single use case of a voip AutoPatch, it works fine.
First, follow the Beginners Guide to get the Beta 2.0 image installed and configured. You technically don't need the server and node just to be a standalone AutoPatch, but the current software wants to phone home, and needs to be able to connect with a node number.
If you use a different distribution of AllStarLink, this guide may, or may not help you. Also, not entirely sure how this will work with other voip providers.
Configuring Asterisk
Once you've run through all the AllStarLink setup, and have a node up and online, it's time to customize. If you're not using voip.ms, you might want to change the tag 'voipms' to something else in all the config files it is mentioned in. We'll be modifying the following config files (located in /etc/asterisk)...
- modules.conf - what modules are loaded at startup
- rpt.conf - repeater configuration info
- sip.conf - configuring your voip provider info
- extensions.conf - setting up how numbers are dialed
modules.conf
The easiest of the batch. Simply change the single line:
noload => chan_sip.so ;
to:
load => chan_sip.so ;
This tells the software to load the code supporting SIP (Session Initiation Protocol, if you're curious)
rpt.conf
change:
callerid = "Repeater" <0000000000> ; callerid for phone calls
(Note, I believe the software puts the machine name here, which is Repeater by default)
to whatever text and phone number you want your callerID to show, when the voip provider makes the call.
NOTE: You must set the number to a valid 10 digit phone number. If you leave it all zeros for testing (like I did), then when voip.ms tries to make a call, nothing will happen because the callerID is invalid. Again, YMMV with a different voip provider.
Add the line:
context = voipms ; Autopatch addon ;
I added this right after the "callerid" line.
Change the line:
61 = autopatchup,noct = 1,farenddisconnect = 1,dialtime = 20000 ; Autopatch up
to:
61 = autopatchup,context = voipms,noct = 1,farenddisconnect = 1,dialtime = 20000,quiet = 1 ; Autopatch up
All I did is add the options "context = voipms" and "quiet = 1". The options can be in any order. context links to the entries we'll make in sip.conf, and if quiet is set to 0, it just didn't work with voip.ms for me.
What this means is when you send *61<number> from your radio, it will send <number> to the sip provider specified in sip.conf. When you send *62, it will hang up. Obviously, customize these to numbers you want to use, if you don't like the defaults.
I noticed a bunch of other DTMF commands in the file, which worked as described. One section I was particularly interested in was the Control Operator (cop) items. I wanted to be able to enable/disable things via DTMF, and these do exactly that. I uncommented (and changed the numbers for) items like:
902 = cop,2 ; system enable
903 = cop,3 ; system disable
That'll let you enable/disable the entire system, plus do any other functions listed there. When testing I was getting Tx held high (see NOTE below). I couldn't use any DTMF codes, since the radio was transmitting. I did find that the following command in the ASL Asterisk CLI lets you use these directly:
rpt fun <node #> *<code>
So, if your node number is 12345, typing "rpt fun 12345 *903" will disable the system. And "rpt fun 12345 *62" will hang up the call in progress. Pretty handy to know when testing everything.
NOTE: I changed the duplex from 1 to 2, since the comments in the file said it was preferred when interfacing with a repeater (which this will eventually). Unfortunately, when not talking to a repeater, this just held Tx on until things timed out. Changing it back to 1 fixed that.
sip.conf
Comment out (or remove) the line:
bindaddr = 127.0.0.1 ; IP address to bind to (0.0.0.0 binds to all)
to:
;bindaddr = 127.0.0.1 ; IP address to bind to (0.0.0.0 binds to all)
This cost me a few hours. I was getting what seemed like a totally unrelated, and very vague, error message on startup when I had the sip module loading. Eventually, I commented out this entire file, and found this was the offending line. I don't know why it didn't work, or why commenting it out fixed it.
One nice thing about the rest of this config file, voip.ms has a page with the required settings! Once you're logged into their main site, you can follow this
link to find them. I'll place mine here too, just for reference...
register => <userid>:<password>@sanjose1.voip.ms:5060
[voipms]
canreinvite=no
context=voipms
host=sanjose1.voip.ms
secret=<password>
type=peer
username=<userid>
disallow=all
allow=ulaw
fromuser=<userid>
trustrpid=yes
sendrpid=yes
insecure=invite
nat=yes
extensions.conf
In the [pstn-out] section, comment out:
exten = _NXXNXXXXXX,1,playback(ss-noservice)
exten = _NXXNXXXXXX,2,Congestion
So they look like:
;exten = _NXXNXXXXXX,1,playback(ss-noservice)
;exten = _NXXNXXXXXX,2,Congestion
Again, if you're using voip.ms, they have the next section listed out, which I added right after the [pstn-out] sections, but I added one more thing...
[voipms]
;include => voipms-inbound
include => voipms-outbound
;[voipms-inbound]
;exten => _X.,1,Ringing
;exten => _X.,n,Answer()
;exten => _X.,n,Rpt(41899|Rrpt/node:NODE:rpt/in-call:digits/0:PARKED|120) 75
;exten => _X.,n,Hangup
; THIS IS FOR OUTGOING AUTOPATCH CALLS
[voipms-outbound]
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@voipms)
exten => _1NXXNXXXXXX,n,Hangup()
exten => _NXXNXXXXXX,1,Dial(SIP/1${EXTEN}@voipms)
exten => _NXXNXXXXXX,n,Hangup()
exten => _NXXX,1,Dial(SIP/${EXTEN}@voipms) ; <-- added this line
exten => _NXXX,n,Hangup() ; <-- added this line
exten => _011.,1,Dial(SIP/${EXTEN}@voipms)
exten => _011.,n,Hangup()
exten => _00.,1,Dial(SIP/${EXTEN}@voipms)
exten => _00.,n,Hangup()
This enables only outbound calling. I added the two lines:
exten => _NXXX,1,Dial(SIP/${EXTEN}@voipms)
exten => _NXXX,n,Hangup()
Without these patterns, you can't use the 4 digit codes from voip.ms for testing.
Also, I figured out that you can insert actions to happen after the call is dialed, and before the hangup. I added the following line in between the Dial and Hangup lines to send a
Pushover notification to my phone whenever an autopatch call is made. This fires when the call completes.
exten => h,1,System(curl -k -X POST "https://api.pushover.net/1/messages.json?token=<token>&user=<user>&message=autopatch+has+made+a+call")
And another addition, an absolute call timer that terminates a call, so someone doesn't spend 30 minutes chatting on the phone, tying up the repeater. Adding the "L(x:y:z)" function to the Dial command terminates after "x" number of milliseconds, starts warning when "y" seconds remain, and repeats the warning every "z" seconds. Replacing the Dial lines with lines that look like this:
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@voipms,15,L(300000:60000:20000))
This terminates the call after 5 minutes, starts warning when 1 minute remains, repeating the countdown every 20 seconds until it hangs up. Or, and the 15 is how many seconds the system lets a call ring.
ONE FINAL NOTE
Everything seemed to work fine, except the '3' DTMF, when sent from a Baofeng, didn't register. Also, nearly all the "lower" digits didn't register if sent from a Kenwood V71. Found a comment in a thread (
here) that suggested changing "deemphasis" in the simpleusb.conf file. Made the change from "no" to "yes", everything now seems to work just fine...
And that's it! With those changes, I was able to make calls from my HT, talking to the AllStarLink, which in turn talked to voip.ms and connected the calls. The quality varies, as you might expect, but it's definitely usable.
Next steps...
Right now, this has all the functionality I need. I'm experimenting with removing courtesy and other tones to keep things quieter when we put it on the repeater frequency. Also want to create multiple clones to geographically distribute amongst local Hams, hopefully using cheaper, reliable Motorola commercial radios. I'll be adding some watchdogs that notify me if things aren't responding as expected. I'll document those when I have them running smoothly.
Comments
Post a Comment