Looking for advice on handling WebRTC connection stability during high-concurrency load testing.
We are running a JMeter 5.6.2 script from Singapore to simulate softphone login and media stream establishment. The target environment is Genesys Cloud (platform_api integration). Everything works fine up to 150 concurrent threads. Once we push past that number, specifically around 200 threads, we start seeing a significant drop in successful WebSocket connections.
The error is not a standard 429 rate limit. Instead, the WebSocket handshake completes, but the initial SDP exchange fails or times out. The client receives a generic transport error, and the call never enters the ‘Connected’ state in the dashboard.
Here is the payload structure we are using for the initial registration request via the REST API before switching to the WebSocket endpoint:
{
"endpoint_type": "softphone",
"user_id": "user_12345",
"device_id": "device_67890",
"capabilities": {
"audio_codecs": ["opus", "g722"],
"video_codecs": []
}
}
After this REST call succeeds, JMeter establishes the WebSocket connection to the media relay. We are observing that the WebSocket connection count in the Genesys admin console plateaus, even though JMeter shows 200 active threads. It seems like the platform is silently dropping excess connections or there is a hidden limit on concurrent softphone sessions per org or per region.
Is there a specific header or configuration in the JMeter WebSocket sampler that needs adjustment for high throughput? Or are we hitting a hard cap on softphone capacity that isn’t documented clearly? We have checked the API rate limits for the REST endpoints, and those are fine. The issue seems isolated to the media/WebRTC layer. Any insights on how to tune this or if there is a known limit we are missing?