[Freeswitch-users] Choppy and fragmented return-audio problem using Unicast

[Vallimamod Abdullah]

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 at sipsolutions.fr
.

> On 6 Oct 2017, at 21:53, Dayton Turner <dayton at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org