Trying to understand why our primary SIP trunk is dropping calls with a 487 Request Terminated error immediately following our weekly schedule publication on Fridays at 4 PM Central. We are operating Genesys Cloud Encompass with a custom SIP B2BUA integration that relies on the WFM schedule state to determine trunk capacity thresholds. The issue manifests specifically when the /api/v2/wfm/schedules endpoint returns a 200 OK status but the downstream telephony gateway still perceives the capacity as zero for the first 15 minutes. We have verified that the schedule adherence metrics are updating correctly in the WFM dashboard, yet the telephony layer fails to reconcile the new agent availability. The SIP logs show the INVITE reaching the B2BUA, but the subsequent 200 OK is never sent back to the PSTN provider, resulting in a timeout. This pattern does not occur during mid-week ad-hoc schedule adjustments, only the full weekly publish. We are using the latest WFM SDK wrapper for our integration logic. Is there a known propagation delay or cache invalidation issue between the WFM schedule publish event and the telephony capacity engine that we need to account for in our retry logic?
Check your WebSocket keep-alive settings in the load test script. The WFM publish spikes the platform_api, causing the B2BUA to drop idle connections.
"keepAliveIntervalMs": 15000,
"idleTimeoutMs": 45000
Increase these values to survive the API storm without triggering 487 errors.