On Tue, Apr 2, 2019, at 9:06 PM, Sungtae Kim wrote: > > On 4/3/19 1:29 AM, Joshua C. Colp wrote: > > On Tue, Apr 2, 2019, at 8:26 PM, Matthew Jordan wrote: > >> > >> On Tue, Apr 2, 2019 at 4:18 PM Joshua C. Colp <jc...@digium.com> wrote: > >>> On Tue, Apr 2, 2019, at 8:15 PM, BJ Weschke wrote: > >>> > I get the desired use case to run app_amd from within a Stasis > >>> > application, but I’m not sure about app_queue. You have everything at > >>> > your disposal within ARI itself to replicate all of the functionality > >>> > of app_queue and beyond. > >>> > >>> Yes, there are certain applications which are logically building blocks > >>> to bigger applications. AMD is one of those which would be best if it > >>> were its own functionality within ARI, but allowing execution of the > >>> application is a good enough option. I don't think applications such as > >>> Queue, Dial, ConfBridge, Playback, Record or some others really make > >>> sense. > >>> > >> Assuming the TALK_DETECTION function isn't sufficient, it's worth > >> noting that the information that AMD uses to make its decisions are > >> available to the parts of Asterisk that make up ARI. I wonder if it > >> would be better to simply wrap up the existing talk detection events > >> under some other HTTP resource rather than open up this entire concept. > > Ideally for AMD I think this would be preferred. > > > >> While I'm pretty far removed from the guts of Asterisk these days, the > >> notion of having dialplan applications be executed from within ARI just > >> fills me with some fear. You can certainly open up some nightmare > >> scenarios where people invoke Stasis from within Stasis recursively, or > >> invoke GoTo or other dialplan context affecting applications. > >> > >> For that matter, many of the monolithic dialplan applications have > >> specific options that place channels into dialplan contexts that > >> execute after their execution. I'm not even sure I can begin to wrap my > >> head around what that will do to a channel in ARI. > > Indeed, that's why I suggested bringing it up on here precisely what > > applications people are needing to jump into the dialplan for. Best case > > those could be made first class citizens under ARI, but worst case I think > > a small subset could be allowed to be executed from ARI. I'm personally > > against allowing arbitrary execution of any application. There's just too > > many unknowns as you say. > > Now I can see the problem too. But also I can see I'm not the only one > having a same dilemma. > > Hm... What it suppose to be? I want implement this feature, but little > bit lost now. > > I will wait for feedback.
I think waiting for now in case there's any additional input on what people jump to the dialplan is good. We can revisit in a week or so once everyone has had a chance to think about it and provide feedback, and then go from there. -- Joshua C. Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org _______________________________________________ asterisk-app-dev mailing list asterisk-app-...@lists.digium.com http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
