Picking SIP codecs — G.711 vs G.722 vs Opus, bandwidth math, codec negotiation gotchas
"Which codec should I use?" is one of those VoIP questions where the wrong answer doesn't break the call — it just makes it sound a little worse, or costs you more bandwidth, or fails quietly on one carrier path. This article explains the four codecs that matter, the math behind their bandwidth, and how to set up codec negotiation that doesn't surprise you.
The four codecs worth knowing
G.711 (ulaw / alaw)
- Bitrate: 64 kbps.
- Quality: standard PSTN — 300 Hz–3.4 kHz narrowband. Sounds like a phone call.
- Compatibility: universal. Every SIP endpoint, every carrier, no licence required.
- When to use it: default for everything unless you have a specific reason to pick something else. ulaw in North America, alaw in Europe and elsewhere.
G.722
- Bitrate: 64 kbps.
- Quality: wideband (50 Hz–7 kHz). Noticeably clearer than G.711 — voices have body to them.
- Compatibility: most modern SIP phones and PBXes. Cisco, Polycom, Yealink all support it. Most SIP carriers support it on direct interconnects but not on PSTN-terminating calls (the PSTN narrowband limit).
- When to use it: internal extension-to- extension calls within the same PBX, or PBX-to-PBX trunks between offices on the same carrier. The bandwidth is the same as G.711 so there's no penalty.
Opus
- Bitrate: variable, typically 16–64 kbps for voice.
- Quality: wideband and beyond. Designed for everything from voice to music; in VoIP usage it rivals or beats G.722.
- Compatibility: WebRTC mandates it; SIP adoption is patchy. Asterisk 16+ supports it but doesn't ship as default in some distros. Some carriers support it on direct trunks.
- When to use it: WebRTC softphones, modern soft-clients, internal PBX-to-PBX where both ends explicitly support it.
G.729
- Bitrate: 8 kbps.
- Quality: noticeably worse than G.711 — slightly tinny, especially on quiet voices.
- Compatibility: widely supported but patent-encumbered (the original patents have expired, but a passthrough licence is still wise on commercial PBXes). Asterisk needs a separate codec module to use it.
- When to use it: when bandwidth is genuinely tight (rural broadband, mobile uplinks). Less common than it used to be — broadband is wide enough now that G.711 fits.
Bandwidth math
Raw codec bitrate is only part of the story. Each RTP packet has IP+UDP+RTP header overhead — 40 bytes per packet. At the default 20 ms packetisation, that's 50 packets per second per direction, so 2,000 bytes/s = 16 kbps of pure overhead per direction.
| Codec | Payload kbps | With overhead (per direction) | Total per call (both directions) |
|---|---|---|---|
| G.711 (20 ms) | 64 | 80 | ~160 kbps |
| G.722 (20 ms) | 64 | 80 | ~160 kbps |
| Opus (20 ms, voice) | 32 | 48 | ~96 kbps |
| G.729 (20 ms) | 8 | 24 | ~48 kbps |
So a 10-line office on G.711 needs about 1.6 Mbps of sustained bandwidth dedicated to voice. Doable on any modern broadband but worth checking on shared circuits.
Negotiation — how SIP picks a codec
When a SIP call sets up, the offer/answer SDP exchange lists codecs in preference order. The answerer picks one from the intersection of "what was offered" and "what I support":
- If both sides offer G.711 + G.722, and the answerer prefers G.722, you get G.722.
- If one side only offers G.711, you get G.711 regardless of the other side's preferences.
- If no shared codec exists, the call fails with 488 Not Acceptable Here.
The trap: a "preferred codec" set differently on each leg of a call (phone → PBX, PBX → trunk, trunk → carrier) can cause mid-call transcoding, which adds latency and CPU on the PBX. Symptom: calls work but sound slightly delayed.
FreePBX codec settings
Three places to set codecs, in priority order:
- Extension codecs (per extension) — the codecs the PBX advertises to the phone.
- Trunk codecs (per trunk) — the codecs the PBX advertises to the carrier.
- Global SIP codec preferences in Settings → Asterisk SIP Settings — the default for both above.
The recommendation:
- Set ulaw as the first preference globally. This is the "won't be wrong" choice.
- Add G.722 as second preference globally. Wideband when both ends support it, fallback to ulaw when they don't.
- On trunks specifically: only list codecs the carrier confirms they support. Don't list G.722 on a trunk that only takes G.711 — you'll get codec negotiation misbehaviour.
- Add Opus on extensions that use WebRTC softphones.
Verifying what was negotiated
asterisk -rvvv
pjsip set logger on
<make a test call>
<watch the 200 OK response>
The SDP body of the 200 OK shows m=audio <port> RTP/AVP <codec-list>. The first codec listed is the one in use for the call.
Common mistakes
- Listing every codec on every trunk. "More is better" backfires — increases negotiation failure modes and risks transcoding. List only what the carrier supports.
- G.729 without the codec module. If Asterisk doesn't have the G.729 module loaded, calls that negotiate to G.729 fail silently.
- Wideband codec on a PSTN call. PSTN terminations are always narrowband. Picking G.722 on a PSTN-terminating trunk just means the carrier transcodes — pointless work.
Also Read
Powered by WHMCompleteSolution