Getting an ancient phone online in 2021.ev

Note: The more I worked on this article, the more I realized that it needed to be split into two separate articles. There was more ground to cover here than I originally thought. This article covers configuring a travel router running OpenWRT as a gateway for an ATA, and a Cisco ATA. The Asterisk configuration stuff will come later.

As seems to happen during the time of the covid-19 plague, it's really easy to clear one's backlog of "wouldn't it be nice if" and household repair projects in a short period of time. I mean, hell, I recabled my server rack, emptied my trophy case, unbolted it from the wall so I could install some industrial PDUs and then built a new startpage for Windbringer using Homer because I got bored with the Firefox plugin I was using in the space of about a week. The obvious question was, what am I going to do next to keep from losing my mind?

There is a community project called Project MF, which built an emulation of the old-time telephone network from the 70's and 80's that old-time phone phreaks and hackers cut their teeth on once upon a time. Only, instead of electromechanical hardware Project MF used the open-source voice over IP software Asterisk that was patched to implement in-band signaling (when control signals go over the same information channel as the voice traffic). So, I went scrounging around in my parts bin and built myself a blue box out of spare parts and a checkout of the firmware from Github. Much to my surprise it worked. It's a little quiet but it works.

(Note to my readers: Once upon a time this sort of thing was illegal. Blue boxing, red boxing, and the like haven't worked for ages because the infrastructure doesn't exist anymore. People are now building sandbox replicas of that old telecom network out of modern technology to play with.)

