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

[Asterisk Bug Tracker]

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-27 08:05 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

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

---------------------------------------------------------------------- 
 (0126394) schmidts (reporter) - 2010-08-27 08:05
 https://issues.asterisk.org/view.php?id=17358#c126394 
---------------------------------------------------------------------- 
the problem isnt answer itself and maybe answering a call within an AGI
could cause this too. The problem was that a sip call which is answered
(really by the client not the application) the indication isnt set to the
right value. This would also cause some problems when this call is
transfered. The patch i mean just sets the indication to the right value
after the client answers, so this could also depend on the status of the
client. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-27 08:05 schmidts       Note Added: 0126394                          
======================================================================