[asterisk-dev] ARI, reinventing the wheel?

[Paul Albrecht]

On Oct 21, 2013, at 11:09 AM, Jared Smith <jaredsmith at jaredsmith.net> wrote:

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

How's this *NOT*" reinventing the AMI wheel? All of this could be accomplished with AMI with the exception of flowing the protocol over a web socket. If that's a requirement, why not fix asterisk to do that and benefit everyone?

> 
> 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
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

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