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 <[email protected]> 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 >
-- _____________________________________________________________________ -- 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
