We are observing a critical discrepancy in call handling behavior when our primary SIP trunk reaches capacity and initiates failover to the secondary provider. The issue manifests specifically within our Architect flow logic designed to manage queue overflow and dynamic routing.
When the primary trunk is saturated, the flow attempts to route calls to the secondary trunk. However, instead of a seamless transition, we are receiving a high volume of ‘480 Temporarily Unavailable’ responses from the secondary provider, accompanied by an average delay of 45 seconds before the call is either dropped or re-routed to voicemail. This is significantly impacting our Service Level Agreement (SLA) metrics for Average Speed of Answer (ASA).
Our current configuration utilizes a standard SIP trunk group with failover enabled. The primary trunk is configured with a concurrency limit of 500 channels, and the secondary is set to accept overflow. We have verified that the secondary trunk is provisioned correctly and capable of handling the overflow volume. However, the latency suggests that the Genesys Cloud platform is not immediately recognizing the primary trunk’s saturation state or is introducing an unnecessary delay before attempting the failover.
We are using Genesys Cloud version 2023-10 GA. The Architect flow includes a ‘Make Call’ block connected to the SIP trunk group, followed by a ‘Queue Call’ block. There are no custom JavaScript blocks involved in this specific path. We have also checked the ‘Conversation Detail’ view, which shows the call state as ‘Ringing’ for an extended period before the failure occurs.
Could the community provide insights into whether this behavior is related to the SIP 183 Session Progress message handling or if there are specific flow adjustments required to minimize the failover latency? We need to ensure that the overflow logic triggers immediately upon reaching the concurrency limit, rather than waiting for a timeout.