The zaptel.conf file located in /etc/ is used to configure your hardware. The following minimal configuration defines an FXO port with FXS signaling:
fxsks=2 loadzone=us defaultzone=us
In the first line, in addition to indicating whether we are using FXO or FXS signaling, we specify one of the following protocols for channel 2:
Loop start (
Ground start (
The difference between loop start and ground start has to do with how the equipment requests a dial tone: a ground start circuit signals the far end that it wants a dial tone by momentarily grounding one of the leads; a loop start circuit uses a short to request a dial tone. Though not common for new installations, analog ground start lines still exist in many areas of the country. For example, ground start lines are predominately used to reduce a condition known as “glare " that is associated with loop start lines and PBXs with high call volumes. All home lines (and analog telephones/modems/faxes) in North America use loop start signaling. Kewlstart is in fact the same as loop start, except that it has greater intelligence and is thus better able to detect far-end disconnects . Kewlstart is the preferred signaling protocol for analog circuits in Asterisk.
To configure a signaling method other than kewlstart, replace
fxsks with either
(for loop start or ground start, respectively).
loadzone configures the set of indications (as configured in
zonedata.c) to use for the channel. The
zonedata.c file contains information about all
the various sounds that a phone system makes in a particular country:
dial tone, ringing cycles, busy tone, and so on. When you apply a
loaded tone zone to a Zap channel, that channel will mimic the
indications for the specified country. Different indication sets can
be configured for different channels. The
defaultzone is used if no zone is specified
for a channel.
After configuring zaptel.conf, you can load
the drivers for the card.
is used to load modules for use by the Linux kernel. For example, to
load the wctdm driver, you would run:
If the drivers load without any output, they have loaded successfully. You can verify that the hardware and ports were loaded and configured correctly with the use of the ztcfg program:
The channels that are configured and the signaling method being used will be displayed. For example, a TDM400P with one FXO module has the following output:
Zaptel Configuration ====================== Channel map: Channel 02: FXS Kewlstart (Default) (Slaves: 02) 1 channels configured.
If you receive the following error, you have configured the channel for the wrong signaling method:
ZT_CHANCONFIG failed on channel 2: Invalid argument (22) Did you forget that FXS interfaces are configured with FXO signalling and that FXO interfaces use FXS signalling?
To unload drivers from memory, use the
rmmod (remove module) command, like
The zttool program is a diagnostic tool used to determine the state of your hardware. After running it, you will be presented with a menu of all installed hardware. You can then select the hardware and view the current state. A state of “OK” means the hardware is successfully loaded:
Alarms Span OK Wildcard TDM400P REV E/F Board 1
Asterisk uses the zapata.conf file to determine the settings and configuration for telephony hardware installed in the system. The zapata.conf file also controls the various features and functionality associated with the hardware channels, such as Caller ID, call waiting, echo cancellation, and a myriad of other options.
When you configure zaptel.conf and load the modules, Asterisk is not aware of anything you’ve configured. The hardware doesn’t have to be used by Asterisk; it could very well be used by another piece of software that interfaces with the Zaptel modules. You tell Asterisk about the hardware and control the associated features via zapata.conf:
[trunkgroups] ; define any trunk groups [channels] ; hardware channels ; default usecallerid=yes hidecallerid=no callwaiting=no threewaycalling=yes transfer=yes echocancel=yes echotraining=yes ; define channels context=incoming ; Incoming calls go to [incoming] in extensions.conf signalling=fxs_ks ; Use FXS signalling for an FXO channel channel => 2 ; PSTN attached to port 2
[trunkgroups] section is
for NFAS and GR-303 connections, and it won’t be discussed in this
book. If you require this type of functionality, see the
zapata.conf.sample file for more
determines the signaling method for hardware channels and their
options. Once an option is defined, it is inherited down through the
rest of the file. A channel is defined using
channel =>, and each channel definition
inherits all the options defined above that line. If you wish to
configure different options for different channels, remember that the
options should be configured before the
channel => definition.
We’ve enabled Caller ID with
usecallerid=yes and specified that it will
not be hidden for outgoing calls with
hidecallerid=no. Call waiting is deactivated
on an FXO line with
Enabling three-way calling with
threewaycalling=yes allows an active call to
be placed on hold with a hook switch flash (discussed in Chapter 7) to suspend the current
call. You may then dial a third party and join them to the
conversation with another hook switch. The default is to not enable
Allowing call transfer with a hook switch is accomplished by
requires that three-way calling be enabled. The Asterisk echo
canceller is used to remove the echo that can be created on analog
lines. You can enable the echo canceller with
echocancel=yes. The echo canceller in
Asterisk requires some time to learn the echo, but you can speed this
up by enabling echo training (
This tells Asterisk to send a tone down the line at the start of a
call to measure the echo, and therefore learn it more quickly.
When a call comes in on an FXO interface, you will want to
perform some action. The action to be performed is configured inside a
block of instructions called a context. Incoming
calls on the FXO interface are directed to the
incoming context with
context=incoming. The instructions to
perform inside the context are defined within
Finally, since an FXO channel uses FXS signaling, we define it
as such with
[incoming] ; incoming calls from the FXO port are directed to this context from zapata.conf exten => s,1,Answer() exten => s,2,Echo()
Whatever you say, the
application will relay back to you.
Now that the FXO channel is configured, let’s test it. Run the zttool application and connect your PSTN line to the FXO port on your TDM400P. Once you have a phone line connected to your FXO port, you can watch the card come out of a RED alarm.
Now dial the PSTN number from another external phone (such as a
cell phone). Asterisk will answer the call and execute the
Echo() application. If you can hear your
voice being reflected back, you have successfully installed and
configured your FXO channel.
 Yes, there is such a thing as ground start signaling on channelized T-1s, but that has nothing to do with an actual ground condition on the circuit (which is entirely digital).
 When a call is initiated from one end of a circuit at the same approximate time a call is initiated from the opposite end of the circuit.
 A far-end disconnect happens when the far end hangs up. In an unsupervised circuit, there is no method of telling the near end that the call has ended. If you are on the phone this is no problem, since you will know the call has ended and will manually hang up your end. If, however, your voicemail system is recording a message, it will have no way of knowing that the far end has terminated and will thus keep recording silence, or even the dial tone or reorder tone. Kewlstart can detect these conditions and disconnect the circuit.
 It is generally safe to assume that the modules have loaded successfully, but to view the debugging output when loading the module, check the console output (by default this is located on TTY terminal 9, but this is configurable in the safe_asterisk script—see the previous chapter for details).