WebRTC softphone connection drops under JMeter load in Singapore

Voice & Telephony
1

So I’m seeing a very odd bug with the WebRTC softphone integration where connections start dropping unexpectedly when we ramp up the concurrent call volume in our load tests. We are using JMeter 5.6 to simulate agents logging in and making outbound calls via the Genesys Cloud platform API in the Asia/Singapore region. The setup involves calling /api/v2/telephony/providers/edges to register the edge and then establishing WebSocket connections for media. Everything works fine with up to 50 concurrent agents, but once we push past 75 agents, we start seeing a significant number of WebSocket connections closing with a 1006 error code. The logs show the connections are established successfully at first, but they terminate shortly after the initial SDP exchange. I have checked the network traces and there are no obvious packet losses or latency spikes that would suggest a network issue. The API rate limits do not seem to be hit either, as the response times for the initial calls are within normal ranges. I am wondering if there is a known limit on the number of concurrent WebRTC sessions per edge or per tenant in the Singapore region. Also, could the issue be related to how the JMeter script handles the WebSocket keep-alive messages? I have tried adjusting the heartbeat interval in the JMeter configuration, but that did not resolve the issue. Any insights into what might be causing these premature disconnects under load would be greatly appreciated. We are trying to determine if this is a configuration issue on our end or a platform limitation we need to account for in our capacity planning.

2

The easiest fix here is this is to verify the WebSocket keep-alive intervals and ensure the JMeter script handles the STUN/TURN server timeouts correctly. In the Asia/Singapore region, network latency can cause the Genesys Cloud edge to drop idle connections faster than expected.

  • Check if your JMeter HTTP Request Defaults include the correct Sec-WebSocket-Protocol header matching the Genesys Cloud version.
  • Ensure the WebSocket sampler is configured to send ping frames every 15-20 seconds. If the interval is too long, the edge server may terminate the session before the next heartbeat.
  • Review the media object in the registration payload. Make sure the codecs array matches exactly what the Singapore edge supports for that specific tenant. Mismatches here often cause silent failures under load.
  • Monitor the Cloud Logs for 408 Request Timeout or 1006 Abnormal Closure events during the test run.

This usually resolves the dropping connections issue. If the problem persists, check if the S3 integration for recording exports is overwhelming the same network path, as bulk exports can sometimes saturate bandwidth in the region.

3

{
“keepAliveInterval”: 20000,
“reconnectAttempts”: 3
}


This config often stabilizes the connection. In Zendesk, we relied on their persistent connection handling, but Genesys Cloud requires explicit keep-alives for WebRTC. Adjusting these values helps prevent the edge from dropping sessions during JMeter bursts in Singapore.