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

[Michael L. Young]

----- Original Message -----
> From: "Ben Merrills" <b.merrills at mersontech.co.uk>
> To: "Asterisk Application Development discussion" <asterisk-app-dev at lists.digium.com>
> Sent: Friday, January 17, 2014 5:26:45 AM
> Subject: Re: [asterisk-app-dev] Questions concerning communicating with an ARI app/module from an external
> application
> 
> > On 16/01/14 22:58, Daniel Jenkins wrote:
> > > 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.
> 
> > Alistair Cunningham wrote:
> > Is there any reason that this proxy has to reside within Asterisk?
> > How about
> > having an external ARI proxy/multiplexor/routing daemon that
> > connects to
> > Asterisk ARI, any configured ARI applications (or lets them connect
> > to it), and
> > any other desired IPC systems such as ZeroMQ? That would then leave
> > Asterisk to get on with what it's good at, which is processing
> > calls.
> 
> I think that, based on the fact that AMI isn't being depreciated, why
> would we not include it in a mechanism for communicating between
> asterisk applications and 3rd party applications. Currently if I
> want to talk to app_queue I can use the Actions and Events that
> app_queue exposes. Why would you remove that ability?

I have had to re-read a couple of times Dan's email and yours and I think I am starting to understand what you guys are envisioning.

But, just to be sure, are you guys talking about an App ontop of an App?  You want an App to communicate with an ARI App with Asterisk in the middle?

> Why should people have to use "another standard" just to commutate
> with something that, to them is no different from app_queue. ARI
> should be a complimentary API, not a thorn in 3rd party dev's side.
> They may be totally unaware it's an ARI implementation, and to be
> honest, they shouldn't have to care.

I am not sure how ARI would be a "thorn in 3rd party dev's side".  It is a tool that one can choose to use.  Every tool has a purpose.  It comes down to using the right tool for the right job.

> AMI Actions could be mapped to an ARI Event message, and ARI could
> push messages to AMI. Yes, you're constrained by the format of AMI
> actions and messages, but you retain backwards compatibility in the
> process.

Here it sounds like you want the reverse.  An AMI app to communicate with an ARI app?  If someone is using AMI, why would they need ARI?

> You could have a way of registering AMI Actions from ARI, that exist
> within a specific application. Then have a way of executing those
> Actions from the AMI. For example:
> 
> ARI -> POST -> Register Action "AddQueue" { json description }
> AMI -> AddQueue [params] -> ARI Event Message -> ARI Registered
> Action Event
> 
> ARI -> POST -> AMI Event "event name" { json description } -> AMI
> Event
> 
> (excuse my very lame flow above)

This appears that you want to create dynamic AMI events from ARI.  Why would we be using Asterisk in this fashion?  This just doesn't seem right.

I agree with Alistair.  I feel that this does not belong in Asterisk.

Asterisk is a toolkit.  It allows you to use the right tool for the right job.

Maybe I am just not quite getting the idea that is being proposed and why it should be in Asterisk.

Michael