Configuring DAHDI

The "make config" step of the Building DAHDI section should have created a set of default configuration files for DAHDI, based on the system's hardware configuration. However, if you ran "make config" before Asterisk was built and installed, some of the files needed by dahdi_genconf may have been missing and it wouldn't have generated all of the config files. So, you may want to run dahdi_genconf now to build the /etc/dahdi/system.conf and /etc/asterisk/dahdi-channels.conf files:

     su
     /usr/sbin/dahdi_genconf

If you have multiple line cards and you need to load them in a particular order (e.g. Digium X100P before TDM400P), you should edit the /etc/dahdi/modules file and order the corresponding drivers in ascending order, the way you want the line cards loaded. On the other hand, if you only have a single type of line card (or only one line card, for that matter), or you don't care which order the line cards are loaded, you can simply leave /etc/dahdi/modules as is.

The parameters in the genconf_parameters file affect the way dahdi_genconf works. Normally, you don't need to touch this file but the most likely change you might want to make is to change the base extension number that dahdi_genconf uses, so that the generated extension numbers match what you're using in your Asterisk config files. For example:

/etc/dahdi/genconf_parameters:

.

       .

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

  base_exten             600

On the other hand, we recommend running dahdi_genconf ONCE, manually, to configure the FXS, FXO and T1 lines, and then NEVER use it again. You can then edit the dahdi-channels.conf file to change extension information, etc., once it is generated the first time. If you choose to do this, you'll have complete control over how the extensions are set up. Just be sure to keep a copy of it elsewhere and/or make sure you never run dahdi_genconf. Here's an example of a single FXS entry (which uses FXO signalling), as you might wish it to appear:

/etc/asterisk/dahdi-channels.conf:

.

       .

;;; line="1 OPVXA1200/12/0 FXOKS
signalling=fxo_ks
callerid="Channel 1" <600>
mailbox=600
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

As mentined, the signalling was set to "fxo_ks" to use FXO, as well as Koolstart (see below). The "callerid" parameter is set to a string that is used to identify the channel, when caller ID information is sent, along with an extension number, in angle brackets. The "mailbox" parameter indicates which mailbox DAHDI should check for pending voicemail and generate a stutter dialtone if mail exists. The "group" parameter lets related channels be grouped together for dialing purposes. The "context" parameter assigns the context to be used in the Asterisk dial plan.

And, here's an example of a single FXO entry (which uses FXS signalling), as you might wish it to appear:

/etc/asterisk/dahdi-channels.conf:

.

       .

;;; line="9 OPVXA1200/12/8 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 9
callerid=
group=
context=default

Note that, for each generated channel, the "callerid", "mailbox", "group" and "context" parameters are set back to the defaults, after the channel is defined. You should follow this standard if you add any new channels.

We have just touched on setting up FXS and FXO channels because these are the ones that mimic those found in a basic PBX (e.g. a SOHO switch). However, the possibilites for the device types for the channels are quite extensive. You should see the information provided for the DAHDI system.conf file (below) for more information.

/etc/asterisk/chan_dahdi.conf:

Under the scheme used by dahdi_genconf, the Asterisk chan_dahdi.conf file is reserved for setting general DAHDI parameters and the included dahdi-channels.conf file is reserved for defining the individual DAHDI channels.

In the chan_dahdi.conf file, the "trunkgroups" section should be empty (for starters). The "channels" section should contain the general parameters settings and then include the dahdi-channels.conf file for configuration of the individual channels. Here's an example of the key parameters:

     [trunkgroups]
     [channels]
     usecallerid=yes
     hidecallerid=no
     callwaiting=yes
     usecallingpres=yes
     callwaitingcallerid=yes
     threewaycalling=yes
     transfer=yes
     canpark=yes
     cancallforward=yes
     callreturn=yes
     echocancel=yes
     echocancelwhenbridged=no
     faxdetect=both
     ;rxgain=0.0       ; Set this positive if you can't hear your callers or
                       ; negative if they're too loud
     ;txgain=0.0       ; Set this positive if your callers can't hear you or
                       ; negative if they think you're too loud
     group=1
     callgroup=1
     pickupgroup=1
     ; Uncomment these lines if you have problems with the disconection of your
     ; analog lines.
     ;busydetect=yes
     ;busycount=3

Note that the generated dahdi-channels.conf file should be included in the /etc/asterisk/chan_dahdi.conf configuration file. If it isn't, you should edit chan_dahdi.conf with your favorite editor and include it at the end of the file.

/etc/asterisk/chan_dahdi.conf:

