Section 4.5. Configuring an FXS Channel

4.5. Configuring an FXS Channel

The configuration of an FXS channel is similar to that of an FXO channel. Let's take a look.

4.5.1. Zaptel Hardware Configuration

The following is a minimal configuration for an FXS channel on a TDM400P. The configuration is identical to the FXO channel configuration above, with the addition of fxoks=1 .

Recall from our earlier discussion that the opposite type of signaling is used for FXO and FXS channels, so we will be configuring FXO signaling for our FXS channel. In the example below we are configuring channel 1 to use FXO signaling, with the kewlstart signaling protocol:

 fxoks=1     fxsks=2     loadzone=us     defaultzone=us 

After loading the drivers for your hardware, you can verify their state with the use of /sbin/ztcfg -vv :

 Zaptel Configuration     ======================     Channel map:     Channel 01: FXO Kewlstart (Default) (Slaves: 01)     Channel 02: FXS Kewlstart (Default) (Slaves: 02)     2 channels configured. 

4.5.2. Zapata Hardware Configuration

The following configuration is identical to that for the FXO channel, with the addition of a section for our FXS port and of the line immediate=no . The context for our FXS port is internal , the signaling is fxoks (kewlstart), and the channel number is set to 1 .

FXS channels can be configured to perform one of two different actions when a phone is taken off the hook. The most common (and often expected) option is for Asterisk to produce a dial tone and wait for input from the user . This action is configured with immediate=no . The alternative action is for Asterisk to automatically perform a set of instructions configured in the dialplan instead of producing a dial tone, which you indicate by configuring immediate=yes . ^[*] The instructions to be performed are found in the context configured for the channel and will match the s extension (both of these topics will be discussed further in the following chapter).

^[*] Also referred to as the BatPhone method, and more formally known as an Automatic Ringdown or Private Line Automatic Ringdown (PLAR) circuit . This method is commonly used at rental car counters and airports.

Here's our new 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     immediate=no     ; define channels  context=internal        ; Uses the [internal] context in extensions.conf     signalling=fxo_ks       ; Use FXO signalling for an FXS channel        channel => 1            ; Telephone attached to port 1  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 

4.5.3. Dialplan Configuration

To test our newly created Zap extension, we need to create a basic dialplan. The following dialplan contains a context called internal . This is the same context name that we configured in zapata.conf for channel 1. When we configure context=internal in zapata.conf , we are telling Asterisk where to look for instructions when a user presses digits on his telephone. In this case, the only extension number that will work is 611. When you dial 611 on your telephone, Asterisk will execute the Echo( ) application so that when you talk into the phone whatever you say will be played back to you, thereby verifying bidirectional voice.

The dialplan looks like this:

 [internal]     exten => 611,1,Answer( )     exten => 611,2,Echo( )