[asterisk-dev] Audio to/from Asterisk

[George Joseph]

First, I think bidirectionality is a given now.  Still thinking about the
in vs out thing.

Does anyone have concerns about port exhaustion on an Asterisk instance
where we're streaming a large number of calls?  Basically, you're adding a
port for every call being streamed.   I've been considering an "RTP
Muxing"  approach where a single module would open a connection to the
audio server and ALL media would flow to/from it over that single
connection with metadata to distinguish channel/bridge, etc.


On Wed, Jul 24, 2019 at 10:30 AM Seán C. McCord <ulexus at gmail.com> wrote:

> I certainly like the foundation on which George's solution is based the
> best.  It's just not useful to me particularly _until_ it is bidrectional.
> There is something to be said about the accessibility of websocket as a
> transport layer, as per Dan's suggestion.  It's more complicated than a
> pure TCP socket (mainly impeded coding-wise on the Asterisk/C side), which
> is why I didn't go that route with AudioSockets.  I'm still fairly
> ambivalent as to the directionality of the connection initiation, but as
> such, the direction doesn't matter to me.
>
> So it _sounds_ like the ideal solution would be a George's solution which
> added:
>   - bidirectional audio
>   - websocket transport option
>   - arbitrary connection directionality
>
> For _my_ case, the only one which really matters is the first.  I don't
> imagine the second would be a big stretch to do.
>
> However, the last seems to me to be a bit more complicated.  It would
> require overcoming a number of hurdles which outbound conveniently bypasses:
>   - communicating the allocated port (and IP address?) to the ARI (another
> event, I'd assume)
>   - determining the IP address (no small feat)
>     - configured value? (messy)
>     - media signaling address from a PJSIP transport? (not very flexible)
>     - STUN-style discovery? (not designed for this)
>     - ICE-style discovery?  (complicated, and even more needing of
> coordination)
>   - tear-down of listener
>     - time-wise
>     - after connection (what if nother ever connects?)
>     - by command only
>   - security
>     - DoS vulnerability
>
> Technically, you could say that interface binding is a problem with
> outbound, too, of course.  It's just more commonly ignorable.
>
> As you say, though, Rome was not actually built in a day (unless you play
> Imperator: Rome, anyway).  George's foundation is clearly better.
> AudioSockets merely works _now_.
>
>
>
> On Wed, Jul 24, 2019 at 12:11 PM Joshua C. Colp <jcolp at digium.com> wrote:
>
>> On Wed, Jul 24, 2019, at 1:06 PM, Dan Jenkins wrote:
>> > oh I dont think it should ever live on the same websocket as the ARI
>> > because of that very reason. But I mean if it could do ARI websocket,
>> > inbound and outbound tcp connections thats as flexible as you'll ever
>> > get and _anyone_ could build modern applications via any means.
>> > starting development using ARI websocket and then potentially moving to
>> > inbound/outbound whenever you need to scale further using an ARI proxy
>> > for example...
>> >
>> > I just dont want this feature to come out and then be un-usable for X
>> > number of applications. Surely Asterisk needs to be the most flexible
>> > it can be?
>>
>> Rome wasn't built in a day. I think building a solid foundation that the
>> various methods (inbound / outbound) can then be built on top of is good.
>> Launching with one direction initially to get things flushed out, and then
>> later adding other options is perfectly reasonable in my opinion - and can
>> be done since we allow features to be added to release branches.
>>
>> --
>> Joshua C. Colp
>> Digium - A Sangoma Company | Senior Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: www.digium.com & www.asterisk.org
>>
>> --
>> _____________________________________________________________________
>> -- 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/20190725/b7d0bacd/attachment-0001.html>