Just noticed that WebRTC sessions are failing when ramping up concurrent users in JMeter. The WebSocket handshake succeeds, but media streams disconnect after 30 seconds. Error logs show ICE candidate gathering failed repeatedly. Running against the Genesys Cloud APAC region with standard softphone SDK. Is there a specific connection limit for simultaneous WebRTC streams during load testing that I am missing?
It depends, but generally…
ICE candidate gathering failed
Check the JMeter thread group ramp-up time. Sudden spikes overwhelm the Genesys Cloud WebSocket capacity before the media negotiation stabilizes. Try staggering the requests by 2-5 seconds to match real-world call patterns.
you need to look at how zendesk handled concurrent widget loads because genesys cloud behaves differently. in zendesk, we just increased the api rate limits and queued ticket updates. here, the ice candidate failure usually means the network path isn’t stabilizing fast enough for the sudden spike. try enabling trickle ice in your sdk config. this allows candidates to be sent as they are discovered, rather than waiting for the full list. it mimics the async nature of zendesk’s background sync.
{
"iceTransportPolicy": "all",
"bundlePolicy": "max-bundle",
"rtcpMuxPolicy": "require",
"iceServers": [
{
"urls": "stun:global.turn.genesys.cloud:3478"
}
]
}
also, check if your jmeter script is reusing the websocket connection. genesys cloud prefers long-lived connections for media. if you are opening/closing sockets rapidly, the server drops them to save resources. stagger the ramp-up as suggested, but also ensure the sdk isn’t forcing a full renegotiation on every heartbeat. this usually fixes the 30-second drop.