Hi! I thought that first as well - however we *are* specifying the native flag, and the received audio is definitely PCMU. When I capture it bit-for-bit, and import it into audacity, selecting 8khz mono u-Law makes the audio play back perfectly. I DO see the "Raw Codec Activation Success L16@" in the logs, despite the received audio stream being PCMU, and despite specifying the native flag. We've also attempted streaming L16 back instead of PCMU and its completely incomprehensible static. Whereas now, you can hear it properly, its just stuttered like mad. So, because of this I believe the codec is correct. Dayton Vallimamod Abdullah wrote:
Hi,
I think you are getting a codec mismatch. Here is how the unicast command works according to the source code: - If native flag is not set, fs will use the L16 codec to exchange media beetween the session and the unicast socket. You can search for "Raw Codec Activation Success L16@" in the debug log to confirm it. - If the native flag is set, fs will use the same read and write codec as your current session: the rtp buffer is sent as-is to the unicast socket and the data received from the unicast socket is also sent back as-is to the session.
Hope this helps!
Best Regards,