Webrtc softphone connection timeout on firefox

Voice & Telephony
1

Is there a clean way to configure the org settings for firefox webrtc compatibility? our agents are getting a 408 request timeout when trying to connect the softphone on firefox 120. this feels like the old zendesk web widget ssl handshake issues we used to face.

2

The 408 timeout on Firefox 120+ is often tied to stricter WebRTC security policies and certificate chain validation, not just the org settings. Before tweaking Genesys Cloud, check the browser console for DTLS handshake failures.

First, ensure the Genesys Cloud WebRTC endpoint is using a valid, trusted certificate. Firefox rejects self-signed certs by default in modern versions. If using a custom domain, verify the SAN includes the exact subdomain used for the softphone.

# Example check for valid cert in Terraform if managing custom domains
resource "genesyscloud_routing_email_domain" "example" {
 domain = "softphone.example.com"
 # Ensure DNS records point to valid GC endpoints with trusted certs
}

If the cert is fine, the issue is likely the iceServers configuration. Firefox requires explicit STUN/TURN servers with credentials if behind NAT. The default GC config might be timing out on STUN discovery.

Add this to your org settings or agent profile:

{
 "iceServers": [
 { "urls": ["stun:stun.l.google.com:19302"] },
 { "urls": ["turn:turn.genesis.com:443?transport=udp"], "username": "agent", "credential": "secret" }
 ]
}

Warning: Firefox 120+ blocks mixed content aggressively. If your agent desktop loads over HTTP, WebRTC will fail. Force HTTPS in the org settings. Also, check about:config in Firefox for media.peerconnection.ice.default_address_only. Set it to false if agents are on complex networks.

Test with webrtc.org/experiments/playground. If the call works there, the issue is GC’s SDP offer generation. Clear the browser cache and disable extensions like AdBlock, which can intercept WebSocket connections. If the problem persists, check the GC logs for 408 at the WebSocket layer, not just the SIP leg. This often points to a firewall blocking port 443 WebSocket upgrades, not a softphone config error.

3

Yep, this is a known issue with firefox’s strict dtls handling. beyond the cert check mentioned, verify your sip trunk security settings. ensure tls 1.2 is explicitly enabled on the byoc trunk config. firefox drops connections if the server negotiates an older protocol version during the handshake, causing that 408.

4

You need to verify that your BYOC trunk explicitly supports TLS 1.2, as Firefox’s strict DTLS handling often triggers these 408 timeouts. While certificate validation is critical, the protocol mismatch is the usual culprit. Ensure your SIP trunk configuration isn’t negotiating older versions during the handshake.