Could someone explain why our inbound voice flow is intermittently failing to regenerate SIP trunks when the queue occupancy exceeds 85% during the 08:00 CET morning rush?
We are operating on Genesys Cloud v2.9.1 and have configured a specific Architect flow designed to handle high-volume inbound calls for our Paris operations. The flow logic includes a ‘Get SIP Trunk’ data action to dynamically route calls based on agent availability. However, under heavy load, the dashboard indicates a spike in ‘Failed to Connect’ errors, specifically returning a 408 Request Timeout from the underlying telephony service.
The Performance Dashboard shows that while the queue is active, the average wait time for the SIP trunk regeneration step jumps from the standard 200ms to over 3 seconds. This latency correlates directly with the 408 errors observed in the conversation detail views. We have verified that the SIP trunk configuration in the Administration section is stable and does not show any downtime or registration issues during these periods.
The issue appears isolated to the dynamic routing logic within the flow, as static routing to the same trunk does not exhibit this behavior. We are concerned that this timeout is causing a significant drop in Service Level Agreement (SLA) compliance for our French-speaking agents, as calls are being dropped before reaching the queue.
Has anyone encountered similar latency issues with dynamic SIP trunk lookups in Architect flows under high concurrency? We need to determine if this is a known limitation of the current platform version or if there is a specific configuration adjustment required to optimize the data action performance. We are currently reviewing the flow execution logs, but the error details are limited to the generic timeout message.