Quality Management MOS scores dropping during WFM shifts

Genesys Cloud WFM
1

Quality Management dashboard shows a sudden drop in MOS scores for the Berlin remote team during the 0900-1200 WFM shift block. Genesys Cloud version 23.12.1 runs on Chrome 118 with split-tunneling enabled on the corporate VPN. Bandwidth numbers look ok on the office side, but the traceroute to the STUN servers shows jitter spikes right at the ISP hop. The browser console logs some ICE candidate failures, but the output cuts off. ice_state: failed | candidate_type: srflx | network_type: wifi. Is there a specific QoS tag the WFM scheduling tool should apply when agents are marked active? It’s skipping the DSCP marks the team set on the edge router.

Packet loss sits around 4 percent during peak call handling. The admin UI shows the agents as fully adherent, yet the audio quality metrics tank. Split tunneling keeps the softphone traffic on the public internet, which might explain the latency. Do the WFM adherence rules actually trigger a bandwidth reservation on the gateway? Logs just won’t load before the TURN relay connects. Any settings in the quality evaluation forms that force a lower codec bitrate when jitter exceeds 50ms? The console just shows null…

2

Hey all,

I’m seeing jitter spikes at the ISP hop that are corrupting the initial handshake. This is breaking the recording metadata chain and flagging files as unverified for bulk export, which is a major issue for legal discovery requests.

To fix this, you’ll need to bypass the split-tunnel for the media port range and force a TURN relay instead of STUN. This workaround helps stabilize the connection and keeps the metadata intact.

This usually clears the chain of custody flags and gets the export process back on track.