[asterisk-dev] ARI Extending Existing Feature: bridge control

Mark Michelson mmichelson at digium.com
Wed Dec 17 16:32:17 CST 2014


Regarding Stasis origination: like AMI/CLI/Dialplan origination, Stasis 
origination comes in two flavors.

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.

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.

Now on to Nir's suggestion regarding bridge lifetimes:

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.

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.

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.

On 12/17/2014 03:16 PM, Phil Mickelson wrote:
> 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?
>
> In my case, the connection to the dialplan is literally three lines.  
> The minimum required.  I never return.
>
> Phil M
>
>
> On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich 
> <nir.simionovich at gmail.com <mailto:nir.simionovich at gmail.com>> wrote:
>
>     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
>     <phil at cbasoftware.com <mailto:phil at 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.belanger at polybeacon.com
>         <mailto:paul.belanger at polybeacon.com>> wrote:
>
>             On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich
>             <nir.simionovich at gmail.com
>             <mailto:nir.simionovich at 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.belanger at polybeacon.com
>             <mailto:paul.belanger at 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
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141217/622dd3b2/attachment.html>


More information about the asterisk-dev mailing list