+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, <ule...@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 <gjos...@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 <ule...@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 <jc...@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 >>> ule...@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 > ule...@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
