I’m completely stumped as to why the predictive routing queue metrics are failing to reconcile with actual SIP trunk failover events in our APAC deployment. We have fifteen BYOC trunks configured with active-passive failover logic, and while the failover itself triggers correctly within the 200ms threshold defined in our outbound routing policies, the analytics dashboard shows a significant lag in call volume attribution. Specifically, when the primary trunk in the Singapore region drops due to a carrier-specific SIP 503 Service Unavailable response, the secondary trunk in Jakarta picks up the load, but the predictive routing engine continues to report zero active calls for the originating queue for approximately 15 seconds. This gap creates a false negative in our service level calculations, causing the system to under-provision agents during peak shift swaps.
The environment is running the latest Genesys Cloud release, and we are monitoring via the PureCloud Analytics API v2. The discrepancy seems tied to how the system handles the SIP registration state during the transition. We have verified that the SIP credentials and outbound routing rules are identical across both regions, and the carrier failover settings are configured to prioritize latency-based routing. However, the audit logs indicate that the SIP session teardown on the primary trunk completes successfully, yet the predictive routing queue does not reflect the new active session until the next polling interval. Is there a known issue with the analytics aggregation engine when dealing with cross-region BYOC trunk failovers? We need to ensure that the queue metrics accurately reflect the real-time call state to maintain our SLA compliance. Any insights into configuring the analytics refresh rate or adjusting the SIP session handling parameters would be appreciated.