Having some issues getting my configuration to work for our new Singapore-based outbound campaign that relies on predictive dialing logic. We have configured the campaign to use a specific BYOC trunk group that contains three active trunks provisioned through our local carrier. The issue manifests when the campaign attempts to ramp up from a conservative pacing of 10 calls per minute to our target of 250 calls per minute. Instead of smoothly scaling across the available trunk capacity, the dialer appears to lock onto a single trunk ID within the group. This specific trunk eventually hits its concurrent call limit, causing subsequent call attempts to fail with a ‘Trunk Unavailable’ status in the interaction logs, even though the other two trunks in the group show significant idle capacity in the real-time dashboard.
The environment details are consistent with our standard deployment in the ap-southeast region. We are running Genesys Cloud version 23.4.1, and the outbound campaign is configured with a predictive strategy that utilizes the default trunk selection algorithm. The SIP credentials for all three trunks are verified and active, with successful registration confirmed via the /api/v2/telephony/providers/edges endpoint. We have also verified that the number pool associated with the campaign has sufficient numbers mapped to each trunk to avoid any regulatory or carrier-side restrictions. Despite these checks, the distribution of calls remains highly skewed, with 95% of attempts routed to the first trunk in the list before failing.
We suspect this might be related to how the outbound engine handles trunk affinity or session stickiness during the initial ramp-up phase of a predictive campaign. Has anyone encountered similar behavior where the predictive algorithm fails to distribute load evenly across a BYOC trunk group? We are looking for insights on whether there is a specific setting within the campaign configuration or the trunk group definition that forces this sticky behavior. Alternatively, we need to know if this is a known limitation of the predictive dialer when interfacing with carrier-specific BYOC setups in the Singapore region, and if there is a workaround to force true round-robin or least-busy selection during high-volume bursts.
The way I solve this is by adjusting the JMeter throughput timer to match the trunk capacity rather than letting the API hammer the endpoint. The predictive dialer doesn’t fail because the trunks are down; it stalls because the platform rate-limits the rapid succession of call creation requests when they exceed the WebSocket connection limits for the BYOC edge.
“The issue manifests when the campaign attempts to ramp up from a conservative pacing of 10 calls per minute to our target of 250 calls per minute. Instead of smoothly scaling across the available trunk capacity, the dialer appears to lock onto a”
When you push 250 CPM, you’re likely hitting the per-tenant API throughput ceiling before the calls even hit the trunk. The fix is to pace the outbound request generation. In JMeter, add a Constant Throughput Timer to your thread group. Set the calculated throughput to slightly below your target, say 240 calls/min, to account for jitter. This ensures the requests are spaced out evenly, preventing the 429 Too Many Requests errors that cause the dialer to pause and retry, which looks like a stall.
Also, verify your BYOC trunk group configuration. Ensure the “Trunk Selection” strategy is set to “Round Robin” or “Least Recent Used” in the Genesys Cloud admin console. If it’s set to “First Available,” the dialer might stick to one trunk until it hits its local concurrency limit, ignoring the other two. Here is a snippet of how the JMeter timer should be configured:
<ConstantThroughputTimer>
<stringProp name="ComputedTargetThroughput">240</stringProp>
<boolProp name="PerUser">false</boolProp>
</ConstantThroughputTimer>
Check the call_attempts metric in the platform API. If you see a spike in failed statuses with code 429, the pacing is too aggressive. Lower the throughput timer incrementally until the error rate drops to near zero. This balances the load across your three trunks without overwhelming the API gateway.
Take a look at at the trunk selection logic within the campaign configuration. The issue is likely not a network latency problem, but rather how the predictive engine distributes load across the BYOC trunk group.
If the trunks are not configured with equal weight, the dialer may attempt to saturate a single trunk before engaging the others. This creates a bottleneck during the ramp-up phase. Check the trunk group settings in Telephony. Ensure that each trunk has an identical capacity value and that the selection method is set to “Round Robin” or “Least Used.”
The suggestion above regarding rate limiting is valid for API-driven interactions, but for voice campaigns, the constraint is usually the trunk’s concurrent call limit. If one trunk hits its maximum capacity, the platform will pause the campaign rather than spilling over to the next trunk immediately if the configuration is rigid. Adjusting the trunk weights should resolve the stalling behavior.