[Home]

Summary:ASTERISK-16236: [patch] wrapuptime not respected properly by app_queue: a queue member with setup wrapuptime gets a call when inappropriate
Reporter:Globus (g106u5)Labels:
Date Opened:2010-06-11 06:50:36Date Closed:2011-07-26 14:42:08
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) wrapuptime-1433rc1.diff
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@toqueue application Playback spam
[wait 15sec]
gw2*CLI> originate local/111@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@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.



****** ADDITIONAL INFORMATION ******

The fix for the situation whereby the AGENT hangs up first is rather obvious and involves adding 1 line to the code of  static int try_calling(struct queue_ent *qe, const char *opt....) as follows:


<inline patch removed by lmadsen>

Not sure what to do with the situation when the CALLING party hangs up -- hence not submitting a patch for now :(
Comments:By: David Woolley (davidw) 2010-06-11 06:58:25

A patch as a comment will not be looked at.  You need to agree to the submission licence terms, if you haven't done so already, then attach them as a "code or documentation" attachment.
By: Globus (g106u5) 2010-06-11 13:08:09

The patch only fixes the problem in 1 of the 2 error-generating situations -- namely, then THE AGENT party hangs up the call. Still figuring out the best way to track call drop by the caller.
By: Leif Madsen (lmadsen) 2010-06-14 15:35:27

Your license was rejected. You will need to resubmit the license and re-upload your patch.
By: Paul Belanger (pabelanger) 2010-06-25 08:51:12

confirmed
By: Leif Madsen (lmadsen) 2011-07-26 14:42:02.651-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!