So here's where we're at with adding this capability... Initial release:
- Two new ARI endpoints, one on channel and one on bridge: - /channels/<channel_id>/externalMedia - /bridges/<bridge_id>/externalMedia - You can specify: - host: <address>:<port> - encapsulation: rtp (with others added later) - transport: udp (with tcp, ws, tls, http, etc added later) - connection_type: client (with server added later) - format: <any asterisk supported codec/format> - direction: both (with in, out supported later) - mixed: true (at some later date, we may allow each channel in a bridge or each direction on a channel to be placed in a separate audio channel) We'll use chan_rtp (rtp, udp, client) as the initial underlying provider but we'll create a mechanism to easily add other providers. Also in the initial release, calling externalMedia on a channel that's already in a bridge will fail. In this case, you should call externalMedia on the bridge. We'll revisit this after we get some real-world feedback. We may be able to use the snoop functionality to isolate a single channel in a bridge for instance. For later releases: What are your priorities for payload encapsulation and transport? On Mon, Jul 29, 2019 at 9:43 AM George Joseph <gjos...@digium.com> wrote: > > > 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 > > -- *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