I can reproduce the error with the following rules:

Flush tables

iptables -F
iptables -X

Default TCP allow established

iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

Default allow DNS (udp)

iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

Block udp input

iptables -A INPUT -p udp -j DROP

Default global policy

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Run all those in order and try using Firefox.

from edumeet.

You can make it work again by blocking all OUTPUT UDP:

Block udp output

iptables -A OUTPUT -p udp -j DROP

from edumeet.

This is most likely a bug in mediasoup and a big problem because Firefox users can't connect to room if they are behind a udp-blocking firewall.
Edit: As there is mentioned on https://groups.google.com/forum/#!topic/mediasoup/5x6D37p53Pc
there is a bug in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1034964 wich most likely is the problem here.

from edumeet.

I will try to check it..

from edumeet.

What happens if you disable in firefox config the ICE tcp
so set in about:config the media.peerconnection.ice.tcp to false?
Does it solve it?

from edumeet.

Check it with https://eper.lab.vvc.niif.hu it seems ok and runs correctly without udp with ice.tcp enabled, but use relayed TCP

from edumeet.

from edumeet.

Strange. :-/

What I have tested and what works for me is the following:
I have two FF tab connected to the same room, and I modeled the udp blocked network with -j DROP in INPUT and OUTPUT chain to and from the SFU (eper..).

So what could be the difference in your case?

Longer delay because of the distance?

I am wondering how should I model better way the UDP drooping firewall?
e.g. Does it send ICMP reject instead of DROP?

from edumeet.

Fixed in new client/server

from edumeet.