SIP Trunk 408 Timeout on High Concurrency

Can anyone clarify why SIP trunks drop with 408 Request Timeout when JMeter simulates 200 concurrent calls? The Genesys Cloud edge seems to reject the INVITEs before the Architect flow even triggers. Is there a hidden rate limit on the SIP registration or media gateway that we are missing?

The main issue here is likely not a SIP trunk limit, but rather how the media gateway handles concurrent INVITEs during peak load. When JMeter fires 200 calls simultaneously, the gateway might be dropping packets before they reach the Genesys edge. This usually happens because the connection pool is exhausted or the TCP window size is too small.

<connection-pool>
 <max-connections>250</max-connections>
 <keep-alive-timeout>60s</keep-alive-timeout>
</connection-pool>

Try increasing the max connections on your gateway configuration. Also, check the TCP window scaling settings. Genesys Cloud expects steady traffic, not bursty spikes. If the gateway cannot handle the initial handshake, it returns a 408. As a scheduler, I see similar issues when sync jobs spike API usage. Smooth out the test load. Start with 50 concurrent calls and ramp up. This helps identify the exact breaking point. Verify the gateway logs for dropped packets. The fix is usually on the gateway side, not in Genesys.