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 conf_name=test123@muc.meet.jitsi 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 conf_name=test123@muc.meet.jitsi 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(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
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
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 media.peerconnection.ice.relay_only=true in about:config.
No errors in console, we can join the meeting but no video/sound only a black screen.
As we compared our ICE statistics to https://meet.jit.si/ 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.
