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@xxxxxxxxxxxxxx> wrote: > On Thu, Jan 16, 2014 at 4:58 PM, Daniel Jenkins <dan.jenkins88@xxxxxxxxx> 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@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger > > _______________________________________________ > asterisk-app-dev mailing list > asterisk-app-dev@xxxxxxxxxxxxxxxx > 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 _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
