Access your PBX using voice channels

As VoIP PBX administrators, we often have to deal with uncooperative network administrators. IP PBXs rely on the underlying network infrastructure for both normal operation and remote access. However, they frequently encounter restrictive network policies, which can complicate remote management. It can be particularly frustrating when network administrators implement policies without consultation, often resulting in denied remote access for everyone except themselves. In such scenarios, even a simple task like renaming an extension (e.g., changing 400 to something else) can become time-consuming. You may need to visit the client’s location to make the change on-site. In the best-case scenario, you might ask the client to use a PC with software like TeamViewer, but this still adds unnecessary complexity. If you’ve faced similar challenges, you know how frustrating it can be.

In this article, I won’t claim to provide the ultimate solution, but I’ll share a method to mitigate the situation. It requires no additional hardware and no human assistance.

Do you remember the days of using analog modems to connect to the internet? At the time, affordable digital lines were unavailable, so modems were the only option. The solution I propose is to use voice lines—VoIP or otherwise—in a way similar to how modems were used back then.

1. Linux Ham Radio AX25 software suite
2. Alsa loopback device
3. Asterisk Alsa channel

You might wonder: why use amateur radio software for this? There are several reasons. First, this software is mature, well-tested, and readily available. Additionally, old modems required a continuous carrier signal to maintain a connection. This could lead to latency issues over VoIP connections, similar to the problems you encounter with failed FAX transmissions. In contrast, amateur radio packet protocols only generate a carrier during actual data transmission, making them less susceptible to latency problems.
The final idea should look such as the following images:

This solution won’t provide the highest connection speeds for your Asterisk server. The maximum achievable speed with this method is 38,400 bps. However, it allows you to remotely manage your installation without relying on others for remote access!

The implementation

The Amateur Radio AX.25

To begin, ensure that the Ham Radio kernel modules are installed. You can verify their presence by checking for mkiss.ko in the /lib/modules/ directory, which indicates that the necessary modules are available.
A Note for Red Hat-Based Distributions
For Red Hat-derived distributions, such as Red Hat Enterprise Linux 5 and 6, as well as the corresponding CentOS versions and possibly others, the Ham Radio kernel modules are not built by default. In this case, you’ll need to build them manually.
For Red Hat users, the best approach is to download the kernel source using the yum utility. Then, integrate the missing Ham Radio kernel modules by transplanting them from the corresponding kernel sources available at www.kernel.org. (You can refer to guides on building kernel modules on CentOS systems after performing the transplant.)
Once your kernel setup is complete, you can turn your attention to the user-space utilities required for this task. Required User-Space Packages It’s recommended to build these utilities from source to ensure compatibility with your environment. Regardless of your approach, ensure you have the following packages installed:

• ax25-apps
• ax25-tools
• libax25
• soundmodem

The AX.25 protocol stack is relatively simple to configure. In my case, the only necessary change was adding a single line to the axports file located in the /etc/ax25 directory. The axports file defines port names and their associated mappings. Here’s an example entry:

sm0     HQH1            4800    255     2       Test connection

The fields in this file represent the following:

• Port Name: The name of the new interface used to send packets through the voice link.
• Callsign: The L2 address used by the AX.25 protocol. In amateur radio, this is assigned by an authority, but in our case, any identifier will work.
• Speed: The communication speed between the TNC and the computer. In this setup, it refers to the communication speed between the kernel and the soundmodem (a software implementation of the TNC).
• MTU: The Maximum Transmission Unit for the AX.25 connection.
• AX.25 Window Parameter: This is equivalent to the "maxframe" setting.
• Description: A description of the connection.

An example of its configuration is the following:

<?xml version="1.0"?>
<modem>
<configuration name="AX25">
<chaccess txdelay="150" slottime="100" ppersist="40" fulldup="1" txtail="100"/>
<audio type="alsa" device="plughw:Loopback,0,0" halfdup="0" capturechannelmode="Mono"/>
<ptt file="none" hamlib_model="" hamlib_params="" gpio="0"/>
<channel name="sm0">
<mod mode="fsk" bps="4800" f0="1200" f1="2200" diffenc="1" inlv="8" fec="1" tunelen="32" synclen="32" filter="df9ic/g3ruh"/>
<demod mode="fsk" bps="4800" f0="1200" f1="2200" diffdec="1" inlv="8" fec="3" mintune="16" minsync="16" filter="df9ic/g3ruh"/>
<pkt mode="MKISS" ifname="sm0" hwaddr="HQH1" ip="23.0.0.1" netmask="255.255.255.0" broadcast="23.0.0.255"
file="/dev/soundmodem0" unlink="1"/>
</channel>
</configuration>
</modem>

This setup has been proven to work, but it is slow—limited to 4,800 bps! If your voice path is clear, there is room to achieve higher speeds with adjustments. To simplify the explanation, I’ve divided the configuration into color-coded sections:

• Orange: This section specifies the media access. I used some default settings, but keep in mind that the media we are working with is significantly different from what this protocol was originally designed for. Our media is full-duplex, so we don’t need to adhere to time constraints like time slots or transmission delays.
• Magenta: This section defines the ALSA hardware we’ll use. I’ll explain this in more detail in the next section, "ALSA Loopback Device." For now, note that in this section, you must specify an ALSA aloop device channel, prefixed by "plug" to handle resampling issues.
• Yellow: This section sets the channel parameters and binds the configuration to the Linux network interface—in this case, sm0.
• Green: Here, you configure the modulation and demodulation method, throughput, and frequencies. Feel free to experiment with different combinations to find what works best in your specific environment.
• Cyan: This section outlines the packet mode parameters. It assigns the Layer 2 and Layer 3 addresses for your connection.

Alsa loopback device aloop

The primary reason for using this piece of software is to interface Asterisk with the soundmodem device. Both Asterisk and the soundmodem rely on ALSA devices for input and output, making the ALSA loopback device the most natural way to connect them.
The aloop module is included in every Linux distribution I’m aware of, so finding one ready for use should not be an issue. In most cases, you simply need to load the aloop module into the kernel.

modprobe snd-aloop

This should result in 8 new channels ready to be used

 card 2: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 2: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 7/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7

We only need one of the ALSA loopback channels, so you can adjust the module loading options by specifying parameters in your distribution's configuration file for kernel modules, such as modprobe.conf or its equivalent.

Asterisk

The Asterisk portion of the configuration utilizes the less commonly used chan_alsa module. The Asterisk ALSA channel driver was originally developed to allow the server console to function as an endpoint in the telephony system. As the name suggests, chan_alsa uses ALSA-compatible devices to manage the voice stream. To adapt this for our setup, the only modification needed in the default alsa.conf configuration is specifying the ALSA device to be used—specifically, the aloop device.

[general]
autoanswer=yes
context=local
extension=s
input_device=plughw:Loopback,1,0
output_device=plughw:Loopback,1,0

At this point, by directing a call to this endpoint, we have effectively created one leg of the tunnel. For example, in extensions.conf:

exten => 929,           1,              Dial(Console/snd/controlC0,30)

Note:
During actual tests of the tunnel, although AX.25 is treated as a type of Ethernet and implements an ARP-style Layer 2 address resolution, I had to set it manually.
If you encounter the same issue, the ARP syntax for AX.25 bindings is as follows:

arp -H ax25 -s 23.0.0.1 HQH1