WebRTC Softphone Disconnects Corrupting Agent Performance Metrics in Performance Dashboard

Voice & Telephony
1

Stumbled on a weird bug today with the WebRTC softphone integration affecting our agent performance reporting. We are using Genesys Cloud v2024.09 with the latest embedded client version. The issue manifests when agents experience brief network fluctuations causing the WebRTC connection to drop and reconnect within a 10-second window. While the call continues successfully from the customer’s perspective, the performance dashboard incorrectly logs these events as separate call segments or marks the agent as unavailable during the reconnection phase.

This discrepancy creates a significant gap between the actual talk time recorded in the conversation detail views and the productivity metrics shown in the queue activity reports. Specifically, the ‘Talk Time’ metric in the agent performance view is inflated by the reconnection delay, while the ‘After Call Work’ appears to start prematurely. We have verified that the SIP trunks are stable and the issue is isolated to the WebRTC client behavior on Windows 11 and macOS Sonoma environments.

We need to understand how the platform reconciles WebRTC session IDs with the underlying call leg identifiers. Is there a configuration setting in the Architect flow that can suppress these micro-disconnects from being logged as state changes? Alternatively, are there specific API endpoints or analytics filters that can be used to cleanse this data before it populates the performance dashboards? Our current workaround involves manual data correction, which is not scalable for a team of 150 agents. We require a definitive solution to ensure that the performance metrics accurately reflect agent productivity without being skewed by client-side reconnection artifacts.

2

You need to adjust the Reconnection Threshold in your WebRTC softphone configuration to prevent these false segments. The default 10-second window is too aggressive for standard network jitter. Set max_reconnect_delay_ms to 30000 (30 seconds) in the client initialization payload. This ensures the session remains active during brief packet loss without triggering a new interaction ID in the backend.

Here is the JMeter config snippet for testing this stability:

{
 "reconnectThreshold": 30000,
 "keepAliveInterval": 5000,
 "stunServers": ["stun:turn.example.com:3478"]
}

Run a load test with 100 concurrent agents using this config. Monitor the /api/v2/analytics/interactions endpoint for duplicate session IDs. If the dashboard still shows splits, increase keepAliveInterval to 10000. This usually stabilizes the metric aggregation during fluctuating network conditions. Avoid setting thresholds below 15 seconds as it causes excessive API calls to the session service.

3

The best way to fix this is to ensure the X-Genesys-Client-Id header is explicitly set in your WebRTC signaling requests. Missing this header causes the regional edge node to treat each reconnection attempt as a separate client, instantly triggering new interaction IDs and corrupting the metrics.

4

Take a look at at the reconnection timeout values in your JMeter setup. If the simulated network drop exceeds the client’s tolerance, it resets the session. Adjusting the delay can help maintain the interaction ID during brief outages.

{
 "reconnect_timeout_ms": 30000
}