Audio codecs on phone calls: G.711, G.722, and Opus, explained

An audio codec converts sampled sound into a bitstream that a phone network can carry and then reconstructs that bitstream as audio at the far end. G.711 represents narrowband speech with simple logarithmic companding at 64 kilobits per second, G.722 carries wideband speech at similar line rates using sub-band ADPCM, and Opus adapts its bitrate, frame size, and speech or music coding mode to the network and application. Which one a call actually uses depends on what both endpoints offer, what the network permits, and whether any intermediary transcodes the media.

A codec sits between sound and packets

A microphone produces a continuously varying electrical signal. A digital audio system measures that signal at a fixed sample rate and quantizes each measurement to a number. The resulting pulse-code modulation, or PCM, stream is easy to process but can be expensive to transport. A codec changes that representation into a defined sequence of bits, balancing four competing properties:

• Bandwidth: how many bits the media consumes per second.
• Speech bandwidth: which audible frequencies survive the round trip.
• Delay: how much audio the encoder must collect before it can emit a frame.
• Robustness and complexity: how the format behaves under packet loss and how much computation it requires.

The codec does not usually send packets itself. In an IP call, encoded frames are commonly placed in RTP packets, which add sequence numbers and timestamps. SIP or another signaling protocol negotiates the media formats, while RTP carries the media after the call is established. This separation matters: a SIP dialog can be healthy while the RTP path is one-way, delayed, or silent.

The terms sample rate, bitrate, and speech bandwidth are related but not interchangeable. An 8 kHz sample rate can represent frequencies only below 4 kHz in theory, and practical telephone filtering narrows that further. Bitrate is the number of encoded bits sent per second. Speech bandwidth is the frequency range that remains useful after capture, filtering, encoding, transport, and playback. A codec can use a high sample rate at a low bitrate, or a high bitrate for a limited frequency range.

G.711: simple, predictable narrowband audio

ITU-T G.711 is the baseline codec of traditional digital telephony. It takes 8,000 samples per second and represents each as an 8-bit companded value, producing a fixed 64-kilobit-per-second stream. The encoded speech is usually described as narrowband because the telephone channel is designed around roughly 300 Hz to 3.4 kHz, not the full frequency range of human hearing.

G.711 has two companding laws. μ-law, also written PCMU, is common in North America and Japan. A-law, or PCMA, is common in many other regions. Companding gives smaller signal amplitudes finer effective resolution than a simple uniform 8-bit quantizer. That helps quiet speech without changing the fixed one-byte-per-sample format. The two laws are not byte-compatible, so an endpoint must use the payload type negotiated for the call.

Its main engineering advantage is simplicity. G.711 requires almost no look-ahead, has a fixed bitrate, and is inexpensive to encode or decode. A system can also manipulate its samples without first running a complex decompressor. Its disadvantages are the 64-kilobit media rate and narrowband frequency response. The stream may sound clear on a clean route, but consonants that depend on higher-frequency energy are less distinct than on a wideband path.

Packetization changes the network cost without changing the codec bitrate. With 20 milliseconds of G.711 audio per RTP packet, the payload contains 160 bytes. RTP, UDP, and an IPv4 header add another 40 bytes before link-layer, tunneling, or encryption overhead. Sending shorter packets reduces packetization delay but increases the share consumed by headers and the number of packets the network must handle.

G.722: wideband speech without a higher headline bitrate

ITU-T G.722 was designed to carry more of the speech spectrum while retaining familiar telephony rates. It samples audio at 16 kHz and represents approximately 50 Hz to 7 kHz of audio. Its standard operating rates are 48, 56, and 64 kilobits per second, with 64 kilobits per second commonly used for voice calls. The result is often called wideband speech or HD voice.

G.722 reaches that result through sub-band adaptive differential pulse-code modulation. A quadrature mirror filter splits the input into lower and upper frequency bands. Each band is encoded by predicting how the next sample will differ from recent samples and then transmitting a quantized prediction error. Speech is locally correlated, so the error usually needs fewer effective bits than an independent PCM sample. Giving the lower band more precision preserves the part of speech that carries most energy while still representing the higher band.

There is an important RTP interoperability detail: the RTP clock rate for the static G.722 payload type is 8,000 Hz even though the audio is sampled at 16 kHz. RFC 3551 preserved that value for historical compatibility. Software that equates RTP timestamp rate with audio sample rate can therefore calculate durations or buffer sizes incorrectly for G.722.

Wideband audio survives only if the complete path supports it. A wideband handset calling through a narrowband trunk may negotiate G.711 or be transcoded at a gateway. Once frequencies above the narrowband cutoff have been filtered out, converting the result back to G.722 cannot restore them. HD voice is consequently an end-to-end property, not merely a codec label shown at one endpoint.

Opus: one codec with a wide operating range

Opus, standardized in RFC 6716, was built for interactive audio over packet networks. It supports sampling rates from 8 to 48 kHz, frame durations from 2.5 to 60 milliseconds, and a broad range of bitrates. It can represent narrowband speech, full-band audio, and operating points between them. Rather than being one fixed recipe, it adapts its internal mode to the signal and configuration.

