I’ve spent hours trying to figure out why SIP INVITE requests are returning 408 Request Timeout errors when JMeter 5.6.2 threads exceed 50 from Singapore.
Running a simple SIP load test against Genesys Cloud. The test works fine at 20 threads but fails consistently at 50. Using the standard SIP plugin. Any ideas on the default SIP connection limits?
Not a SIP expert here, just an integration guy. But 408 usually means the edge dropped the packet before Genesys even saw it.
If you are hitting Singapore, are you routing through the Asia Pacific edge? The default timeout for INVITE is pretty strict. If JMeter holds the connection open waiting for 100 Trying or 180 Ringing, and the network latency spikes, the edge might kill it.
Check your JMeter SIP plugin settings. Make sure “Send Request Timeout” is higher than default. Also, look at the edge logs. If you see the INVITE arrive but no response, it’s likely a firewall or NAT issue on your test box, not Genesys.
One thing to check in Genesys: ensure the SIP trunk you are testing against has the correct IP allow-list. If your test machine IP changes (dynamic IP), the edge might block it silently or timeout.
Try lowering the concurrency to 30 and increasing the ramp-up time. See if it stabilizes. If it does, you are hitting a rate limit or resource cap on the edge, not a bug.
spot on about the edge dropping the packet. i’ve seen this exact 408 behavior when JMeter threads spike without proper keep-alive settings. the issue isn’t just latency, it’s that the SIP plugin defaults to a short timeout for the initial handshake. if the Singapore edge is busy, that 3s default gets eaten up fast.
you need to bump the request_timeout in the SIP Config element. also, make sure you’re using a realistic User-Agent string. Genesys Cloud sometimes rate-limits generic “SIP-JMeter” agents. here’s the config tweak that fixed our load tests:
<com.meterware.http.protocol.HttpProtocolConfig>
<stringProp name="HTTPSampler.domain"></stringProp>
<stringProp name="HTTPSampler.port"></stringProp>
<boolProp name="HTTPSampler.path"></boolProp>
<stringProp name="HTTPSampler.protocol"></stringProp>
<stringProp name="HTTPSampler.concurrentPool">50</stringProp>
<intProp name="HTTPSampler.connect_timeout">10000</intProp>
<intProp name="HTTPSampler.response_timeout">15000</intProp>
<stringProp name="HTTPSampler.useragent">GenesysCloud-WebRTC/1.0</stringProp>
</com.meterware.http.protocol.HttpProtocolConfig>
bumping response_timeout to 15s usually clears the 408s. check your edge logs if it persists.