Building a Multi-Tenant Asterisk Platform

Asterisk Asterisk Support
1

Hi All,
I’m looking for building a Multi-Tenant Cloud Telephony Platform on top of Asterisk, where users can log in and create their own groups.

I am planning to use real-time architecture and save sip peers, queues, and queue members in a Postgres db under different contexts to match each user group.

but I have some concerns to get clarified first,

  1. how to generate dial plans for each user group?. (it’s not a best practice to store dial plans in the database)

  2. At an architecture level, what would be the most suitable solution, which is to maintain separate servers for each client or maintain all the clients in one asterisk server?

much appreciate your input and expertise in guiding me through, Thanks

2

What your trying to do will take years to build but can be done. I think somebody already did this. We moved to HoduPBX that is affordable and does what your asking for but is a little limited the way we have it. We chose this route because it would take a lot of money for programmers and development time just to get where we are now. HoduPBX Is based on free switch which is similar to Asterisk and does this by making resellers tenants and extensions. The dial plan is extremely easy. If you want something now then just buy or rent it. There are a lot out there. No platform is more flexible then Asterisk and if you build it like HoduPBX then you’ll have your Multi user Multi Tenant Cloud Telephony Platform but it will need to be SQL driven because your text files will grow out of control as you expand. I am not here endorsing HoduPBX, I’m just saying I wanted to Use Asterisk to do this but couldn’t, So we tried using several other Multi user Multi Tenant platforms until we got to this one. I know that this may not be what you your asking for but others before you have wanted this as well. Hope this helps a little. PS. FreePBX people, If you make a Multi user Multi Tenant front end, I’ll switch.

1 Like
3

You can use ARI or AGI to drive the calls based on your database information.

Many did.

There are a number of Multi Tenant PBXs based on Asterisk; VitalPBX, MitraPBX, Voxo, Xorcom and many more. Some allow you to modify the dialplan and some don’t.

1 Like
4

Thanks for your valuable Input, appreciate it

5

Thanks for your valuable Input, we can leverage the power of AGI and ARI upto some extend, but if we allow users to build their own dialplans through a dashbord, can we have a general dial plan ?, I think the features will be limited in that case

6

Depends on the flexibility you want to allow your customers.

We’ve built our dialplan in sections for each feature they get to use, each instance of a feature is contained in a single context.

Eg. you have an IVR, we make a context like customerident-ivr-1 for the first, ivr-2 for the second, and so on. Same goes for queues, playback of audio files, like a welcome message etc. Some things are common contexts used for all users, just regulated by channel variables, eg. setting callerID, handling call forwarding etc.

When the customer build their setup, they see a visual representation of the features as blocks connected to each other. When they want to change the connection, they just connect the blocks differently, if they want to eg. change the options of the IVR, they click the block and gets access to the options.

When they are satisfied, they apply their configuration, at which point the flow they built is converted to dialplan with each block being a dialplan template, we fill in the dynamic information eg. the audio for playing the IVR menu, it’s options and destinations, and finally reload the configuration on Asterisk, and the customer is notified that their changes are now live.

We designed our system from the philosophy that the PBX should be independant of outside sources as much as possible, as such we’re not using realtime for extensions or dialplan, just plain old auto generated dialplan.

If I were to do this today, I might consider writing the dialplan in AEL or LUA, to allow for more flexibility and reuse, or use AGI a lot more to cut down on dialplan required, as this way of doing things results in a LOT of similar looking dialplan, in lots of files (Split up to make troubleshooting easier, and keep customers dialplans separated.)

We also have a problem where Asterisk is not always loading all configuration properly, usually this results in PJSIP endpoints or queues missing in the system, currently we have not figured out the reason, we just check the live config against the configuration files after the first reload is done, if something is missing, we do another reload, which usually fixes the problem.

My suspicion is that Asterisk (Or the affected modules) does not like the amount of lines in the combined configuration files, or the number of files loaded. But if you end up with a lot of files, or a lot of lines in your configuration files, beware of this possible problem.

2 Likes
7

Hello,

