[asterisk-bugs] [Asterisk 0017358]: problem with ringinuse=no, queue members receive sometimes two calls

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Aug 31 10:20:27 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17358 
====================================================================== 
Reported By:                nik600
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17358
Category:                   Applications/app_queue
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.31 
JIRA:                       SWP-1512 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-19 02:52 CDT
Last Modified:              2010-08-31 10:20 CDT
====================================================================== 
Summary:                    problem with ringinuse=no, queue members receive
sometimes two calls
Description: 
Dear all

on a debian amd64 i've installed (from source) asterisk 1.4.31

On the system we have in average 50 concurrent calls in queue and 40
sip members.

I'm experiencing an apparently random problem:
sometimes some users receive 2 calls from asterisk, apparently
ignoring the ringinuse=no settings.
It appears on users that are members of many queues

As you can see from the log, the user goes in a status Ring+Inuse.

Any idea?
Why the call is still dispatched to the user if it is not in the "Not
in use" status?

i've added some customized log in the ring_entry function and this is the
result:

[May 18 14:13:04] DEBUG[24945] app_queue.c: KUMBELOG: queue=queue_1       
count=1,membercount=13,ringinuse=0,device=SIP/PL1009,status=1
[May 18 14:13:04] DEBUG[24945] app_queue.c: Found matching member
SIP/PL1009 in queue 'queue_2'
[May 18 14:13:04] VERBOSE[24945] logger.c:     -- Called SIP/PL1009
[May 18 14:13:05] VERBOSE[24945] logger.c:     -- SIP/PL1009-00001807 is
ringing
[May 18 14:13:06] DEBUG[25098] app_queue.c: KUMBELOG: queue=queue_2       
count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=1
[May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member
SIP/PL1009 in queue 'queue_1'
[May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member
SIP/PL1009 in queue 'queue_3'
[May 18 14:13:06] VERBOSE[25098] logger.c:     -- Called SIP/PL1009
[May 18 14:13:07] VERBOSE[25098] logger.c:     -- SIP/PL1009-00001808 is
ringing
[May 18 14:13:07] DEBUG[25312] app_queue.c: KUMBELOG: queue=queue_3       
count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
[May 18 14:13:08] DEBUG[25382] app_queue.c: KUMBELOG: queue=queue_4       
count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
[May 18 14:13:08] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2       
count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=6
[May 18 14:13:12] VERBOSE[25098] logger.c:     -- SIP/PL1009-00001808
answered SIP/192.168.55.32-000017e6
[May 18 14:13:13] VERBOSE[25098] logger.c:     -- Native bridging
SIP/192.168.55.32-000017e6 and SIP/PL1009-00001808
[May 18 14:13:14] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2       
count=1,membercount=15,ringinuse=0,device=SIP/PL1009,status=7

It seems that the system does not change the status of the user after
calling it, and then re-schedule a new call.

After that the status is updated and goes in a ring+inuse status (7)

Do you have any idea about what can cause that?

This is an example of my config

[PL1009]
context=mycontext
callerid=PhoneLine1009 <1009>
secret=pwd1009
type=peer
host=dynamic
call-limit=3
disallow=all
allow=ulaw

queues:
[queue_1]
weight=10
wrapuptime=0
strategy=leastrecent
joinempty=no
retry=0
autopause=yes
setinterfacevar=yes
eventwhencalled=yes
eventmemberstatus=yes
ringinuse=no

member => SIP/PL1009

[queue_2]
weight=10
wrapuptime=0
strategy=leastrecent
joinempty=no
retry=0
autopause=yes
setinterfacevar=yes
eventwhencalled=yes
eventmemberstatus=yes
ringinuse=no

member => SIP/PL1009


[queue_3]
weight=10
wrapuptime=0
strategy=leastrecent
joinempty=no
retry=0
autopause=yes
setinterfacevar=yes
eventwhencalled=yes
eventmemberstatus=yes
ringinuse=no

member => SIP/PL1009

====================================================================== 

---------------------------------------------------------------------- 
 (0126473) bms (reporter) - 2010-08-31 10:20
 https://issues.asterisk.org/view.php?id=17358#c126473 
---------------------------------------------------------------------- 
My client is running 1.6.2.10 on a CentOS 5.5 call center with 60+ queues
and peak call volumes of 400+ concurrent calls. autofill is on, 

I have noticed in the AMI log that when an agent is a member of multiple
queues, sometimes he will be assigned multiple calls within 10 micro
seconds. I do not yet understand the queuing implementation, however it
looks as though a caller is "assigned" to a member (Newchannel) then
another caller from a different queue is "assigned" to the same member
(another Newchannel) before any flag is set on the interface indicating
intention to use. This is well before the ringing on the devices. One
caller gets answered and the other times out.

This happens hundreds of times per day. Calls get handled ok from the
caller perspective but the agents are angry for receiving call waiting
messages. Finally managers are confused about how to manage workforce with
so many apparent call timeouts.

Does anyone know if there is a flag on the interface that says someone is
or is about to use the channel and so it should not be "assigned" to
another caller?

This is my first note so please be gentle. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-31 10:20 bms            Note Added: 0126473                          
======================================================================




More information about the asterisk-bugs mailing list