The callback scheduling block in Architect keeps timing out when the WebRTC softphone is active. Running Architect v2024.2 with the WebRTC SDK 3.12.0 in US1. Standard in-queue callback setup with a 45-second estimated wait threshold. Customer hits the callback option, flow checks the queue position, and triggers the /api/v2/callbacks endpoint. First request lands clean. The retry logic fires after 120 seconds if the queue position doesn’t update, but the second request bombs with a 408 Request Timeout. Console logs show the softphone signaling a mid-call state change right before the retry triggers. Looks like the WebRTC session is holding the interaction lock, blocking the callback API call entirely. It’s blocking the whole flow. You’ll see the media stream stay active while the retry path just hangs.
Dropped a screenshot of the flow trace below. The timing aligns perfectly with the ICE candidate refresh cycle. Customer experience takes a serious hit here. Folks get stuck in a loop where the IVR promises a callback, then the line goes dead after the retry fails. Workaround involves adding a 3-second wait block before the retry trigger, which bypasses the softphone state check. Stops the 408s, but the UX feels sluggish because of the extra delay. The flow doesn’t wait for the media stream to drop. The Architect docs mention interaction state conflicts, but nothing about softphone signaling interfering with scheduled callbacks. Trace ID 8f3a9c21 shows the exact millisecond drop on the retry path. Error payload returns {"code":"request_timeout","message":"Callback scheduling failed due to active media session"}.
The 408 timeout hits because the WebRTC session locks the media channel while the Architect flow tries to push the callback request through the same routing context. Seen this exact brick in that us-east-1 pacing thread last month. Decoupling the scheduling logic from the active softphone session fixes it.
Drop a 3-second delay block right before the callback API action. It forces the WebRTC handshake to settle. Then switch the routing configuration in the admin UI to handle callback queues independently from your standard predictive pacing rules. Set the callback routing strategy to “Longest Available Agent” instead of letting it inherit the outbound pacing multiplier.
{
"routing_strategy": "longest_available_agent",
"max_wait_time_seconds": 45,
"fallback_action": "play_message",
"retry_interval_seconds": 15
}
Paste that into the callback queue settings under Routing > Queues > Callbacks. The 15-second retry interval beats the default 120-second hammer that triggers the 408. Make sure the DNC validation block doesn’t sit between the delay and the API call. It’ll freeze the whole flow just like that eastern window sync thread mentioned last week.
Keep the pacing multiplier under 1.5x for these callback queues. The admin UI chokes when it tries to balance predictive outbound calls with inbound callback routing on the same agent pool. Abandonment rates spike if the system keeps retrying a locked session. Compliance flags get triggered when the queue position never updates. Switch the queue to progressive mode temporarily if the timeouts persist. The pacing engine just drops the packet when it tries to force-feed a blocked channel.