So, I've created a dial function that isn’t called as a replacement for Dial, but as a function within my internal framework. Below is a very generalised overview of how it works, this may or may not be of use :) (assume channel is already answered) - although this wouldn't apply to a general approach Dial Simultaneous originate per destination Wait for channel state change on originated channels On Ringing, set Ringing on primary channel (Early media issue here!) On Answer (Up) Cancel all other originated legs Create bridge (options depend on functionality provided by dial implementation [1]) Add leg1 and 2 to the bridge Hangup If we have a bridge, then Remove legs from bridge (hangup leg2, if leg1 hungup) Destroy bridge Return [2] Else Cancelled channel? Channel Destroyed Originate Timeout? Have all originates ended? Return [2] [1] The bridge options will depend on functionality that you need, for example if you need to intercept DTMF or play audio for call limit warning etc [2] My function returns a DialResult class with things like Ringtime, Talktime, Answered destination (simultaneous dialling, it's nice to know who answered) and a disposition, but a general approach would maybe set channel variables(?). On 19 December 2014 at 23:51, Matthew Jordan <mjordan@xxxxxxxxxx> wrote: On Fri, Dec 19, 2014 at 12:39 PM, Joshua Colp <jcolp@xxxxxxxxxx> wrote: > Paul Belanger wrote: >> >> On Fri, Dec 19, 2014 at 1:09 PM, Leif Madsen<lmadsen@xxxxxxxxxxxxxxxxxx> >> wrote: >>> >>> On 19 December 2014 at 13:01, Joshua Colp<jcolp@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
