asterisk users - Apr 2019 - [asterisk-app-dev] ARI application execution feature survey

On Tue, Apr 2, 2019 at 4:18 PM Joshua C. Colp <jcolp at 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.

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.

-- 
*Matthew Jordan*
Digium - A Sangoma Company | Senior Vice President, Software and Services |
Engineering
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
<https://maps.google.com/?q=445+Jan+Davis+Drive+NW+-+Huntsville,+AL+35806+-+US&entry=gmail&source=g>
direct: +1 256 428 6107
Check us out at: https://digium.com · https://sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190402/a01e7b58/attachment.html>
-------------- next part --------------
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev at lists.digium.com
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

On Tue, Apr 2, 2019, at 8:26 PM, Matthew Jordan wrote:
> 
> 
> On Tue, Apr 2, 2019 at 4:18 PM Joshua C. Colp <jcolp at 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.

-- 
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-dev at lists.digium.com
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

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 <jcolp at
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.
>
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev at lists.digium.com
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev