I don't think checking channel events is too onerous, considering that IP-based connections would be able to fail, too.
As far as the ARI API: I don't really care that much, but is there a reason to not simply use the existing channel tech/target syntax (e.g. ExternalMedia/media.host.example.com:6645)? On Wed, Aug 7, 2019, 10:04 George Joseph <[email protected]> wrote: > > > On Wed, Aug 7, 2019 at 7:28 AM Seán C. McCord <[email protected]> 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 <[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 > > > > -- > *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
-- _____________________________________________________________________ -- 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
