Asterisk: The Future of Telephony, 2nd Edition

Appendix D. Configuration Files

Tip

This appendix contains a reference to the configuration files not covered in the previous appendices. If you are looking for VoIP channel configurations, refer to Appendix A. For a dialplan reference, you’ll want to use Appendix B.

A configuration file is required for each Asterisk module you wish to use. These .conf files contain channel definitions, describe internal services, define the locations of other modules, or relate to the dialplan. You do not need to configure all of them to have a functioning system, only the ones required for your configuration. Although Asterisk ships with samples of all of the configuration files, it is possible to start Asterisk without any of them. This will not provide you with a working system, but it clearly demonstrates the modularity of the platform.

If no .conf files are found, Asterisk will make some decisions with respect to modules. For example, the following steps are always taken:

• The Asterisk Event Logger is loaded, and events are logged to /var/log/asterisk/event_log.

• Manager actions are registered.

• The PBX core is initialized.

• The RTP port range is allocated from 5,000 through 31,000.

• Several built-in applications are loaded, such as Answer(), Background(), GotoIf(), NoOp(), and Set().

• The dynamic loader is started; this is the engine responsible for loading modules defined in modules.conf.

This appendix starts with an in-depth look at the modules.conf configuration file. We’ll then briefly examine all the other files that you may need to configure for your Asterisk system.

modules.conf

The modules.conf file controls which modules are loaded or not loaded at Asterisk startup. This is done through the use of the load => or noload => constructs.

Tip

This file is a key component to building a secure Asterisk installation: best practice suggests that only required modules be loaded.

The modules.conf file always starts with the [modules] header. The autoload statement tells Asterisk whether to automatically load all modules contained within the modules directory or to load only those modules specifically defined by load => statements. We recommend you manually load only those modules you need, but many people find it easier to let Asterisk attempt to autoload whatever it finds in /usr/lib/asterisk/modules. You can then exclude^[164] certain modules with noload => statements.

Here’s a sample modules.conf file:

[modules]
    autoload=no                ; set this to yes and Asterisk will load any
                               ; modules it finds in /usr/lib/asterisk/modules

    load => res_adsi.so
    load => pbx_config.so      ; Requires: N/A
    load => chan_iax2.so       ; Requires: res_crypto.so, res_features.so
    load => chan_sip.so        ; Requires: res_features.so
    load => codec_alaw.so      ; Requires: N/A
    load => codec_gsm.so       ; Requires: N/A
    load => codec_ulaw.so      ; Requires: N/A
    load => format_gsm.so      ; Requires: N/A
    load => app_dial.so        ; Requires: res_features.so, res_musiconhold.so

Since we assume Asterisk is built on Linux, all the module names we use end in a .so extension. However, this may not be the case if you have built Asterisk on a different operating system.

As of this writing, there are eight module types: resources, applications, Call Detail Record database connectors, channels, codecs, formats, PBX modules, and standalone functions.

---

^[164] With the advent of the new menuselect system, this best practice may no longer be necessary if you are building only the modules you need in the first place