Jitsi behind DynDNS: Keeping the WAN IP current?

Docker-Jitsi-Meet runs quite nicely on a Synology DS218+. However we’re behind a DynDNS-Setup which is changing our external WAN IP address every day. What is a good configuration to let Jitsi know of a changed WAN IP address?

Currently we’ve solved it as follows:
.env: DOCKER_HOST_ADDRESS=meet.domain.tld (this seems to work stable)
JVB_STUN_SERVERS= (just leaving the list empty)
JVB_TCP_HARVESTER_DISABLED=false (with port UDP/10000 open)
docker-compose down / up -d every morning (usually the IP changes at night).

We’ve studied the various notes and hints regarding STUN/TURN, but could not figure out from the documentation what’s really the current best setup recommendation for a NAS behind DynDNS. (Additionally obviously, the docker setup complicates modifications that go beyond the capabilities of the .env file.)

As a side note: Like others here in the forum, we’re also seeing individual clients permanently unable to join (no clear pattern; meet.jit.si works for them). They constantly experience what everybody else experiences only when Jitsi’s WAN IP is outdated: only users on the LAN can see and hear each other; all others see all sessions, but no streaming content. We suppose this issue is related to the underlying issue here – NAT traversal — hence we mention it here.

If you keep the meeting room web page open while the WAN IP has changed, they will have to reload the page to re-enter the room.

I wish it was like you suggestion. But unfortunately, when the server gets a new IP address, no user can see other users’ streams anymore. All they see is empty sessions (and themselves), even when they reload the page or come as new users, like in this iPhone screenshot

. Only when the server restarts, they see each other again, even without reloading the page in the browser.

So it must be something about IP discovery, not?

If you look at /etc/turnserver.conf, you can see that there is a specific reference to the <Public_IP> of the server.
That has been detected and reported here during installation.

I’d like to understand if there is a way to “link” it at a global variable to be udated automatically (ie.asking at checkip.dyndns.com).

Yes, it would be great to have the public IP determined and tested for changes. AFAIK that’s in part what STUN/TURN is providing normally, isn’t it? I wonder if they check regularly for IP changes, or just once during start-up?

/etc/turnserver.conf is an interesting suggestion. We’re using the docker installation and can’t find this file in any of its four containers. Generally, might it be that Docker-Jitsi-Meet doesn’t have STUN/TURN running?

Sorry, on docker I can’t help you.

Have you already seen that thread: Jitsi-Meet with NAT, port-mapping and dynamic IP. Here xentity has suggested a simple script to update NAT_HARVESTER_PUBLIC_ADDRESS on


Unfortunately I can’t use it because actually … my server (behind NAT) is working without needing:


(I wonder why …)

1 Like

“Last chance” for solving the loose of audio & video with external partecipants when Jitsi Public-IP is renewed.

As supposed before, we should act on the Jitsi external-IP recorded in /etc/turnserver.conf.
The easiest way I’ve found to update it every time it changes (while using a DynDNS service) should be delegated to a DDNS client such as ddClient or inadyn.

Once configured, that client updates the DDNS with the new IP.
More over, they both should be able to execute a script (once the DDNS has been updated).

For our purpose I’ve modified a script suggested from xentity :



# get the actual IP from the Internet
IPint=$(host -tA $DNSNAME | grep address | cut -d " " -f4 )

# get the configured IP of Jitsi
IPjitsi=$(grep 'external-ip' /etc/turnserver.conf |  grep -oE "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+")

#remove echo after debug
if [ "$IPjitsi" == "$IPint" ]
        echo "IP has not been changed!"
        exit 0
        echo "... actual IP: $IPjitsi"
        echo "... NEW IP: $IPint"

#clear config
sed -i '/external-ip/d' /etc/turnserver.conf

#get IP and renew line
echo external-ip =$IPint >>  /etc/turnserver.conf

sudo service jicofo restart
sudo service jitsi-videobridge2 restart

MANUALLY executing the script … the problem is solved (for me), but I can’t help you some more.

‘cause I’m in trouble with ddClient (got from universe repo):
For some mistake, I’m not able to have it executing any script adding the related parameter.


And I’m in trouble with inadyn too.
This one esplicitally is able to execute a script … but I’m not able to correctly customize the –system parameter for having it working with my DDNS provider.

Maybe we’re near to solve the issue.

Hope somebody could help us on the "last step” …

Thank you for sharing your approach, BlueWheels75. While your situation seems different from ours, it’s interesting to follow. Here’s how we’ve solved this for now, combining a DDNS script with the restart of docker-compose that’s apparently necessary to update docker-jitsi with the new WAN address:

  • our script restart_jitsi.sh is executed when DSM boots up
  • the script essentially loops, polling the WAN IP from our router’s API every 150sec
  • when the WAN IP changes, the script
    1. updates the external DDNS service, using the service’s API call (we use DuckDNS)
    2. captures some statistics: docker logs docker-jitsi-meet_jicofo_1 2>&1 …
    3. shuts down Jitsi: docker-compose down && <some logging…>
    4. rebuilds Jitsi: docker-compose up -d && <some logging…>
    5. applies a few changes to files like /web/interface_config.js inside Jitsi’s containers

So having completed this, we realize that a more elegant solution than polling the router’s API would be a ‘push’ approach from the router to the server, i.e.

  • directing the router’s built-in DDNS feature to our script on our Synology server,
  • passing the external IPv4 and IPv6 WAN address to our script, and
  • performing all the steps above (including the actual API call to the external DDNS service)

This approach would call our script just once every time the router receives a new WAN IP. But our current solution is good enough for us, so we leave this little exercise to the interested reader :slight_smile:

And obviously, a solution that would update Jitsi in Docker with the a WAN IP address without requiring a docker-compose down/up cycle would be more than welcome, e.g. via STUN.

Quick update: We once again had an instance that external clients could not see nor hear each other once a third participant joined the conference. The best explanation we can find is that, unlike regular jitsi, jitsi-docker-meet seems to come without a STUN server of its own.

So to be on the safe side, we’ve enhanced our script restart_jitsi.sh in a way that it, between step 4 and 5 above, inserts two lines to /etc/jitsi/videobridge/sip-communicator.properties in the JVB container, and then restarts JVB and JICOFO:

docker exec docker-jitsi-meet_jvb_1 sed -i '1s;^;org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS='${WAN_IP}'\n;' /etc/jitsi/videobridge/sip-communicator.properties
docker exec docker-jitsi-meet_jvb_1 sed -i '1s;^;org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS='${LAN_IP}'\n;' /etc/jitsi/videobridge/sip-communicator.properties
docker restart docker-jitsi-meet_jvb_1
docker restart docker-jitsi-meet_jicofo_1

This seems to work now.

Hi I wrote a python script for that problem.

you can download it here so you can try it.

It looks for a changed ip and if needed changes the ip in the `sip-communicator.properties.




Hi @sbeechs and @mmo. Thanks for sharing your aproaches, they are interesting. I’ll try both.

For the pleasure of sombody else, I’ve finalized my procedure on this post: No Voice & Video behind NAT (DynDNS) - SOLVED

CU soon