QueueMetrics > Running QueueMetrics

Question related to AvgRing (RT tichet #1323)

(1/1)

indreias:
Hello,

Could somebody explain how is computed the value for "AvgRing" and "TotalRing" for Taken Calls@ACD attempts by terminal.

I have configured Agents phones with "AutoAnswer" and the call is answered immediatelly after reaching the agent phone.

Still we get, into the mentioned report, something like:


--- Code: ---Agent    N. lost  Avg ring  Ring (s) N. Taken  Avg ring  Ring (s)
Ana Rusu 0 - 0:00  29 0:47 22:50 
Cristina B 0 - 0:00  12 0:17 3:33 
Victor Ilie 0 - 0:00  10 0:25 4:18 
Violeta N 0 - 0:00  15 0:48 12:11
--- End code ---

In the queue_log there are no RINGNOANSWER events and I suspect that the vallue is wrongly computed as "Wait time of call till Agent X have answered" instead of the "Ring Time for Agent X".

Anybody have noticed this issue before - or is something wrong in our setup?

Best regards,
Ioan

###
queuemetrics-java-1.6.0_22-21
queuemetrics-1.7.1.7-90
queuemetrics-tomcat-6.0.33-19
asterisk 1.8.6
###

QueueMetrics:
If you have many RINGNOANSWERS eg because you use RINGALL strategy, the results won't mean much.

indreias:
This is not our case - we are running RRMEMORY queues.


--- Code: ---[root@host66 tools]# grep -c RING /var/log/asterisk/queue_log
18

[root@host66 tools]# grep -c CONNECT /var/log/asterisk/queue_log
728
--- End code ---

Also, almost all CONNECT events are with ringtime=0.


--- Code: ---[root@host66 tools]# grep CONNECT /var/log/asterisk/queue_log | grep -c "|0$"
249
--- End code ---

As I have mentioned in the initial post there are almost no RINGNOANSWER events in the queue_log (18 from a total of 728 CONNECTED calls).

Our point of view - expressed on the support ticket as well - is that the RingTime is not computed correctly. This should be done on the "ringtime" info from RINGNOANSWER and CONNECT events. From the data we have in the demo sessions we performed extensively this week it looks the RingTime is computed somehow else.

Best regards,
Ioan

QueueMetrics:
We are working on a patch that will use this information where available.

Anthony:
This is now fixed in version 12.01

Navigation

[0] Message Index