<div dir="ltr">This sounds like a case where Wazo's solution (though it presently is only single-direction) might be the best for you, since it piggy-backs the audio data on the same websocket as ARI. For me, that's worse than useless, since I multiplex the ARI amongst a wide range of processing nodes, but if you want to minimize additional routing and orchestration, you can't beat just simply using the same websocket that your control channel is on. That's about as coupled as it gets.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 11:51 AM Dan Jenkins <<a href="mailto:dan@nimblea.pe">dan@nimblea.pe</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">So even in its most basic form - lets take a Node process thats made a websocket connection to Asterisk for ARI purposes... within the event loop for that ARI session, I cant easily handle the audio going out to asterisk within the same "thread" (I use that term loosely) because when the connection comes into Node (say im listening as a audio providing server on port X ready),,, those two things within the same node process are within two separate events within the same process - as soon as you start sharing state outside of that ARI "thread" thats dealing with that one session we get into dangerous territory. I'd much rather have a websocket out to Asterisk, have an event come in via websocket to say heres a new session and we create an ARI "thread" within that process. When I need to make a session with bidirectional audio in/out of asterisk to my process I should be able to ask the ARI for where to connect to in order to send/receive that media, make that connection with a uuid and then instruct ARI to bridge the original channel and the new one.<div><br></div><div>Simple ARI apps shouldnt need messaging between apps to handle instructions and media. The same process and event loop should be able to handle both.</div><div><br></div><div>Theres a lot of personal preference in all of that I do grant you. But I do believe that I shouldnt have to make specific node processes available to external resources but asterisk already is (to a degree). I see both sides of the coin - im basically saying i want to build it this way and youre saying, but i dont want to have asterisk open to external applications.... so who wins? In an ideal world you should be able to do both because Asterisk needs to be a flexible media engine!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 6:33 PM 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="ltr">AudioSocket was initially designed precisely to be able to slot into the role of MRCP, for a client who was more interested in designing their own system (and paying for its development) than paying the license fees for UniMRCP. George's solution should also fit that need. I have since used AudioSocket for a number of other operations, but that was its original impetus.<div><br></div><div>The channel interface for AudioSocket really should solve the ARI use case (the app interface is simpler for AMI and AGI).</div><div><br></div><div>As to the port-in rather than port-out mechanism... I'm sure there are definitely use cases for it, but in any sufficiently large system, you're going to have to do routing one way or the other: to Asterisk or from Asterisk. Ultimately, you are going to have multiple instances of all components, so the directionality of the socket connection doesn't seem to me to be a large factor. That is to say, adding an inbound port to Asterisk to initiate the two-way socket doesn't seem to be particularly more useful than outgoing. Am I missing something, Dan, about your scenarios? I didn't really design AudioSocket with inbound connections in mind at all.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 10:03 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"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 7:11 AM Dan Cropp <<a href="mailto:dan@amtelco.com" target="_blank">dan@amtelco.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 lang="EN-US">
<div class="gmail-m_-972583730946904001gmail-m_3733698259648159784gmail-m_480895493207640548gmail-m_-4850763118205997367WordSection1">
<p class="MsoNormal">Out of curiosity, would this be an alternative to unimrcp’s asterisk support for MRCP (TTS/ASR)?</p></div></div></blockquote><div><br></div><div>Well it wasn't intended to implement MRCP but yes, it's intended to provide the same very-high-level functionality controlled via ARI.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-972583730946904001gmail-m_3733698259648159784gmail-m_480895493207640548gmail-m_-4850763118205997367WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> asterisk-dev <<a href="mailto:asterisk-dev-bounces@lists.digium.com" target="_blank">asterisk-dev-bounces@lists.digium.com</a>>
<b>On Behalf Of </b>Luca Pradovera<br>
<b>Sent:</b> Monday, July 22, 2019 3:12 AM<br>
<b>To:</b> Asterisk Developers Mailing List <<a href="mailto:asterisk-dev@lists.digium.com" target="_blank">asterisk-dev@lists.digium.com</a>><br>
<b>Subject:</b> Re: [asterisk-dev] Audio to/from Asterisk<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal">I remember this being talked about, and it's essentially tied to the mechanism that would allow streaming ASR/TTS services to be used.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">+1 on this feature!<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jul 22, 2019 at 10:01 AM Dan Jenkins <<a href="mailto:dan@nimblea.pe" target="_blank">dan@nimblea.pe</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Also coming back to this with some real-life case issues I'm currently facing and why I can't use audiosocket :(<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I need to be able to ask the ARI/AGI/AMI for an IP/port combo and for an external app to then connect into asterisk rather than asterisk connecting to a URI elsewhere. Lets say I already have a nodejs (or any other language) process taking
care of controlling that call via ARI or even AGI (all the different ways) - I need that same process to handle the media I'm sending and receiving to/from asterisk and so if I already have that process up and then Asterisk calls out to a generic URI then
that media will never make it back to the original nodejs process.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think its of upmost importance that I be able to ask asterisk for a host:port pair and then be able to connect to that port from my external application.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What do people think? I thought we'd talked about this mechanism at devcon?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Dan<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Sat, Jul 20, 2019 at 2:39 PM Dan Jenkins <<a href="mailto:dan@nimblea.pe" target="_blank">dan@nimblea.pe</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jul 18, 2019 at 8:01 AM George Joseph <<a href="mailto:gjoseph@digium.com" target="_blank">gjoseph@digium.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hey Guys,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">george<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Jul 5, 2019, 15:28 Sylvain Boily <<a href="mailto:sylvain@wazo.io" target="_blank">sylvain@wazo.io</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Hello Seán,<u></u><u></u></p>
<div>
<p class="MsoNormal">On 2019-07-05 4:45 a.m., Seán C. McCord wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">A brief update: <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
I'll be there.<br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For now, you can see it in the 'channel' branch of <a href="http://github.com/CyCoreSystems/audiosocket" target="_blank">
github.com/CyCoreSystems/audiosocket</a>.<u></u><u></u></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><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<u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal">-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" 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" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:Arial,sans-serif">George Joseph</span></b><span style="font-size:9.5pt"><u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:Arial,sans-serif">Digium - A Sangoma Company | Software Developer | Software Engineering</span><span style="font-size:9.5pt"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:7.5pt">445 Jan Davis Drive NW - Huntsville, AL 35806 - US</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt">direct/fax: +1 256 428 6012</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:Arial,sans-serif">Check us out at: <a href="https://digium.com/" target="_blank"><span style="color:rgb(17,85,204)">https://digium.com</span></a> · <a href="https://sangoma.com/" target="_blank"><span style="color:rgb(17,85,204)">https://sangoma.com</span></a></span><span style="font-size:9.5pt"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">Seán C. McCord<u></u><u></u></p>
<div>
<p class="MsoNormal"><a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a><u></u><u></u></p>
<div>
<p class="MsoNormal">CyCore Systems<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" 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" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal">-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" 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" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><u></u><u></u></p>
</blockquote>
</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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-972583730946904001gmail-m_3733698259648159784gmail-m_480895493207640548gmail_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></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_-972583730946904001gmail-m_3733698259648159784gmail_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>
-- <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_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>