Hi,
if a channel is in a queue, is there some AMI command to force the Queue application to fail? I don’t want to use channel redirect, I want channel to continue into the dialplan as if Queue application timed out.
Hi,
if a channel is in a queue, is there some AMI command to force the Queue application to fail? I don’t want to use channel redirect, I want channel to continue into the dialplan as if Queue application timed out.
You can read the context, extension, and priority and channel redirect to those. Unfortunately I’m not sure that it is possible to read the priority, so you may have to know it.
Otherwise your only option is to hang up the channel, which will really hang things up. Actually even the channel redirect involves might involve a hang up. That is certainly how it used to work. The difference is that the technology specific channel was swapped into a new channel, before the hang up, so that the channel that was hung up had no physical channel associated with it.
Your basic problem is that the application has to detect the condition that causes it to terminate, explicitly, and the only thing it will be looking for are hangups and the results of things it did itself, like timeouts.
Queue application is called from AGI, so there is no priority to jump to. It is possible to re-run channel through AGI and somehow skip to the point right after Queue app was called, but it is not simple, so I was hoping to avoid it. But, based on your info, there is no other option. Thanks for your reply, David.
On second thought, it’s probably the easiest to patch app_queue.c to check the value of some variable at the same time it checks for timeout. Then it’s as simple as setting that variable from AMI. I think I’ll do that.
It wasn’t as straightforward as I thought, due to considerable complexity of app_queue, but It wasn’t too much trouble. Works fine.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.