Multi-Tenant PBX With Asterisk

Hi

I came across couple of pointers on the Internet regarding solutions available for providing hosted PBX service.

1. Multiple PBXs: Using separate hardware to host each PBX. Pretty straightforward, but no hosting company wants to use it.
2. Multi-tenant PBX: Configuring multiple PBXs within the same instance of Asterisk. I.e. partitioning a single instance of Asterisk into multiple PBXs by way of configurations, using unique landing context for each tenant.
3. Virtual PBX: Multiple virtual machines within the same hardware, each host an instance of Asterisk.

Which one of the method above is generally used by hosted PBX service providers?

Isn’t the second option with ARA a good choice for dynamic creation of multiple “small” PBX tenants?

Is the last option alone or combination of options 2 and 3 good for cloud based hosted PBX service offering?

Thanks, Kannan.

11 Responses to “Multi-Tenant PBX With Asterisk”

  1. Leandro Dardini said:

    Jul 30, 12 at 8:05 am

    2012/7/30 Kannan

    Working in the voip field from a lots of years, I have found all three type of business.

    The first is maybe the easier and most common. Hardware is cheap and it is easier to “sell” a service like the PBX if it is sold together with a piece of iron. Usually the hardware is placed on client’s network, using the bandwidth of the client. Usually together with the PBX is sold also a router/firewall/traffic shaper/vpn endpoint to try to optimize the traffic on the client’s DSL.

    The major pros about this solution is you can use a normal PBX like freepbx/trixbox, the client can mess the config how he likes, without disrupting other services, you can install VoIP card to connect landlines,.

    The major cons is the cost of the hardware, the cost of the g.729 licenses
    (if any) and the maintenance cost of replacing hardware failures and the need to be physically near each client.

    The second is the holy grail of the VoIP providers.

    The major pros is the cost. Having a single hardware is cheap and it is still cheap also if you decide to get two to be ready in case of an hardware failure.

    The major cons is the software. You cannot use the award winning freepbx/trixbox family and you need to deal with sometime limited or incomplete developed interfaces. The client always asks for the missing feature. One other major cons is the “reload”. If the PBX software is not made using ARA, then every time you add a new peer or a new DID, you need to reload the entire PBX and that is a resource killer. Again, if the pbx interface is not made using ARA, then you cannot let your clients to change the configuration or they will trigger continuous reload (and delaying reload for example every 10 minutes is not a solution)

    The last one is sometime the chosen compromise, but from my point of view, pbxes are not good software to virtualize. They are too sensible to delays and your voice quality can go down if the real server is overloaded.

    The same for the cloud based solutions (I have yet to found). I suspect the
    “cloud” is good for services like http, not for real time applications.

    Leandro

  2. Carlos Alvarez said:

    Jul 30, 12 at 11:30 am

    We use number two. We dabbled with number three but didn’t like the results for a lot of different reasons. As others have mentioned, there is a certain level of danger when you mix companies so closely. We have in the past made a mistake and brought down the whole system, but it’s been many years since we’ve done that. Part is improved skill and part is that Asterisk has improved and no longer commits suicide for certain minor errors.

    To do this, you need to plan out a good naming convention for everything that will be unique to customers accounts. SIP accounts, macros, contexts, etc etc. We use the accountcode feature and prepend the accountcode through the dial plan and accounts.

    accountcode.301 would be a SIP account

    accountcode#function would be a context name

    We do deploy custom hardware for specific functions or customers who are particularly large in some cases. We just need a good reason to. Like they want to self-manage, or they make a lot of changes, need custom integration with databases, etc.

  3. Kannan said:

    Jul 30, 12 at 11:38 pm

    Thanks Leandro for your comments.

  4. Kannan said:

    Jul 30, 12 at 11:41 pm

    Thanks Carlos, it is good to hear from one who is in a similar business.

    Are you getting use of ARA too in similar hosted PBX offerings?

  5. Carlos Alvarez said:

    Jul 31, 12 at 12:00 am

    I don’t know what ARA is. We use just bare Asterisk, no GUI, and from the context it seems that’s related to a GUI. We have no problem doing a config reload during production hours. We never do a full reload, just the relevant module (SIP, dialplan, voicemail, etc).

    I don’t believe there is any freeware PBX software that is good for hosted services unless they are kept tiny and limited. Switchvox is excellent as a hosted platform, but extremely expensive and totally closed so you can’t customize as needed. And at least 50% of our customers have customization that wouldn’t fit into any of the GUI-based systems.

    You’ll need to decide what your market is and your value proposition as well as your ability to learn Asterisk (which I don’t think anyone would argue is easy or fast).

  6. Leandro Dardini said:

    Jul 31, 12 at 12:25 am

    ARA is an acronym for Asterisk Realtime Architecture and is a different way to keep configuration files in asterisk. Instead of reading configuration from plain files at startup, asterisk read them from database, in realtime. This mean, if you need to add a peer, you drop a new line in the sippeers table and you are fine. You start defining an ODBC source in res_odbc.conf and then configure the ARA source for each plain configuration files in extconfig.conf

    About the config reload, reloading only the module changed is a good idea, but the commercial GUI I have meet so far doesn’t support it. I have clients with very simple dialplan, able to reload it even if more than
    130.000 rows long, others, with more complicated dialplan cannot reload it during work hours even if only 30.000 rows long.

    You are right about freeware PBX for hosted services. Independent from the fact a GUI is free or needs a payment, I think it is important to have the source for it to be able to customize it and also it is important to have a clean dialplan, so you can debug and customize it as well. I am a developer selling software. I never protect my code obfuscating or compiling it and my clients enjoy it and never steal my work (so far).

    Leandro

    2012/7/31 Carlos Alvarez

  7. Carlos Alvarez said:

    Jul 31, 12 at 12:28 am

    We tried realtime and decided it wasn’t for us. Never got it into production, so I can’t say much about it.

  8. Ishfaq Malik said:

    Jul 31, 12 at 2:53 am

    We use 2 and I’d have to agree with most of what the previous replies have said. You really need to nail down your conventions and stick to them. We did this by creating our own custom front end so our conventions are built in to the front end code.

    ARA is really useful for this type of thing. If you’re expanding to the point that you need to add new servers for extra capacity, ARA enables you to retain all your config on a single (pair of) machine(s). It also means that, if you have the framework to allow it, your customers can make changes to their own account themselves.

  9. Bryant Zimmerman said:

    Jul 31, 12 at 8:14 am

    Kannan

    I have to disagree with Leanrod. We are a hosted (cloud) PBX company we successfully run our Multi-tenant systems in Virtual machines and have no issues with them. It comes down to designing your virtual environment for your target loads and then not exceeding them. This allows for fail over of hardware and scalability. We have moved our virtual phone switches live with full call loads and have no call drops. We do not usually dedicate a single Virtual Machine to each customer either. We have built our own Multi-tenant PBX on top of asterisk. We achieve many of the features available in freepbx/trixbox (not all). This method allows us to cost effectively service our customers with a presence of scale in mind. It is not uncommon to have 5000 + extensions per virtual switch. This method does require highly skilled engineering to achieve stability.

    Bryant

    ————————————–

  10. Leandro Dardini said:

    Jul 31, 12 at 10:20 am

    Hello Bryant, it is nice to hear someone with different experience, so I am happy to know the “cloud” is indeed a feasible environment even for VoIP.

    Can you share with us some of your configuration magic? Like the cloud service you are using, the power of each node and the load you are experiencing on them in regards to the number of channels active and phone registered?

    Leandro

    2012/7/31 Bryant Zimmerman

  11. Carlos Alvarez said:

    Jul 31, 12 at 10:25 am

    Particularly, what virtualization software are you using?