Why does this config cause immediate WebSocket 1006 Abnormal Closure errors when scaling concurrent WebRTC sessions beyond 500?
Running JMeter 5.6.2 from Singapore against Genesys Cloud platform_api. The test script simulates softphone login and media stream establishment using the WebRTC SDK v3.1.0. The goal is to validate call capacity planning for a large contact center deployment.
The test environment uses a standard Architect flow with no custom Data Actions or complex routing logic. The flow simply answers the call and plays a short tone. The JMeter script handles the WebSocket handshake, sends the connect message, and then initiates the media stream.
At 100 concurrent users, the test runs smoothly. At 300 concurrent users, occasional 403 Forbidden errors appear on the handshake, which is expected due to rate limiting. However, at 500 concurrent users, a significant portion of established WebSocket connections drop immediately after the connect message is acknowledged. The error is not a 403 or 503. It is a clean disconnect with code 1006.
The JMeter logs show the following pattern:
{
"type": "error",
"code": 1006,
"reason": "Abnormal Closure",
"timestamp": 1715623400000,
"sessionId": "wc-12345-abcde"
}
The Genesys Cloud platform_api does not return a specific HTTP error for these drops. The WebSocket connection simply closes. This suggests the issue might be related to resource exhaustion on the server side or a limit on concurrent WebSocket connections per organization.
Has anyone encountered this specific behavior when testing WebRTC softphone concurrency? Is there a documented limit on simultaneous WebSocket connections for WebRTC sessions in Genesys Cloud? The current setup uses default settings for WebSocket keep-alive and heartbeat intervals.
Any insights on how to adjust the JMeter script or Genesys Cloud settings to handle this scale would be appreciated. The current error rate is around 40% at 500 concurrent users, which is not acceptable for production load testing.