Asterisk: The Future of Telephony, 2nd Edition

Working with Interface Configuration Files

In this chapter, we’re going to build an Asterisk configuration on the platform we have just installed. For the first few sections on FXO and FXS channels, we’ll assume that you have a Digium TDM11B kit (which comes with one FXO and one FXS interface). This will allow you to connect to an analog circuit (FXO) and to an analog telephone (FXS). Note that this hardware interface isn’t necessary; if you want to build an IP-only configuration, you can skip to the section on configuring SIP after reading the section on creating configuration files..

The configuration we do in this chapter won’t be particularly useful on its own, but it will be a kernel to build on. We’re going to touch on the following files:

zaptel.conf

Here, we’ll do low-level configuration for the hardware interface. We’ll set up one FXO channel and one FXS channel. This configures the driver for the Linux kernel.

zapata.conf

In this file, we’ll configure Asterisk’s interface to the hardware. This file contains a slightly higher-level configuration of the hardware in the Asterisk user-level process.

extensions.conf

The dialplans we create will be extremely primitive, but they will prove that the system is working.

sip.conf

This is where we’ll configure the SIP protocol.

iax.conf

This is where we’ll configure incoming and outgoing IAX channels.

In the following sections, you will be editing several configuration files. You’ll have to reload these files for your changes to take effect. After you edit the zaptel.conf file, you will need to reload the configuration for the hardware with /sbin/ztcfg -vv (you may omit the -vv if you don’t need verbose output). Changes made in zapata.conf will require a module reload from the Asterisk console; however, changing signaling methods requires a restart. You will need to perform an iax2 reload and a sip reload after editing the iax.conf and sip.conf files, respectively.

In order to test the new devices we have defined, we must have a dialplan through which we can make connections. Even though we have not discussed the Asterisk dialplan (that’s coming up in the next chapter), we want you to create a basic extensions.conf file so that we can test our work in this chapter.

Make a backup copy of the sample extensions.conf (try the bash command mv extensions.conf extensions.conf.sample), and then create a blank extensions.conf file (using the bash command touch extensions.conf), and insert the following lines:

[globals]

[general]
autofallthrough=yes

[default]

[incoming_calls]

[internal]

[phones]
include => internal

Note

In the [general] section, we have set autofallthrough=yes, which tells Asterisk to continue when an extension runs out of things to do. If you set this to no, then Asterisk will sit and wait for input after all priorities have executed. This is most prevalent if the Background() application is the last application executed in an extension. If set to yes (which is now the default in 1.4), Asterisk will drop the call after Background() finishes executing (at the end of the prompt(s) supplied to it). In order to force Asterisk to wait for input after the Background() application finishes playing the voice prompts supplied to it, we use the WaitExten() application.

Do not be afraid if what we’ve just written doesn’t make a whole lot of sense, as we haven’t explored the dialplan, applications, priorities, or extensions yet (that is coming up in the next chapter). So for now, just set autofallthrough=yes. It is safest to use the autofallthrough=yes command as we don’t want Asterisk hanging around waiting for input unless we explicitly tell it to do so.

There is nothing else for now, but we’ll be using this file as we go through this chapter to build a test dialplan so we can ensure that all of our devices are working. Also, be sure to run the dialplan reload command from the Asterisk CLI to update to the latest changes. Verify your changes by running the CLI command dialplan show:

*CLI> dialplan show
[ Context 'phones' created by 'pbx_config' ]
  Include =>        'internal'                                    [pbx_config]

[ Context 'internal' created by 'pbx_config' ]

[ Context 'incoming_calls' created by 'pbx_config' ]

[ Context 'default' created by 'pbx_config' ]

[ Context 'parkedcalls' created by 'res_features' ]
  '700' =>          1. Park((null))                               [res_features]

-= 1 extension (1 priority) in 5 contexts. =-

Note

You will see the parkedcalls context because it is an internal context to Asterisk, specified in the features.conf file.