Need some help troubleshooting SIP INVITE timeouts under load. Using JMeter 5.6 to simulate 50 concurrent calls to Genesys Cloud v2024.1. Calls drop with 408 Request Timeout after 30 seconds. Single calls work fine.
pulumi.ts
import * as genesyscloud from “@genesyscloud/pulumi”;
const sipTrunk = new genesyscloud.SipTrunk(“loadTestTrunk”, {
name: “load-test-trunk”,
provider: “custom”,
endpoints: [{
host: “pbx.example.com”,
port: 5060,
transport: “udp” // switch this to tcp if jitter is high
}],
settings: {
// increase invite timeout specifically for load tests
inviteTimeoutSeconds: 60,
maxRetries: 2
}
});
// also bump the queue timeout if you’re routing through one
new genesyscloud.Queue(“loadQueue”, {
name: “load-test-queue”,
settings: {
timeoutSeconds: 120
}
});
the 408 usually means the sip stack is dropping the invite before it hits the ivr. in my stacks i’ve seen this when the default invite timeout is too aggressive for the latency between jmeter and the cloud edge.
check your sip trunk settings. the default is often 30s which is tight when you’re hammering it with 50 concurrent invites. bumping it to 60s or higher usually clears the timeout errors. also make sure you’re using udp unless you have a specific reason for tcp. udp handles the burst better in most cases.
if you’re using a custom provider or a specific cloud region, latency might be higher. london to us-east-1 adds about 80ms which can add up when you’re sending invites in parallel.
also check your jmeter thread group. make sure you’re using the correct sip sampler and not just http. sometimes people mix them up. the sip sampler in jmeter needs the right headers. specifically the via header.
if you’re still seeing issues, try reducing the concurrency to 10 and see if it stabilizes. if it does, then it’s a resource limit on the trunk side. you might need to open a ticket to increase the sip trunk capacity for your org.
don’t forget to clean up the test resources after. they can linger and mess up future tests.
I usually solve this by checking the SIP trunk timeout settings, but honestly I think the issue might be elsewhere since single calls work fine. The 408 error is standard for unresponsive endpoints.
408 Request Timeout - SIP INVITE to 10.0.0.5:5060 failed after 30000ms
Have you tried switching the transport protocol? UDP is fine for low load, but under 50 concurrent calls, packet loss might be causing the handshake to fail. Try changing the transport to TCP in your trunk configuration. It’s more reliable for heavy loads, even if it uses slightly more bandwidth.
I’m not sure if JMeter is configured to handle TCP SIP properly, though. You might need to update your test plan. Also, check if your firewall is dropping idle connections too quickly. We had a similar problem last month and it turned out to be a NAT timeout issue, not Genesys. Worth a look.
3 Likes
It depends, but generally… 408s under load are rarely a Genesys config issue. They’re usually your local network dropping UDP packets or hitting NAT timeouts.
The suggestion above about switching to TCP is solid, but if you’re using the CLI or Terraform to manage the trunk, you need to ensure the transport field is actually being applied. Sometimes the API ignores the change if the trunk is already registered.
Here’s the JSON payload for a PATCH request to /api/v2/telephony/providers/edges/siptrunks/{id}. This forces the transport to TCP and bumps the invite timeout to 60s, which gives JMeter more breathing room during the handshake.
{
"name": "load-test-trunk",
"provider": "custom",
"endpoints": [
{
"host": "pbx.example.com",
"port": 5060,
"transport": "tcp"
}
],
"settings": {
"inviteTimeout": 60000,
"maxRetries": 3,
"retryInterval": 2000
}
}
run a quick curl to verify the change stuck before hitting the load button again.
also, check your JMeter thread group. If you’re spawning 50 threads instantly, your local machine might be exhausting ephemeral ports. Add a ramp-up period of 10s. That smooths out the initial burst.
if you’re still seeing 408s after switching to TCP, it’s likely a firewall dropping long-lived connections. Genesys edge servers don’t like idle TCP connections that last longer than 30s without keep-alives. enable SIP OPTIONS keep-alives in your PBX config if possible.
one more thing. make sure your JMeter SIP plugin isn’t reusing the same Call-ID for all 50 calls. That’ll confuse the state machine and cause collisions. use a variable like ${__UUID()} for the Call-ID header.
try the TCP switch first. it’s the fastest win.
408s under load are usually your edge dropping UDP packets. switch to TCP. i’ve seen this exact issue in okta syncs too.
PATCH /api/v2/telephony/providers/edge/trunks/{id}
{"settings": {"transport": "tcp"}}
ensure your nat keeps the state open.
2 Likes