Could someone explain the specific threshold logic governing SIP trunk registration timeouts as displayed in the Performance Dashboard for our EU-West BYOC environment.
The current configuration involves a primary SIP trunk connected to a third-party carrier, with the expectation of stable registration states during standard business hours in the Europe/Paris timezone. However, the dashboard reports intermittent ‘Registration Timeout’ events that do not correlate with visible network latency spikes or carrier-side outages. The metric appears to trigger when the registration refresh interval exceeds a specific duration, yet the documentation does not clarify whether this duration is measured from the initiation of the REGISTER request or from the expected expiration of the previous session. This ambiguity complicates the analysis of agent availability metrics, as agents assigned to queues served by this trunk experience brief periods of unavailability that are not reflected in standard agent state history views. The Conversation Detail View shows these interactions as dropped or failed, but the root cause remains unclear without understanding the precise timeout calculation. Additionally, the dashboard aggregates these events across all agents, making it difficult to isolate whether the issue stems from a specific trunk configuration or a broader SIP stack behavior within the BYOC instance. The current SLA requirements mandate a 99.9% uptime for inbound channels, and these unexplained timeout events are causing false positives in our compliance reporting. We require a clear definition of the timeout window and the specific conditions that trigger this metric in the Performance Dashboard. Understanding whether this is a local Genesys Cloud timeout or a propagated error from the SIP trunk provider is essential for optimizing the flow architecture and ensuring accurate metric reporting. Any insights into the underlying calculation methodology or configuration parameters that influence this timeout behavior would be greatly appreciated.