<div dir="ltr">Just going to chime in and say I don't see a one way audio solution as enough and I'd worry that doing that would lead to "oh but only so many people need to chuck audio in". This has been discussed at at least 3 devcons now.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord <<a href="mailto:ulexus@gmail.com">ulexus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I certainly don't mind if a better-designed system comes along and obviates my AudioSocket implementation. I built it because I needed it. However, bidirectional audio flow is critical for me (speech synthesis, external interfacing, real-time processed audio, processed injections, etc). While I would actually prefer a system which was a bit beefier than my own (simple protocol aside, there's a good deal of range between my protocol and MRCP), my meagre C skills (and patience) don't allow me to venture forth into those difficult waters.<div><br></div><div>I do like the separate connection (unlike Wazo's) and the support of TLS (unlike mine)... and yours is certainly (even without looking) more performant. Mine also probably needs a multi-threaded, dedicated-receiver approach like most of the other channels which handle socket-received media, rather than the simple non-blocking I/O with null frame insertion. No perfect solution yet.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 18, 2019 at 8:01 AM George Joseph <<a href="mailto:gjoseph@digium.com" target="_blank">gjoseph@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey Guys,<div><br></div><div>I was on vacation when this thread happened but I'm also working on this now. The implementation uses the existing ARI channel and bridge recording endpoints ands add the ability to specify a URI in the form of (udp|tcp|tls)://hostname:port to stream the media. This makes use of the existing chan_bridge_media driver and only requires a scheme handler similar to Seán's res_audiosocket. This implementation is more targeted to real-time speech recognition/transcription/captioning and is therefore one way (outbound). A future enhancement is planned that would send each channel in a bridge as a separate audio channel in a multi-channel container.</div><div><br></div><div>I'm not suggesting that this should replace Seán's audiosocket stuff but I did want to let you know what was in the pipeline.</div><div><br></div><div>george</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Solutions such as Jack are non-network oriented and severely limited in scalability. There are, of course, many other options, but the closest are chan_rtp and chan_nbs. RTP is a good option except for the difficulty for non-telephony people to interact with it. NBS is deprecated, undocumented, and unsupported by any locatable resources.<div dir="auto"><br></div><div dir="auto">While the original app interface from last year required dialplan, the channel interface does not. It is a plain channel which can be used by ARI directly.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 5, 2019, 15:28 Sylvain Boily <<a href="mailto:sylvain@wazo.io" target="_blank">sylvain@wazo.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Hello Seán,<br>
<br>
<div class="gmail-m_6655909510752751919gmail-m_1294915323101164025gmail-m_3574532234430247964gmail-m_6690327112019832243m_-7160625712045487113moz-cite-prefix">On 2019-07-05 4:45 a.m., Seán C. McCord
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">A brief update:
<div><br>
</div>
<div>I have adapted my app_audiosocket from last year to become
chan_audiosocket, a full bidirectional audio channel interface
for Asterisk to any AudioSocket service (which itself is a
dead-simple implementation). I'll be demoing it in my talk
next week at CommCon, for anyone who might be interested. I'm
going to try to have it ready to push to gerrit for review
this weekend.</div>
</div>
</blockquote>
<br>
I'll be there.<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>For now, you can see it in the 'channel' branch of <a href="http://github.com/CyCoreSystems/audiosocket" rel="noreferrer" target="_blank">github.com/CyCoreSystems/audiosocket</a>.</div>
</div>
</blockquote>
<br>
This is very different from what we did. You need dialplan to use
it. In our case we don't need any dialplan to use it, it's more ARI
approach.<br>
<br>
Sylvain<br>
</div>
</blockquote></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_6655909510752751919gmail-m_1294915323101164025gmail-m_3574532234430247964gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><b style="font-family:arial,helvetica,sans-serif;font-size:12.8px">George Joseph</b><br></div><div dir="ltr"><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Digium - A Sangoma Company | Software Developer | Software Engineering</font></div><font size="1">445 Jan Davis Drive NW - Huntsville, AL 35806 - US</font></div><div dir="ltr"><font size="1">direct/fax: +1 256 428 6012</font><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Check us out at: <a href="https://digium.com/" style="color:rgb(17,85,204)" target="_blank">https://digium.com</a> · <a href="https://sangoma.com/" style="color:rgb(17,85,204)" target="_blank">https://sangoma.com</a></font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><img width="96" height="60"></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_6655909510752751919gmail_signature">Seán C. McCord<div><a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a><br><div>CyCore Systems</div></div></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>