Call Capacity
Calculate maximum simultaneous call capacity for a given trunk or bandwidth allocation.
About Call Capacity
Each VoIP call consumes a fixed amount of bandwidth determined by its codec's bitrate plus RTP/UDP/IP/Ethernet header overhead — this per-call figure (not just the raw codec bitrate) is what determines how many calls a trunk can carry, since headers add meaningful overhead especially at the small, frequent packet sizes typical of voice (usually 20ms packetization intervals). Dividing total available bandwidth by the per-call bandwidth gives the maximum number of simultaneous calls a link can support.
Formula
Max simultaneous calls
max_calls = bandwidth_kbps / codec_bw_per_call_kbps
Worked example
With the default values below, Call Capacity returns Max Simultaneous Calls of 22. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Available Bandwidthminimum 1 kbps
- 2,000 kbps
- Codecone of G.711 (~87.2 kbps with RTP/IP overhead), G.729 (~31.2 kbps with RTP/IP overhead), G.722 HD (~87.2 kbps with RTP/IP overhead), Opus (~50 kbps with RTP/IP overhead, typical)
- G.711 (~87.2 kbps with RTP/IP overhead)
Results
- Max Simultaneous Calls
- 22
- Bandwidth per Call (incl. overhead)
- 87.2 kbps
- Bandwidth Utilization at Max Calls
- 95.9%
Step by step
- 1Values used
- 2Max simultaneous calls
- 3Max Simultaneous Calls= 22
- 4Bandwidth per Call (incl. overhead)= 87.2 kbps
- 5Bandwidth Utilization at Max Calls= 95.9
Assumptions and limits
- The result is derived only from the 2 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is G.711's actual bandwidth 87.2 kbps when the codec itself is 64 kbps?
The 64 kbps figure is just the raw codec payload rate — real packets also carry RTP (12 bytes), UDP (8 bytes), IP (20 bytes), and Ethernet (14+4 bytes) headers on top of the audio payload every 20ms, and at G.711's small packet size these headers add roughly 36% overhead, bringing the effective per-call bandwidth to around 87.2 kbps.
Why does G.729 use so much less bandwidth than G.711?
G.729 uses more aggressive compression (CS-ACELP), encoding voice at just 8 kbps of raw payload versus G.711's 64 kbps — the header overhead is proportionally larger relative to the smaller payload, but the codec's compression advantage still results in roughly a third of G.711's total bandwidth per call, which is why G.729 is popular for bandwidth-constrained WAN links.
Should I plan for 100% bandwidth utilization from voice traffic?
No — reserve headroom for signaling traffic (SIP/H.323), other applications sharing the link, and burst tolerance; a common practice is to size voice bandwidth allocation to 70-80% of the link's dedicated voice VLAN/QoS class capacity, leaving margin to avoid jitter and packet loss during peak load.