Background
We are currently validating our Genesys Cloud deployment for a large-scale migration. The goal is to simulate 500 concurrent inbound calls to verify that our BYOC trunk configuration and Architect routing logic hold up under stress. We are using JMeter 5.6 with the custom SIP plugin to generate traffic. The environment is in the US East region. Our current BYOC trunk is configured with a max capacity of 200 channels. We know this is a bottleneck, but we want to see how the platform handles the overflow and if it gracefully rejects calls or if it causes instability in the existing sessions.
Issue
When the concurrent call volume exceeds the trunk capacity, we are not getting the expected SIP 600 Busy Here responses from the Genesys Cloud edge. Instead, about 30% of the excess calls are hanging for 15 seconds before dropping with a generic 500 Server Error. The JMeter logs show the INVITE request is sent, but no final response is received within the timeout window. This is causing our load test scripts to fail and skewing our data on actual trunk utilization. We need to understand if this is a platform protection mechanism or a misconfiguration in our SIP trunk settings.
Troubleshooting
We have checked the following:
- Verified that the SIP trunk credentials in Genesys Cloud match our SIP provider exactly.
- Increased the JMeter thread group ramp-up time to ensure a smooth increase in load, but the issue persists once the 200-channel limit is hit.
- Checked the Genesys Cloud System Status page; no outages reported in the US East region.
- Reviewed the SIP trace in Genesys Cloud. The traces show the INVITE arriving at the edge, but no corresponding SIP response is logged in the trace viewer for the failed calls. It is as if the edge is swallowing the request.
- Confirmed that our SIP provider is sending the calls correctly and not rate-limiting on their end.
Is there a specific setting in the BYOC trunk configuration that controls how overflow traffic is handled? We want to ensure that excess calls are rejected immediately with a proper SIP response code rather than timing out. Any insights on how to configure this for accurate load testing would be appreciated.