Stuck on a recurring SIP 408 Request Timeout that triggers when forcing a failover from the primary BYOC trunk to the secondary carrier during our scheduled maintenance windows in the Singapore timezone.
The environment involves 15 BYOC trunks distributed across APAC regions, utilizing NICE CXone for call control. The primary trunk connects via a local carrier with strict SIP registration keep-alive intervals, while the secondary trunk routes through a global aggregator. When the primary trunk’s SIP registration is intentionally dropped to test the failover logic, the Architect flow initiates the outbound call on the secondary trunk. However, approximately 40% of these failover calls result in a 408 timeout before the call is established. The SIP trace shows the INVITE reaching the secondary carrier’s edge, but no 100 Trying or 180 Ringing response is received within the 3-second window. This issue does not occur when the primary trunk is active. The outbound routing configuration uses a round-robin strategy with health checks disabled to force the failover test. The carrier-specific quirks for the secondary provider indicate a potential delay in processing INVITEs from new source IPs during failover events. Adjusting the SIP timer settings in the BYOC trunk configuration to increase the invite timeout to 5 seconds has not resolved the issue. The logs show the call failing at the NICE CXone edge before reaching the carrier’s media server. Need assistance in determining if this is a configuration issue on the BYOC trunk level or a carrier-specific latency problem that requires adjustment in the outbound routing rules. The impact is significant during peak hours in the APAC region, causing a drop in outbound call success rates during planned failover drills. Any insights on optimizing the SIP handshake for BYOC failover scenarios would be appreciated.