Detecting missing Queue exit events

Detecting missing Queue exit events

On some version of Asterisk, there are conditions when an unanswered call would exit the queue without leaving a trace of its exiting in the queue_log, therefore generating incomplete call processing events that lead reporting software like ​​QueueMetrics​​ to produduce inaccurate results.

You will notice this if you encounter pieces of the queue_log that look like the following example:

1167421685|1169421668.34679|qname|NONE|ENTERQUEUE||5555551234

1167099900|1169099887.31480|qname|NONE|ENTERQUEUE||5555551234

1168222540|1168222529.5949|qname|NONE|ENTERQUEUE||5555551234

Here you can see that the caller-id 5555551234 entered the queue three times in a row but its exiting statuses were never recorded.

To solve this problem, it is important to know why the queue was exited without response, and this can be obtained with a sample piece of the dialplan like the following:

exten => s,1,queue(myqueue)

exten => s,2,System( echo "${EPOCH}|${UNIQUEID}|myqueue|NONE|EXITCODE|${QUEUESTATUS}" >> /var/log/asterisk/queue_log )

exten => h,1,System( echo "${EPOCH}|${UNIQUEID}|myqueue|NONE|EXITHANGUP|${QUEUESTATUS}" >> /var/log/asterisk/queue_log )

You should leave this code running for a while and then review the queue_log manually for traces of ENTERQUEUEs followed only by EXITCODE and EXITHANGUP records. They will be followed by the condition causing the problem, like TIMEOUT, FULL, JOINEMPTY, LEAVEEMPTY, JOINUNAVAIL, or LEAVEUNAVAIL.

After you have this information, you can know how to modify the dialplan to record a fake queue end entry, therefore producing a valid queue_log file.

Note: version 1.4 of Asterisk should finally be unaffected by this problem.

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。