Is there a clean way to handle SIP 486 Busy Here during concurrent WebRTC load testing?
Running JMeter 5.6.2 from Asia/Singapore to simulate peak inbound call volumes for our Genesys Cloud contact center. Pushing 200 concurrent threads through the WebRTC Gateway API. The goal is to validate call capacity planning and API throughput under stress.
The issue is that after roughly 30 seconds of sustained load, a significant portion of the incoming SIP INVITE requests start failing with 486 Busy Here. This happens even though the underlying SIP trunks have plenty of available channels. The error suggests the target extension or queue is busy, but our logic routes directly to a single agent group with 50 available seats.
I suspect this might be related to WebSocket connection limits or how Genesys Cloud handles concurrent session handshakes via the platform_api. The rate limit headers (X-Rate-Limit-Remaining) show plenty of capacity left, so it is not a standard 429 rate limit issue.
Here is the relevant JMeter configuration:
- Thread Count:
200 - Ramp-Up:
10seconds - Loop Count:
5 - Protocol:
WebSocketoverWSS - Endpoint:
https://api.ciscospark.com/v1/webchat
The logs show the initial handshake succeeds, but the subsequent SIP INVITE fails with 486. I have tried increasing the ramp-up time to 60 seconds, but the 486 errors still occur once the concurrent connection count exceeds 50.
Is there a specific header or parameter I need to include in the WebRTC handshake to prevent this? Or is this a known limitation of the Genesys Cloud WebRTC Gateway under high concurrency? Any insights on how to structure the load test to avoid triggering these false busy signals would be appreciated. I am relatively new to this setup, so I might be missing a basic configuration step.