[asterisk-bugs] [Asterisk 0014329]: wrapuptime=0 in 1.6.0.1 and 1.6.0.3

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14329 
====================================================================== 
Reported By:                x86
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   14329
Category:                   Applications/app_queue
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0.3 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-25 17:23 CST
Last Modified:              2009-02-05 19:07 CST
====================================================================== 
Summary:                    wrapuptime=0 in 1.6.0.1 and 1.6.0.3
Description: 
When you set wrapuptime=0 in queues.conf on any queue, persistent (afaik...
did not try dynamic agents) members of that queue will randomly (more so
than not) miss calls if they recently got off of the phone. It seems that
when the wrap up time is set to 0, app_queue ignores the 0 and defaults the
value to something around 10 seconds.
====================================================================== 

---------------------------------------------------------------------- 
 (0099580) x86 (reporter) - 2009-02-05 19:07
 http://bugs.digium.com/view.php?id=14329#c99580 
---------------------------------------------------------------------- 
Sorry for the delay. It is happening with static queue members on SIP
channels, not Agent channels. I did check that the agents are in "not in
use" state after taking a call, but Asterisk simply refuses to dial queue
members that have just gotten off the phone within roughly 10-20 seconds.
It seems like it's sporadic, as it happens frequently, but not every time.
I would say about 90% of the time the issue is reproducible. Here is the
queues.conf:

[general]
        persistentmembers = yes
        autofill = yes
        monitor-type = MixMonitor

[service]
        musicclass = default
        ; Change to announce to agent what queue call is coming in on
        ;announce = queue-markq
        strategy = ringall
        wrapuptime=0
        timeout = 60
        retry = 5
        weight=0
        autopause=no
        announce-frequency = 90
        periodic-announce-frequency=24
        periodic-announce = mousty/busy-time
        joinempty = yes
        leavewhenempty = no
        ringinuse = no
        context = leavequeue
        member => SIP/7000  
        member => SIP/7001  
        member => SIP/7002  
        member => SIP/7003  
        member => SIP/7004  
        member => SIP/7005  
        member => SIP/7006

[others]
        musicclass = default
        ; Change to announce to agent what queue call is coming in on
        ;announce = queue-markq
        strategy = ringall
        wrapuptime=0
        timeout = 60
        retry = 5   
        weight=0    
        autopause=no
        announce-frequency = 90
        periodic-announce-frequency=24
        periodic-announce = mousty/busy-time
        joinempty = yes
        leavewhenempty = no
        ringinuse = no
        context = leavequeue
        member => SIP/7000  
        member => SIP/7001  
        member => SIP/7002  
        member => SIP/7003  
        member => SIP/7004  
        member => SIP/7005
        member => SIP/7006 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-05 19:07 x86            Note Added: 0099580                          
======================================================================