Choppy and fragmented return-audio problem using Unicast
Hello list, I've got a question about using the unicast call command via ESL. I realize there are other ways to do this, such as writing a native C module, but with a lack of developers with the necessary C skills, we're trying to take a "simpler to implement" approach at first just to get things rolling. The objective is to send and receive audio to a 3rd party application. In this case, we're using a UDP transport via unicast, running a small application written in golang on the FS server itself. As a proof of concept, we're simply capturing received RTP on the UDP socket, and piping it back to the UDP port FS is listening on - basically an echo test. Audio does come in, we are able to send audio back, but the return audio as we hear it sounds incredibly choppy, and like some of the audio frames are being clipped or dropped entirely. We also tested merely saving the received audio to a file and wrote it to disk. Loading it up in audacity and importing raw audio, it plays back properly when we import it as ULAW 8khz mono. Additionally, we also tried skipping the echo test and instead simply opening the saved file and bitstreaming it back to FS on the listening unicast UDP port. Despite playing back properly in audacity, its all choppy and cut up when played back via the UDP stream. Nothing fancy going on, literally just opening the file and bitstreaming it to the UDP socket. We also tried a couple example 8khz ulaw files, just streaming those back and they behave similarly. In fact, they sound sped up (in playback "speed", but not pitch, which is interesting). Am I missing something about what format the UDP unicast listening port in FS expects to receive, differently than what it sent out in the first place? As we receive 8khz ulaw, we're sending that back in return. flags:native is specified on the ESL call-command. We also tried transcoding to L16 before sending it back, no luck there either (completely unintelligible stream of fuzz) I thought about trying another method of allowing a 3rd party application to access the audio stream (both receive and send back) like mod_tts_commandline but it wasnt clear wether this route permits for audio in both directions to be involved or if it was merely return audio. Additionally, via ESL if we execute the playback application and just ask FS to play one of its own soundfiles, it sounds perfectly fine, so Im confident that the setup up until the unicast test is working correctly. Testing is on FS 1.6.15 on Centos 7. Any thoughts? Thanks in advance :) Dayton <http://www.getpostbox.com><http://www.getpostbox.com>
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, -- Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 6 Oct 2017, at 21:53, Dayton Turner <dayton@voxter.ca> wrote:
Hello list,
I've got a question about using the unicast call command via ESL. I realize there are other ways to do this, such as writing a native C module, but with a lack of developers with the necessary C skills, we're trying to take a "simpler to implement" approach at first just to get things rolling.
The objective is to send and receive audio to a 3rd party application. In this case, we're using a UDP transport via unicast, running a small application written in golang on the FS server itself. As a proof of concept, we're simply capturing received RTP on the UDP socket, and piping it back to the UDP port FS is listening on - basically an echo test.
Audio does come in, we are able to send audio back, but the return audio as we hear it sounds incredibly choppy, and like some of the audio frames are being clipped or dropped entirely. We also tested merely saving the received audio to a file and wrote it to disk. Loading it up in audacity and importing raw audio, it plays back properly when we import it as ULAW 8khz mono. Additionally, we also tried skipping the echo test and instead simply opening the saved file and bitstreaming it back to FS on the listening unicast UDP port. Despite playing back properly in audacity, its all choppy and cut up when played back via the UDP stream. Nothing fancy going on, literally just opening the file and bitstreaming it to the UDP socket.
We also tried a couple example 8khz ulaw files, just streaming those back and they behave similarly. In fact, they sound sped up (in playback "speed", but not pitch, which is interesting).
Am I missing something about what format the UDP unicast listening port in FS expects to receive, differently than what it sent out in the first place? As we receive 8khz ulaw, we're sending that back in return. flags:native is specified on the ESL call-command. We also tried transcoding to L16 before sending it back, no luck there either (completely unintelligible stream of fuzz)
I thought about trying another method of allowing a 3rd party application to access the audio stream (both receive and send back) like mod_tts_commandline but it wasnt clear wether this route permits for audio in both directions to be involved or if it was merely return audio.
Additionally, via ESL if we execute the playback application and just ask FS to play one of its own soundfiles, it sounds perfectly fine, so Im confident that the setup up until the unicast test is working correctly.
Testing is on FS 1.6.15 on Centos 7.
Any thoughts? Thanks in advance :)
Dayton
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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,
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,
participants (2)
-
Dayton Turner
-
Vallimamod Abdullah