<div dir="ltr">Unfortunately I won't be at DevCon this year (I'll be on a plane flying from West to East US) - I will of course try to listen in etc but I'd like to raise one new idea and another maintenance issue to be discussed at DevCon.<div><br></div><div>Idea:</div><div><br></div><div>I find it tough to get people (even myself) to build actual production applications with the ARI because of the nature of how we connect to the ARI - one websocket from an application into Asterisk. Over the years this has lead to proxies sitting in the middle, those being maintained (or unmaintained due to maintainers moving on and no longer developing the codebase etc). Last year we discussed making the ARI work with more than one websocket connected with the same app name - as far as I'm aware this hasn't happened yet.</div><div><br></div><div>Working with Drachtio (a SIP Proxy) a lot this year has made me realise we were overcomplicating the matter. Drachtio has the idea of inbound and outbound connections (apps that are addressable by Drachtio) - its very much like ARI. Inbound connections - Node app makes a TCP connection to Drachtio and traffic is sent down it. Good for development of an idea maybe but not good for production scaling - exactly the same as ARI. Drachtio also has the concept for outbound connections - whenever a SIP dialog (or whatever messaging) needs to go to an application, Drachtio makes an outbound connection to an app - 10 Drachtios can all make outbound connections to a TCP loadbalancer and could talk to 500 Node apps - ridiculous numbers but hopefully you see the point. Its easy to scale in comparison to what we have in ARI today.</div><div><br></div><div>Dialplan (yes I know.... after I asked to not have to even write Stasis() any more....) would look like.... - thanks for that! (side note - can we redirect from one stasis app to another yet?)</div><div><br></div><div>Stasis("app") - no change<br></div><div>Stasis("wss://<a href="http://foo.com">foo.com</a>") - if the string is a URI then make an outbound connection to it. If it doesn't accept the websocket in a timeout period then fail it so you could go to another line of dialplan where you could go to another Stasis app</div><div><br></div><div>Stasis("wss://<a href="http://foo.com">foo.com</a>") - fail</div><div>Stasis("wss://<a href="http://bar.com">bar.com</a>") - yay success</div><div><br></div><div>I think this is really flexible and simple and allows us to utilise existing load balancers that are already available like in AWS or HaProxy - no need to maintain a proxy codebase any more.</div><div><br></div><div>You should be able to add metadata to the uri as uri parameters too</div><div>Stasis("wss://<a href="http://bar.com?uuid=foo-bar-foo-bar">bar.com?uuid=foo-bar-foo-bar</a>")<br></div><div><br></div><div>Probably opens a can of worms with auth mechanisms etc.... maybe you should be able to set variables before the stasis call to have them included? I don't know...</div><div><br></div><div>Of course, the client libraries would need updated to support creating a websocket server instead of a websocket client</div><div><br></div><div>Maintenance item</div><div><br></div><div>the old swagger definitions of the ARI need updated. We need to get off an old definition format and at least move to open API. I know many people who have tried to say fix something in the node module and given up because trying to get setup is difficult. If we're not going to keep up with standards then we should just not use a standard thats out there (I don't agree with this)</div><div><br></div><div>Looking forward to seeing as many of you as I can at Astricon</div><div><br></div><div>Dan</div></div>