<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 December 2014 at 23:51, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Fri, Dec 19, 2014 at 12:39 PM, Joshua Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br>
> Paul Belanger wrote:<br>
>><br>
>> On Fri, Dec 19, 2014 at 1:09 PM, Leif Madsen<<a href="mailto:lmadsen@thinkingphones.com">lmadsen@thinkingphones.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 19 December 2014 at 13:01, Joshua Colp<<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>>  wrote:<br>
>>><br>
>>>> Right now you can't directly replace app_dial with an ARI equivalent<br>
>>>> because of early media. There is no way to do anything with a channel<br>
>>>> until<br>
>>>> it has answered and no way to exchange early media.<br>
>>>><br>
>>> So in the mean time, ignoring the "early media" component, for the<br>
>>> signalling (or pseudo-signalling perhaps as it where), could you have the<br>
>>> left hand channel (channel A) attached to a bridge and then connected to<br>
>>> another channel or application in ARI that would provide ringing? (think<br>
>>> the<br>
>>> 'r' option in app_dial)<br>
>>><br>
>>> If so, you could at least simulate the ringing for now, and then when the<br>
>>> other channel answered, move the bridged connection from Channel A to<br>
>>> "ringing channel" over to Channel B.<br>
>>><br>
>>> Forgive me for being naive here. My knowledge of the actual constructs<br>
>>> available in ARI are still primitive :)<br>
>>><br>
>> Okay, so lets ignore the limitation today for early media.   And say<br>
>> we only care about bi-directional audio when the far end answers.  We<br>
>> can then add in features once we get the basic working.<br>
>><br>
>> So ARI dial would be as above.<br>
>><br>
>> Answer incoming channel<br>
>> Start originate<br>
>> on answer create bridge<br>
>> move caller A and B into bridge.<br>
><br>
><br>
> If you want to get as close to app_dial as you can:<br>
><br>
> 1. Don't answer incoming channel<br>
> 2. Originate outgoing channel<br>
> 3. Watch events from outgoing channel<br>
>         If ringing then call /ring on caller<br>
>         If hung up then DELETE caller<br>
> 4. Once outgoing channel has answered answer caller<br>
> 5. Create bridge<br>
> 6. Place caller and outgoing channel into bridge<br>
><br>
> If you want a simplistic dial then what you've done will work.<br>
><br>
<br>
</div></div>I'll echo Phil's comment here: the basics of Dial aren't hard. An<br>
early example can be found in the ari-py repo [1], as well as the<br>
ari-examples repo [2]. In both of these cases, we used a holding<br>
bridge to hold the initiator of the dial, but that's just because it<br>
was fun and interesting. As Phil and Josh noted, you can just use the<br>
ring() operation to indicate Ringing to the caller.<br>
<br>
A lot of Dial's difficulty is because it tries to do everything. Going<br>
down the list of all of the options, and how you might do them in ARI:<br></blockquote><div><br></div><div>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.</div><div><br></div><div>It would be nice to solve the problems around early media. Adhearsion has had some discussion around these issues relating to the Rayo protocol (<a href="https://github.com/adhearsion/adhearsion/issues/298">https://github.com/adhearsion/adhearsion/issues/298</a>) and implements something similar to Dial() (<a href="http://www.rubydoc.info/gems/adhearsion/Adhearsion/CallController/Dial:dial">http://www.rubydoc.info/gems/adhearsion/Adhearsion/CallController/Dial:dial</a>).</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* A - you can easily play announcements to the called party in ARI<br>
* a - you can answer the channels whenever you want<br>
* b|B - pre-dial routines don't make any sense with ARI<br>
* C - ideally, you would reset the CDR prior to the Stasis<br>
application; however, if you are building an ARI application, you<br>
probably aren't relying on Asterisk's CDRs heavily anyway<br>
* c - you can hang up channels however you want during a cancel<br>
* d - you can intercept DTMF from the caller and take any action you want<br>
* D - you can /play DTMF digits to either channel whenever you like<br>
* e - 'h' extension logic doesn't make much sense when you are already<br>
running in a separate process<br>
* f|u - you can manipulate Caller ID on either channel whenever you like<br>
* F|g|G - you can release either surviving channel to the dialplan<br>
however you like<br>
* h|H|k|K|t|T|w|W|x|X - as mentioned on the -dev list [3],<br>
implementing features in ARI is cooler and actually makes your<br>
application simpler - you don't have to keep track of what Asterisk is<br>
doing to your channels<br>
* i|I - these ones *may* eventually have a place in the POST /channels<br>
operation, depending on how an early bridge is implemented<br>
* L - this is actually easier and more powerful to implement in ARI<br>
* m - this can be done with a holding bridge or a direct startMoH call<br>
* M - macros don't make sense in ARI<br>
* n|N|p|P - privacy mode can be implemented in ARI however you'd like<br>
* o - does anyone even use this?<br>
* O - I repeat, does anyone even use this?<br>
* r|R - you determine how you ring to the caller<br>
* S - trivial to implement with a timer in ARI<br>
* s - you control the outgoing channel's party identification<br>
* U - gosubs don't make sense in ARI<br>
* z - you control the dial operation yourself<br>
<br>
So... other than early media and some possible interception of party<br>
identification updates that happen automatically under the hood, an<br>
ARI application can do just about everything Dial does... and more.<br>
<br>
[1] <a href="https://github.com/asterisk/ari-py/blob/master/examples/originate_example.py" target="_blank">https://github.com/asterisk/ari-py/blob/master/examples/originate_example.py</a><br>
[2] <a href="https://github.com/asterisk/ari-examples/tree/master/bridge-dial" target="_blank">https://github.com/asterisk/ari-examples/tree/master/bridge-dial</a><br>
[3] <a href="http://lists.digium.com/pipermail/asterisk-dev/2014-December/071971.html" target="_blank">http://lists.digium.com/pipermail/asterisk-dev/2014-December/071971.html</a><br>
<span class=""><font color="#888888"><br>
--<br>
Matthew Jordan<br>
Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
</div></div></blockquote></div><br></div></div>