DAHDI Telephony Interface Driver

If all is well, you just need to run the following:

You'll need the utilities provided in the package dahdi-tools to configure DAHDI devices on your system.

If using sudo to build/install, you may need to add /sbin to your PATH.

If you still have problems, read further.

gcc and friends. Generally you will need to install the package gcc. There may be cases where you will need a specific version of gcc to build kernel modules.

TODO: copy build requirement from Zaptel README.

The following may be useful when testing the package or when preparing a package for a binary distribution (such as an rpm package) installing onto a subtree rather than on the real system.

This can be useful for any partial install target of the above (e.g: install-modules or install-programs).

the targetdir must be an absolute path, at least if you install the modules. To install to a relative path you can use something like:

To build extra modules / modules directory not included in the DAHDI distribution, use the optional variables MODULES_EXTRA and SUBDIRS_EXTRA:

Userspace programs communicate with the DAHDI modules through special device files under /dev/dahdi . Those are normally created by udev, but if you use an embedded-type system and don't wish to use udev, you can generate them with the following script, from the source directory:

This will generate the device files under /dev/dahdi . If you need to generate them elsewhere (e.g. tmp/newroot/dev/dahdi) use the option -d to the script:

DAHDI includes the wcb4xxp driver for the B410P, however, support for the B410P was historically provided by mISDN. If you would like to use the mISDN driver with the B410P, please comment out the wcb4xxp line in /etc/dahdi/modules. This will prevent DAHDI from loading wcb4xxp which will conflict with the mISDN driver.

To install the mISDN driver for the B410P, please see http://www.misdn.org for more information, but the following sequence of steps is roughly equivalent to make b410p from previous releases.

You will then also want to make sure /etc/init.d/misdn-init is started automatically with either chkconfig —add misdn-init or update-rc.d misdn-init defaults 15 30 depending on your distribution.

OSLEC is an Open Source Line Echo Canceller. It is currently in the staging subtree of the mainline kernel and will hopefully be fully merged at around version 2.6.29. The echo canceller module dahdi_echocan_oslec provides a DAHDI echo canceller module that uses the code from OSLEC. As OSLEC has not been accepted into mainline yet, its interface is not set in stone and thus this driver may need to change. Thus it is not built by default.

Luckily the structure of the dahdi-linux tree matches that of the kernel tree. Hence you can basically copy drivers/staging/echo and place it under driver/staging/echo . In fact, dahdi_echocan_oslec assumes that this is where the oslec code lies. If it is elsewhere you'll need to fix the #include line.

Thus for the moment, the simplest way to build OSLEC with dahdi is:

After doing that, you'll see the following when building (running make)

As this is an experimental driver, problems building and using it should be reported on the OSLEC mailing list.

In many cases you already have DAHDI installed on your system but would like to try a different version. E.g. in order to check if the latest version fixes a bug that your current system happens to have.

DAHDI-linux includes a script to automate the task of installing DAHDI to a subtree and using it instead of the system copy. Module loading through modprobe cannot be used. Thus the script pre-loads the required modules with insmod (which requires some quesswork as for which modules to load). It also sets PATH and other environment variables to make all the commands do the right thing.

There is an extra mode of operation to copy all the required files to a remote host and run things there, for those who don't like to test code on thir build system.

Basic operation is through running

from the root directory of the dahdi-linux tree. Using DAHDI requires dahdi-tools as well, and the script builds and installs dahdi-tools. By default it assumes the tree of dahdi-tools is in the directory dahdi-tools alongside the dahdi-linux tree. If you want to checkout the trunks from SVN, use:

If the tools directory resides elsewhere, you'll need to edit live/live.conf (see later on). The usage message of live_dahdi:

Normally you should run:

to build and install everything. Up until now no real change was done. This could actually be run by a non-root user. All files are installed under the subdirectory live/ .

Reloading the modules (and restarting Asterisk) is done by:

Note: this stops Asterisk, unloads the DAHDI modules, loads the DAHDI modules from the live/ subdirectory, configures the system and re-starts Asterisk. This can do damage to your system. Furthermore, the DAHDI configuration is generated by dahdi_genconf. It can be influenced by a genconf_parameters file. But it may or may not be what you want.

If you want to run a command in the environment of the live system, use the command exec:

Note however:

As mentioned above, live_dahdi can also copy all the live system files to a remote system and run from there. This requires rsync installed on both system and assumes you can connect to the remove system through ssh.

As you can see, it copies the script itselfand the whole live/ subdirectory. The target directory is /tmp/live on the target directory (changing it should probably be simple, but I never needed that).

