WebRTC Connection Drops at 50 Concurrent Threads - GC Softphone SDK

Voice & Telephony
1

Could someone clarify why the WebRTC connections are dropping unexpectedly during a moderate load test?

Error: WebSocket connection closed abnormally (code 1006)

Environment details:

  • Genesys Cloud EU1
  • JMeter 5.6.2 for load simulation
  • Custom softphone implementation using Genesys Cloud JavaScript SDK v3.4.12
  • Testing from AWS Singapore (ap-southeast-1)

The setup involves a simple JMeter script that simulates agents logging in and initiating outbound calls via the platform API. I am using the /api/v2/interactions endpoint to start conversations. The goal is to test the softphone’s stability under concurrent load.

Here is the sequence of events:

  1. JMeter threads ramp up to 50 concurrent users.
  2. Each user logs in and establishes a WebSocket connection to the Genesys Cloud signaling server.
  3. Calls are initiated successfully for the first 30-40 threads.
  4. Suddenly, random WebSocket connections start closing with code 1006. No specific error message is returned in the payload, just the abrupt disconnect.
  5. The softphone UI shows “Connection Lost” and fails to reconnect automatically.

I have checked the browser console and the network tab. The initial WebSocket handshake succeeds. The STUN/TURN server configuration seems correct as audio works fine for the calls that do not drop. The issue seems to correlate with the number of concurrent active WebSockets rather than API rate limits, as I am not seeing 429 errors on the REST calls.

Is there a known limit on concurrent WebRTC sessions per user or per tenant in the EU1 region? Or could this be a timeout issue related to the keep-alive interval in the SDK? I have tried adjusting the JMeter throughput controller, but the drops still occur around the same concurrency mark.

Any insights into troubleshooting this specific WebSocket behavior would be appreciated. I can share the JMeter thread group configuration if needed.

2

The documentation actually says WebRTC scaling limits are enforced at the org level, not the SDK level, which explains the 1006 drops. Check the concurrency thresholds in this guide: https://support.genesys.cloud/articles/websocket-concurrency-limits-eu1

3

Have you tried adjusting the reconnectDelay and maxReconnectAttempts in your SDK configuration? The 1006 error often indicates the server is closing the connection due to rapid reconnection attempts rather than a hard capacity limit. When simulating 50 concurrent threads from a single region like ap-southeast-1, you might be triggering rate limiting on the handshake phase.

In JMeter, ensure you are not creating a new WebSocket instance for every iteration. Reuse the connection object where possible. Also, check if your test plan includes a proper teardown phase. If connections are not cleanly closed, the server sees them as active, quickly hitting the concurrent session limit for that org.

Warning: Genesys Cloud enforces strict WebSocket concurrency limits per organization. Exceeding these limits will result in immediate connection drops regardless of your SDK version. Always monitor the activeConnections metric in the admin portal during load tests to stay within safe bounds.

4

The simplest way to resolve this is to adjust the JMeter thread group settings to prevent aggressive socket creation. The issue is not the WebRTC limit, but how the test script handles connection teardown. When you run 50 threads from a single IP range in ap-southeast-1, the handshake rate triggers security filters before the media even starts.

Error: WebSocket connection closed abnormally (code 1006)

This log indicates the server actively terminated the handshake. In your JMeter script, ensure the WebSocket sampler is set to reuse connections. Do not create a new instance per iteration. Add a constant timer between requests to mimic human behavior. This reduces the handshake frequency and avoids the 1006 drop. Also, verify that your SDK config includes keepAlive: true. Without it, idle connections drop quickly under load. This approach aligns with standard load testing practices for digital channels. It ensures the export logs remain clean and the audit trail is accurate for any compliance review later.