Access your PBX using voice channels

As VoIP PBX administrators we often have to deal with not so cooperative network administrators.
The IP PBXs depend from the underlying network infrastructure, as for their normal behaviour, as for their access remotely and not rarely happen to have to deal with very restrictive network policies.
I found frustrating the fact that network administrators implement their network policy, without any consult, ending at last denying any remote access to the infrastructure but their owns.
In such situations, change an extension name, say 400, becomes a time consuming task and you have to move to the client location and do it on site or in the best case scenario, you might have to ask to the client to use one of the PC equipped with some software such as Teamviewer.
If you ever had this kind of experiences, you know what I mean.

In this article I want to propose you, not the SOLUTION, but something you may use to mitigate the situation; requiring no extra hardware, nor human help.

Do you remember the old days when you had to use the analog modems to connect to the Internet?
Since at the time there were no digital lines or at least no cheap digital lines, the only solution were use modems.
Well, the solution I want to propose is indeed use voice lines, VoIP or not, in a similar way you used to do in such old days.
Before I show you my implementation, if you do not know already, let me introduce some piece of software I'll use to implement it.

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

The very first question that might be asked is: Why use amateur radio software?
Well, reasons can be many. The most obvious is that this software is already there, it is quite old and tested. But if you need another, I can add that old modems produce a carrier that have to be kept for a connection long time, using a VoIP packet connection you may have latency problem, the same you have when FAXes do not work. Amateur Radio packet protocols produce a carrier only during the effective data transmission, therefore they are less prone to have latency issues.

The final idea should look such as the following images:

This solution won't let you connect your Asterisk server at the highest speed, with this method the best you can do is 38400bps, but at least you can remotely manage your installation without beg anyone's help for a remote access!

The implementation

The Amateur Radio AX.25

Make sure you have the hamradio kernel modules installed, you may check the presence of mkiss.ko in the /lib/modules/ directory to have an hint they're really there.

A note for RedHat derived distributions, this is true at least for RedHat Enterprise Linux 5, 6, correspondingly CentOS versions and possibly other distributions. Those distributions do not have hamradio kernel modules built, therefore you have to build your own.
The best I can suggest to the happy RedHat users is to download the kernel source using the yum utility, and then integrate all missing pieces (hamradio kernel modules) with the ones moved from the correspondent kernel sources taken from www.kernel.org. (here a guide to build kernel module on CentOS systems after you made the transplant)

Once you're sure kernel is ok, you may begin consider the user space utilities you need for this task.
My suggestion is build them your own from the sources.
Anyway you decide to do, make sure you have the followings packages:

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

The AX25 protocol stack is not so difficult to configure, in fact I had the only need to add only a row to the axports file in the /etc/ax25 directory. The axports defines the port names, their associated mappings.
Here an example:

sm0     HQH1            4800    255     2       Test connection

The fields in this file represent in order:

• The name of the new interface you'll use to send packets through the voice link
• The Callsign you'll use "on the air". This is the L2 address used by the ax25 protocol. In the real amateur radio field this is assigned by some authorities, but in our case anything would be fine.
• The speed of communication between TNC and computer, in other words the speed of the communication between the kernel and the soundmodem, which is a software implementation of the TNC.
• The MTU for this ax25 connection.
• The ax25 window parameter.  It might be considered like 'maxframe'.
• The description.

The next step is configure the soundmodem software, which is the actual modulator demodulator for the voice signal.
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 is proved working, but it is also slow, 4800 bps! If your voice path is clear, there space to get faster.
I divided the configuration in coloured sections:

• orange: This section specifies the media access. I used some default settings, but consider the media we're trying to use is far much different from the one intended for this use. Our media is full duplex; and we do not really need to respect time constraints like time slots nor tx delays.
• magenta: This section specifies the actual alsa hardware we're are going to use. I plan to explain in more details in the next section "Alsa loopback device" but let's say that in this section we should specify an alsa aloop device channel preceded by the suffix "plug" which is need for resampling issues.
• yellow: This section specifies the channel settings and the binding with the actual Linux interface, in this case sm0.
• green: This sections specify the modulation and demodulation method, the throughput and frequencies involved. Feel yourself free to try various combinations to find the best in your situation.
• cyan: This section specifies the packet mode setting parameters. In this section you assign the layer 2 and layer 3 address for your connection.

Alsa loopback device aloop

The only reason this piece of software is there, is because we want to interface Asterisk with the soundmodem device. They both use an alsa device as input/output therefore the alsa loopback device is the natural way to interface them. The aloop is present in every Linux distribution I know, so it shouldn't be difficult to find one ready to be used.
In most situation the only need is 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 need just one of those channels, so you may tweak the module loading with options specifying in the modprobe.conf, or whatever your distribution has to specify kernel modules parameters.

Asterisk

The Asterisk part of the configuration makes use the uncommon chan_alsa.
The Asterisk Alsa channel driver has been originally developed to let use the server console be used as endpoint in the telephony system. Chan_alsa as its name suggest uses an alsa capable devices to direct the voice stream.
The only thing we need to tweak in the alsa.conf original configuration is the alsa device to be used, 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, directing a call to this end point we created a leg of the tunnel.
Eg. in extensions.conf

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

Note:
In actual tests of the tunnel, in spite ax25 is seen as a kind of ethernet, and implements an arp style level 2 address resolution, I had to set it manually.
If it happen you have the same issue, the arp syntax for ax25 bindings is:

arp -H ax25 -s 23.0.0.1 HQH1