> -----Original Message----- > From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev- > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Alistair Cunningham > Sent: 17 February 2014 10:34 > To: Asterisk Application Development discussion > Subject: Re: ARI Channel-Exec Suggestion > > On 17/02/14 03:27, Matthew Jordan wrote: > > In general, I'm against the idea of having a mechanism to execute > > dialplan applications through ARI. > > I worry that not allowing this will make it difficult, perhaps impossible, for > those with large AGI applications to reap the benefits of ARI. > > In particular, those doing billing cannot risk losing the control of the call and > having an important billing event such as a hangup or transfer going > unnoticed (or noticed late). Passing control of the call from > Stasis() to back extensions.conf seems to me to be high risk for this (though I > hope I'm wrong). I, and I suspect others too, would much prefer to have > Asterisk call Statis() as soon as it receives an incoming call, and then have the > statis application keep control of the call throughout. > > > (1) It confuses AGI and ARI. AGI does it's job well: allow for remote > > execution of the dialplan from an external source. Heck, you can even > > use an AGI to exec a Stasis application to toss the channel over to > > ARI - that direction is just fine. > > That appears to me to mean that those who need AGI features are stuck > with AGI and cannot fully migrate to ARI. Maybe they can partially, but > they're going to end up with a hybrid AGI/ARI application in the same way > they have a hybrid AGI/AMI application now. ARI is going to be very tempting to AGI programmers, it offers a lot of the same benefits, with some very good improvements, but also some drawbacks. Those drawbacks are becoming evident, and they're not a technical limitation, but a conceptual one. The idea that ARI should be used to replace only certain types of applications I think is a little short sighted. > > > (2b) Remote execution of other dialplan applications opens up a whole > > world of permission escalation vulnerabilities. For example, would it > > be allowable for me to run the System dialplan application through > > that exec statement? > > Don't we already allow that in AGI? > > > (3) As time goes on and more resources are added, the need for this > > functionality will diminish. Right now, channel technology agnostic > > text messaging, i.e., MessageSend, speech recognition, and text to > > speech are some of the more obvious candidates for resources; however, > > I think we've already hit that "90% of the dialplan functionality is > > doable through ARI" point. As we continue to find and build the things > > that people need, I think the desire for this feature will be less - > > other than some people will always like the dialplan :-) > > I agree that this is the long-term answer. Here are the Asterisk applications > Enswitch does an AGI EXEC on: > > AGI(), because we support AGI user plugins. > AMD() > Answer() > Background() > Busy() > ChanSpy() > ConfBridge() > Congestion() > Dial() > Echo() > Hangup() > Monitor() > MusicOnHold() > Page() > Playback() > Playtones() > Progress() > ReceiveFax() > Record() > Ringing() > SendFax() > StartMusicOnHold() > StopMonitor() > StopPlaytones() > UserEvent() UserEvent is another grip of mine. A while ago we discussed the ways in which ARI was being isolated from AMI. Exposing something like UserEvent would help to break that divide. Personally, I think if exec isn't implemented, there will need to be a lot of ARI dependencies on existing dial plan applications (like UserEvent). > > Before we re-write our code to use ARI, we need to be confident that > there's a way to implement (or elegantly work around) all of these. Many are > no problem. Answer() is already implemented, for example. There are some > that worry me though, such as AMD(), ReceiveFax(), and SendFax(). > Of course checking all of them in detail is my job, but if you could quickly cast > your eye down the list and see if there are any obvious problems it would be > much appreciated. > > -- > Alistair Cunningham > +1 888 468 3111 > +44 20 799 39 799 > http://integrics.com/ > > _______________________________________________ > 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
