why NAT_HARVESTER_PUBLIC_ADDRESS is needed?

[roeycohen]

why do we need to configure NAT_HARVESTER_PUBLIC_ADDRESS (using DOCKER_HOST_ADDRESS) behind NAT, if the org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES is already configured (using JVB_STUN_SERVERS) with "stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302"?

shouldn't the stun servers already discover the real address of JVB?

I'm asking because I'd like to create to JVB machines using autoscaling where I wouldn't know the IP address before the instance is turned on...

[fidergo-stephane-gourichon]

I'm confused, too.

Reading https://github.com/jitsi/docker-jitsi-meet

If running in a LAN environment (as well as on the public Internet, via NAT) is a requirement, the DOCKER_HOST_ADDRESS should be set.

Set to what?

I have read #137 and #171 and it's still totally unclear. I know about NAT traversal and read about ICE and STUN although I do not practice them daily.

My setup

internet -> 1.2.3.4 NAT BOX 192.168.123.1 -> 192.168.123.45 server[ docker[x.y.z.t jitsi container] ]

So, what address should I set there?

• x.y.z.t ? docker-specific IP address? Probably not.
• 192.168.123.45 ? The address on the local LAN of the machine containing the docker container? Perhaps, I don't know.
• 1.2.3.4 ? The public-facing address of the NAT bridge? Probably not, given that the address provided as example in the config file is DOCKER_HOST_ADDRESS=192.168.1.1 is not a publicly routable address.

Questions

Things are running with it unset and it appears to work. What happens if it is ill-configured?

I'm afraid changing it will just break my experimental setup. I changed it to the second option above, it didn't break anything.

Additional information

From what I understand it probably changes things only in the case of two participants that happen to be on the same local network (inside the NAT), by allowing to avoid the server relaying all the bandwidth. But I might be wrong.

Also, the NAT I happen to use is a "smart" one in the sense that every machine inside the NAT can access all resources that are available from outside (including the ones routed by the NAT to the inside), it just works. Some NAT are dumb: when inside the NAT you can access fully external resources but not resources that would re-enter the NAT. Not sure I'm clear, but this might cause some things to just work here in spite of misconfiguration.

Anyway, please @saghul if you could explain and provide examples it would be great.

[saghul]

One case in which you absolutely need it is if you want a LAN only deployment, since the JVB container is unaware of the Docker host address and won’t find it using STUN.

[fidergo-stephane-gourichon]

Thanks for this partial explanation. In the other cases, what happens if it is ill-configured? What value should be put in?

[saghul]

It should contain the IP address you want the JVB to put on the SDP for ICE candidatees. This is the IP that will be used for relaying media, so it must be visible to all participants who may join.

A misconfigured value would yield to conferenes without video because ICE would fail.

[roeycohen]

made a test, indeed removing this value in AWS causes ICE to fail so no video/audio is shared. but I don't understand why...

@saghul how do you handle auto-scaling in https://meet.jit.si? also, how do you handle servers removal? are you using rest API in JVB, or something else?

[saghul]

We do have an AWS harvester which should be enabled by default. Can you try this? https://github.com/jitsi/ice4j/blob/master/doc/configuration.md#orgice4jiceharvestforce_aws_harvester Also, did you set STUN servers?

[roeycohen]

@saghul not sure to which container ice4j is relevant, by i'll try to take some time to learn.

I don't use STUN server, for now I was able to make jitsi listen on port 80, so it works for most of the firewalls I've encountered :)

[saghul]

not sure to which container ice4j is relevant, by i'll try to take some time to learn.

Sorry, my bad, those options apply to the JVB.

I don't use STUN server, for now I was able to make jitsi listen on port 80, so it works for most of the firewalls I've encountered :)

Nice!

[jendakol]

Hi @saghul, first: thank you for your great job! I'm just still a little bit confused about this topic.

Doc says:

If running in a LAN environment (as well as on the public Internet, via NAT) is a
requirement, the DOCKER_HOST_ADDRESS should be set.
...
The public IP address is discovered via STUN. STUN servers can be specified
with the JVB_STUN_SERVERS option.

So I should or should NOT set it when behind NAT? What I've understood is that the app will discover by public IP automagically and logs of my instance are confirming this:

jvb_1      | JVB 2020-04-01 19:09:29.760 INFO: [26] org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover() Discovered public address 217.***.***.78:60598/udp from STUN server 52.28.143.184:443/udp using local address 172.21.0.5:0/udp
jvb_1      | JVB 2020-04-01 19:09:29.760 INFO: [21] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize() Using org.ice4j.ice.harvest.StunMappingCandidateHarvester, face=/172.21.0.5, mask=/217.***.***.78
jvb_1      | JVB 2020-04-01 19:09:29.760 INFO: [21] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize() Initialized mapping harvesters (delay=570ms).  stunDiscoveryFailed=false

However, I'm still facing the "two clients and no more" problem.

I'm forwarding 80/tcp, 4443/tcp and 10000/udp ports to the image (set on router, etc.) and do SSL termination on nginx.

Thanks for explaining!

[saghul]

@jendakol Hi, and sorry for the troiuble you're having. The option is ill named and not clearly explained. I plan on addressing that once we cacn ship the next stable release.

In the general case, things should Just Work (TM), that is: the JVB will discover its own IP and advertise it as an ICE candidate.

The problem is that on some networks you might not be able to route traffic to your own public IP from behind the NAT. In that case setting DOCKER_HOST_ADDRESS helpss, because the JVB will know about both and advertisse both, thus one will suceed.

Another case is that on a LAN-only (no Internet at all) setup. In that case STUN discovery for the JVB must be disabled because otherwise the JVB won't start as it thinks it's "unhealthy". In this case you do need to set DOCKER_HOST_ADDRESS.

[jendakol]

So, if I understand correctly, in my setup (and according to logs I've provided), it should just work, ok? Interesting... I'll try once again, I guess.
Thanks.

[fidergo-stephane-gourichon]

It looks like this commit 52a1449282d21e4869e921d3de44796848a81972 adds to README.md some answer to the questions I asked here. I let the original issue reporter @roeycohen tell if his questions get a satisfying answer.

[roeycohen]

@fidergo-stephane-gourichon it's clearer now. Sorry, i still didn't get the chance to try the AWS harvester...

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.