Xorcom Astribank

The Astribank is a USB channel bank for Asterisk developed by Xorcom.


Astribank vs. Legacy Channel Banks
Astribank vs. PCI Cards
Astribank vs. IP Gateways


Astribank is a revolutionary concept in channel banks for Asterisk systems. Astribank uses USB 2.0 ports to connect to the Asterisk server, eliminating the requirement for PCI (E1/T1) card and even for PCI slots. Astribank comes in various models which are all built of three types of modules: 8 port FXS, 8 port FXO, 1/2/3/4 port PRI, 1/2/3/4 port R2 and 2/4/6/8 port BRI ISDN.
Multiple Astribank units may be used on a single server using either different USB 2.0 ports, or using USB 2.0 hub or USB 2.0 PCI card, to easily create a system with hundreds of analog extensions. Considering its support for MWI (Message Waiting Indicator) in analog phones, it makes an especially practical solutions for large commercial implementations such as hotels. The Astribank 2 models support TwinStar TM for full redundancy of Asterisk-based PBX systems, including all telephony interfaces.


  • Designed specifically for Asterisk systems
  • All Astribank models connect via USB 2.0 - NO T1/E1 card required, NO PCI slot required
  • Flexible configurations based on 8 port FXS/FXO modules, 1/2/3/4 PRI modules, 1/2/3/4 R2 modules and 2/4/6/8 BRI ISDN modules
  • Up to 32 analog ports (FXS/FXO) per single unit
  • Rack-mountable in 19" racks (1U)
  • Supports 110V and 220V power
  • LEDs show status of each channel
  • Easy setup - no need to open panels or shut down server
  • All necessary cables and documentation included
  • Support by Xorcom professional engineers
  • The Astribank driver is part of the official release of Zaptel (DAHDI)
  • Multiple units may be connected via a single USB 2.0 port (using USB 2.0 hub)
  • Supports caller ID
  • Supports TwinStar failover solution for complete Asterisk-based PBX systems, including telephony interfaces
  • Supports MWI (Message Waiting Indication) for analog phones
  • 5 REN ringing generator
  • Up to 6,000 feet line length (1 REN) – 3 REN for 4,000 feet line
  • 2 output ports (relays) enable external units activation from the dial plan (alarm systems, gates etc.) - optional
  • 4 input ports enable automatic dialing triggered by external events (receiving a call when alarm goes off etc.) - optional
  • Automatically detected and configured with Xorcom Rapid

The Astribank is available in various configurations, from 8 to 32 channels, based on the following modules:
  • 8 Port FXS
  • 8 Port FXO
  • 1/2/4 Port PRI
  • 1/2/4 Port R2
  • 2/4/8 Port BRI ISDN

For more information, see the product page at http://www.xorcom.com/products/product-catalog/telephony-interfaces/astribank-usb-channel-banks.


For your convenience, we provide pre-packaged drivers. For full instructions, see http://www.xorcom.com/downloads/astribank-drivers.html. See below for drivers for several Linux distributions.
If you don't use them, see the section on configuration below.

Debian Stable Repository

The packages repository of Xorcom Rapid is compatible with the stable release of Debian (3.1 Sarge). The magic apt to use it is:
deb http://updates.xorcom.com/rapid sarge main

and run:
apt-get update
apt-get install zaptel zaptel-modules-`uname -r`

Debian Etch Repository

The packages repository of Xorcom Rapid also includes packages for Debian 4.0 (Etch). The magic apt to use it is:
deb http://updates.xorcom.com/rapid etch main

and run:
apt-get update
apt-get install zaptel zaptel-modules-`uname -r`

For the moment you may need to answer 'y' to the question regarding using unsigned packages.

TrixBox/CentOS Repository

Note to Windows users: On Windows you can get a free SSH client called putty. To paste text on putty, just click the right mouse button (ctrl+v does not work there as expected).

On this manual, every gray box, is code you should copy from your browser (usually ctrl+c), and then paste into your SSH client.

These commands should be entered in an SSH connection. The username is root, and the password is the password you defined in the installation:

  1. stop asterisk
amportal stop

  1. add new respositories for the Xorcom utilities and drivers:
