[asterisk-bugs] [Asterisk 0016519]: Queue with wrapuptime "call" agent that shouldn't have any call

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16519 
====================================================================== 
Reported By:                benngard2
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16519
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-1139 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-12-28 09:16 CST
Last Modified:              2010-04-26 04:53 CDT
====================================================================== 
Summary:                    Queue with wrapuptime "call" agent that shouldn't
have any call
Description: 
I did some tests on Asterisk SVN-trunk-r234256.

extensions.conf
exten =>
0317998989,1,ExecIf($[${DB_EXISTS(CFIM/0317998989)}]?Goto(${DB(CFIM/0317998989)},1)
exten =>
0317998989,2,ExecIf($[${QUEUE_MEMBER(0317998989,logged)}=0]?Dial(H323/900 at Avaya))
exten => 0317998989,3,Answer()
exten => 0317998989,4,Queue(0317998989,rt)
exten => 0317998989,5,Hangup()
exten => 989,1,Goto(0317998989,1) <- just for lazy people in our company

queues.conf
[general]
autofill=yes
keepstats=yes
[0317998989]
retry=5
strategy=rrmemory
timeout=20
wrapuptime=120

agents.conf
[general]
persistentagents=yes
[agents]
agent => 0317998971,1234,Stefan Andersson
agent => 0317998972,1234,Kerem Tubluk
agent => 0317998975,1234,Magnus Benngard
agent => 0317998976,1234,Jimmy Beckman

Logging in agents through a manager script, sample output from cli:
sip*CLI> queue show 0317998989
0317998989   has 0 calls (max unlimited) in 'rrmemory' strategy (17s
holdtime, 59s talktime), W:0, C:7, A:2, SL:0.0% within 0s
   Members:
      SIP/0317998975 with penalty 2 (dynamic) (Not in use) has taken no
calls yet
      SIP/0317998976 with penalty 1 (dynamic) (Not in use) has taken 7
calls (last was 2564 secs ago)
   No Callers
If I call the queue, 0317998976 will ofc get the call but when we hang up
and I call within 120 seconds, 0317998976 will still get the call.

Shouldn't that second call go to 0317998975?
====================================================================== 

---------------------------------------------------------------------- 
 (0120882) lvl (reporter) - 2010-04-26 04:53
 https://issues.asterisk.org/view.php?id=16519#c120882 
---------------------------------------------------------------------- 
We also encountered issues with WRAPUPTIME suddenly not being respected
anymore. Eventually, I've traced it down to the following: it breaks as
soon as you do a 'queue reset stats', or a 'queue reload'. I believe this
is due to the following function in app_queue.c:

static void clear_queue(struct call_queue *q)
{
	q->holdtime = 0;
	q->callscompleted = 0;
	q->callsabandoned = 0;
	q->callscompletedinsl = 0;
	q->wrapuptime = 0;
	q->talktime = 0;

	if (q->members) {
		struct member *mem;
		struct ao2_iterator mem_iter = ao2_iterator_init(q->members, 0);
		while ((mem = ao2_iterator_next(&mem_iter))) {
			mem->calls = 0;
			ao2_ref(mem, -1);
		}
		ao2_iterator_destroy(&mem_iter);
	}
}

Because of the line "q->wrapuptime = 0", the wrapuptime for the queue is
permanently set to 0 as soon as this function is called. I think the
solution is to remove that line, and instead set mem->lastcall = 0 inside
the member iterator. 

I'm not too familiar with the asterisk sourcecode though, so I'll let
someone with more experience submit a patch. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-26 04:53 lvl            Note Added: 0120882                          
======================================================================