I’ve been checking two scenarios with my jitsi-installation (coturn [that has been delivered automatically with Jitsi meet] configured and running) @ debian10:
The server does not serve port 10000 (via UDP) to the outside world at all. One participant is a desktop computer (win 10 pro, outgoing traffic is not limited, using current opera browser to create a session), the others are an ios phone [1 year old] and an android tablet [1 year old]. All of them connected to the same private (natted) home network.
The server offers ports 80 (tcp), 443 (tcp) and 10000 (udp) to the outside world. One participant is a desktop computer (win 10 pro, outgoing traffic destined for port 10000 [udp] is blocked, using current opera browser to create a session), the others are an ios phone [1 year old] and an android tablet [1 year old]. All of them connected to the same private (natted) home network.
The results in both scenarios are nearly the same. I can open up a conference via the desktop computer. The next client connects to the conference successfully. Always. Whenever I try to add the remaining client, the conference goes “black” for some participants.
In scenario 2 the desktop computer can’t see, speak to or hear anyone. The handheld devices work properly. In scenario 1 everyone is able to perceive the others being joined, but everything is “dark” (no audio, no video) for everyone.
It’s quite interesting to see, that whenever I switch back to p2p (canceling participation for any single device) the conference comes back to life (both being able to see, speak and listen to each other) - independent of the given scenarios.
Thus, it seems like p2p works like a charm whenever port restrictions come into play. But as soon as the conference gets bigger, troubles come up. The jicofo log is then spitting messages like …
… ConnectivityCheckClient$PaceMaker.run#919: Pair failed: publicserverip:10000/udp/host -> privateclientip:43868/udp/host
… ConnectivityCheckClient.processSuccessResponse#627: Pair succeeded: publicserverip:10000/udp/host -> publicclientip:43868/udp/prflx (stream-8e530142.RTP).
The 2nd message confuses me. Is my very own network setup at home responsible?
Much thx for reading!
P.S. Whenever I turn off the server’s firewall completely, the problem sustains.