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

[Paul Belanger]

On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich
<nir.simionovich at gmail.com> wrote:
> I see your point now - that makes more sense. It was fairly clear to me that
> ast_bridge_config is somewhat of a legacy data structure,
> but I was assuming that in some respect it was used in ARI as well. What
> your actually saying is that ARI bypasses all of the legacy
> stuff and interacts directly with the bridge core, and that's why it doesn't
> support that data structure. So technically, accessing bridge
> configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex task,
> as they don't see the same information space.
>
> This now raises a slightly off-topic discussion - wouldn't it beneficial to
> provide some form of ARI access to some of the legacy stuff
> as well? On one hand, we don't really want to do that - as we're trying to
> push people into proper usage of ARI and Asterisk, however,
> my heart goes out to the legacy stuff, that if we don't cater to, will
> become a caveat.
>
> I will explain. About 6 years I've built a large scale Asterisk based dialer
> for a customer. When I say large scale, I meant humongous
> in 2008 terms - 2500 concurrent calls. Now, that dialer relied heavily on
> AMI (of course) and AGI. It was originally built on Asterisk 1.6.
> Recently, the customer came back to me, asking me to upgrade their system to
> Asterisk 11, specifically for security reasons. I then
> looked at the code, realizing that the customer had wrote some stuff using
> MeetMe and some of the deprecated app_queue stuff.
> I indicated to them that their legacy code should be migrated as well.
> Customer looked at it, realized that apart from upgrading Asterisk,
> they will have about 6 months worth of coding to migrate their stuff to the
> new constructs - the entire project caved. We just upgraded
> to latest version of the 1.6 branch, and the customer is now evaluating 1.8
> - in other words, not supporting the legacy stuff in some
> respect will at some point bite us in the ass.
>
> I realize this is very much a leadership question, not a technical nor
> operational.
>
> 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.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger