SIP 408 Request Timeout - No Response Within 32000ms
The primary BYOC trunk (Bandwidth.com) is rejecting outbound calls from the Singapore region Architect flow when the secondary carrier (Telnyx) is triggered for failover. The flow is designed to handle 408 errors by retrying on the next trunk in the list, but the retry logic seems to be bypassing the registration check entirely.
Environment details:
- Genesys Cloud Version: 2023-10
- BYOC Trunks: 15 active (mix of Bandwidth, Telnyx, Twilio)
- Region: Singapore (ap-southeast-1)
- Flow Version: v4.2 (Architect)
The SIP registration status shows as ‘Registered’ for both carriers in the admin console, yet the actual SIP INVITE times out on the failover leg. Is there a known issue with how the outbound routing engine handles concurrent failover requests during high concurrency periods in the APAC timezone? The logs indicate the initial call succeeds, but any subsequent call within a 200ms window triggers this timeout on the backup trunk.
Has anyone seen similar behavior with Bandwidth’s specific SIP stack requiring a longer handshake timeout before failover is permitted?
The way I solve this is by decoupling the SIP timeout from the Data Action execution. The issue often stems from the flow waiting for a synchronous ServiceNow ticket creation via REST API while the SIP INVITE is pending. If the ServiceNow endpoint takes >30s, the BYOC trunk drops the connection before the retry logic can engage.
Move the ticket creation to an asynchronous webhook payload instead of a blocking Data Action. This keeps the media path clean. Configure the flow to send a lightweight JSON payload to a middleware service that queues the ServiceNow incident. This prevents the 408 from being misinterpreted as a trunk failure.
See the fictional support article for async payload patterns: Genesys Cloud Async Webhook Best Practices.
Also, verify that your Telnyx trunk registration is active in the Singapore region. A 408 during failover often indicates the secondary trunk is not registered, not just a timeout. Check the trunk status in Administration > Telephony > Trunks.
SIP 408 Request Timeout - No Response Within 32000ms
It depends, but generally… Zendesk never had this specific SIP complexity, so migrating from their digital-only setup to GC voice requires checking trunk health first. Ensure your AWS Direct Connect latency isn’t masking the 408 as a registration failure.