[asterisk-bugs] [Asterisk 0017500]: [patch] wrapuptime not respected properly by app_queue: a queue member with setup wrapuptime gets a call when inappropriate

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17500 
====================================================================== 
Reported By:                g106u5
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17500
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.31 
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-06-11 06:50 CDT
Last Modified:              2010-06-14 15:44 CDT
====================================================================== 
Summary:                    [patch] wrapuptime not respected properly  by
app_queue: a queue member with setup wrapuptime gets a call when inappropriate
Description: 
This is somewhat akin but not same as 
https://issues.asterisk.org/view.php?id=16519


Wrapup time is supposed to give the agent some time after completing an
incoming call  before the next incoming call arrives, e.g., to complete
some call report "paperwork".  It is implemented in app_queue.c as
follows:


        /* on entry here, we know that tmp->chan == NULL */
        if (qe->parent->wrapuptime && (time(NULL) - tmp->lastcall <
qe->parent->wrapuptime)) {
                if (option_debug)
                        ast_log(LOG_DEBUG, "Wrapuptime not yet expired for
%s\n", tmp->interfac
e);

inside ring_entry(...)


It looks as though lastapp for me is set to the time the call is ANSWERED
by the agent not the time call is HANGUP by either then agent or the
caller. The "testonly" setup is as follows (reproduced on  tarballed
1.4.31/Linux-i386, 1.4.33-rc1/Linux-i386 1.6.0.15/FreeBSD-i386 from ports)

>>>[queues.conf]<<<<<
[general]
;
persistentmembers = yes
keepstats = yes
autofill = yes
setinterfacevar=yes
announce-frequency = 0

[queue1]
ringinuse=no
strategy = rrmemory
timeout = 8
retry = 1
wrapuptime=60
announce-frequency = 0
joinempty = yes
autopause=no  
timeoutrestart = yes
servicelevel = 10    
setinterfacevar=yes
member => SIP/bt101/101


>>>>>[sip.conf]<<<<<<<
[general]
context=from_sip_ext_unknown
limitonpeers=yes

[bt101]
type=friend
host=dynamic
username=bt101
secret=bt101
nat=yes
context=from_bt101
disallow=all
allow=alaw
call-limit=6

>>>>>>>[extensions.conf]<<<<<<<<<<<<<<
[toqueue]
exten => _X.,1,Queue(queue1)

The client bt101 is an X-lite with AA (auto-answer turned on).

The bug:

gw2*CLI> queue show queue1
queue1       has 0 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:0, C:0, A:0, SL:0.0% within 10s
   Members: 
      SIP/bt101/101 (Not in use) has taken no calls yet
   No Callers

gw2*CLI> originate local/111 at toqueue application Playback spam
[wait 15sec]
gw2*CLI> originate local/111 at toqueue application Playback spam
[from a different terminal in 30 sec after the first cmd] 
gw2*CLI> queue show queue1
queue1       has 1 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:0, C:1, A:0, SL:100.0% within 10s
   Members: 
      SIP/bt101/101 (Not in use) has taken 1 calls (last was 30 secs ago)
   Callers: 
      1. Local/111 at toqueue-39cf;2 (wait: 0:11, prio: 0)

The lastcall (30 sec here) should be something like 6 seconds (difference
between 30 seconds and the length of the spam.wav file), however it is 30
seconds (time since the agent picked up). Consequently, the agent will 
receive next call in 30 seconds not 60 (wrapuptime). 

Alike  effects was seen under multiple configurations involving
SIP/account/number  agents and SIP clients calling through local channel. 


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-14 15:44 pabelanger     Status                   needs license =>
feedback
======================================================================