Ok, I'll start with this - I agree with the both of you, ARI is the right way to go.
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, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: "oh, 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, which in turn, will call the Stasis app (if truly required). 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 needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson <p...@cbasoftware.com> wrote: > > 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. > > 1. You would know when the call started and was connected. > 2. You can easily play a sound, any sound, to either end of the > connection or to both. > 3. You can disconnect the call when you want. > 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. > > ARI is the way to go! IMHO. > > Phil M > > > On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger < > paul.belan...@polybeacon.com> wrote: >> >> On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich >> <nir.simionov...@gmail.com> wrote: >> > Well, >> > >> > In simple words yes. To be more specific, I'd like to do something >> like >> > this: >> > >> > 1. Have a simple dialplan that will dialout using the L parameter in >> Dial >> > application >> > 2. Have ARI bridge list function retrieve not only the list of active >> > bridges, but also their allocated duration timers - if assigned >> > 3. Provide a means via ARI to manipulate the duration timers >> > >> Correct me if I am wrong, but I don't think this will work. Any >> bridge or channel from your dialplan would not be controlled by >> stasis. And since it is not in stasis, ARI cannot modify it. I think >> the general idea was to build a new app_dial atop of ARI, then your >> application would provide that functionality to control the L >> parameter. >> >> -- >> Paul Belanger | PolyBeacon, Inc. >> Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) >> Github: https://github.com/pabelanger | Twitter: >> https://twitter.com/pabelanger >> >> -- >> _____________________________________________________________________ >> -- 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 >
-- _____________________________________________________________________ -- 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
