From Stu2
Jump to: navigation, search

Developing an understanding of Radio over IP using Open Source Tools and Amateur Radio


Radio over IP provides the ability to link radio systems (audio and PTT) together using an IP based network. Traditionally, communication systems have been linked together using microwaves, land lines and linking radio systems. RoIP opens up a whole new world of interoperability. Now, radio systems can be dynamically linked together and combined with other resources on the IP network. For example, it's possible to provide backup radio dispatch services anywhere there is an Internet connection.

RoIP represents the convergence of Radio and Computer networks. This presents a new set of challenges, specifically in the areas of network security, network performance and standards.

Old vs. New


Certification and Accreditation is a NIST based security model, which is very comprehensive. The key to conducting a successful C&A is to define the system boundaries. That is, what is inside and what is outside. When technologies converge, often in the same device, it's difficult to draw the boundary line.

Radio techs and engineers haven't had to be concerned with IT security and therefore have developed systems which are not secured from both the end point and transport perspectives. For example, the network code has not been tested for buffer overruns and may not be robust enough to withstand DoS attacks. Further, the protocols are unencrypted and the authentication mechanisms are very simple. This places the transport security burden on the network (e.g. VPN/IPSEC,) which complicates deployments. This exact set of issues occurred when Phone systems converged with IP networks. (VoIP)

Network Performance

Bandwidth, Latency, Jitter and Packet Loss are three key areas. RoIP increases network traffic and bandwidth is NOT free. QoS (CoS) ensures available bandwidth under heavy load, but bandwidth has to exist in the first place. In voice applications, jitter and packet loss are important because the audio streams use UDP based protocols. Packets arriving out of order or not at all cause disruptions in the re-assembled audio stream. Buffers and forward error correction help, but if the jitter and loss exceed the buffer's capability, audio is lost. Since the success of a RoIP deployment depends on the network, we need to devise ways to measure the network performance, understand the network requirements and ensure the link meets those requirements.

Availability and Reliability of service. These systems provide vital links between communication systems, which may handle public safety traffic. Adding the IP network into the mix creates another point of failure in the overall system. Radio (i.e. wireless) provides communications between sites which is NOT dependent on the telephone system. RoIP brings this dependency back into the equation. (If the interlinks could be done with IP over Radio, using nodes with emergency power supplies - we can limit this issue somewhat.)

Availability is important in terms of 'liability'. Public safety systems are designed to be 'HA' or high-availability. The standard is 99.99% uptime. If the system goes down, the owners could be held liable for an incident/accident because public safety personnel depend on the system for communications. The other side of the story is that 'something is better than nothing' and that 100% coverage is never guaranteed in a radio system.


There are many different standards. For example, we have Project 25, Wires II, DSTAR, Bridging Systems Interface, IRLP, EchoLink and IAX2/Asterisk. They use SIP, TCP, UDP, RTP, RTCP, etc. and many different CODECS such as IMBE, AMBE, AMBE+2, GSM, uLaw, Speex, etc.

The federal government is committed to Project 25 standards as part of the transformation to digital narrow banding. (12.5Khz and 6.25Khz) The standards have been around for a long time, however, the key standards for interoperability are just beginning to emerge. (Inter Sub System Interface - ISSI) Many vendors have implemented the Common Air Interface (CAI), but the standard allows for proprietary 'features,' which users come to depend on. This means even P25 standards aren't really standard.

Amateur radio has the exact same problem. EchoLink, DSTAR, IRLP and other systems are somewhat proprietary. For example, IRLP requires the use of a proprietary hardware interface. It's easy to understand why this occurs. Systems are competing for market share and controlling the network allows engineers to design towards a known set of constraints. It's important that these systems provide basic hooks into their network to allow them to interoperate at some basic level. (e.g. audio and PTT)

In my estimation, this means gateway technologies are going to be important. I have found at least three vendors that use this approach.

Demo Lab

I created a demo lab to understand how the open source pieces fit together. After surveying the hardware, software and various systems, I settled on the asterisk-based repeater system (app_rpt) and the rtpDir project.

Lab Configuration

Here's how I connected all the pieces together.

  • Here is a drawing of the lab's architecture/configuration: Demo Lab
  • Very simple diagram of how the pieces fit together: Simple Diagram


The app_rpt application uses Asterisk as the foundation. app_rpt is a repeater controller, which can be linked to other similar configurations. It's quite flexible and complicated. Understanding asterisk configuration files is very helpful. It's best to download the ACID CD as a base. (The installation erases everything on the hard drive.) It includes the source code and compiling tools for asterisk.

A major downside is that only two hardware interfaces are available. The PCI card from Tiara uses zaptel hardware from Digium. The PCI card lists for $400 and the Digium HW costs about $100. The other solution uses a modified USB sound FOB. This costs $7 and requires you to crack open the FOB, remove parts and solder wires to surface mounted components. It only works with a FOB based on the CM-108 chip. These FOBs are hard to find. I bought mine from Computer Geeks. DMK Engineering makes the URI, which is a nice alternative. It costs $65 for hams.

The application can reside on the same computer as the rtpDir, but I chose to separate them to see how it worked over a LAN... and eventually over a WAN. Make sure you recompile asterisk using the latest version of app_rpt.c on the rtpDir web site. Otherwise, you won't be able to link to the rtpDir implementation. The symptom is 'digital noise' on the rtpDir radio when transmitting through the Allstar node.

  • app_rpt/Asterisk and rtpDir - assembling the pieces: Architecture
  • Modified USB Sound FOB - this is a USB sound card based on CM-108 chip: Sound FOB
  • DB-9 of the modified Sound FOB - connects to Alinco DR-135: DB-9
  • Interface Schematic for the FOB-Alinco: Schematic PDF

