Just noticed that the Predictive Routing confidence scores are dropping significantly when calls route through our secondary BYOC trunk during failover drills in the Asia/Singapore region. We manage 15 BYOC trunks, and while the primary carrier maintains stable SIP registration and latency under 150ms, the secondary carrier introduces a 300ms jitter spike. This latency appears to corrupt the initial handshake data sent to the Predictive Routing engine.
The issue manifests in the Architect flow where we use the Get Predictive Routing Score action. When the call bridges via the secondary trunk, the API returns a score of 0.12 instead of the expected 0.85+ for high-priority inbound segments. This causes the call to be queued unnecessarily, increasing AHT by 45 seconds per interaction as agents manually verify the segment data.
We checked the SIP logs and confirmed that the SDP negotiation completes successfully, but the custom headers containing the segment ID are being stripped or delayed by the secondary carrier’s gateway. The documentation states:
“Predictive Routing requires real-time access to call metadata. Any delay or loss in SIP header transmission during the initial setup phase may result in default scoring behavior.”
This default behavior seems to be triggering incorrectly. We have verified that the outbound routing rules prioritize the secondary trunk only when the primary health check fails. The health check itself is passing, but the actual media path switches due to a false positive on packet loss detection.
Has anyone encountered similar scoring discrepancies when using BYOC trunks with high-latency secondary carriers? We are considering adjusting the timeout thresholds in the Predictive Routing configuration, but we want to ensure this does not impact our overall routing accuracy. The current SDK version is v2.4.1, and we are using the standard REST API endpoints for score retrieval.