[asterisk-app-dev] Questions concerning communicating with an ARI app/module from an external application
Daniel Jenkins
dan.jenkins88 at gmail.com
Fri Jan 17 10:09:08 CST 2014
On Fri, Jan 17, 2014 at 4:01 PM, Michael L. Young <myoung at acsacc.com> wrote:
> ----- 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
I drew a really rudimentary diagram the other day which may show you what
we're talking about,
http://imgur.com/NGsGeYR
It may or it may not help,
Let me know if it doesn't and I'll try to explain a bit more
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140117/9e92b6fa/attachment-0001.html>
More information about the asterisk-app-dev
mailing list