User Stats discrepancy

[jikseyres16]

Hi Vicidial Team,

I have this concern where under User Stats report where in:

AGENT ACTIVITY FOR THIS TIME PERIOD: (10000 record limit)

some wait time becomes longer for just a short period of time.

# DATE/TIME PAUSE WAIT TALK DISPO DEAD CUSTOMER STATUS LEAD TYPE CAMPAIGN PAUSE CODE
339 2018-10-26 01:27:52 10 0 0 0 0 0 PCCW LOGIN
340 2018-10-26 01:27:02 46 0 0 0 0 0 PCCW SI
341 2018-10-26 01:26:59 3 0 0 0 0 0 PCCW
342 2018-10-26 01:21:36 1 31137 122 2 0 122 U 949139 M PCCW LAGGED
343 2018-10-26 01:20:56 2 12 6 20 0 6 U 949116 M PCCW
344 2018-10-26 01:20:47 3 0 3 3 0 3 U 949116 M PCCW
345 2018-10-26 01:20:27 2 3 12 3 0 12 U 949187 M PCCW

How do I say this, from 2018-10-26 01:20:56 row #343 to 2018-10-26 01:21:36 row#342 there are almost 2mins difference only, question is why there are 31137 wait seconds on row#342?

oh almost forgot, agent login from 00:03hrs

432 2018-10-26 00:03:08 18 0 0 0 0 0 PCCW LOGIN

so why from 2018-10-26 00:03:08 to 2018-10-26 01:21:36 there are almost 8hrs wait time where the agent is only been logged for 1:21mins only.

Thank you

ViciBox Redux v.6.0.4
VERSION: 2.12-550a
BUILD: 160414-1013
Asterisk 1.8.32.3-vici

[mflorell]

First of all, I would strongly recommend you upgrade your system since it is running code from over 2 years ago and we have made many security and bug fixes since then(including in agent activity monitoring).

[roger.milligan]

Hello. I note that that row 342 is status LAGGED.

The moment you start to see LAGGED, you should first go after the cause of it. In my understanding LAGGED happens when the agent browser frontend cannot connect to the server for more than 30 seconds. (It usually connects 1 or 2 times a second.). This may be caused by a network issue, but in my experience it can also happen if the Vici Agent screen is sharing browser windows with another web app (on a different tab) that is hogging the browser resources and causing the Vici JavaScript to get held up.

Could this be an issue on your site?

Roger

[jikseyres16]

Hi Sir Matt and Sir Roger,

Thanks for your inputs and sorry for late revert I'm trying to learn how to upgrade svn at this moment, will also try if I can replicate the scenario stated by Sir Roger.

Thank you guys again

[williamconley]

Some log table values are generated based on time of arrival of a packet. If packet order is scrambled, or other various asterisk anomalies occur, it's technically possible for two events to happen in the wrong order, and as a result appear to have time-traveled (call connected before being answered, wait time being calculated as a negative value as a result). Negative values, however, are impossible, so the mysql data storage system rolls the value over to "Max" and starts going downward. Thus you suddenly have a massive number.

Some later revisions of Vicidial have these "unlikely/impossible" values filtered out. So if you're lucky, the upgrade will resolve your issue.

But you may also have an issue with dropped packets, lagged packets, network jitter, that sort of thing. There are numerous network analysis packages to help you identify and eradicate local and public network issues. Always a good idea to sort those out as soon as you can, certainly before you begin to push the Vicidial server at all as unpredictable results are inevitable when networking is imperfect and a load is applied.

Happy Hunting