Calculate maximum simultaneous call capacity for a given trunk or bandwidth allocation.
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.
Max simultaneous calls
max_calls = bandwidth_kbps / codec_bw_per_call_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.
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.
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.