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 <[email protected]> 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 <[email protected]> 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 > [email protected] > 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
