Summary:	ASTERISK-11577: Agent status in queues
Reporter:	Doug (doug)	Labels:
Date Opened:	2008-03-05 06:00:30.000-0600	Date Closed:	2008-03-05 12:17:46.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	In CLI using show queues command I will often get diferent status for same agents on seperate queues. I believe the way the queue works is the following: Status = "Unknown" or "Not In USe" (the queue will pass calls to agents) Status = "Ringing", "In use" or "Paused" (the queue stops passing calls) Now this is correct however I have where there are 2 queues setup with different Agents and the status of the Agent is not the same in both queues (see below). The problem is that in 1 queue the Agent shows as "In Use" and the other "Unknown" and therefore calls will be passed to the queue and agent that shows as "Unknown" even though the Agent is on a call. This causes a return of "Circut-Busy" and adds a CDR with No-Answer. This will cause a mass amount of CDR's that are usless and end up with millions of these entries in the database of Master.csv. When using a mysql database this causes lookups to be very slow due to the masses of CDR's. Can anyone explain why we have "unknown" status or how we can stop this status showing a different value on seperate queues? Thanks ****** ADDITIONAL INFORMATION ****** Show Queues: default-nash has 0 calls (max unlimited) in 'random' strategy (21s holdtime), W:0, C:3, A:1, SL:66.7% within 60s  Members:   Local/5008@default-agent/n (dynamic) (paused) (Not in use) has taken no calls yet   Local/5005@default-agent/n (dynamic) (In use) has taken 2 calls (last was 5070 secs ago)   Local/5006@default-agent/n (dynamic) (In use) has taken 1 calls (last was 616 secs ago)   Local/5007@default-agent/n (dynamic) (Ringing) has taken no calls yet  No Callers default-rapa has 2 calls (max unlimited) in 'random' strategy (31s holdtime), W:0, C:55, A:40, SL:76.4% within 60s  Members:   Local/5008@default-agent/n (dynamic) (paused) (Not in use) has taken 10 calls (last was   Local/5005@default-agent/n (dynamic) (Unknown) has taken 17 calls (last was 260 secs ag   Local/5006@default-agent/n (dynamic) (Unknown) has taken 4 calls (last was 15 secs ago)   Local/5007@default-agent/n (dynamic) (Unknown) has taken 10 calls (last was 72 secs ago   Local/5078@default-agent/n (dynamic) (Unknown) has taken 11 calls (last was 612 secs ag  Callers:   1. Zap/18-1 (wait: 1:39, prio: 0)   2. Zap/2-1 (wait: 0:17, prio: 0) Attempt on busy Agent: - Executing [5006@default-agent:1] NoCDR("Local/5006@default-agent-4d2c,2", "") in new stack  -- Executing [5006@default-agent:2] Set("Local/5006@default-agent-4d2c,2", "DND=") in new stack  -- Executing [5006@default-agent:3] GotoIf("Local/5006@default-agent-4d2c,2", "0?20") in new stack  -- Executing [5006@default-agent:4] GotoIf("Local/5006@default-agent-4d2c,2", "1?7") in new stack  -- Goto (default-agent,5006,7)  -- Executing [5006@default-agent:7] Set("Local/5006@default-agent-4d2c,2", "GROUPCOUNT=1") in new stack  -- Executing [5006@default-agent:8] GotoIf("Local/5006@default-agent-4d2c,2", "1?20") in new stack  -- Goto (default-agent,5006,20)  -- Executing [5006@default-agent:20] Congestion("Local/5006@default-agent-4d2c,2", "") in new stack  -- Local/5006@default-agent-4d2c,1 is circuit-busy  -- Nobody picked up in 0 ms
Comments:	By: Doug (doug) 2008-03-05 07:33:58.000-0600 NB we are using the stateinterface patch (bug 11603) By: Doug (doug) 2008-03-05 08:27:15.000-0600 I found a similar ticket with no resolution allthough closed due to reporter not being able to do testing. http://bugs.digium.com/view.php?id=10605 By: Mark Michelson (mmichelson) 2008-03-05 12:17:44.000-0600 state_interface is not officially supported in 1.4. I have no idea what your backport entails, so I have no idea if there is an error there or somewhere else. I am closing this issue since the report is against an unsupported feature of 1.4. If the same behavior happens with 1.4 without the state_interface backport or if the problem happens in trunk, please feel free to reopen.