SIP Trunk Failover Impact on Active Call Metrics in Performance Dashboard

Could someone explain the precise mechanism by which the Genesys Cloud performance dashboard categorizes calls that drop during a SIP trunk failover event? We recently experienced a brief instability with our primary SIP provider, triggering an automatic failover to the secondary trunk. While the telephony logs indicate that the active calls were successfully bridged to the secondary provider with minimal audio interruption, the business stakeholders are reporting a significant spike in “Abandoned Calls” and a drop in “Service Level” for that specific time window.

The discrepancy lies in how the system interprets the SIP re-INVITE or re-registration process. If the call leg is technically maintained by Genesys Cloud despite the underlying trunk switch, the dashboard should reflect a continuous active state. However, the metrics suggest these calls are being treated as dropped and abandoned by the customer, which is skewing our SLA reports. This is causing considerable friction with the operations team, as the actual customer experience did not match the reported performance degradation.

“When a SIP trunk fails, Genesys Cloud will attempt to route active calls to available trunks based on the trunk group configuration. If a call is successfully transferred, the call state remains ACTIVE. If the transfer fails, the call is terminated and marked as abandoned or failed depending on the IVR context.”

The documentation suggests that if the transfer is successful, the state remains ACTIVE. Yet, the performance view is showing a high volume of abandoned calls during the exact minute of the failover. We are using the standard Queue Performance dashboard and have verified that no agents were involved in these specific calls; they were in the IVR or waiting in queue. Is there a known latency in metric aggregation that causes this temporary misclassification, or is there a specific SIP header or event that we need to monitor to ensure the dashboard correctly identifies these as successful handovers rather than abandonments? We need to align the technical reality with the business reporting.

It depends, but generally… the dashboard treats the SIP re-INVITE as a new leg, breaking the original session ID unless the failover preserves the correlation metadata. For legal discovery, this fragmentation complicates the chain of custody.

  • Verify legId persistence in /api/v2/recordings
  • Check SIP signaling logs for re-INVITE events
  • Review Performance Center session stitching rules