Voice technologyOct 1, 2026 · 5 min read

AvaritCall · Editorial team

G.711, G.722 and Opus: choosing a call audio codec

Choose between G.711, G.722 and Opus by checking end-to-end compatibility, the media path and STT input. Learn why audio sampling rates and RTP clocks require separate decisions.

G.711, G.722 and Opus: choosing a call audio codec

Short answer: establish which codec can actually run across every call leg, then evaluate wider audio bandwidth or adaptation to network conditions. G.711 can be a candidate when researching telephone interoperability, G.722 when preserving a wideband telephone path, and Opus when designing adaptable media.

Understand the codec candidates

PCMA is G.711 A-law; PCMU is μ-law. The RTP profile assigns both 8 kHz and 8 bits per sample, yielding a 64 kbit/s encoded payload. [1] G.722 codes a 7 kHz audio band within 64 kbit/s. [2] Opus adapts across audio bandwidths and bitrates. [3] These facts establish a starting point. Investigate the carrier, PBX, browser, recording system and speech recognizer together before committing to an implementation preference.

Keep sampling rate separate from the RTP clock

G.722 samples audio at 16 kHz but uses an 8 kHz RTP clock for backward compatibility. [1] Opus uses a 48 kHz RTP clock in every mode. [4] Do not turn the SDP clock value directly into the sampling rate of decoded PCM. Store the codec, timestamp clock and decoder output format separately in your media adapter. Sharing a single variable called “rate” obscures which timeline has changed during troubleshooting.

Compare codecs against the job

Starting matrix for an engineering decision
CandidateFirst questionEvidence needed
G.711 / PCMA / PCMUShared encoding at the telephone boundaryExact negotiated codec on every leg
G.722Preserving the wideband pathMedia map between telephone and PBX
OpusMedia settings for network conditionsEndpoint parameters and call samples

This matrix is not a quality ranking. In a reception workflow, intelligibility matters alongside reaching the right employee, retaining audio after hold and processing the recording. Record why a candidate was rejected: does the remote endpoint lack a common codec, does a bridge require another format, or have the intended settings not yet been verified? A documented reason lets another engineer revisit the decision without guessing what the original team assumed.

Inspect the complete media path

In a hypothetical support line, the customer telephone, carrier, company PBX and application can impose different boundaries. Mark the incoming encoding, outgoing encoding and conversion point at each boundary. Before changing the preference list, inspect what the conversation actually negotiated. An offered option is not an accepted option. Repeat this check for transfer and return from hold. Document the fallback path in language that the operations team can use when the preferred path cannot be established.

Where conversion is necessary, our design recommendation is to place it at an explicit boundary. Avoid multiplying separate transformations for recording, monitoring and STT without a reason. Writing down each branch’s requirement preserves the rationale when another provider is added.

Implementation example: a reception call

Imagine a hotel assessing G.722 for its IP telephone leg while inspecting its external telephone leg separately. The adapter records G722/8000 signaling and decoded 16 kHz PCM output in distinct fields. [1] The team then checks the greeting, a spoken room number, employee transfer and call closure using the same scenario. The purpose is to make each stage’s audio format visible, rather than declaring a codec the winner.

If listening reveals distortion, compare samples before and after the relevant conversion as well as the final recording. Changing codec priority before locating the first failing boundary can hide the cause.

Give STT its own input contract

A speech-to-text service does not necessarily accept the codec negotiated for the telephone call. The adapter should prepare audio matching the provider’s encoding, channel layout and actual sampling rate. If conversion is needed, first establish exactly what the incoming data represents. Keep codec preference independent from recognition model selection; otherwise a transcript change cannot be attributed clearly to the audio path or the model. Keep a short description of the conversion alongside the configuration.

Deployment checklist

  • Record offered and selected codecs separately for every call leg.
  • Verify decoder output, RTP clock and channel layout independently.
  • Show recording and STT conversion boundaries in the media map.
  • Listen to greetings, silence, overlapping speech, transfers and reconnection scenarios.
  • Document the decision rationale, fallback path and conditions for revisiting the choice.

Frequently asked questions

Which codec is best? There is no universal answer without the shared media path and intended task. External calls and internal conversations in the same organization can justify different choices. Define what makes a conversation acceptable, then evaluate candidates against those conditions.

Does a higher sampling label restore missing audio detail? No. Resampling alone cannot recover frequency information that was previously removed. Preserve the distinction between the source audio’s limits and the output format; changing a file label does not supply new speech information. [5]

Should STT be checked after a codec change? Yes. Recheck that the input contract remains valid and the application produces the expected representation. Establishing a call successfully does not demonstrate that every downstream processing step receives correctly described audio.

Sources
  1. [1]RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control — IETF / RFC Editor, 2003-07 (accessed: 2026-10-01)
  2. [2]ITU-T G.722 (09/2012): 7 kHz audio-coding within 64 kbit/s — ITU-T, 2012-09-13 (accessed: 2026-10-01)
  3. [3]RFC 6716: Definition of the Opus Audio Codec — IETF / RFC Editor, 2012-09 (accessed: 2026-10-01)
  4. [4]RFC 7587: RTP Payload Format for the Opus Speech and Audio Codec — IETF / RFC Editor, 2015-06 (accessed: 2026-10-01)
  5. [5]Best practices: Cloud Speech-to-Text — Google Cloud, 2026-09-30 (accessed: 2026-10-01)
Related solutions

See it on your own calls.

Set up in 5 minutes. $5 free on sign-up, pay as you go — no commitment.

Keep reading