> -----Original Message----- > From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev- > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew Jordan > Sent: 17 February 2014 02:28 > To: Asterisk Application Development discussion > Subject: Re: ARI Channel-Exec Suggestion > > 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. > My use of the unimrcp commands was quite specific for my usage, I'll explain why. If you wanted to write an ARI application, the only way to play an audio prompt currently is via a stored sound. Allowing for TTS and ASR in ARI would greatly increase the scope for applications possible, admittedly mostly custom applications and not general purpose, but that's beside the point. > (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. AGI lacks some very basic functionality that's now exposed via ARI, and I have to say it's going to be very, very tempting to AGI programmers. Simple things like silence time on a recording are exposed via ARI but not AGI! And now ARI is here, I can only see AGI falling further from the fold into a 3rd class citizen. > > (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) > So, my use case was another example I wanted to write for AsterNET.ARI. This time I have created an implementation of TwilML for ARI. Allowing channels to be controlled via markup, and using ARI seemed like a nice way to do it. This of course lead me to my two questions from yesterday, fetching stored files on the Asterisk server, and being able to interact with dial plan applications, and specifically the unimrcp ones for commands like "Say". In general, ARI lends itself very well to this, bar the points mentioned already. > (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 _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
