[asterisk-dev] ARI Extending Existing Feature: bridge control

[Leif Madsen]

On 18 December 2014 at 11:07, Paul Belanger <paul.belanger at polybeacon.com>
wrote:

> On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich
> <nir.simionovich at gmail.com> wrote:
> > New question: Do we want to enable legacy features inside ARI?
> >
> New answer: I don't believe so.
>
> I think this issue / question is the hardest thing to understand about
> ARI.  There really isn't any sort of link to existing Asterisk
> application or features; not yet any ways.  Somebody has to build it
> again a top of ARI.
>
> When I first dreamed of using ARI I was looking at it from a
> configuration management tool mindset.  Oh, I could create a new peer
> in chan_sip over HTTP or let me reconfigure features.conf using ARI.
> However, as I started playing with it more I found that was not what
> it did.  And, changing it to do something like that doesn't feel like
> the right approach.
>
> Now, that being said. Creating some sort of interface to control
> sorcery objects, now that would be cool.  Having sorcery connect to
> redis and change key / values directly in redis for sip peers would be
> hotness.  However, I'm not sure I would want to have Asterisk serve up
> that interface directly.  Feels more like an external application
> would serve up the REST interface into redis, allowing the user to
> change key/pairs.
>
> I also believe, until there are some standard ARI libraries /
> application (for example app_dial replacement). It will feel like a
> large task to build anything in ARI, because some of the core
> application basically need to be written from scratch.  And I think
> this is the main reason people are slow to move to ARI or fearful from
> dropping the dialplan.  Because doing:
>
> exten => s,1,NoOp()
>     same => n,Dial(SIP/foo at example.org)
>
> is a lot easier then origination a channel over ARI, creating bridges
> and playing any tones needed using ARI.  Easier might not be the right
> work, more steps required is.
>

I also agree that we do not want to start making ARI start talking to
legacy applications.

As discussed at AstriDevCon, the push is really to start making Asterisk a
media communications platform. The way to do that is to move away from the
dialplan centric driven applications and to move to a decentralized model
of applications and business logic being separated from Asterisk, and
essentially making Asterisk much dumber in terms of the actual business
logic and routing logic, and making it a lean mean media communications
machine. The way forward sometimes is to stop looking back.

Currently both AMI and AGI are still happily co-existant in Asterisk, and
should be considered the defacto interface to traditional methods of
writing Asterisk business logic (dialplan, etc). When flipping to ARI, it
is a different mind set that does take some time to get around. Much like
Paul I had my own preconceived notions about what ARI was and was initially
disappointed it didn't match what I thought it should have been. However
over the last few months of watching what Paul has been doing along with
some small side POC stuff to better understand what ARI is intended for, it
definitely has become a lot clearer.

At the most basic levels, ARI to me is a bridge control interface that
allows you to hook channels together while not worrying about transcoding,
media characteristics etc. You have two or more channels that may or may
not speak the same language, and your external applications stick them
together, and Asterisk acts as the universal translator for those channels.
By writing all your business logic and controls outside of Asterisk, it
makes the API much simpler to interoperate with, and allows great scaling
possibilities.

Admittedly I'm still a bit naive on a lot of the ARI front, but one thing
my gut tells me, is it is a new interface, and should not be confused as a
replacement to the legacy (term used loosely) methods of building Asterisk
systems. This is one of those situations that I feel avoiding legacy and
backwards compatibility with the traditional methods is going to really
open up a better realm of possibilities with ARI. If someone truly just
needs an HTTP based interface for controlling dialplan and such, I feel a
translation application (library) should just be written for AMI and AGI
that permits that and has that goal. Overloading what ARI is supposed to be
doing is a step backwards in my opinion.

--
Leif "The Dialplan Is Dead" Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141218/0d3df9a3/attachment.html>