All of this is largely due to the fact that Hasufin gave me a bright red touchtone phone like you might see in a a spy movie. I really wanted to put it to use somehow, which is what sent me down this particular rabbit hole. Project MF is the first thing I thought of ( (local mirror) to get the phone working.

So I set about trying to set up my own Project MF server on Leandra. Cutting to the chase, I didn't put a whole lot of time in on it because the patches to Asterisk are for an ancient version of Asterisk (v1.2.12), and as of this writing the latest version is v18.2.0. What this basically means is that there is a good chance that this extremely old version of the software released in 2006 might not work reliably on a fairly up-to-date Linux system (Linux kernel v5.9.6-arch1-1, glibc v2.32-5). I really didn't feel like trying to figure out where any problems might lie for weeks on end. Plus, I really needed to get my phone plugged in and working first, so I decided to worry about the software after I had working hardware.

This is significantly harder than it sounds these days. We don't have an active landline out here, either. Even if we did that didn't mean that the batphone could communicate with an Asterisk server online. I had to fall back on a hardware workaround. In the VoIP field there are devices called ATAs - analog telephony adapters - which are devices that you can plug one or more old-school phones into, and then plug the ATA into a data network and you then have a VoIP phone. However, because our house isn't wired for data (and running CAT-6 cable along the baseboards is a bad idea, ask me how I know) I then had to get the ATA on our local wireless network. The problem I then ran into was that most wifi enabled ATAs are locked to a particular provider and can't be reconfigured. After thinking about it for a bit I decided that I didn't feel like then doing any serious hardware hacking with no guarantee of payoff just to get a Yule gift working.

Back to my stash of spare parts. I dug out a travel router (a TP-Link N150) and installed OpenWRT on it so that I could configure it appropriately (which you can never do with stock firmware) and, after some consultation with the Internet hive mind ordered a Cisco SPA122 small business ATA. What I wanted to build was this:

The travel router, after flashing OpenWRT onto it, was configured thusly (and perhaps a bit tersely):

  • Network -> Wireless -> radio0 -> edit
    • Get the wireless interface of the travel router onto your wireless network as a client, just like your laptop.
    • General Setup -> Mode -> Client
    • General Setup -> ESSID -> your wireless network
    • General Setup -> Network -> wan, wan6
    • Wireless Security -> Encryption -> WPA2-PSK
    • Wireless Security -> Cipher -> auto
    • Wireless Security -> Key -> your wireless password here
  • Network -> Interfaces-> WAN -> Edit
    • Make sure the travel router uses the configuration information from your wireless network.
    • General Settings -> Protocol -> DHCP Client
    • General Settings -> Bring up on boot -> check
    • Advanced Settings -> Use default gateway -> check
      • "Use whatever gateway the network's wireless router sends me."
    • Advanced Settings -> Use DNS servers advertised by peer -> check
      • "Use whatever DNSes the network's wireless router sends me."
    • Physical Settings -> Bridge interfaces -> not checked
    • Physical Settings -> Interface -> wlan0
    • Firewall Settings -> Create / Assign firewall zone -> "wan: wan wan6"
  • Network -> Interfaces-> LAN -> Edit
  • Turn the LAN Ethernet jack of the travel router into the internal gateway, for the ATA.
    • General Settings -> Protocol -> Static address
    • General Settings -> Bring up on boot -> check
    • General Settings -> IPv4 address ->
    • General Settings -> IPv4 netmask ->
    • General Settings -> IPv4 gateway -> empty
    • General Settings -> IPv4 broadcast -> empty, use calculated default
    • General Settings -> Use custom DNS servers -> empty
    • Advanced Settings -> Force link -> check
    • Physical Settings -> Bridge interfaces -> check
      • "Turn on sending traffic from behind the travel router to the wireless network."
    • Physical Settings -> Enable STP -> not checked
    • Physical Settings -> Enable IGMP snooping -> not checked
    • Physical Settings -> Interface -> eth0.1
      • This is the Ethernet jack the ATA gets plugged into.
    • Firewall Settings -> Create / Assign firewall zone -> "lan: lan"
    • DHCP Server -> Advanced settings -> Dynamic DHCP -> check
  • Network -> DHCP and DNS
    • We don't want the DHCP server to conflict with the one on your wireless network.
    • We also don't want the security features to mess with what you're trying to do.
    • General Settings -> Domain required -> check
    • General Settings -> Authoritative -> check
      • "Is this the only DHCP server running behind the travel router?" "Yes."
    • General Settings -> DNS forwardings -> the IP address of the in-house DNS
      • This should be your wireless router at home, usually.
    • General Settings -> Local service only -> check
    • General Settings -> Non-wildcard -> check
    • Advanced Settings -> Suppress logging -> check
    • Advanced Settings -> Filter private -> check
    • Advanced Settings -> All servers -> check
  • Network -> Firewall
    • General Settings -> Enable SYN-flood protection -> check
    • General Settings -> Input -> accept
    • General Settings -> Output -> accept
    • General Settings -> Forward -> Reject
    • General Settings -> Zones
      • This is a basic firewall, nothing special.
      • lan => wan
        • Input: accept
        • Output: accept
        • Forward: reject
        • Masquerading -> unchecked
      • wan => reject
        • Input: reject
        • Output: accept
        • Forward: reject
        • Masquerading -> checked
    • Port Forwards
      • This forwards ports from your wireless network to your ATA. Without this, the ATA can send traffic but can't receive it (one sided calls, no dialtone, no ringing).
      • Name: ATA-admin-page
        • Match: Incoming IPv4, TCP, from wan, to this device, port 8080
        • Action: Forward to lan IP , port 80
        • Enable: check
      • Name: ATA-inbound-SIP
        • Match: Incoming IPv4, TCP, from wan, to this device, port 5060-5061
        • Action: Forward to lan IP , port 5060-5061
        • Enable: check
      • Name: ATA-inbound-RTP
        • Match: Incoming IPv4, from wan, to this device, port 16384-16482
        • Action: Forward to lan IP , port 16384-16482
        • Enable: check
    • Traffic Rules
      • This sets IPtables rules that allow the above port forwards to work.
      • This also makes it possible to administer the traffic router from your home wireless network, which is not the default.
      • All of the rules below are added to the list. Don't mess with the ones that already exist, or you will drive yourself mad.
      • Name: Allow-SSH-WAN
        • Allows SSHing into the travel router for maintenance.
        • Match: incoming IPv4 and IPv6, protocol TCP, from any zone, to this device, port 22.
        • Action: Accept input
        • Enable: check
      • Name: Allow-HTTP-WAN
        • Allows access to the travel router's web control panel.
        • Match: incoming IPv4 and IPv6, protocol TCP, from any zone, to this device, port 80.
        • Action: Accept input
        • Enable: check
      • Name: Allow-inbound-SIP
      • Permits incoming SIP traffic from your wireless network to reach the ATA. This is controlling-calls-signal-traffic.
      • Match: forwarded IPv4 and IPv6, from wan, port 5060-5061, to lan, IP <the ATA's static IP, here, port 5060-5061
      • Action: Accept forward
      • Enable: check
      • Name: Allow-inbound-RTP
        • Permits incoming RTP traffic from your wireless network to reach the ATA. This is the actual people-talking-sound-traffic.
        • Match: forwarded IPv4 and IPv6, from wan, port 16384-16482, to lan, IP <the ATA's static IP, here, port 16384-16482.
        • Action: Accept forward
        • Enable: check

At this point, the travel router was sitting on my wireless network along with everything else. Then I plugged the WAN jack of the Cisco ATA into the LAN jack on the travel router and Windbringer into the LAN jack, and logged in to configure ATA per the manual. Note that some of the holes punched in the travel router are supposed to make it possible to administer the ATA remotely later.

For the purposes of this blog post I'll only be talking about the network configuration of the ATA. The VoIP stuff won't be useful until the article about installing and configuring Asterisk, so I'll skip over that for now. There is no particular reason that you have to use the same ATA as I (but you can if you want), so for that reason I won't go into specifics the way I did for the travel router (because OpenWRT is OpenWRT, and once you know your way around it doesn't really matter what hardware it is). However, I will try to describe things that are common to different devices.

If there is a way to configure the unit specifically for NAT mode, it's probably a good idea to do so. I don't know if it's actually helpful but I did anyway. Set a hostname on the ATA; I called it "batphone" for obvious reasons but you can pick whatever makes sense to you. I found it helpful to hardcode one internal DNS in my ATA (the default in my home network, but you may not need to do so. If your ATA is also an office router you can configure that functionality however you like, but that only matters if you plug anything into the back end of the unit. A fair amount of encryption-related stuff will probably be taking place, so make sure that you set the correct date and time on your ATA. If your ATA supports getting its date and time from the network be sure to turn that on to make life easier.

If you scroll back up and look at the firewall rules for the travel router, two ports were forwarded through the firewall, 5060 and 5061 for SIP. If you can configure a range of ports for SIP on your ATA (hey, two ports is a range), configure the same ones as in the firewall. You shouldn't need more than two for SIP. If there is a way to set your registration interval (the amount of time in between the ATA sending a SIP "hey, I'm here" message to the server), set it to something between 30 and 60 seconds, which is long enough to keep the firewall from doing anything dumb like closing the port for inactivity. Yes, you poked holes in the travel router's firewall for SIP packets to go in both directions, but that doesn't mean that your travel router's is all that bright. I advise against taking that particular chance. Also, in the travel router's firewall rules you opened a range of ports for RTP, Real Time Protocol (the protocol which carries the audio traffic for all sides of a conversation). If you can configure your ATA to use the same ports (and only those ports) for RTP, do so. If you're following the above example, you'll want to set the RTP port range to 16384 to 16482. That way the ATA and the firewall will have matching settings.

If you can turn on remote configuration (meaning that you can configure your ATA from the WAN side as well as the LAN side), do so because that means you'll be able to work on your ATA through the travel router. Of course, set a non-default admin password on your ATA. No sense in being totally irresponsible, after all. If you can update the firmware on your ATA to the latest stable version, it's probably a good idea to do so.

Save your settings one more time (you do save your settings periodically, right?), then plug your old-school phone into one of the phone jacks on the back (into Line 1, traditionally). Reboot the ATA and wait for it to come back up. If, at this point you pick up the phone plugged into the ATA, you should not hear a dialtone (meaning that it's not registered with a VoIP server) but dialing will produce touch tones. Incidentally, not hearing a dial tone from a VoIP phone means that it's not associated with the SIP server on the other end.

That's pretty much it for configuring the ATA, and for configuring a cheap travel router to act as a wireless bridge of sorts for it. The next blog post coming will describe what I went through to get Asterisk set up, get my NPSTN credentials, and get everything configured on the network. It'll probably be as long as this post (if not longer), which is why I split them up.

Happy hacking, everyone!