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

Wed Sep 15 09:11:55 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-09-15 09:11 CDT
====================================================================== 
Summary:                    [patch] 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

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

---------------------------------------------------------------------- 
 (0126990) bms (reporter) - 2010-09-15 09:11
 https://issues.asterisk.org/view.php?id=17358#c126990 
---------------------------------------------------------------------- 
Please consider the attached patch to 1.6.2.10 understanding I will patch
the head pending some initial feedback on this patch. This is my first
submission so please be gentle. My analysis of this issue brought me to the
conclustion that in very short intervals the queue can think a member is
not-in-use when in fact it is preparing to dial. This is because each queue
has a different member list and the same member can be part of multiple
queues. Under certain loads it is not possible to suppress the attempt to
dial on the same interface simultaneously. Phones with call waiting will
accept this but callers will fall out of the queue unnecessarily.

To resolve this apparent problem, I created a queue view of interfaces
that it consults to see if it is already using one interface. I added a
linked list of structures containing the interface name and last time it
was used. I added a pointer to the structure in member. Each time an
attempt to try a member is performed I make sure that the member points to
the structure for the particular interface. This way if two queues each
have a member pointing to the same interface, only one will get access. And
no one else will gain access for 2 seconds after which the device status
will probably be correct.

Not being very familiar with most of the code and being tasked to fix a
specific problem I did not know where to put any garbage collection. I have
the code to do it if someone can point me to where it should be called.

I tested the patch with 1 member associated with 5 queues and dumping
several calls in each queue with a script. 1.6.2.10 and 1.6.2.11 both would
periodically ring the agent with 2-4 calls simultaneously. The attached
patch single threads the calls. My environment requires autofill and
multiple outgoing calls. I would be grateful for constructive notes. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-15 09:11 bms            Note Added: 0126990                          
======================================================================