Managing Complex Setups With Asterisk

Home » Asterisk Users » Managing Complex Setups With Asterisk
Asterisk Users 23 Comments


we are finally going to redesign our Asterisk-Setup, which has grown quite complex. We have five sites with a total of 400 users, 15 SIP
registrations and 3 IAX registrations. We do not use any VoIP-hardware, so it’s all software-based. But we make heavy use of features, including voicemail, followme, conferencing, call-recording, and queuing.

As I said, the configuration has grown quite complex — so complex that we are all a bit scared to touch it. It works, but as we are now adding a sixth site and upgrading the hardware, we thought it would be a good opportunity to get the sixth site up and running on a new box, then migrate the other sites.

Now we are trying to figure out how to organise sip.conf, iax.conf and extensions.conf. I read about Realtime configuration, but I was a bit disappoointed because it’s really just moving the section-key-value store from the flat files to a relational database without really making use of any relational features. Sure, it’s realtime thereafter, but not any less complex.

So what to do? Does anyone have a similar setup and would like to offer a glance into their configs? Are there best practices? Or is there maybe even software (Linux) to manage setups?


23 thoughts on - Managing Complex Setups With Asterisk

  • Can Asterisk do virtual hosting? While I want/need the sites to be hosted by the same instance (so that e.g. calls can be transferred easily), I don’t want to have to name my peers [site1-john], and I want people to be able to SIP-dial and and trust that Asterisk knows what to do.


  • martin f krafft wrote:

    Peer names have to be distinct, this is just a fundamental design element of chan_sip. What a lot of people end up doing is instead of treating peers as people they treat them as devices. The peer name becomes the MAC address of the device they have been assigned.

    Since peer names are not the same as extensions though you can certainly have multiple john extensions on different domains. You need to create different contexts which route them accordingly and then map the domains to the contexts in sip.conf

    Take a gander at sip.conf.sample – specifically the SIP DOMAIN SUPPORT
    section and you’ll see what I mean.


  • also sprach Joshua Colp [2012.11.07.1831 +0100]:

    Especially in combination with users.conf, this can become quite cumbersome.

    Also, it solves the sip.conf problem, but in extensions.conf, your contexts still need to encode the locality/domain, e.g.
    [site1-phones], [site2-outgoing] and [incoming-to-site3]. This is all doable, with prefixes and #includes, but it requires more discipline than if Asterisk would simply learn to virtually host. 😉

    Also, when users have multiple devices, then handing out two sets of credentials is a bit of a pain. I realise that this is not specific to your suggestion, but I do recall a university using Asterisk that provided 10 logins for everyone, i.e. if my username was 12345, then
    12345[0-9] would all be valid SIP login names using the same password. Any idea how this was done? 10 stanzas? 😉

  • martin f krafft wrote:

    “Simply” doesn’t cover the amount of work required to do that. Months would be required most likely. It’s not a worthwhile investment when it can be done like above right now. It’s essentially pushing the responsibility and burden away from the user of Asterisk to the developers of Asterisk, and over the years I’ve only heard from approximately three people who really wanted that ^_^. I’m not saying it wouldn’t be nice for some people, but it’s just not feasible ‘nor something a vast majority want like you have expressed.

    Yes, or they had a SIP registrar in front which allowed multiple AORs
    (registrations) per account. This is another design limitation in the way chan_sip has been written.


  • Just to chime in, if you REALLY want multi-tenant, it is super easy and surprisingly efficient to use kernel level virtualization to run multiple instances of asterisk (and even FreePBX). We use LXC to do this. The “host” runs an instance that has the dahdi hardware, drivers, and upstream connections. The “clients” have SIP connections to the host for all inbound/outbound, so you have a central place to collect/process CDR records for billing. Getting your phones to connect to each instance is an exercise for the network admin 😉

    Much simpler than working out multiple contexts, extension overlaps, etc., IMO.


  • 2012-11-07 20:49, Jeff LaCoursiere skrev:

    Any quirks / observations you have running LXC? We run OpenVZ now with the same setup and it works very well. But as Debian will not support OpenVZ in the next version we are looking for alternate solutions..

    Do you run Dahdi run Dahdi for timing / meetme on both the “host” (HN)
    and the “clients” (VE)?


    Any other pitfalls or recommendations with LXC?

  • What is your point of pain? Right now we do most of the configuration, provisioning, and system management outside of asterisk.

    So, for example here is how we handle the initial configuration and provisioning, we use puppet[1]. Leif and I did a talk at astricon[2]
    about it.

    System management is another issue, but we mostly use puppet or external agi / database to control certain _dynamic_ features.

    Either way, don’t manually build your 6th machine. Start from fresh using some sort of automated tool (chef / puppet). This will help you get on the right path.


  • Since moving to Ubuntu 12.04 server, LXC mgmt has been much simpler and stable. Had some troubles with Ubuntu 10, though that was our proof-of-concept, and mainly just with getting a template finalized.
    Shutting down a container, back then, was a scary and often fatal thing to do. WIth 12.04 I have had zero LXC related issues in roughly six months. Have a few dozen companies running on the platform and getting ready to white label the infrastructure to several resellers. In our lab we have managed to get 200 instances, with FreePBX, running simultaneously (though idle) on one host. Each (optimized!) container seems to eat about 75M of RAM. Our latest tweak is to make all of the containers internally addressed on an OpenVPN-only accessible virtual LAN, and are only distributing telephony hardware that can connect to the platform natively (still on a search for the right ATA, though getting by with DD-WRT router in front of Cisco ATA).



  • Realized I didn’t answer your questions. Yes, the host runs Dahdi for timing, entirely for Meetme in the containers (host is just for transport), and the driver is exposed to the containers in the LXC conf file.

    LXC does NOT have the same level of operational controls over the containers, yet, as OpenVZ (like limiting resources). That hasn’t really been an issue for us so far.



  • also sprach Paul Belanger [2012.11.07.2340 +0100]:

    My systems are already managed automatically, thankfully no longer with Puppet. 😉

    I am only talking about configuration of Asterisk, whether in
    /etc/asterisk or some sensible external data source. My point of pain is the complexity due to a couple of special cases, e.g.

    – Roaming users, i.e. no 1:n relation between sites and users;
    – Multiple devices per user (some want them all to ring, some want
    individual extensions but shared voicemail, …)
    – Keeping track of the mappings between incoming calls (from SIP
    providers) and extensions to ring (using incoming contexts and
    extension groups for that)
    – Keeping track of which extension uses which outgoing trunk
    – …

    With a logical naming scheme, a policy and include files, this is all working. But it’s very error-prone and there is a bit of redundancy in the information, so I was wondering if there wasn’t a better way.

    The new machine for the 6th site is up and running (provisioning
    (not image-based) took less than half an hour). What now? 😉

  • What about just setting up a database which stores your data however you want then generate static files from that data or creating views for realtime (where appropriate)?

    That’s how I do it with my company’s system.

    To keep things not so complicated, I have AGI scripts. Keeps things clean and is a little more flexible and powerful.

    – Logan

  • also sprach Logan Bibby [2012.11.08.0747 +0100]:

    Sure, I could do that. First, however, I would like to keep scouting for existing solutions. I prefer not to cook my own solutions but to adopt and contribute to existing (free) solutions.

  • 2012-11-08 00:26, Jeff LaCoursiere skrev:

    That’s very cool. I’ve also looked at Ubuntu server for their long support-time. I
    definitely have to test this setup.

    Thanks for the insight!

  • also sprach Jeff LaCoursiere [2012.11.07.2049 +0100]:

    Yes, separation into logical units is one way forward, but then you will necessarily have redundant configuration between the instances. It’s nice to have clear separations (unless you cannot clearly separate), but I am not convinced that this decreases complexity.

  • Actually, i would suggest breaking it up and store most of your data into mysql (realtime).

    By breaking up, you can separate distinctive parts, like pstn-gateways, GSM-gateways, internal-proxies, external-proxies, voice-mail, conference-server, etc etc. If you store the user-specific data into a database, it doesn’t matter on which proxy you register, the configuration is shared them all. Same for your dialplan.

    If you use LXC, the overhead will be less compared with using XEN. And if you keep each asterisk-container stupid, it is easier to maintain/replace.


  • Then you are on the right path.

    Either way, it sounds like you need to store your data some place and start building it out. I don’t know of any existing tools to do that, and I’m in the same boat. I have everything I want / need managed by puppet, but more dynamic data needs to be moved out into something else.

  • also sprach Paul Belanger [2012.11.08.2304 +0100]:

    To recap: given that Asterisk RealTime doesn’t really provide anything more than real-time access to data (i.e. the data in the database are not any more structured that they are in
    /etc/asterisk), any more logical and/or abstract approach to Asterisk configuration means that the data have to come from elsewhere and be brought into shape.

    Either the abstraction happens in a relational database and Asterisk accesses stored procedures or views (I would not use LDAP due to childhood traumata), or the relational database is used to generate Asterisk’s configuration files, or some other data source is used to generate these configuration files.

    It’s a shame that noone has done anything into this direction yet. On the other hand, it means that there aren’t already a dozen PHP+MySQL hacks out there, and that’s a good thing.

    So if I design the database (PostgreSQL), anyone interested in providing a frontend, e.g. using Django?

    Are people interested in discussing the design here and making it widely usable? I only have my own three use-cases to refer to, and I would probably impose my own paradigms…

    Does anyone already have something done into that domain?

  • also sprach Raj Mathur (राज माथुर) [2012.11.16.1005 +0100]:

    As long as we can agree on using a database (i.e. no MySQL) or the filesystem (Git…), then the question of which language to use for a frontend is secondary. I wouldn’t chose Java myself, but I suspect that the job is enough “text processing” that Perl would actually be a sensible choice — except I won’t help since I don’t know it well.

    But shouldn’t the first step be a mixture of database design and requirement specification?

    I would like a solution that keeps users, sites, and numbers
    (belonging to trunks (hardware, as well as SIP)) separate and then basically allows for free combinations.

    User A might have a desk at site I, to which a range of numbers is assigned, and in addition to an internal number (e.g. a one digit site prefix followed by a two digit number, or a site-independent number assigned per person), one of those externals rings at A’s desk.

    User B might roam between sites I and II and either should have the same internal/external numbers ringing at both desks, or require some sort of login to let the system know where to ring.

    User C might have a desk with a phone at site II, but is out most of the time, and calls should also ring on his/her cell.

    User D has a smart phone and wants both his desk and the smart phone to ring.

    All users want voicemail and be able to configure the time until voicemail answers.

    During vacation etc., a forwarding number should be configurable.

    Some users might want their voicemail to say e.g. “press 1 now to be transferred to my cell”.

    We would also want to be able to specify per-user whether to use UDP, TCP or IAX, who can transfer and park calls, who can record them with mix monitor, who can create ad-hoc conferences, their language, who has a video telephone…

    … and of course there ought to be a way to set user-specific sip.conf settings.

    On top, it would be nice if there were some sort of group inheritance. This sounds a bit like LDAP, except LDAP can’t actually do it. What I mean is that I’d really like to define a group of e.g. managers who all have internal numbers beginning with 11 and secretaries who can create conferences, and then associate users with (multiple) groups, inheriting and merging the settings.

    These are — I think — my base requirements. What would you add?

  • [2012.11.16.1005 +0100]:

    I’ll talk to clients and get a feature list from them too. Then we can filter into initial, advanced and nice to have categories.

    Unless enough other people are interested (yes, asking on Saturday morning is a good way of ensuring no one answers 🙂 , we ought to take this to private mail.


    — Raj

    Raj Mathur || || GPG: || || CC68
    It is the mind that moves || || D17F