[asterisk-dev] Audio to/from Asterisk

Thu Jul 25 12:01:21 CDT 2019

While I know there are people who try to maximize the number of concurrent
calls, that's really not an issue for me.  I dimension these systems to
about 200 calls per Asterisk box.  Even if that were 1000, port exhaustion
just isn't a concern.

On Thu, Jul 25, 2019 at 12:54 PM George Joseph <gjoseph at digium.com> wrote:

> 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
>
> --
> _____________________________________________________________________
> -- 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/20190725/0f13568d/attachment.html>