Then, on the remove computer:

The live_dahdi script reads a configuration file in live/live.conf if it exists. This file has the format of a shell script snippet:

The variables below can also be overriden from the environment:

The relative path to the dahdi-linux tree. The default is . and normally there's no reason to override it.

The relative path to the dahdi-tools tree. The default is dahdi-tools.

Set a syncing astribank. See xpp_sync(8). Default is auto.

The command for an init.d script to start/stop Asterisk. Should accept start and stop commands. Use true if you want to make that a no-op. Defaults to /etc/init.d/asterisk .

Manual list of modules. They will be loaded by insmod. If reside in a subdir, add it explicitly. Modules for the drivers that are detected on the system will be added by the script. Default: dahdi dahdi_echocan_mg2

A list of modules to remove when unloading. Will be resolved recursively. The default is dahdi. You may also want to have oslec or hpec there if you use them.

The kernel modules can be configured through module parameters. Module parameters can optionally be set at load time. They are normally set (if needed) by a line in a file under /etc/modprobe.d/ or in the file /etc/modprobe.conf.

Example line:

The module parameters can normally be modified at runtime through sysfs:

Viewing and setting parameters that way is possible as of kernel 2.6 . In kernels older than 2.6.10, the sysfs "files" for the parameters reside directly under /sys/module/module_name .

Useful module parameters:

To get a list of parameters supported by a module, use

Or, for a module you have just built:

For the xpp modules this will also include the description and default value of the module. You can find a list of useful xpp module parameters in README.Astribank .

Userspace programs will usually interact with DAHDI through device files under the /dev/dahdi directory (pedantically: character device files with major number 196) . Those device files can be generated statically or dynamically through the udev system.

A PBX system should generally have a single clock. If you are connected to a telephony provider via a digital interface (e.g: E1, T1) you should also typically use the provider's clock (as you get through the interface). Hence one important job of Asterisk is to provide timing to the PBX.

DAHDI "ticks" once per millisecond (1000 times per second). On each tick every active DAHDI channel reads and 8 bytes of data. Asterisk also uses this for timing, through a DAHDI pseudo channel it opens.

However, not all PBX systems are connected to a telephony provider via a T1 or similar connection. With an analog connection you are not synced to the other party. And some systems don't have DAHDI hardware at all. Even a digital card may be used for other uses or is simply not connected to a provider. DAHDI cards are also capable of providing timing from a clock on card. Cheap x100P clone cards are sometimes used for that purpose.

If all the above fail, you can use the module dahdi_dummy to provide timing alone without needing any DAHDI hardware. It will work with most systems and kernels.

You can check the DAHDI timing source with dahdi_test, which is a small utility that is included with DAHDI. It runs in cycles. In each such cycle it tries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded or you don't have the device files, it will fail immediately. If you lack a timing device it will hang forever in the first cycle. Otherwise it will just give you in each cycle the percent of how close it was. Also try running it with the option -v for a verbose output.

To check the clock source that is built into dahdi_dummy, you can either look at title of its span in /proc/dahdi file for a "source:" in the description. Or even run:

DAHDI provides telephony channels to the userspace applications. Those channels are channels are incorporated into logical units called spans.

With digital telephony adapters (e.g: E1 or T1), a span normally represents a single port. With analog telephony a span typically represents a PCI adapter or a similar logical unit.

Both channels and spans are identified by enumerating numbers (beginning with 1). The number of the channel is the lowest unused one when it is generated, and ditto for spans.

There are up to 128 spans and 1024 channels. This is a hard-wired limit (see dahdi/user.h . Several places throuout the code assume a channel number fits in a 16 bits number). Channel and span numbers start at 1.

Dynamic spans are spans that are not represented by real hardware. Currently there are two types of them:

Modules that support the dynamic spans are typically loaded at the time the ioctl DAHDI_DYNAMIC_CREATE is called. This is typically called by dahdi_cfg when it has a line such as:

in /etc/dahdi/system.conf . In that case it will typically try to load (through modprobe) the modules dahdi_dynamic and dahdi_dynamic_'somename'. It will then pass params to it.

Dynamic spans are known to be tricky and are some of the least-tested parts of DAHDI.

(To be documented later)

(To be documented later)

A simple way to get the current list of spans and channels each span contains is the files under /proc/dahdi . /proc/dahdi is generated by DAHDI as it loads. As each span registers to DAHDI, a file under /proc/dahdi is created for it. The name of that file is the number of that span.

Each file has a 1-line title for the span followed by a few optional general counter lines, an empty line and then a line for each channel of the span.

