<div dir="ltr">Hi All,<div><br></div><div>Something we've been discussing on and off on the asterisk-dev IRC channel is how an external application communicates with an ARI application. You'll have to bear with me, as I explain the scenario where this becomes an issue.</div>
<div><br></div><div>We're talking a lot ( and some people are even "doing") about how we can replace app_queue or app_voicemail with an ARI application - right now we see these as being very specific apps built for a certain business need, you write all your business logic into your application and that application talks to Asterisk via the ARI.</div>
<div><br></div><div>However, there's also the possibility of creating generic replacements for app_queue etc in the long run, where we can replace all the C driven app_queue with an application that communicates via the ARI,</div>
<div><br></div><div>So in the long run, in my view, there's the possibility of being able to configure asterisk without any C apps - because they won't exist anymore; just the same as you can compile asterisk without any C apps today, but instead of C apps, you'd be able to have asterisk with "digium certified ari apps" - these apps would be voicemail, queue etc.</div>
<div><br></div><div>So, if you take the second scenario, average joe bloggs user who just wants to use "asterisk" and doesn't care that underneath it you've got a python process running an app_queue replacement and a Node.js process running a voicemail replacement. The end user just sees Asterisk.</div>
<div><br></div><div>This is where thing's get a little confusing when it comes to communication. Today, we can talk to app_queue via the AMI, we can give it commands and we can say we want information and that information to be sent to us in the form of events. Imagine the point where Asterisk has a replacement app doing queue duties for us. Our external application still wants to run commands at queue, we still want to get notifications about what's going on, just the same as today. However, as things stand, you can't do this.</div>
<div><br></div><div>One solution that was suggested in IRC was that you wouldn't talk to Asterisk, you'd talk to the application itself that was dealing with Queues now. I'd say this is 1. confusing for an end user and 2. can lead to huge inconsistencies in how we talk to these apps/modules.</div>
<div><br></div><div>Today, we have a standard in the AMI, however good or bad people think of that standard, it's still a standard way of getting information and sending actions.</div><div><br></div><div>What a few of us in IRC are suggesting is for Asterisk to act as a proxy in a sense when it comes to talking to an ARI application. And for that proxy to enforce standards.</div>
<div><br></div><div>So for example, app_queue replacement would assign to Asterisk routes within the ARI (HTTP and Websocket) or even the AMI, when calling one of those routes/actions/websocket streams, the information would be routed to/from the ARI application.</div>
<div><br></div><div>This could then also enforce standards, so a call id would always be a callId (Or whatever it really is) and not a call_id / id / call / callId / callID / CallID across multiple ARI applications.</div>
<div><br></div><div>It means the end user has one form of communication, one standard, not different endpoints on different ports from different applications.</div><div><br></div><div>What do people think? Is there a case for something like this? Do we ever see these generic ARI modules becoming a real part of Asterisk?</div>
<div><br></div><div>Keen to know people's thoughts on the matter! If I haven't explained myself as well as I could have, I can make a diagram or something...</div><div><br></div><div>Dan</div><div><br></div></div>