.

       .

;
; Include the DAHDI channels that were generated by dahdi-genconf. ;
#include dahdi-channels.conf

Since dahdi-channels.conf is included in chan_dahdi.conf, the parameters used therein are the same as those described in the comments in chan_dahdi.conf. You can look there if you wish to understand them. Also, more information on configuring digital channels, as well as the options that can be used in both chan_dahdi.conf and dahdi-channels.conf can be found here:

     http://www.asteriskguide.com/mediawiki/index.php?title=Digital_Channels&;\
     redirect=no

The /etc/dahdi/system.conf file generated by dahdi_genconf is usually OK to use as is. However, you may wish to check that the "loadzone" and "defaultzone" parameters are correctly set to your country.

/etc/dahdi/system.conf:

.

       .

# Global data

     loadzone        = us
     defaultzone     = us

The dahdi_genconf generated file should pick the correct device type for all of your installed cards. Here is a list of the possibilites:

     e&m       Channels 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.
     e&me1     Channels are signalled using E&M signalling on an E1 line.
     fxsls     Channels are signalled using FXS Loopstart (see below) protocol.
     fxsgs     Channels are signalled using FXS Groundstart (see below)
               protocol.
     fxsks     Channels are signalled using FXS Koolstart (see below) protocol.
     fxols     Channels are signalled using FXO Loopstart (see below) protocol.
     fxogs     Channels are signalled using FXO Groundstart (see below)
               protocol.
     fxoks     Channels are signalled using FXO Koolstart (see below) protocol.
     sf        Channels are signalled using in-band single frequency tone.
               The syntax is as follows:
            ch# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
            rxfreq - rx tone frequency in Hz
            rxbw - rx notch (and decode) bandwith in hz (typically 10.0)
            rxflag - either 'normal' or 'inverted'
            txfreq - tx tone freq in hz
            txlevel - tx tone level in dbm
            txflag - either 'normal' or 'inverted'.
            Set rxfreq or txfreq to 0.0 if that tone is not desired.
     unused    No signalling is performed, each channel in the list remains idle.
     clear     Channels are bundled into a single span. No conversion or
               signalling is performed, and raw data is available on the master.
     bchan     Like clear except all channels are treated individually and are
               not bundled. inclear is an alias for this.
     rawhdlc   The DAHDI driver performs HDLC encoding and decoding on the
               bundle, and the resulting data is communicated via the master
               device.
     dchan     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.
     hardhdlc  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.
     nethdlc   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.
               Syntax:
            nethdlc=<channel list>[:interface name]
            Use original names, don't use the names which have been already
            registered in the system (e.g eth).
     dacs      The DAHDI driver cross connects the channels starting at the
               channel number listed at the end, after a colon.
     dacsrbs   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 three choices for the line start method, used on the FXS or FXO lines, are:

     Loopstart    The original analog circuit made the connection between the
                  customer premises and the central office, using two copper
                  wires. Typically there is a -48 VDC signal between the two
                  wires which is powered by the central office switch. When
                  the phone goes off hook, a switch on the phone closes the
                  connection between the two wires and current is drawn from
                  the central office switch. The switch determines that current
                  is being drawn and provides a dial tone. Loopstart does not
                  include hangup notification unless specifically done through
                  forward disconnect.
     Groundstart  One problem that was identified with loop start circuits is
                  a condition known as glare, which occurs when a call is
                  switched to the analog line at the central office, at the
                  same time that the phone goes off hook to make an outgoing
                  call. The ground start protocol was designed to eliminate the
                  glare problem. From the phone side, the ring lead is grounded
                  first. Then the central office circuit must ground the tip
                  lead before the switch can close the loop between tip and
                  ring. Ground start lines always have a little current runing
                  through them and the additional hardware drives up costs.
                  However, this format allows for signaling when shorting the
                  line to ground (one of the biggest uses of ground start was
                  in pay phones, where a ground start line could send variable
                  pulses to indicate the money being deposited, before the
                  switch sends a dial tone to the phone). Ground start does
                  include hangup notification.
     Koolstart    Koolstart is also known as Disconnect Supervision, and is
                  the line start method that you usually want to use for FXO
                  devices. If your phone provider doesn't support it, the
                  FXO device will not detect that the other side has hung up
                  and Asterisk will continue to service the port. If you can't
                  get your Telco to give you Disconnect Supervision on your
                  line there are workaround that are possible.

