[asterisk-dev] Audio to/from Asterisk

Thu Jul 25 14:14:10 CDT 2019

+1 to Sean. When a box inherently dies for whatever reason I want that to
drop as few calls as possible for the greatest bang for buck.

On Thu, 25 Jul 2019, 20:03 Seán C. McCord, <ulexus at gmail.com> wrote:

> 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
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190725/92559b49/attachment.html>