Call Terminated by Call Queue

[Luke Ivison]

Hi

We have been experiencing a problem where we are getting lost calls when there are agents available. It would appear that the call is being terminated by call queue and I am not sure how it is being terminated by the call queue.

Is anyone else experiencing this issue?

Thanks
Luke

 

[AWS2P]

and your 3CX licence is more than 20 SC and your trunk is also permitting to have enough channels ?

 

[Luke Ivison]

we have 32 SC and yes my trunk is allowing enough calls as the call is originally getting through to our IVR we have and then the caller is pressing an option and the call is being terminated straight away.

 

[AWS2P]

So problem occurs before reaching the Q ? just selecting an option in IVR goes the call to be ended ?

If so , can we have settings from this IVR ? hide sensitive infos

in your IVR do you have set something like this

 

[Luke Ivison]

The call comes through to the IVR the caller then presses an option whether it be 1,2,3 or 4. Once pressed the call gets terminated by the call queue they select.

 

[AWS2P]

in post #7 @JohnS_3CX ask you about Q number that were not matching one from 0001 and other 0012

What is the good Q number ? 0001 or 0012? if it's 0012 then your IVR is not set in accordance.

 

[Luke Ivison]

I don't understand what you are getting at! We have IVR set up for each number that comes in for example the extension i used for John was digital receptionist number was 1102 which then has 4 call queues associated with it which are 0011, 0012, 0013 and 0014, when it goes through to ANY call queue its sometimes gets terminated by the queue. Queue 0012 was used as an example of what happens its not the only queue that is terminating a call. All digital receptionists and call queues are setup exactly the same.

 

[Luke Ivison]

 

[JohnS_3CX]

Hi Luke,

Another possibility is if the user pressed the * button while waiting in the queue for an agent to answer the call which will send them to end call destination.

It will appear in your 3CXQueueManager.log like the example here:

2019/09/03 12:11:22.534|5692|0006|Trac|DBG: Call 338 (Main): Received DTMF - '*'/0
2019/09/03 12:11:22.534|5692|0006|Trac|DBG: DTMF: Performing action System.Action`1[QMgrPlugIn.DTMFMenu]
2019/09/03 12:11:22.535|5692|0006|Info|Caller (number of caller appears here) has forced 'Froward to No-Answer destination' action in call 338
2019/09/03 12:11:22.535|5692|0006|Trac|DBG: QCall 338 got NoAnswer request, reason: UserRequested
2019/09/03 12:11:22.535|5692|0006|Info|Poll is terminated, reason: Canceled (User requested), QCID=338

It will also appear in 3CXQueueManager.track.log as:

2019/09/03 12:11:22.576|5692|0010|Info|338,Q.801: [caller ID appears here] (hist_id: 00000C04271AC86F_27)
  Time: 9/3/2019 12:11:09 PM - 9/3/2019 12:11:22 PM (00:00:12.9242532)
  Waiting: 00:00:00.0025534
  Polling: time: 00:00:12.8820071 (1 rounds), agents dialled: 1, rejected: 0, timed out: 0
  NoAnswer: UserRequested =>

 

[AWS2P]

You clearly see in logs that's the Q and not IVR who ends calls?

 

[AWS2P]

as a test if you set Q to be reached directly without IVR, in that case is it working as expected with no dropped calls?

 

[Luke Ivison]

Hi John

I think it may have something to do with the callback feature. I looked in the event log and seen this:

 

[JohnS_3CX]

Yep, that is also possible. If you have call queue notifications enabled you should receive an email when this happens (you must also add an extension as the queue manager, and that extension should have a valid email entered in their extension profile)

 

[AWS2P]

If callback is the problem, it's easy to test Q without and see if it fix or not

 

[Luke Ivison]

We have the notify when callback fails option ticked on all queues too. Here is another example of a call that was dropped from the same number 3 times in a row. I don't think this is anything to do with the callback feature now i have dug deeper. There is 2 different queues used here.

 

[AWS2P]

As test can you try to modify DNA value on Qs to see if it change Q behavior, try setting 1800s it's quite enough and more usable value

 

[Luke Ivison]

What difference will it make if i decrease the call wait time?

 

[AWS2P]

this is just to make a test, no problem for your use calls will stay 30 minutes in Q before DNA forward, so for callers it change nothing, but if 3CX has a problem with so big value you use for now it may change behavior, that 's the only way to know if it can help or not to fix your problem.

 

[Luke Ivison]

The call wait time has only been recently increased to the maximum while i try to get to the bottom of this problem. It was initially on 960 seconds and we was still having this same issue, so i don't think decreasing it will change anything.

 

[AWS2P]

Ok, i 've done same config as yours on my demo pbx and this works like a charm on mine , so don't know what happens on yours

 

[JohnS_3CX]

Hi Luke,

I suggest checking the queue logs as per my post #28

Post has been updated to include detailed information for your convenience