Asterisk zaphfc


Note: Using bristuff breaks PRI support, so you cant have both bri and pri in the same server.
However a user reports: "We are using Asterisk 1.0.7-BRIstuffed-0.2.0-RC8a with a Digium PRI card an a beroNet quadBRI
in one server and it's running perfecty for months. It depends only on the order the modules are loaded
(/sbin/modprobe zaptel, insmod qozap.ko, insmod wcte11xp.ko - in this order)."

If compared to a CAPI driven card a hfc-pci card provides your box with NT mode, zaptel timing and echo cancelation.

When multiple devices are connected to the ISDN connection, then all user device behave as slaves, where the network terminator (NT) behaves as master and synchronizes the communication on the S0 bus. The special behavior of the network terminator is called NT mode. User devices are normally not capable of running in NT mode. As a result, user devices can not communicate with each other even when they are connected via a crossed cable. Only some special ISDN cards (HFC chipset) are capable of running in NT mode, and can directly communicate with other ISDN user devices using a standard Ethernet cable (not crossover - TE and NT ports have the TX and RX pins switched already).

Recent versions:

Note Junghanns do NOT keep links on the front page up to date ... always check the downloads directory for the latest versions.

Mar 2010: As you may have noticed zaphfc is now named Asterisk vzaphfc, a complete rewrite of zaphfc (but still called zaphfc for compatibility reasons). This module is meant to work with cheap ISDN (BRI) cards based on the HFC chipset made by Cologne Chip. The code probably never moves to DAHDI cause of marketing reasons by Digium.
vzaphfc is reported to run stable on some productive systems (x86 and x86_64).
See DAHDI hfc-s with vzaphfc Howto for Asterisk 1.6 and Asterisk & HFC-Karten unter Gentoo also.

Feb 2010: Nowadays (as of Asterisk 1.6.0) BRI support is included in Asterisk. The zaphfc driver, though, is still not included in DAHDI. It's maintained, though. The version included in the Debian packages is taken from;a=summary. Those are basically the same ones from, and the same ones in packages from Elastix and Debian.


(I believe that this is solved on bristuff 0.3.0-PRE1o. Can anybody please update the page? Tzafrir)

If you experience problems forwarding the incoming caller-id to internal phones, you probably forgot setting callerid=asreceived in your zapata.conf. Otherwise, add a SetCIDNum in your dialplan,i.e.
exten => 444555544,1,SetCIDNum(0${PRI_NETWORK_CID})
exten => 444555544,2,Dial(SIP/123)

The above example, assigns the network provided callerid to the internal Caller ID field. A Zero is prefixed as it is nescessary for dialing out.

Meanwhile, there are one fork and one patch improving the driver in several ways:

  • The patch from Florian Zumbiehl:
    • Interrupt loss tolerant b channel handling (see below).
    • Support for the slave mode of the chip, enabling the cards to run completely in sync.
    • "Interrupt bundling" greatly reduces the driver's CPU usage with several cards in the system.
  • The fork from Daniele Orlandi:
    • not maintained anymore; instead see Asterisk vISDN
    • Interrupt loss tolerant b channel handling (see below).
    • Sniffing capability, so you can examine ISDN packets using a patched ethereal.

They have been created independently and both improve the b channel handling to be more tolerant to lost/delayed interrupts (which is a big problem with the original driver if you have more than one card, a card sharing interrupts, or any major concurrent load on the system). The other improvements are quite different, though, which is why they are both listed here for you to choose. They might be merged someday, but until then you will have to choose one of them.

For hfc install instructions see:

Setting up hfc cards for NT mode:

Q: Do I need to use a special kind of wire, is a NT1 (also called ntba or network termination device) needed for termination / powersupply between the card and a phone?

A: It depends. If the device(s) you want to connect have their own power supply, such as PBXes, you usually won't need an NT1 for power supply. Otherwise, use an hfc-s based card that does power the line (usually with an external power supply such as BNPW1). With an another card, just follow the documentation at to wire up your card, your NT1 and your phone equipment. Of course, you always need termination - which can be done without the need for an NT1, though.

In order to connect a telephone directly to a card, you need to:
  • terminate the S0-bus by using resistors, no matter how short the cable is.
  • provide power feeding to the telephone, if it does not supply it's own power.
  • cross link the ports, because the card receives what the telephone sends and vice versa.
