How Codecs Shape Call Quality

Every VoIP call passes through a codec. The codec determines how your voice is converted from an analog signal into digital data, how much that data is compressed, and how much bandwidth the resulting stream requires. It is one of the most important factors in call quality, and it is one that most people never think about because it is negotiated automatically between endpoints before the first word is spoken.

Understanding codecs is not about memorizing bitrate tables. It is about understanding why the same network conditions produce different call quality depending on which codec is in use, and why choosing the right codec for your environment matters more than most network optimizations. If you want to know what conditions your codec actually has to survive, a VoIP quality test measures the packet loss and jitter on your real network path.

What a codec does

The word "codec" is short for coder-decoder. The coder side takes analog audio from a microphone, samples it at regular intervals, and converts those samples into digital data. The decoder side takes the digital data and converts it back to analog audio for the speaker.

Between coding and decoding, some codecs also compress the data. Compression reduces bandwidth but introduces artifacts and makes the audio more fragile in the face of packet loss and jitter. This is the fundamental tradeoff in codec selection: bandwidth versus quality versus resilience.

Every codec produces a stream of RTP packets at regular intervals. The most common interval is 20 milliseconds, meaning 50 packets per second in each direction. Some codecs support different packet intervals (ptime), which affects packet count and per-packet overhead.

The major codecs

G.711 (u-law and a-law)

G.711 is the reference standard for VoIP audio quality. It samples audio at 8kHz and uses 8 bits per sample with no compression, producing a constant 64kbps stream. With IP, UDP, and RTP headers added, a G.711 call uses 80kbps in each direction at the standard 20ms ptime, or about 87kbps once Ethernet framing is counted as well. Which figure you want depends on where you are sizing: the IP number for WAN and trunk capacity, the Ethernet number for switches and the LAN.

There are two variants. G.711 u-law (also written μ-law) is used in North America and Japan. G.711 a-law is used in the rest of the world. The difference is in the companding algorithm used to map the analog signal to 8-bit samples. Both produce equivalent quality.

G.711's strengths are simplicity and predictability. There is no compression algorithm to introduce artifacts. No processing delay beyond the packetization interval. No variability in output quality based on audio content. What goes in comes out, minus whatever the network does to the packets in transit.

Its weakness is bandwidth. At 87kbps per call, G.711 uses roughly three times the bandwidth of compressed codecs. For most modern business internet connections, this is irrelevant: 100 simultaneous G.711 calls need less than 9Mbps. But on constrained links or high-density deployments, the bandwidth adds up. A bandwidth calculator can show you the exact per-call overhead for each codec so you can plan accordingly.

G.711 losses are also comparatively simple to conceal, though that is not the same as being the most resilient narrowband codec. At the same ptime, a lost packet removes the same duration of audio under any codec. What differs is how hard the gap is to hide: G.711 packets carry independent uncompressed samples, so the receiver can fill the gap with basic interpolation (repeating the last good frame), whereas predictive codecs additionally lose decoder state with each missing packet and take longer to recover.

That is one factor among several, not a ranking. How bad a given loss actually sounds also depends on the receiver's packet loss concealment implementation, whether losses arrive in bursts or isolated, whether FEC or redundancy is in use, the bitrate, and the specific stack at each end. Two devices running the same codec on the same impaired path can sound noticeably different.

G.729

G.729 compresses voice audio to 8kbps, roughly one-eighth of G.711's bitrate. With packet overhead, a G.729 call uses about 24kbps at the IP layer, or 32kbps on Ethernet: the headers cost the same regardless of how small the payload is, which is most of why the eightfold payload saving does not translate into an eightfold bandwidth saving. This made G.729 essential in the early days of VoIP when bandwidth was expensive and limited.

The compression works by modeling the human vocal tract and encoding a set of parameters that describe the speech rather than encoding the raw audio samples. The decoder uses these parameters to synthesize audio that sounds like the original. This is CELP (Code-Excited Linear Prediction) coding; the ITU-T names G.729's variant specifically as CS-ACELP, conjugate-structure algebraic-code-excited linear prediction.

The result sounds good for voice: clear and intelligible for most speakers in most conditions. But it does not sound like G.711. Compression artifacts are present, particularly on non-speech audio. Hold music, DTMF tones, modem signals, and fax transmissions all suffer noticeably through G.729 because the vocal tract model does not describe them well.

G.729 is more sensitive to packet loss than G.711. Not because a G.729 packet carries more milliseconds of audio (at the same ptime it carries exactly the same duration) but because each packet encodes a compressed representation rather than raw samples, and the decoder needs context from surrounding packets to reconstruct the signal accurately. A lost packet creates a gap of the same length that is harder to conceal. So at the same loss rate, especially when the losses come in bursts rather than randomly, a G.729 call degrades more than a G.711 call does, because concealment has less to work from.

G.729 was historically encumbered by patents, which required licensing fees. Those patents have expired, but the codec's market position has been largely supplanted by Opus for new deployments.

G.722

G.722 is the standard wideband codec, sampling audio at 16kHz instead of 8kHz. The higher sample rate captures frequencies up to 7kHz (compared to 3.4kHz for narrowband codecs), producing noticeably richer, more natural-sounding voice. This is what marketing calls "HD Voice."

G.722 uses 64kbps, the same as G.711, but at wideband quality. This seems like a free upgrade, and in many environments it is. The catch is that both endpoints and every intermediate device must support G.722. If a call leg transits through a system that only supports narrowband codecs, the call will be transcoded down and the wideband quality is lost.

G.722 is widely supported on modern desk phones and softphones. If your VoIP provider and all your endpoints support it, it is worth enabling for the quality improvement.

