Anyone still using the ACID version of the software?

I am tracing down a issue and I need a copy of /etc/dahdi/system.conf

If anyone could post the contents of that file, I might kiss you (don’t count on it)

My old backups do not include that.

Thanks in advance

DAHDI Configuration File

This file is parsed by the DAHDI Configurator, dahdi_cfg

Span Configuration


First come the span definitions, in the format

span=,,<line build out (LBO)>,,[,yellow]

All T1/E1/BRI spans generate a clock signal on their transmit side. The

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.

NOTE: The B410P card cannot reliably connect one of its four ports

configured in TE mode to another one configured in NT mode. It will not

reliably sync clock from itself. Please use another physical card and

configure one to provide clock and one to recover clock in any B410P test


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

0: 0 db (CSU) / 0-133 feet (DSX-1)

1: 133-266 feet (DSX-1)

2: 266-399 feet (DSX-1)

3: 399-533 feet (DSX-1)

4: 533-655 feet (DSX-1)

5: -7.5db (CSU)

6: -15db (CSU)

7: -22.5db (CSU)

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

to 0.


one of ‘d4’ or ‘esf’ for T1 or ‘cas’ or ‘ccs’ for E1. Use ‘ccs’ for BRI.

‘d4’ could be referred to as ‘sf’ or ‘superframe’


one of ‘ami’ or ‘b8zs’ for T1 or ‘ami’ or ‘hdb3’ for E1. Use ‘ami’ for


* For E1 there is the optional keyword ‘crc4’ to enable CRC4 checking.

* If the keyword ‘yellow’ follows, yellow alarm is transmitted when no

channels are open.


Dynamic Spans


Next come the dynamic span definitions, in the form:


Where is the name of the driver (e.g. eth), is the

driver specific address (like a MAC for eth), is the number

of channels, and 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.

Channel Configuration


Next come the definitions for using the channels. The format is:


Valid devices are:


Channel(s) are signalled using E&M signalling on a T1 line.

Specific implementation, such as Immediate, Wink, or Feature

Group D are handled by the userspace library.


Channel(s) are signalled using E&M signalling on an E1 line.


Channel(s) are signalled using FXS Loopstart protocol.


Channel(s) are signalled using FXS Groundstart protocol.


Channel(s) are signalled using FXS Koolstart protocol.


Channel(s) are signalled using FXO Loopstart protocol.


Channel(s) are signalled using FXO Groundstart protocol.


Channel(s) are signalled using FXO Koolstart protocol.


Channel(s) are signalled using in-band single freq tone.

Syntax as follows:

channel# => sf:,,,,,

rxfreq is rx tone freq in Hz, rxbw is rx notch (and decode)

bandwith in hz (typically 10.0), rxflag is either ‘normal’ or

‘inverted’, txfreq is tx tone freq in hz, txlevel is tx tone

level in dbm, txflag is either ‘normal’ or ‘inverted’. Set

rxfreq or txfreq to 0.0 if that tone is not desired.


No signalling is performed, each channel in the list remains idle


Channel(s) are bundled into a single span. No conversion or

signalling is performed, and raw data is available on the master.


Like ‘clear’ except all channels are treated individually and

are not bundled. ‘inclear’ is an alias for this.


The DAHDI driver performs HDLC encoding and decoding on the

bundle, and the resulting data is communicated via the master



The DAHDI driver performs HDLC encoding and decoding on the

bundle and also performs incoming and outgoing FCS insertion

and verification. ‘fcshdlc’ is an alias for this.


The hardware driver performs HDLC encoding and decoding on the

bundle and also performs incoming and outgoing FCS insertion

and verification. Is subject to limitations and support of underlying

hardware. BRI spans serviced by the wcb4xxp driver must use hardhdlc

channels for the signalling channels.


The DAHDI driver bundles the channels together into an

hdlc network device, which in turn can be configured with

sethdlc (available separately). In 2.6.x kernels you can also optionally

pass the name for the network interface after the channel list.


nethdlc=[:interface name]

Use original names, don’t use the names which have been already registered

in system e.g eth.


The DAHDI driver cross connects the channels starting at

the channel number listed at the end, after a colon


The DAHDI driver cross connects the channels starting at

the channel number listed at the end, after a colon and

also performs the DACSing of RBS bits

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


1,3,5 (channels one, three, and five)

16-23, 29 (channels 16 through 23, as well as channel 29)

So, some complete examples are:





An example of BRI port:




NOTE: When using BRI channels in asterisk, use the bri_cpe, bri_net, or

bri_cpe_ptmp (for point to multipoint mode). libpri does not currently

support point to multipoint when in NT mode. Otherwise, the bearer channel

are configured identically to other DAHDI channels.


Tone Zone Data


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=” where the zone is a two letter country code.

You may also specify a default zone with “defaultzone=” where zone

is a two letter country code.

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

loadzone = us
#loadzone = us-old

PCI Radio Interface


(see app_rpt -- Radio Repeater/Remote Base)

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


Overiding PCM encoding


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.


Echo Cancellers


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.

Valid echo cancellers are: hwec, mg2, kb1, sec2, and sec.

‘hwec’ is a special echo canceller that should be used if hardware echo

cancellation is desired on and available on the specified channels.

If compiled, ‘hpec’ is also a valid echo canceller.

To configure the default echo cancellers, use the format:



Configure channels 1 through 8 to use the mg2 echo canceller


And change channel 2 to use the kb1 echo canceller.


I have ACID running on node 28599 but no dahdi, sorry. I don’t think dahdi was around when ACID was out
GeorgeC W2DB