Just noticed that our SIP trunk registrations are dropping precisely when the weekly WFM schedule publish job completes in Genesys Cloud 2024-2.0. This is causing a brief window of unreachability for agents who are scheduled to be online but whose devices have reset their registration state.
- The issue occurs every Friday at 11:59 PM Central Time when the automated publish workflow triggers.
- Agents using the Genesys Cloud Desktop application (version 7.2.1) report a “Registration Failed” error immediately after the schedule goes live.
- Our SIP trunk provider logs show a burst of 408 Request Timeout responses from the Genesys Cloud edge nodes during the 5-minute publish window.
- The GET /api/v2/wfm/schedules/{scheduleId}/history endpoint confirms the publish was successful, but the telephony layer seems to be resetting session states.
- We have verified that agent availability is correctly updated in the WFM module, so this is not a data sync issue between WFM and the telephony provisioning engine.
- The problem is specific to the weekly publish; daily ad-hoc schedule changes do not trigger this SIP re-registration storm.
- We are using the default SIP trunk configuration provided by Genesys Cloud, with no custom codec restrictions or advanced security profiles applied.
- The impact is minimal but annoying; agents have to manually refresh their softphone connections, which disrupts their start-of-week workflow.
- We have checked the system health dashboard, and all telephony services are reporting green status during the incident window.
- This behavior started appearing after the last platform update, which included changes to the WFM schedule optimization engine.
- We need to understand if there is a known race condition between the WFM publish API and the SIP registration service.
- Is there a way to stagger the SIP re-registration requests to avoid this timeout burst?
- We are considering disabling the automatic publish and using manual overrides, but that defeats the purpose of our automated scheduling workflow.
- Any insights into how the WFM publish job interacts with the telephony provisioning backend would be appreciated.
- We are open to testing any configuration changes that might mitigate this SIP trunk instability during high-traffic schedule updates.