Section 4.4. Configuring an FXO Channel

4.4. Configuring an FXO Channel

We'll start by configuring an FXO channel. First we'll configure the Zaptel hardware , and then the Zapata hardware. We'll set up a very basic dialplan, and we'll show you how to test the channel.

4.4.1. Zaptel Hardware Configuration

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 ( ls )

• Ground start ( gs )

• Kewlstart ( ks )

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.

^[*] 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.

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 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. ^[*] You can verify that the hardware and ports were loaded and configured correctly with the use of the ztcfg program:

^[*] 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 scriptsee the previous chapter for details).

 #  /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:

 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 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 

4.4.2. Zapata Hardware Configuration

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 

The [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 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 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) 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 signalling=fxs_ks .

4.4.3. Dialplan Configuration

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,2,Echo( ) 

Whatever you say, the Echo( ) application will relay back to you.

4.4.4. Dialing in

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.