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

[Nir Simionovich]

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?

Nir

On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson <mmichelson at digium.com>
wrote:
>
>  On 12/17/2014 05:01 PM, Nir Simionovich wrote:
>
> <snip>
>
>  Let's try to stick to the tech for now and answer the first two
> questions:
>
>    1. Is there a way to obtain the information in ast_bridge_config for
> each of the iterated bridges?
>
>
> ast_bridge_config is not used at all for Stasis bridges. ast_bridge_config
> describes bridge features that basic bridges use based on Dial(), Queue(),
> and FollowMe() features. For instance, when Dial is called with the 't' and
> 'T' options, the ast_bridge_config indicates that the caller and callee can
> perform DTMF transfers based on features.conf settings.
>
> For Stasis bridges, the idea of using ast_bridge_config does not make
> sense for several reasons
>
> 1) Stasis applications are intended to be fully in control of everything
> that happens in the bridge. There should be nothing that the participants
> should be able to do independently of the Stasis application to change the
> bridge.
> 2) ast_bridge_config relies heavily on the concept that a bridge contains
> exactly two participants. For basic bridges, this assumption holds. Stasis
> bridges can have any number of participants, though, so this structure
> doesn't work well.
>
>     2. Is there a way to manipulate the configuration of the bridge, via
> modifying the associated bridge configuration in real time?
>
>
> The configuration of a Stasis bridge is defined by the Stasis application
> that creates and manipulates the bridge. It is up to the Stasis application
> to determine properties of the bridge and manipulate the bridge based on
> those properties. Whether you can manipulate this in real time is based on
> the programming language and runtime model of the ARI library you use.
>
>
>  Nir
>
>
>
> --
> _____________________________________________________________________
> -- 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/e6575046/attachment.html>