This behavior depends on how Asterisk and QueueMetrics handle incomplete calls, i.e. calls that were not properly closed in the logs due to errors and are missing a closing event.

Such calls remain "open" in the system until an Asterisk restart occurs, which triggers a QUEUESTART event. When this happens, all open calls, both mistakenly left open and genuinely open ones, are forcefully closed. At this point, QueueMetrics tries to determine whether they are "real" calls or "incomplete" calls. It does so by checking properties default.maxOngoingTalkTime and default.maxOngoingWaitTime, which are the same ones used to exclude calls from the real-time page. The same logic applies at the end of the analysis in order to show a report that includes all calls.

So, if you have an incomplete call (one for which no further events will ever be received), and you run a report that ends just one minute after the call started, that call is likely to be counted. However, if you run the same report ending one week after the call started, it will be excluded as it is clearly an incomplete call.

In early versions of QueueMetrics, incomplete calls closed by a mid-flight QUEUESTART event would always appear in the report because their durations were not taken into account when determining whether the call was incomplete. To change this behavior, you can set the following property:

default.ignoreQueueStarts=true

With this setting, calls that are auto-closed by the QUEUESTART event will be considered incomplete and excluded from all reports, preventing discrepancies between short and long period reports.

In any case, calls that are complete — meaning they have all of their events and fall fully within the analysis period — will always be counted correctly, even if their wait or conversation times exceed the thresholds defined in default.maxOngoingTalkTime and default.maxOngoingWaitTime.