Trying to understand why my JMeter load test triggers SIP 408 Request Timeout errors when concurrent INVITE requests exceed 150 per second on our BYOC trunk configuration. The environment is Genesys Cloud US1. I am using the Genesys Cloud Java SDK 6.2 for initial setup but the actual load is generated via a custom SIP User Agent in JMeter to bypass SDK overhead. The timeouts occur specifically at the edge gateway level before the request reaches the routing queues.
The configuration for the SIP trunk is standard, but I suspect the WebSocket connection pool or the signaling throughput limit is being hit. I have verified that the media ports are open and the SDP negotiation is successful for lower volumes. The error logs from the Genesys Cloud side show “Request Timeout” with a specific correlation ID that points to the ingress edge node.
Here is the JMeter thread group configuration and the BYOC trunk settings I am using:
jmeter_config:
thread_group:
threads: 200
ramp_up: 10
loop_count: 10
sip_timer:
constant_delay: 50 # ms
throughput_target: 150 # req/sec
byoc_trunk:
region: us1
sip_domain: mycompany.sip.genesys.cloud
max_concurrent_calls: 500
codec_priority:
- opus
- g722
- pcma
edge_logs:
timestamp: "2023-10-27T14:30:00Z"
error_code: "SIP_408"
message: "Request Timeout"
node_id: "edge-us1-03"
I have checked the API rate limits for the administrative endpoints, but this is a signaling issue, not an API call issue. Is there a specific limit on the number of simultaneous SIP INVITEs the US1 edge can handle before dropping them with a 408? I tried increasing the JMeter constant delay to 100ms, which reduced the timeouts but did not eliminate them. The goal is to support 300 concurrent calls without signaling failures. Any insights into the signaling capacity per edge node would be helpful. I am also monitoring the WebSocket connections for the softphones, but they seem stable during this test. The issue is strictly with the inbound SIP trunk signaling.