Context:
My config is not working as expected for the primary BYOC trunk group deployed in the Asia/Singapore (AP-SG) region. We are currently managing fifteen distinct BYOC trunks across multiple regions, and while the AP-NE and EU-FRA connections remain stable, the AP-SG trunk is experiencing persistent registration instability. The carrier utilizes a standard SIP INVITE flow, but the Genesys Cloud edge is returning a 408 Request Timeout intermittently during the initial registration handshake, specifically when the contact header includes the specific carrier-provided IP ranges. The SIP trace logs indicate that the REGISTER request is sent, but the 200 OK response is not received within the configured timer interval, causing the trunk status to toggle between “Registered” and “Unregistered” every 30 to 45 seconds. This flapping behavior disrupts the outbound routing logic, causing calls to failover to the secondary trunk unnecessarily, which increases latency and complicates our analytics reporting on call disposition. The carrier has confirmed their side is sending the 200 OK, but it appears to be dropped or delayed before reaching the Genesys Cloud edge. We have verified the SIP credentials, proxy settings, and firewall rules, ensuring that UDP ports 5060 and 5061 are open and that no NAT issues are present. The issue persists regardless of whether we use the default keep-alive settings or adjust them to match the carrier’s requirements. The environment is running the latest Genesys Cloud release, and the trunk configuration has not changed recently. The problem seems isolated to the specific carrier’s SIP stack behavior in the AP-SG region, as other carriers using similar configurations are stable. We need to determine if there is a specific configuration parameter or timeout setting that can be adjusted to accommodate this carrier’s delayed response pattern without compromising the overall trunk stability. The error logs show a consistent pattern of 408 timeouts followed by immediate re-registration attempts, creating a loop that affects call quality and reporting accuracy. Any insights into how to handle this specific SIP timeout issue with BYOC trunks in the AP-SG region would be appreciated. We are looking for a solution that does not require carrier-side changes, as they have indicated no issues on their end.