Segmenting A Configration File

Home » Asterisk Users » Segmenting A Configration File
Asterisk Users 7 Comments

Hi List,

I am planning a multi-tenant VoIP services system with Asterisk, using configuration tweaks. Having all the tenant configurations in one configuration file is overwhelming. I would like to segment the configuration files and include them in the main configuration file. Is it possible?

For e.g. I would like to have the main extenstions.conf file to include tenant01_extenstions.conf, tenant02_extensions.conf. By this way it is easy to manage the configurations of each tenant.


7 thoughts on - Segmenting A Configration File

  • Sure, you can include multiple files from the general extension.conf. You can do the same for the sip.conf.


    I am typing from my mobile phone… Il giorno 11/ago/2012 12:17, “Kannan” ha scritto:

  • We put each tenant’s sip and extensions config files in
    /etc/asterisk/accounts and then do an include for that directory in the main files.

    We keep all the voicemail.conf in one because changes to passwords will NOT
    be saved to included files. We used to use includes for voicemail but that meant no password changes.

    The main file has a list of all phone numbers in the system in numerical order where we set the account name, and then we send them to the proper context like this:

    exten => 12015551212,1,Set(CDR(accountcode)=johnsmith)

    exten => _X.,n(cont),Goto(${CDR(accountcode)}#did,${EXTEN},1)

    There’s a bunch of other stuff in there where we do line counting and such.

  • This is no longer the case. Starting with 1.8 a new voicemail.conf setting (passwordlocation) has been added[1] to allow you to store the passwords outside the voicemail.conf file. With this setting the password gets written to secret.conf file within spooldir for each mailbox. That way, you can then breakout each mailbox into separate config files with include statements.


  • We have developed a completely parametrised solution for one client, where she can configure contexts without ever having to touch the main Asterisk files. For each context, the dialplan checks configuration values for recording, permitting calls to various types of extensions, adding to queues, barge-in, etc and enables or disables those services depending on the parameters provided. You can even create custom extensions and invoke AGIs at runtime if you need more fine-tuning.

    All these customisations — the client’s configuration, the dialplan functions, users, etc. are in separate files, #included by the main Asterisk configurations.


    — Raj

  • One of my clients uses thirdlane. The web interface is clean and nice, but asterisk completely locks when one of the client change the config and reloads during peak hours. It is possible my client uses an old version or hasn’t applied all the patches or hasn’t configured asterisk in the right way or the underlying hardware is not enough powerful, but I’d not suggest it to manage over than few hundred peers.

    I have seen several software solutions, all configuration file based and they all have the same problem. They locks asterisk on reload, so you’ll end not altering the configuration during peak hours and you’ll avoid giving the clients the ability to change their config. The only key solution is to have a completely realtime version.


    2012/8/12 Carlos Rojas