WebRTC Connection Drops During Schedule Publish API Calls

I can’t seem to figure out why our WebRTC softphone connections are intermittently dropping specifically when the WFM schedule publish job runs via the SDK. We use the Genesys Cloud API v2.140.0 to automate our weekly schedule deployments in America/Chicago. The publish process triggers a high volume of API calls to update agent states and availability. During this window, agents on the WebRTC softphone experience sudden disconnections. The error logs show “ICE Candidate Gathering Failed” followed by a “Connection Lost” event. This happens consistently on Tuesdays at 10 AM CST when we push the new shifts. We have verified that the network bandwidth is stable and there are no firewall changes. The issue seems tied to the API load rather than network congestion. We are using the default WebRTC settings provided by Genesys Cloud. No custom STUN or TURN servers are configured. The problem affects agents across different locations but is most prevalent in our Chicago hub. We have tried reducing the batch size of the schedule publish, but the drops still occur. The API response times spike during the publish window, which correlates with the softphone disconnects. We suspect that the WebRTC signaling server is struggling with the concurrent API requests. Is there a known limitation on concurrent API calls that impact WebRTC stability? We need a reliable way to publish schedules without disrupting active agent sessions. The current workaround is to publish during off-peak hours, but this delays the schedule availability for agents. We would appreciate any insights into optimizing the API calls or configuring the WebRTC settings to handle this load. Here are the specific details of our environment:

• Region: us-east-1
• SDK Version: 2.140.0
• API Endpoint: /v2/wfm/schedules/publish
• Error Code: ICE Candidate Gathering Failed
• Agent Count: 150 active during publish window
• Network: Corporate VPN with stable latency

We have checked the WFM logs and confirmed that the schedule publish completes successfully. The issue is purely on the softphone side. Any guidance on mitigating this conflict would be greatly appreciated.

Ah, yeah, this is a known issue…

The WebRTC drops likely stem from resource contention during the bulk API operations. The WFM publish job generates significant load on the underlying infrastructure, which can impact the WebSocket stability required for WebRTC signaling. Here are some adjustments to test:

• Throttle the API Calls: Reduce the concurrency in your SDK script. Instead of publishing all schedules simultaneously, batch them. For example, publish 50 agents per request with a 2-second delay between batches.
• Check WebSocket Heartbeats: Ensure your softphone client is sending regular ping/pong messages. If the API load causes slight latency spikes, the client might timeout the connection.
• Monitor Network Jitter: Use a tool like JMeter to simulate the API load while monitoring network latency. High CPU usage on the server handling these requests can drop packets.
• Stagger Publish Times: If possible, schedule the publish job during off-peak hours when agent call volume is low. This reduces the total load on the system.

These steps should help stabilize the connections during the publish window.

The documentation actually says schedulePublish triggers bulk updates that can saturate the WebSocket connection. Instead of throttling, try implementing exponentialBackoff in your SDK client. Set retryLimit to 3 and backoffFactor to 2. This reduces the immediate load spike during America/Chicago peak hours without sacrificing deployment speed.