Hello, again huge thanks for adding support for AMR-WB codec in livekit sip.
I've spent some time to make it working with other services supporting AMR-WB codec as e.g. Asterisk or Kamailio, and after the issue was fixed, I was no longer getting invalid frames log messages, but the received audio was like "playing random bytes" audio.
After my investigation I found out that there is RFC 4867 for the AMR-WB codec implementation describing 2 formats:
- Storage format - used for files or email attachments
- RTP Payload formats - used for phone calls
- Bandwidth-Efficient Mode - marked as octet-align=0 in SDP (if the octet-align param is missing, this is the default mode)
- Octet-Aligned Mode - marked as octet-align=1 in SDP
As for voice calls the RTP Payload formats are used, there is no support for the AMR-WB codec storage format.
I'm not a sip/codec expert, and correct me if I'm wrong but it seems that the AMR-WB codec is implemented in the storage format.
At least when I used Claude to write for me an Encoder/Decoder from Storage to RTP format - I tried both Bandwidth-Efficient and Octet-Aligned modes, it started working and the audio was as expected.
I don't know if the storage format is expected here, and how it was tested, but this seems to be a bug for me.
If needed I can share the Claude generated Encoders/Decoders, or help with the implementations of the RTP formats.
Hello, again huge thanks for adding support for AMR-WB codec in livekit sip.
I've spent some time to make it working with other services supporting AMR-WB codec as e.g. Asterisk or Kamailio, and after the issue was fixed, I was no longer getting invalid frames log messages, but the received audio was like "playing random bytes" audio.
After my investigation I found out that there is RFC 4867 for the AMR-WB codec implementation describing 2 formats:
As for voice calls the RTP Payload formats are used, there is no support for the AMR-WB codec storage format.
I'm not a sip/codec expert, and correct me if I'm wrong but it seems that the AMR-WB codec is implemented in the storage format.
At least when I used Claude to write for me an Encoder/Decoder from Storage to RTP format - I tried both Bandwidth-Efficient and Octet-Aligned modes, it started working and the audio was as expected.
I don't know if the storage format is expected here, and how it was tested, but this seems to be a bug for me.
If needed I can share the Claude generated Encoders/Decoders, or help with the implementations of the RTP formats.