[asterisk-dev] Audio to/from Asterisk
Seán C. McCord
ulexus at gmail.com
Wed Aug 7 10:18:01 CDT 2019
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 <gjoseph at digium.com> wrote:
>
>
> On Wed, Aug 7, 2019 at 7:28 AM Seán C. McCord <ulexus at 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 <gjoseph at 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 <gjoseph at 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 <gjoseph at digium.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 22, 2019 at 3:05 AM Jean Aunis <jean.aunis at 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 <dan at 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 <ulexus at 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 <gjoseph at 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 <ulexus at 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 <sylvain at 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
>>>>>>>> ulexus at 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
>> ulexus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190807/527d53b5/attachment-0001.html>
More information about the asterisk-dev
mailing list