Asterisk “virtual Hosting”

Home » Asterisk Users » Asterisk “virtual Hosting”
Asterisk Users 4 Comments

Hello,

I am in the peculiar situation to have to set up a PBX for two independent sites, but operated by the same entity. Yes, I could set up two VPSs and install Asterisk to each, put common stuff (e.g. conferencing setup) into Git and share between both using includes, but for various reasons (among them simplicity and cost), I’d prefer a single Asterisk instance.

I know I can #include files from sip.conf and extensions.conf, so making a extensions.conf that consists of

#include ext-common.conf
#include foo/extensions.conf
#include bar/extensions.conf

is trivial. Unfortunately, the contexts in each of these files must not clash, and so I will be forced to use e.g. [bar-incoming] in bar/extensions.conf.

That’s a bit of redundancy here (which I am always trying to avoid like the plague) and I am wondering if there are better ways. Do you know of any, short of writing a script to “compile” the files and change the contexts based on path (which will be dirty and hard to get right)?

Thanks,

4 thoughts on - Asterisk “virtual Hosting”

  • I use a preprocessor
    (http://software.hixie.ch/utilities/unix/preprocessor/) to tailor dialplans and configuration files to each host based on the client
    (or project) and the hostname.

    This lets me do stuff like:

    [globals]
    DATABASE-DATABASE = @DATABASE_DATABASE@
    DATABASE-PASSWORD = @DATABASE_PASSWORD@
    DATABASE-PRODUCTION-SERVER = @DATABASE_PRODUCTION_SERVER@
    DATABASE-REPORTING-SERVER = @DATABASE_REPORTING_SERVER@
    DATABASE-ROOT-PASSWORD = @DATABASE_ROOT_PASSWORD@
    DATABASE-USERNAME = @DATABASE_USERNAME@

    and

    #ifdef A11
    exten = s,n, execif($[${ACCEPT-COUNTER} < 0]?hangup) #else exten = s,n, execif($[${ACCEPT-COUNTER} < 0],hangup) #endif

  • also sprach Steve Edwards [2015-05-16 23:22 +0200]:

    Yeah sure, templating works, but it introduces a layer of complexity that can make debugging hard(er).

    I just had the following alternative ideas.

    – when #include parses a file, prefix all stanzas found therein
    with text derived from the path, e.g.

    * #include foo/extensions.conf → “foo-”
    * #include bar.conf → “bar-”
    * #include foo/bar/moo.conf → “foo-bar-moo-“

    – if e.g. a context includes another context using a path
    separator, then the [common] context is looked up in a different
    location:

    * include foo/common → “foo/extensions.conf”
    * include foo/bar/common → “foo/bar/extensions.conf:foo/bar.conf”

    The same logic could be applied e.g. in the arguments of the
    Dial() application or local channels or registry instructions in
    sip.conf.

    The first is probably easier to implement, while the second is clearer to the user.

    Is this something to consider?

  • also sprach Steve Edwards [2015-05-17 08:31 +0200]:

    Fair point. Preprocessing it shall be.

    Hehe. The difference is that e.g. when encountering a problem, in your situation one always has to look at the preprocessor output, identify the issue, and then translate it into a fix in the input. Whereas with hierarchical includes, the files you edit are the same files Asterisk reads and hence this can be taken into account e.g. in log messages etc.

    You know the Henry Ford quote about faster horses, right? 😉

    […]

    Yeah, and it’s nicely done. Arguably it’s still a hack and debugging becomes an indirect process (see above). But sure, it’ll probably be the best solution for now.

    … although I believe Asterisk would benefit from better namespace separation between sets of registrations/contexts.