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.
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. On Wed, Aug 7, 2019 at 9:00 AM George Joseph <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> >>> >>> On Mon, Jul 22, 2019 at 3:05 AM Jean Aunis <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> 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 [email protected] 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
