Asterisk Digium Zaptel Hardware TDM Configuration Tweaks
Warning! Warning! Warning
This page is mostly technical details. If this is not for you then
we suggest you read one of our other articles on Telephone and VOIP technology.
The tips and patches provided here are provided "as is" with no warrantee of
any kind. Follow this guide at your own risk. Use common sense.
Smart people make backups.
I won't claim that this is the best or the only way to do things.
However, these steps got our office phone system working nicely
with Digium Zaptel hardware with the Asterisk PBX.
Please note that there are still SERIOUS problems with this card and/or the
various software that interact with it. After a lot of tweaking most of the
problems can be resolved or ignored. However, the fact that ring groups can put
an incoming call into limbo hasn't been resolved.
Anyone who can help me resolve this problem will be my hero. :)
Our Office Setup
Our Asterisk server has two Digium TDM400P cards. Each card has two FXO and
two FXS modules each. In Digium speak we have two "TDM22B" models.
If you want read more about the JEB Office Asterisk Server you can do so
Physically Install the Cards
This is pretty straight forward.
- Shut down your PC
- Pop open the case
- Deal with removing all the bad karma and static from your body.
Typically I just touch the metal frame of the computer case.
I try to avoid shuffling my feet on the rug, petting your fluffy pet, or other static generating activity.
- Turn off the power supply, but leave it plugged in. Wait thirty seconds. Most computers have a light inside the computer case that turns off when the power is really off.
- Insert TDM22B cards
- Connect a power connector to each card. This is necessary or the card will not work!
- Boot the PC
Ensure You have a Dedicated IRQ for each card!
Digium TDM cards should not share IRQs.
You can check for IRQ sharing by running the command: cat /proc/interrupts. Another useful command is lspci -v.
What can you do if the TDM cards are sharing interrupts? Try the following:
Check Motherboard PCI version
Asterisk will run on just about any hardware.
However, Digium cards need a PCI 2.2 version slot.
If the green lights on the back of the card don't ever turn on,
or the card isn't detected by kudzu or genzaptelconf try
Our test Celeron 700MHz machine ran Asterisk perfectly, but was
incompatible with the Digium cards. Switching to a system with a
newer Asus A7V8X-X motherboard solved the problem.
If you are using TDM cards then you should not be using the ztdummy device. A clue that you are using ztdummy is that cat /proc/interrupts will show a high number of interrupts on a USB device that's constantly increasing at the same rate as your zaptel interrupts are being triggered.
Disabling ztdummy will eliminate 1,000 extra interrupts a second.
Issues with genzaptelconf
Overall genzaptelconf is a great idea. However,
the default "genzaptelconf" from Asterisk@home 1.0 has a few flaws
due to bad assumptions.
Symptoms may include one or more of the following
- An extension on a second TDM22B card can answer a call, but not dial out.
- Running the "zap show channels" command from the asterisk console doesn't correctly
show "from-pstn" and "from-internal" correctly for extensions and incoming lines.
- Extensions and incoming lines are both thrown into the same group=0 (g0) group
- From the shell running "ztcfg -v -v" doesn't match the zap Show Channels results from the asterisk console.
- An incoming call with callerid blocked will show the callerid of your last defined zap extension instead of "unknown caller". This also affects the CDR logs.
- One TDM card worked great, but extensions on the second one don't work properly.
Most of the problems arise from assuming default values. When a value is set these
channel settings falling through to the next channel. This may pass incorrect
settings to subsequent channels.
Any fxs_ks implicitly gets set for a "from-pstn" context ...but doesn't revert back to "from-internal" for any fxo_ks.
This means if you have an extension defined after an incoming line (e.g. the first port on your second TDM22B) it will
default it to an incoming line!
Also, both extensions and incoming lines are tossed together into group 0.
This can screw up your dialing rules. My original hack was to create a trunk for Zap/3 and Zap/4 and have
all my routes use both trunks. However, not having a proper g0 route
makes more difficult to generate dial plans and shell scripts that dial out on the first available lines.
My /usr/local/sbin/genzaptelconf Fixes/Tweaks/Features
You can try my patched /usr/local/sbin/genzaptelconf.
This is experimental. Use at your own risk. It works for us, but my fixes may break some other assumption
that you are relying on just as badly as the original bad assumptions broke my configuration. :)
Sadly, sometimes you'll find that your local phone company provides extremely poor service. Sadly mine can't properly install a new phone line. Four months later and they still screwing something up six ways to Sunday.
Fortunately, there's Vonage. Read how I got a new Vonage line up and running in five easy steps.
Download the Patched Script
Here's the script: /usr/local/sbin/genzaptelconf.
Right click on the link and do a save-as.
I got ahold of the original author of genzaptelconf. He said that Asterisk@home
included an older version of his script. Versions of Asterisk@home after 1.5 do include
this revised script.
However...you still have to do a small 1 line mod to /etc/asterisk/zapata.conf for it to work.
Here's the genzaptelconf link: