VoIP codecs compared: Opus vs G.711 vs G.722 vs G.729

Offer Opus when both ends support it, G.722 when you want wideband audio from a phone that lacks Opus, and G.711 as the fallback that nearly every PBX and phone understands. G.729 has a fixed 8 kb/s rate, but it is narrowband, and on Asterisk it needs a separately licensed module. The bandwidth figures below are IP-level and per direction, with RTP, UDP and IPv4 headers counted, because that is what your uplink and your firewall actually carry.

The four codecs at a glance

CPU ratings are qualitative. Measure on your own hardware before you size a server.

Bandwidth per call, with overhead counted

Every RTP packet carries headers. The fixed RTP header is 12 bytes (RFC 3550, section 5.1). UDP adds 8 bytes (RFC 768), and IPv4 adds at least 20 (RFC 791). That is 40 bytes per packet over IPv4, or 60 over IPv6, whose fixed header alone is 40 bytes (RFC 8200). SRTP with its default 80-bit authentication tag adds another 10 bytes (RFC 3711).

Three formulas cover the table:

• Payload per packet (bytes) = bitrate (bit/s) × ptime (s) ÷ 8
• Packets per second = 1000 ÷ ptime (ms)
• Bandwidth per direction = (payload + 40) × packets per second × 8

Ptime is the packetization time, the amount of audio each packet carries. Here is the arithmetic for the common cases:

A few notes on the table:

• Opus is variable-bitrate by default, so its rows are averages at the target rate. Actual packets vary with the audio.
• SRTP adds 10 bytes per packet, which takes G.711 at 20 ms to 84 kb/s per direction.
• IPv6 adds 20 bytes per packet, which takes the same call to 88 kb/s.
• Layer 2 framing, such as Ethernet, VLAN tags or PPPoE on DSL, sits on top of these numbers. Measure on the link you actually have.

Here is why the upstream number matters. On a 1 Mb/s upstream DSL line, twelve G.711 calls at 20 ms need 12 × 80 = 960 kb/s before anything else is sent, so the uplink is effectively full. The same twelve calls on Opus at a 16 kb/s target need 12 × 32 = 384 kb/s, provided both ends negotiate Opus. For how the media path changes under NAT, see SIP and NAT explained.

Choosing a codec

Opus when both ends support it. RFC 7874 requires WebRTC endpoints to implement Opus and G.711, and recommends offering Opus before PCMA and PCMU when the sampling rate is above 8 kHz. Opus spans 6 to 510 kb/s, so one codec covers both tight links and high-quality calls.

G.722 for wideband audio from a phone that lacks Opus. It samples at 16 kHz with a top frequency of about 7 kHz, against about 3.4 kHz for narrowband G.711. At 64 kb/s it costs the same bandwidth as G.711 at 20 ms.

G.711 as the near-universal fallback. Nearly every PBX and phone supports µ-law (PCMU, payload type 0) or A-law (PCMA, payload type 8), and RFC 3551 defines both as static payload types. The common regional default is µ-law in North America and Japan and A-law in most other countries. Public reporting says the G.711 patents have expired.

G.729 only when bandwidth is the binding constraint. Pick it when you accept narrowband audio and the license arrangement works for your PBX. Darwvin Softphone, configured as in the setup guide, offers Opus, G.722 and G.711, and does not offer G.729.

Packet loss, ptime and delay

Each lost packet removes ptime worth of audio. At 20 ms, one lost packet leaves a 20 ms gap until concealment fills it, and the quality of that fill depends on the decoder.

Opus includes loss handling in the codec itself. RFC 6716 says packet loss concealment is an optional decoder feature that "SHOULD be included when receiving from an unreliable channel" (section 4.4). Its in-band forward error correction (section 2.1.7) re-encodes perceptually important frames at a lower bitrate and adds them to a later packet. The receiver can use that only when the fmtp line signals useinbandfec=1 (RFC 7587). On Asterisk, the Codec Opus page lists fec as a tuning option, and it is off by default.

Ptime is a trade-off. A 10 ms ptime limits the audio lost per packet, but it doubles the packet count compared with 20 ms and raises the overhead shown in the table. A 30 ms ptime cuts overhead, but each lost packet takes more audio with it and the delay grows. RFC 3551 lists 20 ms as the default packet duration for PCMU, PCMA, G722 and G729, which is a sensible starting point.

Delay differs by codec. Opus has an algorithmic delay between 5 ms and 65.2 ms depending on mode (RFC 6716, section 2). G.729 uses 10 ms frames with a 5 ms look-ahead, about 15 ms before network effects. G.711 works sample by sample and adds almost no algorithmic delay.

Transcoding and codec mismatch

Transcoding means decoding a stream and encoding it again in another codec. Each pass adds delay and CPU load, and it costs some quality. Two things to plan for:

• Transcoding keeps the PBX in the media path for that call, so direct media does not apply. Size the PBX for those calls, not only for pass-through calls.
• A mismatch with no common codec fails the call. The Asterisk PJSIP troubleshooting guide puts it plainly: the codec sets used by each endpoint during a call must have a non-empty intersection. A failed negotiation can surface as 488 Not Acceptable Here (RFC 3261, section 21.4.26). The SIP response codes guide covers the others.

