SIP Trunk Status Reporting Latency in EU-West BYOC Performance Dashboard

Voice & Telephony
1

SIP Trunk Status: FAILED (Connection Refused)
Timestamp: 2023-10-27 14:32:15 CET
Source: Genesys Cloud Performance Dashboard > Telephony > Trunk Health

The Genesys Cloud Performance Dashboard for our EU-West BYOC environment is reporting a critical failure for our primary SIP trunk connection. The dashboard indicates a “Connection Refused” status starting precisely at 14:32 CET. This timestamp coincides with a scheduled maintenance window performed by our on-premise CPE provider, during which the SIP trunk interface was briefly restarted.

Despite the CPE provider confirming that the SIP trunk is up and operational since 14:35 CET, the Genesys Cloud dashboard continues to display the trunk as “Failed” or “Unhealthy” as of 15:00 CET. Agent performance metrics associated with this trunk, such as Call Abandonment Rate and Average Wait Time, are also not updating, suggesting that the backend telemetry feed for this specific trunk is stalled or cached at the failure state.

We have verified the following:

  1. The SIP trunk configuration in Genesys Cloud Architect has not been modified.
  2. The CPE provider’s health check endpoints are returning 200 OK.
  3. Other trunks in the same region are reporting health status correctly.

The issue appears to be isolated to the dashboard’s health check mechanism for this specific trunk. Is there a known latency or caching issue with the SIP Trunk Health module in the EU-West BYOC performance views? Specifically, how long does it typically take for the dashboard to refresh the health status after a brief network interruption? Are there any manual refresh triggers or cache-clearing procedures available for dashboard administrators to force a re-evaluation of the trunk health status without impacting live traffic?

Understanding the reconciliation logic between the real-time SIP signaling data and the dashboard’s health view is critical for our incident reporting processes. Any insights into the expected refresh interval or known limitations in the BYOC performance data pipeline would be greatly appreciated.