Looking for some advice on troubleshooting this specific bottleneck we are hitting during our capacity planning phase. We are running a JMeter script to simulate concurrent inbound calls using the WebRTC BYOC implementation. The setup targets the Singapore region (ap-southeast-1) and uses the standard WebSocket handshake endpoint provided in the developer documentation. Everything works perfectly fine up to around 400 concurrent sessions. Once we push past that mark, specifically around 450-500 active connections, we start seeing a significant spike in WebSocket disconnections. The client side logs show a clean closure with code 1001, but the server side does not log any corresponding error or warning. This is happening well before we hit the documented API rate limits for the REST endpoints, so it seems isolated to the media signaling layer. We are using the latest version of the Genesys Cloud WebRTC SDK and have verified that the TURN server credentials are being rotated correctly every hour. The network latency from our test environment in Singapore to the Genesys edge nodes is consistently under 15ms, so packet loss or jitter does not seem to be the culprit. The JMeter configuration is set to ramp up users linearly over 30 seconds with a 10-second think time between call attempts. We have also checked the firewall rules on our end and confirmed that UDP ports 3478 and 50000-65000 are fully open. Is there a hidden connection limit per tenant or per application key that is not clearly documented? Or could this be related to how the platform handles WebSocket keep-alive packets under high load? We need to scale this to 2000 concurrent sessions for our next quarter’s SLA requirements, so understanding this hard ceiling is critical. Any insights on where to look next would be appreciated.