[asterisk-bugs] [Asterisk 0014527]: Queue members associated with ZOMBIE channels (breaks wrapuptime and queue_log).
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Mar 3 16:22:15 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14527
======================================================================
Reported By: kebl0155
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14527
Category: Applications/app_queue
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: 1.6.0.3
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-02-23 06:26 CST
Last Modified: 2009-03-03 16:22 CST
======================================================================
Summary: Queue members associated with ZOMBIE channels
(breaks wrapuptime and queue_log).
Description:
In some circumstances, queue members become associated with a ZOMBIE
channel during the answer process.
When the ZOMBIE channel is hung up under normal clearing as part of the
answer process, an AgentComplete event is generated, and the wrapuptime
counter is set, even though the agent is still on a call. The queue_log
entry is also written at this time with just 1 second of talk time.
No further AgentComplete event is generated when the call comes to an end.
The wrapuptime is then counted from the start of the call, not the end of
the call.
======================================================================
----------------------------------------------------------------------
(0101140) mmichelson (administrator) - 2009-03-03 16:22
http://bugs.digium.com/view.php?id=14527#c101140
----------------------------------------------------------------------
Allow me to explain what is happening here. The cause of this is that the
incoming call to the queue is on a Local channel. When the channel is
answered by a queue member, the Local channel optimizes itself out of the
equation. The queue application sees this as a hangup of the incoming
channel and thus treats the situation as the end of a call.
Fixing this in the code is not going to be an easy thing at all. In fact,
I would say that anyone who takes on this bounty is going to run into lots
of trouble when attempting to fix this in the code. As you have found,
using the /n flag at the end of a Local channel will cause the
aforementioned optimization not to occur. Another possible fix you could
explore is to avoid using a Local channel as the incoming channel for the
queue if it can be done. I realize that what you have posted is pretty much
a toy example which illustrates the point, so asking for such dialplan
changes in your actual dialplan will probably be more difficult. An
alternative to dialing a local channel would be to use Goto's in the
dialplan if possible.
Issue History
Date Modified Username Field Change
======================================================================
2009-03-03 16:22 mmichelson Note Added: 0101140
======================================================================
More information about the asterisk-bugs
mailing list