Raw Data Reporting Discrepancy (agent,park, closer logs)

[scopor]

Hi all,

My install is as follows from scratc vicibox 5 i686-5.0.3 ISO |Vicidial VERSION:2.8.517a Build:131019-0849|Asterisk 1.8.23.1-Vici|Single Server|No Digium/Sangoma Hardware|No Extra Software After Installation|Intel Xeon 2.4

We are trying to build our own back end reporting using the raw data generated by vicicial. We have extracted the data from the vicidial_agent_log, park_log and vicidial_closer_log. However we ran into some issues with some of the data. There is an inconsistency that occurs. It does not happen on all calls but we noticed it a couple times and we are trying to recreate it to see what exactly caused or is causing it. For example on the vicidial_agent_log, the call came in at 10:10 lasted for 119 seconds, yet the closer and park log are reporting the call as taking place in the second half hour about 25 mins after the call took place 10:25 and 10:26. Or if the closer and park log are correct then the vicidial_agent_log is reporting the call 25 minutes prior to the call taking place. I am hoping that this makes sense. See image below with examples.

Has anyone experience this issue? Any feedback would be appreciated.

Below are two examples of this issue.

[williamconley]

1) It is either "from scratch" (which means manually installed from source code) or from the Vicibox .iso image. It can't be both. LOL (We have all assumed that you used the .iso image, of course, but I thought you'd like to rectify that tiny bit). Kudos, by the way, on posting very full versioning.

2) Excellent troubleshooting. Consider checking your /var/log/astguiclient logs to see if you can identify the scripts generating these log entries and where they may have gone astray. You can activate logging to file (if it's off) under Admin->Servers (choose your server, then modify the log setting)

3) Consider (seriously) upgrading before you dig in too deep, as you are not using the latest version. I'm pretty sure you'd be unhappy if you spent six hours on it and then found out it was already fixed in 'trunk'.

4) Happy Hunting!

[scopor]

Thank you William. You are correct. I guess I was trying to ensure that I provided all the information. So it is from ISO as you assumed. I am using mysql workbench to pull the raw data.

I was trying to upgrade my svn trunk following a post from this forum but was unsuccessful. Once I can successful perform an upgrade I will and will provide feedback after testing the data.

[scopor]

As suggested by William I have attempted an upgrade of vicibox 5 to the latest svn trunk. This did not solve the data discrepancy I reported earlier. I have downloaded and installed vicibox 6 standard iso on a 64bit intel Pentium 3.10GHz Dual Core CPU as a test install. No additional hardware/software is installed.

My version is as follows.
Version: 2.10b0.5
SVN Version: 2148
DB Schema Version: 1384
DB Schema Update Date: 2014-07-06 03:49:47

I am still having the same issue. Let me try to explain the issue in as much details as possible. I am placing inbound test calls to the server and logged in as an agent. I logged in at 17:28pm the following entry is made in the vicidial_agent_log.

65, 7425, 172.16.50.43, 2014-07-08 17:28:06, , TEST, 1404854886, 0, 1404854886, 0, , 0, , 0, , ADMIN, , LOGIN, , 0, N, , AGENT

I placed an inbound test call to the queue and took that call as the logged in agent. Look at the same entry above with additional information being written to it. Note that it did not create a new entry but added data to the first entry.

65, 7425, 172.16.50.43, 2014-07-08 17:28:06, 21, TEST, 1404854886, 61, 1404854947, 74, 1404855021, 21, 1404855042, 6, XFER, ADMIN, , LOGIN, , 0, N, 1404855021.60, AGENT

I then ended and dispositioned the call. Look at the new entry created in the vicidial agent_log file (66). Note that there is no repeat of the uniqueid to indicate that the call had ended.

66, 7425, 172.16.50.43, 2014-07-08 17:30:48, , TEST, 1404855048, 0, 1404855048, 0, , 0, , 0, , ADMIN, , , , 0, N, , AGENT

In the line above note that the uniqueid is missing. The time stamp of 17:30 is when the call ended and the call lasted 21 seconds which is reflected in the modified line 65. The interesting thing is this, if I place a new call as you would see from the entry below, the time stamp of 17:30 is retained and a new uniqueid is added with additional data representing this new call. So it would appear that this new call has started at 17:30 when in fact the call started at 17:44 as indicated in the new entry on line 67.

66, 7425, 172.16.50.43, 2014-07-08 17:30:48, 22, TEST, 1404855048, 0, 1404855048, 826, 1404855874, 13, 1404855887, 3, INQ, ADMIN, , , , 0, N, 1404855873.65, AGENT
67, 7425, 172.16.50.43, 2014-07-08 17:44:50, , TEST, 1404855890, 0, 1404855890, 0, , 0, , 0, , ADMIN, , , , 0, N, , AGENT


Line 67 shows the start of the new call without the uniqueid, while line 66 which has the time the previous call ended and the the uniqueid of this new call that started at 17:44.

Is this a bug in the way the system logs these calls? Any expert opinion here would be helpful as we are trying to generate our own reporting from the raw data but we can't do that if the raw data is skewed.

I will appreciate any assistance or guidance. I hope I have provided enough information and that it was clear and concise.

Cheers.

[mflorell]

The vicidial_agent_log is NOT a call log. It is an agent activity log, with each new entry starting with a PAUSE event. Because of this you will not see new vicidial_agent_log entries when a call goes to an agent.

[scopor]

Thank you Matt for your quick reply. We have examined all the logs and we realize that's where most of the activity took place. I am not trying to argue with you or doubt you as clearly you are the expert on vicidial. However we have been testing this for a couple months and the data was giving us these issues for quite a while and we are trying to determine what is wrong or where to find the correct information so we can generate performance reports from these logs. You indicated that the agent log is not a call log, however based on the test we have been doing once an agent logged into a campaign gets a call this is reflected in the agent log. Can you tell us where else to look for this information as we have examined all the logs that can possible store data. Thanks.

[mflorell]

The talk_epoch in the vicidial_agent_log is the timestamp that the agent receives a call to the agent interface.

It would help to have a better detailed description of what exactly you are looking for.