Can anyone clarify why there is a significant variance in how Genesys Cloud logs SIP 408 Request Timeouts compared to our carrier SBC metrics for our Singapore-based BYOC trunks? We are currently managing 15 trunks across the APAC region, and our analytics reporting indicates a 4% failure rate on outbound calls initiated via the outbound-campaigns API. However, our carrier’s SBC logs show only a 0.8% timeout rate for the same time window.
The issue appears isolated to trunks configured with the auto-failover strategy enabled. When a call fails on the primary carrier, the platform attempts a retry on the secondary carrier. In the Architect flow, we are using the Make Phone Call block with a specific trunk_id attribute. The flow logs explicitly state Call failed: SIP 408 Request Timeout at timestamp 2023-10-27T08:15:22Z. Yet, when we cross-reference this with the carrier’s CDRs, the INVITE was actually answered with a 200 OK, but the media stream failed to establish within the Genesys Cloud timeout window.
We are running Genesys Cloud v2023-10 and our SBCs are configured with TLS 1.3 enforcement. The SIP INVITE headers include the Contact field pointing to our SBC’s public IP. We have verified that the From and To headers match the registered SIP identities. The discrepancy suggests that Genesys Cloud might be timing out the INVITE transaction before the carrier’s 200 OK response is fully processed, or there is a latency issue in the signaling path that is not being captured in the standard telephony-events stream.
Has anyone encountered similar latency issues with the auto-failover logic where the platform prematurely marks a call as failed due to a 408, even though the carrier successfully initiated the call? We are looking for a way to adjust the timeout threshold or debug the exact point of failure in the SIP dialog to align our internal analytics with carrier-side data.