On 19 December 2014 at 23:51, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
I'll echo Phil's comment here: the basics of Dial aren't hard. AnOn 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.
>
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
