asterisk 1.8 ringall strategy in queues causes non-answering agents to exit out of Dial() even with 'g' option
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
asterisk (Ubuntu) |
New
|
Medium
|
Unassigned |
Bug Description
In asterisk 1.8, calls to queues with a 'ringall' strategy will kill
the Dial() of all non-answering agents as soon as another agent
answers. This kill doesn't respect the 'g' option given to Dial(),
i.e. control is never returned to the dialplan. This appears to be a
regression from asterisk 1.4 which didn't have this behaviour.
It breaks our use of asterisk as we set database variables to reflect
the 'offhook' status of agents, and need to be able to unset them once
the agent's extension is no longer being rung/in use but we can't do
that if Dial() doesn't reliably return control to the dialplan.
Here's some log snippets to demonstrate the problem:
| -- Executing [s@macro-
| -- Executing [s@macro-
Notice the 'g' option to both dial commands.
| -- Local/1008@
| -- Local/1008@
| -- Local/1008@
| -- Local/1002@
| -- Local/1008@
| -- Local/1002@
| -- Local/1002@
| -- Local/1002@
| -- SIP/8916-0000dcc2 answered Local/1008@
| -- Local/1008@
| -- Local/1008@
Here, 1008 answers.
| == Spawn extension (macro-queueexten, s, 4) exited non-zero on 'Local/
The 1002 macro dies, but does not execute the 'h' extension or in any
other way return control to the dialplan as requested.
| -- Executing [h@macro-
Whereas 1008 does execute 'h'.
| == Spawn extension (macro-queueexten, s, 4) exited non-zero on 'Local/
Sounds like a bug to me. Some thoughts for workarounds. Could ${EXTENSION_ STATE(. ..)}) (when using hints) or ${SIPPEER( ...,curcalls) } (if using SIP and call-limit) help you here? 1.6 brought in lots of new shiny stuff like this which eliminated the need for various similar hacks I had to use in previous versions.