At the company I work for (https://www.wave.com/en/) we run our support call center on Asterisk’s queue application. I’d like to give our backend the ability to pause/unpause queue members, but more generally, I’m interested in learning how to imperatively trigger some dialplan from our backend (basically RPC-style). I have a working prototype using ARI, but I’m just getting started learning Asterisk and my approach feels a little weird, so I’d love to get some feedback!
The way I’ve done things is to POST to the “/channels” API (https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Channels+REST+API) with an “endpoint” argument of the form “Local/extension@context”. This does indeed run context's extension, but I also have to pass an “app” argument (or a “context” + “extension” etc.), or else I get a 400 response due to “Invalid parameters for originating a channel”. I’m currently just passing “NoOp” as my app argument, which seems to work, but, I don’t know, it feels hacky.
Is there a different way I could/should be thinking about this?
You would generally want to use /n, to inhibit optimisation, which would terminate the local channel dialplan once any call bridged.
However, my feeling is that ARI is the wrong technology for this. AMI would be better, although it is not perfect, as, whilst you can force a transfer of control, you cannot force a pure subroutine call. ARI is a first party control technology, and requires the dialplan to be running the stasis application,for the whole duration of the call, but AMI is third party control, and your requirement seems to be for third party control.
If you have to pass parameters to local channels, you can do by setting them as channel variables, or embedding them in the extension name, and parsing them out. Both ways are effectively pass by value, although there are ways of writing values into variables on other channels.
Any forced transfer of control of the channel itself will, more or less, abruptly terminate any dialplan application currently running on it.
Ah, ok! I had glossed over AMI since I thought it was subsumed by ARI, but looking at it more closely I see what you mean (or at any rate, AMI already has built-in actions for pausing/unpausing queue members). Thank you for the tip
