Using the Asterisk PBX as a multi-port and linked Repeater Controller
By Steve Rodgers, WA6ZFT and Jim Dixon, WB6NIL
Edited by Mike Morris WA6ILQ and Kevin Custer W3KKC

This article describes the Asterisk app_rpt application, and how can be used to link repeaters together over the Internet.

Asterisk is a PBX system that is Linux based, very popular, and incidentally is open-source. When you think about it, a PBX is at it's core an audio switching system. The Asterisk hardware and software platform, being open source, offers a way to add additional audio sources and destinations to a working system.

The 'app_rpt' application turns the Asterisk system into a very flexible and powerful repeater controller capable of controlling one to a dozen or more separate repeaters, links and remote bases separately and simultaneously at the same physical site. In addition, it supports full duplex linking from one Asterisk site to another, autonomous remote bases (more on this later), and a VOIP autopatch. Our solution employs telephony hardware (not sound cards) to achieve this multi-port operation in a flexible and efficient manner.

All software and hardware designed in the project is licensed under the GNU Public License (GPL). Basically, this means the software and hardware designs are open source and may be used by anyone provided the terms of the GPL are followed. Releasing the design in this form allows a user community to cooperate and help each other by sharing their bug fixes and improvements with other users. For details on the GPL, visit

The Asterisk Project

