Could someone explain why we are hitting SIP 408 Request Timeout errors when ramping up our JMeter load test for Genesys Cloud BYOC trunks? We are trying to validate the SIP stack performance under stress, specifically targeting the concurrent call setup capacity.
Our current test plan uses a simple loop controller to initiate INVITE requests to the Genesys Cloud SIP URI. We start with a low concurrency of 10 calls per second and ramp up by 10 every 30 seconds. The test runs smoothly until we hit around 150 concurrent active INVITEs. At this point, the response times spike, and we start seeing a significant number of 408 Request Timeout errors from the Genesys Cloud SIP proxy. The errors are not consistent; they seem to correlate with the peak of the ramp-up phase.
We have checked our network connectivity and there are no packet drops or latency issues on our end. The JMeter logs show the INVITE being sent, but the timeout occurs before a 100 Trying or 200 OK is received. We are using the latest JMeter version (5.6.2) with the SIP plugin. Our request payload is standard, but here is the snippet we are using for the INVITE header:
INVITE sip:genesyscloud.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK12345
Max-Forwards: 70
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=12345
Call-ID: 12345@192.168.1.100
CSeq: 1 INVITE
Contact: <sip:tester@192.168.1.100:5060>
Content-Type: application/sdp
Content-Length: 123
We are based in Asia/Singapore, but the Genesys Cloud region is US-East. Could this latency be contributing to the 408 errors during high concurrency? We have tried increasing the timeout settings in JMeter, but the errors persist. Is there a known limit on the number of concurrent SIP INVITEs Genesys Cloud can handle before returning 408? Any advice on how to structure our JMeter test to avoid triggering these timeouts would be greatly appreciated. We want to ensure our test accurately reflects the platform’s capacity without being limited by our test setup.