Need some help troubleshooting SIP 408 Request Timeout errors that appear specifically during the teardown phase of our load tests.
The environment is Genesys Cloud US1. We are using JMeter 5.6 with the SIP plugin to simulate agent call volumes. The goal is to validate how the platform handles rapid call termination spikes. The test script creates 50 concurrent SIP calls, holds them for 10 seconds, and then sends a BYE message to terminate the session.
The issue is not with call setup. INVITE and 200 OK responses are received correctly. The calls connect, and media flows as expected for the 10-second duration. The problem occurs immediately after the 10-second hold timer expires. JMeter sends the BYE request to the Genesys Cloud SIP trunk endpoint. For approximately 15% of the concurrent sessions, Genesys Cloud does not return a 200 OK response. Instead, the JMeter sampler times out after 5000ms, reporting a 408 Request Timeout.
We have verified the network path. There is no packet loss or high latency between the JMeter server and the US1 SIP trunk IPs. The same test script, running with only 10 concurrent calls, completes successfully with zero 408 errors. This suggests a potential resource contention or rate-limiting issue on the Genesys side when handling a burst of simultaneous teardown requests.
We are using standard SIP credentials and valid DIDs. The Architect flow is simple: Answer → Wait → Hangup. No complex logic is involved during the hangup phase.
Has anyone seen similar behavior with high-concurrency BYE requests? Is there a specific configuration in the SIP trunk or the Architect flow that needs adjustment to handle rapid teardowns? We want to ensure our capacity planning accounts for this potential bottleneck. Any insights on increasing the timeout or adjusting the SIP trunk settings would be appreciated.