The QueueMetrics database is built around the concept of a stream of events. Every event is bound to its timestamp (time when it happened).
When you run a report fro a specific time period, especially if it is very short because you are polling data via XML-RPC, QueueMetrics includes all the information that comes from events in the specified time-frame, and nothing more. So there are four scenarios:
- Calls which its events are all in the time period: no problems; they are correctly reported.
- Calls which started in the time period, but ended after it. You'll know when it started but not when it ended.
- Calls which started before the time period but ended in it. Some information (notably the Caller-ID) is missing.
- Calls which started before the time period and terminated after the time period without any event in-between. These calls didn't generate any event in that time period. So such calls might be skipped altogether.
The reason why QueueMetrics uses a bounded window is that when running a report for a specific period, a deeper problem looms: when is a call to be counted? when it started in the given period, or when it connected, or when it ended, or when it is completely within? this commonly happens when you make multiple consecutive short-time analyses - if a call starts in period A and ends in period B, where is it to be counted? the correct answer depends on what you need the data for, so our approach is to be agnostic on this and look at plain events.
A good real-life solution to the problem is to take your time period and add a margin before and after. How much is a good margin? it depends. We suggest at least twice the average duration of the calls in your call center. Then your script will examine those calls timings (answer, hang-up) and decide which ones to count and which are to be skipped.