Genesys Cloud WebRTC Softphone disconnects at 50 concurrent users with STUN errors

Voice & Telephony
1
  • WebSocket logs showing 1006 Abnormal Closure when load test hits 50 concurrent sessions using JMeter WebSampler plugin.
  • Environment: Genesys Cloud EU1 region, testing from AWS Singapore (ap-southeast-1).
  • SDK version: genesys-cloud-web-sdk v2.45.0.
  • Browser: Chrome 120.0.6099.130 (headless mode via Puppeteer).
  • The softphone connects successfully for the first 45-48 users. After that, new connections fail to establish media streams.
  • Error in browser console: Failed to create offer: Operation not allowed at this time followed by STUN server unreachable.
  • Network tab shows 200 OK on /api/v2/platform/user/me but WebSocket handshake fails with 403 Forbidden after rate limit threshold.
  • JMeter config: Thread Group with 100 threads, ramp-up 60 seconds, loop count 10. Each thread initiates a call via /api/v2/finesse/users/{id}/interactions.
  • We suspect the issue is related to TURN server capacity or WebSocket connection limits per tenant.
  • Current API rate limit headers show X-RateLimit-Limit: 100 and X-RateLimit-Remaining: 0 when errors start.
  • Tried increasing WebSocket keep-alive interval to 30 seconds, but no improvement.
  • Check if there is a hidden limit on concurrent WebRTC sessions per tenant or per IP address.
  • Logs show iceConnectionState: failed for all failed attempts after the 48th user.
  • No issues with single-user tests or low concurrency (10 users).
  • Question: Is there a documented limit on concurrent WebRTC softphone connections in Genesys Cloud?
  • How to properly handle 429 Too Many Requests during WebSocket reconnection attempts in the Web SDK?
  • Should we implement exponential backoff in the JMeter script before retrying the WebSocket connection?
  • Any known issues with STUN/TURN server capacity in EU1 region during peak load?
2

Make sure you verify the STUN server connectivity from the AWS Singapore region. Genesys Cloud EU1 endpoints may have latency issues that cause WebSocket drops under high concurrency.

Check if the JMeter script is reusing WebSocket connections efficiently. Headless Chrome instances can exhaust local port ranges or memory limits when scaling to 50 concurrent sessions.

Consider adjusting the keep-alive interval in your WebSDK configuration. This helps maintain session stability during load spikes and prevents premature 1006 closures.