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

[Dayton Turner]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171006/b2d3effc/attachment.html>