[asterisk-bugs] [Asterisk 0016775]: Queue with autofill=no and strategy=ringall sometimes rings non-oldest caller through to agents
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Feb 5 16:15:54 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16775
======================================================================
Reported By: tbpsn
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16775
Category: Applications/app_queue
Reproducibility: random
Severity: minor
Priority: normal
Status: new
Asterisk Version: Older 1.4 - please test a newer version
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-02-04 14:47 CST
Last Modified: 2010-02-05 16:15 CST
======================================================================
Summary: Queue with autofill=no and strategy=ringall
sometimes rings non-oldest caller through to agents
Description:
I'm experiencing a possible bug in 1.4.26 x86_64 with app_queue. I have a
queue set to strategy=ringall and autofill=no, but I am seeing autofill
behavior (non FIFO), with latter callers ringing through before the oldest
caller has been answered.
Example: A caller sits on hold for 2 minutes (due to all agents being
busy), then a new caller enters the queue. An agent becomes free, and as
it happens, the newer caller (with a shorter hold time) rings through to
the agent and the call is answered, leaving the caller with the longest
hold time still unserviced.
Reviewing the logs, it's clear that asterisk is correctly retrying to send
the oldest caller through at the correct interval. It just looks like the
newer caller seems to have squeezed through, and happened to be answered
first.
My queue definition is listed in 'Additional Information'
======================================================================
----------------------------------------------------------------------
(0117806) tbpsn (reporter) - 2010-02-05 16:15
https://issues.asterisk.org/view.php?id=16775#c117806
----------------------------------------------------------------------
I was able to complete further analysis on this issue today. What I found
is that certain callers in the queue are essentially getting 'stuck'. They
sit in the queue, but do not ring out to the agents.
Below is an example of a new call coming through and being pushed out to
agents right away, even though there were two 'stuck' calls ahead of it.
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: queue: 400, options: t, url: ,
announce: , expires: 0, priority: 0
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: Queue 400 has no realtime
members defined. No need for update
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: Queue '400' Join, Channel
'SIP/SIPtrunk-c403ed30', Position '3'
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: There is 1 available member.
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: It's our turn
(SIP/SIPtrunk-c403ed30).
[Feb 5 12:59:19] DEBUG[5601] app_queue.c: SIP/SIPtrunk-c403ed30 is trying
to call a queue member.
You see the queue module realize that the new call is caller 3.
Confusingly though, its the calls 'turn' immediately after, even though
callers 1 and 2 handn't been picked up yet.
Here is a separate example of the same behavior. This is the output of
'queue show' when we were having an issue with one stuck caller:
400 has 3 calls (max unlimited) in 'ringall' strategy (13s
holdtime), W:0, C:333, A:26, SL:0.0% within 0s
Members:
Local/507 at from-internal/n (In use) has taken 25 calls (last was 127
secs ago)
Local/506 at from-internal/n (Not in use) has taken no calls yet
Local/505 at from-internal/n (In use) has taken 11 calls (last was
59499 secs ago)
Local/504 at from-internal/n (Not in use) has taken 35 calls (last was
6830 secs ago)
Local/503 at from-internal/n (Not in use) has taken 47 calls (last was
8062 secs ago)
Local/502 at from-internal/n (Not in use) has taken 40 calls (last was
7349 secs ago)
Local/501 at from-internal/n (In use) has taken 17 calls (last was 815
secs ago)
Local/651 at from-internal/n (Not in use) has taken no calls yet
Local/517 at from-internal/n (In use) has taken 40 calls (last was 51
secs ago)
Local/607 at from-internal/n (Not in use) has taken no calls yet
Local/515 at from-internal/n (Not in use) has taken no calls yet
Local/514 at from-internal/n (Not in use) has taken no calls yet
Local/513 at from-internal/n (Not in use) has taken no calls yet
Local/604 at from-internal/n (Not in use) has taken 35 calls (last was
232 secs ago)
Local/512 at from-internal/n (Not in use) has taken no calls yet
Local/511 at from-internal/n (In use) has taken 20 calls (last was
57961 secs ago)
Local/510 at from-internal/n (In use) has taken 32 calls (last was 85
secs ago)
Local/509 at from-internal/n (In use) has taken no calls yet
Local/508 at from-internal/n (In use) has taken 29 calls (last was 142
secs ago)
Callers:
1. SIP/SIPtrunk-c4051f10 (wait: 18:24, prio: 0)
2. SIP/SIPtrunk-c4012530 (wait: 1:03, prio: 0)
3. SIP/SIPtrunk-c4002c50 (wait: 0:14, prio: 0)
Essentially, Caller 1 has been stuck for some time and has not been
ringing through to the agents. As new calls come in (2 and 3), they ring
through to agents immediately, assuming agents are available.
Here is the output of a 'show channel' command for the stuck caller, in
case it's useful. I've taken out any personal information and replaced it
with ***:
PBX*CLI> core show channel SIP/SIPtrunk-c4051f10
-- General --
Name: SIP/SIPtrunk-c4051f10
Type: SIP
UniqueID: 1265402770.520203
Caller ID: ***
Caller ID Name: ***
DNID Digits: ***
State: Up (6)
Rings: 0
NativeFormats: 0x100 (g729)
WriteFormat: 0x40 (slin)
ReadFormat: 0x100 (g729)
WriteTranscode: Yes
ReadTranscode: No
1st File Descriptor: 12
Frames in: 56974
Frames out: 56297
Time to Hangup: 0
Elapsed Time: 0h19m8s
Direct Bridge: <none>
Indirect Bridge: <none>
-- PBX --
Context: ext-queues
Extension: 400
Priority: 19
Call Group: 0
Pickup Group: 0
Application: Queue
Data: 400|t||
Blocking in: ast_waitfor_nandfds
Variables:
CWIGNORE=TRUE
PLAYBACKSTATUS=SUCCESS
MONITOR_FILENAME=/var/spool/asterisk/monitor/q400-20100205-124638-1265402770.520203
RGPREFIX=EO:
NODEST=400
DIAL_OPTIONS=trM(auto-blkvm)
BLKVM_BASE=400
BLKVM_OVERRIDE=BLKVM/400/SIP/SIPtrunk-c4051f10
MACRO_DEPTH=0
TTL=64
AMPUSERCIDNAME=
AMPUSER=
REALCALLERIDNUM=***
IVR_RETVM=
IVR_CONTEXT=ivr-4
IVR_CONTEXT_ivr-4=
DIR-CONTEXT=default
LOOPCOUNT=0
MSG=custom/LanguageSelectionJFF
DB_RESULT=DAY
CALLINGPRES_SV=allowed_not_screened
FROM_DID=s
MYSQL_STATUS=0
connid=1
SIPCALLID=BW204610078050210-334988361@***
SIPDOMAIN=192.168.123.3
SIPURI=sip:***@10.1.254.5:5060
CDR Variables:
level 1: clid=***
level 1: src=***
level 1: dst=1
level 1: dcontext=ivr-4
level 1: channel=SIP/SIPtrunk-c4051f10
level 1: lastapp=Queue
level 1: lastdata=400|t||
level 1: start=2010-02-05 12:46:10
level 1: answer=2010-02-05 12:46:10
level 1: duration=0
level 1: billsec=0
level 1: disposition=ANSWERED
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1265402770.520203
Issue History
Date Modified Username Field Change
======================================================================
2010-02-05 16:15 tbpsn Note Added: 0117806
======================================================================
More information about the asterisk-bugs
mailing list