[asterisk-dev] Audio to/from Asterisk
Jean Aunis
jean.aunis at prescom.fr
Mon Jul 22 03:08:42 CDT 2019
It may not be suitable for your use case, but you could instantiate a
UnicastRTP channel. It will allocate an RTP port and store it into a
channel variable.
Jean
Le 22/07/2019 à 10:01, Dan Jenkins a écrit :
> 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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <http://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://digium.com/> · https://sangoma.com
> <https://sangoma.com/>
>
>
>
> --
> Seán C. McCord
> ulexus at gmail.com <mailto: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/20190722/e96bd6d0/attachment-0001.html>
More information about the asterisk-dev
mailing list