Trying to understand why SIP trunk connections drop when simulating high concurrent call volumes.
Using JMeter to hit the telephony API for outbound calls. At 100 concurrent threads, the WebSocket closes unexpectedly.
WebSocket connection to 'wss://api.mypurecloud.com/api/v2/telephony/providers/edge/users/current/calls' failed
Is there a specific limit on simultaneous WebSocket streams per user token? The documentation mentions rate limits but not connection caps.
This is actually a known issue… The WebSocket connection described is fundamentally a real-time monitoring channel for the specific user context, not a high-throughput telephony signaling endpoint. The Performance Dashboard relies on these streams to visualize agent activity and queue status, but they are not designed to handle the volume of outbound call initiation requests generated by JMeter threads. When 100 concurrent threads attempt to establish or maintain these connections simultaneously, the system interprets this as an abnormal surge in monitoring traffic rather than legitimate telephony operations. This triggers the platform’s protective mechanisms, resulting in the abrupt closure of the WebSocket streams to preserve system stability. The documentation regarding rate limits applies to the underlying REST API calls for creating the calls, but the WebSocket layer has its own strict concurrency thresholds per user token to prevent resource exhaustion.
To resolve this, the testing methodology needs to shift away from using the real-time monitoring endpoint for bulk call generation. Instead, utilize the standard REST API for initiating the outbound calls, which is optimized for batch processing and has higher throughput capabilities. The WebSocket should only be used if the specific test requires observing the real-time state changes of a limited number of concurrent calls. For load testing purposes, relying on historical data views or aggregated metrics in the Performance Dashboard is more effective than trying to force real-time visibility on every single transaction. Check the Queue Performance view after the test run to analyze the success rates and any dropped calls, rather than attempting to monitor each connection individually during the load spike. This approach aligns with the intended use of the analytics infrastructure and avoids triggering the connection limits associated with the monitoring streams.