DAHDI uses modular echo cancellers that are configured on a per channel basis. The echo cancellers are compiled and installed as part of the dahdi-linux package. You can specify in the system.conf file the echo canceller to be used for each channel. The default behavior is for there to be no echo canceller on any channel. Since running without echo cancellation is not likely to give good results, it is important that you specify an echo canceller for each channel, if the line cards do not have built-in hardware echo cancellation.

The choices for echo cancellers are:

     mg2    This is the default echo canceller that is provided by the DAHDI
            driver. It does a fair to middling job of echo cancellation. It was
            hacked from the original Zaptel echo canceller by Michael Gernoth.
            Until the oslec echo canceller is widely available, this is probably
            the best we're going to get.
     kb1    This was the original Zaptel echo canceller by Kris Boutilier.
            Additional background on the techniques used in this echo canceller
            (as well as mg2) can be found in: Messerschmitt, David; Hedberg,
            David; Cole, Christopher; Haoui, Amine; Winship, Peter; "Digital
            Voice Echo Canceller with a TMS32020," in Digital Signal Processing
            Applications with the TMS320 Family, pp. 415-437, Texas Instruments,
            Inc., 1986. A PDF of this document is available by searching on the
            document title at http://www.ti.com/. It was hacked by Michael
            Gernoth to form mg2, which is supposed to be better.
     sec    Steve's echo canceller. An echo canceller, suitable for electrical
            and acoustic cancellation. This echo canceller does not currently
            comply with any relevant standards (e.g. G.164/5/7/8). It was
            written by Steve Underwood, with various optimizations and
            improvements by Mark Spencer and is based on a bit from here, a bit
            from there, eye of toad, ear of bat, etc. - plus, of course, his own
            2 cents.
     sec2   Steve's 2nd echo canceller. An echo canceller, suitable for
            electrical and acoustic cancellation. This echo canceller does not
            currently comply with any relevant standards (e.g. G.164/5/7/8). It
            was written by Steve Underwood and is based on a bit from here, a
            bit from there, eye of toad, ear of bat, etc. - plus, of course, his
            own 2 cents.
     jpah   An echo canceller based on mg2, sort of, by Jason Parker. According
            to Jason, this echo canceller will completely hose your audio. Don't
            use it unless you're absolutely sure you know what you're doing.
     hpec   This a proprietary high performance echo canceller which must be
            compiled in. It only works with Digium hardware. You'll probably
            want to use oslec instead, anyway.
     olsec  An open source high performance line echo canceller. When used
            with Asterisk it works well on lines where the built-in Zaptel
            echo canceller fails. No tweaks like rxgain/txgain or fxotrain
            are required. Oslec is supplied as GPL licensed C source code and
            is free as in speech. Oslec partially complies with the G168
            standard and runs in real time on x86 and Blackfin platforms.
            Patches exist to allow any Zaptel compatible hardware to use
            Oslec. It has been successfully tested on hardware ranging from
            single port X100P FXO cards to dual E1 systems. Hardware tested
            includes TDM400, X100P, Sangoma A104, Rhino E1 etc. It also works
            well on the IP04 embedded Asterisk platform. Michael Gernoth, the
            creator of mg2, says its better than mg2.

More information of echo cancellers can be found at:

     http://www.voip-info.org/wiki/view/Asterisk+echo+cancellation

The DAHDI startup script in init.d uses some configuration parameters that are defined in /etc/dahdi/init.conf. Generally, the parameter values set therein are adequate for most uses and will not need to be adjusted. However, you may need to adjust the time to wait for UDEV if you have a lot of lines, the startup is slow, etc. The default is 40 seconds, which should be ample but you might set it to something longer (e.g. 100 seconds).

/etc/dahdi/init.conf:

.

       .

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

After you've configured DAHDI, reboot your system. Some of the DAHDI parameters do not get reset upon reload so reboot is the best course of action. If you want to check that the DAHDI channels are set up properly, you can attach to the running Asterisk process and send it a show command:

     su
     /usr/sbin/asterisk -rx 'dahdi show channels'

If you saw the DAHDI channels, they have been loaded properly. The listing should look something like this:

     Chan Extension  Context       Language  MOH Interpret  Blocked  State     
   pseudo            default                 default                 In Service
        1            from-internal           default                 In Service
        2            from-internal           default                 In Service
        3            from-internal           default                 In Service
        4            from-internal           default                 In Service
        5            from-internal           default                 In Service
        6            from-internal           default                 In Service
        7            from-internal           default                 In Service
        8            from-internal           default                 In Service
        9            from-pstn               default                 In Service
       10            from-pstn               default                 In Service
       11            from-pstn               default                 In Service
       12            from-pstn               default                 In Service