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