Does anyone know why our predictive outbound campaigns are failing with 408 Request Timeouts specifically when routing through our Singapore-based BYOC trunks, even though SIP registration status remains ‘Registered’ and latency is under 50ms?
Background
We operate 15 BYOC trunks across the APAC region, managed via a centralized SBC cluster. Our primary use case involves high-volume predictive dialing campaigns targeting local numbers. The environment consists of Genesys Cloud (v2024.1) connected to our custom SBCs (Asterisk-based, patched to latest stable). We utilize the standard Telephony Outbound API for campaign management and have configured dedicated outbound routes for each geographic trunk to ensure proper number normalization and carrier selection.
Issue
When launching a predictive campaign with a ratio of 1.5, approximately 15-20% of the initial dial attempts fail immediately with a 408 Request Timeout error in the Campaign Analytics dashboard. These failures occur within the first 200ms of the INVITE transmission. Interestingly, if we switch the campaign to ‘Power Dialer’ mode or reduce the predictive ratio to 0.1, the success rate improves significantly, suggesting a concurrency or resource exhaustion issue at the edge rather than a simple routing misconfiguration. The errors are isolated to the Singapore and Jakarta trunks; our Sydney and Tokyo trunks perform normally under identical campaign loads.
Troubleshooting
- Verified SIP credentials and trunk registration status via the Admin portal; all trunks show green ‘Registered’ status.
- Checked SBC logs: No corresponding 408s or rejections are visible in the local SIP traces. The SBCs appear to send the INVITE, but Genesys Cloud does not acknowledge it within the expected window.
- Inspected the
/api/v2/telephony/outbound/campaigns/{campaignId}/statsendpoint. Thedisposition_codeis consistently408_TIMEOUT. - Tested manual outbound calls via Architect flows using the same trunks; these succeed without issue.
- Reviewed carrier failover settings; no failover events are triggered during these failures.
We suspect a potential bottleneck in the Genesys Cloud edge connector handling concurrent SIP INVITEs for the APAC region, or perhaps a specific timeout configuration mismatch between our SBCs and the Cloud platform. Has anyone encountered similar behavior with high-ratio predictive campaigns on BYOC trunks in the Asia-Pacific timezone?