What is G.711, and how does this voice codec work?

Voice quality often feels random until you realize everything rides on a tiny codec choice. G.711 is the quiet default many PBXs and SIP trunks still rely on. For the formal standard, see the ITU-T Recommendation G.711 ¹.

G.711 is a 64 kbps PCM codec that samples voice at 8 kHz with 8-bit companding. It gives classic PSTN narrowband quality, very low delay, low CPU usage, and excellent interoperability for VoIP and SIP intercoms.

²

Once G.711 is clear, other choices like G.729 or Opus make more sense. G.711 becomes your “baseline” codec toward the PSTN, for fax and tones, and as a safe fallback when wideband codecs fail or do not match between endpoints.

How does G.711 μ-law differ from A-law for me?

Regional standards often confuse global projects. Phones work in one country, then sound wrong or fail to negotiate codecs in another. Much of this comes down to μ-law vs A-law.

G.711 has two variants: μ-law (PCMU) mainly in North America and Japan, and A-law (PCMA) in most of the rest of the world. They use the same 64 kbps rate but different companding curves and payload IDs.

³

Where μ-law and A-law actually matter

Both μ-law and A-law:

• Sample at 8 kHz
• Use 8 bits per sample
• Produce a 64 kbps stream
• Deliver similar “PSTN quality” voice

The difference sits in how they compress the dynamic range. μ-law keeps a bit more resolution at higher amplitudes, A-law spends more resolution on lower-level signals. In practice, most users do not hear a big difference in normal calls.

What matters more is interop and region. For RTP:

• Payload type 0 = PCMU (μ-law)
• Payload type 8 = PCMA (A-law)

Those static payload type assignments are defined in the RTP A/V Profile (RFC 3551) ⁴. Most SIP trunks in North America expect μ-law as the default. Many European trunks expect A-law. Phones, intercoms, and PBXs usually support both, but they will offer one first.

A simple summary:

In mixed deployments, PBXs often sit in the middle. For example, a SIP intercom or IP phone might use G.722 or Opus inside the LAN. The PBX then transcodes to G.711 μ-law toward a North American SIP trunk, or A-law toward a European carrier.

For DJSlink SIP intercoms and gateways, I normally:

• Use μ-law when the trunk or carrier is in North America.
• Use A-law when the trunk is in Europe or the Middle East.
• Enable both on LAN devices so the PBX can choose.

The key point: decide your “default G.711 flavor” per site or region and keep it consistent across trunks and PBX profiles. That avoids odd one-way audio or failed codec negotiation when you expand.

When should I prefer G.711 over compressed codecs?

Compressed codecs promise more calls in less bandwidth. In reality, they add complexity, delay, and sometimes licenses. Sometimes the simple 64 kbps choice wins.

I prefer G.711 on LAN and good WAN links when I want low delay, easy interop, better fax and tones, and I am not under heavy bandwidth pressure. Compressed codecs are for truly tight links.

⁵

Bandwidth versus simplicity and quality

G.711 uses 64 kbps for the raw stream. On RTP with 20 ms packets, each call needs roughly 80–90 kbps each way once headers and Ethernet framing are included. That is more than G.729, which lands around 30–40 kbps, and often more than a tuned Opus stream.

A quick comparison:

On a modern LAN or a decent fiber WAN, that extra bandwidth is rarely a real problem. The network core can easily handle dozens or hundreds of G.711 calls. In that context, G.711 gives some strong advantages:

• Very low algorithmic delay
• Simple configuration on PBXs, SIP trunks, and IP phones
• Almost universal support on carriers and gateways

That makes it an ideal choice:

• Between PBX and SIP trunk when you want least surprise.
• Between IP phones and on-premise PBX in a wired LAN.
• Between SIP intercoms and IP PBX when door audio must be snappy.

Where compressed codecs still make sense

There are still cases where G.711 is too heavy:

• Sites with very small WAN pipes (old MPLS, satellite, LTE with limited uplink).
• Remote branches with many concurrent calls over limited VPN tunnels.
• Legacy hardware that only supports G.729 for certain links.

In those cases, I often:

• Use Opus or G.722 inside the LAN or over good VPNs.
• Use G.711 toward the PSTN or cloud trunks when bandwidth allows.
• Use G.729 only on truly constrained segments and keep it at the edge.

The design goal is simple: use G.711 as the default “safe” codec whenever the network can handle it, and drop to compressed codecs only in clearly identified parts of the path. That reduces transcoding, improves interop, and keeps call quality more predictable.

Can G.711 deliver fax and DTMF more reliably?

Fax and DTMF tones are still part of many security and elevator systems. Compressed codecs often distort these tones or break fax handshake completely.

G.711 is much better for fax pass-through and in-band DTMF than low-bitrate codecs. It preserves tones with minimal processing, so modems, alarms, and legacy equipment have a higher chance of working.

⁶

Why tones survive G.711 better

G.711 is very close to “raw” PCM in the telephony sense. It uses simple companding and no heavy prediction or psychoacoustic tricks. Fax and modem signals were designed in a world where this was the standard path.

When a low-bitrate codec like G.729 or a low-rate Opus mode sees these tones, it tries to compress them as if they were voice. That process removes fine detail and can change timing slightly. Fax and modem protocols are very sensitive to that.

For DTMF, you have three common options:

G.711 gives you:

• Good in-band DTMF for simple setups.
• A safe path for tones from some door controllers, alarm panels, and ATAs.
• Better results for fax pass-through when T.38 is not available.

In many projects with SIP elevators, emergency phones, and legacy fax machines, the strong rule is: use G.711 or T.38, never G.729, for those legs.

Practical fax and tone design with G.711

In a real PBX design, I often combine these rules:

• Set trunks and gateways that carry fax or modem traffic to G.711 only.
• Enable T.38 where both ends support it, but fall back to G.711 pass-through rather than G.729.
• Use RFC 2833 or SIP INFO for DTMF whenever a carrier and PBX both support it.

A small decision table helps:

By treating G.711 as the “tone-friendly” codec, you avoid many strange one-way DTMF issues and “half-fax” failures that are hard to debug in the field. This matters a lot for DJSlink SIP elevator phones, emergency intercoms, and any device that still talks with tones under the hood.

Why do G.711 calls clip on congested links?

Sometimes calls sound perfect inside the office but clip, stutter, or drop syllables when remote sites or VPN users talk. People often blame the codec, but the real issue is congestion.

G.711 calls clip on congested links because packets are dropped or delayed beyond the jitter buffer. Without built-in FEC, even small loss causes audible gaps, so QoS and bandwidth planning are critical.

⁷

What happens to G.711 on a busy link

G.711 sends about 50 RTP packets per second per direction at 20 ms packetization. There is no built-in forward error correction. If packets are late or lost, the jitter buffer must:

• Drop late packets.
• Stretch or repeat recent samples (PLC).
• Or produce a short mute.

On a congested link, several things can happen:

• Queue drops on routers when upstream bandwidth is full.
• Bufferbloat that adds delay, pushing packets beyond jitter buffer limits.
• Competing traffic like large file transfers or video that grabs all the upstream capacity.

Because G.711 uses more bandwidth than compressed codecs, it hits these problems sooner on a small pipe. The codec itself is not fragile, but the network must give it a clean path.

A simple view:

How to stop clipping on real networks

To fix clipping, I focus on the network rather than changing codec first:

1. Measure: use tools or router stats to check packet loss, jitter, and actual bandwidth use on WAN links.
2. Apply QoS: mark RTP with DSCP EF and give it a strict priority or high-priority queue on every hop.
3. Shape at the edge: cap traffic slightly below the ISP rate so your router does the queuing, not the provider.
4. Reserve capacity: ensure worst-case concurrent calls still fit comfortably in the uplink, including overhead.

In some cases, raising the packetization interval from 20 ms to 30 or 40 ms reduces header overhead but adds delay and makes single packet loss more painful. For G.711, 20 ms is usually the best balance; I rarely stretch beyond that unless I fully understand the trade.

If a remote site has a very small link and no budget for upgrades, then a lower-bitrate codec (or fewer simultaneous calls) may be needed. But even then, QoS, policing, and good design matter more than simply switching codec.

Once the network treats voice as first-class traffic, G.711 becomes very stable. Calls stop clipping, intercom audio feels instant, and the PBX behaves much closer to a traditional PSTN system in terms of reliability.

Conclusion

G.711 is still the foundation codec for SIP trunks, PBXs, intercoms, fax, and tones. With solid QoS, clear μ-law/A-law choices, and enough bandwidth, it stays simple, predictable, and easy to support.

Footnotes