Current Location ：
Codec Selection for Business Voice: G.711, G.729, Opus and the Trade-offs
Codec selection is usually decided once, during design, by whoever wrote the template. It then stays in place for a decade while the network underneath changes beyond recognition. The decision matters more than most people expect: it sets the bandwidth per call, it determines whether a constrained link can carry voice at all, and it decides how much transcoding happens invisibly in the middle of your calls. This article compares the codecs you will actually meet, explains where compression pays for itself, and describes the failure mode that appears when nobody checked which codec each leg was using.
The Practical Short List
There are dozens of codecs in the standards, but a business voice deployment normally chooses among four. Each occupies a different point on the quality and bandwidth curve, and the right choice depends on the weakest link rather than the strongest.
| Codec | Typical bitrate | Where it fits | What it costs |
|---|---|---|---|
| G.711 (a-law / u-law) | 64 kbps | LAN, good WAN, anywhere bandwidth is plentiful | Highest bandwidth, best compatibility |
| G.722 | 64 kbps | Wideband on internal calls and supported handsets | Requires both ends and the trunk to agree |
| G.729 | 8 kbps | Constrained WAN links, satellite, remote sites | Licensing, audible artefacts, transcoding |
| Opus | 6 to 510 kbps variable | WebRTC, softphones, modern endpoints | Not universally supported by carriers or legacy handsets |
Bandwidth Is Only Half the Sum
The bitrate on the datasheet excludes packet headers. A G.711 call carried in a standard RTP stream with IP, UDP, and Ethernet overhead typically consumes closer to 80 to 90 kbps per direction once headers are counted. Compression helps, but it also adds processing: every point where the stream is decoded and re-encoded introduces delay and quality loss. A call that starts on G.729 and is transcoded to G.711 for a trunk is worse than a call that used G.711 throughout, and it consumes more CPU on the way.
- Count headers, not just payload, when planning a WAN link
- Avoid transcoding by agreeing one codec end to end wherever possible
- Check what the carrier actually accepts before standardising on a codec
- Set a clear preference order on the platform rather than relying on defaults
- Test with real background noise; compression artifacts are worst in noisy rooms
When Compression Is Worth It
Compression earns its keep on links that are genuinely constrained: a small branch on a slow circuit, a satellite backhaul, a site where voice shares capacity with something that cannot be throttled. It is rarely worth it on a LAN, and it is often counterproductive on a link that is congested for reasons unrelated to codec efficiency. If a link cannot carry voice at G.711 with proper quality of service, the honest question is whether the link is adequate at all, not whether a lower bitrate can paper over it.
The Failure Nobody Checked For
The most common codec fault is not a bad choice but an inconsistent one. A handset negotiates G.722 for an internal call, the trunk offers only G.711, and the platform silently transcodes. Everything works, so nobody investigates. Months later, capacity planning built on the assumption of one codec per call is wrong by a significant margin, and the bill for a bigger trunk or a faster link appears without a clear cause. Checking the negotiated codec on both legs, and recording the answer, prevents that surprise.
Redstone Approach
Redstone IP-PBX platforms support standard voice codecs with configurable preference lists per trunk and per endpoint group, and our design reviews include an explicit codec decision rather than a default carried forward from a template. Where a link is constrained, we plan the codec and the quality of service settings together, and we document which codec each path is expected to negotiate so that later troubleshooting starts from a known baseline.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