Two more gotchas. First, do not change G.722's RTP clock to 16000. RFC 3551 keeps it at 8000 Hz for backward compatibility, even though the sampling rate is 16 kHz, so an rtpmap line that says G722/16000 is a configuration bug to fix at the source. Second, a ptime mismatch does not break calls on its own, but it changes the bandwidth you planned for. When the audio symptoms look like a codec problem, the one-way audio guide lists the checks in order.

Setting codec order in Asterisk

In PJSIP, the endpoint's allow lines define its codecs, and their order is the local preference. Start with disallow=all to clear the default list, as the Asterisk NAT guide does, then add codecs in the order you want:

[1001]
; the aor and auth sections are also required and are not shown
type=endpoint
context=internal
disallow=all
allow=opus
allow=g722
allow=ulaw
allow=alaw
transport=transport-udp
aors=1001
auth=1001

The res_pjsip reference describes incoming_call_offer_pref, which defaults to local. That setting keeps your local order when Asterisk chooses from a remote offer. Two checks before you rely on the order:

• Opus only works if your Asterisk build includes the Opus codec. Confirm that before you add opus to an allow line. The Codec Opus page covers tuning in codecs.conf.
• To see what was negotiated, enable the PJSIP logger with pjsip set logger on and read the SDP answer in the trace. The official troubleshooting guide uses the same logger for call problems.

For the full PJSIP setup around these lines, see the FreePBX and Asterisk guide. Then choose the order by scenario:

FAQ

Is Opus always better than G.711?

No. Opus can carry wideband or fullband audio at much lower bitrates than G.711 uses, but only where both endpoints negotiate it. If the PBX has to transcode it to G.711 for another leg, you pay for two conversions and lose much of the bitrate advantage.

Is G.729 free to use?

Most of its patents expired on 1 January 2017, and the licensors offered the rest royalty-free from that date, according to the SIPRO Lab update as relayed in a 2017 blog post. Asterisk's G.729 support is a separate module that Sangoma licenses per channel, and registering the key requires the server to reach the internet. Check current terms before you deploy. This is not legal advice.

Why does G.722 use an 8000 Hz RTP clock?

RFC 3551 requires it. G.722 samples at 16 kHz, but its RTP clock stays at 8000 Hz because RFC 1890 assigned that value and it must remain for backward compatibility.

What payload types do µ-law and A-law use?

They are the static payload types 0 (PCMU) and 8 (PCMA), both at an 8000 Hz clock (RFC 3551). G.722 is 9 and G.729 is 18. Opus has no static type, so the offer assigns it a dynamic number between 96 and 127, and the rtpmap line names it (RFC 7587).

What ptime should I use?

Start with 20 ms. RFC 3551 lists it as the default packet duration for these payloads, and it balances overhead against delay and loss. Change it only when the bandwidth table or a loss test says to.

References

• RFC 3551, RTP audio and video profile: https://www.rfc-editor.org/rfc/rfc3551
• RFC 3550, RTP: https://www.rfc-editor.org/rfc/rfc3550
• RFC 768, User Datagram Protocol: https://www.rfc-editor.org/rfc/rfc768
• RFC 791, Internet Protocol: https://www.rfc-editor.org/rfc/rfc791
• RFC 8200, IPv6 specification: https://www.rfc-editor.org/rfc/rfc8200
• RFC 3711, Secure RTP: https://www.rfc-editor.org/rfc/rfc3711
• RFC 6716, Opus audio codec: https://www.rfc-editor.org/rfc/rfc6716
• RFC 7587, RTP payload format for Opus: https://www.rfc-editor.org/rfc/rfc7587
• RFC 7874, WebRTC audio codec requirements: https://www.rfc-editor.org/rfc/rfc7874
• RFC 3261, SIP (section 21.4.26, 488 response): https://www.rfc-editor.org/rfc/rfc3261
• ITU-T G.711, pulse code modulation of voice frequencies: https://www.itu.int/rec/T-REC-G.711
• ITU-T G.722, 7 kHz audio coding within 64 kbit/s: https://www.itu.int/rec/T-REC-G.722
• ITU-T G.729, coding of speech at 8 kbit/s with CS-ACELP: https://www.itu.int/rec/T-REC-G.729
• Opus, license terms: https://opus-codec.org/license/
• Asterisk, Codec Opus: https://docs.asterisk.org/Configuration/Codec-Opus
• Asterisk, res_pjsip reference: https://docs.asterisk.org/Latest_API/API_Documentation/Module_Configuration/res_pjsip/
• Asterisk, PJSIP troubleshooting guide: https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Asterisk-PJSIP-Troubleshooting-Guide/
• Sangoma knowledge base, G.729 license registration: https://sangomakb.atlassian.net/wiki/spaces/OpenSource/pages/428441777/Open+Source+-+How+do+I+register+a+G729+license
• SIPRO Lab G.729 update, relayed in a 2017 blog post: https://www.mgraves.org/2017/03/its-official-the-patents-on-g-729-have-expired/