cat >/etc/yum.repos.d/xorcom.repo << EOF
name=Xorcom RPM Repository for CentOS and RHEL

  1. remove all zaptel modules
rpm -qa | grep zaptel-modules | xargs -l rpm -e || true

  1. install new software, this commands may output a lot of text, and at
  2. the end, you should press "y"
  4. yum install zaptel zaptel-modules-`uname -r` freepbx-module-zapauto -y
yum install freepbx-module-zapauto -y

  1. start asterisk
amportal start

  1. done

Now you should connect the Astribank. After 10 seconds you should see the Astribank light flashing. You will also see that /proc/xpp is populated with information about your hardware, and /proc/zaptel will also be populated.

The next stage is to configure freePBX to recognize the new extensions made available by your Astribank (it depends on the model, but may vary from 12 to 38)

  1. Now on your Trixbox web interface, click on "System Administration" (the default user is "maint" and the default password is "password")
  2. Now click on the "FreePBX" link.
  3. Click on the "Tools" menu on the top right.
  4. Click on the "Module admin" link
  5. In the "Module Administration" page you should enable (at least) the modules "core" and "Zaptel configuration (zapauto)" and submit.
  6. If needed press on the red bar at the top of the screen, and reload the page.
  7. On the "Setup" page, choose the "Zaptel configuration" menu and follow the instructions

With this done you should have all the channels configured, with extension numbers starting from 401. If you get any other problems, see the troubleshooting section, or contact support@xorcom.com .

Other Distributions

  • SuSE - A pending bug report
  • AsteriskNow - Should work as of Beta 5, provided that you install the package fxload.

From Source

This section explains how to build the Xorcom Astribank Zaptel drivers from source (if you have not installed from a binary package above).

The Astribank driver is now part of Zaptel. Either get the the latest zaptel tarball from our site, or get the one from http://asterisk.org .

Note: this applies to Zaptel 1.2 . The current Zaptel 1.4 release (1.4.0) has a slightly older code. If you really need Zaptel 1.4, wait for 1.4.1 or get the code from the subversion.

Extra packages needed:
  • libusb-devel (on Debian: libusb-dev)
  • fxload:
    • in Debian and Mandrake this is a separate package.
    • RHEL4 and CentOS4, Fedora <=4 include it in hotplug-utils, which is normally installed.
    • Fedora >= 5 does not have the package.
  • The perl module Time::HiRes:
    • RHEL, CentOS, Fedora: perl-Time-HiRes
    • Debian: part of the package perl-modules (normally installed)

It should be built according to the standard Zaptel building instructions In addition to that, you should also build and install the userspace tools and files:

  1. if this is zaptel 1.4 or newer:
  1. for every version:
make install
  1. specific to the Astribank:
make -C xpp/utils install

This will also require the libusb development libraries: libusb-dev on Debian, libusb-devel on RedHats (Fedora, RHEL, Centos), and plain libusb on some others (SUSE? Mandriva? fixes, anybody?).

Also note that the default init.d script that is included with the zaptel tarball does not work well. Until this is changed, see the section below regarding the init.d script.

Init Script

Below is an example of the steps required to load the Astribank's drivers. The steps may vary from one system to another, and depend on the distribution, kernel version and other factors. More elaborate example could be found in the init.d script from the Debian package and in the suggested zaptel helper script

  1. Load modules. There are many other ways to do that. Debian and Gentoo
  2. have modules lists file. Most ditsros support hotplugging/coldplugging
  3. (in Gentoo: install coldplug)
  4. No need to modprobe zaptel explicitly.
modprobe xpp_usb
  1. wait for the Astribank initialization to end:
cat /proc/xpp/XBUS-*/waitfor_xpds >/dev/null
  1. If you set zap_autoreg=0, this could be a time to register with zaptel
for zt_reg in `grep -l 0 /proc/xpp/XBUS-*/XPD_*/zt_registration 2>/dev/null`; do
echo 1 >$zt_reg
  1. All spans are now in place. zaptel.conf should now be valid. Time for:

  1. one last thing: set device synchronization:
echo 0 0 >/proc/xpp/sync


