Can anyone clarify the expected behavior of real-time digital channel metrics when a SIP trunk failover occurs in the Asia/Singapore region? We are managing fifteen BYOC trunks with a strict failover logic that triggers within 200ms upon primary carrier timeout. While the voice traffic routes correctly to the secondary provider, the associated digital messaging queues linked to these trunk groups exhibit significant data lag in the Genesys Cloud analytics dashboard.
The issue manifests specifically during high-volume inbound spikes. When the primary trunk drops, the Architect flow switches the routing path, but the digital queue occupancy metrics continue to reflect the primary trunk’s status for up to four minutes. This creates a false positive for agent availability, causing the predictive outbound scheduler to assign tasks based on stale capacity data. The discrepancy is visible in the /api/v2/analytics/queues/realtime endpoint, where the activeAgents count does not align with the actual connected sessions.
We have verified that the SIP registration remains stable, and the carrier-specific quirks regarding session timers have been adjusted in the trunk configuration. However, the analytics engine seems to cache the trunk state rather than polling the active routing decision. This is particularly problematic for our reporting SLAs, as we require sub-minute accuracy for queue performance indicators.
Here is the sample payload discrepancy observed during the failover window:
{
"queueId": "abc-123",
"timestamp": "2023-10-27T08:15:00Z",
"metrics": {
"activeAgents": 15,
"actualConnected": 8,
"trunkStatus": "PRIMARY_ACTIVE",
"routingState": "SECONDARY_ACTIVE"
}
}
Is there a specific configuration parameter or API call that forces an immediate refresh of the digital queue metrics during a trunk failover event? We are currently running Genesys Cloud v2.63 and have exhausted the standard troubleshooting steps for analytics latency.