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
