On Wed, Aug 7, 2019 at 7:28 AM Seán C. McCord <ule...@gmail.com> wrote:
> I would definitely prefer to have it be a "normal" channel, so that it > interoperates with everything exactly as any other channel, especially as > regarding bridges. I went back and forth a lot on this during the > AudioSocket development. There are conveniences with having things > automated/bundled, but flexibility is more important. > The thinking now is to create an "externalMedia" sub-resource under "channels" so "POST /channels/externalMedia" would give you a back a channel you could do anything you want with. > > DNS is pretty important for me, since my deployments are generally all in > an abstracted, dynamic environment (generally kubernetes), but I developed > asteriskconfig to be able to reactively handle those kinds of changes and > abstractions... so first pass no DNS? Sure. Ultimately, it's pretty > important. > Yeah OK. I'll might as well do it now then. The only downside is that you'll have to look for events or do a GET on the channel to see if/when it's connected. > > > On Wed, Aug 7, 2019 at 9:00 AM George Joseph <gjos...@digium.com> wrote: > >> Thinking more about code organization and taxonomy... It might make >> sense to make ExternalMedia a first-class object in it's own right. Rather >> than calling "POST /channels/<channel_id>/externalMedia" or "POST >> /bridges/<brdge_id>/externalMedia" to create a new external media session, >> you'd call "POST /externalMedias" and pass in the bridge or channel id you >> want to act on. This prevents having to have external media code in both >> the channels and bridges modules. >> >> Also thinking about DNS resolution. How important is it to be able to >> specify a hostname for the external server, at least in the first release? >> It complicates matters because the lookup has to be done asynchronously or >> we risk locking ARI up if the lookup response time is slow. We'd have to >> solve this later for TCP connection types anyway because the connection >> handshake could also be be slow but I'm wondering if I can defer the async >> processing for a bit. >> >> On Thu, Aug 1, 2019 at 6:52 AM George Joseph <gjos...@digium.com> wrote: >> >>> 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 >>> >>> >> >> -- >> *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 > 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 -- *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
