Environment:
Self-hosted livekit/sip v1.14.0 (media-sdk c8704a7, Aug 2026), livekit-server 1.13.x, inbound PSTN trunk from an Australian carrier (using PortaSIP).
What happens:
Our carrier’s INVITE offers PCMA/8000 first and PCMU/8000 second — the standard preference on A-law networks (Australia, Europe, most of the world outside North America/Japan). The bridge answers PCMU on
every call.
Locking the trunk to only_listed_codecs: true with codecs: [PCMA] works, but that’s exclusion, not preference: if a caller path ever arrives without PCMA we get a 400 “common audio codec not found” instead of a working call.
Why (from source):
media-sdk/sdp/offer.go SelectAudio() picks the codec with the highest internal Priority from the enabled set, iterating the offer but never using its order (the order-respecting break only runs when answer ==
true, i.e. when parsing the far end’s answer):
for _, c := range desc.Codecs {
if audioCodec == nil || codec.Info().Priority > priority {
audioCodec = codec
priority = codec.Info().Priority
}
if answer { break }
}
The priorities are hardcoded per codec: g722 −5, g711/ulaw −10, g711/alaw −20. So the ranking is always G722 > PCMU > PCMA regardless of what the offerer prefers, and regardless of the order given in a trunk’s SIPMediaConfig.codecs list — sip/pkg/sip/media_codecs.go codecSet() folds that list into an on/off CodecSet and discards the order.
Impact:
On A-law networks every PCMA+PCMU offer is answered with the carrier’s second choice, which typically inserts a transcode somewhere in the carrier path (A-law → µ-law) on every call. We are currently chasing
an intermittent one-way-audio issue where our carrier’s engineer has flagged exactly this transcode as the likely culprit. Even if it turns out not to be the cause, forcing a transcode that the offerer
explicitly tried to avoid is the wrong default.
Ask- Either (or both) of:
- Honour the offerer’s order when parsing an inbound offer (RFC 3264 §6.1 says the answerer should use the offerer’s preference order), falling back to internal priority only for ties or when the offer has
no order. - Make the trunk codecs list ordered — treat the order in SIPMediaConfig.codecs as the priority for that trunk, so operators can say “PCMA, then PCMU” without having to exclude PCMU entirely.
Option 2 alone would already fix our case and is fully backwards-compatible (existing single-codec locks behave identically).
Happy to test a build against a real A-law carrier.
