[asterisk-dev] Audio to/from Asterisk

Wed Jul 24 11:06:07 CDT 2019

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 <ulexus at gmail.com> 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 <dan at nimblea.pe> 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 <ulexus at gmail.com> 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 <gjoseph at digium.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 24, 2019 at 7:11 AM Dan Cropp <dan at amtelco.com> 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 <asterisk-dev-bounces at lists.digium.com> *On
>>>>> Behalf Of *Luca Pradovera
>>>>> *Sent:* Monday, July 22, 2019 3:12 AM
>>>>> *To:* Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>>>>> *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 <dan at nimblea.pe> 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 <dan at nimblea.pe> 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 <ulexus at gmail.com>
>>>>> 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 <gjoseph at digium.com>
>>>>> 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 <ulexus at gmail.com>
>>>>> 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 <sylvain at wazo.io> 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
>>>>>
>>>>> ulexus at gmail.com
>>>>>
>>>>> 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
>>> ulexus at gmail.com
>>> 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
> ulexus at gmail.com
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190724/0b120c7f/attachment-0001.html>