How big of a PBX can I build?

Hello All,
I am looking to put together an Asterisk implementation for my company over the next year or so. I am currently looking at Asterisk 1.6.2 for it’s scalability. I have heard that FreeSwitch runs circles around Asterisk but we really want the comfort of support from a company large enough to support us and there are several larger company’s, besides Digium, that can provide support for Asterisk.

My question is regarding the scalability of FreePBX. I absolutely love the features and the management interface but I am just not sure how many users it can serve on a single instance. I’ll tell you what we have in hardware and then tell you what we are looking for and I would appreciate any reply with good, bad, or ugly.

The environment will most likely run under Xen across 3 IBM BladeCenters. We will be pure SIP. Brekeke SIP Proxy will handle registrations if we go to a multi-Asterisk setup. If we need dedicated hardware instead of Xen then that is no problem. I currently have a production conference bridge running a quad-core 2.33 Ghz and 4gig of ram, so that should be able to do something. If we need bigger then we can go bigger.

We are a services company with over 500 branch locations and about 13 phones per branch. Ideally we want as few servers as possible and there will be no hardware redundancy in the branch offices. We have a highly available MPLS network to take care of redundancy for the branches and Xen essentials will jump the environment between blades on and hardware failure. Redundancy isn’t critical at the branch level.

So if I were to put in a single instance of FreePBX with Asterisk 1.6.2 (g.711/uLaw and NO Call Center Activity) do you think that this would fit the bill? I personally don’t think it could handle 5000+ phone registrations and about 300 to 500 simultaneous sessions but I know there are a LOT of people out there MUCH smarter than me at these things.

I really appreciate any thoughts on this.
Perry Pennington

Whether a single server can handle the demands, the 5000 registrations is not an issue. The concurrent call load: 300 easy… 500 on the raggedy edge depending on whatever features you are going to have in heavy use. With some tuning, a good modern server could probably be made to handle it.

That said, since this is a bet your company decision, putting a national network of locations on to single point of failure design seems to be a very questionable starting point. The vision of all phones in all locations being inoperable is one that should be keeping someone awake.

All good points, but I assure you, this is not a Single Point of Failure design unless you are referring to the application. The only thing that is single is the application and if that fails then we should look long and hard at putting it in to begin with.
Redundant network
Redundant hardware
Single Application

I do know that much can go wrong with any application even with all of the redundancies, so our call centers (The real money maker) will not be on Asterisk at all. We are using Genesys for their needs. We are a bit funny about putting all of our eggs on Open Source for some reason. (Even though we are a heavy Red Hat shop… Go figure…)

All of this being said, I agree that a multiple instance will probably suit us better. So that makes life a little easier from the capacity standpoint. Now I just need to get good at making the machines talk to each other. I did see a “How-To” regarding getting multiple FreePBX boxes talking. My Proxy will hold the enterprise dial plan so that will make life a little easier too…
Thanks for the sanity check…

The University of Calgary has implemented Asterisk as an upgrade path to their legacy Nortel PBX (DMS-500 or something like that). They service about 12,000 phones. With Asterisk, they are at about 500 and using less than 5% of their Asterisk resources.

They used a Cisco router for hardware transcoding for four T1 lines from the PSTN and to interface to the legacy phone system as it was putting quite a load on Asterisk’s software based transcoding. They separated the MySQL database onto another server. Used another file server for voicemail and migrated the Nortel phone’s voicemail to Asterisk also. And one server for Asterisk.

The big issue that they had was “Applying Configuration Changes” - it was taking about 5 min for reloading 500 phones. So they developed an interface to use the configs from MySQL directly as opposed to reloading the text config files.

This is all from memory from a meeting with them about 1 1/2 year ago. I was impressed.

Thanks for that information. I can clearly see that this can be done (And quite impressively I might add). My co-workers and manager suggest we start with one of our divisions on a single instance and just grow. When we start to reach the limits of that instance and we still like the ROI, feature set, have had no real problems, etc., then we look at a way to effectively scale what we have for the next division.

That’s a sound approach to me. Plus it will allow us more time to get familiar with the nuts and bolts of the platform. I have been working in it for about 3 years but it has been mostly with smaller companies and our conference bridge.

Thanks again for that feedback. I greatly appreciate it.

I should clarify that, properly implemented, asterisk is perfectly fine for large scale applications including large scale call centers. We operate several call centers [the largest with over a thousand seats] on asterisk clusters and the performance has been as good as any non open source solution at a fraction of the cost to implement or operate.

My first comment was more on the “hub and spoke” design structure implied by the OP. The approach we have taken to multiple locations is to distribute clusters of asterisk servers [in our case around the globe] and have multiple routing paths available to manage overall service reliability and load balancing as well as skills based services. This way, each hub acts as a regional primary center and backs up two other regions. Using this approach of multiple servers organized in high availability clusters, we have been able to handle peak global concurrent call loads well into the thousands while risk of any service down time, yet alone system wide service failure, is approximately nil.