Trying to understand the metric calculation for ‘Connection Delay’ within the Queue Activity view when SIP trunk failover is triggered. The organization operates in EU-West BYOC. During a scheduled maintenance window on the primary SIP provider, traffic routed to the secondary trunk via the Telephony settings.
The Architect flow logs indicate that calls were successfully bridged to agents within 800ms of the initial SIP INVITE reaching the secondary provider. However, the Queue Performance dashboard reports an average ‘Wait Time’ of 4.5 seconds for these specific interactions. This discrepancy skews the overall Service Level agreement (SLA) metrics for the ‘Tier1_Support’ queue, suggesting a performance degradation that does not align with the actual call leg analysis.
The environment details are as follows:
- Region: EU-West BYOC
- Feature: SIP Trunk Failover
- Metric: Wait Time vs. Connection Delay
- Time Window: 2023-11-15 14:00:00 UTC to 2023-11-15 15:00:00 UTC
The concern is whether the ‘Wait Time’ metric includes the SIP handshake latency between the two providers, or if there is a caching issue in the Performance dashboard. Accurate reporting is critical for vendor performance reviews.
Could someone clarify how ‘Wait Time’ is calculated in the Queue Activity view during SIP trunk failover events, and whether the inter-provider latency is factored into this metric?