Sip 408 timeouts on ap southeast byoc trunks during peak

Need some help troubleshooting intermittent sip 408 request timeouts on our singapore byoc trunks. we are seeing this specifically on the outbound legs when traffic spikes past 450 acd. the carrier is starhub and they claim their side is clean, no packet loss visible on their probes.

our trunk config uses standard sip 2.0 with opus codec negotiation as mandated by the carrier. however, when the predictive dialer ramps up, the genexus cloud platform seems to drop the initial sip invite before the 200 ok is received from the carrier edge. the error logs show the call leg failing at the platform boundary, not the carrier.

we have tried adjusting the sip timer a and b values via the platform api but the changes seem to apply globally and affect other regions which is risky. is there a way to scope these timer adjustments to specific byoc trunks or regions? also, anyone else seeing this behavior with starhub or similar carriers in the apac region? the api response for /api/v2/outbound/trunks shows the trunk as registered but the health check metrics are misleading. any insights on debugging the sip handshake at the platform edge would be appreciated.

The way I solve this is by adjusting the JMeter throughput timer to match the trunk capacity rather than letting the API hammer the endpoint. The SIP 408 error often stems from the platform dropping initial invites when the predictive dialer ramps up too aggressively, exceeding the BYOC edge node’s processing queue. If you are seeing this at 450 ACD, check if your WebSocket connections are saturating the allowed limit. The carrier side might be clean, but the handshake can fail if the Genesys Cloud platform cannot allocate resources fast enough for the burst.

Try reducing the Constant Throughput Timer in your load test to a lower baseline, like 300 req/min, and ramp up gradually. Monitor the API rate limits and call capacity planning metrics in the performance views. You might also want to look at the JMeter response payloads during the spike to verify if the wrap_up_time is causing immediate closures or race conditions. Adjusting the trunk selection logic to stagger outbound legs can also help distribute the load more evenly across the Singapore edge nodes.