SIP 408 Request Timeout during JMeter load test on US1 BYOC trunk

Could someone explain the exact behavior of the US1 BYOC edge when handling rapid-fire INVITE requests from a single IP source? We are running a capacity planning test using JMeter 5.4.1 to simulate a sudden spike in inbound call volume. The test configuration uses a thread group with 200 concurrent users ramping up over 10 seconds.

We are consistently hitting SIP 408 Request Timeout errors after approximately 45 successful connections. The JMeter logs show the INVITE is sent, but no provisional 100 Trying or 180 Ringing response is received within the 30s timeout window configured in the sampler. The BYOC trunk status in the Genesys Cloud admin console (v2023.10.0) remains healthy, and the SIP logs on our proxy show the INVITEs are being forwarded correctly to the Genesys edge IP.

Is this a hard limit on concurrent INVITE processing per trunk or IP? We noticed the WebSocket connections for the associated agent desktops are stable, so it seems isolated to the SIP signaling path. Any insights on how to tune the JMeter keep-alive settings or if there is a specific Genesys configuration to increase the INVITE burst tolerance?

The documentation actually says…

Cause: BYOC edges enforce strict rate limits on INVITEs per IP. Rapid-fire requests from a single JMeter instance trigger throttling, resulting in 408 timeouts.

Solution: Distribute load across multiple virtual IPs or increase the ramp-up interval. Check the edge configuration for specific concurrency thresholds.

If you check the docs, they mention that distributing the load across multiple virtual IPs is the correct mitigation for these rate limits.

This aligns with what I see in bulk export pipelines where single-source bursts trigger throttling mechanisms designed to protect the edge.