* You are viewing Posts Tagged ‘Dahdi’

E911 Signalling


We’ve got a dedicated T1 with two trunks running into our ILECs selective router for 911. Split out of the T1 into two MF CAMA trunks on ILEC side.

I’m trying to use asterisks e911 signaling, but I’m having trouble with the dial command. (== Everyone is busy/congested at this time (1:1/0/0))

I’m missing something and I’m thinking it has to do with the hookstate of the dahdi channel.

If anyone has a similar situation and want to provide some guidance, I’d sure appreciate it.



Here’s my config:

DAHDI version

[root@e911 dahdi]# dahdi_hardware

pci:0000:02:01.0 wct1xxp+ e159:0001 Digium Wildcard T100P T1/PRI
or E100P E1/PRA Board

e911*CLI> core show version

Asterisk 11.7.0 built by root @ e911 on a x86_64 running Linux on
2014-01-28 15:50:19 UTC











exten => s,1,dial(DAHDI/1/${CALLERID(num)})

e911*CLI> dahdi show status

Description Alarms IRQ bpviol CRC
Fra Codi Options LBO

Digium Wildcard T100P T1/PRI Card 0 OK 0 0 0
ESF B8ZS 0 db (CSU)/0-133 feet (DSX-1)

e911*CLI> dahdi show channels

Chan Extension Context Language MOH Interpret Blocked State Description

pseudo default default In Service

1 public default In Service

2 public default In Service

e911*CLI> dahdi show channel 1

Channel: 1


File Descriptor: 7

Span: 1


Dialing: no

Context: public

Caller ID:

Calling TON: 0

Caller ID name:

Mailbox: none

Destroy: 0

InAlarm: 0

Signalling Type: E911 (MF)

Radio: 0





Confno: -1

Propagated Conference: -1

Real in conference: 0

DSP: no

Busy Detection: no

TDD: no

Relax DTMF: no

Dialing/CallwaitCAS: 0/0

Default law: ulaw

Fax Handled: no

Pulse phone: no

Gains (RX/TX): 0.00/0.00

Dynamic Range Compression (RX/TX): 0.00/0.00

DND: no

Echo Cancellation:

128 taps

currently OFF

Wait for dialtone: 0ms

Actual Confinfo: Num/0, Mode/0x0000

Actual Confmute: No

Hookstate (FXS only): Offhook

Here’s a debug from a 911 call.

[Jan 31 11:29:53] DEBUG[9876][C-00000005]: pbx.c:4890
pbx_extension_helper: Launching ‘Dial’

— Executing [s@InFromSIP:1] Dial(“SIP/SIP-00000005″,
“DAHDI/1/2177772001″) in new stack

[Jan 31 11:29:53] DEBUG[9876][C-00000005]: sig_analog.c:820
analog_available: analog_available 1

[Jan 31 11:29:53] DEBUG[9876][C-00000005]: sig_analog.c:845
analog_available: Channel 1 off hook, can’t use

[Jan 31 11:29:53] WARNING[9876][C-00000005]: app_dial.c:2437
dial_exec_full: Unable to create channel of type ‘DAHDI’ (cause 17 –
User busy)

== Everyone is busy/congested at this time (1:1/0/0)

[Jan 31 11:29:53] DEBUG[9876][C-00000005]: app_dial.c:3100
dial_exec_full: Exiting with DIALSTATUS=BUSY.

— Auto fallthrough, channel ‘SIP/SIP-00000005′ status is ‘BUSY’

What Is Dahdi.auto_assigned_spans And Why Should You Care?

What is dahdi.auto_assign_spans and why should you care?

In later versions the kernel module dahdi[Q] includes a new parameter:
auto_assign_spans. It defaults to 1, and if you set it to 0, DAHDI can start behaving in strange and completely expected ways. Chances are the default will be set to 1 in a future version. Here is why you’ll want to set it yourself.

Up until DAHDI 2.5, hardware drivers for DAHDI presented DAHDI with spans[W]. The device would initialize the hardware, identify the spans in it, and register them with the dahdi core. The dahdi core assigns each span the first available span number and the first available series of channel numbers.

If you have a single device, what you get here is expected. If you have more than one device, you should make sure that they get detected in the same order on each boot. One missing: your configuration is completely botched. As a result, chan_dahdi has adapted to assume that if any channel has the wrong signalling, it may be because a device is missing (or got added) and we cannot trust other parts of the configuration.

Much work has been done to fix this fundemental problem. Dahdi 2.6 added the basic building blocks: When the hardware drivers register with DAHDI
they expose information about the complete device. This information is available to userspace through sysfs[E]. If the module parameter auto_assign_spans has the value 1 (the default), it all happens as before (except now we call the operation “assignment” – spans are assigned. And they can be unassigned and reassgined later).

