WebRTC Softphone Connection Drops at 200 Concurrent Users

Voice & Telephony
1

So I’m seeing a very odd bug with WebRTC softphone stability. Using Genesys Cloud US1 environment. When JMeter load test hits 200 concurrent users, softphones drop connections with ‘ICE Connection Failed’ errors. API throughput is fine, but WebSocket connections seem to choke. JMeter 5.6 config attached. Is there a specific rate limit for WebSocket upgrades in BYOC environments? Any help appreciated.

2

I’d recommend looking at at the WebSocket handshake configuration rather than assuming a hard rate limit on the BYOC edge. The “ICE Connection Failed” error typically indicates that the STUN/TURN server resolution is timing out under load, not that the Genesys Cloud API is rejecting connections. In ServiceNow integrations, we often see similar latency spikes when payload serialization blocks the main thread, but here the bottleneck is likely the UDP port range exhaustion on the client side during the JMeter simulation.

Ensure your JMeter script is configured to reuse WebSocket connections instead of creating a new one per iteration. A common fix is to adjust the iceServers configuration in the WebRTC init payload to prioritize TURN servers with higher concurrency limits.

{
"error": "ICE Connection Failed",
"code": 1006,
"details": "No candidate pairs"
}

Check the genie://logs for specific STUN timeout entries. If the TURN relay is not configured correctly in the BYOC profile, connections will drop once the direct path fails. Verify the webRtc.turnServer settings in the admin console match your firewall rules.

3

Check your UDP port range allocation in the OS network stack. The ICE Connection Failed error at 200 concurrent users usually indicates ephemeral port exhaustion on the client side, not a Genesys Cloud WebSocket limit.

4

If I remember correctly, migrating from Zendesk’s web widget architecture to Genesys Cloud’s WebRTC softphone requires a shift in how we view connection persistence. Zendesk handles chat sessions via standard HTTPS long-polling, which is forgiving of network jitter. Genesys Cloud, however, relies on UDP for media and specific WebSocket handshakes for signaling. When hitting 200 concurrent users in a load test, the “ICE Connection Failed” error is rarely a Genesys backend limit. It is almost always a client-side resource exhaustion issue.

Here is how I approached this during my recent Zendesk-to-GC migration projects:

  • Verify Ephemeral Port Limits: In Zendesk, each chat thread is a lightweight HTTP request. In GC, each softphone session requires a unique UDP port. Ensure your test environment’s OS allows a high enough ephemeral port range (e.g., net.ipv4.ip_local_port_range = 1024 65535). Linux defaults are often too low for 200+ simultaneous WebRTC sessions.
  • STUN/TURN Server Accessibility: Zendesk does not use STUN/TURN. GC does. Load tests often fail because the client cannot resolve the STUN server (stun.global.genesys.cloud) quickly enough under load. Ensure DNS resolution is cached and not throttled.
  • JMeter WebSocket Configuration: The default JMeter WebSocket sampler may not handle the reconnection logic correctly. GC expects persistent connections. Try adding a “WebSocket Keep-Alive” sampler or reducing the concurrent start rate to allow handshake completion before the next batch.
  • Check for NAT Hairpinning: If your load generators are behind a NAT, ensure hairpinning is enabled. Zendesk’s proxy-based model hides this, but WebRTC exposes it.

This mindset shift from “stateless HTTP” to “stateful media streams” is crucial. The documentation suggests monitoring the webrtc.connectionState in the browser console during the test to confirm if the drop is due to network timeout or credential rejection.