Quick question about WebRTC softphone stability when pushing concurrent sessions. Running JMeter 5.6.2 from Singapore targeting our Genesys Cloud org. The goal is to validate softphone capacity for a new BPO site. I am using the standard WebSocket endpoint wss://webchat-eu.genesis.com/webrtc for signaling. The test plan creates 50 concurrent threads, each establishing a WebSocket connection and attempting to initiate a WebRTC offer via the /api/v2/interactions endpoint. The environment is standard Genesys Cloud EU region. Browser context is headless Chrome via Selenium Grid, simulating Chrome 120. The issue occurs almost immediately after thread count hits 20. The WebSocket connections are established successfully, but the WebRTC handshake fails. The browser console logs show ‘IceConnectionState: failed’ followed by ‘Connection reset by peer’. The server side returns a 408 Request Timeout on the interaction creation API call. The error payload indicates ‘WebRTC negotiation timeout’. I have verified that the firewall allows UDP ports 3478-3481 and TCP 443. The JMeter server has sufficient bandwidth and CPU headroom. The problem persists even when reducing the thread count to 10, suggesting it is not a pure resource exhaustion issue on the client side. The latency between Singapore and the EU data center is around 150ms, which should be acceptable. I suspect there might be a limit on concurrent WebRTC negotiations per organization or a specific rate limit on the signaling channel that is not documented clearly. The standard API rate limits for REST endpoints do not seem to apply here since the failure happens during the WebSocket handshake phase. I am looking for any known limits on concurrent WebRTC sessions per user or per organization. Also, is there a specific header or parameter in the WebSocket handshake that can help optimize connection stability under load? Any insights on how to structure the load test to avoid these timeouts would be helpful. I need to ensure the softphone can handle at least 100 concurrent agents without dropping calls during peak hours.