* You are viewing Posts Tagged ‘Dahdi’

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:


Direct DAHDI Documentation


I wanted to switch from using Dialogic/Eicon cards to using Digium’s T-1 cards. When I purchased a sample card the salesperson assured me there was documentation specific to the DAHDI interface. Now that I’m digging in, I’m finding it’s documented a lot like Linux — one must read the fairly uncommented source code.

I don’t have a problem with this generally, but here I just don’t understand the divisions of labor between Asterisk, DAHDI Hardware, DAHDI kernel modules and Userland (me). (BTW, I do not wish to use Asterisk as we have numerous projects based on Dialogic/Eicon spanning some 20 years. My intent is to write a replacement look-a-like driver which uses Digium’s cards instead of Dialogic’s.)

My specific issues are:

1) HDLC. Does the hardware have an HDLC controller, or is it the user’s job to hunt for flags, frame the data and calc the FCS?

2) ISDN/PRI. Does the kernel module load Q.921/931 implementation or is this user’s responsibility? I know there’s a LIBPRI product, which I may use, but I have my own PRI library which was confirmance tested with ATT years ago. Either way, I’m not sure how the D-channel data is flowing.

3) I got the idea that B-channel data is collected by the kernel module in 8 sample blocks (1 ms). Does this mean I need to be reading it out/writing it in at that rate? I saw some buffering code, but wasn’t sure if that was voicefile type playback/record or if all audio is treated without regard to its source/destination. I guess I could lock onto it at 1ms using Linux’s HPET timer, although that sounds clumsy.

4) I can certainly convert between ulaw/linear to sum for conferencing, but it seems the kernel module might support that as well? Or at the least it seems the kernel module can support chan-to-chan connections.

5) I found some DTMF (FIR goertzel) code somewhere in DAHDI, but also in Asterisk. While I have such code in own library, am I to understand DTMF can be detected within the kernel module?

I guess I really would like to see a doc on the overall concept of DAHDI hardware and its kernel module. I don’t care how it’s laid out, I’d just like to get my mind around it. Does anyone know of an example telephony C file that might show:

1) initialization of DAHDI spans
2) waiting for inbound events
3) answering a call
4) sending a voice file, recording a voice file
5) disconnection of calls
6) de-initialization

And perhaps showing how two channels are connected to create a conversation?

Thanks in advance, Gary