<div dir="ltr">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, <br>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 <br>stuff and interacts directly with the bridge core, and that's why it doesn't support that data structure. So technically, accessing bridge <br>configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex task, as they don't see the same information space. <div><br></div><div>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 <br>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,<br>my heart goes out to the legacy stuff, that if we don't cater to, will become a caveat. </div><div><br></div><div>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<br>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.</div><div>Recently, the customer came back to me, asking me to upgrade their system to Asterisk 11, specifically for security reasons. I then<br>looked at the code, realizing that the customer had wrote some stuff using MeetMe and some of the deprecated app_queue stuff. </div><div>I indicated to them that their legacy code should be migrated as well. Customer looked at it, realized that apart from upgrading Asterisk,<br>they will have about 6 months worth of coding to migrate their stuff to the new constructs - the entire project caved. We just upgraded<br>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 <br>respect will at some point bite us in the ass.</div><div><br></div><div>I realize this is very much a leadership question, not a technical nor operational. </div><div><br></div><div>New question: Do we want to enable legacy features inside ARI? </div><div><br></div><div>Nir</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 12/17/2014 05:01 PM, Nir Simionovich
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><snip></div>
</blockquote><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>Let's try to stick to the tech for now and answer the first
two questions:</div>
<div><br>
</div>
<div>
<div style="font-size:13px"> 1. Is there a way to obtain the
information in ast_bridge_config for each of the iterated
bridges?<br>
</div>
</div>
</div>
</blockquote>
<br></span>
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.<br>
<br>
For Stasis bridges, the idea of using ast_bridge_config does not
make sense for several reasons<br>
<br>
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.<br>
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.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div style="font-size:13px"> 2. Is there a way to manipulate
the configuration of the bridge, via modifying the
associated bridge configuration in real time?</div>
</div>
</div>
</blockquote>
<br></span>
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.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Nir </div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<br>
</div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div></div>