Is it possible to configure the Performance Dashboard to accurately reflect call disposition during a forced SIP trunk failover event? We are currently operating a primary SIP trunk via a Tier-1 provider and a secondary backup trunk. The environment is configured in the Europe/Paris region. When the primary trunk experiences a complete session timeout (SIP 504 Gateway Timeout) and traffic shifts to the secondary, the dashboard metrics for the affected queues become inconsistent for approximately 15 minutes.
The specific issue is that calls routed to the secondary trunk are often marked as “Abandoned” in the queue performance view, even though the call was successfully connected to an agent. The conversation detail view shows the correct disposition, but the aggregate queue metrics do not update in real-time. This discrepancy causes significant confusion for our team leads who monitor agent performance and service levels. They perceive a drop in answer rates, which triggers unnecessary operational interventions.
We have verified that the routing rules in Architect are correctly configured to handle the failover. The SIP settings for both trunks are identical regarding timeout values and retry logic. The problem seems to lie in how the Performance Dashboard aggregates data during the transition period. We need to understand if there is a known latency in metric calculation when switching transport providers.
Additionally, we are looking for a way to manually reconcile these metrics without relying on the delayed background job. Is there a specific filter or view in the Performance Dashboard that isolates calls by trunk ID? This would allow us to verify the actual success rate of the failover calls. We are not developers, so we cannot query the Analytics API directly. We rely entirely on the UI for our daily reporting. Any guidance on configuring the dashboard to handle these edge cases would be appreciated. We need to ensure that our KPIs reflect the true state of the telephony infrastructure, especially during critical failover scenarios.