genzaptelconf, which is included in the package, will generate more accurate and complete but longer files (e.g: with callerID and mailbox-es) can generate working and valid zaptel.conf and zapata.conf. If you have no experince with writing zapata.conf and zaptel.conf, it is recommended to use it to generate your configuration.

You would still need a valid dialplan. Here is a very simple extensions.conf snippet:

; 401 will dial to channel 1, 420, to zaptel channel 20, etc.
exten => _4XX,1,Dial(ZAP/${EXTEN:1})

; Dial through the first FXO port availble.
; This assumes that all FXO ports are in group 0 and all others are not,
; as in the sample zapata.conf for 8FXS/8FXO below, and as is generated
; by genzaptelconf by default.
exten => 9.,Dial(Zap/g0/${EXTEN:1})

The context of FXS ports
analog phones.
; They are allowed to dial to all other phones
include => phones-zap
; They are also allowed to call through the trunk:
include => trunk-9

; Calls from the PSTN enter here. Redirect calls to an IVR
; or a default extension in the s context here. In this case we
; redirect calls to Zaptel channel 1:
exten => s,1,Dial(Zap/1)

exten => s,1,Set(ZAP_CHAN=Cut(${CHANNEL},-,1))
exten => s,n,Set(ZAP_CHAN=Cut(${ZAP_CHAN},/,2))
; 11 is the number of the first input port. At least in the sample ocnfiguration below.
exten => s,n,Set(INPUT_NUM=Math(${ZAP_CHAN}-11))
; The sample below just logs the signal.
exten => s,n,NoOp(Got signal from input port number ${INPUT_NUM})
; Alternatively:
;exten => s,n,System(run something)

; No. We did not forget the context astribank-outputs. Output
; ports only get calls from the PBX. Thus they don't need a context
; of their own.

Below are some sample configurations:
  • /etc/zaptel.conf:
    • Astribank 8FXS:


    • Astribank 16 8FXS/8FXO


  • /etc/asterisk/zapata.conf
    • Astribank 8FXS:


; The real analog ports:
channel => 1-8

; output ports:
channel => 9-10
; input ports:
channel => 11-14

    • Astribank 16 8FXS/8FXO:


; The real analog ports:
channel => 1-8

; output ports:
channel => 9-10
; input ports:
channel => 11-14

; FXO ports
channel => 15-22

  • /etc/dahdi/init.conf
The astribank defaults to an E1 line type for the PRI. To use a T1, add the following line:

; For all spans:
; Or specify a span:

Manual Trixbox Configuration

Add the following two lines to /etc/sysconfig/zaptel :



genzaptelconf -sdF

Now you can see the list of availble channels using:

