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

[Nir Simionovich]

Now, this is why I love Open Source - opinions, thoughts and most
importantly, acceptance.

I can totally see where the general idea is going here, and that is what we
all agreed during AstriDevCon this year.


On Thu, Dec 18, 2014 at 6:31 PM, Leif Madsen <lmadsen at thinkingphones.com>
wrote:
>
> 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
>
> --
> _____________________________________________________________________
> -- 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/20141218/b38eac75/attachment.html>