Quick question about SIP trunk performance when scaling up. We are running a load test to validate our Genesys Cloud capacity before a major rollout. The environment is US-East, and we are using the standard SIP trunking configuration.
The issue appears when we push concurrent call volume past 150 calls per minute. Initially, everything works fine. But around the 180th concurrent call, we start seeing a spike in SIP 408 Request Timeout errors. The calls fail to connect, and the Architect flow logs show the IVR entry point is never reached. The JMeter script is configured to hold the call for 60 seconds after connection, simulating a long hold time.
I have checked the trunk settings. The max concurrent calls limit is set to 500, which should be sufficient. The timeout values are at default. I am wondering if there is a hidden rate limit on the SIP signaling layer that is not documented clearly for beginners. Or maybe the WebSocket connection for the IVR is dropping?
Here is the payload structure we are sending for the call setup in our test harness:
{
"from": "{"phoneNumber": "+15551234567"}",
"to": "{"phoneNumber": "+15559876543"}",
"callFlow": "{"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"}",
"timeout": 60000,
"metadata": {
"test_id": "load_test_001",
"concurrent_group": "group_A"
}
}
The error logs from the Genesys Cloud side just show a generic “Call failed” status. No specific SIP error code is returned in the REST API response, only in the raw SIP trace. We are using JMeter 5.4.1 with the custom SIP plugin. The network latency between our load generator and Genesys Cloud is under 20ms.
Any insights on what might be causing this bottleneck? Is it a trunk configuration issue or an Architect flow limitation? We need to stabilize this before production. Thanks for any help.
Make sure you verify your JMeter throughput ramp-up isn’t overwhelming the SIP registrar’s capacity.
<ThroughputController name="SIP Ramp" duration="300" loopLimit="10000" perUser="true" trackAllUsers="true">
<elementProperty name="LoadController.duration" value="300"/>
</ThroughputController>
Check if the 408s correlate with specific thread group peaks.
It depends, but generally… the SIP 408 timeouts observed during high-concurrency load tests are rarely indicative of a Genesys Cloud platform limitation. Instead, they typically point to configuration bottlenecks on the client-side SIP registrar or the network path between the load generator and the Genesys Cloud edge nodes. From an AppFoundry partner perspective, we frequently encounter this scenario when max_concurrent_calls parameters are not explicitly tuned for burst traffic.
The suggestion above regarding JMeter throughput is valid, but it misses the critical SIP-level keep-alive and retransmission settings. When scaling past 150 calls per minute, the default invite_timeout often expires before the Genesys Cloud signaling server can process the burst. You need to adjust the sip_registrar_timeout and retransmission_interval in your load test configuration to match Genesys Cloud’s expected handshake windows.
Consider implementing the following configuration adjustment in your SIP test client:
<Parameter name="sip_invite_timeout" value="30000"/>
<Parameter name="sip_retransmission_interval" value="500"/>
<Parameter name="max_retransmissions" value="5"/>
Additionally, verify that your SIP trunk configuration in Genesys Cloud has the codec_priority set to G711U or G729 to minimize processing latency during peak loads. If you are using a BYOC trunk, ensure the media_encryption is set to SRTP but that the key_exchange method is optimized for high-throughput scenarios. We have seen significant improvements in 408 error rates by aligning the jitter_buffer settings with the Genesys Cloud recommended defaults. Finally, check the network_latency between your load generator and the US-East edge. If the round_trip_time exceeds 50ms, you may need to increase the initial_invite_timeout to 45000 milliseconds to accommodate the network variance.