Its speech-oriented path uses linear prediction: it models the vocal tract as a filter and efficiently codes the excitation needed to reproduce the signal. Its transform-oriented path represents audio energy across frequency components. Opus can use either approach or combine them in a hybrid mode. That flexibility lets it handle both speech and less speech-like sounds without requiring the application to switch payload formats midstream.

Opus also exposes controls that matter on real networks. Variable bitrate can spend more bits on difficult frames and fewer on simple ones. Constrained variable bitrate limits short-term rate swings. Discontinuous transmission can reduce media during silence. In-band forward error correction can include information about a previous frame so the decoder may reconstruct it if that earlier packet was lost, at the cost of bitrate and at least one packet of recovery delay.

These features make Opus common in WebRTC and other internet calling systems, but support at the edge does not guarantee support across a telephone route. A gateway may have to decode Opus and encode G.711 for a narrowband trunk. The call still works, but the transcoding boundary becomes part of its quality and delay budget.

Negotiation decides; preference alone does not

During SIP session setup, an offer commonly lists one or more media formats in SDP. Each codec is associated with an RTP payload type and may include parameters such as channels or mode constraints. The answer selects compatible formats. Payload type numbers in the dynamic range are local mappings, so both sides must interpret the SDP rather than assume that a number always means Opus.

The selected codec can reflect more than quality preference. A session border controller may allow only approved formats. A trunk may require G.711. A browser endpoint may prefer Opus. A recording or analytics system may accept some formats natively and transcode others. If two call legs are bridged, each leg can use a different codec, with a media server translating between them.

That translation is not free. Every lossy encode step discards information according to its own model. Repeated tandem transcoding can accumulate artifacts, especially when a low-bitrate codec is involved. Resampling adds filters and can change timing. Codec processing and buffering also add to call latency. A good media design therefore avoids unnecessary decode-and-re-encode stages and keeps audio in a lossless internal form while it is being analyzed or mixed.

Packet loss, jitter, and the decoder

A codec is only one part of perceived call quality. RTP packets may arrive late, arrive out of order, or never arrive. A receiver uses a jitter buffer to turn variable network arrival times into steady audio playback. A larger buffer tolerates more jitter but increases delay; a smaller one is more responsive but declares late packets unusable sooner.

When a packet is missing, the decoder or media stack applies packet-loss concealment. For G.711, concealment may repeat, attenuate, or extrapolate recent waveform segments. More stateful codecs can use their signal model to synthesize a plausible replacement. Concealment prevents a hard gap or click, but it does not recreate the speaker's exact missing phonemes. Bursts of packet loss are generally harder to hide than isolated losses because the predictor has less trustworthy recent audio.

Packet size changes the failure shape. If each packet holds more milliseconds, headers consume a smaller percentage of the link, but one lost packet removes a longer span of speech and packetization waits longer before sending. Short frames reduce the audio affected by one loss and can lower framing delay, while increasing packet rate. The right setting depends on network conditions, processing capacity, and the application's responsiveness requirements.

Choosing and diagnosing a call codec

For a controlled IP path, prefer the highest useful speech bandwidth that every required component supports without avoidable transcoding. For a connection to the public phone network, expect the narrowest segment to set the effective ceiling. G.711 remains a dependable interconnection format; G.722 improves intelligibility when wideband survives end to end; Opus gives packet-network applications much more freedom to trade bitrate, delay, and resilience.

When debugging, inspect each call leg rather than the caller's device alone:

1. Read the SDP offer and answer to identify the negotiated payload format and parameters.
2. Confirm which endpoint sent and received RTP, using sequence numbers and timestamps to find gaps or discontinuities.
3. Measure packet loss, late loss, reordering, and jitter separately.
4. Locate every transcode and resample boundary, including media servers and carrier gateways.
5. Compare the audio before and after each boundary when recordings or packet captures are available.

That method distinguishes codec limitations from transport failures. Metallic audio may come from repeated lossy transcoding; clipped words may be packet loss or an overaggressive speech detector; muffled but stable audio may simply be a narrowband route. The audio codec name is evidence, but not a complete diagnosis.

FAQ

Is G.722 always better than G.711?

G.722 carries a wider speech spectrum when the path remains wideband. If an intermediary converts the call to narrowband, the extra frequencies disappear, and additional transcoding can offset the benefit. End-to-end support matters more than a single endpoint's preference.

Does a higher codec bitrate always sound better?

No. Bitrate, speech bandwidth, codec design, packet loss, microphone quality, and transcoding all affect the result. G.722 can carry wider speech than G.711 at the same 64-kilobit-per-second rate because it represents the signal differently.

Can a call change codecs after it connects?

Yes. SIP endpoints can renegotiate media with a new offer and answer, although every component on the route must handle the change correctly. Some systems instead keep each call leg fixed and transcode at a bridge.

Why not use Opus for every phone call?

Many packet-native endpoints support Opus, but traditional trunks, gateways, recorders, and handsets do not all share that support. Interoperability requirements often make G.711 the common denominator at a telephone-network boundary.