Trying to make sense of why the SIP trunks are dropping connections with 408 Request Timeout errors when running a JMeter script that sends 500 concurrent SIP OPTIONS messages per second to the Genesys Cloud SIP URI in ap-southeast-1. The goal is to validate the keep-alive handling capacity of the platform under high concurrency. The JMeter config uses a Thread Group with 500 users, ramp-up time 10 seconds, and loop count 1. Each thread sends a raw SIP OPTIONS request to the trunk URI every 2 seconds. The platform returns 200 OK for the first 100 requests, but then starts returning 408 Request Timeout for subsequent requests. The error logs show that the SIP server is not responding within the expected timeout window. The network latency between the JMeter server and the Genesys Cloud edge is less than 10ms. The SIP trunk configuration allows for unlimited concurrent calls, but the keep-alive mechanism seems to be getting overwhelmed. Is there a limit on the number of concurrent SIP OPTIONS requests that the platform can handle? Or is there a specific configuration setting that needs to be adjusted to increase the keep-alive capacity? The JMeter test plan is attached below for reference. Any insights on how to tune the SIP trunk settings or the JMeter script to avoid these timeouts would be greatly appreciated. The current setup is causing false positives in the load test results, making it difficult to assess the true capacity of the SIP trunks.
The quickest way to solve this is to realize that flooding SIP trunks with OPTIONS requests is not a standard WFM concern, but it does impact system availability for scheduling. High concurrency like 500 requests per second can trigger rate limiting or timeout thresholds on the platform side, regardless of the region. The 408 errors indicate the server is dropping connections before processing, which is expected behavior under extreme load tests that exceed normal operational parameters.
For workforce management purposes, focus on ensuring that schedule adherence metrics are not skewed by these infrastructure tests. If you must run such tests, coordinate with platform support to establish a baseline for expected behavior. Avoid running these floods during peak scheduling windows or when publishing weekly schedules, as transient network issues could disrupt API calls for shift swaps or time-off requests. Keep the test isolated to off-hours to prevent any collateral impact on agent self-service functions.
The way I solve this is by:
- Reducing JMeter thread concurrency to match standard trunk capacity limits.
- Verifying that keep-alive intervals in the SIP trunk settings are not conflicting with the test frequency.
- Monitoring the Performance Dashboard for queue activity spikes rather than raw SIP metrics, as those provide clearer business impact data during load tests.