Where is the call being transcoded? How to prove it
To locate transcoding, compare the negotiated codec and observed RTP payload on each side of the device that may be converting the call. Different codecs on the two legs prove that media translation occurs at, or between, those capture points.
A single SDP offer cannot prove transcoding. It lists possibilities. The answer narrows the negotiation, and the RTP stream shows what was actually sent.
Think in call legs
phone ← leg A → PBX or SBC ← leg B → carrier
| Evidence | Leg A | Leg B |
|---|---|---|
| Offered codecs | G.722, PCMA | PCMA, PCMU |
| Answered codec | G.722 | PCMA |
| Observed RTP | G.722 | PCMA |
In that illustrative call, the middle system receives G.722 on one side and sends PCMA on the other. Media is not passing through unchanged.
Collect the four messages that matter
For a basic call, retain the offer and answer on both legs. On a back-to-back user agent such as many PBXs and SBCs, the outbound leg is a separate SIP dialog and can negotiate a different codec.
- Find the inbound INVITE and its SDP offer.
- Find the answer on that dialog.
- Find the outbound INVITE generated toward the next hop.
- Find its answer.
- Verify the RTP payload types actually used in each direction.
Match dialogs carefully. Call-IDs can differ across the middle system, so use timestamps, calling and called identities, and platform correlation identifiers where available.
Payload numbers need context
Static RTP payload types such as 0 for PCMU and 8 for PCMA are widely recognisable. Dynamic payload types must be interpreted through the a=rtpmap lines for that media description. Payload type 101 is often telephone-event, but treating it as universal without reading SDP is unsafe.
The offer/answer rules in RFC 3264 require the answer to select compatible formats from the offer. They do not require an intermediary’s two separate call legs to use the same codec.
Confirm the operational cost
Transcoding is not automatically a fault. It becomes relevant when it adds processing load, changes audio quality, breaks an unsupported format, affects DTMF handling or consumes licensed resources.
On Asterisk, core show translation displays available audio translation paths and their relative cost. Other platforms expose media-resource sessions, DSP usage or transcoder counters. Correlate those platform records with the call rather than relying on codec lists alone.
If both captured legs use the same codec, do not claim transcoding without additional platform evidence. Recording, conferencing or media anchoring may still decode audio internally, but the wire evidence has not shown a format change.
Related: voice codecs, the protocol comparison and packet captures.
Technical references
Scheduled for 22 August 2026. Examples are illustrative; read the SDP mapping for the captured call.