Docker-jitsi-meet: Changing the default JVB_PORT results in "failure to bind" errors

[TheNetStriker]

I've changed the default JVB_PORT to 10005 because the port 10000 was already used by Webmin on my server. When I checked the logs of the jvb container I found that every 5 seconds "Retrying a bind because of a failure to bind to address" errors where logged for the ports 10006, 10007, 10008, 10009 and 10010. After that I changed the Webmin port to 11000 and tested with the default jvb port 10000 the errors were gone.

What are those additional ports for and is there a way to use other ports than the default port 10000?

[saghul]

If your system using 10000-10010 for anything? Does it work if you set it to say 20000? I don't see any place with 10000 hardcoded around here...

[TheNetStriker]

On the docker host only the port 10001 is currently used by the Ubiquiti Unify server. (This port cannot be changed) I just tried setting the port to 20000, but I still get the same errors:

JVB 2020-03-24 17:29:18.407 INFO: [28] org.ice4j.ice.harvest.SinglePortUdpHarvester.<init>() Initialized SinglePortUdpHarvester with address 172.20.0.6:20000/udp
JVB 2020-03-24 17:29:18.410 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10001 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.410 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10002 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.411 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10003 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.411 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10004 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.413 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10002 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.413 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10003 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.413 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10004 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.413 INFO: [28] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /172.20.0.6 and port 10005 (Address already in use (Bind failed))
JVB 2020-03-24 17:29:18.456 INFO: [28] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 1502ms. Sticky failure: false

Here to compare are the logs when I set the port to 10000:

JVB 2020-03-24 17:30:46.075 INFO: [28] org.ice4j.ice.harvest.AbstractUdpListener.<init>() Initialized AbstractUdpListener with address 172.20.0.6:10000/udp. Receive buffer size 212992 (asked for 10485760)
JVB 2020-03-24 17:30:46.076 INFO: [28] org.ice4j.ice.harvest.SinglePortUdpHarvester.<init>() Initialized SinglePortUdpHarvester with address 172.20.0.6:10000/udp
JVB 2020-03-24 17:30:46.144 INFO: [28] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 1518ms. Sticky failure: false

I also tried to start the container with port 20000 with the Unify service stopped, but I still get those errors. I also checked before the start that the ports from 10000 to 10010 are not in use using netstat. Any ideas what the container is trying to do here?

[saghul]

@bgrozev Do you know why those extra ports might be used?

[kawaii]

I am having a similar problem. We set our JVB_PORT to 10070 and yet the logs are full of similar entries like this:

org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /192.168.0.5 and port 10071 (Address already in use (Bind failed))
org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /192.168.0.5 and port 10072 (Address already in use (Bind failed))
org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /192.168.0.5 and port 10073 (Address already in use (Bind failed))
org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() Retrying a bind because of a failure to bind to address /192.168.0.5 and port 10074 (Address already in use (Bind failed))

Are we supposed to be exposing a _range_ of UDP ports for use by the videobridge as opposed to the single port we set in the configuration?

[bgrozev]

Ahh, these must be health checks resulting in ports in the 10001-20000 range being tried. They should be harmless unless the health check actually fails. I'll add it to my list to take a look and see if we can fix it.

[bgrozev]

@TheNetStriker Which version of jitsi-videobridge are you using? I can not see a way for this to happen on master (2.1)

[TheNetStriker]

@bgrozev Thanks for the hint. I just installed the latest images and now I can use the videobridge on port 10005 without those warnings. This must have been fixed very recently because I installed the videobridge last week.

[cjk]

@TheNetStriker That sounds promising - and indeed the docker-image of the bridge was updated just one day ago.
Did you have do change any configuration to make it use port 10005 or was it used automatically?

[TheNetStriker]

@cjk I just changed the port in the .env file and the errors were gone.

[cjk]

@TheNetStriker Thanks for the hint!

[TheNetStriker]

@cjk I just checked the logs of the jvb container again, and the port warnings are back when I use port 10005 with the latest container version. Maybe I did not wait long enough when I checked the logs last time. So the problem does not seem to be fixed with the new version.

[cjk]

@TheNetStriker It's actually working for me now, after force-upgrading to the latest Jitsi-Docker codebase. Note that just upgrading the docker-images wasn't enough for me, I had to checkout the latest source, then instead of docker-compose up -d I used make clean and make to update and re-build everything from source.
After that, Jitsi worked flawlessly on all the default-ports and the connection-problems were gone - see also #307

[saghul]

Latest master is ready for the upgrade, we'll publish new images very soon.