- Environment: Genesys Cloud v12.5
- Region: US East
- Agent Desktop: Chrome 118, WebRTC softphone enabled
- WFM Module: Schedule Publishing & Shift Swap
Is it possible to correlate WebRTC connection stability with the specific API calls triggered during agent shift swap approvals? We are noticing a pattern where agents on the WebRTC softphone experience intermittent audio dropouts or complete connection resets exactly when the WFM schedule lock is released after a bulk shift swap publication.
The issue seems tied to the POST /api/v2/wfm/schedules endpoint execution. When we process a large batch of shift trades (50+ swaps) via the API, the softphone clients for agents involved in those swaps report a ICE_CONNECTION_FAILED state in the browser console, followed by a reconnection attempt that often fails silently for 10-15 seconds. This disrupts their real-time adherence status, causing false violations in the WFM dashboard.
Has anyone encountered this specific intersection of WFM API throughput and WebRTC stability? We suspect the backend resource contention during the schedule recalculation might be impacting the signaling server’s ability to maintain the SDP offers for active sessions. We are currently looking at the GET /api/v2/voice/web-rtc diagnostics but need to know if there is a known limitation or a specific header we should be checking to isolate the WFM impact from general network latency.