On Sun, Feb 16, 2014 at 10:45 AM, Ben Merrills
<b.merrills@xxxxxxxxxxxxxxxx> wrote:
> Hi All,
>
> I was wondering, what thought has been given to Exec style commands in ARI.
> Say for example I want to call another app within Asterisk, let's say
> MRCPSynth for TTS.
>
> Looking at the channel spec, there's currently no way to execute a dial plan
> application on a channel. I say 'Exec' simply because I come from an AGI
> background.
>
> Would something like this be a way forwards?:
>
> POST /channels/{channelid}/exec?app=MRCPSynth
>
> BODY: <?xml version=\"1.0\"?><speak version=\"1.0\" xml:lang=\"en-AU\"
> xmlns=\"http://www.w3.org/2001/10/synthesis\";><voice name='Karin'
> gender='female'>Hello
> world!</voice></speak>,p=default&i=any&f=/tmp/synth.raw
>
> Where the application is passed in the query, and the arguments as the body
> of the HttpPost.
>
> Just throwing this out there to see if others have given this consideration
> yet.
>
In general, I'm against the idea of having a mechanism to execute
dialplan applications through ARI. Here's a few thoughts on why,
although - like anything - I think it'd be great to have more
discussion surrounding this topic.
(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. ARI's purpose, however, isn't to
replace the dialplan (although you may end up replacing *most* of it
with various ARI applications) - it's to replace Queue. Or VoiceMail.
Or any of the other applications you may call from the dialplan. In
general, you wouldn't call VoiceMail *from* Queue - you'd release it
back to the dialplan with instructions on where to go next. That's a
good paradigm to have, and I think ARI fits better in that model then
trying to throw away the dialplan.
(2) It's hard to say that all dialplan applications are safe to
execute from ARI. Your example *may* be safe to execute - but throwing
a channel into Queue, VoiceMail, or any other long running application
would *not* be safe. Having a resource operation that creates unsafe
state is not something I'd want.
(2a) On this same point, there is a major difference between AGI and
ARI: AGI is synchronous and blocks while it executes; ARI is not. Say
running an exec operation initially is safe - what do we do when ARI
issues an addChannel operation to a bridge? Or starts an asynchronous
media operation while the channel is in some other application? Or
attempts to control a channel's media operation that was started by
the other application? There's a lot of plumbing that lets ARI do this
to a channel in the Stasis dialplan application that explicitly does
not exist for every other application. Things won't only not just
work; they could crash (in sometimes very unpredictable ways)
(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?
(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 would much rather add resources for the kinds of functionality that
is needed, rather than expose the dialplan equivalents. TTS would be
fantastic to expose as a resource with supporting operations using
Asterisk's res_speech engine, which would make it agnostic of the TTS
engine. I *think* the UniMRCP libraries are built on this, since they
provide a res_speech_unimrcp library.
Just as a side note - and I'll throw my "IANAL" disclaimer on this -
but I know there's versions of UniMRCP out there that are not
compatible with the GPLv2. You may want to double check the licensing
of your modules and the libraries that they depend on.
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
