DAHDI Telephony Interface Driver

This package needs the headers from dahdi-linux. Thus you should install dahdi-linux before building dahdi-tools.

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.

Some libraries are needed for extra utilities that are provided with DAHDI.

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

There are some make targets that are provided to build or install just parts of DAHDI:

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 th real system.

This can be useful for any partial install target from the list above.

The configure script various several tests and based on them generates some files ( build_tools/menuselect-deps and makeopts). You can pass it --with options and variable settings, for instance:

If you just want to recreate the same files without a full detection run, use:

To re-run ./configure with the same parameters it was run with last time, use:

Configuration for DAHDI resides under /etc/dahdi .

The main method to configure DAHDI devices is using the utility dahdi_cfg. dahdi_cfg reads data from the configuration file /etc/dahdi/system.conf , figures out what configuration to send to channels, and send it to the kernel.

A sample annotated system.conf is included in this directory and installed by default. Edit it to suit your configuration. Alternatively use the script dahdi_genconf to generate one that should work with your system.

The configuration file of the dahdi init.d script is /etc/dahdi/init.conf . That file is used to override defaults that are set at the beginning of the init.d script.

DAHDI Configuration File

This file is parsed by the DAHDI Configurator, dahdi_cfg

First come the span definitions, in the format

All T1/E1/BRI spans generate a clock signal on their transmit side. The <timing source> parameter determines whether the clock signal from the far end of the T1/E1/BRI is used as the master source of clock timing. If it is, our own clock will synchronise to it. T1/E1/BRI connected directly or indirectly to a PSTN provider (telco) should generally be the first choice to sync to. The PSTN will never be a slave to you. You must be a slave to it.

Choose 1 to make the equipment at the far end of the E1/T1/BRI link the preferred source of the master clock. Choose 2 to make it the second choice for the master clock, if the first choice port fails (the far end dies, a cable breaks, or whatever). Choose 3 to make a port the third choice, and so on. If you have, say, 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each port should be different.

If you choose 0, the port will never be used as a source of timing. This is appropriate when you know the far end should always be a slave to you. If the port is connected to a channel bank, for example, you should always be its master. Likewise, BRI TE ports should always be configured as a slave. Any number of ports can be marked as 0.

Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed faxes, unreliable modem operation, and is a general all round bad thing.

The line build-out (or LBO) is an integer, from the following table:

If the span is a BRI port the line build-out is not used and should be set to 0.

Next come the dynamic span definitions, in the form:

Where <driver> is the name of the driver (e.g. eth), <address> is the driver specific address (like a MAC for eth), <numchans> is the number of channels, and <timing> is a timing priority, like for a normal span. use "0" to not use this as a timing source, or prioritize them as primary, secondard, etc. Note that you MUST have a REAL DAHDI device if you are not using external timing.

If a non-zero timing value is used, as above, only the last span should have the non-zero value.

Next come the definitions for using the channels. The format is: <device>=<channel list>

Valid devices are:

The channel list is a comma-separated list of channels or ranges, for example:

So, some complete examples are:

An example of BRI port:

Finally, you can preload some tone zones, to prevent them from getting overwritten by other users (if you allow non-root users to open /dev/dahdi/* interfaces anyway. Also this means they won’t have to be loaded at runtime. The format is "loadzone=<zone>" where the zone is a two letter country code.

You may also specify a default zone with "defaultzone=<zone>" where zone is a two letter country code.

An up-to-date list of the zones can be found in the file zonedata.c

(see http://www.zapatatelephony.org/app_rpt.html)

The PCI Radio Interface card interfaces up to 4 two-way radios (either a base/mobile radio or repeater system) to DAHDI channels. The driver may work either independent of an application, or with it, through the driver;s ioctl() interface. This file gives you access to specify load-time parameters for Radio channels, so that the driver may run by itself, and just act like a generic DAHDI radio interface.

Unlike the rest of this file, you specify a block of parameters, and then the channel(s) to which they apply. CTCSS is specified as a frequency in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS for receive is specified as the code directly, for example 223. DCS for transmit is specified as D and then the code, for example D223.

The hardware supports a "community" CTCSS decoder system that has arbitrary transmit CTCSS or DCS codes associated with them, unlike traditional "community" systems that encode the same tone they decode.

this example is a single tone DCS transmit and receive

specify the transmit tone (in DCS mode this stays constant):

specify the receive DCS code:

this example is a "community" CTCSS (if you only want a single tone, then only specify 1 in the ctcss list)

specify the default transmit tone (when not receiving):

Specify the receive freq, the tag (use 0 if none), and the transmit code. The tag may be used by applications to determine classification of tones. The tones are to be specified in order of presedence, most important first. Currently, 15 tones may be specified..

The following parameters may be omitted if their default value is acceptible

Set the receive debounce time in milliseconds:

set the transmit quiet dropoff burst time in milliseconds:

set the COR level threshold (specified in tenths of millivolts) valid values are {3125,6250,9375,12500,15625,18750,21875,25000}

Invert COR signal {y,n}

Set the external tone mode; yes, no, internal {y,n,i}

Now apply the configuration to the specified channels:

We are all done with our channel parameters, so now we specify what channels they apply to

Usually the channel driver sets the encoding of the PCM for the channel (mulaw / alaw. That is: g711u or g711a). However there are some cases where you would like to override that. mulaw and alaw set different such encoding. Use them for channels you have already defined with e.g. bchan or fxoks.

deflaw is similar, but resets the encoding to the channel driver’s default. It must be useful for something, I guess.

DAHDI uses modular echo cancellers that are configured per channel. The echo cancellers are compiled and installed as part of the dahdi-linux package. You can specify in this file the echo canceller to be used for each channel. The default behavior is for there to be NO echo canceller on any channel, so it is very important that you specify one here if you do not have hardware echo cancellers and need echo cancellation.

Valid echo cancellers are: mg2, kb1, sec2, and sec. If compiled, hpec is also a valid echo canceller.

To configure the default echo cancellers, use the format: echocanceller=<echocanceller name>,<channel(s)>

Example: Configure channels 1 through 8 to use the mg2 echo canceller

And change channel 2 to use the kb1 echo canceller.

Shell settings for Dahdi initialization scripts. This replaces the old/per-platform files (/etc/sysconfig/zaptel, /etc/defaults/zaptel)

The maximal timeout (seconds) to wait for udevd to finish generating device nodes after the modules have loaded and before running dahdi_cfg.

A list of modules to unload when stopping. All of their dependencies will be unloaded as well.

Override settings for xpp_fxloader

FIXME: still not properly formatted.

/etc/dahdi/genconf_parameters

This file contains parameters that affect the dahdi_genconf configuration generator.

Syntax: * A comment from # to end of line * Blank lines ignored * Whitespace at end of line trimmed * Single valued items: key <whitespace…> value * List valued items: key <whitespace…>value1 <whitespace…>value2 …

When generating extensions for chan_dahdi.conf or users.conf etc: the extension number will be channel_number+base_exten . The default is:

Make FXS (analog phones) extensions answer immediately (sets immediate = yes for them in chan_dahdi.conf). Don’t enable this before you’re read documentation about this option.

For FXS (analog phones) - use KS or LS? ks is the only method for Asterisk to provide disconnect supervision and thus it would normally be preferred and is the default.

For FXO (analog lines) - use KS or LS? KS is the default and is normally the better choice as it allows detecting hang-ups on many lines.

Set tone zone values. This is used for playing tones (busy, dial-tone and such). The default is us. This sets the value for both loadzone and defaultzone in system.conf .

The dialplan context into which to send trunks in chan_dahdi.conf or users.conf. The default value is:

The dialplan context into which to send extensions in chan_dahdi.conf or users.conf. The default value is:

Two extra contexts for the input ports and output ports of an Astribank. Default values are:

A group to put all analog phones in. By default 0, so you can dial to the first phone available using Dahdi/g5 .

A group in which to put all the channels belonging to some trunk. Thus you can dial through "some trunk" using Dahdi/G0/NUMBER

Channels of digital trunk of span N are also added to group 10+N (that is: 14 for channels of span 4).

Do we want to use PtP (bri) or PtMP (bri_ptmp) for BRI? PtMP allows connecting several CPE devices on the same network device (several BRI phones on the same line, kind of like several analog phones on the same analog line). However it is generally brings unnecessary complexity for a pbx-pbx connection. It is still the default as this is normally what you get for a BRI PSTN connection.

If this option is set (that is: not remmed-out), BRI NT ports will also be set as overlap. This is useful if you want to connect ISDN phones.

The echo canceler to use. If you have a hardware echo canceler, just leave it be, as this one won’t be used anyway.

The default is mg2, but it may change in the future. E.g: a packager that bundles a better echo canceler may set it as the default, or dahdi_genconf will scan for the "best" echo canceler.

bri_hardhdlc: yes - forces BRI cards to use hardhdlc signalling. no - forces BRI cards to use dchan (an alias for fcshdlc). It is usefull only for dahdi with the bristuff patch.

If it is left out or set to auto: * Information supplied by the driver is used to decide: - Currently implemented for Astribanks. - Taken from /sys/bus/xpds/drivers/bri/dchan_hardhdlc. * Without this info, falls back to hardhdlc.

For MFC/R2 Support: R2 will make E1 spans CAS and with the r2_idle_bits bit in system.conf . It will also make dahdi_genconf default to generating the channels of this card in unicall.conf rather than in chan_dahdi.conf . The meaning of this may be extended somehow to support R2 through openr2/chan_dahdi later on.

Explicitly set the idle bits for E1 CAS (Sample value is the default):

Set T1 framing type to d4 instead of esf:

Use E&M on CAS (default is FXS/FXO). If set, E1 spans will be used as E&M-E1 and T1 will use the requested type:

pri_termtype contains a list of settings: Currently the only setting is for TE or NT (the default is TE). This sets two different but normally related configuration items:

A TE span will have *_cpe signalling in Asterisk and will also get timing from the remote party.

A NT span will have *_new signalling in Asterisk and will provide timing to the remote party.

pri_termtype is a list if span specs and configuration (TE/NT) for them. The first spec that matches is used. The matching is of perl regular expressions, but with * and ? have their meaning from basic regular expressions.

SPAN/2 NT SPAN/4 NT

SPAN/* NT

The file zonedata.c contains the information about the tone zones used in libtonezone (and hence also in ztcfg). Here is a list of those zones:

The directory xpp has, in addition to helper utilities for the Xorcom Astribank, a collection of perl modules to provide information related to DAHDI. The perl modules themselves are under xpp/perl_modules/ . In xpp/ there are several utilities that use those modules: - xpp-specific: dahdi_registration, xpp_sync, xpp_blink . - General: lsdahdi, dahdi_genconf, dahdi_hardware, dahdi_drivers

The DAHDI perl modules will currently only be automatically installed if you happen to install the xpp directory. Those utilities require the perl modules to be installed, however they will also look for them in the directory perl_modules, and thus can be run directly from the DAHDI source tree. For example:

To get usage information on a program, you can also use perldoc (sometimes provided in a package separate from perl itself). For instance:

Some of them are specific for the Xorcom Astribank and described in its docuemntation. the others are:

DAHDI digital cards can provide data channels through ppp as point-to-point connections. This requires a plugin to the ppp daemon that is included in the ppp/ subdirectory. To install it:

Information for upgrading from Zaptel 1.2 or 1.4 to DAHDI 2.0

Upgrading from Zaptel to DAHDI is fairly straightforward; install this package using the installation instructions, and then reconfigure and rebuild Asterisk; Asterisk 1.4 releases later than 1.4.21, and all releases of Asterisk 1.6, will automatically use DAHDI in preference to Zaptel, even if Zaptel is still installed on the system.

Important notes about upgrading:

The Zaptel package, which included both kernel modules and userspace tools for configuring and managing the modules, has been split into two packages:

In addition, there is a dahdi-linux-complete package that contains both dahdi-linux and dahdi-tools for simplified installation.

The primary kernel modules have changed names; the new names are:

It is no longer possible and needed to select a software echo canceler at compile time to build into dahdi.ko; all four included echo cancelers (MG2, KB1, SEC and SEC2) are built as loadable modules. If the Digium HPEC binary object file has been placed into the proper directory the HPEC module will be built as well.

Any or all of these modules can be loaded at the same time, and the echo canceler to be used on the system’s channels can be configured using the dahdi_cfg tool from the dahdi-tools package.

Many tool names have changed:

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.

Please report bug and patches to the Asterisk bug tracker at http://bugs.digium.com/ in the "DAHDI" category.