Trying to understand why our custom failover logic in Architect is not triggering correctly when a primary BYOC trunk drops registration status during peak traffic windows in the Asia/Singapore timezone. We are managing 15 distinct BYOC trunks across multiple carriers, and the current flow relies on a Data Action to fetch real-time trunk health metrics before routing outbound calls. The issue manifests as a silent failure where the flow proceeds to the ‘Failed’ path even though secondary trunks show active SIP registration status in the Admin console.
The environment is running Genesys Cloud Platform v2024.1 with the latest Architect updates. The specific error observed in the flow logs is a 503 Service Unavailable returned by the internal routing engine when attempting to bind the call leg to the secondary trunk ID. This occurs despite the SIP credentials being valid and the carrier reporting healthy keep-alive packets. We have verified that the outbound routing rules are correctly prioritized, with the primary trunk set to ‘Preferred’ and the secondary set to ‘Failover’. However, the latency between the trunk status check and the actual call initiation seems to exceed the platform’s default timeout threshold, causing the flow to abort before the failover logic can engage.
Is there a known limitation or configuration tweak required for handling rapid state changes in BYOC trunk availability within Architect flows? We suspect the issue might be related to how the platform caches trunk registration states during high-concurrency events, but we need confirmation on whether this is a platform behavior or a misconfiguration on our end. Any insights into optimizing the Data Action polling interval or adjusting the SIP timeout settings for outbound legs would be greatly appreciated. We are currently seeing a 15% drop in successful outbound connections during these peak windows, which is impacting our SLA targets significantly.