<div dir="ltr">While I agree with the both of you - I still don't see a reason why not to do it. <div><br></div><div>I'll tell you how I see it - I'm looking at this kind of feature from a cost/performance/benefit ratio. </div><div><br></div><div>Does this kind of feature enable a new benefit that didn't exist previously - yes.</div><div>Does it impact the overall performance of Asterisk - probably not.</div><div>Is it a low hanging fruit to develop? - I can't answer that yet</div><div>Would it take a longer time to develop a bridge manager externally, or develop the feature? - I can't answer that yet</div><div><br></div><div>Currently, I'm trying to evaluate the task - from a technical/operational/financial reasoning. If Tech/Ops make sense,<br>but Finance doesn't - it ain't worth doing. </div><div><br></div><div>Let's try and discuss for a minute what it would actually take in order to do this, instead of debating<br>if we should or shouldn't. </div><div><br></div><div>Yes, maybe you'll say - "in order to do this, you'll need to do 1, 2, 3, 4 ...." - and maybe I'll: "cool, I'll have a go <br>at it", and maybe it will go in, and maybe it will not - but that's open source. Open Source means, we work collaboratively,<br>we explore things and keep our minds open to ideas and suggestions. </div><div><br></div><div>When Leonid and I created PHPARI about 4 months ago, we created it out of a need for a proper wrapper that<br>will fit nicely into our projects. I'm currently aware of 10 different people using it in production - and some of them<br>already contributed code and structural changes to it. One of the things people asked us for an OAuth based<br>ARI proxy, because they like using tokens. Does ARI truly need something like that - not really. Does ARI<br>need better security - for sure. Will we shot down the idea down? not at this point. We first examine what it will<br>take to do it, technically, then financially - then we decide. </div><div><br></div><div>Damn, this is turning into another theological discussion - not really to be part of this list. </div><div><br></div><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 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 style="font-size:13px"><br></div><div style="font-size:13px">Nir </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 12:33 AM, Phil Mickelson <span dir="ltr"><<a href="mailto:phil@cbasoftware.com" target="_blank">phil@cbasoftware.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nir,<div><br></div><div>I don't disagree with you at all.  All I'd like is another way.  The current methods don't have to disappear.  It's not either or.  However, there's also no reason not to explore new methods, is there?</div><div><br></div><div>Phil M</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 5:29 PM, Nir Simionovich <span dir="ltr"><<a href="mailto:nir.simionovich@gmail.com" target="_blank">nir.simionovich@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Phil,<div><br></div><div>  It is one thing to say: "I'm interested in advancement", it is completely a different thing to say: "I don't give a damn about backward compatibility".</div><div><br></div><div>  Asterisk is a huge community around the world, shifting the community from one methodology of thought to another takes time. During that time <br>of transition, we must think about the fact that some (if not many) will still stick to the old ways. </div><div><br></div><div>  For example, it took over 3 years to deprecate app_meetme - do you honestly believe it will take the same time to deprecate app_dial? I suspect <br>that the answer will be - app_dial will always be there. We may not like it, but still, it is the simplest way of getting a call out of Asterisk. Like it or not,<br>the dialplan will still be here, even 5 years or 10 years from now - it's the most basic form. In the mean time, we must provide functionality and <br>robustness - if we don't, we'll become irrelevant. </div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson <span dir="ltr"><<a href="mailto:phil@cbasoftware.com" target="_blank">phil@cbasoftware.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nir, I agree with you about wondering why does the call go through the dialplan.  Perhaps someone could answer that?  Or, perhaps give us some idea if this will change?<div><br></div><div>In my case, the connection to the dialplan is literally three lines.  The minimum required.  I never return.</div><div><br></div><div>Phil M</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich <span dir="ltr"><<a href="mailto:nir.simionovich@gmail.com" target="_blank">nir.simionovich@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. <div><br></div><div>However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff,<br>both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call.<br>If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: "oh, <br>originate the call and dump it into a Stasis app" - but that didn't happen. Instead, you put the call into a dialplan or an application,<br>which in turn, will call the Stasis app (if truly required). </div><div><br></div><div>My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much<br>needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring<br>out why they should move to ARI. </div><div><br></div><div>This kind of feature can be a tipping point.</div><div><br></div><div>My 2c on the matter.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson <span dir="ltr"><<a href="mailto:phil@cbasoftware.com" target="_blank">phil@cbasoftware.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree with Paul 100%.  Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want.<div><br></div><div>1.  You would know when the call started and was connected.</div><div>2.  You can easily play a sound, any sound, to either end of the connection or to both.</div><div>3.  You can disconnect the call when you want.</div><div>4.  I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time.</div><div><br></div><div>ARI is the way to go!  IMHO.</div><div><br></div><div>Phil M</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich<br>
<<a href="mailto:nir.simionovich@gmail.com" target="_blank">nir.simionovich@gmail.com</a>> wrote:<br>
> Well,<br>
><br>
>   In simple words yes. To be more specific, I'd like to do something like<br>
> this:<br>
><br>
> 1. Have a simple dialplan that will dialout using the L parameter in Dial<br>
> application<br>
> 2. Have ARI bridge list function retrieve not only the list of active<br>
> bridges, but also their allocated duration timers - if assigned<br>
> 3. Provide a means via ARI to manipulate the duration timers<br>
><br>
Correct me if I am wrong, but I don't think this will work.  Any<br>
bridge or channel from your dialplan would not be controlled by<br>
stasis.  And since it is not in stasis, ARI cannot modify it. I think<br>
the general idea was to build a new app_dial atop of ARI, then your<br>
application would provide that functionality to control the L<br>
parameter.<br>
<span><font color="#888888"><br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a><span><font color="#888888"><br>
<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>
</font></span></font></span></blockquote></div></div><span><font color="#888888">
</font></span></div></div><span><font color="#888888"><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></font></span></blockquote></div></div>
<br><span><font color="#888888">--<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></font></span></blockquote></div></div><span><font color="#888888">
</font></span></div></div><span><font color="#888888"><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></font></span></blockquote></div></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>
</div></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>