All this can be done easily by using an old NT1. Here is an easy way on doing it:
  • Take an ISDN cable and cut it in the middle. On each side of the cabe there is an RJ-45 plug. The middle pair (4 and 5) must be connected with the surrounding wire pair on the other side (3 and 6) and vice versa.
  • Add 2 100 ohm resistors to the wires. One to the first pair (connected to 4 and 5) and one to the second (connected to 3 and 6).
  • Use an old NT1 if you don't have an own power supply. U could even use a somehow broken NT1, as long as the power feeding function is still working.
NOTE: Ethernet cross link cables don't work, because they use different pairs than ISDN S0 does.

Plug one end of your new cross link cable to your ISDN card that should run in NT-Mode, and one to your telephone. If your telephone set needs external power, connect an old NT1 to your ISDN card using the cross link cable, and your telephone with a NORMAL ISDN (or Ethernet/straightthrough wired) cable to your NT, using the second plug.

For a "cleaner" method please consult chapter 2.2 of this guide from

To load the card in NT1 mode you'll need to set the 'modes' option when loading the driver:

insmod ./zaphfc.o modes=1

or if you have more cards (example: two) you can use

insmod ./zaphfc.o modes=1 #(binary: 0 1) card0: NT mode, card1: TE mode
insmod ./zaphfc.o modes=2 #(binary: 1 0) card0: TE mode, card1: NT mode
insmod ./zaphfc.o modes=3 #(binary: 1 1) card0: NT mode, card1: NT mode
and so on

Note that when using more than one card, the module will segfault when unloading:

  zaphfc: stop
  zaphfc: shutting down card at e0962000.
  unregistered from zaptel.
  zaphfc: freed one card.
  zaphfc: shutting down card at 00000000.
  Unable to handle kernel NULL pointer dereference at virtual address 0000006c
  printing eip:
  *pde = 00000000
  Oops: 0002
  CPU:    0
  EIP:    0010:[<e095d086>]    Tainted: P 
  EFLAGS: 00010082
  eax: 00000000   ebx: 00000282   ecx: dcc0a000   edx: dcc0bf7c
  esi: d5d5d5d5   edi: 00000000   ebp: bfffea58   esp: df4e5f64
  ds: 0018   es: 0018   ss: 0018
  Process rmmod.modutils (pid: 26999, stackpage=df4e5000)
  Stack: e095e660 00000000 d5d5d5d5 00000286 c15efa60 d5d5d5d5 d5d5d5d5e095e58a 
       d5d5d5d5 e095d000 fffffff0 c011caea e095d000 e095d000 fffffff0 da4b9000 
       c011be8f e095d000 00000000 00001000 df4e4000 00000001 0806fb00 c01090df 
  Call Trace:    [<e095e660>] [<e095e58a>] [<c011caea>] [<c011be8f>] [<c01090df>]

  Code: c6 40 6c 00 53 9d a1 30 ed 95 e0 89 44 24 04 8b 00 89 04 24 

... and you'll be stuck with a half removed module. The only cure I've found thus far is rebooting.

Use this patch to fix the problem (this problem is fixed in bristuff-0.2.0-RC5!):

+++ zaphfc.c 2005-01-04 18:02:17.344086630 +0100@@ -78,7 +78,7 @@

+ free_irq(hfc_dev_list->irq, hfc_dev_list);printk(KERN_INFO "zaphfc: shutting down card at %p.\n",hfctmp->pci_io);
hfctmp->regs.int_m2 = 0;
hfc_outb(hfctmp, hfc_INT_M2, hfctmp->regs.int_m2);
@@ -105,7 +105,7 @@
printk(KERN_INFO "unregistered from zaptel.\n");
- free_irq(hfc_dev_list->irq, hfc_dev_list);

When configuring zaptel, you'll need to load the zaphfc driver before any wcfxs or wcfxo drivers, as the zaphfc channels are loaded as a span.

All in all, the driver is 'sort of' working, 'sometimes'. I have dialtone disappearing from the ISDN phones regularly, only a restart of asterisk brings it back. To be fair, the configuration of this setup has not had any real priority, and no real debugging has been done.

when picking up the handset on one of the phones, I allways get the following message in the console:

Feb 17 21:02:07 WARNING[147466]: chan_zap.c:5954 zt_pri_error: PRI: XXX
Missing mandatory IE 24/Channel Identification XXX

the configs

If you only have one hfc card it should be enough to change
signalling = bri_cpe_ptmp
signalling = bri_net_ptmp
in your /etc/asterisk/zapata.conf file

If you have two hfc cards you will have to do some more configuration.

add the following lines into /etc/zaptel.conf


Then execute

You can double check by doing to get a verbose output:
ztcfg -vv

