Struggling to figure out why our secondary BYOC trunks in the Singapore region are consistently returning SIP 408 Request Timeout errors specifically during the transition window from primary to secondary carrier. We are managing fifteen BYOC trunks across APAC, and while the primary trunks handle the bulk of the load without issue, the failover logic seems to be triggering prematurely or incorrectly. The environment is running Genesys Cloud Platform version 2023-11.2, with the BYOC edge nodes updated to the latest available patch as of last week.
The issue manifests when we attempt to route outbound calls via Architect flows that utilize the Make Outbound Call widget with a specific BYOC trunk selection. When the primary trunk health check fails (which we simulate for testing), the system attempts to route to the secondary trunk. Instead of establishing the session, we receive a 408 error from the carrier gateway after exactly 3.5 seconds. The SIP INVITE is sent, but the 100 Trying response is never received back from the carrier, leading to the timeout.
We have verified the SIP credentials and registration status for all fifteen trunks, and they show as Registered in the admin console. The outbound routing rules are configured to use a round-robin strategy with failover enabled. However, the logs indicate that the failover is not waiting for a proper 4xx or 5xx rejection before timing out. This suggests a potential misconfiguration in the SIP timeout settings or a latency issue specific to the Singapore edge node.
Has anyone encountered similar behavior with carrier-specific quirks in the APAC region? We are particularly concerned about the impact on our analytics reporting, as these timeouts are skewing our call success metrics. Any insights into the correct configuration for SIP timeout values in the BYOC trunk settings would be appreciated. Reference: Genesys Docs