If you want there is Wazo Platform (https://wazo-platform.org) which are open-source (free software) multi-tenant project build on the top of Asterisk fully programmable.

Sylvain

2 Likes
8

Thanks for your valuable Input, you are correct, It depends on the flexibility I want to allow my customers. Assume this scenario, If a new client logs into the system and generates its own dial plan in its own context, and saves it.
but when the dial plan gets reloaded, it will affect all the users right ?, will it be a cause to drop the calls currently having in the system ?

9

Thanks for your valuable input, seems like a good alternative.

1 Like
10

Reloading the dialplan does not affect on going calls. If your going to to have any large volume of calls and customers, If it were me and I was using Asterisk, I’d go with Real Time Asterisk (SQL) to keep the dialplan, ext. text files small and readable. Please note that Asterisk may not handle a very large client base on small servers.

1 Like
11

When you reload configuration, ALL configuration will be reloaded. However, no calls or other state will be dropped. From my testing, calls on the way through your dialplan, will continue the old flow, and new calls will get the new flow.

In our case we have experienced customer A reloading their configuration, causing a PJSIP endpoint for customer B to go missing, hence the guess that the problem is the amount of configuration(files) Asterisk has to process.

The problem with missing parts of the configuration happens quite often, like every 2-3 reloads, hence our hack of just verifying the configuration after it was applied. I’m almost certain the problem has nothing to do with the contents of my configuration files, as a simple reload will do, it could be an issue with filesystem synchronization where the files are not completely written when Asterisk reads them, but as the reload is done after the configuration generator has ended, it makes no sense either.

But regardless of what solution you choose, you should be aware of this potential problem, a missing PJSIP endpoint is, for us, no big deal as the configuration will be reloaded again a few seconds later, however, if a queue is missing all members their stats and penalties, are lost for that particular queue, causing the customer to have to add members again. A workaround here, for us, would be to make a copy of the members and check if they are right, after a second reload.

1 Like
12

What is a “Very large client base” and what is a “small server” in this case?

13

What is a “Very large client base” and what is a “small server” in this case?
I would not put over 100 clients ie: extensions ect. in text files. Things get wildly out of control and messy. He wants to have multi users and with multi tenants. His files will grow large fast. Then you have the reloads as you stated. He should learn how to use Realtime Asterrisk (SQL) to eliminate most of these problems. Although CPU’s are much faster it still takes time and memory to have all of the text files loaded and parse through each process. I don’t know what system he’s going to want to deploy and what codecs he’s going to want to support. If it’s just gong to be a small deployment of under 1000 users, Realtime Asterrisk (SQL) should work with 4 or more cores and at least 8-16GB of ram. If it were say 100 users, then less will work fine. Hardware is cheap now and more powerful. Guys, These are just my opinions from 20 years of past experience with Asterisk. It’s still the best and most flexible platform to work on.

1 Like
14

Yes, that is true, That was one of my concerns which is the extension.conf file gets bigger and bigger when the system grows with more clients, but initially, I am expecting around 100 users in the system. (which is 100 different dial plans in the system)

Anyway, I am using Asterisk Real-time architecture to store sip peers, queues, and queue members.
However, the asterisk itself doesn’t recommend storing the dial plan in the database.

15

I think the advice against taking dialplan from a database is that it isn’t cached, so you end up with high rates of database access, and the database being a very critical point of failure.

1 Like
16

One thing to considure is how do you want to scale

For each server:

  • Multiple customers one one Asterisk
  • VMware one per customer
  • LXC one per customer
  • Docker one per customer

The benefit with a desing with one per customer is:

  • Restart do not affect other customers
  • Less reloads
  • Customer can get access to AMI
  • Customer can get access to logs
  • Easyer to trubbelshute one customer
  • Customer can run diffrent versions (roling update)

I have worked on all 4 types of systems and if I had to build a new system today I would do a K8s with a docker per customer
Asterisk has limit to how large a dialplan it can handle and how many concurent peers it support, and splitting the system up make is less of an issue

seperate note on alle the system I have worked on we have always avoided Realtime either with

  • Dynamic generating config files and reload them
  • Registre sip users to Kamailio
  • Dialplan use ODBC to look up what to do and the arg for aplications
    Table A (EXT=200,Context=Queue,ID=22, NextEXT=201)
    Table B (ID=22, arg1,SupportQueue,Duration=60,Ring=Music)
1 Like
17

The drawbacks include things like

  • High number of IP addresses required.
  • Higher resource usage. (And potentially wasted resources, if virtualization is not used)
  • More servers to manage, and keep updated. (A docker container is a server in this regard)
  • More servers to backup, unless you centralize storage of things like audio files for MOH, voicemail etc.
  • More complicated client setup if you need to use a feature like webrtc.

Depending on the size of your customers, it may be more beneficial, to put multiple smaller customers on a single server, while larger customers get their own.

Also as for the issue of files growing too large to maintain, it’s possible to split most of the files in smaller chunks and include them into other config files.

1 Like
18

Would you happen to know what that limit is, or do you have something else to backup that claim? As far as I’m aware, no such limit should exist, and you should be limited to only by available resources. (RAM and diskspace).

19

There is no inherent built in limit. The obvious limit is as you say, RAM and disk space. There may be other limits based on the implementation but those aren’t an enforced limit, more of a side effect of choices made.

20

Though time I have expirenced the folowing limitations
but as jcolp mentions you can tweek/fix asterisk to remove them
and some has just been bad platform design
but the larger you system is the more expensive it is to fork
with newer servers thise limits move

  • file descripters (config fix)
  • context switches (bug fix)
  • chan_sip quailify storm (resend faster than reciving ack can be handled) (bug fix / platform redesign)
  • 100.000+ lines in one dialplan context (platform redesign)
  • dialplan loop (on single customer very easy to find but on 100 customer share very hard as it will drown in general output, cli line scroll 200+ lines per sec make it hard to see what is what. Loops are not always 1-2 lines sometime that are 30-50 lines before they loop)

when you design a system with multiple server automation is key
even with 10 server I would use CI/CO to automate management

with a setup where you have one server per customer you will alway want a SIP proxy in front
removing any issues with webrtc and multiple public IP
and last I cheked private IP are really cheap
also clients should not connect directly to a server, as then you cant move them from one server to a second server if load become an issue on the first one

but in the end the most import thing is to make a desing that is as simple as possible
as the simpler it is the easyer it is to maintain
and always play with the idear that will this desing scale to when you have 10.000 customer with 1000 users each