Address discovery through STUN failed / Jitsi doesn't work on subdomain

Install & Config Docker
#1

Hi,

first of all thanks to the Jitsi developers and the community for working on Jitsi! It’s an amazing piece of software. I am running the official docker image and after a few hiccups in the beginning I now have a seemingly working Jitsi server, great!

However theres two issues:

The jvb containers log contains a whole lot of stack traces about “Address discovery through STUN failed”. I can connect to my server and conferences work properly, also with multiple participants. So I am wondering if this is a non-issue and I can ignore it? I did notice that I have to specify the DOCKER_HOST_ADDRESS with my servers public IP for JVB to work, so maybe thats where the STUN request fails? When the server tries to find its own address?

Another issue I have is that I can’t make Jitsi work on a subdomain like “meet.mydomain.com”, it only works on the master domain “mydomain.com”. I am running the docker image without SSL, it’s connected to the internet though a nginx proxy on the docker host handling the SSL/TLS connection. I configure that connection through Plesk 18, which is installed on my server. When I try to install jitsi-meet on a subdomain (technically theres no difference with the setup on my side except the domain name) it fails to load properly and keeps restarting.

Edit: I should mention that I enabled ipv6 in the config.js, otherwise nothing was really changed in the docker image default settings (apart from app name etc), I delete all config files on update and just sed -i replace the relevant stuff.

Maybe somebody can enlighten me :slight_smile:

Thanks for the attention,
Normen

Edit2:
This seems to be the first stack trace about STUN:

INFO: Joined MUC: jvbbrewery@internal-muc.meet.jitsi
Apr 10, 2020 3:00:39 AM org.ice4j.ice.harvest.StunMappingCandidateHarvester discover
INFO: We failed to obtain addresses for the following reason: 
java.lang.IllegalArgumentException: unresolved address
	at java.net.DatagramPacket.setSocketAddress(DatagramPacket.java:316)
	at java.net.DatagramPacket.<init>(DatagramPacket.java:144)
	at org.ice4j.stack.Connector.sendMessage(Connector.java:325)
	at org.ice4j.stack.NetAccessManager.sendMessage(NetAccessManager.java:654)
	at org.ice4j.stack.NetAccessManager.sendMessage(NetAccessManager.java:600)
	at org.ice4j.stack.StunClientTransaction.sendRequest0(StunClientTransaction.java:266)
	at org.ice4j.stack.StunClientTransaction.sendRequest(StunClientTransaction.java:244)
	at org.ice4j.stack.StunStack.sendRequest(StunStack.java:681)
	at org.ice4j.stack.StunStack.sendRequest(StunStack.java:619)
	at org.ice4j.stack.StunStack.sendRequest(StunStack.java:586).
#2

Digging around a bit more the solution for issue #1 seems to be to comment out the JVB_STUN_SERVERS parameter in the .env file. Apparently if STUN doesn’t work and you’re using a fixed IP for your server you’re supposed to disable STUN.

My question would be why it doesn’t work in the first place and why I can’t use my ipv6 address then…

#3

Hi @Normen_Hansen,
sorry for that silly question - but where can I find this env file? Is that something relevant to docker? (I’m not using docker here)
Thanks for enlightment,
HP.

1 Like
#4

Yeah it is. But effectively this is just a log of a past failed attempt with no consequences so you can just ignore it. Note it’s logged on the INFO log level so you can just set your logger to log only WARNING level stuff, then it’s gone.

…or somehow disable the use of STUN in jvb directly - I have no idea on how to do that though as I’m using the docker images.

#5

Sorry, I’m not sure about that, my /var/log/jitsi/jvb.log says:

2020-04-17 15:43:06.791 SEVERE: [29] Health.doRun#300: Health check failed in 0ms:
java.lang.Exception: Address discovery through STUN failed (...)

and this every 10 seconds - poor log space…

1 Like
#6

Right, the 10-second interval is happening without the stun server error as well though, in that case it’s INFO level. It is the reporting of a past failed event.

#7

I’m also flooded by “Address discovery through STUN failed” in jitsi-videobridge2 (2.1-203-g83195fcd-1 ).

Perhaps passing an empty list of STUN servers to the jvb would stop it?

$ ack -i STUN /etc/jitsi/
...
/etc/jitsi/videobridge/sip-communicator.properties
2:org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:44

Will test later, now I prefer to avoid maintenance as the server is actively used.