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
