oh I dont think it should ever live on the same websocket as the ARI because of that very reason. But I mean if it could do ARI websocket, inbound and outbound tcp connections thats as flexible as you'll ever get and _anyone_ could build modern applications via any means. starting development using ARI websocket and then potentially moving to inbound/outbound whenever you need to scale further using an ARI proxy for example...
I just dont want this feature to come out and then be un-usable for X number of applications. Surely Asterisk needs to be the most flexible it can be? On Wed, Jul 24, 2019 at 7:00 PM Seán C. McCord <[email protected]> wrote: > 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. > > On Wed, Jul 24, 2019 at 11:51 AM Dan Jenkins <[email protected]> wrote: > >> 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. >> >> 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. >> >> 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! >> >> On Wed, Jul 24, 2019 at 6:33 PM Seán C. McCord <[email protected]> wrote: >> >>> 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. >>> >>> The channel interface for AudioSocket really should solve the ARI use >>> case (the app interface is simpler for AMI and AGI). >>> >>> 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. >>> >>> >>> On Wed, Jul 24, 2019 at 10:03 AM George Joseph <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, Jul 24, 2019 at 7:11 AM Dan Cropp <[email protected]> wrote: >>>> >>>>> Out of curiosity, would this be an alternative to unimrcp’s asterisk >>>>> support for MRCP (TTS/ASR)? >>>>> >>>> >>>> Well it wasn't intended to implement MRCP but yes, it's intended to >>>> provide the same very-high-level functionality controlled via ARI. >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* asterisk-dev <[email protected]> *On >>>>> Behalf Of *Luca Pradovera >>>>> *Sent:* Monday, July 22, 2019 3:12 AM >>>>> *To:* Asterisk Developers Mailing List <[email protected]> >>>>> *Subject:* Re: [asterisk-dev] Audio to/from Asterisk >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> I remember this being talked about, and it's essentially tied to the >>>>> mechanism that would allow streaming ASR/TTS services to be used. >>>>> >>>>> +1 on this feature! >>>>> >>>>> >>>>> >>>>> On Mon, Jul 22, 2019 at 10:01 AM Dan Jenkins <[email protected]> wrote: >>>>> >>>>> Also coming back to this with some real-life case issues I'm currently >>>>> facing and why I can't use audiosocket :( >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> What do people think? I thought we'd talked about this mechanism at >>>>> devcon? >>>>> >>>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On Sat, Jul 20, 2019 at 2:39 PM Dan Jenkins <[email protected]> wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord <[email protected]> >>>>> wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 18, 2019 at 8:01 AM George Joseph <[email protected]> >>>>> wrote: >>>>> >>>>> Hey Guys, >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> george >>>>> >>>>> >>>>> >>>>> On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord <[email protected]> >>>>> wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jul 5, 2019, 15:28 Sylvain Boily <[email protected]> wrote: >>>>> >>>>> Hello Seán, >>>>> >>>>> On 2019-07-05 4:45 a.m., Seán C. McCord wrote: >>>>> >>>>> A brief update: >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> I'll be there. >>>>> >>>>> >>>>> >>>>> For now, you can see it in the 'channel' branch of >>>>> github.com/CyCoreSystems/audiosocket. >>>>> >>>>> >>>>> 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. >>>>> >>>>> Sylvain >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>>> >>>>> asterisk-dev mailing list >>>>> To UNSUBSCRIBE or update options visit: >>>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *George Joseph* >>>>> >>>>> Digium - A Sangoma Company | Software Developer | Software Engineering >>>>> >>>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US >>>>> >>>>> direct/fax: +1 256 428 6012 >>>>> >>>>> Check us out at: https://digium.com · https://sangoma.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Seán C. McCord >>>>> >>>>> [email protected] >>>>> >>>>> CyCore Systems >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>>> >>>>> asterisk-dev mailing list >>>>> To UNSUBSCRIBE or update options visit: >>>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>>> >>>>> asterisk-dev mailing list >>>>> To UNSUBSCRIBE or update options visit: >>>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>>> >>>>> asterisk-dev mailing list >>>>> To UNSUBSCRIBE or update options visit: >>>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>> >>>> >>>> >>>> -- >>>> *George Joseph* >>>> Digium - A Sangoma Company | Software Developer | Software Engineering >>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US >>>> direct/fax: +1 256 428 6012 >>>> Check us out at: https://digium.com · https://sangoma.com >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>> >>>> asterisk-dev mailing list >>>> To UNSUBSCRIBE or update options visit: >>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>> >>> >>> >>> -- >>> Seán C. McCord >>> [email protected] >>> CyCore Systems >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> asterisk-dev mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-dev >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > -- > Seán C. McCord > [email protected] > CyCore Systems > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
