Looking for advice on
Running a load test against our Genesys Cloud SIP trunks using JMeter. The goal is to simulate peak inbound volume during the APAC morning rush. We are hitting a 408 Request Timeout consistently when concurrent connections exceed 500. The JMeter script uses a constant timer with a 1000ms delay between requests.
The environment is set up in the Asia Pacific region. We are using the standard REST API for registration before switching to WebSocket for the media stream. The error logs show the timeout happening right at the registration phase, not during the call setup.
Is there a known limit on the number of simultaneous SIP registrations per tenant? We have checked the network firewall and there are no drops. The issue seems to be on the Genesys platform side.
Any suggestions on how to adjust the JMeter config to avoid this? We need to scale up to 2000 concurrent calls for our next test phase.
The documentation actually says…
SIP registration is not idempotent like REST calls.
Check your JMeter thread group settings.
Use a sequential loop with proper deregistration logic.
Do not fire 500 concurrent REGISTER requests.
Genesys Cloud rate limits this heavily.
Look at the genesyscloud_telephony_providers_edges_trunk resource constraints.
Max concurrent registrations per trunk is usually 50-100.
You are hitting the gateway timeout because the control plane is saturated.
Stagger your load test.
Use a ramp-up period.
Do not blast all threads at once.
Also, check your SIP trunk health status in Admin.
If it shows “Degraded”, back off immediately.
This is not a WebSocket issue.
This is a SIP signaling bottleneck.
Fix the load test script first.
Then retest with 50 concurrent connections.
Scale up slowly.
Monitor the genesyscloud_telephony_providers_edges_trunk_health metrics.
You will see the timeout disappear.
If it persists, check your firewall logs.
Ensure no NAT timeout is killing the SIP keepalives.
But 99% of the time, it is the load test pattern.
Stop blasting.
Start ramping.
This has the hallmarks of a classic case of expecting Genesys Cloud to behave exactly like our old Zendesk ticketing system, where metadata just magically appeared alongside the interaction record. In Zendesk, webhook integrations were just simple HTTP POSTs to a public URL. Now, with Genesys Cloud Private Connect (BYOC), the Edge seems to be rejecting the burst. The 408 timeout is likely because the SIP registration logic is fundamentally different from the RESTful patterns we are used to in Zendesk.
The suggestion above about rate limits is spot on. Try adding a staggered delay in your JMeter script. Instead of firing 500 concurrent REGISTER requests, use a sequential loop with a 200ms delay. Also, verify that the genesyscloud_telephony_providers_edges_trunk resource allows that many concurrent connections. Migrating from Zendesk means adjusting our mental model from ticket queues to real-time media streams.