[Home]

Summary:ASTERISK-05112: agent wrapuptime not working across queues
Reporter:mike9 (mike9)Labels:
Date Opened:2005-09-19 08:57:34Date Closed:2008-01-15 15:50:23.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_agent
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_agent.diff
( 1) full
( 2) full1
( 3) logger.rtf
( 4) nowrapup2.rtf
( 5) nowrapup3.rtf
Description:in agents.conf: wrapuptime=15000 (15 sec)
Agent 'A' is a member of queues 1 & 2.

If (callback) agent 'A' takes a call on 'queue_1', and hangs up, if there is another caller in 'queue_1', there will be a 15 second wait before agent 'A' is rung again. If there is a caller in queue_2, agent 'A' will be rung immediately after hangup from previous call.

****** ADDITIONAL INFORMATION ******

callback agent wrapuptime was working correctly in STABLE. I am not sure if wrapuptime is working correctly for off-hook agents.

This issue has been present for at least 3 weeks.

This behaviour is the same whether the new queue wrapuptime is used or not.
Comments:By: Jennifer Hales (jennifer hales) 2005-09-25 19:13:45

I am also experiencing this problem.  I have multiple queues and agents associated with more than one queue.  These agents do not get wrapuptime if they are recieving calls from different queues, however they do get wrapuptime if they are recieving calls from the same queue.
By: Michael Jerris (mikej) 2005-09-25 20:22:58

Can anyone identify based on using checkout of cvs by date when this was broken in cvs?
By: Kevin P. Fleming (kpfleming) 2005-09-25 20:39:24

I don't see how this can be working this way... chan_agent is not aware of the source of _any_ calls to agents, whether they come from queues or direct calls via Dial().

Please do some simple testing using Dial(Agent/...) to determine whether the wrapuptime is working properly on your system, or if the delay you are seeing is being introduced via other means.
By: Jennifer Hales (jennifer hales) 2005-09-26 17:27:14

When I do Dial(Agent/....) the wrapuptime is working as identified below.

 == Spawn extension (test, s, 4) exited non-zero on 'SIP/3153-56d5'
   -- Executing Answer("SIP/3153-764b", "") in new stack
   -- Executing Goto("SIP/3153-764b", "test|s|1") in new stack
   -- Goto (test,s,1)
   -- Executing Wait("SIP/3153-764b", "1") in new stack
   -- Executing Set("SIP/3153-764b", "CALLERID(name)=Test") in new stack
   -- Executing Set("SIP/3153-764b", "SPYGROUP=cs") in new stack
   -- Executing Dial("SIP/3153-764b", "Agent/4021") in new stack
Sep 27 08:21:19 NOTICE[14974]: app_dial.c:1091 dial_exec_full: Unable to create channel of type 'Agent' (cause 17 - User busy)
 == Everyone is busy/congested at this time (1:1/0/0)
   -- Executing Hangup("SIP/3153-764b", "") in new stack
 == Spawn extension (test, s, 5) exited non-zero on 'SIP/3153-764b'

However it still does not work when calls come from different queues.

Hope this is of some help.
Regards
Jenn
By: Kevin P. Fleming (kpfleming) 2005-09-26 19:21:04

I'll need to see a complete trace of this problem occurring.
By: Jennifer Hales (jennifer hales) 2005-09-27 17:28:13

What traces do you want exactly?  I am happy to provide what ever you need.
By: Michael Jerris (mikej) 2005-09-27 21:58:51

perferabally a trace of the agent answering the first call to queue1, then the second call to queue 2 before the wrap time is complete.
By: Kevin P. Fleming (kpfleming) 2005-09-29 00:07:46

Right, with 'set verbose 10', 'set debug 10' and the output captured via the 'full' logger file.
By: Jennifer Hales (jennifer hales) 2005-10-03 17:54:05

Attached is the information you required. The logger.rtf is everything that happened since I got in this morning, sorry if it is a bit big but more information is better than not enough.  This problem is intermittent also.  It only pressents itself when we are very busy.  The wrapuptime is working when we are not so busy.
By: Kevin P. Fleming (kpfleming) 2005-10-04 19:28:30

Unfortunately that is only the debug log, not the combined one, so there is no way to see what is really happening.

Can you reproduce this problem at will? If so, the best course of action will likely be for one of us to get remote access to your system and try to debug the problem.
By: BJ Weschke (bweschke) 2005-10-05 11:52:27

Reproduced with the required data.

The first call from bjq works fine.

The second call from bjq2 also works OK as it does wait the expected wrapuptime.

The third call from bjq doesn't work as the wrapuptime from the call from bjq2 shouldn't have expired yet but the call is delivered immediately.
By: BJ Weschke (bweschke) 2005-10-05 14:53:55

If p->lastdisc is getting set within agent_hangup, the acknowledged flag has already been set to 0 at the beginning of the function so we must not look at that value to determine whether or not the wrapuptime should be incremented onto p->lastdisc. patch attached against current HEAD.
By: Jennifer Hales (jennifer hales) 2005-10-05 17:22:39

Sorry about not sending the full file last time.  Here it is from today, we got it to fail twice.
By: Kevin P. Fleming (kpfleming) 2005-10-05 17:32:35

That is certainly a valid fix, but it may not be the source of this problem. I've committed it to CVS HEAD regardless, and if this problem persists please request this bug to be reopened.
By: Digium Subversion (svnbot) 2008-01-15 15:50:23.000-0600

Repository: asterisk
Revision: 6736

U   trunk/channels/chan_agent.c

------------------------------------------------------------------------
r6736 | kpfleming | 2008-01-15 15:50:22 -0600 (Tue, 15 Jan 2008) | 2 lines

don't check 'acknowledged' for setting lastdisc, since it's guaranteed to be zero at this point (issue ASTERISK-5112)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6736