Application Capacity Planning?

I am using Asterisk to initiate SIP calls that are terminated at a PSTN switch in the neighboring rack at the datacenter (across 100bT ethernet). Our members have registered from their own phone number to receive calls - our authentication process has been OK’d by our paranoid lawyers. We need to plan how much capacity to dedicate to the Asterisk server to handle call volume scaling.

We are planning only to initiate calls, then transfer a single audio file that has been pre-transcoded for sending over the call connection to the PSTN switch, with no IVR or other features/processing. We need to know what will be necessary to support up to 25,000 calls initiated within a 30 second window, and sustained (concurrent calls) for 3-5 minutes. That means how many initiations/calls an Asterisk server can handle, on what hardware. If we need to have multiple Asterisk instances running concurrently, we’d like to have a cluster, so the app that kicks the calls off (a cronjob, and a Postgres/LDAP database of callee phone#s, running on a separate server in the same rack) can handle as simple a network schema as possible.

So, how many Asterisk servers does it take to place and send 25K calls within 30s, running on better HW to minimize the number of boxes?

You request is difficult to plan regarding capacity.

What you should be asking yourself is how many calls do you want to handle simultaneously. It is very hard to state the length of a call.

A dual Opteron Server should be able to handle 4 Channels T1/E1 with no problems or dropping of calls.

To build a cluster you then need to assertain your sym call volume, and devide that by the number of channels in a T1/E1 in your area, the standard is usually 30 Channels.

We have ability to handle 3600 sym calls, and with 30 Nodes in our cluster. and the cluster is able to easily grow to 128 before we have to re-look at switching.

If you are interested in design services for a cluster visit … /Overview/ … ess-Nomad/

We can either provide you with design services or provide you will a fully functional cluster.

Thanks for the ideas about scale. I’m not sure I’m clear on your estimates. Do you mean that a dual-Opteron should handle 4 channels of a T1’s 24 (E1=30) channels? Doesn’t that mean only 4 simultaneous calls? Or do you mean 4 T1s, which would be 96 simultaneous calls?

Your other estimate of a 30-node cluster supporting 3600 simultaneous calls means a single node can carry up to 120 simultaneous calls.

Since our app is only initiating prerecorded calls at prescheduled times, we can determine the length of a call. Unless you mean that the server cannot instruct Asterisk to hang up a call to end it. But you’re correct that our scaling focus is the number of simultaneous calls we can initiate, and how many simultaneous calls we can maintain (if those numbers are somehow different).

So perhaps you’re saying that 25,000 total calls can be placed by a 128-node in two cycles: 15,360 calls, then 9,640 calls (leaving 15,360 more calls in unused capacity in the second cycle). At 5 minutes per cycle, the two cycles are complete in a 10 minute window. Can a cluster have more than 128 nodes? A 209-node cluster (or cluster of clusters) could initiate and complete 25,000 simultaneous calls, a single 5-minute cycle.

Thanks for helping me get a handle on this. We’ll need an expert to actually design, and probably implement and build, the cluster. We probably start at a scale of 5,000 simultaneous calls, unless there’s big savings in building more capacity. And we’ll need expertise building the app that drives the Asterisk server(s) to terminate their calls on the PSTN switch, including the kickoff at our other application server/cluster. Once I have a handle on the limits to scale, I can start planning how to approach the architecture. Thanks for helping me get started.

You cluster can scale to whatever your pocket can scale to, depending on how fast you grow your cluster you will need to plan your backend switching.

Please contact me on charles at, for us to discus your solution.