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

[Julian Lyndon-Smith]

This is similar to how we are currently using asterisk, with realtime
curl, node and rabbitMQ / stomp , and would more than welcome this
approach

All of our queue logic is in the application, not app_queue

Julian

On 17 January 2014 20:09, Paul Belanger <paul.belanger at polybeacon.com> wrote:
> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev



-- 
Julian Lyndon-Smith
IT Director, Dot R Limited

"I don’t care if it works on your machine!  We are not shipping your machine!”

The kangaroo dances: http://www.youtube.com/watch?v=MAWl5iYOaUg