Codecs and transcoding: why calls sound the way they do

The codecs you actually meet

*The wire column is the part people forget. At the standard 20 ms packet time a stream is 50 packets per second, and each packet carries 40 bytes of IP+UDP+RTP headers before any voice — 16 kbit/s of pure overhead (more on the LAN with Ethernet framing, more again inside any tunnel). Halving ptime doubles that overhead tax; doubling ptime halves it but adds packetisation delay and makes each lost packet twice as loud. That trade — overhead versus loss-resilience versus delay — is the whole ptime decision.

What transcoding really costs

• Quality, permanently. Each lossy encode discards information; decode-and-re-encode discards more. One transcode from a healthy codec is usually tolerable; two in tandem (G.729 → G.711 → AMR across two borders) lands audibly below either codec's own ceiling. The E-model literature calls this equipment impairment, and it stacks.
• Latency. A transcode point must collect a full frame, decode, re-encode, re-packetise: one-way delay grows by tens of milliseconds per hop, and conversational quality pays for it.
• Capacity. Transcoding is the most CPU-expensive thing an SBC does — sessions-per-box figures routinely drop by an order of magnitude when transcoding is on. That is why codec policy (forcing both sides onto one codec at offer time) is always preferred to codec conversion.

The quiet victims: DTMF and fax

DTMF. Low-bitrate speech codecs are built to encode voices, and DTMF tones are not voices — G.729 mangles them badly enough that in-band digits become unreliable. The fix is RFC 4733 (née 2833): digits travel as named events on their own payload type, negotiated as telephone-event in SDP. The classic fault is a transcoding or interworking point that converts audio but forgets the event stream — or sends digits both in-band and as events, so the far IVR hears "5 5". When an IVR misbehaves, the first question is always: which of the three DTMF transports (in-band, RFC 4733, SIP INFO) did each leg think it agreed?

Fax. A fax machine's modem tones survive G.711 and nothing lossier. The choices are pass-through (force G.711, disable VAD, pray the clocks are clean) or T.38, which demodulates the fax and sends its data as its own protocol, renegotiated mid-call via re-INVITE when the tone is detected. That re-INVITE is fragile at borders — a peer that refuses it with 488 and no G.711 fallback is the anatomy of most "fax broke after the migration" tickets.

Reading codec trouble in a trace

1. Read the offer/answer honestly: what was offered, what was answered, per leg. An SBC narrowing the codec list between legs is policy at work — see whether the surviving codec is one both ends genuinely do well.
2. Confirm the RTP payload type actually matches the answered codec, both directions. Asymmetric codecs (G.711 one way, G.729 the other) are legal but a classic source of one-sided complaints.
3. Check telephone-event made it into both legs' answers when DTMF matters, and watch the PT 101 packets to see what was really sent.
4. ptime: offered vs answered vs the spacing the packets actually arrive at. Mismatched ptime forces repacketisation — cheap transcoding with the same failure modes.