cat /proc/zaptel/*

To add an analog extension from the Astribank, use

Add Extension => Zaptel

from the FreePBX setup menu. For the channel name use "Zap/NNN" where
NNN is the number of the channel as seen in /proc/zaptel/1 (expected to
be 1 to 8).

The analog trunk "9" should be configured to ring through the first
analog extension. That group is set in the file (that was generated by
genzaptelconf) /etc/asterisk/zaptel-auto.conf .

Multiple Astribanks

If you have multiple Astribank devices connected to the same system, you would probably want to assure that they are assigned zaptel channel numbers in the order you want, and not in some arbitrary order.

There is currently no complete and perfect solution for that, due to the way numbers are used to address Zaptel channels and spans. However you can get pretty close even when you dynamically plug and unplug devices.

For starters, tell the Astribank driver not to register spans automatically to zaptel. This is done by setting the value of the parameter zap_autoreg to 0 for the module xpp. Normally this is done by adding the following line in your modprobe config file:
options xpp zap_autoreg=0

The file in /etc/modprobe.conf for RedHat/CentOS/Fedora, and any file under /etc/modprobe.d , e.g. /etc/modprobe.d/zaptel.conf for Debian, Gentoo and others.

Once you do that, you can wait for all the devices to load and register them in the order of your choosing. You do not depend on the order in which they appear. This means, however, that you have to explicitly configure the devices at some point. As you need to run ztcfg anyway, this isn't a regression.

But how will you register them in an order that does not depend on the arbitrary plugging order or discovery order? If you look at the file /proc/xpp/xbuses, you'll see see there a field called "CONNECTOR" with a value such as "usb-0000:00:09.2-3". This value only depends on the place in which the USB device is connected. Thus as long as you plug the same device to the same socket, it will remain in the same place.

The devices are registered when you run the zaptel init.d script. We have an init.d script snippet that sorts the unregistered devices by the order of their connectors, and then registers them. See the links (but not the simplistic example) in the section regarding init.d script above.


Build Problems

Only XPP not Built

I build the zaptel drivers with make or make linux26. All other drivers are built. But the Astribbank drivers (under xpp/) are not built.

Currently in Zaptel 1.2 the driver will only be built for i386 and for kernels of versions >= 2.6.10. If your kernel version is < 2.6.10 or a different architecture you'll need to edit the Makefile.
In Zaptel 1.4 or current trunk it is also possible that you have disabled the selection of the xpp driver (xpp_usb) from the kernel drivers selection.

Error Building fpga_load

Do you have USB development libraries installed? libusb-dev, libusb-devel or libusb , depending on your distribution.

If you get an "error" from the "command" o , try running:
make -C xpp/utils HOSTCC=gcc CONFIG_USB=y install

Sound Quality

One possible reason for sound quality issues is that the device uses hos syncronization rather than device syncronization. Try
echo 0 0 >/proc/xpp/sync

When all's well:

See README.Astribank for a rather detailed installation procedure.

Error Messages

Always Last Span

I have a system with an Astribank and some other Zaptel hardware. Why do you recommend that the Astribank module will be loaded after all the other zaptel drivers?

We generally recommend that you place the xpp drivers last. The reason for that is that the span that the Astribank driver registers is not registered immediatly at the time of the module loads:

At module load time only basic initialization of the module is done. The later parts of the initialization, as well as registering the span to zaptel, takes some extra time. Thus if you modprobe xpp_usb and immediately after that load the module wct4xxp for a Digium T1 card, the order of the zaptel span is not well-defined and may change unexpectedly.

Inputs and Outputs

In addition to the standard 8 phones, you get 6 extra channels (2 outputs, 4 inputs). They generate normal zaptel channel:

$ cat /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS"

1 XPP_FXS/0-0
2 XPP_FXS/0-1
3 XPP_FXS/0-2
4 XPP_FXS/0-3
5 XPP_FXS/0-4
6 XPP_FXS/0-5
7 XPP_FXS/0-6
8 XPP_FXS/0-7
9 XPP_OUT/0-8
10 XPP_OUT/0-9
11 XPP_IN/0-10
12 XPP_IN/0-11
13 XPP_IN/0-12
14 XPP_IN/0-13

Wiring of Ports

The 8 phone ports are all RJ11 sockets. These are normal RJ11 ports, which use the middle two pins (3+4). The astribank is immune to polarity swap, in case your wiring inverts the two.

The output ports can switch up to 220v each, at 2A. Full details are given at http://www.xorcom.com/application-notes/using-astribank-to-open-doors.html

The input ports are activated by dry switches, and shouldn't have any additional power sources added to them. Full details are given at http://www.xorcom.com/application-notes/astribank-for-burglar-alarms.html

The /proc/xpp Interface

In addition to the procfs entry generated by zaptel under /proc/zaptel , the Astribank driver generates its own files under /proc/xpp . Most of them provide information. Some of them are writable and allow control by the user. I'll try to document here just information that is important to the user. There is more ddebugging information here which I for the moment not document for the sake of the reader's sanity.

Note that this interface is still subject to changes.
$ ls -l /proc/xpp/
dr-xr-xr-x 3 root root 0 2006-03-16 05:15 XBUS-0
-rw-r--r-- 1 root root 0 2006-03-16 05:15 sync
-r--r--r-- 1 root root 0 2006-03-16 05:15 xbuses

/prox/xpp/sync is a writable file. Reading it can be used to tell the current timing source (Astribank or host). Writing to it can set the value. Generally for faxes to work well you need device synchronization.

$ cat /proc/xpp/sync
  1. To modify sync source write into this file:
  2. HOST - For host based sync
  3. 0 0 - XBUS-0/XPD-0 provide sync
  4. m n - XBUS-m/XPD-n provide sync
tick: #172894848
tick rate: 1000/second (average over 10 seconds)

The 'xbuses file is a list of Astribank devices. The value of "CONNECTOR" will generally tell you where the device is connected in the USB devices tree, which will generally not change if you don't add/remove a USB hub. So it can be used to tell the USB port the Astribank is connected to. See more on the STATUS later.

$ cat /proc/xpp/xbuses
XBUS-0: CONNECTOR=usb-0000:00:10.4-2 STATUS=connected bus_type=2
  1. ls -l /proc/xpp/XBUS-0/
dr-xr-xr-x 2 root root 0 Mar 16 05:19 XPD-0
-r--r--r-- 1 root root 0 Mar 16 05:19 summary
-r--r--r-- 1 root root 0 Mar 16 05:19 xpp_usb

Those two files have some debugging information regarding the USB connection. Let's look into the XPD directory:

$ ls -l /proc/xpp/XBUS-0/XPD-0/
-r--r--r-- 1 root root 0 Mar 16 05:29 fxs_info
-rw-r--r-- 1 root root 0 Mar 16 05:29 slics
-r--r--r-- 1 root root 0 Mar 16 05:29 summary
-rw-r--r-- 1 root root 0 Mar 16 05:29 zt_registration

The file "summary" is full of per-extension status information. Have a cat. However we have more interesting things to look at now: two more writable files here. Yey! Let's examine them:

$ cat /proc/xpp/XBUS-0/XPD-0/slics
  1. Writing bad data into this file may damage your hardware!
  2. Consult firmware docs first
SLIC_REPLY: D reg_num=0x0, dataH=0x0 dataL=0x0

We mean that!

As for zt_registration: writing 1 there attempts to register that "XPD" as a Zaptel span. This should always work. Writing 0 should attempt to unregister the device. Thous should work if Asterisk is not using the extensions.

Adding and Removing

Now what would happen if I unplug and replug a device?

Asterisk Not Running

If Asterisk wasn't running: no problem. All's well:
Before unplugging:
$ head -n 4 /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS"


Unplugging: nothing under /proc/zaptel and /proc/xpp/xbuses is empty.

Plugging back:
$ cat /proc/xpp/xbuses
XBUS-0: CONNECTOR=usb-0000:00:10.4-2 STATUS=connected bus_type=2

$ head -n 4 /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS"

1 XPP_FXS/0/0/0
2 XPP_FXS/0/0/1
$ cat /proc/xpp/sync
  1. To modify sync source write into this file:
  2. HOST - For host based sync
  3. 0 0 - XBUS-0/XPD-0 provide sync
  4. m n - XBUS-m/XPD-n provide sync
tick: #174658987
tick rate: 1000/second (average over 10 seconds)

You only need to run ztcfg...

$ ztcfg
$ head -n 4 /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS"


And set the sync source back to the device: (note the space after the second '0')
The built-in echo of bash fails to print error messages if there are any.

$ /bin/echo 0 0 >/proc/xpp/sync
$ cat /proc/xpp/sync
  1. To modify sync source write into this file:
  2. HOST - For host based sync
  3. 0 0 - XBUS-0/XPD-0 provide sync
  4. m n - XBUS-m/XPD-n provide sync
tick: #180507
tick rate: 1000/second (average over 10 seconds)

With Asterisk Running

Before unplugging:
$ head -n 4 /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS"

1 XPP_FXS/0/0/0 FXOKS (In use)
2 XPP_FXS/0/0/1 FXOKS (In use)

Unplugging the device. At this point there is no USB device. However Asterisk has open channels and we can't easily persuade it to close the channels/span. Thus we keep the zaptel span and the XPD:
$ head -n 4 /proc/zaptel/1
Span 1: XBUS-0/XPD-0 "Xorcom XPD #0/0: FXS" NOTOPEN

1 XPP_FXS/0/0/0 FXOKS (In use)
2 XPP_FXS/0/0/1 FXOKS (In use)
$ cat /proc/xpp/xbuses
XBUS-0: CONNECTOR=usb-0000:00:10.4-2 STATUS=missing bus_type=2

If we try to unregister, we get the error number telling us that the device is busy. Unregistration now is not possible as long as Asterisk uses the device:
$ /bin/echo 0 >/proc/xpp/XBUS-0/XPD-0/zt_registration
/bin/echo: write error: Device or resource busy

If you stop Asterisk now, that span will be freed. And you could continue with the procedure from the previous section. However if you plug it back before Asterisk was started, a second span will be created:
$ cat /proc/xpp/xbuses
XBUS-0: CONNECTOR=usb-0000:00:10.4-2 STATUS=missing bus_type=2
XBUS-1: CONNECTOR=usb-0000:00:10.4-2 STATUS=connected bus_type=2
$ ls /proc/zaptel
1 2
$ head -n 4 /proc/zaptel/2
Span 2: XBUS-1/XPD-0 "Xorcom XPD #1/0: FXS"

16 XPP_FXS/1/0/0
17 XPP_FXS/1/0/1
As you can see, the second "device" is actually connected. And is connected to the same connector the previous device was connected to.

We can't just use the new channels, as our zaptel/zapata configurations know them with the previous numbers. Thus asterisk will fail to start at this point if it were stopped. What can we do? stop asterisk to release the span, unregister the second span from zaptel and reregister it. It will be registered as span 1 and all will be well:

/etc/init.d/asterisk stop
/bin/echo 0 >/proc/xpp/XBUS-1/XPD-0/zt_registration
/bin/echo 1 >/proc/xpp/XBUS-1/XPD-0/zt_registration
echo 1 0 > /proc/xpp/sync
/etc/init.d/asterisk start

Or, if we were to generalize it:

/etc/init.d/asterisk stop
  1. unregister and re-register all XPDs to start from span 1:
for reg in /proc/xpp/*/*/zt_registration; do /bin/echo 0 >$reg
for reg in /proc/xpp/*/*/zt_registration; do /bin/echo 1 >$reg
  1. find the first XPD and sync from it:
