Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX

[DustinB3403]

@scottalanmiller I believe he is saying he doesn't have the final decision; but at least as some weight when it comes to the conversation.

[scottalanmiller]

@360col said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

The main aim of this thread is for me to learn more on what would have been the recommended solution for this particular scenario if one we to set up a phone system servicing that many sites. Let say 10 to 20 brands with multiple sites each.

Right, and the top recommendation, long before you pick a platform, is picking the business architecture of your providers. Hence why we were giving that. The PBX is trivial compared to the provider, especially since your main problems here are from the provider, not the PBX.

Is FreePBX ideal for you? Probably not. Are your problems caused by FreePBX? No, they are from the provider.

So while it may not feel like it, we are actually addressing your original question and issues moreso than what you are wanting as an answer.

[360col]

@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Basically you are saying "I must use this provider" and then asking "what's an alternative provider."

We all agree the current system is a problem. So I'm not talking about that anymore. I'm asking what if I were given this to start fresh. What systems (FreePBX / Fusion) would you use. How would you structure it? What would you need to provide those features.

[scottalanmiller]

@360col said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Basically you are saying "I must use this provider" and then asking "what's an alternative provider."

We all agree the current system is a problem.

Sort of, we all agree that the vendor you can't change is a problem. How much can you change if you can't change the vendor of the thing in question?

I'm unclear what can be changed. If you are locked to one vendor, then it comes down to what that vendor offers.

[360col]

I want to steer this thread back to my original question. That is how would one setup a system that provides those features starting from a clean slate. Please ignore I ever mention about the current system. That part is done and dusted! This is purely for my learning and for other who may have the same questions as I am now.

Let say I will get SIP trunks from a provider and then setup myself a system that does the rest.

From what I've learned so far from this and the other thread is that. FreePBX & FusionPBX are 2 potential options.

FreePBX: not true multi tenant with many limitations (for this screnario)

FusionPBX: True multi tenant. However not as well know used. Documentation are not good.

What other options are out there that wold have those features?

[scottalanmiller]

So beyond the scenes, FreePBX is Asterisk. Abd FusionPBX is FreeSwitch. Each is the leader for that specific platform

There arent many other open kernels to work from. So most other options are very similar to these.

So these tend to be the big options as anyone else will be a near clone of these.

[alimrahimi]

Hi Scott and Mark,

I have couple customer looking for about 800 VoIP extension in California, I need some recommendation good infrastructure setup, I really appreciate for your suggestion and recommendation.

Q1. Hosting Provider recommendation
1 .AWS
2. vultr
3. Digital ocean
4- Dedicated server( colocation)
Note: of course everyone agreed to pay less as long as have minimum downtime for better call quality

Q2.Fusion Server infrastructure option

1.Separate database Server
server 1 - Fusion application
Seever 2 - postscript database

NOTE: Of course I should have a good bandwidth between two server

2. Load Balancer option
   Load Balancer point to Server 1- App1 and Server 2- App 2 and these two app server point to a Database server(postscript database)

Note: The load balancer is a single point of failure; if it goes down, your whole service can go down. A high availability (HA) setup is an infrastructure without a single point of failure. To learn how to implement an HA setup, you can read this section of How To Use Floating IPs.

3. Master-Slave Database Replication

Note: The application accessing the database must have a mechanism to determine which database nodes it should send an update and read requests to Updates to slaves are asynchronous, so there is a chance that their contents could be out of date If the master fails, no updates can be performed on the database until the issue is corrected and does not have built-in failover in case of failure of a master node

4. load balance the caching servers, in addition to the application servers, and use database replication in a single environment.
   

Note:This environment still has two single points of failure (load balancer and master database server), but it provides the all of the other reliability and performance benefits that were described in each section above.

5. IF you recommned any other setup to start for two new customer and of cource i can scale it later.

Q3. Do i need to setup kamailio or opensips and what is the advantage to have it now?

Thank you so much in advance for you help and support.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Q1. Hosting Provider recommendation
1 .AWS
2. vultr
3. Digital ocean
4- Dedicated server( colocation)
Note: of course everyone agreed to pay less as long as have minimum downtime for better call quality

Dedicated server would not make sense. High cost and no benefit, given the size, unless you already have it for other reasons. At 800 extensions, you can run this on less than $20/mo on a cloud provider, likely only $10. And then you have things ready to spin up a spare instance when needed.

Vultr has consistently been the "go to" player here. AWS doesn't allow ISO uploads and is overly expensive. DO traditionally doesn't allow ISO uploads, and doesn't perform up to par with Vultr. Vultr is your best value, performance, and features.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Q2.Fusion Server infrastructure option

