Start with concurrent calls, not users
The first mistake in capacity planning is sizing for headcount. A hundred staff do not generate a hundred simultaneous calls — the number that matters is peak concurrent calls, and it is usually far lower than people expect.
For a typical office, a common planning ratio is somewhere between 3:1 and 5:1 users to concurrent calls. A hundred staff might peak at twenty or thirty simultaneous calls. A contact centre is entirely different: agents are on the phone most of the time, so concurrency approaches the agent count, and outbound diallers can exceed it because they place several calls per agent.
Two rules make the estimate defensible:
- Size for the busy hour, not the average. Traffic is not evenly spread — Monday morning and the hour after lunch look nothing like 4pm.
- Measure rather than guess if you can. If you already have a system, your CDRs contain the answer. Count overlapping calls, not calls per hour.
A rough concurrency check from CDR data:
SELECT DATE_FORMAT(calldate, '%Y-%m-%d %H:00') AS hour,
COUNT(*) AS calls,
ROUND(SUM(billsec)/3600, 1) AS call_hours
FROM cdr
WHERE disposition = 'ANSWERED'
GROUP BY hour
ORDER BY call_hours DESC
LIMIT 10;Call-hours per hour approximates average concurrency for that hour. Your peak concurrency will be meaningfully higher than the average, so add headroom rather than sizing to the number you calculate.
Bandwidth
Bandwidth is the most predictable part, because it is arithmetic. Each call consumes the codec payload plus per-packet overhead, and the overhead is substantial: IP, UDP and RTP headers add 40 bytes to every packet, 50 times a second at standard 20 ms packetisation.
Concretely, G.711 lands around 87 kbps per direction over Ethernet, and G.729 around 31 kbps. Multiply by peak concurrency, and remember calls are full duplex — check your upload capacity, which on most business connections is the smaller number.
Thirty concurrent G.711 calls need roughly 2.6 Mbps in each direction. That is modest for the downlink and can be significant for an asymmetric uplink, which is exactly where quality problems originate. Work it out precisely for your codec and packetisation with the VoIP bandwidth calculator.
Then leave headroom. Voice competing with everything else on the link is the normal cause of degraded calls, and QoS only helps if there is capacity to prioritise.
Server sizing: transcoding is what hurts
Asterisk itself is efficient at passing media through. What consumes CPU is changing the media, and this is the single most important factor in server sizing.
Ranked by cost:
- Pass-through — same codec both sides, no processing. Cheapest by a wide margin. A modest server handles hundreds of such calls.
- Encryption — TLS and SRTP add real per-packet work.
- Transcoding — converting between codecs is expensive, and G.729 in particular is costly. This is what collapses a server that seemed fine in testing.
- Recording, conferencing and MoH — each adds encoding work per stream.
The practical lesson: design to avoid transcoding. If your phones and your trunk both speak G.711, calls pass through untouched. Introduce G.729 on the trunk while phones use G.711 and every single call now needs conversion in both directions — the same hardware might handle a fraction of the calls.
Music on hold deserves a specific mention because it is easy to overlook: it plays continuously to every held caller, so an unconverted MoH file transcoding per call is pure waste. Convert it to a native format and that cost disappears.
Trunk sizing
Trunk capacity is normally sold as concurrent channels. Size it to your peak with headroom, but be aware of the economics: unlike bandwidth, extra channels usually cost money, so there is a real trade-off between blocking calls and paying for capacity you rarely use.
Classical telecom uses Erlang models to calculate how many channels are needed for a target blocking probability given an offered traffic load. That level of rigour is worth it for contact centres where blocked calls are lost revenue. For an office, peak concurrent calls plus 30% is usually adequate.
Whatever number you choose, set the limit explicitly. A concurrent-call cap is also a fraud control — it bounds what a compromised extension can generate overnight.
What actually breaks first
In practice, systems fail in a fairly consistent order:
- Uplink saturation — usually the first real constraint, and it shows as call quality degrading at busy times rather than as an outage.
- Transcoding CPU — audio breaks up under load while the server looks otherwise healthy.
- Trunk channel limits — calls are rejected with 503 once the ceiling is reached.
- Database load — CDR writes and realtime lookups on an unindexed table become a bottleneck surprisingly early.
- Memory — rarely the limit for signalling, but recording and conferencing change that.
Monitor rather than predict
Capacity planning built on assumptions ages badly. Track the real numbers so growth is visible before it becomes a complaint: peak concurrent calls per day, CPU during the busy hour, link utilisation, and packet loss or jitter at peak.
Two useful triggers: if quality degrades predictably at the same time each day, you have a capacity problem rather than a configuration one. And if peak concurrency is regularly above 70% of your trunk limit, start planning before you begin blocking calls.
Frequently asked questions
How many concurrent calls do I need?
For a typical office, roughly one concurrent call per 3–5 users at peak. Contact centres approach one per agent, and outbound diallers can exceed it. Measure your own CDRs if you have history.
How much bandwidth per call?
About 87 kbps per direction for G.711 and 31 kbps for G.729, including headers, at 20 ms packetisation. Calls are full duplex, so check your upload capacity.
What limits an Asterisk server first?
Usually transcoding CPU, if the design forces codec conversion. Matching codecs end to end so calls pass through untouched is the single biggest sizing win available.
Should I cap concurrent calls on the trunk?
Yes — for capacity management and as a fraud control. A cap slightly above genuine peak bounds the damage a compromised extension can do.