[asterisk-dev] Audio to/from Asterisk
Seán C. McCord
ulexus at gmail.com
Wed Aug 7 08:27:27 CDT 2019
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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190807/f47cd418/attachment-0001.html>
More information about the asterisk-dev
mailing list