G.711 vs. Opus vs. G.722: Does Codec Choice Actually Matter?

Search for VoIP codec comparisons and you will find spec tables: sample rates, bitrates, MOS columns, license notes. What the tables never tell you is the thing you actually want to know — whether picking one codec over another will make your calls sound better, and by how much. The honest answer is more interesting than the tables: sometimes the difference is dramatic and audible in the first second of a call, and sometimes codec choice is a rounding error next to what your network is doing.

This post is the verdict version. We will put the four codecs you will actually encounter — G.711, G.729, G.722, and Opus — head to head, say plainly which one wins each matchup and why, and then draw the line between the situations where codec choice genuinely matters and the ones where it is a distraction from the real problem.

The difference you can hear: narrowband vs. wideband

Before any head-to-head, one distinction explains most of what people perceive: audio bandwidth, meaning the range of frequencies the codec carries.

Narrowband codecs — G.711 and G.729 — sample at 8 kHz and carry roughly 300 Hz to 3.4 kHz. That range was chosen a century ago as the minimum for intelligible telephone speech, and it is why every phone call you have ever made on the PSTN has that unmistakable "phone voice" quality. Consonants like s and f, which live largely above 4 kHz, get clipped; voices lose their timbre; distinguishing "fifteen" from "sixteen" requires context.

Wideband codecs — G.722 and Opus — sample at 16 kHz or higher and carry 50 Hz to 7 kHz (G.722) or up to 20 kHz (Opus in fullband mode). This is what marketing calls "HD voice." The difference is not subtle. Speech sounds present and natural rather than filtered, listener fatigue on long calls drops measurably, and intelligibility of names, numbers, and spellings improves enough that call centers report fewer repeats. On the MOS scale, narrowband codecs are capped around 4.4 no matter how perfect the network is; wideband codecs can score meaningfully higher on the extended scale because they are reproducing more of the actual voice.

So the first-order answer to "does codec choice matter" is: the narrowband/wideband split matters a lot, and it is the one difference an untrained listener will identify instantly. Everything else is second-order. Now the matchups.

G.711 vs. G.729: bandwidth savings and what they cost

This is the classic comparison, and it made sense in 2005. G.711 is the PSTN codec: 64 kbps of uncompressed 8-bit audio, negligible CPU cost, near-zero codec latency, and the reference against which everything else is scored. G.729 compresses the same narrowband speech into 8 kbps using a predictive model of human vocal tracts — an 8x reduction in payload.

But the on-wire math is less flattering than the raw bitrates. Every RTP packet carries roughly 40 bytes of IP/UDP/RTP headers regardless of payload. At 20 ms packetization, G.711 costs about 87 kbps per direction on the wire; G.729 costs about 24 kbps. The real saving is closer to 3.6x than 8x, and against a modern connection — even a modest 20 Mbps uplink carries over 200 concurrent G.711 streams — the saving buys you nothing you were short of.

Meanwhile the costs are permanent. G.729's model-based compression caps its MOS around 3.9 versus G.711's 4.4 — audible as a slightly synthetic, "underwater" quality on some voices. It handles music, hold tones, and DTMF poorly. It consumes DSP or CPU on every device that encodes it, and if a call gets transcoded G.729-to-G.711 anywhere in the path (common at PSTN gateways), you pay the quality penalty plus a lossy re-encode. The patents that once made it a licensed product expired in 2017, which removed the last commercial reason for vendors to keep it in the front of the priority list.

Verdict: G.711 wins unless you are on a genuinely constrained link — think satellite, cellular backup, or a WAN circuit shared with everything else and no QoS. G.729 is fading for good reason, and if you are constrained enough to consider it, Opus at a comparable bitrate sounds better anyway.

G.711 vs. G.722: same bitrate, twice the audio

Here is the comparison with the most lopsided verdict in VoIP. G.722 delivers wideband audio — 50 Hz to 7 kHz — at the same 64 kbps as G.711. Same bandwidth cost, same packetization, similar negligible CPU load, and it has been a published ITU standard since 1988. Deployed on two desk phones on the same LAN, the improvement is immediate and obvious: the call sounds like the person is in the room rather than on a phone.

So why isn't everything G.722? Because a call is only as wideband as its weakest hop. The moment a call touches the PSTN, a legacy gateway, or any endpoint that only speaks G.711, it gets negotiated or transcoded down to narrowband — and most business calls touch at least one of those. G.722 thrives inside closed systems: internal calls on a hosted platform, phone-to-phone within one vendor's ecosystem, on-net calls between offices. It evaporates at the borders. There is also mundane friction — devices that support it but ship with it disabled or ranked below G.711 in the default codec list, so it never gets negotiated even between two capable endpoints.

Verdict: G.722 wins outright wherever both ends and everything between them support it. There is no bandwidth argument against it; the only thing stopping universal HD voice is the long tail of narrowband infrastructure in the middle of most call paths. If your platform supports it, enable it and rank it first — the fallback to G.711 costs you nothing.

Opus vs. everything: the codec that assumed the network would be bad

Opus, standardized in 2012 as RFC 6716, is what you get when you design a voice codec after the internet's failure modes are well understood. Where G.711 and G.722 are fixed-rate codecs from an era of engineered telephone networks, Opus assumes the transport is unreliable and adapts.

