[asterisk-dev] Audio to/from Asterisk

George Joseph gjoseph at digium.com
Thu Aug 1 07:52:17 CDT 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190801/15e61359/attachment-0001.html>


More information about the asterisk-dev mailing list