Opus

Opus is the modern standard for real-time audio. It supports both narrowband and wideband audio, adjusts its bitrate dynamically based on network conditions, and includes sophisticated packet loss concealment. It was designed for the internet rather than adapted from telephone network standards.

Opus operates at bitrates from about 6kbps to 510kbps, with typical voice configurations using 24-48kbps. At the low end, it outperforms G.729 in quality at comparable bitrates. At the high end, it delivers wideband quality that exceeds G.722. Its adaptive bitrate capability means it can lower its bitrate on the fly when the network degrades, which is more compression, not less, trading audio richness for a stream that fits through congestion. Resilience comes from a separate set of tools the codec was designed with: in-band forward error correction, packet loss concealment, and DTX (RFC 6716).

The packet loss concealment in Opus is significantly more advanced than older codecs. Its in-band FEC (RFC 6716) encodes a redundant low-bitrate copy of each frame into the following packet, allowing the decoder to reconstruct lost packets, provided the feature is enabled and signaled between the endpoints (the useinbandfec parameter of RFC 7587). That is a different mechanism from the concealment older codecs rely on: FEC reconstructs the lost frame rather than masking its absence, which is why Opus with FEC can hold up at moderate loss rates while using less bandwidth than G.711.

Opus is standard in browser-based calling and is increasingly supported by SIP-based VoIP platforms. Its main limitation is that older PBX systems, SIP trunking providers, and desk phones may not support it. Calls between an Opus-capable softphone and a provider that only supports G.711 will negotiate down to G.711.

Other codecs you may encounter

iLBC (internet Low Bitrate Codec). Designed specifically for packet loss resilience at low bitrates (13.3 or 15.2 kbps). Each packet is independently decodable, meaning a lost packet does not affect surrounding audio. Rarely used in new deployments but occasionally seen in legacy browser-calling applications.

GSM. The codec from mobile phone networks, sometimes used in low-bandwidth VoIP. Quality is acceptable for voice but noticeably compressed. Mostly a legacy choice.

G.726. An ADPCM codec that offers bitrates between G.711 and G.729 (16, 24, 32, or 40 kbps). Occasionally used but largely superseded by more modern options.

How codec negotiation works

When a VoIP call is initiated, the calling endpoint sends an INVITE message containing an SDP body that lists its supported codecs in order of preference. The receiving endpoint responds with its own SDP indicating which codec it has chosen from the offered list.

If the two endpoints share no common codec, the call fails. If they share multiple codecs, the answering endpoint typically selects the highest-preference codec that both support.

This negotiation is why you can have a phone configured for Opus that seamlessly falls back to G.711 when calling a provider that does not support Opus. The phone offered both, the provider selected G.711, and the call proceeds at narrowband quality. No error, no warning: just a silent quality downgrade that neither party may notice unless they are listening for it.

Transcoding: the hidden quality tax

When a call passes through a system that needs to convert between codecs (say, the inbound leg uses Opus but the outbound trunk only supports G.711) the system must decode the audio from one codec and re-encode it in the other. This is transcoding.

Transcoding introduces three costs. First, processing load: decoding and re-encoding audio in real time requires CPU resources. At scale, this can be significant. Second, latency: the transcode step adds a small but nonzero delay. Third, and most important, quality loss. Every compression and decompression cycle introduces artifacts. A call that is compressed with G.729, decompressed, then recompressed with G.711 sounds worse than a call that used either codec end-to-end.

Transcoding between two lossy codecs is the worst case. The artifacts from the first codec are baked into the audio signal. The second codec then compresses that already-degraded signal, adding its own artifacts on top. The result is audibly degraded in a way that neither codec would produce on its own.

Avoiding unnecessary transcoding is one of the simplest ways to improve call quality. Use the same codec end-to-end when possible. If your provider's trunk supports G.711 and your phones support G.711, configure G.711 as the preferred codec and eliminate the transcode.

Choosing the right codec

The choice depends on your specific constraints.

If bandwidth is not a concern (most modern offices), use G.711 for maximum compatibility and consistent quality, or G.722/Opus for wideband quality if your entire call path supports it.

If bandwidth is constrained (remote sites on limited links, high-density call centers), G.729 reduces bandwidth significantly at an acceptable quality tradeoff. Opus at a constrained bitrate is a better choice if your infrastructure supports it.

If packet loss is a known issue (and you cannot fix it), Opus with in-band FEC enabled is the strongest starting point, because it can reconstruct some lost audio rather than only conceal it. G.711 is a reasonable fallback given how simple its gaps are to conceal, and G.729 tends to fare worst because each loss also costs decoder state. Treat that as an ordering to test rather than a guarantee: the concealment quality of your particular endpoints, and whether your loss is bursty or isolated, can matter more than the codec choice.

If you are mixing endpoints (desk phones, softphones, mobile clients, browser clients), you will likely end up with multiple codecs in play. Make sure your PBX or provider handles the negotiation cleanly and minimize transcoding by aligning codec preferences across endpoint types.

The codec is not usually the first thing to troubleshoot when calls sound bad. Network conditions (jitter, loss, congestion) cause the majority of quality problems regardless of codec. But the codec determines how gracefully the audio degrades when network conditions are imperfect, and it sets the ceiling on your MOS score: even a perfect network cannot push G.729 past roughly 3.9, and you can watch how each codec moves the score under loss and jitter in the MOS Explorer. Understanding why voice is uniquely demanding and how your codec choice interacts with your network reality is part of building a VoIP deployment that sounds good consistently, not just when conditions are ideal.