I don't believe you want to ignore the answer event from the IVR ... the call did get answered and given you are monitoring a VDN the answer will impact what events your monitor on the call will get going forward. If you wanted to ignore the IVR answer event and knew the range of extensions that represented the IVR you could filter the answers events for those extensions - but I don't think that by itself will address the problem you now have. The question is what happened to the call next. How does the IVR handle getting the call to an agent if the customer chooses to wait, if you are discarding the IVR answer event how can your application know if a call back was requested so you don't get a false positives on abandonment? In the customer chooses to wait, does the IVR transfer the call back into the queue/VDN? A different queue/VDN? Can your application use a value like UCID to recognize what is occurring when the customer chooses to wait? Additionally, will your VDN monitor even continue to deliver events for the call?
Is your application looking at the connection cleared event to see which party disconnects first? Probably not as this problem is new to you. A true abandon would probably always come from the 'customer' trunk side of the call first, but again we would need to examine the behavior of the Call Back Assist application to see how it behaves in the case callback was requested.
Assuming that the call flows back to the same or another VDN you could monitor for and observe the connection established events and check for agent ID extension ranges.
I can't design this for you (for one, there is a lot about the call flow that is not in evidence here), but the call flow just got more complex I don't believe a simple ignore a particular answer event coming from a range of extensions will be a sufficient cure.
|