WebSocket Connection Drops During High-Concurrency BYOC Load Test

Could someone explain why WebSocket connections are dropping during a high-concurrency load test in our BYOC environment?

Running a JMeter script to simulate 500 concurrent inbound calls via the WebRTC endpoint. The setup uses the standard Genesys Cloud BYOC configuration with our own media servers. At around 300 concurrent sessions, the WebSocket connections start failing with a 1006 (Abnormal Closure) error. The logs show the connections are being dropped by the server side, not the client.

The JMeter config is set to ramp up 50 users every 10 seconds. The API calls to create the calls are succeeding (201 Created), but the WebSocket handshake fails shortly after. Checking the Genesys Cloud logs, there are no obvious error messages, just the connection termination.

We are using the latest version of the Genesys Cloud Web SDK. The environment is set to production, and we have verified that the WebSocket endpoints are accessible. The load test is running from a single JMeter instance to simulate a burst of traffic.

Is there a known limit on the number of concurrent WebSocket connections per BYOC tenant? Or could this be a timeout issue related to the media server configuration? We have checked the network connectivity and there are no firewall rules blocking the traffic. The issue seems to be specific to the high concurrency level, as lower concurrency tests (e.g., 100 concurrent calls) work without any issues.

Any insights on how to troubleshoot this further would be appreciated. We are looking to validate the capacity of our BYOC setup before going live with a larger campaign. The current behavior is preventing us from scaling the load test to the desired concurrency level.

It varies, but usually the WebSocket concurrency limit in your BYOC configuration needs explicit tuning. When migrating from Zendesk, we often assumed infinite scaling for digital interactions, but Genesys Cloud’s media infrastructure requires specific capacity planning. The 1006 error typically indicates that the media server is rejecting connections because the concurrent session threshold was reached. Check your BYOC media server settings in the Admin console under Telephony > Media Servers. You likely need to increase the Max Concurrent Calls value or add additional media server instances to handle the 500-session load.

In Zendesk, ticket volume was decoupled from real-time media streams, so this bottleneck was rare. Here, the WebRTC handshake is resource-intensive. Ensure your NAT traversal settings are also optimized, as high concurrency can exhaust STUN/TURN resources. A quick fix is to scale out your media server deployment group. Monitor the Media Server Health dashboard during the test to identify which nodes are hitting capacity. This configuration step is often overlooked during migration from ticketing systems to unified communications platforms.

have you tried adjusting the genesyscloud_byoc resource limits? the 1006 error often stems from hitting the default concurrent session cap. check your terraform state for max_concurrent_sessions or similar constraints. increasing this in the provider config usually resolves the drop-off without touching media server settings.