Codec choice and bandwidth reality

Capacity planning for voice goes wrong because people use the codec’s nominal rate. G.711 is 64 kbit/s, so ten calls need 640 kbit/s. In practice they need about a third more than that on Ethernet, and more again over a tunnel; the difference is all overhead.

Where the rest goes

Each packet carries the payload plus RTP, UDP and IP headers — 40 bytes — plus layer 2 framing. At the usual 20 ms packetisation there are 50 packets per second, each carrying 160 bytes of G.711 payload and 40 bytes of headers.

That is 25% overhead before Ethernet framing, and on Ethernet a G.711 call is about 87 kbit/s each way. Over a tunnel it is more.

The effect is worse for compressed codecs, because the headers are a fixed cost against a smaller payload. G.729 at 8 kbit/s nominal becomes around 31 kbit/s on Ethernet — nearly four times the headline figure.

Packetisation

Larger packets carry more payload per header and reduce overhead, at the cost of delay and of losing more audio per lost packet. 20 ms is the usual compromise. 30 ms saves bandwidth and is defensible on a constrained link.

Compression on the link

RTP header compression can reduce 40 bytes to a few on a point-to-point link, which is a substantial saving for compressed codecs. It costs CPU and only works hop by hop.

Choosing

On a LAN, use G.711. It sounds better, costs nothing you are short of, and avoids transcoding.

On a constrained WAN, G.729 buys capacity and costs quality. Be aware that transcoding between codecs adds delay and degrades quality further — two compressed hops sound noticeably worse than one.

Opus is worth considering where both ends support it: it adapts its rate to conditions and handles loss better than either of the traditional choices.

Plan honestly

Calculate with real per-call figures including overhead, add the signalling, and leave headroom. A link sized exactly for the expected call count will not deliver them.