ARI Application Execution Feature Survey

Home » Uncategorized » ARI Application Execution Feature Survey
Uncategorized 8 Comments

Hi Asterisk users,

I’m one of Asterisk ARI users, and trying to designing the new ARI for application execution in Stasis().

This will be made possible for executing the applications in the Stasis() application.

But, before going further, I would like to know which application needs to be considered.

Because this feature will introduce new Stasis behavior, I would like to test the applications as many as possible before submitting the code. However, I can’t test all of them, so I would like to make a priority and list.

If you want to use your favorite application with this feature, please reply this. I will add to the list. 🙂

Btw, I’m considering the app_amd, app_queue for myself. 🙂

For more detail of this feature, you can see it here. http://lists.digium.com/pipermail/asterisk-dev/2019-April/077270.html

Thank you.

Kind regards, Sungtae

8 thoughts on - ARI Application Execution Feature Survey

  • 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.

    —
    Joshua C. Colp Digium – A Sangoma Company | Senior Software Developer
    445 Jan Davis Drive NW – Huntsville, AL 35806 – US
    Check us out at: http://www.digium.com & http://www.asterisk.org

  • 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.

  • Ideally for AMD I think this would be preferred.

    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: http://www.digium.com & http://www.asterisk.org

  • 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: http://www.digium.com & http://www.asterisk.org