[asterisk-app-dev] Questions concerning communicating with an ARI app/module from an external application

[Daniel Jenkins]

Hi All,

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.

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.

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,

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.

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.

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.

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.

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.

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.

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.

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.

It means the end user has one form of communication, one standard, not
different endpoints on different ports from different applications.

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?

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...

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140116/01e92086/attachment.html>