<div dir="ltr">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.<div><br></div><div>So it _sounds_ like the ideal solution would be a George's solution which added:</div><div> - bidirectional audio</div><div> - websocket transport option</div><div> - arbitrary connection directionality</div><div><br></div><div>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. </div><div><br></div><div>However, the last seems to me to be a bit more complicated. It would require overcoming a number of hurdles which outbound conveniently bypasses:</div><div> - communicating the allocated port (and IP address?) to the ARI (another event, I'd assume)</div><div> - determining the IP address (no small feat)</div><div> - configured value? (messy)</div><div> - media signaling address from a PJSIP transport? (not very flexible)</div><div> - STUN-style discovery? (not designed for this)</div><div> - ICE-style discovery? (complicated, and even more needing of coordination)</div><div> - tear-down of listener</div><div> - time-wise</div><div> - after connection (what if nother ever connects?)</div><div> - by command only</div><div> - security</div><div> - DoS vulnerability</div><div><br></div><div>Technically, you could say that interface binding is a problem with outbound, too, of course. It's just more commonly ignorable.</div><div><br></div><div>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_.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 12:11 PM Joshua C. Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jul 24, 2019, at 1:06 PM, Dan Jenkins wrote:<br>
> oh I dont think it should ever live on the same websocket as the ARI <br>
> because of that very reason. But I mean if it could do ARI websocket, <br>
> inbound and outbound tcp connections thats as flexible as you'll ever <br>
> get and _anyone_ could build modern applications via any means. <br>
> starting development using ARI websocket and then potentially moving to <br>
> inbound/outbound whenever you need to scale further using an ARI proxy <br>
> for example... <br>
> <br>
> I just dont want this feature to come out and then be un-usable for X <br>
> number of applications. Surely Asterisk needs to be the most flexible <br>
> it can be?<br>
<br>
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.<br>
<br>
-- <br>
Joshua C. Colp<br>
Digium - A Sangoma Company | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" rel="noreferrer" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" rel="noreferrer" target="_blank">www.asterisk.org</a><br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Seán C. McCord<div><a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a><br><div>CyCore Systems</div></div></div>