Compiling Zaptel

Figure 3.3, “Layers of device interaction with Asterisk” shows the layers of interaction between Asterisk and the Linux kernel with respect to hardware control. On the Asterisk side is the Zapata channel module, chan_zap. Asterisk uses this interface to communicate with the Linux kernel, where the drivers for the hardware are loaded.

Figure 3.3. Layers of device interaction with Asterisk

Layers of device interaction with Asterisk

The Zaptel interface is a kernel loadable module that presents an abstraction layer between the hardware drivers and the Zapata module in Asterisk. It is this concept that allows the device drivers to be modified without any changes being made to the Asterisk source itself. The device drivers are used to communicate with the hardware directly and to pass the information between Zaptel and the hardware.


While Asterisk itself compiles on a variety of platforms, the Zaptel drivers are Linux-specific—they are written to interface directly with the Linux kernel. There is a project at that provides Zaptel support for Solaris. There is also a project that is working to provide Zapata drivers for BSD, located at

First we will discuss the ztdummy driver, used on systems that require a timing interface but that do not have hardware. Then we will look at compiling and installing the drivers. (The configuration of Zaptel drivers will be discussed in the next chapter.)


Before compiling the Zaptel drivers on a system running a Linux 2.4 kernel, you should verify that /usr/src/ contains a symbolic link named linux-2.4 pointing to your kernel source. If the symbolic link doesn’t exist, you can create it with the following command (assuming you’ve installed the source in /usr/src/):

# ln -s /usr/src/'uname -r' /usr/src/linux-2.4   

Computers running Linux 2.6 kernel-based distributions do not usually require the use of the symbolic link, as these distributions will search for the kernel build directory automatically. However, if you’ve placed the build directory in a nonstandard place (i.e., somewhere other than /lib/modules/ <kernel version> /build/), you will require the use of the symbolic link.

While Asterisk and the other related packages run on Linux 2.4.x kernels, development is done first and foremost on 2.6.x kernels and support for 2.4.x kernels is not guarenteed in the future.

The ztdummy Driver

In Asterisk, certain applications and features require a timing device in order to operate (Asterisk won’t even compile them if no timing device is found). All Digium PCI hardware provides a 1 kHz timing interface that satisfies this requirement. If you lack the PCI hardware required to provide timing, the ztdummy driver can be used as a timing device. On Linux 2.4 kernel-based distributions, ztdummy must use the clocking provided by the UHCI USB controller.


Many older systems (and some newer ones) use an OHCI USB controller chip, which is incompatible with ztdummy. However, if you’re using a 2.6 kernel there is no need to worry about which USB controller chip your system has.

The driver looks to see that the usb-uhci module is loaded and that the kernel version is at least 2.4.5. Older kernel versions are incompatible with ztdummy.

On a 2.6 kernel-based distribution, ztdummy does not require the use of the USB controller. (As of v2.6.0, the kernel now provides 1 kHz timing[46] with which the driver can interface; thus, the USB controller hardware requirement is no longer necessary.)

The Zapata Telephony Drivers

Compiling the Zapata telephony drivers for use with your Digium hardware is straightforward; however, the method employed between the 1.2 and 1.4 versions is slightly different due to the new build environment. First we need to run ./configure in order to determine what applications and libraries are installed on the system. This will ensure that everything Zaptel needs is installed. The following commands will build Zaptel and its modules:

# cd /usr/src/zaptel-version
# make clean
# ./configure
# make menuselect
# make
# make install   


While running make clean is not always necessary, it’s a good idea to run it before recompiling any of the modules, as it will remove the compiled binary files from within the source code directory. You can also use it to clean up after installing if you don’t like to leave the compiled binaries floating around. Note that this removes the binaries only from the source directory, not from the system.

In addition to the executables, make clean also removes the intermediary files (i.e., the object files) after compilation. You don’t need them occupying space on your hard drive.

If you’re using a system that makes use of the /etc/rc.d/init.d/ or /etc/init.d/ directories (such as CentOS and other Red Hat-based distros), you may wish to run the make config command as well. This will install the startup scripts and configure the system, using the chkconfig command to load the zaptel module automatically at startup:

            # make config


The Debian equivalent of chkconfig is update-rc.d.

While Digium only officially supports Zaptel on Linux, several projects to port Zaptel to other platforms should be noted:

Using ztcfg and zttool

Two programs installed along with Zaptel are ztcfg and zttool. The ztcfg program is used to read the configuration in /etc/zaptel.conf to configure the hardware. The zttool program can be used to check the status of your installed hardware. For instance, if you are using a T1 card and there is no communication between the endpoints, you will see a red alarm. If everything is configured correctly and communication is possible, you should see an “OK.” The zttool application is also useful for analog cards, because it tells you their current state (configured, off-hook, etc.). The use of these programs will be explored further in the next chapter.


The libnewt libraries and their development packages (newt-devel on Red Hat-based distributions) must be installed for zttool to be compiled.

The ztcfg and zttool applications, along with other useful utilities, are located under the Utilities section of the Zaptel menuselect screen.

[46] Note that this is configurable in the kernel, so it is possible certain distributions may not have this set to 1,000 Hz; CentOS, however, does have this set at the correct frequency.