SIP Trunk Registration Failures During JMeter Stress Test

Voice & Telephony
1

Looking for advice on SIP trunk registration failures observed during concurrent load testing.

  • Running JMeter 5.6.2 with custom SIP sampler plugin to simulate inbound call volume.
  • Target environment is Genesys Cloud pure cloud, US East region.
  • Test scenario involves ramping up 500 concurrent SIP registrations within 60 seconds.
  • Initial 100 registrations succeed with 200 OK response.
  • Subsequent registrations fail with 408 Request Timeout after 10 seconds.
  • Some requests return 403 Forbidden with message ‘Rate limit exceeded’.
  • Checked API rate limits documentation, but SIP signaling seems separate from REST API limits.
  • WebSocket connection pool in JMeter set to max 1000 connections.
  • Network latency between test server and GC edge is under 5ms.
  • No firewall blocks detected on port 5060 UDP/TCP.
  • SIP trace shows REGISTER requests being sent correctly.
  • Genesys Cloud admin portal shows no active incidents.
  • Tried reducing ramp-up time, but issue persists at lower concurrency levels.
  • Increased JMeter heap size to 4GB to avoid memory issues.
  • Verified SIP trunk credentials are correct and not expired.
  • Question is whether there is a hidden limit on SIP registration attempts per minute.
  • Or if the load test configuration is triggering a security mechanism.
  • Need to understand the exact threshold for SIP signaling rate limiting.
  • Any guidance on how to properly scale SIP load tests without hitting these errors?
  • Also interested in best practices for simulating high concurrent SIP traffic.
  • Current setup uses single thread group for all registrations.
  • Considering splitting load across multiple virtual users or thread groups.
  • But first need to confirm if 403 is due to rate limiting or config error.
  • Appreciate any insights from community members with similar experience.
2

This looks like a rate limiting issue on the SIP proxy rather than a trunk configuration error. The cloud provider throttles rapid registration bursts to prevent abuse.

Adjust the JMeter test plan to space out requests. Use a constant throughput timer to cap registrations at 10 per second. This aligns with standard SIP signaling limits.

<com.thoughtworks.xstream.XStream>
 <org.apache.jmeter.timers.ConstantThroughputTimer>
 <throughput>600</throughput>
 </org.apache.jmeter.timers.ConstantThroughputTimer>
</com.thoughtworks.xstream.XStream>

Monitor the 408 errors. They should drop significantly once the burst pattern is smoothed out.

3

You might want to check at the underlying SIP signaling constraints rather than just the test parameters.

Subsequent registrations fail with 408 Request Timeout after 1

The Genesys Cloud SIP proxy enforces strict rate limits on registration bursts. While JMeter can generate load, the platform throttles rapid concurrent attempts to maintain stability. Adjusting the test to respect these limits is necessary.