[asterisk-dev] ARI, reinventing the wheel?

[Jared Smith]

On Mon, Oct 21, 2013 at 11:39 AM, Paul Albrecht <palbrecht at glccom.com>wrote:

> You have misunderstood my question. Let me try again: What is the
> justification for developing a new interface for managing asterisk? How is
> it an improvement over AMI? What specifically is AMI lacking? How does ARI
> fix the problem?
>

Let me see if I can clarify things here.

First of all, you seem to be coming into the conversation with a
preconceived notion that ARI is somehow a replacement or "better version"
of AMI.  This is not the case.  AMI was designed for third-party command
and control.  ARI was not designed for the same type of command and
control.  To illustrate this, let me explain the typical scenario in which
ARI might be used.

1) An external ARI program creates a websocket connection to Asterisk (over
Asterisk's built-in HTTP server) and connects to the "/ari/events?app=foo"
resource.  In doing so, it registers an application name (foo in this
example) for which it would like to receive event notifications.

2) A call enters the Asterisk dialplan, and calls the
Stasis(foo,hello,world) dialplan application.  The first parameter to the
dialplan application (foo in this example) is the application name (with
other parameters being arbitrary parameters passed to your ARI
application).  When the channel calls this dialplan application, Asterisk
emits an event over the Stasis message bus (and hence to the program in
step one listening for events on the websocket) letting the program know
that there is a new channel that has connected, and passing along the
unique channel identifier.

3) The program in step one then controls the business logic of the call.
It might, for example, make an HTTP call over the REST interface to the
/ari/channels/{channelId}/answer, to tell Asterisk to answer that
particular channel.  The program might use REST APIs to play sounds, start
call recording, create bridges, etc.  As these things happen, events
continue to get generated on the Stasis bus, and the program reads those
events from the websocket connection.

As you can see, ARI is much more about first-party channel control than it
is about third-party command and control of the Asterisk system in
general.  In that regard, it's much more related to the ExternalIVR and AGI
interfaces than it is to AMI.  Hopefully that helps clarify why Paul
Belanger stated that AMI is what you'd want to use if you wanted to write a
new piece of functionality in Asterisk (say a replacement for Asterisk's
aging voicemail or queueing systems) without diving into C code.

--
Jared Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131021/4d80788a/attachment.html>