SIP INVITE timeout at 450 concurrent call volumes

Voice & Telephony
1

running jmeter 5.6 against the sip trunk, throughput drops to 12 req/sec once concurrent call volumes hit 450. env is eu-west-1, org capacity 3000. hitting 503 Service Unavailable on /api/v2/telephony/sessions. saw that community thread about websocket pool exhaustion, but it’s not that. feels like sip registrar backpressure. jmeter setup: 200 threads, 15s ramp, keepalive true. staging queue just flatlined for twenty mins. logs show…
{“status”:“rejected”,“code”:503,“message”:“sip_registrar_timeout”}

2

Are you hitting the public SIP URI or the internal cluster endpoint? Honestly, the registrar just flatlines past 400 legs.
Cause: Genesys hard-throttles /api/v2/telephony/sessions when backpressure hits.
Solution: Switch to the @genesys/web-messaging-sdk WebSocket transport. Don’t blast raw SIP.

{ "transport": "wss", "maxConcurrent": 350 }

Toss that into your JMeter wrapper.

3 
{
 "routing": {
 "maxConcurrent": 400,
 "overflowAction": "queue"
 },
 "wem": {
 "adherenceSource": "realtime",
 "capacityBuffer": 0.85
 }
}

The registrar limits hit hard at 450. It’s a hard limit. WEM reports skew when 503s spike. Drop the concurrency to 400. Set CAPACITY_BUFFER low. WEM tracks the actual answered calls, not the INVITE attempts. If you blast 450, the scheduler thinks agents are busy but the telephony layer rejects half.

Check the WFM_SCHEDULER logs. The adherence payload gets corrupted when sessions time out. I see this every Monday morning. You’ll notice the service level metric drops because the calls never ring.

Adjust the MAX_CONCURRENT in the routing profile. Force the queue to absorb the load. WEM needs clean data.

curl -X PUT /api/v2/routing/routingprofiles/{id} \
 -H "Authorization: Bearer $TOKEN" \
 -d '{"maxConcurrent": 400}'

The 503s kill the service level metric. WEM shows 90% adherence but the queue is empty. Fix the throttle.