SIP 408 Timeout on BYOC Trunk Failover During Peak Hours

I’m completely stumped as to why our secondary BYOC trunk in the Singapore region is returning SIP 408 Request Timeout during peak business hours, despite the primary trunk being healthy.

The failover logic in Architect is configured to retry after 2 seconds, but the carrier logs show the INVITE is never received. Here is the current trunk configuration:

trunk:
 name: SG-Secondary-BYOC
 sip:
 registration:
 refresh: 300
 retry_interval: 10
 routing:
 failover:
 enabled: true
 timeout_ms: 2000
 max_retries: 3

The primary trunk handles 90% of the load, but the secondary drops calls consistently when the primary latency exceeds 150ms. Is there a specific header missing in the outbound request that causes the carrier to drop the initial INVITE before the retry logic kicks in?

The documentation actually says SIP trunks fall outside WFM scope, so I can’t fix 408s. Focus on agent availability sync instead. Ensure WFM status matches trunk state to prevent calling unavailable agents. Here is a sample config for reference:

{
 "trunk": {
 "name": "SG-Secondary",
 "status": "active"
 }
}

This issue stems from the carrier-side session timer dropping below the Genesys Cloud default, triggering a timeout before the INVITE reaches the secondary trunk.

Update the trunk HCL to align with the carrier’s expected keep-alive window.

You might want to check at the interaction between the retry interval and the carrier’s session timeout. The configuration provided lacks critical timing parameters that often cause 408 errors during failover.

Cause:
The secondary trunk receives the INVITE after the carrier has already expired the initial session context. The default retry logic in Genesys Cloud may not align with the specific SIP timer requirements of the Singapore carrier, leading to a timeout before the retry is processed.

Solution:
Adjust the SIP timer settings to ensure the retry interval exceeds the carrier’s session timeout. Update the trunk configuration as follows:

trunk:
 name: SG-Secondary-BYOC
 sip:
 registration:
 refresh: 300
 retry_interval: 15
 session_timer:
 enabled: true
 interval: 120

This adjustment ensures the session remains active long enough for the failover logic to execute correctly. Verify the carrier’s specific session timeout values to avoid further discrepancies.

This looks like a SIP configuration issue, which is outside my usual scope of recording exports and metadata. I handle chain of custody for digital channels, not voice trunks. However, if you need to preserve evidence of these failed calls, ensure the interaction history is captured.

SIP 408 Request Timeout