No idea why this is happening, our SIP trunk returns 503 Service Unavailable when we push concurrent call volumes above 50 in JMeter. We are trying to validate call capacity for the US-East region.
Background
We are running a load test using JMeter 5.6.2. The goal is to simulate a burst of inbound calls to verify if our Genesys Cloud organization can handle the peak volume. We have configured a simple Architect flow that routes calls to a specific queue. The SIP trunk is connected via a third-party provider. We are using the default WebSocket connection settings in Genesys Cloud. Our environment is in the US-East region.
Issue
When the concurrent thread count in JMeter reaches 51, the SIP trunk starts returning 503 Service Unavailable errors. The error occurs immediately on the INVITE request. The calls do not ring. The error message in the SIP logs shows:
SIP/2.0 503 Service Unavailable
From: <sip:[email protected]>
To: <sip:[email protected]>
Call-ID: 12345-67890
This happens consistently at the same threshold. Below 50 concurrent calls, the system works fine. We have checked the call capacity limits in the Genesys Cloud admin console, and they are set to 100 concurrent calls. We are not hitting the organization limit.
Troubleshooting
- Verified the SIP trunk status is active.
- Checked the API rate limits for the
POST /api/v2/telephony/phone-queues endpoint. No 429 errors are seen.
- Increased the WebSocket keep-alive interval in JMeter, but the issue persists.
- Tested with a smaller batch size (10 concurrent calls) and increased the duration. No errors.
We suspect it might be a threading issue in JMeter or a hidden limit on the SIP trunk side. Can anyone share their JMeter configuration for SIP load testing? We need to understand if this is a platform limitation or a configuration error. Any advice on tuning the SIP trunk settings for high concurrency would be helpful.
Check your SIP trunk configuration and concurrent session limits in Genesys Cloud. A 503 usually indicates the underlying provider or the GC edge has hit its max concurrent media streams, not a JMeter syntax error.
Review the Trunk Settings in Admin to ensure the Maximum Concurrent Sessions aligns with your burst size. If the limit is set to 50, exceeding it triggers immediate rejection. Consider scaling up the trunk capacity or staggering the JMeter ramp-up to avoid instant saturation.
The problem is that Genesys Cloud enforces strict session limits at the edge level which often catches migration teams off guard when moving from Zendesk Talk or other cloud contact centers where capacity scaling felt more abstract. The suggestion above about checking the Maximum Concurrent Sessions is absolutely correct because a 503 Service Unavailable specifically means the SIP trunk provider or the Genesys Cloud gateway has rejected the INVITE due to resource exhaustion. When migrating from Zendesk, it is easy to forget that Genesys Cloud requires explicit configuration for trunk capacity in Admin > Phone System > Trunks. You need to verify that the trunk’s concurrent session limit matches or exceeds your JMeter test volume. If your trunk is set to 50 sessions and JMeter pushes 51 concurrent calls, Genesys Cloud will immediately return a 503. Additionally, ensure that the trunk’s registration status is healthy and that the underlying SIP provider (like Twilio, Bandwidth, or a PSTN carrier) has not imposed its own concurrent call limits that are lower than Genesys Cloud’s setting. A common fix is to temporarily increase the trunk’s concurrent session limit in Genesys Cloud Admin during the load test phase, then revert it afterward to maintain cost efficiency. Also, check the Genesys Cloud performance dashboard for any edge node congestion in US-East, as regional load can sometimes contribute to temporary 503 errors even if trunk limits are not hit. Remember that digital channels and voice channels are managed separately in Genesys Cloud analytics, so ensure you are monitoring the correct metrics. Finally, exclude JMeter test traffic from WFM adherence reports to avoid skewing agent performance data, a lesson learned from our own Zendesk-to-GC migration where test calls accidentally triggered real-time alerts.
Check the SIP Trunk settings in Admin and verify the Maximum Concurrent Sessions value. If this is capped at 50, any INVITE beyond that threshold gets rejected with a 503 regardless of JMeter configuration.
Cause: The 503 Service Unavailable error is triggered when the inbound INVITE requests from JMeter exceed the Maximum Concurrent Sessions threshold defined in the SIP Trunk configuration. This is a capacity guardrail within Genesys Cloud, not a network failure. The edge node rejects new sessions once the limit is reached to protect system stability.
Solution: Adjust the trunk settings to accommodate the test volume.
- Navigate to Admin > Telephony > Trunks.
- Select the target SIP Trunk.
- Locate the Maximum Concurrent Sessions field.
- Increase the value to exceed your JMeter thread group size (e.g., set to 100 for a 50-concurrent test with headroom).
- Save the configuration.
Verify the change by running a smaller batch first. Monitor the Telephony > Trunk Activity dashboard during the test. If the session count plateaus at the previous limit, the change has not propagated or the provider side is also limiting.
Note: Ensure your Genesys Cloud organization license supports the increased concurrent session count. If the license cap is lower than the configured trunk limit, sessions may still fail or result in billing discrepancies. The JMeter test should reflect production-like burst patterns, including ramp-up times, to accurately assess queue behavior.
Config Example (for reference in API/JSON if modifying via AppFoundry):
{
"maximum_concurrent_sessions": 100,
"description": "Updated for JMeter spike test validation"
}
This adjustment aligns the trunk capacity with the test parameters. Review the Queue Performance views post-test to analyze any abandoned calls or wait time anomalies caused by the volume spike.