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:

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.^[53] Ground start is really a rather strange thing, because it doesn’t exist in its analog form in Asterisk, so technically, there is no ground signal happening, but is rather a signaling bit that is intended for analog circuitry that historically would have been at the end of the T1. If this does not make much sense, don’t sweat it; chances are you won’t have to worry about ground-start signaling. 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.^[54] Kewlstart is the preferred signaling protocol for analog circuits in Asterisk.

To configure a signaling method other than kewlstart, replace the ks in fxsks with either ls or gs (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 of 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. modprobe is used to load modules for use by the Linux kernel. For example, to load the wctdm driver, you would run:

# modprobe wctdm         

If the drivers load without any output, they have loaded successfully.^[55] You can verify that the hardware and ports were loaded and configured correctly with the use of the ztcfg program:

# /sbin/ztcfg -vv         

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 (or there is no hardware present at that address):

ZT_CHANCONFIG failed on channel 2: Invalid argument (22)
Did you forget that FXS interfaces are configured with FXO signaling
and that FXO interfaces use FXS signaling?

To unload drivers from memory, use the rmmod (remove module) command, like so:

# rmmod wctdm         

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
signaling=fxs_ks       ; Use FXS signaling for an FXO channel
channel => 2            ; PSTN attached to port 2

The [trunkgroups] section is used for connections where multiple physical lines are used as a single logical connection to the telephone network, and won’t be discussed further in this book. If you require this type of functionality, see the zapata.conf.sample file and your favorite search engine for more information.

The [channels] section 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 of 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 callwaiting=no. 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, Understanding Telephony) 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 three-way calling.

Allowing call transfer with a hook switch is accomplished by configuring transfer=yes; it 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 (echotraining=yes). 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 extensions.conf.

Finally, since an FXO channel uses FXS signaling, we define it as such with signaling=fxs_ks.

The following minimal dialplan makes use of the Echo() application to verify that bidirectional communications for the channel are working:

[incoming]
; incoming calls from the FXO port are directed to this context 
;from zapata.conf
exten => s,1,Answer()
exten => s,n,Echo()

Whatever you say, the Echo() 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.