Predictive Routing Campaign Pauses Despite BYOC Trunk Capacity and No 5xx Errors

Why does this setting in the Predictive Routing campaign configuration cause the dialer to enter a “Paused” state with zero active agents, even when our BYOC trunks show healthy SIP registration and no 5xx errors?

We are managing 15 BYOC trunks across APAC regions, primarily Singapore and Sydney. The issue manifests specifically during the 09:00 SGT ramp-up period. The Architect flow is standard for outbound predictive dialing, routing through the SG_BYOC_PRIMARY trunk group. The trunk health dashboard shows 100% registration stability. SIP INVITEs are being sent, and the carrier is responding with 180 Ringing. However, the PR engine stops dialing after approximately 45 seconds, citing “Insufficient Agent Capacity” despite having 50 available agents in the skill group.

I have verified the following:

  • Agent skill proficiency is set to 1.0.
  • The campaign’s “Max Active Calls” is set to 500, well above our current utilization.
  • The “Predictive Dial Rate” is conservative at 2.0.
  • No SIP errors (4xx/5xx) are logged in the Call Detail Records (CDR) for the affected interval.

The logs show a discrepancy between the PR engine’s view of agent availability and the actual workforce management data. It seems the PR engine is factoring in a hidden penalty or delay metric related to the BYOC trunk latency, which is averaging 120ms (well within acceptable limits).

“The Predictive Routing engine dynamically adjusts the dialing rate based on real-time agent availability and call connect rates. If the engine detects a mismatch between expected connect time and actual SIP response latency, it may throttle or pause the campaign to prevent abandoned calls.”

Has anyone encountered this specific throttling behavior on BYOC trunks? Is there a specific API endpoint or debug log I can query to see the internal “agent availability” calculation the PR engine is using at the moment of pause? I need to determine if this is a configuration error in the trunk failover logic or a platform-side bug with latency tolerance thresholds.