Fundamentals
Codecs Compared: G.711, G.729, G.722 and Opus
A codec is the recipe that turns a voice into packets: how much it compresses, how much bandwidth it consumes, how it behaves when packets vanish, and how much CPU it burns at both ends. Codec choice is the quietest big decision in a VoIP deployment — it trades bandwidth against resilience, and most 'mystery quality problems' involving robotic voice or music-on-hold disasters are codec decisions made by default.
This comparison uses the four codecs you will actually meet, with wire bandwidth computed the way networks experience it — headers included.
The comparison
| Codec | Payload | On the wire (20 ms, Ethernet) | Character |
|---|---|---|---|
| G.711 (µ-law/A-law) | 64 kbps | ≈ 87 kbps | Uncompressed PSTN quality; the reference. Shrugs off small loss with simple concealment; carries fax/modem tones (pass-through) and music faithfully |
| G.729 | 8 kbps | ≈ 31 kbps | Speech-model compression for thin links; quality degrades fast under loss; destroys fax/DTMF inband and music; per-channel licensing history on some platforms |
| G.722 | 64 kbps | ≈ 87 kbps | 'HD voice': double the audio bandwidth of G.711 (wideband) at the same bitrate — noticeably more natural voice when both ends support it |
| Opus | 6–510 kbps adaptive (VoIP speech typically 16–32) | ≈ 40–55 kbps typical | Modern adaptive codec (RFC 6716): scales from narrowband to fullband, built-in loss resilience (FEC options); native in WebRTC, growing in desk phones |
How to choose, by segment
Codec policy is per-segment, not per-company. On the LAN and to most hosted providers: bandwidth is plentiful — prefer G.711 (or G.722 where endpoints agree) for maximum resilience and compatibility (fax pass-through, DTMF inband fallback, music). Across genuinely thin links (rural sites, expensive WAN bandwidth, dense call-center trunking): G.729 or Opus earn their keep — price the trade with the bandwidth guide's math, and expect to work harder on loss. Everywhere: minimize transcoding — every conversion between codecs costs quality and CPU, and a call that crosses G.711 → G.729 → G.711 arrives pre-damaged (see the robotic-voice guide). The practical method: set one preferred order on endpoints, PBX and trunks (e.g., G.722, G.711, Opus, G.729 last), and audit actual negotiated codecs in captures after any platform change.
Audit your codec reality in an hour
- Pull SDP from sample calls on each path type (internal, to provider, between sites): list the negotiated codec per leg — not the configured one, the negotiated one.
- Flag tandem transcodes: any path whose legs disagree in codec family is converting mid-call; find where and ask why.
- Match policy to segment bandwidth using the wire-rate table; change one segment's preference order at a time.
- Retest edge cases after changes: fax (if used), DTMF to a strict IVR, music on hold, and a call under mild induced loss if you have a lab.
- Record the intended codec matrix in the run-book — codec drift after firmware and platform updates is silent and common.
Frequently asked questions
- Is G.711 'wasting' bandwidth in 2026?
- On office networks, effectively no: 87 kbps is noise against modern LAN/WAN capacity, and what it buys — loss resilience, universal compatibility, clean fax/DTMF/music behavior — is worth more than the 56 kbps saved per call. On constrained links the calculus reverses, which is a sizing question, not an ideology.
- Why does hold music sound terrible on our system?
- If any leg negotiates G.729, its speech model mangles music by design — it is not a fault you can tune away. The fixes are G.711 on that path or sourcing hold music the codec survives (simple, speech-band content). Diagnose with the codec audit above.
- Should we force Opus everywhere?
- Where every endpoint and the provider genuinely support it, Opus is excellent and adaptive. Forcing it across mixed estates guarantees transcoding at the seams — negotiate it first in preference order, keep G.711 as the universal fallback, and let each path settle at its best common codec.