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

[Ben Merrills]

> 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?

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.

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.

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)

I understand my overview above is very simplistic, but it gives an overview of one way this may be achieved.

Skrusty.