Can anyone clarify the hard limits on concurrent SIP INVITE transactions for a single Genesys Cloud org when using direct SIP trunking?
We are running a load test to validate inbound call capacity. The setup involves a custom SIP provider sending traffic through a Genesys Cloud SIP trunk. The goal is to simulate a burst of 2,000 calls per minute (CPM) to see how the platform handles the signaling load before the calls are routed to agents.
Using JMeter, we configured a thread group with 500 concurrent users, each sending an INVITE request every 3 seconds. The test runs against the public SIP endpoint provided in the Genesys Cloud admin console.
After approximately 45 seconds into the test, we start seeing a significant number of 408 Request Timeout responses from the Genesys Cloud SIP proxy. The JMeter logs show that the requests are sent correctly, but the ACK is never received. Around 60 seconds in, the failure rate spikes to 40%.
We have checked the following:
- The SIP trunk is configured with the correct codec preferences (G.711 u-law only).
- No call center routing rules are dropping the calls prematurely; they are routed to a simple queue.
- The network path has sufficient bandwidth (1 Gbps link).
- We are not hitting the API rate limits for REST calls, as this is pure SIP signaling.
Is there a known limit on the number of concurrent SIP dialogues that can be established per minute? Or is this a timeout issue with the SIP proxy under high load? We need to understand if this is a configuration issue on our end or a platform limitation.
Any insights into how Genesys Cloud handles high-volume SIP signaling bursts would be appreciated. We are trying to determine the maximum sustainable CPM for our deployment.
You need to understand that the 408 Request Timeout is rarely a hard limit issue with Genesys Cloud’s global infrastructure. It is almost always a signaling bottleneck at the edge or a configuration mismatch in the SIP trunk settings.
From a performance monitoring perspective, when you see these timeouts during high-volume bursts, the first step is to check the “SIP Trunk Activity” view in the Performance Dashboard. Look specifically at the “Failed Calls” and “Timeouts” metrics. If the failure rate spikes exactly when the INVITE rate exceeds a certain threshold, it indicates the upstream SIP provider is dropping packets or the TCP connection pool is exhausted.
Ensure your SIP trunk is configured for TCP rather than UDP for high-volume scenarios. UDP is connectionless and can lead to packet loss under extreme load, causing the 408s. In the SIP Trunk configuration, verify that the “Max Concurrent Sessions” is set appropriately. While Genesys Cloud can handle significant concurrency, the trunk itself has limits defined by your contract and the underlying carrier capabilities.
Additionally, check the “Call Center” settings for any restrictive routing rules that might be causing delays in processing the INVITE. A common fix is to adjust the “Invite Timeout” setting in the SIP trunk configuration, though this is often a symptom rather than the cure.
The most reliable approach is to monitor the real-time queue metrics alongside the SIP trunk activity. If the queue metrics show calls arriving but the SIP trunk shows timeouts, the issue is likely with the SIP signaling path. If both show anomalies, the problem might be within the flow logic itself, particularly if there are complex IVR paths that delay the initial handshake.
Consider breaking down the JMeter test into smaller, sustained bursts rather than a single massive spike. This helps isolate whether the issue is a burst capacity problem or a sustained throughput limitation. Genesys Cloud is designed to handle high concurrency, but the integration points-specifically the SIP trunk-require careful tuning and monitoring to ensure stability under load.