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

[Paul Belanger]

On Thu, Jan 16, 2014 at 4:58 PM, Daniel Jenkins <dan.jenkins88 at gmail.com> wrote:
> Hi All,
>
Ohai!

> 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.
>
Here is how we are looking at doing the app_queue replacement, which
we call payload.  Business logic does not belong in payload, so much
so we are actually thinking people will extend payload for their
specific needs.

> 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.
>
Right, to me the apps folder in asterisk, not that ARI is released, is
basically dead.  Anything that exists their today, eventually will
exists as an ARI application. From Asterisk point of view, it is no
longer an app engine, but handles media operations (and obviously the
ARI interface).

> 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.
>
For me, I want Asterisk out of the picture as much as possible. I will
explain further down.

> 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...
>
They say a picture is a 1000 words, so please take a look at the following:

http://wiki.kickstand-project.org/pabelanger?action=AttachFile&do=view&target=payload.png

This is something that leifmadsen, juggie and myself have been working
on over the last few months.  Basically a blueprint for our queue
replacement. As you can see, at the core of it we are using a message
bus (AMQP for instance).  Then, on the right side, we have multiple
Asterisk boxes (because we want distributed queues) we have a local
process that converts AMPQ <--> ARI, then of course Asterisk.

With that in mind, that is the extent of so called 'interface' into
Asterisk.  You can then see, on the left hand side, we plan on doing
the business logic and providing our own interface for users to
consume. Again, you see Asterisk is not in the picture here. Nor do I
think we want it in the picture, simply put I can't guarantee my
asterisk node to be there 15 mins from now, either because I deleted
it (VM) or because it crashed.  I want all my data out side and setup
in a HA / redundant manner.

So, it answer your question, no I don't think I'd want it in Asterisk,
I want it to be outside of Asterisk.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger