Configuration is broken for some reason correctly regarding outbound call distribution across our 15 BYOC trunks in the AP-SE-2 region. We are seeing significant skew in Predictive Routing campaigns where calls are disproportionately routed to trunks with higher observed latency, despite equal weighting in the outbound routing configuration. The campaign is configured to use ‘Least Cost’ as the primary selection criteria, but the actual distribution does not match the expected cost models when accounting for the real-time SIP registration status and carrier response times.
The environment involves Genesys Cloud Engage with SDK v2.14. The outbound routing rules are set to prioritize specific carrier IDs based on cost tiers. However, when the predictive engine selects a trunk, it occasionally selects a carrier that is experiencing intermittent SIP 408 Request Timeouts, leading to abandoned calls before the carrier even answers. This is particularly problematic during peak hours in the Asia/Singapore timezone when load is highest. The analytics endpoint /api/v2/analytics/conversations/details/realtime shows a discrepancy between the ‘scheduled’ calls and ‘connected’ calls, with a high rate of ‘carrier_timeout’ errors specifically associated with the secondary failover legs.
We have verified that the SIP credentials are valid and the trunks are registered. The issue seems to stem from how the predictive routing engine evaluates trunk health in real-time. It appears to be ignoring recent failure metrics when making routing decisions for high-volume campaigns.
- Adjusted the outbound routing rules to explicitly exclude carriers with >5% failure rate in the last 15 minutes, but the predictive engine still selects them.
- Increased the timeout threshold for SIP INVITE responses from 5s to 10s, which reduced timeouts but increased average call setup time, negatively impacting agent wrap-up times.
Is there a way to force the predictive routing engine to consider real-time SIP registration health and recent failure rates more heavily? We need a stable distribution that respects the carrier failover logic without manual intervention.