1.Separate database Server
server 1 - Fusion application
Seever 2 - postscript database

NOTE: Of course I should have a good bandwidth between two server

You typically do separate app and database servers when you are mixing apps and/or going to large scale. This is not large scale at all. You are well within the range of any tiny PBX. Adding this will likely just hurt performance, add risk, add complexity, and add cost. At this small scale, I don't see any benefits to the separation.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

2. Load Balancer option
   Load Balancer point to Server 1- App1 and Server 2- App 2 and these two app server point to a Database server(postscript database)

Note: The load balancer is a single point of failure; if it goes down, your whole service can go down. A high availability (HA) setup is an infrastructure without a single point of failure. To learn how to implement an HA setup, you can read this section of How To Use Floating IPs.

HA doesn't mean you have or don't have a single point of failure. HA is exactly what it sounds like "availability rates that are significantly higher than standard." HA is determined by how many "nines" you get of availability, how that is achieved is not a factor in whether something is HA or not. In fact, many "fully redundant" solutions are actually the opposite, "low availability", because many redundancy mechanisms add risk rather than removing it.

Load balancing is not an appropriate mechanism for voice calls and does not make sense here.

It looks like you are taking diagrams from web applications, not PBX servers. These designs are not appropriate approaches for a PBX.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

3. Master-Slave Database Replication

Note: The application accessing the database must have a mechanism to determine which database nodes it should send an update and read requests to Updates to slaves are asynchronous, so there is a chance that their contents could be out of date If the master fails, no updates can be performed on the database until the issue is corrected and does not have built-in failover in case of failure of a master node

This doesn't really make sense. The deeper we go, the more it looks like you are dealing with architectural diagrams from something other than a phone system. If we were talking about a high availability web app, sure, this makes total sense and is a standard design. For a PBX, this would buy you effectively nothing. All of this complexity would put you at greater risk, rather than protecting you.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

4. load balance the caching servers, in addition to the application servers, and use database replication in a single environment.
   

This doesn't work at all. You can't cache PBX traffic. So this is simply impossible. Whatever source you are using for this information is specific to web apps, and doesn't apply to your needs.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Note:This environment still has two single points of failure (load balancer and master database server), but it provides the all of the other reliability and performance benefits that were described in each section above.

Sort of. Enterprise load balancers are clustered, not individual units. So this isn't a risk in that type of architecture. Bad idea for your phone system, doesn't make sense here, but is not a single point of failure when talking about this architecture.

If this was a real enterprise web app, we wouldn't put the database in master/slave but in master/master or active/passive modes so this would not be a single point of failure, either. What's the purpose of the slave node if it was believed it would be useless, anyway? In any normal database setup for HA, you have two (or three, or many) nodes that are all load balanced and any can take over.

But again, this isn't how PBXs work, so doesn't matter.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

5. IF you recommned any other setup to start for two new customer and of cource i can scale it later.

Worrying about PBX scaling will get you into big trouble. A single small PBX can handle thousands and thousands of extensions, no problem.

All you need for 800 extensions is a single VM that runs your PBX, that's it. Add anything more to that, and you are just adding more things to fail, more things to misconfigure, more cost. One VM, nothing more. Keep it "normal".

If you want HA, you don't need anything really, just a backup that you can restore in seconds. PBX are nearly stateless, you don't need live replication to keep them for HA purposes. If you have extreme needs way beyond industry norms (like way beyond) then you could run two PBX VMs, one replicated to the other, so that failover is a few seconds faster. That's it, that's all that you need. That way you can have the IP of the second VM registered with your trunk provider ahead of time.

It's that simple. Anything "more complicated" is just making things worse, not better.

[scottalanmiller]

@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

Q3. Do i need to setup kamailio or opensips and what is the advantage to have it now?

No, you don't need it.

[scottalanmiller]

At such a small scale, you could even use SQLite instead of PostgreSQL to make VM to VM replication easier and system management easier, and to reduce risk. SQLite is a database, not an RDBMS, so has no service to fail, unlike MySQL, PostgreSQL, SQL Server, etc. There is nothing to "go down", it's just a file. So backups and restores, and uptime are a breeze.

[360col]

@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

At such a small scale, you could even use SQLite instead of PostgreSQL

At what size would you stop using SQLite?

[scottalanmiller]

@360col said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:

At such a small scale, you could even use SQLite instead of PostgreSQL

At what size would you stop using SQLite?

Maybe a few thousand, or with multi-tenancy. PostgreSQL lets you go to a full live/live model, but that would be for things like 911 call centers.