PBX maximum active calls

Hi every,

Anyone know how many simultaneous calls can a PBX handle without losing performance?

I’m using:

  • PBX ver 14.0.17
  • Asterisk ver 13.36.0
  • For cpu/ disk/ ram, v.v… I can update anytime in needed,

The versions of FreePBX or Asterisk are not enough to go on. Actual details of the system and what is being done on it is needed

I build PBX for calling out and receive inbound call then transfer to other PBX. I even not allow recording on it.

So you’re trying to build a robocalling system for solicitation?

Not really, it more like a transit station. So I really need to know how many simultaneous calls can PBX handle.

How many simultaneous calls would you have?
100? 500? 1000?

This is a quick AI generated answer:

General Estimation for uLaw Calls

For a typical server:

  • Low-End CPU (e.g., Intel Core i3, single socket, 4 cores): Around 100-200 simultaneous calls.
  • Mid-Range CPU (e.g., Intel Xeon E-series, single socket, 8 cores): Around 300-500 simultaneous calls.
  • High-End CPU (e.g., AMD EPYC or Intel Xeon Scalable, dual socket, 32 cores): Over 1,000 simultaneous calls.

How to Calculate Call Capacity:

  1. CPU Load: Each call generates minimal CPU load when using uLaw. A good rule of thumb is that a modern CPU core can handle approximately 50-100 simultaneous uLaw calls.
  2. Bandwidth: Ensure you have at least 100 kbps per call (uplink and downlink).
  • For 200 simultaneous calls, you need ~20 Mbps symmetrical bandwidth.

Unfortunately the (acknowledged) AI missed the fact that calls have two legs, both with uplink and downlink.

That’s why it says “symmetrical” bandwidth. I read that as 20up/20down, Ulaw is only about 128k for a two way conversation was my understanding… so you are correct…it would be something more like what? 60mbps both ways? (arguably my math could be way off)

20 calls x 2 legs is 40 up and 40 down.

The use of 100kbps is to account for the RTP, UDP, IP, and Ethernet (etc.) overhead. the actual payload is 64kbps (64,000).

IT is 80Kbps the payload is 64 and the overhead makes it 80.

20 calls is 40mbps up/down? That seems heavy to me.

This is not correct. You can get roughly 18-20 calls on a 1.5Mbps connection. We did it all the time with T1.

Actually it is more like 16-18 with the math.

exactly… Used to have a few customers on ISDN lines at ~2.3mbps and they’d have no issues with 10 simultaneous calls…

With a 4 or 6 core Xeon. We used about 20% of the CPU with 16GB and 100GB of hard disk for 100 or 150 simultaneous calls. And the system was using FreePBX 2.11 (distribution was Elastix 2.5)
This is an example of course.
Do not use the transcoding codec. Everything was on G711a for trunks and extensions.
No call recording, no voicemail.
The system used was designed to provide a trunk to each of our customers.

By the way, I am coding a FreePBX module (16 and 17) providing this kind of services. I am currently testing it on a client. It seems to work fine. It is easy to manage clients and DIDs.

are you a registered CLEC?

You can only get 12 two party calls when using T1 in circuit switched mode, if the T1 is being used by both A and B side. The extra overhead of VoIP means you will get less, if using the same (G.711) codec. T1 has 24 circuits, but a simple phone call has two legs, so half the circuits are handling traffic coming from the A side and half from the B side (although you wouldn’t use the same trunk for both legs (except if the call is hair-pinned) with circuit switched telephony, wherwas it is normal to use the same Ethernet interface, for both legs, for VoIP.

100kbps is often quoted but probably allows some safety margin.

Computing VoIP traffic bandwidth consumption gives 82,800, at layer 3, and with some arithmetic, at least 91,800 over Ethernet (the article is aimed towards long distances, not Ethernet over true Ethernet networks). It does point out that some compression of UDP and IP layer headers may be done over long distance connections.

What kind of services? You are aware of all the rules and regulations that has to be followed in North America? Specially in the US? Making this a solution for providers means you have to follow these rules or this will be unusable for those in North America/US. Are you going to have the ability to sign calls per SHAKEN of STIR/SHAKEN? Will there be tools for robocall mitigation (inbound and outbound)? How would your module conform to regulation requirements?

I will never understand why the urge to make a FreePBX something it is not is there. The concept of FreePBX + PAYG Carrier = I’m a provider is dead in the US as of now.

There is only the USA in this world? (humor)
My module is able to connect or receive any other PBX system / gateways on any extensions configured as a gateway and not as a phone. So you can be SIP provider, or you can be an office providing trunks for other sub offices using legacy PBX systems. That works too.
That works in France, Europe and why not elsewhere.

This is all poor math and poor understanding. A T1 is 1.544Mbps full duplex meaning that it can do 1.544Mbps upload at the same time it is doing 1.544Mbps download. So a single VoIP call at 84Kbps is full duplex. Resulting in 1544 / 84 = 18 (rounded down). That means it can support 18 calls doing 84Kbps up/down each because it’s full duplex. To get the numbers you’re talking about would be based on half-duplex (like Wifi).

1 Like