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