[asterisk-app-dev] ARI dial application

Sat Dec 20 05:01:14 CST 2014

On 19 December 2014 at 23:51, Matthew Jordan <mjordan at digium.com> wrote:

> On Fri, Dec 19, 2014 at 12:39 PM, Joshua Colp <jcolp at digium.com> wrote:
> > Paul Belanger wrote:
> >>
> >> On Fri, Dec 19, 2014 at 1:09 PM, Leif Madsen<lmadsen at thinkingphones.com
> >
> >> wrote:
> >>>
> >>> On 19 December 2014 at 13:01, Joshua Colp<jcolp at digium.com>  wrote:
> >>>
> >>>> Right now you can't directly replace app_dial with an ARI equivalent
> >>>> because of early media. There is no way to do anything with a channel
> >>>> until
> >>>> it has answered and no way to exchange early media.
> >>>>
> >>> So in the mean time, ignoring the "early media" component, for the
> >>> signalling (or pseudo-signalling perhaps as it where), could you have
> the
> >>> left hand channel (channel A) attached to a bridge and then connected
> to
> >>> another channel or application in ARI that would provide ringing?
> (think
> >>> the
> >>> 'r' option in app_dial)
> >>>
> >>> If so, you could at least simulate the ringing for now, and then when
> the
> >>> other channel answered, move the bridged connection from Channel A to
> >>> "ringing channel" over to Channel B.
> >>>
> >>> Forgive me for being naive here. My knowledge of the actual constructs
> >>> available in ARI are still primitive :)
> >>>
> >> Okay, so lets ignore the limitation today for early media.   And say
> >> we only care about bi-directional audio when the far end answers.  We
> >> can then add in features once we get the basic working.
> >>
> >> So ARI dial would be as above.
> >>
> >> Answer incoming channel
> >> Start originate
> >> on answer create bridge
> >> move caller A and B into bridge.
> >
> >
> > If you want to get as close to app_dial as you can:
> >
> > 1. Don't answer incoming channel
> > 2. Originate outgoing channel
> > 3. Watch events from outgoing channel
> >         If ringing then call /ring on caller
> >         If hung up then DELETE caller
> > 4. Once outgoing channel has answered answer caller
> > 5. Create bridge
> > 6. Place caller and outgoing channel into bridge
> >
> > If you want a simplistic dial then what you've done will work.
> >
>
> I'll echo Phil's comment here: the basics of Dial aren't hard. An
> early example can be found in the ari-py repo [1], as well as the
> ari-examples repo [2]. In both of these cases, we used a holding
> bridge to hold the initiator of the dial, but that's just because it
> was fun and interesting. As Phil and Josh noted, you can just use the
> ring() operation to indicate Ringing to the caller.
>
> A lot of Dial's difficulty is because it tries to do everything. Going
> down the list of all of the options, and how you might do them in ARI:
>

Agreed entirely. Dial() is the same sort of monster that Voicemail and such
are. I think Paul is trying to get agreement on an ARI /dial resource
(please correct me if I've misunderstood, Paul!) but I think this is a
mistake. This would break with the purpose of ARI, which is for low-level
flexible control to implement these sort of application level features
outside of Asterisk.

It would be nice to solve the problems around early media. Adhearsion has
had some discussion around these issues relating to the Rayo protocol (
https://github.com/adhearsion/adhearsion/issues/298) and implements
something similar to Dial() (
http://www.rubydoc.info/gems/adhearsion/Adhearsion/CallController/Dial:dial
).

What we have found is that these things are very often application specific
and it's difficult to create something simple yet generic at the
application level of abstraction; it is probably better to simplify or
augment the lower level primitives to compose these things more easily in
an ARI application.

> * A - you can easily play announcements to the called party in ARI
> * a - you can answer the channels whenever you want
> * b|B - pre-dial routines don't make any sense with ARI
> * C - ideally, you would reset the CDR prior to the Stasis
> application; however, if you are building an ARI application, you
> probably aren't relying on Asterisk's CDRs heavily anyway
> * c - you can hang up channels however you want during a cancel
> * d - you can intercept DTMF from the caller and take any action you want
> * D - you can /play DTMF digits to either channel whenever you like
> * e - 'h' extension logic doesn't make much sense when you are already
> running in a separate process
> * f|u - you can manipulate Caller ID on either channel whenever you like
> * F|g|G - you can release either surviving channel to the dialplan
> however you like
> * h|H|k|K|t|T|w|W|x|X - as mentioned on the -dev list [3],
> implementing features in ARI is cooler and actually makes your
> application simpler - you don't have to keep track of what Asterisk is
> doing to your channels
> * i|I - these ones *may* eventually have a place in the POST /channels
> operation, depending on how an early bridge is implemented
> * L - this is actually easier and more powerful to implement in ARI
> * m - this can be done with a holding bridge or a direct startMoH call
> * M - macros don't make sense in ARI
> * n|N|p|P - privacy mode can be implemented in ARI however you'd like
> * o - does anyone even use this?
> * O - I repeat, does anyone even use this?
> * r|R - you determine how you ring to the caller
> * S - trivial to implement with a timer in ARI
> * s - you control the outgoing channel's party identification
> * U - gosubs don't make sense in ARI
> * z - you control the dial operation yourself
>
> So... other than early media and some possible interception of party
> identification updates that happen automatically under the hood, an
> ARI application can do just about everything Dial does... and more.
>
> [1]
> https://github.com/asterisk/ari-py/blob/master/examples/originate_example.py
> [2] https://github.com/asterisk/ari-examples/tree/master/bridge-dial
> [3]
> http://lists.digium.com/pipermail/asterisk-dev/2014-December/071971.html
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20141220/8cc50049/attachment-0001.html>