The title line shows the number of the span, its name and title, and (potentially) the alarms in which it is.

The title shows the span number and name, followed by any alarms the span may have: For example, here is the first span in my system (with no alarms):

There are several extra optional keywords that may be added there:

Following that line there may be some optional lines about IRQ misses, timing slips and such, if there are any.

The channel line for each channel shows its channel number, name and the actual signalling assigned to it through dahdi_cfg. Before being configured by dahdi_cfg: This is DAHDI channel 2, whose name is XPP_FXS/0/0/1.

After being configured by dahdi_cfg: the signalling FXOLS was added. FXS channels have FXO signalling and vice versa:

If the channel is in use (typically opened by Asterisk) then you will see an extra (In use):

User-space programs can only work with DAHDI channels. The basic operation is read() to read audio from the device and write() to write audio to it. Audio can be encoded as either alaw (G.711a) or (m)ulaw (G.711u). See the ioctl DAHDI_SETLAW.

While it is technically possible to use /dev/dahdi/NUMBER directly, this will only work for channel numbers up to 249. Generally you should use:

FIXME: there's more to tell about the user-space interface.

Most of the configuration is applied from userspace using the tool dahdi_cfg in the package dahdi_tools. This section will not cover the specifics of that file. Rather it will cover the way configuration from this file is applied. Also note that there are other methods to configure DAHDI drivers: there are Module Parameters. The xpp driver have their own separate initialization scripts and xpp.conf that arecovered in README.Astribank.

When a span is registered, it is considered "unconfigured". Only after dahdi_cfg has been run to apply configuration, the span is ready to run. The only exception to that is dahdi_dummy, which does not need any configuration.

