Affects Version/s: None
Target Release Version/s: None
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.
- ADDITIONAL INFORMATION ******
This seems to happen whenever multiple levels of Local channels and/or bridging are used to connect agent and caller. Here's an example dialplan that will reproduce this error.
exten => 1,1,Answer
exten => 1,2,Dial(Local/plainae@test)
exten => 12345,1,Dial(SIP/12345)
exten => plainae,1,Queue(PlainAE)
We have one agent as a member of the queue:
queue add member Local/12345@main to PlainAE
When a call is placed from SIP/12344 to extension 1, a local channel dials the queue. The queue dials a second local channel to reach the agent, listening on SIP/12345. When the agent answers, both local channels are masqueraded out.
When the agent is called, an AgentCalled event is generated:
This is as it should be. When the call is answered, an AgentConnect event is generated:
This is also as it should be.
As the local channels are masqueraded out, a complex sequence of Bridge, Masquerade and Rename events are generated (see attached log).
Having had a look at the Manager stream of events, it appears that the Rename events are being followed, but not the Masquerade or Bridge events. The agent should be left as associated with the SIP channel for the agent's phone (SIP/12345-0825c248 in this case). Instead, it's eventually associated with Local/plainae@test-c6d0;1<ZOMBIE>, which is one of the leftover channels from the bridge/masquerade sequence.
So, when this channel is hung up as part of the normal clearing process, the following event is generated:
This is coming way too early - we shouldn't get one of these until either the agent or caller hangs up the phone. The wrapuptime counter is also set at this time (instead of the end of the call as it should be). The call is also written as complete in the queue_log, with just one second of talk time.
Finally, when the call ends, we get two Hangup events:
Cause-txt: Normal Clearing
Cause-txt: Normal Clearing
This is when the AgentComplete event should be fired off, however there is no such event because the queue system thinks the call has already ended.
I have attached a full capture of the Manager events associated with this broken process.
This happens with both the 1.6 and 1.4 release groups (I haven't checked 1.2).
A quick fix would be to prevent the system from following Rename events where the Newname: field ends with <MASQ>. This would leave the queue member associated with the correct channel at the end of the bridging process.
I did take a look at the app_queue code, but couldn't work out where to start with implementing this (sorry!)...