Livekit answers with AMR codec configuration that wasn't offered

[alexbakker]

While testing the AMR codec with Livekit, I encountered a codec configuration mismatch that caused garbled audio. Below are two excerpts from the SDPs exchanged in the SIP dialog. This was tested on Livekit Cloud on the 16th of July 2026.

Our offer:

a=rtpmap:96 AMR-WB/16000
a=fmtp:96 octet-align=1;mode-change-capability=2

Livekit's answer:

a=rtpmap:96 AMR-WB/16000

The missing a=fmtp attribute implies default codec settings, which means octet-align=0 according to RFC 4867 section 8.2. This is the mismatch. I would have expected Livekit to either echo the same AMR codec settings in the answer, or to reject the payload type outright.

Excerpt from RFC 4867 section 8.3.1:

An SDP answerer MUST include, in the SDP answer
for a payload type, the following parameters unmodified from
the SDP offer (unless it removes the payload type): "octet-
align"; "crc"; "robust-sorting"; "interleaving"; and
"channels".  The SDP offerer and answerer MUST generate AMR or
AMR-WB packets as described by these parameters.

[dennwc]

We do not support an octet aligned AMR-WB encoding yet.

For now you can force octet-align=0 on the other end, if possible.

But you are right, we should at least send back the octet-align=0, even though it's out of spec (as we will modify the original offer by doing so).