Some of the configuration is handled by the DAHDI core. Some of it is handled by callbacks, which are function pointers in the `struct dahdi_span': spanconfig, chanconfig and (in a way) startup.

Dahdi_cfg starts by reading the configuration from the configuration file (/etc/dahdi/system.conf, by default), and creating a local configuration to apply. If you use -v, at this stage it will pront the configuration that is "about to be configured". Then it will start to actually apply the configuration.

Before actually applying configuration, it destroys any existing dynamic spans and generates new ones (if so configured. FIXME: what about running DAHDI_SPANCONFIG for new dynamic spans?).

Next thing it will do is apply the parameters from span lines using the ioctl DAHDI_SPANCONFIG. Some generic processing of parameters passed in DAHDI_SPANCONFIG is done in the DAHDI core, in the callback function spanconfig in , but most of it is left to spanconfig callback of the span (if it exists. This one typically does not exists on analog cards).

Now dahdi_cfg will ask each existing channel for its existing configuration and apply configuration if configuration changes are needed. Configuration is applied to the channels using the ioctl call DAHDI_CHANCONFIG ioctl. As in the case of the span configuration, part of it is applied by the DAHDI core, and then it is handed over to the span's chanconfig callback. Typically all spans will have such a callback.

Echo cancellers and tone-zones are handled separately later.

Once everything is done, the ioctl DAHDI_STARTUP is called for every span. This is also translated to a call to the optional span callback startup.

Finally the ioctl DAHDI_HDLC_RATE is called for every channel (that is: if 56k is not set for the channel, it will be explicitly set to the standard HDLC rate of 64k).

Low-level drivers create spans (struct dahdi_span). They register the spans with the DAHDI core using dahdi_register().

struct dahdi_span has a number of informative members that are updated solely by the low-level driver:

There are various function pointers in the struct dahdi_span which are used by the DAHDI core to call the low-level driver. Most of them are optional.

The following apply to a span:

The following apply to a single channel.

There are several alternative methods for a span to use for signalling. One of them should be used.

If the device is a CAS interface, the driver should copy the signalling bits to and from the other side, and DAHDI will handle the signalling. The driver just need to provide a rbsbits and set DAHDI_FLAG_RBS in the span→flags.

Note that rbs (Robed Bits Signalling) here merely refers to the (up to) 4 signalling bits of the channel. In T1 they are transmitted by "robbing" bits from the channels and hence the name. In E1 they are transmitted in a timeframe of their own.

The driver should then signal a change in the signalling bits in a channel using dahdi_rbsbits().

If the device does not know about signalling bits, but has their equivalents (i.e. can disconnect battery, detect off hook, generate ring, etc directly) then the driver can specify a sethook function and set DAHDI_FLAG_RBS in span→flags. In that case DAHDI will call that function whenever the signalling state changes.

The hooksig function is only used if the rbsbits function is not set.

The span should notify DAHDI of a change of signalling in a channel using dahdi_hooksig().

Alternatively, if DAHDI_FLAG_RBS is not set in the flags of the span (to use either rbsbits or hooksig), the DAHDI core will try to call the sethook function of the span (if it exists) to handle individual hook states.

The span should then notify DAHDI of a change in the signalling state using dahdi_sethook().

FIXME: anybody using this one?

Like any other kernel code, DAHDI strives to maintain a stable interface to userspace programs. The API of DAHDI to userspace programs, dahdi/user.h, has remained backward-compatible for a long time and is expected to remain so in the future. With the ABI (the bits themselves) things are slightly trickier.

DAHDI's interface to userspace is mostly ioctl(3) calls. Ioctl calls are identified by a number that stems from various things, one of which is the size of the data structure passed between the kernel and userspace.

Many of the DAHDI ioctl-s use some specific structs to pass information between kernel and userspace. In some cases the need arose to pass a few more data members in each call. Simply adding a new member to the struct would have meant a new number for the ioctl, as its number depends on the size of the data passed.

Thus we would add a new ioctl with the same base number and with the original struct.

So suppose we had the following ioctl:

And we want to add the field int onemore, we won't just add it to the struct. We will do something that is more complex:

We actually have here two different ioctls: the old DAHDI_EXAMPLE would be 0xC0044A3E . DAHDI_EXAMPLE_V1 would have the same value. But the new value of DAHDI_EXAMPLE would be 0xC0084A3E . (TODO: fix ioctl values)

Programs built with the original dahdi/user.h (before the change) use the original ioctl, whether or not the kernel code is actually of the newer version. Thus in most cases there are no compatibility issues.

When can we have compatibility issues? If we have code built with the new dahdi/user.h, but the loaded kernel code (modules) are of the older version. Thus the userspace program will try to use the newer DAHDI_EXAMPLE (0xC0084A3E). But the kernel code has no handler for that ioctl. The result: the error 25, ENOTTY, which means "Inappropriate ioctl for device".

As a by-product of that method, for each interface change a new #define is added. That definition is for the old version and thus it might appear slightly confusing in the code, but it is useful for writing code that works with all versions of DAHDI.

An alarm indicates that a port is not available for some reason. Thus it is probably not a good idea to try to call out through it.

Your T1/E1 port will go into red alarm when it cannot maintain synchronization with the remote switch. A red alarm typically indicates either a physical wiring problem, loss of connectivity, or a framing and/or line-coding mismatch with the remote switch. When your T1/E1 port loses sync, it will transmit a yellow alarm to the remote switch to indicate that it's having a problem receiving signal from the remote switch.

The easy way to remember this is that the R in red stands for "right here" and "receive"… indicating that we're having a problem right here receiving the signal from the remote switch.

(RAI — Remote Alarm Indication)

Your T1/E1 port will go into yellow alarm when it receives a signal from the remote switch that the port on that remote switch is in red alarm. This essentially means that the remote switch is not able to maintain sync with you, or is not receiving your transmission.

The easy way to remember this is that the Y in yellow stands for "yonder"… indicating that the remote switch (over yonder) isn't able to see what you're sending.

(AIS — Alarm Indication Signal)

Your T1/E1 port will go into blue alarm when it receives all unframed 1s on all timeslots from the remote switch. This is a special signal to indicate that the remote switch is having problems with its upstream connection. dahdi_tool and Asterisk don't correctly indicate a blue alarm at this time. The easy way to remember this is that streams are blue, so a blue alarm indicates a problem upstream from the switch you're connected to.

TODO: explain.

Not really an alarm. Indicates that a span is not available, as the port is in either a local or remote loopback mode.

Something is not connected. Used by e.g. the drivers of the Astribank to indicate a span that belongs to a device that has been disconnected but is still being used by userspace programs and thus can't e destroyed.

This package is distributed under the terms of the GNU General Public License Version 2, except for some components which are distributed under the terms of the GNU Lesser General Public License Version 2.1. Both licenses are included in this directory, and each file is clearly marked as to which license applies.

If you wish to use the DAHDI drivers in an application for which the license terms are not appropriate (e.g. a proprietary embedded system), licenses under more flexible terms can be readily obtained through Digium, Inc. at reasonable cost.

KB1 was not designed to function at greater than 128 taps, and if configured this way, will result in the destruction of audio. Ideally DAHDI would return an error when a KB1 echocanceller is configured with greater than 128 taps.

Please report bug and patches to the Asterisk bug tracker at http://issues.asterisk.org in the "DAHDI" category.