The result should look somewhat like the following:

Zaptel Configuration

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 2: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Individual Clear channel (Default) (Slaves: 01)
Channel 02: Individual Clear channel (Default) (Slaves: 02)
Channel 03: D-channel (Default) (Slaves: 03)
Channel 04: Individual Clear channel (Default) (Slaves: 04)
Channel 05: Individual Clear channel (Default) (Slaves: 05)
Channel 06: D-channel (Default) (Slaves: 06)

6 channels configured.

In your /etc/asterisk/zapata.conf set

; Zapata telephony interface
; Configuration file
;language=de ; you'll need to have German voiceprompts installed for this
switchtype = euroisdn
signalling = bri_net_ptmp ; this is NT mode! Use bri_cpe_ptmp for standard TE mode
immediate=yes ; is this correct, isn't this only for analog handsets?
setcallerid(""<${CALLERIDNUM}>) ; is this correct, shouldn't it rather be "callerid=..."?

card 1
group = 1,3
channel => 1-2

card 2
signalling = bri_cpe_ptmp
group = 2,3
channel => 4-5

The meaning of the above keywords is very well explained in Asterisk config zapata.conf.

For the UK .. BT circuits on ISDN2E (probably all ISDN circuits) you MUST set:


Failing to set this will result in errors of "PRI: received SETUP message for a call that is not a new call " and messages related to "unable to transfer audio" .. examing PRI debug with 'intense' (pri intense debug span 1 on the CLI) will reveal an error related to "unallocated number" before the call is dropped. "unknown" works as a pridialplan setting "local" and others do not.

Note: Unlike in chan_capi you cannot set a filter in the .conf files to listen on specific MSNs and ignore calls to other MSNs on the same S0 bus. Instead you need to use contexts (like "from-bri" above).
Note: For CLIR (to hide your outgoing Caller ID Number) you'll need to use SetCallerPres in the dialplan.

Stability checks

  • I have now got this little ditty running to keep an eye on it:

while true; do grep "(F" /proc/zaptel/2; sleep .1; done

Typical values are F4, F6 (DEACTIVATED) and of F7 (ACTIVATED)

  • On the CLI: pri show span 1
  • less /var/log/messages | grep zaphfc

zaphfc warnings in syslog and Frank Gockel's patch

If you find messages like these in your syslog:

Sep 9 23:37:41 nobaq kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6207, z2=6200, wanted 8 got 7), probably a buffer overrun.
Sep 9 23:37:41 nobaq kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6207, z2=6200, wanted 8 got 7), probably a buffer overrun.
Sep 9 23:43:14 nobaq kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=7112, z2=7105, wanted 8 got 7), probably a buffer overrun.

maybe Frank Gockels patch is for you. You can find a detailed discussion here:

Frank gockel programmed a patch for zaphfc which tries to recover lost interrupts. At the beginning, my syslog was full of these messages but after applying the patch, everything is OK. No such message for half a year and good sound quality.

You can find a description of the patch (in german) at

Homepage of this wonderful patch:

Problem with ZapHFC with ISDN BRI HFC cards and signalization (busy etc.)

  • edit /etc/asterisk/zapata.conf and insert the line for correct ISDN signalization:


Common compile error

If you have something like this :
/usr/src/bristuff-0.2.0-RC8o/zaphfc/zaphfc.c:396: error: structure has no member named `bytes2transmit'
/usr/src/bristuff-0.2.0-RC8o/zaphfc/zaphfc.c:419: error: structure has no member named `bytes2transmit'
/usr/src/bristuff-0.2.0-RC8o/zaphfc/zaphfc.c:436: error: structure has no member named `eoftx'

It's because zaptel was not patched correctly. Maybe you don't have patch (debian : apt-get install patch).
You can try this :
cd bristuff-0.3.0-PRE-1p/zaptel-1.2.5
patch -p1 < ../patches/zaptel.patch

Finding cards - where and what to buy

You're looking for a 'Cologne HFC' card. The Cologne chips are used by different manufacturers at the low end of the market. That's fine as you're going to throw the cheap Windows drivers and software away anyay! In the UK, there are very few cards for sale due to the RoHS legislation - some manufacturers just stopped making the cards rather than spend money making them compliant. Have a look on eBay though as there are still some old, non-RoHS cards out there, as well as new ones!

See also

Other ISDN BRI channels in Asterisk:

Go back to Asterisk zaptelBRI

Created by: JustRumours, Last modification: Sun 06 of May, 2012 (20:20 UTC) by admin
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+