Stuck on a persistent registration failure when scaling outbound load tests. The environment is Genesys Cloud in ap-southeast-1. Using a BYOC trunk via Twilio SIP. Target concurrency is 100 calls. JMeter 5.6.2 is driving the load. API version is v2.
The registration works fine at low concurrency (10-20 calls). When hitting 100 concurrent sessions, the SIP REGISTER requests start failing with 408 Request Timeout. The SIP server logs show the request leaving the JMeter client, but no response from the Genesys Cloud SIP proxy.
SIP/2.0 408 Request Timeout
Via: SIP/2.0/TCP 10.0.0.5:5060;branch=z9hG4bK-12345
From: <sip:[email protected]>;tag=123
To: <sip:[email protected]>;tag=456
Call-ID: abc-123
CSeq: 1 REGISTER
Content-Length: 0
The documentation states:
“SIP REGISTER requests must be completed within 30 seconds. If the carrier or trunk provider experiences latency, increase the registration timeout in the trunk configuration.”
I have already increased the SIP register timeout to 60s in the Genesys Cloud trunk configuration. The issue persists. The latency between the JMeter server (in ap-southeast-1) and the Genesys Cloud SIP endpoint is <5ms. This is not a network latency issue.
Is there a hidden rate limit on SIP REGISTER requests per trunk in ap-southeast-1? Or is the Genesys Cloud SIP proxy dropping registrations under load? The Twilio side shows no errors. The Genesys Cloud monitoring dashboard shows no alerts. The calls are failing before they even reach the Architect flow.
Need to understand if this is a platform limitation or a configuration error. Any insights on SIP registration behavior at scale in this region?
Have you tried adjusting the JMeter thread group pacing? The 408 timeout is likely a symptom of the SIP stack getting overwhelmed by the initial burst of REGISTER requests, rather than a hard limit on the BYOC trunk itself. Genesys Cloud handles concurrent registrations, but if 100 threads hit the SIP proxy at the exact same millisecond, the connection queue fills up before the handshake completes.
In my recent load tests for call capacity planning, I found that staggering the start time reduces this pressure significantly. Instead of a pure “Start all threads at once” approach, use a ramp-up period.
<!-- JMeter Thread Group Config -->
<elementProp name="ThreadGroup.main_controller" elementType="ThreadGroupMainController">
<stringProp name="ThreadGroup.main_controller.sampler_class">org.apache.jmeter.protocol.java.sampler.JavaSampler</stringProp>
<stringProp name="ThreadGroup.num_threads">100</stringProp>
<!-- Ramp up over 30 seconds to distribute REGISTER requests -->
<stringProp name="ThreadGroup.ramp_time">30</stringProp>
<boolProp name="ThreadGroup.scheduler">false</boolProp>
</elementProp>
Also, check the WebSocket connection limits if you are using WebRTC alongside SIP. The ap-southeast-1 region has slightly higher latency, which can exacerbate timeout issues when connections are opened simultaneously. Ensure your SIP client is configured with a reasonable retry interval. If the first REGISTER fails due to a transient 408, a quick retry often succeeds once the queue clears.
This usually happens because the SIP stack has a finite number of concurrent registration handlers. By spreading the load over 30 seconds, you keep the request rate within the comfortable throughput zone for the Genesys Cloud SIP interface. It is not about the total concurrency, but the rate of arrival. Try reducing the ramp-up time to 10 seconds if 30 is too slow for your test cycle, but avoid setting it to zero.