<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 25, 2019 at 12:54 PM George Joseph <<a href="mailto:gjoseph@digium.com">gjoseph@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"><div dir="ltr">First, I think bidirectionality is a given now.  Still thinking about the in vs out thing.<div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 10:30 AM Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.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"><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" target="_blank">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-m_-5552963068543355473gmail-m_3329298359294357495gmail_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>
-- <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-m_-5552963068543355473gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><b style="font-family:arial,helvetica,sans-serif;font-size:12.8px">George Joseph</b><br></div><div dir="ltr"><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Digium - A Sangoma Company | Software Developer | Software Engineering</font></div><font size="1">445 Jan Davis Drive NW - Huntsville, AL 35806 - US</font></div><div dir="ltr"><font size="1">direct/fax: +1 256 428 6012</font><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Check us out at: <a href="https://digium.com/" style="color:rgb(17,85,204)" target="_blank">https://digium.com</a> · <a href="https://sangoma.com/" style="color:rgb(17,85,204)" target="_blank">https://sangoma.com</a></font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><img width="96" height="60"></div></div></div></div></div></div>
-- <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>