[asterisk-dev] Audio to/from Asterisk
George Joseph
gjoseph at digium.com
Wed Aug 7 09:03:45 CDT 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190807/ea5e31d5/attachment-0001.html>
More information about the asterisk-dev
mailing list