On Mon, Jul 22, 2019 at 3:05 AM Jean Aunis <jean.au...@prescom.fr> wrote:
> 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 > I missed this last week, sorry Jean! So yeah, what's wrong with using chan_rtp? Basically it sets up a two-way rtp instance with an arbitrary destination. You can dial the destination as "UnicastRTP/<ip_address>:<port>/c(ulaw)" either from the dialplan, or you can create a channel using ARI and add it to an existing bridge. It doesn't solve Dan's need for connecting to asterisk instead of the other way around but I think we can make that work. > 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 <d...@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 <ule...@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 <gjos...@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 <ule...@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 <sylv...@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 >>> ule...@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 -- *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