I can’t seem to figure out why the BYOC SIP trunk registration drops intermittently when pushing concurrent call volumes above 150 in the Asia/Singapore edge cluster.
We are running a load test using JMeter 5.6.2 with a custom SIP plugin to simulate inbound traffic to our Genesys Cloud BYOC endpoint. The setup involves a thread group with 200 users, ramp-up time of 60 seconds, and a loop count of 3. The goal is to validate the SIP trunk capacity before a major campaign launch.
The issue manifests specifically when the concurrent call count hits roughly 140-160. We start seeing a high rate of 503 Service Unavailable responses from the Genesys Cloud SIP proxy. This is not a standard 4xx client error, which suggests the platform is rejecting the load, not our test config. The SIP traces show the INVITE requests reaching the edge but failing at the initial handshake phase with a 503 before any media negotiation occurs.
Here are the specific details:
- Genesys Cloud Region: Asia/Singapore
- SIP Trunk Type: BYOC (Bring Your Own Carrier)
- JMeter Config: 200 threads, 60s ramp-up, 3 loops
- Error Rate: ~15% of INVITEs fail with 503 during peak load
- WebSocket Status: Signaling WebSockets remain connected, no drops observed on the client side
We have verified that our carrier-side SIP trunk is properly configured and has sufficient capacity. The issue seems isolated to the Genesys Cloud edge processing. We are also monitoring the SIP Trunk Health Dashboard in Genesys Cloud, which shows green status until the 503s start appearing, then briefly turns yellow before recovering.
Has anyone else encountered this specific 503 behavior during high-concurrency SIP load tests? Are there known limits on the BYOC SIP proxy in the APAC region that we might be hitting? Any insights into whether this is a platform-side rate limiting issue or a configuration mismatch on our end would be greatly appreciated. We are trying to determine if we need to adjust our JMeter ramp-up strategy or if there is a backend capacity issue.