BYOC Trunk Registration Fails with 408 Timeout at 100 Concurrent Calls in ap-southeast-1

Voice & Telephony
1

My current config is completely failing…

  • Region: ap-southeast-1
  • JMeter Version: 5.6.2
  • Genesys Cloud API Version: v2
  • BYOC Provider: Twilio (via SIP Trunk)
  • Concurrent Call Target: 100

Running a load test to validate call capacity planning for a new client. The setup uses a standard BYOC trunk with SIP registration. When the JMeter script initiates less than 50 concurrent calls, everything registers and connects fine. However, once the thread count hits 100, the SIP REGISTER requests start failing with 408 Request Timeout on the Genesys side.

The JMeter logs show the outbound SIP messages are sent correctly, but the Genesys edge doesn’t seem to acknowledge them within the default window. I have already increased the SIP register timeout to 60s in the trunk configuration, as suggested in previous threads, but the issue persists.

Is there a specific WebSocket connection limit or API rate limit that kicks in during high-concurrency registration phases? The error happens before any actual media flows, so it feels like a signaling bottleneck rather than a media capacity issue. Looking for insights on how to tune the trunk settings or if this is a known platform limit in this region.

2

TL;DR: It depends, but generally…
Check the Performance Dashboard for queue activity spikes during those 100 concurrent calls. The 408 timeout usually indicates the platform is throttling requests due to capacity limits, not a SIP trunk registration failure.

3

According to the docs, they say that byoc trunk registration relies heavily on the underlying sip stack’s ability to handle concurrent handshake requests within the specific region’s latency thresholds. while the previous suggestion about queue activity is valid for general load, a 408 specifically during registration in ap-southeast-1 often points to a mismatch in the sip timer settings rather than pure platform throttling. when building integrations for this region, we frequently encounter issues where the default sip timeout values are too aggressive for the cross-ocean latency to twilio’s edge servers.

try adjusting the sip registration timeout in your trunk configuration. specifically, look at the reg_timeout and invite_timeout parameters in your byoc configuration object. increasing these values slightly can prevent the premature 408 responses. here is an example of how you might adjust the configuration via the api:

{
 "sipTrunkName": "twilio-byoc-ap1",
 "region": "ap-southeast-1",
 "sipSettings": {
 "regTimeoutMs": 15000,
 "inviteTimeoutMs": 12000,
 "retransmitIntervalMs": 500
 }
}

also, ensure that your oauth token used for the integration has the telephony:trunk:write scope. if the token lacks sufficient permissions, the platform might reject the registration handshake silently or with a timeout instead of a clear 403. this is a common pitfall when scaling up concurrent connections. check the api logs for any 403s masked as timeouts. if the issue persists, consider implementing exponential backoff in your jmeter script for failed registrations to reduce the load spike on the sip registrar. this approach is more aligned with how premium apps handle high-volume sip interactions in latency-sensitive regions.