Predictive pacing drops to zero when BYOC latency passes 120ms, which pushes abandonment past the 3% compliance limit. Should the SIP stack force a custom 183 media override since trunk settings have Early Media off but local ringback still triggers? We’ve checked the edge logs, but the rate stays flat, and the /api/v2/outbound/campaigns/{id} endpoint keeps returning 422 UNPROCESSABLE ENTITY with PREDICTIVE_MODEL_TIMEOUT.
Latency over 120ms breaks the model. That timeout error normally pops up when the pacing engine just waits too long for a media path confirmation. In CXone, you’d tweak the predictive_pacing_timeout inside the campaign settings, but GC maps that directly to the pacing_strategy object in the update payload. The timeout_threshold_ms replaces the old CXone dialer delay config, and force_model_reset clears the stale pacing queue. You don’t actually need a SIP 183 override since early media is already off.
{
"pacing_strategy": {
"type": "PREDICTIVE",
"timeout_threshold_ms": 150,
"force_model_reset": true
}
}
Push that to the campaigns endpoint and the rate should climb back up. Are you routing through a third-party SIP provider or a direct carrier link? Check the edge jitter buffer settings if the latency spikes keep hitting the provider side.
You might want to skip the SIP override entirely and just reset the pacing model through the API instead. PureCloudPlatformClientV2 handles the campaign update by expecting a strict pacing_strategy object, so you’ll need to map the timeout threshold directly in the PATCH body. First, grab the baseline config using outboundApi.getCampaign(). Next, construct a payload that sets timeout_threshold_ms to 250 and flips force_model_reset to true. The client validates that JSON against the routing schema before it even leaves your process, which stops the 422 from hitting the queue engine.
PATCH /api/v2/outbound/campaigns/{campaignId}
{
"pacing_strategy": {
"timeout_threshold_ms": 250,
"force_model_reset": true,
"strategy_type": "PREDICTIVE"
}
}
Running that clears the stale dialer queue without touching trunk media settings. Usually works faster. Edge logs stay quiet.
Log snippet from our console shows the missing type field causing the 422:
[2024-05-21T09:15:00.442Z] ERROR OutboundCampaignUpdate: 422 UNPROCESSABLE ENTITY - Field pacing_strategy.type is required...
The API approach works, but the endpoint doesn’t accept the patch when the strategy type is implicit. You’ll need to send the full structure.
{
"pacing_strategy": {
"type": "predictive",
"timeout_threshold_ms": 250,
"force_model_reset": true
}
}
Excuse me, I apologize for the basic question, but our team faced this issue during the shift change. At 09:15:00 CET, the pacing model stopped responding when latency hit 130ms on the .jp edge.
Check division permissions. The 422 error often appears when the campaign is in a locked division state. The force_model_reset flag might need a division context for multi-site setups.
Log output is incomplete because the buffer flushed:
... response status: 200 OK ...