A codec determines how call audio is compressed for transmission between CCaaS and the phone system, trading off bandwidth against voice quality. The RTP Audio Codec Preference setting on Voice Settings is a comma-separated list of codec names, entered in the order CCaaS should prefer them during call setup — this page covers how that negotiation works and what the common codecs trade off against each other.

How Codec Negotiation Works

Every SIP call begins with an offer/answer exchange (carried in the SDP portion of the SIP INVITE and its response) in which each side lists the codecs it supports, typically in order of preference. The two sides settle on the first codec that appears on both lists, and that codec is used for the call's RTP audio stream.

RTP Audio Codec Preference sets CCaaS's side of that list. Placing a higher-quality, higher-bandwidth codec first means it's used whenever the phone system also supports it, falling back to the next entry only when it doesn't.

Negotiation Flow

sequenceDiagram
    participant C as CCaaS
    participant P as Phone System

    C->>P: SDP Offer (codec preference, e.g. G.711, G.729)
    P->>C: SDP Answer (selects G.711)
    Note over C,P: Both sides now expect G.711 for this call
    C->>P: RTP audio encoded as G.711
    P->>C: RTP audio encoded as G.711
    Note over C,P: Audio decodes correctly on both ends

⚠️
No Shared Codec Causes No Audio, Not Just Poor Audio
If CCaaS and the phone system share no codec in common, the call typically fails to establish audio entirely rather than degrading gracefully. This is one of the more common causes of one-way or no-audio calls, alongside SIP ALG interference — see SIP ALG for a related cause of the same symptoms.

The Negotiated Codec Must Match the Transmitted Codec

Agreeing on a codec during the SDP offer/answer exchange isn't enough on its own — each side then has to actually encode its RTP audio using that agreed codec for the rest of the call. If the far end's phone system answers the SDP offer with one codec but transmits RTP audio encoded in a different one, CCaaS decodes the incoming audio incorrectly, since it's decoding under the assumption that the negotiated codec is what's actually arriving.

This shows up as one-way or garbled audio rather than a failed call, because the SIP handshake itself completed successfully — only the media stream is wrong. It's a fault in the far end's SDP-answer handling, not something CCaaS's own RTP Audio Codec Preference setting can correct, since that setting only governs what CCaaS itself offers and prefers on its side of the negotiation.

Mismatch Example

sequenceDiagram
    participant C as CCaaS
    participant P as Phone System

    C->>P: SDP Offer (prefers ULAW)
    P->>C: SDP Answer (agrees to ULAW)
    Note over C,P: Negotiation complete — both sides expect ULAW
    P->>C: RTP audio actually encoded as G.729
    Note over C: Decodes incoming audio as ULAW — does not match the actual G.729 payload
    Note over C,P: Result: one-way or garbled audio, even though the SIP handshake succeeded

📘
Diagnosing a Suspected Mismatch
A packet capture of the call's SDP negotiation compared against the actual RTP payload type of the media stream will confirm whether the far end is transmitting the codec it agreed to. If it isn't, the phone system or SBC on that end needs to be corrected — reordering CCaaS's own codec preference does not address a far-end negotiation bug.

Common SIP Audio Codecs

Codec	Bandwidth	Notes
G.711 (μ-law / A-law)	64 kbps payload (roughly 80–100 kbps on the wire with RTP/UDP/IP overhead)	Uncompressed, toll-quality audio and the most universally supported codec on SIP trunks and desk phones. μ-law is standard in North America and Japan; A-law elsewhere. The safest fallback for compatibility, at the cost of bandwidth.
G.722	Same 64 kbps payload as G.711	Wideband ("HD Voice") codec — samples a wider frequency range than G.711, producing noticeably clearer audio at the same bandwidth. Requires both endpoints to support it.
G.729	8 kbps payload	Heavily compressed, roughly an eighth of G.711's bandwidth, at some cost to audio quality. Useful when WAN bandwidth is constrained, at the cost of added CPU load to compress and decompress.
Opus	Adaptive, roughly 6–128 kbps	Modern, royalty-free codec that adjusts bitrate to network conditions and can match or exceed G.711 quality at a fraction of the bandwidth. Requires both endpoints to support it — not yet as universally available on desk phones and older PBXs as G.711.

Choosing a Preference Order

The right order depends on what the deployment's phone system and endpoints actually support, and how constrained the network is:

Compatibility first — Placing G.711 first (or as the only option) maximizes compatibility across desk phones, softphones, and phone systems, at the cost of bandwidth.
Bandwidth-constrained sites — G.729 is worth placing ahead of G.711 when WAN bandwidth is limited, such as a satellite link or a low-bandwidth branch connection.
Quality-sensitive use cases — G.722 or Opus, when supported by the endpoints involved, deliver noticeably clearer audio — worth prioritizing for use cases where transcription accuracy or call clarity matter most.

📘
Confirm Support Before Reordering
A codec only gets used if the phone system and the specific endpoint on the call both support it. Changing the preference order doesn't add support for a codec that either side lacks — it only changes which supported codec is chosen first.