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

[Alistair Cunningham]

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.

> (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()

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/