<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Regarding Stasis origination: like
AMI/CLI/Dialplan origination, Stasis origination comes in two
flavors.<br>
<br>
1) Originate to an application. Unlike with AMI/CLI/Dialplan
origination to an application, this will always originate to a
Stasis application. So in a way, this flavor of origination does
what Nir expects.<br>
<br>
2) Originate to a dialplan location. This functions pretty much
exactly like AMI/CLI/Dialplan origination to an
extension/context/priority. The difference here is that your
Stasis application gains a subscription to the channel that is
created, so you have the ability to be notified of activities that
this channel performs. My guess is that this is intended more for
deployments that have upgraded Asterisk to use ARI for specific
applications, but that already have some semblance of dialplan/AGI
that they want to incorporate. In general, I would expect that
someone implementing an ARI application from scratch would never
use this flavor of origination.<br>
<br>
Now on to Nir's suggestion regarding bridge lifetimes:<br>
<br>
I'm not a fan of adding this to ARI. To me ARI should expose
primitive operations only, and it's up to
library/framework/application writers to build it into something
more. For instance, you'll notice that we have no DTMF-triggered
features available in ARI bridges. This is because we expose the
ability for ARI applications to capture DTMF themselves and
translate that into their own feature instead. Similarly, with
regards to bridge lifetimes, any programming language you could
ever use to write an ARI application will have timing libraries
available for you to manage the lifetime of a bridge.<br>
<br>
The thing that's neat with a REST interface that exposes
primitives is that it promotes an ecosystem where people can write
libraries on top of ARI that perform more complex operations. For
instance, it would be totally possible for someone to write a
bridge management library that exposed a more complex API where
bridges could have a lifetime, could play media to participants at
given intervals, could have the lifetime changed (and play media
to the participants letting them know that the lifetime changed),
and could maybe even allow the bridge to be re-created after
expiration if a participant takes a certain action (like providing
more money to a service). Someone else could fork that bridge
management library and add their own features on top of it.<br>
<br>
Instead of having ARI expose the "one true way" to manage the
lifetime of bridges, people have a choice between different
implementations written by others or they can write their own
(either from scratch or by forking someone else's library) to fit
their needs.<br>
<br>
On 12/17/2014 03:16 PM, Phil Mickelson wrote:<br>
</div>
<blockquote
cite="mid:CAHVWxNB9z4w48_CEw3Uy-j0WKbDBXhmwO2yL1ABeWhjgjzVbDQ@mail.gmail.com"
type="cite">
<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="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 17, 2014 at 4:12 PM, Nir
Simionovich <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:paul.belanger@polybeacon.com"
target="_blank">paul.belanger@polybeacon.com</a>
| IRC: pabelanger (Freenode)<br>
Github: <a moz-do-not-send="true"
href="https://github.com/pabelanger"
target="_blank">https://github.com/pabelanger</a>
| Twitter: <a moz-do-not-send="true"
href="https://twitter.com/pabelanger"
target="_blank">https://twitter.com/pabelanger</a><span
class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided
by <a moz-do-not-send="true"
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 moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888">
</font></span></div>
</div>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>