The Asterisk PBX project ( is an open source soft PBX which supports traditional TDM (Time Domain Multiplexed) telephony hardware as well as the new VOIP (Voice Over Internet Protocol) standards. Both technologies can be intermixed and used together. Asterisk runs under Linux ( Extensive documentation on Asterisk can be found at

Asterisk uses the concept of 'channels' to describe connection endpoints (e.g. a telephone set or a telephone line). Channels are 'bridged' to establish a connection from one endpoint to another. Asterisk handles call routing, and codec translation (transcoding) between channel types.

Hardware Interfacing:

Within the Asterisk software channels described by a technology name. For example channels derived from TDM equipment are named 'Zap', and those derived from IAX are named 'Iax'. For the repeater linking application you only need to use two channel types: Iax and Zap.

Zap channels used in the repeater linking application are assigned to FXS (foreign exchange station) hardware interfaces. FXS interfaces look like a CO (central office) line, and provide DC battery to power the telephone set. There are currently two accepted ways of adding FXS channels to your Asterisk PC platform.

As mentioned above, Zap channels interface to TDM hardware. The physical connection from Asterisk to your repeater is done using 2 zap FXS channels for each repeater you need to interface. One of the Zap channels is for transmit and will be called the 'TX pair', and the other will be for receive and will be called the 'RX pair'. This is known in the telecom industry parlance as a '4-wire' interface.

The TX and RX pairs are connected from the FXS hardware interface to the ARIB (analog radio interface board). The ARIB is available in board blank form from the source at the end of this article. The ARIB converts the 4-wire connection to COR, PTT, PL, TX-audio and RX-audio to facilitate connection to your repeater. An example of a system with one repeater is shown in figure 1 below:

When we configure Asterisk for use as a repeater controller, we set up the configuration files zaptel.conf and zapata.conf with the type of signaling to be used by a given channel. For the RX channel or RX pair, we use loop start signaling. For the TX channel or TX pair we use ground start signaling. The reasons for this are:

When Asterisk wants to key the repeater transmitter, it places battery on the TX pair.

This is sensed by the ARIB which results in the repeater transmitter PTT being activated. Ground start signaling fulfills this need, as the FXS interface in the PC is the only side capable of providing battery.

When the repeater receiver senses a signal, and activates the COR and/or PL signals, the ARIB closes the loop on the RX pair. This causes a current to flow in the RX-pair which is sensed by the FXS interface as an off-hook condition. The off hook condition is then passed to the Asterisk repeater application where it is handled and processed.

Whenever there is a DC current flowing in the TX and RX pairs, AC audio is usually riding on top of this DC current. This audio is picked off of the TX pair and inserted on the RX pair by the ARIB using transformer isolation. The ARIB also contains op-amps and level pots to tailor the transmit and receive audio levels. Optional de-emphasis is available for the receive audio path.

Multiple repeaters at the same site:

Networking Multiple Asterisk Repeater Systems:

(text to be written)

(text to be written)

Adding an Autopatch:

(text to be written)

Adding a Remote Base:

A remote base (sometimes mistakenly called a link) is a simplex radio that is used to talk to another system (as a user radio).

(more text to be written)

Adding a Link radio:

A link (sometimes called a point-to-point link) is a full duplex (or sometimes a simplex) radio that is used to talk to a matching link port on another system (sometimes called a "backbone link").

(more text to be written)

Building Asterisk with app_rpt support:

For this step, you are going to need a PC with Linux installed, so if don't have the PC staged with Linux you are going to use as your repeater controller, now would be the time to go off and get a suitable PC, and install Linux on it. The developers have had good results with Red Hat Linux 9 and 800MHz or faster PCs. If you use slower PCs or other Linux distributions, your mileage may vary. Make sure the PC has enough slots for your Digium card(s) and at least 1 Ethernet port. When installing Linux, be sure to install the development system (Binutils, Gcc) plus Gdb, Make, M4, Automake, Autoconf, Flex, Bison, CVS, OpenSSL, and OpenSSH.

Configuration Files:

There are 5 asterisk configuration files which are site-specific and will need to be modified. We provide full information on each file and its contents plus sample files.

DTMF Command Scheme:

The app_rpt Asterisk application provides a very flexible way to define DTMF command sequences. The flexibility has been specifically designed to allow different function subsets on different ports. This would allow the local repeater to have full control and a link port to have some control, and a remote base port to have no control rights. The DTMF command scheme is defined in one of the configuration files.

The Allstar Link System:

(text to be written)

Frequency agile HF remote base support

Efforts have concentrated (so far) on the Yaesu FT-897, only because the developers have one. Other manufacturers and models may be supported in the future.

Digital Radio Interface:

This is a PCI card capable of controlling 4 radios simultaneously without having to use the ARIB and Digium FXS or T1 hardware and channel bank. There will be a new channel driver written for Asterisk to support this hardware. Note that the four ports are NOT dedicated "repeater" ports, they are generic radio ports and can be configured to be any combination of repeater, remote base, duplex link, simplex link, or whatever.


The developers use a linux distribution called 'Limey Linux' on their test bed systems and personal repeater (software and hardware development is done on more standard systems). 'Limey Linux' is a micro-Linux distribution with known good performance with Asterisk and app_rpt, and is available with both pre-installed. The distribution fits on a 32MB compact flash and has Asterisk, OpenSSL, OpenSSH, the Development system, and start up scripts to allow a 'diskless' system to be created. Ours runs on a Via ME6000 Mini-ITX motherboard with 256MB of RAM.


Hardware Sources:

The following is an explanation of DAHDI by Jim Dixon WB6NIL. It is presented here with his express written consent:

DAHDI (previously Zaptel, also/originally Zapata Telephony technology) is/was the hardware/software/systems implementation that allows Asterisk to interface with physical telephony interfaces, provide functionality in software essential to traditional telephony (whereas previous, hardware-implemented designs did this in rather expensive hardware), and, probably most-important to the "radio" type uses of Asterisk, provides synchronization, routing, and combining (conferencing) of audio streams within the system. So, it is essentially an interface between the "physical" "telecom" world, and the "computer" world.

Asterisk is the "computer world" part of the system. It provides "call-level" telecom functionality (call switching, call routing, voice interaction, application interface, logging, etc), in addition to audio-stream-level interface and functionality for computer-related voice transport (such as VOIP). Since Asterisk has good application support, it was easy to make it a REALLY good platform on which to implement radio control, since it had nearly all of the characteristics necessary to do so inherently, and was not difficult to add what it lacked.

LibPRI is a protocol library for for Primary rate ISDN telecom services. It was included mainly for completeness. I seriously doubt that anyone that initially implemented a radio system has much use for this, but trust me, several people that initially implemented telephone switches using my distro and THEN decided to put a radio interface or two on it, were certainly happy I did it this way. Obviously, LibPRI is not needed for a purely "radio" environment.

Zaptel (as mentioned above) was the previous name of DAHDI (don't blame me!! I didnt come up with EITHER of these names!!)

Jim WB6NIL "Daddy of DAHDI" -- As I was called by Mark Spencer circa 2008 (while at an Astricon)

P.S. I cant tell all of you how tempted I was to answer more like this:

DAHDI - Counterpart of the "MAHMI" technology. Once together, DAHDI and MAHMI spawned a number of derivative technologies, such as "SONNI". Sadly, DAHDI and MAHMI don't functionally inter-operate well anymore, and, as you might imagine, SONNI, now requiring two distinct interfaces (one for DAHDI, one for MAHMI), sometimes has interface "issues". :-) :-) :-)

Sadly, Jim Dixon WB6NIL died in December of 2016 of CHF. He is very much missed - - W3KKC