Codec choice and what a voice call really costs on your link

Ask how much bandwidth a voice call uses and you will usually be told 64 kbps for G.711 or 8 kbps for G.729. Both figures are the codec’s payload rate, and neither is what the call costs on your link. The overhead roughly doubles the smaller one.

Where the extra bandwidth goes

Voice is sent in small packets — typically one every 20 milliseconds, so 50 per second. Each carries headers: 12 bytes of RTP, 8 of UDP, 20 of IPv4, plus whatever the layer beneath adds. That is 40 bytes of IP-level overhead per packet regardless of how small the payload is.

At 50 packets per second, 40 bytes is 16 kbps of pure header. For G.711 that is an annoyance. For G.729, whose payload is 8 kbps, the headers are twice the voice.

The practical numbers

• G.711 at 20 ms — 64 kbps payload, about 80 kbps at the IP layer, and roughly 87–95 kbps once Ethernet framing is counted.
• G.729 at 20 ms — 8 kbps payload, about 24 kbps at IP, roughly 31 kbps over Ethernet.

So the real ratio is closer to three to one than eight to one. That changes the argument: G.729 saves real bandwidth on a constrained link, but not as much as the headline suggests, and it costs measurable quality to do it.

The other lever: packetization

Sending one packet every 30 or 40 milliseconds instead of every 20 cuts the packet rate and therefore the header overhead — G.711 at 30 ms drops to about 74 kbps at IP. The cost is latency: each step adds its own interval to the one-way delay, and it makes packet loss worse, because losing one packet now loses more speech.

20 ms is the sensible default. Change it only on a link where you have measured that bandwidth, not delay, is the binding constraint.

When each codec is the right answer

G.711

Uncompressed, no licensing question, no transcoding required by almost anything, and it handles fax, DTMF and hold music without argument. On a LAN or any link with headroom, use it. Compressing voice on a gigabit network to save 50 kbps is effort spent making calls worse.

G.729

Worth it on a genuinely narrow or expensive link — a branch on a small connection, a site paying per megabyte. Its quality cost is modest for a single encode but compounds: two G.729 legs in series sound noticeably worse than one, which is the usual hidden cost of an architecture that transcodes twice.

Opus and the wideband codecs

Where both ends support them and the traffic is internal or to a modern softphone, wideband is a real quality improvement rather than a marginal one — the difference is audible immediately. It usually cannot survive a hop onto the PSTN, so treat it as an internal and WebRTC option rather than a replacement everywhere.

Sizing a link

Multiply the per-call figure by the concurrent-call peak, then add headroom. Sizing a link to exactly the peak means the first burst of anything else on that link degrades voice. A third of headroom is a reasonable starting point on a shared link, less on one dedicated to voice.

And make sure the link actually prioritizes voice. A correctly sized connection with no queuing policy will still produce bad calls the moment a backup runs, because the calculation assumed voice gets its bandwidth and nothing enforced it.

Codec negotiation is where surprises live

The codec in use is negotiated per call, and the outcome is not always the one in the configuration. Two things are worth verifying on a running system:

• What is actually being used on live calls, per trunk. Systems frequently fall back to a codec nobody selected.
• Where transcoding is happening. Every transcode consumes PBX resources and degrades quality, and most of it is avoidable by aligning the codec list at both ends.

AcmaPBX reports negotiated codec per call leg, which is the fastest way to find transcoding nobody intended. If calls are fine internally and poor to one trunk, that report usually names the cause in a minute.