But if auto_assign_spans is set to 0, the spans of the device will just sit there and wait for the user to do something: you can ask dahdi to either assign spans “automatically” (to the first available numbers, just as before). But you can also ask DAHDI to give each span a specific span number and a specific initial channel number. See [R] for the exact details.

While doing that we noticed that setting a span to be either E1 or T1
has to be done before it is assigned (you can’t change the number of channels after a span is assigned). Thus a similar interface was added to change the “span type”.

Another important component are “udev events” – when a kernel object is created (or destroyed), the kernel emits an event. udevd listens on those events. With the proper udev rules, you can react to addition of dahdi devices, spans or channels.

With those low-level tools in place, all we need are a few shell scripts. You can find the full specification in [T]. You should note the two new tools. Those tools provide a simple and clean interface to the sysfs interface.

dahdi_span_assignments: can unassign spans (remove) assign spans automatically (auto), or assign them according to the specifications in
/etc/dahdi/assigned-spans.conf (add). It also has the option
‘dumpconfig’ to print the current state in the same format used by its configuration file assigned-spans.conf .

dahdi_span_types: similar for the span types attribute with
/etc/dahdi/span-types.conf .


“dahdi Show Channels” No Such Command

I have followed the instructions in Asterisk The Definitive Guide 4th edition.

DAHDI-Linux And DAHDI-Tools 2.8.0-rc5 Now Available

The Asterisk Development Team has announced the releases of:

This release is available for immediate download at:
http://downloads.asterisk.org/pub/telephony/dahdi-linux http://downloads.asterisk.org/pub/telephony/dahdi-tools http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete

*** THIS RC FIXES CentOS 6.5 “PDE_DATA” build issue ***

In version 2.8 we have introduced two new drivers:
wcte43x – For Digium’s new line of 2/4 span T1/E1 cards wcaxx – For Digium’s new line of analog fxs/fxo cards

We introduced a common library called “wcxb” which ties the previous two drivers, plus the recently introduced wcte13xp driver, together into one common base.

dahdi-linux-complete tarballs now include all firmware necessary to build without an internet connection.

Issues closed in this release:

Shortlog of changes since v2.7.0.1:
Oron Peled (16):
xpp: Serialize dahdi registration
xpp: refactor FXS ring settings
xpp: FXS: ring/mwi settings: a sysfs interface
xpp: ring/mwi settings: add to FXS init script
add a ‘location’ attribute to sysfs (dahdi_device):
dahdi: add “tools_rootdir” module parameter
Also send DAHDI_TOOLS_ROOTDIR with device events
live_dahdi: load “dahdi” with tools_rootdir=$DESTDIR
remove udev rules: moved to dahdi-tools
sysfs: create symlink “ddev” to device of span
dahdi: Rename span ‘master’ as ‘master_span’
.gitignore: *.ko.unsigned
Rename “pinned spans” to “assigned spans”
xpp: automatic dahdi_registration by default
sysfs: new driver attribute: master_span
Makefile: new ‘make-dist’ target

Russ Meyerriecks (3):
wcte13xp: Migrate to wcxb library
wcte13xp: Hold framer in reset to stop xmit on modprobe -r
wcte13xp: Improve maintenance functions and error counters

Shaun Ruffell (28):
dahdi_config: Remove unused NO_DCDC definition.
dahdi: Clear DAHDI_ALARM_NOTOPEN when spans are re-initialized.
dahdi: Fix placement of ‘/’ in output of /proc/dahdi/x
dahdi: Work around missing KBUILD_MODNAME
dahdi: Backport try_wait_for_completion() and list_first_entry()
wct4xxp: Print warning in dmesg if span priority is not set correctly.
wct4xxp: Fix bipolar error insertion test mode.
wct4xxp: VPM companding switch print is now debug only.
wct4xxp: If linemode changed via sysfs, reset the complete part.
wct4xxp, wcte13xp: Move the octasic DSP code into separate module.
wcaxx: New driver for A4A/A4B/A8A/A8B analog cards.
wcaxx: Update A4B firmware to version 0b0017
wcxb: Update the firmware meta block during flash update.
wcte43x: Do not grab reglock in handle_transmit/handle_receive.
wcte43x: Remove ‘dcxo’ debug attribute.
oct612x: Make dependent on dahdi.ko
dahdi_dynamic: Create a span type for dynamic spans.
wcaxx: Use startup/shutdown callbacks to protect access to channel registers.
wctdm24xxp: Remove assigned callback.
dahdi: Remove “ddev” symlink before unregistering the span device.
dahdi: CentOS 6.5 backported PDE_DATA definition.
wcxb: is_pcie -> pci_is_pcie()
wcxb: Do not access cur_transfer/cur_msg outside of lock.
wcaxx: Add extra dummy read when checking for single fxs modules.
wcte43x: Update firmware to version e0017.
dahdi: Replace drv_attr with drv_groups on kernels > 3.12.
Revert “wcaxx: Use startup/shutdown callbacks to protect access to channel registers.”
dahdi: Fix previous CentOS 6.5 commit.

