[asterisk-app-dev] ARI Channel-Exec Suggestion

[Ben Merrills]

> -----Original Message-----
> From: asterisk-app-dev-bounces at lists.digium.com [mailto:asterisk-app-dev-
> bounces at lists.digium.com] On Behalf Of Alistair Cunningham
> Sent: 17 February 2014 10:34
> To: Asterisk Application Development discussion
> Subject: Re: [asterisk-app-dev] 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 at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev