It is not an option to open up other UDP ports with port forwards set up to the Jitsi VM, clients should only use 10000/udp. Running with a user different from root but added to the docker group to be able to run commands without sudo. The Jitsi docker images was built from the up-to-date dev branch locally using make yesterday, then an unmodified docker compose file was used to put them online. And so the dropped packets are causing the connection problems, as there are no video and audio received on either end. Ports seems to be chosen randomly between two connection attempts but stay the same for a session. When we tried to debug the issue, the firewall live log showed that packets from and to port 10000/udp are accepted at first (an in-out pair) but there are many packets that are being dropped on several other udp ports in the range of 1400-65000 as observed over some connection trials after the two successful packets. When one or both participants go to an external network (e.g., mobile internet for mobile client, or mobile hotspot for a laptop), both can join the meeting but as soon as there are the two of them in the same room, video and audio are not available for both parties, the connection issues message is displayed and only the chat works. When both participants are on the same LAN env, video conferencing with all the bells and whistles are working fine from laptop to laptop, laptop to mobile and mobile to mobile. Port 443 at the reverse proxy is mapped to Docker host env variable is set to the Jitsi VM's LAN IP address. The Ubuntu VM hosting the Jitsi docker has ufw enabled with 8443/tcp and 10000/udp ports open. We have a Jitsi dockerized instance running behind NAT, and ports 443/tcp (through an nginx reverse proxy with LE SSL certs) and 10000/udp (forwarded directly to the Jitsi VM in Proxmox) are open on the external firewall.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |