Firefox issue ?

[nlienard]

On Chrome, Safari all is working perfectely
On Firefox, user can connect but is not showing the video of other people. (other can see him).

Is it a general issue on FF ?

thanks

[jech]

We test under Firefox regularly. Did the user choose « Receive: Nothing » in the side menu? Is there anything in the logs?

[nlienard]

User have kept default and i can experience same issue. I double check and it is set by default to "Receive: Everything".
No error message in Firefox.
in FF, we only see our own camera but not other people.
in Chrome, everybody can see each other.

[nlienard]

Case 1:
Alice is using Firefox
Rob is using Firefox
=> They both only see their own face

Case 2:
Alice is using Firefox
Rob is using Chrome
=> Alice see only herself. Rob can see Alice

Case 3:
Alice is using Chrome
Rob is using Chrome
=> They can see each other

[jech]

Could you please show the "ICE Stats" section of about:webrtc on Alice's browser in Case 2? Is there anything in Alice's Javascript consle (Ctrl-Shift-k)?

[jech]

Unable to reproduce. Please reopen if you can provide further information.

[la-balisa]

Hi ! I comment this issue, since i have the exact same problem : Firefox doesn't display other people's camera or shared screen. At the same time, Chromium is able to display video streamed by Firefox (or Chromium obviously).

Some insights on my setup :

• I'm behind a NAT (actually, behind a router which does DMZ to another router which does NAT). I redirected port 8443/tcp and 8444/udp+tcp to my server). I used port 8444 for TURN comms as port 1194 is already used by my openVPN service.
• I setup Galene server using my own experimentation to build a docker image for Galene, that you can find here : https://git.qrok.me/la_balisa/galene-docker-debian
• The Galene container is behind an nginx reverse-proxy (jwilder's one) ; this may be relevant, as the original issue author (nlienard) seems to use one also (haproxy, see running Galene behind haproxy ? #45 )
• I disabled Galene's built-in encryption (-- insecure flag) so i can use my already working letsencrypt setup
• Simple access to web interface works fine, without any SSL or other visible issue. On a faulty firefox session, nothing shows into console (Ctrl-Shift-K)
• Others services works fine within my setup (web pages, music server, minecraft server etc)
• On galene container's logs, i have this : error when handling datagram: failed to handle Refresh-request from CLIENT_IP:56531: no allocation found CLIENT_IP:56531:0.0.0.0:8444

Finally, i notice that this happens only if Firefox connects from WAN ; when i try the same setup but with my 2 clients on the same network than my server (as it's a home server), it works fine !

Feel free to ask for more information :-) I can also give you the URL of my server if you want to see it by yourself (but i would prefer not giving it publicly)

[la-balisa]

Here is a save of my ICE stats section from about:webrtc page on a faulty firefox session. I hid my public IPs.
I also join full about:webrtc save, just in case.

My server is on the distant MY_SERVER_PUBLIC_IP ip, pointed-to by MY_PUBLIC_DOMAIN.
Both clients are on a shared Android connection, at MY_CLIENTS_PUBLIC_IP.

Some networks explanation :

• 192.168.43.X is my Android shared network, so it's clients's local IPs (.105 is my faulty firefox IP)
• 10.88.0.X is my server-side local network ; but i can see 10.88.0.20 on full report, and this IP doesn't exist on my network (can't ping it)
• 192.168.88.X is my server-side first network (only contains my ISP box, and my own router, which creates 10.88.0.X network)
• 172.21.0.X is a docker network on my server, containing reverse-proxy and Galene containers
• 172.18.X.X and 172.17.X.X are other docker networks on my server. No idea why they are referenced here
  ICE stats.txt
  full aboutWebrtc.txt

[jech]

In Galène's log, you should see something about the relay test being successful or not. Please tell us what it says. Please type "/relay-test" in the chat window. It should tell you something. Please let us know what it is, in both Chrome and Firefox. (Just to be clear: we need three results, the server-side relay test, and both client-side relay tests.)

[la-balisa]

On Galene's log, i see this just after server start, and twice a day :
Relay test successful in 55.221258ms, RTT = 939.986µs

But the command /relay-test returns "Relay test failed: Error: timeout" in Firefox AND Chromium (and also on Firefox while on the same network than the server, although video works at this time).

I run the server with -turn MY_PUBLIC_IP:8444

[jech]

On Galene's log, i see this just after server start, and twice a day : Relay test successful in 55.221258ms, RTT = 939.986µs

This indicates that the TURN server is accessible from Galène's server.

But the command /relay-test returns "Relay test failed: Error: timeout" in Firefox AND Chromium (and also on Firefox while on the same network than the server, although video works at this time).

This means that the TURN server is *not* accessible from the browser. You need to make sure that the address MY_PUBLIC_IP:8444 allows incoming TCP traffic (essential) and incoming UDP traffic (less essential, but nice to have).

[la-balisa]

Thank you for your answer. I don't know how to diagnose better. Ports appear open when using online port checker tool, or nc -z -v IP PORT [-u]. Ports are redirected through my router. I tried these from inside and outside my LAN.

I tried using directly server_local_IP:8443 without https, bypassing my reverse-proxy, but same result.
I tried using port 1194, just in case something would be hardcoded, that doesn't help either.
I don't have a firewall on my server neither.

Would you have any idea for something else i could check ? Some way to enable verbose/debug mode maybe ? Or client-side logs, to see which checks are performed ?

Edit : tried outside of Docker, directly on my server, with and without https, with default ports. Didn't try video on Firefox, but the /relay-test is still failing with timeout

EDIT : if i run Galène directly on my server (not containerized), with default ports, and specify -turn 10.88.0.100:1194, then it works from browser connected to my LAN (10.88.0.100 is my server address). But it still fails from clients from outside my LAN.

If i run it with -turn 192.168.88.2:1194 (this IP being the WAN-side of my router), it fails from every browser (yet it succeeds from the server itself). Same result with -turn auto (succeeds from the server itself, fails from every browser)

[jech]

Log into a group, then open the Javascript console (Ctrl-k in Firefox), and evaluate the following:

serverConnection.rtcConfiguration;