Dealing with a very strange bug here with the Bring Your Own Carrier (BYOC) integration when simulating high concurrent inbound call volumes.
-
Environment details:
-
Genesys Cloud US1 region.
-
BYOC Edge instance located in Ashburn, VA.
-
JMeter version 5.6.2 running on a dedicated EC2 instance in us-east-1.
-
Target: SIP trunk endpoint configured via BYOC API.
-
Test Configuration:
-
Goal: Validate call capacity planning for peak hour inbound traffic.
-
Thread Group: 100 concurrent users ramping up over 10 seconds.
-
Loop Count: 5 iterations per thread.
-
Request Type: SIP INVITE sent directly to the Edge SIP endpoint.
-
Expected behavior: Calls should be routed to the default queue or voicemail, even if agents are busy.
-
Observed Issue:
-
At approximately 60 concurrent calls, the Edge starts returning SIP 503 Service Unavailable responses.
-
The error occurs specifically during the INVITE transaction phase.
-
No 429 rate limiting errors are seen on the API side, suggesting this is a media/SIP layer issue, not an API throughput issue.
-
The JMeter logs show the 503 response coming back from the Edge IP address, not the carrier side.
-
Troubleshooting steps taken:
-
Checked Edge health dashboard: All components show green status.
-
Verified SIP trunk bandwidth allocation: Currently set to 100 concurrent calls, but testing only at 60.
-
Reviewed Genesys Cloud logs via the API (/api/v2/architect/flows): No corresponding flow execution errors found for the failed calls.
-
Checked for WebSocket connection limits: The test does not use WebSocket APIs, only raw SIP signaling.
-
Question:
-
Is there a hidden concurrency limit on the BYOC Edge SIP stack that is lower than the configured trunk capacity?
-
Could the 503 error be related to resource exhaustion on the Edge media processing unit during rapid INVITE bursts?
-
Any specific JMeter configuration adjustments recommended for SIP load testing against Genesys Edge to avoid triggering these 503 errors?