Running a load test simulating 500 concurrent WebRTC sessions. The initial WebSocket connection succeeds, but the SDP offer/answer exchange fails after 300 connections. Server returns 408 Request Timeout on /api/v2/websockets. The environment is Genesys Cloud EU-West. Is there a hidden limit on simultaneous media stream negotiations? Why do WebRTC handshakes time out at 300 concurrent connections in a load test?
Oh, this is a known issue…
Cause: The 408 errors during SDP negotiation at scale are typically caused by the sliding-window rate limit enforcement on the /api/v2/websockets endpoint. While the initial WebSocket handshake succeeds, the subsequent API calls for media stream metadata exceed the standard 50 requests per minute cap for summary endpoints. This bottleneck is exacerbated in EU-West regions where network latency adds to the request processing time, causing the registrar to drop the connection before the answer is generated.
Solution: Implement an asynchronous decoupling pattern for the metadata exchange. Do not block the WebRTC handshake on synchronous API calls. Instead, queue the SDP details in a local buffer or message queue, then push them to the Platform API using batch endpoints with exponential backoff. Ensure your integration respects the Retry-After header. For high-concurrency tests, verify that your OAuth token refresh logic is not adding unnecessary load. Consider increasing the X-Genesys-Rate-Limit-Strategy tolerance if your Premium App entitlement allows it, though architectural changes are usually more effective than limit bypasses.