Hi Robert,
I took a closer look at that message, and I think there may be another angle worth investigating before treating this as a headset or workstation issue.
The reducedMedia state itself appears to be related to how the Genesys Cloud WebRTC client decides which client instance should actually handle media.
In the current Genesys Cloud WebRTC SDK, setMediaHandling() is marked as Genesys internal use only, and the SDK documentation specifically says that the media-handling mode should be selected based on the alerting leader status of the consuming client. When reducedMedia is selected, the SDK also disables headset usage and releases idle persistent connections. The source even comments that when a client is no longer the alerting leader, it needs to give up those persistent connections while active calls are preserved.
That makes me wonder whether the warning:
setUseHeadsets was called with true but media handling is set to reducedMedia
may be a consequence of that client currently operating as a reduced-media/non-alerting instance, rather than indicating that the headset itself is unsupported.
This would also fit with the newer WebRTC Alerting Leader behavior. Genesys Cloud can now determine which WebRTC client receives inbound alerts when the same user has multiple active clients, including browser/desktop, embedded clients, or multiple instances of the same client type.
A few details might help confirm whether this is what you are seeing:
-
Are these users running more than one Genesys Cloud client at the same time - for example browser + desktop app, multiple tabs, or an embedded client alongside the main Genesys UI?
-
Is WebRTC Alerting Leader enabled/configured in the organization?
-
Where exactly were these logs collected - from the client currently receiving WebRTC calls or from another active Genesys instance?
-
Do all simultaneous client instances show the warning, or only one of them?
-
Most importantly, are the users experiencing any actual symptom - audio problems, missed calls, or headset buttons such as Answer/Mute/Hang Up not working - or is the warning only visible in the logs?
Genesys also documents multiple tabs, browser + desktop, different computers, and embedded client + browser/desktop as concurrent login scenarios, with Alerting Leader being the mechanism intended to support this more predictably.
The headset model, connection type (USB/dongle/Bluetooth), OS and browser/client version would still be useful, especially if there is an actual headset-control problem. But I would first try to determine whether all of these users have multiple WebRTC client instances and whether the warning is being generated by an instance that is intentionally operating in reduced-media mode.
If there is no observable issue for the agents, it may turn out that the log is describing expected media/headset orchestration for that particular client instance rather than an actual failure.
------------------------------
Fernando Sotto dos Santos
Consultor de Atendimento Senior Grupo Casas Bahia
------------------------------