WebRTC softphone connection drops at 150 concurrent threads

Stuck on a weird issue during load testing the WebRTC softphone integration. We are running JMeter scripts from our Asia/Singapore environment to simulate agent login and call initiation. Everything works fine up to 100 concurrent threads. Once we push past 120, about 30% of the WebSocket connections fail to establish a media stream.

The API calls for authentication succeed, but the actual media negotiation times out. No obvious 429s on the auth endpoints, but the WebSocket handshake seems to be failing silently or timing out on the server side.

WebSocket connection to ‘wss://.mygenesyscloud.com/media/webrtc’ failed: Error during WebSocket handshake: net::ERR_CONNECTION_TIMED_OUT

We are using the standard Genesys Cloud WebRTC SDK (v2.1.0). Has anyone seen this specific behavior when scaling up concurrent softphone sessions? Is there a hidden limit on WebSocket connections per org or per IP range that isn’t documented clearly? We need to hit 500 concurrent agents for our capacity planning, but this bottleneck is blocking us. Any insights on how to tune the client or if this is a platform-side constraint?

Pretty sure the 400 error stems from schema mismatches rather than missing skills. Align interaction steps with Genesys Cloud’s required format. Direct macro-to-intent mapping fails because the underlying data structures do not correspond. The system expects specific JSON payloads for intent recognition, not just simple string matches.

In the context of WebRTC load testing, this suggests that the failure point is likely not the media stream itself, but the initial signaling handshake configuration. When pushing past 120 concurrent threads, the WebSocket handshake timeout often becomes the bottleneck. The default settings may be too aggressive for high-concurrency scenarios in the EU1 region.

Try adjusting the ICE candidate gathering timeout and ensuring the SDP offer/answer exchange is not being truncated by intermediate proxies. The dashboard often shows these as silent failures because the agent state remains “Ready” even when the media pipeline fails. Check the Connection Quality metrics in the Performance view for dropped packets during the negotiation phase. This usually highlights NAT traversal issues rather than SDK bugs.

Make sure you verify that the WebSocket handshake timeouts are not caused by carrier-level SIP registration drops during the load spike. When 150 concurrent threads initiate calls, the BYOC trunk often experiences a burst of SIP REGISTER requests that can exceed the carrier’s rate limits or cause temporary session table exhaustion on the edge. This is a common carrier-specific quirk in APAC regions. Check your trunk’s failover logic to ensure it isn’t prematurely switching to a secondary carrier due to perceived instability. The environment requirements for stable WebRTC signaling under load are strict.

Adjust the SIP keep-alive interval in the trunk configuration to maintain session state. Also, monitor the edge logs for 408 Request Timeout errors from the carrier. If the carrier is dropping registrations, the media negotiation will fail regardless of the WebSocket status. Consider implementing a staggered login sequence in your JMeter script to simulate realistic agent behavior rather than a simultaneous burst.