Our management team relies on accurate interaction metrics for our executive dashboards, but we’ve noticed a strange data anomaly recently.
Several of our agents are reporting that the Genesys Cloud desktop app (running via Chrome browser) is not releasing their microphone after a call is disconnected. This causes their state to get stuck, which skews our tHandle metrics and active conversation counts in the Analytics API conversations/details/query.
I checked the raw interaction data and the disconnect event seems to be missing when this happens. Is this a known Chrome WebRTC bug? We are tracking these discrepancies in Power BI and need a way to filter them out until it is resolved.
From an HR and agent engagement perspective, this is actually causing a lot of frustration on the floor.
We run several gamification contests based on call volume and handle times. Because agents are getting stuck with the mic locked, their KPIs drop artificially, which means they lose out on leaderboard points and rewards.
I can’t speak to the technical WebRTC side of things, but our agents found that completely closing the Chrome tab and reopening it is the only way to reset the state and get back into the queue to keep their numbers up.
I’ve seen audio device contention cause similar hangups, especially if you have Microsoft Teams running alongside the browser client.
We use Teams Direct Routing with our SBCs, and sometimes the Windows audio subsystem locks the mic exclusively to Teams if a background presence sync happens exactly as the GC call disconnects.
You can check the PowerShell Get-Process for any locked audio handles, but a quick workaround is disabling ‘Allow applications to take exclusive control of this device’ in the Windows sound control panel.
Potential Workaround for the Chrome Mic Lock
We ran into this exact issue in our healthcare environment. It seems to happen specifically with Chrome 118+ when the WebRTC media connection drops unexpectedly rather than closing gracefully.
FWIW, here are a few things we did to mitigate it while waiting for a platform fix:
- Force Media Refresh: We told agents to use the ‘Reload’ button inside the GC interface rather than refreshing the whole tab.
- WebRTC Diagnostics: If you look at the
chrome://webrtc-internals dump, you’ll see the MediaStreamTrack is still active.
- Client Logging: Enable advanced logging in the GC desktop app and look for ICE disconnection errors.
YMMV, but we also wrote a quick Python script to monitor agent presence via the API and alert us if someone is stuck in a weird state for more than 10 minutes:
# pseudo-code for presence check
routing_status = api_instance.get_users_routingstatus(user_id)
if routing_status.status == 'INTERACTING' and call_duration > 600:
alert_supervisor(user_id)
That might give you some leads to track down the skewed dashboard metrics.
This is definitely a pain point. When we were doing a migration from NICE CXone, we actually compared the agent experience heavily.
In CXone MAX, the WebRTC session is handled a bit differently and seems to tear down the socket much faster upon disconnect. In Genesys Cloud, the persistent connection is great for rapid call delivery, but it does leave you vulnerable to these browser-level hardware locks if the tear-down sequence gets interrupted.
One thing to check: are your agents using a VDI environment? We noticed this bug was 10x worse when running GC inside Citrix compared to a local Chrome installation.