Just noticed that our agents in the Chicago cluster are experiencing immediate WebRTC softphone disconnections when I trigger the weekly schedule publication via the WFM API. The error manifests as a WebSocket close code 1006 (Abnormal Closure) in the browser console, followed by a “Connection Lost” notification in the Genesys Cloud UI within 3-5 seconds of the publish job starting. This only happens during the high-concurrency window of our Tuesday 9 AM CT publish cycle, not during ad-hoc schedule updates.
The environment is running Genesys Cloud standard edition with the latest Chrome browser (v120+). We are using the default WebRTC configuration without any custom STUN/TURN overrides. Interestingly, the SIP trunk registrations remain stable, and inbound calls via PSTN continue to ring correctly for agents who have not yet refreshed their browser tabs. However, once an agent attempts to rejoin their softphone session post-publish, they get a 401 Unauthorized error until they perform a full logout/login cycle.
I have checked the WFM audit logs and the API request returns a 200 OK, so the schedule data itself is valid. The issue seems tied to the real-time status sync between the WFM service and the Media Processing service. When I disable the “Auto-pause” feature for agents during the publish window, the disconnects stop, but this defeats the purpose of our shift-swapping workflow where agents need to see their updated availability instantly.
Has anyone configured a specific delay or rate-limiting parameter for the WFM-to-Media service sync? We are trying to avoid forcing 200+ agents to manually refresh their browsers every week. Looking for a workaround that maintains the real-time schedule visibility without breaking the WebRTC signaling channel during the publish transaction.