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