[Home]

Summary:ASTERISK-09889: ACD Agent reported as busy when avalible
Reporter:Doug (doug)Labels:
Date Opened:2007-07-17 04:10:38Date Closed:2007-08-16 20:05:55
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_agent
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:We have a problem where Agents are reported as "busy" and will show this way untill running a "reload app_queues.so" from the CLI. ACD status's are the reset and show true values. This causes incoming calls to the ACD to stay in the queue as all agents are eventualy marked as "busy".

in the below example you will see agents 4387 and 370 showing as "in use" but a show channels will show no such calls. This will eventualy happen on all agents making the queue usless.

Asterisk versions 1.2.20 and 1.2.21

sol*CLI> show queues
default      has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 0s
  No Members
  No Callers

default-uitb has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 60s
  Members:
     Local/4408@default-agent/n (dynamic) (Not in use) has taken no calls yet
     Local/4449@default-agent/n (dynamic) (Not in use) has taken no calls yet
  No Callers

default-svs  has 0 calls (max unlimited) in 'ringall' strategy (3s holdtime), W:0, C:2, A:2, SL:100.0% within 60s
  No Members
  No Callers

default-alge has 0 calls (max unlimited) in 'fewestcalls' strategy (8s holdtime), W:0, C:11, A:32, SL:90.9% within 60s
  Members:
     Local/4370@default-agent/n (dynamic) (In use) has taken 4 calls (last was 7652 secs ago)
  No Callers

default-arbe has 0 calls (max unlimited) in 'rrmemory' strategy (6s holdtime), W:0, C:10, A:21, SL:100.0% within 60s
  Members:
     Local/4387@default-agent/n (dynamic) (In use) has taken 5 calls (last was 370 secs ago)
     Local/4371@default-agent/n (dynamic) (Not in use) has taken 5 calls (last was 1944 secs ago)
  No Callers

default-lede has 0 calls (max unlimited) in 'fewestcalls' strategy (11s holdtime), W:0, C:7, A:31, SL:85.7% within 60s
  Members:
     Local/4370@default-agent/n (dynamic) (In use) has taken 3 calls (last was 2988 secs ago)
  No Callers

sol*CLI> show channels
Channel              Location             State   Application(Data)
Zap/2-1              s@all-default-defaul Up      Bridged Call(Zap/33-1)
Zap/33-1             0739071280@zap-incom Up      Dial(Zap/g1/0739071280|300)
2 active channels
1 of 255 max active call ( 0.39% of capacity)
 == Parsing '/etc/asterisk/manager.conf': Found
Comments:By: Mark Michelson (mmichelson) 2007-07-17 11:02:15

This could be related to issue ASTERISK-9337, which I have fixed in 1.2. It will be in 1.2.22, which will be released very soon. If you need to fix this immediately, you can svn update to the latest version of 1.2, which will have the fix I made.

If this does not fix your issue, then please make it known.
By: Doug (doug) 2007-07-18 08:19:43

We are not using chan_agent, we are using chan_local and and AgentCalLBackLogin. This patch seems only to apply to chan_agent?
By: Mark Michelson (mmichelson) 2007-07-20 11:48:25

Sorry for the delay, but yes the patch for issue ASTERISK-9337 does affect agents logged in via AgentCallbackLogin. 1.2.22 has been released and the fix has been integrated in. I suggest upgrading to 1.2.22. If the issue does not go away, then report back here saying so and I'll investigate further.
By: Mark Michelson (mmichelson) 2007-07-30 12:40:33

It's been a week now and I was wondering if 1.2.22 had solved the problem for you or if you're still having issues?
By: Jason Parker (jparker) 2007-07-31 11:20:04

Can this issue be reproduced on 1.4?

Once 1.2 goes into maintenance mode (scheduled for tomorrow - August 1st), all issues that only affect 1.2 may be closed.
By: Nick Baker (javasensai) 2007-07-31 11:37:26

I'm experiencing the same Busy agents issue with 1.4.9
By: Mark Michelson (mmichelson) 2007-07-31 16:43:05

All right, well it looks like this issue is still alive then. In order to fix this, though, I will need to see console debug output so I can see when it is that the agents' states get changed and when it is that the agent gets stuck busy.
By: Konrad Rozycki (krdian) 2007-08-14 09:34:24

I've found the same issue with 1.4.10.1. I'll send debug later.
By: BJ Weschke (bweschke) 2007-08-15 09:34:41

Can the folks posting that this is happening on 1.4 post some configs as to how they're ringing agents so we can try and reproduce on some test systems?
By: BicomSystems Ltd. (fkasumovic) 2007-08-16 03:08:53

This problem is caused by agent wrapuptime (agents.conf)
and "ring in use" patch  http://bugs.digium.com/view.php?id=6315
when ring in use is set to no.
Default value for agent wrapuptime is 5 seconds, if agent receive next call in
that period , when app queue executes ring_entry(...) function ast_request(...) will return busy status next function update_dial_status(...) will apply this status to queue member and there you are with status "Busy", when ever ring in use check is made it will get that member is busy and never call it.
If you set ringinuse (queues.conf) yes, or wrapuptime (agents.conf) to 0 [ms], this will not happen.
Please fix it :).

Faruk.
By: Mark Michelson (mmichelson) 2007-08-16 14:39:21

Using fkasumovic's information, I have duplicated the behavior on a local machine, which means hopefully I will have a fix somewhat soon.

Thank you very much for the information!
By: Digium Subversion (svnbot) 2007-08-16 15:58:49

Repository: asterisk
Revision: 79748

------------------------------------------------------------------------
r79748 | mmichelson | 2007-08-16 15:58:49 -0500 (Thu, 16 Aug 2007) | 8 lines

Fixes a problem where agents would get stuck busy due to their wrapuptime being longer than the queue's wrapuptime and
ringinuse=no for the queue.

(closes issue ASTERISK-9889, reported by Doug, repaired by me)

Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!


------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-16 16:03:49

Repository: asterisk
Revision: 79749

------------------------------------------------------------------------
r79749 | mmichelson | 2007-08-16 16:03:47 -0500 (Thu, 16 Aug 2007) | 16 lines

Merged revisions 79748 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79748 | mmichelson | 2007-08-16 16:16:40 -0500 (Thu, 16 Aug 2007) | 8 lines

Fixes a problem where agents would get stuck busy due to their wrapuptime being longer than the queue's wrapuptime and
ringinuse=no for the queue.

(closes issue ASTERISK-9889, reported by Doug, repaired by me)

Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!


........

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-16 20:05:55

Repository: asterisk
Revision: 79825

------------------------------------------------------------------------
r79825 | file | 2007-08-16 20:05:53 -0500 (Thu, 16 Aug 2007) | 106 lines

Merged revisions 79747,79749,79755,79764,79788,79794,79813,79824 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r79747 | tilghman | 2007-08-16 18:09:46 -0300 (Thu, 16 Aug 2007) | 2 lines

Don't reload a configuration file if nothing has changed.

................
r79749 | mmichelson | 2007-08-16 18:21:35 -0300 (Thu, 16 Aug 2007) | 16 lines

Merged revisions 79748 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79748 | mmichelson | 2007-08-16 16:16:40 -0500 (Thu, 16 Aug 2007) | 8 lines

Fixes a problem where agents would get stuck busy due to their wrapuptime being longer than the queue's wrapuptime and
ringinuse=no for the queue.

(closes issue ASTERISK-9889, reported by Doug, repaired by me)

Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!


........

................
r79755 | file | 2007-08-16 18:28:50 -0300 (Thu, 16 Aug 2007) | 2 lines

Fix properties on trunk again.

................
r79764 | russell | 2007-08-16 18:33:38 -0300 (Thu, 16 Aug 2007) | 19 lines

Merged revisions 79756 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79756 | russell | 2007-08-16 16:29:24 -0500 (Thu, 16 Aug 2007) | 11 lines

Fix more deadlocks in chan_iax2 that were introduced by making frame handling
and scheduling multi-threaded.  Unfortunately, we have to do some expensive
deadlock avoidance when queueing frames on to the ast_channel owner of the IAX2
pvt struct.  This was already handled for regular frames, but ast_queue_hangup
and ast_queue_control were still used directly.  Making these changes introduced
even more places where the IAX2 pvt struct can disappear in the context of a
function holding its lock due to calling a function that has to unlock/lock it
to avoid deadlocks.  I went through and fixed all of these places to account for
this possibility.
(issue ASTERISK-10007, patch by me)

........

................
r79788 | russell | 2007-08-16 19:30:39 -0300 (Thu, 16 Aug 2007) | 22 lines

Merged revisions 79778 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79778 | russell | 2007-08-16 17:24:25 -0500 (Thu, 16 Aug 2007) | 14 lines

This patch fixes a bug where reloading the module with "module reload" did not
delete classes from memory that were no longer in the config.  This patch fixes
that problem as well as another one.  Previously, if you reloaded MOH using the
"moh reload" CLI command, which behaved differently than "module reload ...",
MOH had to be stopped on every channel and started again immediately.  However,
there was no way to tell what class was being used, so they would all fall back
to the default class.

(closes issue ASTERISK-9825)
Reported by: blitzrage
Patches:
     asterisk-10139-advanced.diff.txt uploaded by jamesgolovich (license 176)
Tested by: jamesgolovich

........

................
r79794 | russell | 2007-08-16 19:33:02 -0300 (Thu, 16 Aug 2007) | 12 lines

Merged revisions 79792 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79792 | russell | 2007-08-16 17:32:33 -0500 (Thu, 16 Aug 2007) | 4 lines

Fix a little race condition that could cause a crash if two channels had MOH
stopped at the same time that were using a class that had been marked for
deletion when its use count hits zero.

........

................
r79813 | tilghman | 2007-08-16 20:31:14 -0300 (Thu, 16 Aug 2007) | 2 lines

Revise dialplan locks to permit multiple locks per channel, but with deadlock avoidance

................
r79824 | file | 2007-08-16 22:19:04 -0300 (Thu, 16 Aug 2007) | 2 lines

Fix building of chan_zap under development mode without libpri and libss7 installed.

................

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