This is because the standard behavior of QueueMetrics when running with filters and multi-stint mode as well, is the following:
- get the full set of calls
- filter out those who do not match the criteria
- aggregate multiple stints out of remaining calls
As you only have the IVR information on the FIRST call, if you run a filter in multi-stint mode, only the FIRST stint will pass the filter; this way, the second stint is not found when running in multi-stint mode. This is a natural extension of what is explained in chapter 12.1 of the User Manual, so we do not consider this a bug.
This is the way QM has been working so far; you could easily get that working by adding a second IVR record for the second leg of the call.
Like e.g.:
1289928508|1234.1|A0|NONE|INFO|IVR|123
1289928508|1234.1|A0|NONE|ENTERQUEUE||123-5551234
1289928538|1234.1|A0|NONE|EXITWITHTIMEOUT|1
1289928540|1234.1|A1|NONE|INFO|IVR|123
1289928541|1234.1|A1|NONE|ENTERQUEUE||123-5551234
1289928611|1234.1|A1|Agent/3347|CONNECT|70|1235.2
1289928624|1234.1|A1|Agent/101|COMPLETECALLER|70|13|2
This works just fine.
On the other side, I think that if we change the order of execution doing multi stint aggregation before filtering your problem should go away. We expect to do just that for the next version.