So I’m seeing a very odd bug with SIP registration timeouts on our Singapore BYOC trunks. Agents are getting 408 errors that aren’t triggering the configured failover logic, causing dropped calls during peak hours.
408 Request Timeout: SIP/2.0 408 Request Timeout
Why is the failover not activating despite the trunk being marked as unhealthy?
Have you tried adjusting the SIP registrar timeout settings specifically for your APAC region, because the default 30-second window might be too aggressive for high-latency cross-border connections? In Zendesk, we didn’t have to worry about SIP trunks at all since everything was digital-first, but migrating to Genesys Cloud means embracing the PSTN reality where network jitter can cause these 408 Request Timeouts before the failover logic even kicks in. The issue isn’t necessarily that the trunk is unhealthy, but that the registrar gives up waiting for the 200 OK response before the failover timer expires. You need to increase the registration_timeout parameter in your BYOC trunk configuration. Try setting it to 45 seconds instead of the default 30. This gives the Singapore node enough breathing room to respond without triggering a premature failure state. Also, check your health check interval. If it’s set to 10 seconds, the trunk might be marked unhealthy too quickly. A common fix during migrations is to align the SIP timeout with the actual network latency of your region. For APAC, adding a 15-second buffer is usually safe. Make sure your failover trunk has a lower priority weight so it doesn’t interfere with primary routing unless necessary. This approach saved us during our own migration from Zendesk’s digital channels to GC’s unified comms. The key is patience with the SIP handshake. Don’t rush the failover logic. Adjust the timeout, monitor the logs for 200 OK delays, and verify the trunk status in the Admin console. This simple tweak often resolves the 408 errors without needing complex routing rules.