Shaun RuffellL (1):
wcaxx: Remove some left over debugging trace statements.

Tzafrir Cohen (6):
xpp: Firmware for Astribanks 2.02
xpp: Firmware for Astribanks 2.02: Makefile
xpp: USB_FW.202.hex: provide as a symlink
xpp: mark an AB as failed if it gives bad desc
xpp: Fail loading if no module on first slot
Ignore some more firmware files

Wendell Thompson (2):
wcte13xp: Use interrupts for Falc alarms and signaling
wcte43x: Add driver for TE435/TE235 digital cards.

The diffstat from the v2.7.0.1 release:
.gitignore | 9 +
Makefile | 28 +-
README | 17 +-
build_tools/genudevrules | 40 –
build_tools/live_dahdi | 2 +-
build_tools/make_dist | 26 +
drivers/dahdi/Kbuild | 21 +-
drivers/dahdi/dahdi-base.c | 74 +-
drivers/dahdi/dahdi-sysfs.c | 150 +-
drivers/dahdi/dahdi_dynamic.c | 4 +
drivers/dahdi/firmware/Makefile | 71 +-
drivers/dahdi/oct612x/Kbuild | 32 +
drivers/dahdi/oct612x/oct612x-user.c | 200 +
drivers/dahdi/oct612x/oct612x.h | 49 +
drivers/dahdi/wcaxx-base.c | 4544 ++++++
drivers/dahdi/wct4xxp/Kbuild | 4 +-
drivers/dahdi/wct4xxp/base.c | 159 +-
drivers/dahdi/wct4xxp/vpm450m.c | 139 +-
drivers/dahdi/wct4xxp/vpm450m.h | 8 +-
drivers/dahdi/wctdm24xxp/base.c | 31 +-
drivers/dahdi/wcte13xp-base.c | 2294 ++-
drivers/dahdi/wcte43x-base.c | 3591 +++++
drivers/dahdi/wcxb.c | 951 ++
drivers/dahdi/wcxb.h | 184 +
drivers/dahdi/wcxb_flash.c | 170 +
drivers/dahdi/wcxb_flash.h | 34 +
drivers/dahdi/wcxb_spi.c | 386 +
drivers/dahdi/wcxb_spi.h | 116 +
drivers/dahdi/xpp/card_fxs.c | 295 +-
drivers/dahdi/xpp/card_global.c | 6 +
drivers/dahdi/xpp/firmwares/FPGA_1161.202.hex |20517 +++++++++++++++++++++++++
drivers/dahdi/xpp/firmwares/Makefile | 5 +-
drivers/dahdi/xpp/firmwares/USB_FW.202.hex | 1 +
drivers/dahdi/xpp/init_card_1_30 | 22 +-
drivers/dahdi/xpp/xbus-core.c | 24 +-
drivers/dahdi/xpp/xbus-sysfs.c | 11 +-
drivers/dahdi/xpp/xpp.rules | 11 –
include/dahdi/dahdi_config.h | 3 +-
include/dahdi/kernel.h | 55 +-
39 files changed, 32537 insertions(+), 1747 deletions(-)

For a full list of changes in these releases, please see the shortlog at:


Dahdi Fax Catch-22

I’ve got a Digium Wildcard TDM410P with one POTS line and three extensions. One of the extensions is connected to a fax modem. This kind of works, but there’s a gotcha. If I set faxdetect=incoming in chan_dahdi.conf, then incoming faxes do get routed to the modem and this all works, but outbound faxes fail, with a message like this:

[Oct 29 21:57:09] WARNING[16732][C-00000000] app_dial.c: Unable to create channel of type ‘DAHDI’ (cause 17 – User busy)

If I set faxdetect=no, then outbound faxes work, but of course incoming faxes do not get routed to the modem. I’m guessing that what is happening is that the “outbound” call coming in from the modem’s channel is an “incoming” call on that channel, asterisk detects the fax and tries to route it to the same channel, resulting in busy.

Is there any way around this catch-22? Is there some way to set faxdetect=incoming only on the one POTS line channel?

The only alternative I can think of would be a kludgy Radio Shack-style solution like a manual switcher, that switches the modem between the connection to the dahdi channel (receive) and a direct connection to the POTS line (send). I’d really like not to have to resort to that.


Feature Request: SIPPEER Or IAXPEER Equivalent For DAHDI


With setvar statements in chan_dahdi.conf, we have a convenient way to store DAHDI channels specific values.

Unfortunately, we don’t have a function to access this data from the dialplan as easily as SIPPEER ou IAXPEER would for SIP or IAX trunks.

Using AST_CONFIG, you can access DAHDI setvar value but:
1. only one setvar value (see bellow)
2. AST_CONFIG reads values from current config file not previously loaded file (this is obviously what you would expect from this function).

What do you think of this ?
Would you qualify this as useful ?


In chan_dahdi.conf, I add this: