Firefox does not give video or sound

We are running the latest version of Jitsi, relay all tcp and udp trafik via TURN. The setup works great with Edge, Chrome, Safari… but Firefox appears to have problem getting the ICE trickle to work.

Entering the meeting works, but no video or sound = no active webRTC channel.

The browser console does not throw any error messages in regards to this, webrtc dev tool shows no stable ICE connection.

JVB 2022-10-17 11:29:56.666 SEVERE: [2183] [confId=1234567890 epId=12345678 stats_id=ABCDE-FGH] DtlsServer.accept#52: Error during DTLS connection: org.bouncycastle.tls.TlsTimeoutException: Handshake timed out
JVB 2022-10-17 11:29:56.666 SEVERE: [2183] [confId=1234567890 epId=12345678 stats_id=ABCDE-FGH] DtlsTransport.startDtlsHandshake#110: Error during DTLS negotiation, closing this transport manager
org.bouncycastle.tls.TlsTimeoutException: Handshake timed out
           at org.bouncycastle.tls.DTLSReliableHandshake.receiveMessage(Unknown Source)
           at org.bouncycastle.tls.DTLSServerProtocol.serverHandshake(Unknown Source)
           at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source)
           at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source)
           at org.jitsi.nlj.dtls.DtlsServer.accept(DtlsServer.kt:45)
           at org.jitsi.nlj.dtls.DtlsServer.start(DtlsServer.kt:41)
           at org.jitsi.nlj.dtls.DtlsStack.start(DtlsStack.kt:150)
           at org.jitsi.videobridge.transport.dtls.DtlsTransport.startDtlsHandshake(DtlsTransport.kt:107)
           at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
           at java.base/java.util.concurrent.ThreadPoolExecutor$
           at java.base/

Any ideas?

Do you see any errors in the browser JS console? What FF version is that?

This was solved by updating the underlaying infrastructure, appears Firefox is more picky on the addresses presented by the ICE process

Hi, Could You give some more details, now I am struggling same issue.

Is Chrome, Safari and Edge working fine? Do you allow VP8 codec?

If yes, it could be due to that Firefox is more picky on the IP adresses ICE picks up on the way. In the Jitsi GUI, check the remote and local IP adress being presented

Are they what you expect? If no, this could be the issue. Also, have a look in the browser console for any errors

Yes, Chrome, Safari, Edge working fine. VP8 is allowed.
I don’t see any specific errors in console. In Chrome addreses are as expected.

Ice status from firefox

Is the 10.x.x.x adress the client? Same issue with p2p?

.6 is coturn .45 is JVB, since we are using jibri p2p is disabled.

Would be interesting to see if the issue appears with p2p, just to help narrow down the behaviour

Do nginx/turn/jvb logs throw any error messages when a ff user connects?

I am also seeing this behaviour from Firefox (107.0.1). When connecting trough TURN (TCP) there is no video or audio. It works every time in Chrome.
With Firefox it works maybe 1 out of 10 attempts, often the first attempt after a server restart.

The WebRTC stats image above is very similar to what I’m seeing.

We managed to fix this issue, needed to add bellow to jvb.conf

    ice {
      advertise-private-candidates = false

also we needed to add public IP to coturn- before fix it was running on private IP behind Load Balancer, and add public IP addresses to JVBs - before fix it was working on private adresses. Looks like this is needed on firefox for some reason - or maybe someone have idea how to run again on private addreses.

Changing advertise-private-candidates = false did not resolve the issue for us.

We are running Jitsi (docker) on machine with a private IP. The firewall with public IP forwards all relevant ports to the Jitsi server.
The same for Coturn, (coturn on machine with private IP. Firewall with public IP forwarding all ports to coturn server).

We have tested Firefox both by blocking access to port 10000 and also by setting in about:config.

No errors in console, we can join the meeting but no video/sound only a black screen.

Are you setting JVB_ADVERTISE_IPS to your public IP for media?

Yes it is set to the public IP.
For Chrome and Safari it does not seem to mater if this is set or not since the JVB public IP is discovered with STUN.

As we compared our ICE statistics to we saw that there are only public candidates and in our understanding Coturn need ip address definitely- same on JVB each one need public IP. When we tested coturn without public IP accesible by NLB it was not working. Onle when we added public IP to coturn and jvb it started working on firefox

Thank you for the information. Unfortunately we are not able to move the TURN server from behind the NAT at this time.

I tried switching out Coturn for Eturnal but got the exact same results for Firefox.
Not sure if this is a bug in Firefox ICE handling or if it is Chrome/Edge/Safari handling things outside the specifications.