Three properties set it apart. First, adaptive bitrate: Opus operates anywhere from 6 to 510 kbps and can change rate mid-call without renegotiation. When your uplink gets congested, an Opus stream can drop from 40 kbps to 12 kbps and keep the call alive at reduced fidelity — a fixed-rate codec just keeps transmitting into the congestion and loses packets. Second, in-band forward error correction: at the cost of some bitrate, each packet carries a low-fidelity copy of the previous packet's audio, so a single lost packet can be reconstructed from its successor rather than concealed by guesswork. Third, genuinely good packet-loss concealment: when a packet is unrecoverable, the decoder synthesizes plausible audio from the surrounding speech instead of leaving a gap.

The practical consequence shows up exactly where calls actually fail. At 1% packet loss, G.711 is already producing audible clicks and dropouts; by 3–5% it is objectively poor, with MOS falling toward 3.0 and below. Opus with FEC enabled remains conversational through that same range — listeners often cannot pinpoint the loss at all until it climbs past 5%. We cover the mechanics of why loss hurts fixed-rate codecs so badly in our guide to VoIP packet loss; the short version is that G.711's concealment is primitive and every lost packet is 20 ms of speech gone forever.

Add fullband audio (up to 20 kHz, better than G.722's wideband), open licensing with no patents to negotiate, and the fact that it is the mandatory-to-implement audio codec for WebRTC — meaning every browser call, most UCaaS desktop clients, and a growing share of mobile VoIP already use it — and the verdict writes itself.

Verdict: Opus wins every matchup on technical merit. It matches or beats every codec here on quality per bit, and it is the only one that actively defends the call when the network degrades. The only reason to run anything else is that some element in your call path doesn't support it — which, in the SIP trunk and desk phone world, is still common.

The honest verdict: when codec choice matters and when it doesn't

Here is the part the comparison tables omit. On a clean network — sub-1% loss, jitter under 20 ms, reasonable latency — all four codecs deliver calls users rate as good. The gap between G.711 and Opus on a healthy path is real but modest: wideband richness, nothing more. The gap between any codec on a healthy path and any codec on a degraded one is enormous. A G.711 call over a clean connection beats an Opus call over a congested Wi-Fi link every single time. The network dominates, and no codec rescues a path with 200 ms of jitter or bursty 8% loss.

Codec choice genuinely matters in three situations. Lossy or variable links — Wi-Fi, cellular, congested last miles — where Opus's FEC and concealment convert would-be dropouts into calls that merely sound slightly compressed. Constrained upload bandwidth, where per-call cost determines how many concurrent calls fit before they degrade each other; the difference between ~87 kbps and ~30 kbps per stream is the difference between 10 and 30 usable channels on the same uplink. Trunk economics and capacity planning, where carriers price or provision channels around assumed per-call bandwidth.

Codec choice is a distraction when you are using it to explain quality problems on a path you have never measured. If calls sound bad, the probability that switching G.711 to G.722 fixes it is close to zero; the probability that the cause is loss, jitter, bufferbloat, or a misbehaving router is close to one. Measure first. For a deeper treatment of how encoding decisions ripple into perceived quality, see how codecs shape call quality.

The codec you configured is not the codec you get

One more dose of reality. You do not simply choose a codec — you express a preference, and the call decides. Every SIP or WebRTC call begins with SDP offer/answer negotiation: the caller lists supported codecs in priority order, the callee picks from the intersection, and every intermediary (PBX, SBC, trunk provider) gets a chance to filter, reorder, or strip that list before the far end ever sees it.

This is why codec configuration so often appears not to work. You rank Opus first on your endpoints; the SBC strips it because its transcoding license doesn't cover it; the trunk offers G.711 and G.729 only; your HD-capable phones dutifully complete a G.711 call. Nothing is broken — every element behaved according to its own configuration — but the codec you chose never had a chance. Transcoding adds another wrinkle: a call can be Opus on one leg and G.711 on another, with a lossy conversion in the middle that costs quality on both. If you want to know what your calls actually negotiate and why, our SDP media negotiation guide walks through the offer/answer exchange line by line.

The practical upshot: audit the negotiated codec in a SIP trace or WebRTC internals dump before concluding anything about codec performance, because there is a decent chance your calls are not using the codec you think they are.

Stop reading tables, start measuring

The interaction between codec and network is exactly the kind of thing that resists intuition and yields to measurement. If you want to build that intuition, our MOS explorer lets you dial in packet loss, jitter, and latency against different codec profiles interactively and watch the predicted MOS respond — it makes the "Opus degrades gracefully, G.711 falls off a cliff" behavior visible in about thirty seconds.

And for your actual network, run our VoIP quality test. It sends a real codec-encoded media stream over a real WebRTC path — not a generic ping — so the loss, jitter, and MOS it reports reflect what a genuine call would experience on your connection. The premium tier adds sequential codec-comparison runs, testing the same path with different codec profiles back to back, which answers the question this entire post circles: on your network, with your impairments, does the codec matter? Sometimes the answer is yes by half a MOS point. Sometimes it is no, and now you know to go fix the network instead.