What is the reason this setting causes the Genesys Cloud WebRTC softphone to fail on Firefox when migrating agents from Zendesk Talk? We are moving our support team to Genesys Cloud and replicating the voice setup. In Zendesk, the browser-based phone just works with minimal config. Here, however, the softphone fails to initialize on Firefox 121.0, throwing a MediaStreamError in the console. Chrome works fine, which is frustrating for our agents who prefer Firefox.
The configuration below is derived from our Zendesk voice settings, mapped to the Genesys Cloud user_settings API. We are using the genesys-cloud-webrtc-sdk v1.2.4. The error suggests a codec negotiation issue, but the YAML looks standard.
voice_settings:
webrtc_enabled: true
preferred_codecs:
- opus
- pcma
- pcmu
ice_servers:
- urls: "stun:stun.l.google.com:19302"
- urls: "turn:turn.genesys.cloud:3478"
username: "agent_aki"
credential: "secret"
Is there a specific Firefox preference or a Genesys Cloud admin setting we are missing that differs from the Zendesk default behavior?
The easiest fix here is this is…
{
"media_settings": {
"stun_servers": [
{ "url": "stun:global.turn.twilio.com:3478" },
{ "url": "stun:2.stun.twilio.com:3478" }
],
"turn_servers": [
{
"url": "turn:global.turn.twilio.com:3478?transport=udp",
"username": "your_turn_user",
"credential": "your_turn_pass"
},
{
"url": "turn:global.turn.twilio.com:3478?transport=tcp",
"username": "your_turn_user",
"credential": "your_turn_pass"
}
]
}
}
Firefox is strictly stricter about ICE candidate gathering compared to Chrome. Chrome often tolerates a lack of explicit TURN servers by falling back to STUN or direct connections if NAT traversal allows it. Firefox frequently throws a MediaStreamError if the initial ICE gathering fails to find a valid path within the default timeout.
In a load testing context, we see this exact behavior when the WebSocket signaling layer is healthy, but the media layer cannot establish a peer connection. The issue is rarely the softphone binary itself, but the network configuration passed to the WebRTC stack.
Ensure your Genesys Cloud organization settings have valid, reachable STUN and TURN servers configured. If you are behind a complex corporate firewall, Firefox will not retry as aggressively as Chrome. You must provide a fallback TURN server that supports both UDP and TCP transports.
Also, verify that your agents are not running aggressive ad-blockers or privacy extensions in Firefox. These extensions sometimes block the getUserMedia permission prompts or interfere with the WebSocket handshake required for the softphone to register. Check the browser console for any CORS errors related to the signaling endpoint. If the signaling works but media fails, it is almost certainly an ICE/STUN/TURN resolution issue. Add explicit TURN servers to your config and retry the initialization.