Quick question about predictive routing behavior when underlying SIP trunks experience intermittent 487 Call Leg Transaction Terminated responses. We are managing 15 BYOC trunks across APAC regions, and recently noticed a significant discrepancy in queue depth calculations versus actual answered calls in the analytics reports. The issue seems to correlate with carrier-specific failover logic. When a primary trunk drops a call with a 487, the platform marks the interaction as abandoned in the real-time dashboard, but the predictive routing algorithm appears to still count that agent as busy for the duration of the configured retry window, leading to a backlog of calls that never actually ring an agent.
We are using Architect version 2023.2 and the latest Genesys Cloud SDK for our custom reporting integrations. The outbound campaign is configured with a predictive dialer profile set to ‘Progressive’ with a target speed of 1.2 calls per agent. According to the Genesys Docs, the system should adjust the pacing algorithm based on real-time answer rates. However, the 487 responses from our secondary carrier are not being treated as ‘no answer’ events but rather as system errors, which stalls the pacing logic.
The specific error trace in the flow logs shows a SIP_REGISTRATION_FAIL followed by the 487, but the interaction object in the database retains a status of ‘queued’ for up to 45 seconds before timing out. This creates a phantom queue depth that inflates our abandonment metrics artificially. We have verified the SIP credentials and registration status on the carrier side, and they report no issues. Is there a way to configure the predictive routing engine to treat SIP 487s as immediate abandon events rather than waiting for the full retry timeout? We need to stabilize the agent load distribution before our next peak hour window tomorrow morning Singapore time. Any insights on how to tweak the failover logic or adjust the predictive model parameters to account for these carrier quirks would be appreciated.