[Home]

Summary:ASTERISK-15855: No ENTERQUEUE event in queue_log if leavewhenempty=yes in queues, therefore no ACD report is available to track overflow calls.
Reporter:David Brillert (aragon)Labels:
Date Opened:2010-03-22 10:46:39Date Closed:2011-06-07 14:00:46
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) AsteriskCLI_no_ENTERQUEUE-EXITEMPTY.txt
Description:I have background application in queue to overflow incoming ACD caller to IVR menu if leavewhenempty=yes and no agents are logged or all are paused.
On incoming call since no agents are available the caller is overflowed to IVR but no events are written to /var/log/asterisk/queue_log
There is no ENTERQUEUE event therefore there is no EXITEMPTY event written.
Therefore I cannot generate a report or extrapolate the number of times a caller could not enter a queue because no agent was available.

The overflow works but Asterisk needs to generate ENTERQUE event then EXITEMPTY event when leavewhenempty is invoked in queue_log so we can report on these events.


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

[default-sales]
music                          =  default
strategy                       =  rrmemory
servicelevel                   =  30
context                        =  default-aa-servicemainmenubutton1englishsubmenu
timeout                        =  15
retry                          =  5
maxlen                         =  0
weight                         =  0
reportholdtime                 =  no
reportwaitcall                 =  no
memberdelay                    =  0
timeoutrestart                 =  no
autofill                       =  yes
autopause                      =  no
ringinuse                      =  no
setinterfacevar                =  yes
wrapuptime                     =  
joinempty                      =  strict
leavewhenempty                 =  yes
eventwhencalled                =  vars
eventmemberstatus              =  yes
monitor-format                 =  wav49
monitor-type                   =  MixMonitor
queue-youarenext               =  queue-youarenext
queue-thereare                 =  queue-thereare
queue-callswaiting             =  queue-callswaiting
queue-holdtime                 =  queue-holdtime
queue-minutes                  =  queue-minutes
queue-seconds                  =  queue-seconds
queue-thankyou                 =  queue-thankyou
queue-lessthan                 =  queue-less-than

dialplan does this:
exten           => s,15,Queue(default-queue-e-appeals-level1||||60|)
exten           => s,16,NoOp(${QUEUESTATUS})
exten           => s,17,GotoIf($["${QUEUESTATUS}" = "FULL"]?1000)
exten           => s,18,GotoIf($["${QUEUESTATUS}" = "TIMEOUT"]?1000)
exten           => s,19,GotoIf($[$["${QUEUESTATUS}" = "LEAVEEMPTY"] | $["${QUEUESTATUS}" = "JOINEMPTY"]]
dialplan always use Queue() application which also create ENTERQUEUE event
once done he check the status and if FULL, TIMEOUT, LEAVEEMPTY, JOINEMPTY then dialplan go back to IVR
 -- Executing [s@default-application-acd-sales:15] Queue("SIP/6002-00006caf", "default-sales|tH|||15|") in new stack
[Mar 18 14:12:35] WARNING[11800]: app_queue.c:4227 queue_exec: Unable to join queue 'default-sales'
-- Executing [s@default-application-acd-sales:16] NoOp("SIP/6002-00006caf", "JOINUNAVAIL") in new stack

dial plan looks fine.

Queue() application was properly called and properly returned JOINUNAVAIL which in configuration goes back to IVR


Comments:By: David Brillert (aragon) 2010-03-22 10:51:05

Uploaded Asterisk CLI with agi debug enabled, verbose = 10
There is no point uploading queue_log file since it never contains any events related to this bug (ENTERQUEUE, then EXITEMPTY never get written in this scenario).

I have no idea how to write a patch for this.  I'm looking for help...
By: David Brillert (aragon) 2010-03-22 11:17:05

Not only are overflow calls not counted by EXITEMPTY
Also the call never gets tracked entering the queue since there is no ENTERQUEUE event either hence MAJOR.  All ACD calls must be tracked and the reason for their overflow.
By: David Woolley (davidw) 2010-03-23 08:16:17

JOINUNAVAIL is the result of the use of joinempty, not leavewhenempty.  The call was never in the queue, hence I believe it is correct that there should be no queue events recorded.

This looks like either a feature request, or that you should write your own custom queue log entry.
By: Joel Vandal (jvandal) 2010-03-23 08:31:49

On join_queue function (apps/app_queue.c), it start by setting "res" to -1 (false), it correctly set the reason but do nothing else, and at end it do a return of "res" so it return always FALSE for JOINEMPTY, JOINUNAVAIL and QUEUE_FULL.

On queue_exec, it call the join_queue function and if result is "TRUE", it will create an ENTERQUEUE event.

I agree that we can use "QueueLog" dialplan application to generate events if status is JOINUNAVAIL or JOINEMPTY... But, since this is a Queue (ACD) call, does it logic to always create an ENTERQUEUE event for joinempty/unavail and full, then save the EXITEMPTY status ?
By: David Brillert (aragon) 2010-03-23 08:48:39

davidw: Firstly I wish to thank you for your response, it is appreciated.

There is only one scenario I have tested where if no agents are available the EXITEMPTY event is written.
Caller enters queue and agent is available but agent chooses not to answer the caller and pauses status or logs out of queue, then the call follows the dial plan and overflows out of the queue.  This writes the ENTERQUEUE event and the EXITEMPTY events to queue_log.

In the reported scenario the caller never enters queue and no events are written to queue_log since the caller never enters the queue because no agents are technically logged.  EXITEMPTY needs to be captured somewhere since call centers need to know when the queues are not staffed via reports.  Arguably I don't think this should be a feature request since the implementation of the existing feature is incomplete.  I just don't see the value of EXITEMPTY if it can only be used in a scenario where agents log off or pause after a call has already entered the queue.

The discussion should continue as to what is the best method to capture the necessary events to generate the necessary reports for the call center.
By: Leif Madsen (lmadsen) 2010-03-23 09:40:36

I do have to agree with davidw at this point that this feels like a feature request. It may be best to continue this discussion on the asterisk-dev mailing list, referencing this issue number in the discussion.
By: David Brillert (aragon) 2010-03-23 09:57:36

lmadsen:

jvandal and I tested some workaround magic based on davidw's suggestion to write to queue_log outside of Asterisk source code.  you can close this issue.


By: Leif Madsen (lmadsen) 2010-03-24 10:47:42

Closed per the reporter. Thanks!