G.711 vs G.729: VoIP Codec Comparison

Almost every SIP trunk negotiation, IP-PBX configuration, and carrier interconnect sooner or later forces the same decision: G.711 or G.729. The two codecs are the practical defaults for digital voice over IP, and they were designed for opposite worlds. G.711 carries voice at near-PSTN quality and consumes 64 kbps per call before any network overhead. G.729 compresses the same speech down to 8 kbps using an aggressive predictive algorithm, at the cost of some quality, some CPU, and a long history of licensing complications.

This article is a head-to-head comparison: bandwidth math, voice quality, CPU and license cost, fax and DTMF compatibility, and a clear framework for choosing one or the other on each leg of a real network. For the broader codec landscape including Opus and AMR, the SIP trunking pillar covers the wider context. For the mechanics of converting between codecs when both end up on the same call, the SBC AMR to G.711 transcoding article goes deep on the transcoding plane.

The Engineering Difference

G.711 and G.729 sit at opposite ends of the bandwidth-quality trade-off, and the engineering reasons trace back to when each codec was designed.

G.711 dates to the 1970s and was built for fixed-line digital telephony. It samples speech at 8 kHz, applies a simple logarithmic compression (A-law or µ-law) to each sample, and produces a steady 64 kbps stream. The math is almost trivial: an x86 CPU can encode and decode thousands of concurrent G.711 streams without breaking a sweat, and converting between A-law and µ-law is a lookup table. Voice quality is essentially what you get from a wired PSTN call.

G.729 dates to the mid-1990s, when corporate VoIP was being shoved through 64 kbps or 128 kbps WAN links that also had to carry data. It samples at the same 8 kHz but compresses each 10 ms frame down to 80 bits using CS-ACELP, yielding 8 kbps. The codec analyzes short windows of speech, models the speaker’s vocal tract as a set of filter coefficients, and transmits the coefficients plus an excitation index instead of the waveform itself. The receiver synthesizes the speech back from those parameters. The compression works well for human voice and badly for everything else, which is why G.729 cannot carry fax modem tones, music on hold, or in-band DTMF reliably.

The signaling-side reference for how each codec is offered and accepted lives in the SDP body of the SIP INVITE, defined in RFC 4566. The codec list and its priority order are what the negotiation operates on, and an SBC has full visibility into both sides.

Bandwidth: What the Numbers Actually Look Like

The 64 kbps versus 8 kbps headline figure is the codec payload alone. Real per-call bandwidth on the wire is higher on both sides because every RTP packet carries RTP, UDP, IP, and Ethernet headers that add the same number of bytes regardless of how much audio is inside.

At a typical 20 ms ptime, the math works out roughly as follows. G.711 generates 50 packets per second, each carrying 160 bytes of audio plus about 54 bytes of RTP/UDP/IP/Ethernet headers, for a total of around 85 to 87 kbps per direction. G.729 generates the same 50 packets per second, each carrying 20 bytes of audio plus the same 54 bytes of headers, for a total of around 31 kbps per direction. The compression ratio in the payload is 8 to 1, but on the wire it collapses to roughly 2.8 to 1.

Three implications follow. First, larger ptime values (30 or 40 ms) shrink the header overhead and improve the ratio for both codecs, but they also increase end-to-end delay if a packet is dropped, which matters more for low-bit-rate codecs that have less redundancy to begin with. Second, VAD with G.729b cuts the average bit rate further during silence (often by 30 to 50 percent), which helps on shared links but breaks fax and some IVR prompts. Third, the bandwidth savings of G.729 only matter when the link is actually constrained. Inside a managed LAN, on a modern dedicated SIP trunk, or on any link sized for HD video, the difference between 87 kbps and 31 kbps per call is rarely the decision driver.

Voice Quality

G.711 delivers near-toll-quality voice at a Mean Opinion Score of roughly 4.2, which sits within the same range as a wired PSTN call. G.729 sits at roughly 3.9, which most listeners hear as “good but slightly compressed.” Whispered consonants lose definition, sibilants soften, and the sense of presence drops. Nobody will mistake the call for high-fidelity audio, but conversational speech remains intelligible.

The gap matters in three specific situations. The first is tandem transcoding. Every time a call is transcoded from G.729 to G.711 and back, the MOS drops further because the lossy compression compounds. Two G.729-to-G.711 hops in the same call path push perceived quality noticeably below either codec alone, which is why network architects try to minimize the number of transcoding points in any given route. The second is wideband audio. G.729 caps the call at 8 kHz sampling regardless of what either endpoint is capable of, so a Microsoft Teams or WebRTC client that could otherwise deliver wideband Opus will sound narrowband across a G.729 leg. The third is noisy or stressed speech. CS-ACELP is tuned for clean voice; background noise, simultaneous talkers, and emotional or shouted speech all degrade more sharply on G.729 than on G.711.

If voice quality is the primary KPI for a deployment (executive conferencing, contact center recording, sales call analytics), G.711 wins by default. If bandwidth is the binding constraint, the MOS hit on G.729 is a known and manageable trade-off.

CPU, Licensing, and Where the Cost Hides

G.711 is effectively free in both CPU and license terms. The codec is a public ITU-T recommendation with no patent encumbrance, every commercial PBX and SBC supports it natively, and a modern CPU encodes thousands of concurrent streams without breaking 5 percent utilization.

G.729 has a more complicated history. The codec was patent-encumbered for years, with royalties owed to Sipro Lab Telecom and other holders. The patents began expiring in 2017 and the codec became effectively royalty-free, which prompted several open-source projects to add native G.729 support. The commercial reality has not fully caught up. Many enterprise PBX vendors (Cisco, Avaya, and others) still charge per-channel G.729 licenses, partly as legacy revenue capture and partly because hardware DSP boards still carry per-channel licensing terms. The result is that the per-call cost of G.729 on a managed PBX deployment is often dominated by the license, not by the CPU or the bandwidth.

CPU cost on the codec itself is real but modest on modern hardware. Pure-software G.729 encode/decode is workable for hundreds of concurrent streams on a commodity x86 core. At carrier scale, however, hardware DSP acceleration remains the practical default because predictable per-channel latency matters more than peak throughput. ProSBC pairs with TSBC-HW-TRANS for hardware-accelerated G.729 transcoding when a deployment needs the codec at scale; software G.729 transcoding inside ProSBC is on the product roadmap for late 2026.

Fax, DTMF, and Modem Compatibility

The cleanest way to summarize this section is that G.711 is fax-safe and G.729 is fax-fatal. CS-ACELP models speech, not signaling tones, and the moment a T.30 fax handshake hits a G.729 codec the modem tones are unrecoverable. Any fax-bearing call path must either stay on G.711 end to end with passthrough conditions met (echo cancellation disabled, VAD disabled, near-zero packet loss) or switch to T.38 relay at the SBC. The Fax over IP and T.38 article covers the relay mechanics in detail.

DTMF has a parallel story. In-band DTMF carried as audio survives G.711 but not G.729. The fix is RFC 2833 (now RFC 4733), which carries DTMF as named RTP events outside the audio stream. Most modern SIP endpoints negotiate RFC 2833 by default, but legacy IVRs and some PBX trunk types still emit in-band DTMF that an SBC has to detect and convert. If G.729 is in the path, RFC 2833 is mandatory.

Modem and TTY traffic have the same constraint. Voice-band data of any kind needs G.711 or it does not survive the compression.

When to Use Each: A Decision Framework

The choice usually decides itself once the network is mapped honestly. The pattern that holds across most deployments is straightforward.

Inside a managed LAN, on a dedicated SIP trunk sized for the call load, on a UCaaS connection over a healthy WAN, or on any leg where bandwidth is not the binding constraint, G.711 is the default. Quality is higher, CPU is cheaper, fax and DTMF interop is automatic, and the license is free. The bandwidth savings of G.729 do not justify the trade-offs when the pipe is wide enough.

G.729 still earns its place on three kinds of links. Constrained WAN segments, typically branch offices linked to headquarters over 1 to 4 Mbps shared circuits where every 50 kbps of voice headroom matters; mobile, satellite, or maritime backhaul where bandwidth is metered or genuinely scarce; and legacy carrier interconnects where the upstream provider only offers G.729 on a given termination route. In each of these cases the saved bandwidth is meaningful, the fax and DTMF concerns are handled with T.38 and RFC 2833, and the perceptible quality hit is acceptable for the use case.

The trickier middle ground is high-density hosted PBX or contact center platforms where customers are spread across a mix of network types. The right answer there is rarely a single codec choice for the platform; it is a per-customer or per-trunk codec policy enforced at the SBC.

Mixed Networks and the Role of the SBC

Most real networks have both codecs in play. A North American carrier hands off G.711 µ-law to one customer, a European carrier offers A-law to another, a constrained branch office runs G.729, and a Teams Direct Routing tenant negotiates Opus or Silk on its leg. The SBC is the only network element with the per-leg media control, the SDP visibility, and the policy hooks to mediate cleanly between all of them.

Three SBC functions matter for codec policy. The first is per-leg codec negotiation through SDP rewriting: the SBC can offer one codec to the carrier and a different one to the PBX, then bridge the two with transcoding in the middle. The second is per-NAP codec configuration, where each trunk group carries its own preferred-codec list, fallback list, and packetization rules, all enforced at the boundary without either endpoint needing to know what the other is doing. The third is transcoding capacity itself. Software transcoding inside ProSBC handles G.711 A-law to µ-law natively, which covers the most common North-America-to-Europe interop case. Hardware DSP transcoding through TSBC-HW-TRANS covers G.729, AMR, and the full set of complex codecs at carrier scale.

The deeper mechanics of how a B2BUA SBC actually negotiates and converts codecs between legs are covered in the SBC AMR to G.711 transcoding article. The decision in front of the architect is which codec to enforce on each NAP. The SBC is how that decision becomes real on the wire.

Frequently Asked Questions

Conclusion

The G.711 versus G.729 decision is rarely as close as it looks on paper. G.711 wins on quality, CPU, licensing, fax interop, and DTMF reliability, and the bandwidth difference (87 kbps versus 31 kbps per call on the wire) only matters when the link is actually constrained. G.729 still earns its place on narrow WAN segments, mobile backhaul, and legacy carrier interconnects where the bandwidth saving is real. The harder problem in most networks is not picking one codec, it is enforcing a coherent per-leg codec policy across a network where both end up in play. That is the SBC’s job, and the per-NAP policy at the boundary is where the decision becomes operational.