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.
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:
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.
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.
The dialplans we create will be extremely primitive, but they will prove that the system is working.
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
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. =-
You will see the parkedcalls
context because it is an internal context to Asterisk, specified in
the features.conf file.