Re: ARI Channel-Exec Suggestion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev




[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux