Choosing between G.711 and G.729? You’ll trade fidelity for bandwidth. G.711 runs at 64 kbps (≈80–87 kbps per call with overhead), scores ~4.1–4.2 MOS, and adds ~125 µs delay—ideal on LANs. G.729 compresses to 8 kbps (≈16–24 kbps per call), averages ~3.92 MOS, adds ~165–200 ms, and saves WAN bandwidth but needs more CPU and licenses. Minimize transcoding to preserve MOS. Use G.711 for quality, G.729 for scale. There’s more that sharpens this choice.
Key Takeaways
- G.711 delivers higher voice quality (≈4.1–4.2 MOS) with minimal delay, while G.729 averages ≈3.92 MOS and adds higher latency.
- Bandwidth: G.711 uses ~80–87 kbps per call; G.729 typically 16–32 kbps depending on 20–40 ms payload.
- Use G.711 on LANs for fidelity; choose G.729 on bandwidth-limited WANs to scale more calls.
- G.711 is license-free and lighter on CPU; G.729 requires per-channel licensing and more processing.
- Avoid transcoding; multiple G.729 encode/decode cycles degrade quality more than G.711.
Bitrate and Bandwidth at a Glance
At a glance, G.711 runs at a raw 64 kbps using PCM with minimal processing, while G.729 compresses to 8 kbps—an 8:1 reduction that cuts raw bitrate to 12.5% of G.711. You’ll see the compression rate tradeoffs immediately in bandwidth: with headers, G.711 averages about 80 kbit/s per call, whereas G.729 lands near 32 kbit/s.
Packetization matters. A 20 ms G.729 payload consumes roughly 24 Kbps including IP/UDP/RTP’s fixed 40-byte overhead; doubling to 40 ms drops it to about 16 Kbps. For multiple calls, five G.711 streams can push ~512 kbit/s, while five G.729 calls stay near 200 kbit/s—over 60% savings. G.711 clarity generally surpasses G.729 due to its higher bitrate, making it preferable when voice quality is the top priority.
Factor processing: G.711 is light; G.729’s CPU needs rise. Use payload sizing and audio sampling optimization to balance network and hardware limits.
Voice Quality Metrics and MOS Scores
If you judge voice by the numbers, MOS makes the trade-offs clear: G.711 reliably scores 4.1–4.2—near the narrowband ceiling—while G.729 averages about 3.92 and hits 4.0 after a single encode/decode. You’ll hear G.711’s uncompressed clarity as the industry’s gold standard; it preserves full fidelity across the 300–3,400 Hz band. G.729’s lossy compression sacrifices subtle nuances but keeps intelligibility “good” for most business calls.
Voice quality perception still hinges on delay, packet loss, and jitter. Under equal network conditions, G.711 maintains a 0.2–0.3 MOS edge and stays consistent across hops and transcoding. G.729 degrades with multiple encode/decode cycles, and artifacts can make synthetic voices sound more artificial. For codec interoperability considerations, minimizing transcoding preserves MOS and keeps toll-quality thresholds intact. Additionally, best practice is to use G.711 in LAN and G.729 in WAN to balance quality and bandwidth efficiency.
Processing Load and Performance Impact
You’ll see stark differences in CPU load: G.711 is medium complexity and typically supports ~4 calls per DSP channel, while G.729 is high complexity and often halves that to ~2, with G.729A easing demands at some quality cost. Importantly, G.711 is free and widely supported, while G.729 is licensed per channel and needs more CPU, which can affect total cost and capacity planning.
Higher compute for G.729 increases latency—especially during transcoding—and can slash concurrent call capacity unless you add DSPs or hardware offload. Plan scalability around these realities: bandwidth saved by G.729 can be offset by CPU, whereas G.711 usually delivers higher call density with minimal processing overhead.
Codec CPU Demands
Cut through the noise: G.711 barely taxes the CPU, while G.729’s compression hits processors hard. You’ll see this immediately in environments with hardware limitations and scaling challenges. G.711’s simple, uncompressed path uses minimal CPU, runs well on legacy gear, and keeps headroom for other workloads. G.729’s “computationally perplexing” algorithm demands far more cycles per call, especially during transcoding, which slashes concurrent call capacity on software PBXs. Opus is widely regarded as the best voice codec for VoIP in 2025, offering unmatched audio quality. Expect higher infrastructure costs with G.729: more powerful CPUs, or offload to dedicated DSPs, hardware transcoders, or gateways. At scale—thousands of endpoints or voice AI agents—G.729’s processing load becomes a gating factor. G.711 delivers MOS ≈4.2 quality with negligible CPU overhead, ideal on LANs. Use G.729 on constrained WAN links, but budget for CPU and per-channel licensing.
Latency and Scalability
CPU headroom is only half the story; latency and scale separate G.711 and G.729 in real networks. G.711 adds only 125 microseconds of algorithmic delay, delivering near-instant audio and a MOS around 4.1, but it consumes about 87 kbps per call leg. This matters because G711 codec offers excellent sound quality but requires more bandwidth than G.729.
G.729 introduces ~15 ms algorithmic latency plus roughly 75 ms per endpoint for encode/decode, so you must budget ~165–200 ms one-way in loaded paths to keep round-trip under 400 ms.
In bandwidth-limited WANs, G.729’s 8 kbps payload (16–24 kbps with headers) yields an eightfold capacity gain, enabling far more concurrent calls. That’s a clear scalability win with acceptable MOS (~3.92).
On clean LANs, choose G.711 for fidelity and minimal jitter sensitivity. Balance quality of service trade offs with network topology considerations—loss, jitter, international delay ceilings, and branch bandwidth.
Audio Sampling, Coding Methods, and Frequency Range
You’ll compare PCM in G.711 to CS-ACELP in G.729: 64 kbps waveform coding vs. 8 kbps predictive coding. Both sample at 8 kHz and target the same narrowband 300–3,400 Hz voice range. Expect MOS ≈4.2 for G.711 and ≈4.0 for G.729, with quality more resilient in G.711 across transcoding. Additionally, G.711 is a royalty-free codec introduced by the ITU in 1972, while G.729 is a licensed codec with fees typically bundled into hardware supporting G.729 licensing.
PCM vs. CS-ACELP
Although both target telephony, PCM (G.711) and CS-ACELP (G.729) take fundamentally different paths in how they sample and code audio. You get uniform 8 kHz sampling in G.711 with direct amplitude quantization (A-law/μ-law), no prediction, and a fixed 64 kbps stream. G.729 processes 10 ms frames (80 samples), applies speech modeling and vocal tract simulation via CS-ACELP, and compresses to 8 kbps (variants: 6.4–11.8 kbps). In VoIP deployments, the G.711 codec uses 8-bit uncompressed PCM encoding at 64 kb/s, offering minimal delay and wide interoperability.
- G.711: waveform coding, license-free, minimal delay, higher fidelity.
- G.729: predictive speech coding, licensed, ~15 ms algorithmic delay, bandwidth-efficient.
| Attribute | G.711 (PCM) vs. G.729 (CS-ACELP) |
|---|---|
| Sampling | 8,000 SPS vs. 10 ms frames (80 samples) |
| Coding | Waveform PCM vs. CELP with adaptive codebooks |
| Bit rate | 64 kbps vs. 8 kbps (6.4–11.8 kbps variants) |
| Processing | Low CPU, universal support vs. higher CPU, licensed |
Narrowband Frequency Range
Why do both G.711 and G.729 sound like “telephony”? Because they’re both narrowband: 300–3,400 Hz, sampled at 8,000 samples per second. You capture core speech energy and discard everything else. That bandpass defines telephone sound characteristics—clear for voice, thin for music or rich ambience.
G.711 uses uncompressed PCM (μ-law/A-law), delivering MOS ≈ 4.2. G.729 uses lossy CS-ACELP frames (~10 ms, ~80 samples), MOS ≈ 4.0 after one pass. Same frequency range, different coding methods, different call quality trade offs and bandwidth needs: 64 kbps vs 8 kbps per direction. VoIP codecs also determine bandwidth requirements and influence latency and jitter across the network.
- Narrowband focus: intelligibility prioritized; higher and lower tones excluded.
- Sampling parity: 8 kHz rate anchors identical spectral limits.
- Practical impact: G.711 sounds fuller; G.729 saves bandwidth but magnifies artifacts with multiple transcodes.
Network Overhead and Total Call Bandwidth
Cut through the noise by focusing on what really drives call bandwidth: payload bitrate plus near-constant protocol overhead. You’re adding fixed IP/UDP/RTP (20/8/12 bytes) and about 18 bytes at Ethernet per packet, so overhead is largely codec-agnostic. That’s why G.711 at 64 kbps lands around 80–87 kbps per call, while G.729 at 8 kbps totals about 28–32 kbps.
Packetization matters: 20 ms frames for G.711 (160 samples) are efficient; shrinking intervals raises overhead percentage. G.729’s 30-byte payload stays more efficient in constrained links.
Plan for concurrency. Five G.711 calls consume roughly 400–512 kbps; five G.729 calls need about 140–200 kbps. Use dynamic bandwidth optimization and codec selection flexibility to match conditions: prioritize G.711 for fidelity, switch to G.729 when capacity is tight. Additionally, remember that different codecs inherently consume different bandwidth, so selecting G.711 versus G.729 directly changes per-call usage.
Licensing History and Cost Implications
While both codecs deliver voice, their cost DNA diverges sharply: G.711 is an ITU standard from 1972 that’s royalty-free, whereas G.729 emerged later with patent-backed compression and per-channel royalties.
You face straightforward licensing criteria with G.711—none. Its open status created strong adoption incentives, universal interoperability, and zero ongoing fees beyond equipment. As a cornerstone VoIP codec, G.711 uses Pulse Code Modulation, reinforcing its role in ensuring clear and reliable voice communication.
G.729, by contrast, layers royalties into hardware pricing and charges per software channel; costs scale with concurrent calls and vary by vendor and volume.
- G.711: zero royalties, predictable budgets; implementation cost equals hardware only.
- G.729: per-channel fees, bulk discounts for manufacturers, different models for hardware vs software.
Economic signal: as call volume rises, G.711’s cost advantage widens; enterprises negotiate G.729, while small shops often “prepay” via device pricing.
Best-Fit Use Cases for LAN, WAN, and PSTN Interconnects
Cost differences set the stage, but network context decides which codec you should run. On LANs, pick G.711. You’ve got abundant bandwidth; its 64 kbps stream and light CPU load deliver MOS ≈4.2 for crisp internal calls. G.729’s compression brings little value inside modern LANs.
Across WAN links, choose G.729. It slashes bandwidth by 87.5% (8 kbps vs. 64 kbps), sustaining more concurrent calls and preventing congestion in high-volume scenarios. MOS ≈4.0 remains business-grade, and the extra processing is a fair trade. Pair it with call prioritization and redundancy controls to maintain sessions stable under load.
For PSTN interconnects, default to G.711. It matches legacy expectations (toll-quality, 300–3,400 Hz) and guarantees seamless gateway compatibility, including typical cellular handoffs. Configure codec negotiation by path.
Transcoding Effects and Multi-Hop Considerations
Think of transcoding as a necessary tax when your call crosses networks that don’t share a codec. When G.711 meets a G.729-only segment, media gateway transcoding kicks in, adding processing load and latency. Each hop compounds delay and quality loss—especially with compressed codecs. G.711 tolerates several hops; G.729’s MOS (~4.0) falls fast after 2–3 compress/decompress cycles.
Avoid multiple compressed-to-compressed conversions; use G.711 as the intermediary when you must transcode.
Place edge device transcoding at borders to localize processing and protect core paths.
Monitor hops; every gateway adds protocol overhead and jitter risk.
Balance bandwidth and CPU: G.711 uses 64 kbps with light processing; G.729 saves to 8 kbps but costs CPU. Centralize transcoding, align peer codecs, minimize hops.
Variants, Features, and Compatibility Notes
You’ll pick between two clear families: G.711 (μ-law in North America/Japan, A-law in Europe) at a fixed 64 kbps with minimal CPU and a MOS ~4.2, versus G.729 variants at 8 kbps—G.729a (reduced complexity), G.729b (VAD/comfort noise), and G.729ab (both)—with a MOS ~4.0 that drops under repeated transcoding.
G.711 is uncompressed narrowband (300–3,400 Hz), 8 kHz sampling, universally supported, and ideal for fax, modems, PSTN gateways, and music on hold.
G.729 shares the same bandwidth and sample rate but uses aggressive compression and silence compression techniques; you trade bandwidth savings for higher CPU and audio quality tradeoffs. Expect about 15x more processing than G.711 (G.729a halves that). Licensing may apply.
Voice AI and rich audio prefer G.711.
Dynamic Codec Selection and Deployment Guidance
You should enforce policy-based codec switching via SDP/SIP preferences and region rules (e.g., G.729 first on constrained links, G.711 on premium lines) while honoring early/late offer behavior.
Route calls with bandwidth awareness—G.729 saves ~87.5% vs G.711 for internal paths—then trigger real-time fallback/upgrade (G.729⇄G.711/G.722) as conditions change.
Minimize transcoding by matching peer capabilities, using G.711 as the common intermediary only when unavoidable to avoid compounded CPU load and quality loss.
Policy-Based Codec Switching
When you switch codecs by policy, treat it as a deterministic pipeline: allow, add (egress only), then order. Start with allow-codecs; omitting it blocks traffic. Use “*” to baseline, then tighten for policy based transcoding avoidance and CERG codec optimization. Session-agent policies override domain policies, and egress runs on SDP already changed by ingress. If you add on egress and also set order-codecs, ordering from order-codecs wins. Enforce packetization with force-ptime; valid packetization-time values are 10–90 ms (default 20). Conditions pair target codec and trigger; process all policies serially.
Apply codec policies via realm-config; you don’t need both directions.
For cluster-wide defaults, adjust service parameters.
Purge CODEC config and power-cycle during network changes; require Superuser confirmation for domain changes.
Bandwidth-Aware Routing
Building on policy-based switching, bandwidth-aware routing ties codec choice to live network conditions and hard thresholds. You use monitoring driven decision making: real-time capacity, packet loss, jitter, and congestion steer G.711 versus G.729.
Pre-set triggers act: loss >1% or jitter >30 ms favors G.729; ample bandwidth prioritizes G.711’s 4.2 MOS over G.729’s 4.0.
Quantify before you choose. A single G.711 call consumes 80–87 kbps; five need ~512 kbit/s. G.729 uses ~32 kbps per call; five need ~200 kbit/s. On DSL with 512 kbps upstream, target six G.711 calls; on constrained links, default to G.729.
Implement automated configuration options: codec preference lists, continuous capacity probes, and WAN-aware triggers that switch codecs dynamically. This keeps voice clarity aligned with available bandwidth.
Transcoding Avoidance Strategies
A disciplined way to avoid transcoding is to make codec negotiation predictable end to end: align endpoint capabilities, constrain offers/answers, and place any necessary conversion at the edge.
Start with SIP configuration guidelines: in Asterisk, use disallow=all, then allow in priority order. Guarantee the top codec in any SDP answer existed in the offer. Strip or add codecs via ingress/egress policies, and use force-ptime to block incompatible intervals.
Match capabilities on adjacent legs; expect G729 at the access, G711 in the core. Put transcoding only on SBCs/BGFs at peering edges; keep media gateways out of heavy conversions. Monitor Channel.c warnings for native format mismatches. Plan for fax (PCMU/PCMA) and IVRs (G711). Drive resource capacity planning with codec mix telemetry.
- Prevent hidden transcodes with strict SDP policing
- Localize conversions at edges to lower core costs
- Prioritize G729 where bandwidth is constrained
Frequently Asked Questions
How Do G.711 and G.729 Affect Call Setup Times?
G.711 typically sets up faster due to negligible algorithmic delay and light processing. You’ll see slower G.729 setups from compression and buffering, unless bandwidth requirements dominate—then G.729’s 8 kbps aids network utilization and boosts setup reliability on constrained links.
Are There Emergency Calling (E911) Considerations for Each Codec?
Yes. You prioritize Emergency call reliability in your Codec selection for E911. Use G.711 for superior fidelity (MOS 4.2), legacy compatibility, and lighter processing. Prefer G.729 only under constrained bandwidth; it’s efficient (8 kbps) but risks intelligibility and transcoding degradation.
Do These Codecs Impact DTMF and Fax Transmission Reliability?
Yes. You’ll get superior DTMF reliability and fax transmission reliability with G.711 due to uncompressed audio. G.729 degrades in-band tones and fax signals; use RFC 4733 for DTMF or T.38/fax relay, or negotiate G.711 during fax.
What Troubleshooting Steps Differ Between G.711 and G.729 Call Issues?
You troubleshoot G.711 by tightening packet loss handling (<1%), jitter/latency, and bandwidth optimization for 64 kbps streams. For G.729, prioritize compression artifacts, PLC tuning, variant compatibility, and negotiation order; allow higher loss (3–5%) and verify WAN congestion thresholds.
How Do G.711 and G.729 Influence Battery Life on Mobile Clients?
G.711 drains less battery; G.729’s heavier compression increases CPU cycles and energy use. You balance Bandwidth utilization against power: G.729 saves bandwidth but costs battery. Transcoder requirements further tax processing, so you switch codecs dynamically based on battery thresholds.
Conclusion
You’ve seen the tradeoffs clearly. G.711 delivers 64 kbps, near-transparent quality (MOS ~4.3), minimal CPU, but higher bandwidth. G.729 hits 8 kbps, solid quality (MOS ~3.9), higher CPU, tighter bandwidth—great for WAN. Account for RTP/UDP/IP overhead: ~87–100 kbps per G.711 call vs ~31–40 kbps for G.729. Avoid unnecessary transcoding; it compounds artifacts and latency. Use G.711 on LAN/PSTN interconnects, G.729 over constrained links. Enable dynamic codec selection based on jitter, loss, and policy.
