<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"></head><body
bgcolor="#FFFFFF" text="#000000">
<span>Hello list,<br>
<br>
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.<br>
<br>
The objective is to send and receive audio to a <span
__postbox-detected-content="__postbox-detected-date"
class="__postbox-detected-content __postbox-detected-date"
style="display: inline; font-size: inherit; padding: 0pt;"><span
__postbox-detected-content="__postbox-detected-date"
class="__postbox-detected-content __postbox-detected-date"
style="display: inline; font-size: inherit; padding: 0pt;">3rd</span></span>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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) <br>
<br>
I thought about trying another method of allowing a <span
__postbox-detected-content="__postbox-detected-date"
class="__postbox-detected-content __postbox-detected-date"
style="display: inline; font-size: inherit; padding: 0pt;"><span
__postbox-detected-content="__postbox-detected-date"
class="__postbox-detected-content __postbox-detected-date"
style="display: inline; font-size: inherit; padding: 0pt;">3rd</span></span>
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.<br>
<br>
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.<br>
<br>
Testing is on FS <span
__postbox-detected-content="__postbox-detected-date"
class="__postbox-detected-content __postbox-detected-date"
style="display: inline; font-size: inherit; padding: 0pt; color: rgb(0,
0, 0);">1.6.15</span> on Centos 7. <br>
<br>
Any thoughts? Thanks in advance :) <br>
<br>
Dayton<br>
</span><a href="http://www.getpostbox.com"><span style="color: rgb(51,
102, 153);"></span></a><a href="http://www.getpostbox.com"><span
style="color: rgb(51, 102, 153);">
</span></a>
<div class="moz-signature">
</div>
</body>
</html>