Hi, This log message can come from other modules too. Can you confirm it is from file switch_ivr.c near line 447? If so, that's definitely strange. What version of freeswitch are you using? Can you post your unicast server and esl test code in a gist? I will try it with my system. Best Regards, -- Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 10 Oct 2017, at 23:38, Dayton Turner <dayton@voxter.ca> wrote:
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,