I had several issues to resolve. First, I wasn't sure the USB sound FOB actually worked. I broke the first FOB by prying to hard on the case. The screwdriver slipped and broke of a surface mounted chip. I didn't know this until I photographed the unit for my documentation. Second, I used an Alinco and wasn't sure which pins to use on the DB-9. I ended up using the 9600 baud I/O. The local microphone doesn't work when the Alinco is in the 9600 baud mode, which is a drawback. However, this lets the app_rpt DSP algorithms decode the DTMF signals more reliably. I ended up using a 1K/1K voltage divider on the output. To figure out if the FOB was working, I tested it on another Linux system. (Ubuntu) I playback and record sounds through the Alinco using the sound applications. Once I know the FOB worked, I plugged it back into the computer running ACID.

A couple of notes about usbradio.conf

  • The txctcss lines must be commented out, if you use ctcssfrom=no option.
  • carrierfrom=usbinvert for the alinco
  • set duplex=0 for a simplex base station
  • invertptt=0, I used a NPN transistor for the PTT
  • Turn on debug (radio set debug) to see if COR works

rtpDir Notes

rtpDir functions as an audio bridge, which can link EchoLink, IRLP, DSTAR and app_rpt/Asterisk systems together. The system acts just like an audio conference bridge. That is, when one station transmits, the audio is distributed to all the other connected systems. The configuration files are well documented, but not 100%. So it takes some time to figure them out. Read through the rtpDir mailing list on yahoo for clues, if you get stuck. The guys were very helpful.

I replaced the stock chan_rtpdir.c file in the ACID asterisk source tree with the one from the rtpDir Yahoo site. The directions are in the rtpDir readme file. This was critical for making app_rpt work with rtpDir. I didn't do this the first time and had a bunch of digital hash/noise when the links connected together. This is a clue that you don't have the right chan_rtpdir.c file in app_rpt.

For a local hardware/radio interface, I used the Ultimate Linking Interface (aka ULIBoard from WB2REM) and the TS2K. I bought the ULI several years ago at Dayton and it worked fairly well. However, I eventuallly replaced it with a Microkeyer because it provided a better interface for other operations. (e.g. winkey, CAT, etc.) Here is a picture of the stuff on my bench: ULI and TS2K

Here is the config file, 5198.conf.

Some key config lines to make the ULI board work:

# sound card device indexes.
# Run showcard for correct values.
# rtpDir does NOT check these
# if soundCard is set to no
# linkMode is either ascii(a) or sound(s)

Of course, it didn't work from the start. After many hours of troubleshooting, I discovered an extra 'tab' on the end of my callsign in the 5198.conf file. This kept me from joining the EchoTest conferences. I was able to authentic to the server, but not join the conference. I discovered this by complete accident. Using wireshark (sniffer,) I spotted an out of place 'dot' in the packet trace, which turned out to be a TAB. Incidentally, I tried using the windows version and wasn't able to link the local radio via the ULI interface. So I tried a Ubuntu based system, where I had the problem with the Echolink test. Once I was able to log into the EchoTest server, I didn't go back to the windows version.

The PTT button in rtpDIR does NOT key the local rig as one would expect. To test the local PTT, playback a GSM file. (Control/Playback) You should also be able to record a GSM file via the local radio to test the incoming audio.

Experiments and Capabilities

The following experiments were run to demonstrate the various capabilities of the Demo Lab:

  • Link Alinco simplex radio to Asterisk Controller to form a basic Allstar Node
  • Connect local radio to the rtpDir implementation - provides a local RF path into the bridge
  • Link the Allstar node with the rtp bridge - transport RoIP over the local area network
  • Link the rtp bridge with Echolink and the EchoTest conference - signals transmitted into the linked systems are echoed back to the system, shows echolink connectivity
  • Use DTMF tones on the Allstar node to create and destroy link with rtpDir - the Asterisk server decodes the DTMF tones from the discriminator output of the Alinco
  • Trunk the Allstar node with home PBX - provides incoming and outgoing phone service via the IP network (i.e. this is done on separate PBX servers)
  • Dial into the bridge via the Allstar node - provides telephone connectivity, both RX and TX from phone
  • Added IP based phone, registered with home PBX - phone can be remote, adding another degree of freedom
  • Allstar to phone connection - using DTMF tones on handheld, brought up 'autopatch' feature and dialed internal extension - this could be trunked anywhere

References - Asterisk-based repeater application, uses modified sound FOB (cheap) or PCI board/Digium HW (expensive) - Open source interoperability, home of iaxRpt soft node windows app - Allstar node system, link repeaters together using app_rpt/Asterisk and IAX2 - Realtime Protocol Director, i.e. bridging software, works with echolink, IRLP, DSTAR and app_rpt/asterisk, can use simple HW interfaces - measurement tools - Echolink - bridge between echolink, irlp and asterisk - Internet Radio Linking Project - Interesting views about trunking - look for the ISSI white paper - Good summary of P25 and all the parts - presentation on the testing suite from NIST - Java Application for ISSI testing - USB Dongles to W3 Astro