bus=`awk -F: '/STATUS=connected/{print $1}' /proc/xpp/xbuses | head -n 1| cut -d- -f2`
/bin/echo "$bus 0" >/proc/xpp/sync
/etc/init.d/asterisk start


We have some patches that were submitted to Zaptel and/or Asterisk. Intended to make Zaptel/chan_zap easier to use and more hot-pluggable.


#6955 . Allows completely changing the configuration of zaptel channels without restarting Asterisk (but disconnects all currently running calls on Zaptel channels). This should make the plugging part of hotplugging much easier: you no longer need to restart asterisk.

Status: Accepted into trunk and will be included in Asterisk 1.4 . 1.2


#7256 . This patch defines a zaptel event called ZT_EVENT_REMOVED . When sent for a channel, Asterisk is asked to release that zaptel channel. This should allow a hardware driver to disconnect hardware. With this patch, the unplugging part of hotplugging becomes easier.

The bug report has a trivial patch to zaptel.h that defines that event, a patch for asterisk trunk and a patch for asterisk 1.2.

Status: Zaptel part of the patch was merged into Zaptel 1.4. Latest Astribank drivers (zaptel/xpp/ , as of 1.2.7) send ZT_EVENT_REMOVED upon disconnecting. The Asterisk part of the patch is still pending review.


#7613 . This patch avoids the need to run ztcfg from userspace for analog spans. It does so using a rather simple hueristic to separate analog spans (for which there is a decent default) from digital ones (for which there is none).

Status: experimental. While I like this patch, it has not seen much review, and is a bit too disruptive to get in before 1.4.


XPP here does not stand for X Printing Panel, XML Pull Parser,
X-Windows Phase Plane or XML Professional Publisher. It is simply the
Xorcom Peripheral Protocol, which connects a computer to a XPD (Xorcom
Peripheral Device)

See also



For more information:
Asterisk Solutions

See also

Created by: tzafrir, Last modification: Thu 01 of May, 2014 (10:08 UTC) by rbridger
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+