<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 class="HOEnZb"><div class="h5"><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>--<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>