Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

alt

Daniel Nashed

Sametime Meetings Premium internally without Google STUN servers

Daniel Nashed – 23 December 2020 19:52:51


We ran into this today. A customer is using ST Meetings Premium in their intranet and have no connection outside.

This isn't only a challenge for software installation and updates, but also causes issues with ST meetings if the Google STUN servers cannot be reached.


Side note: The update from Pre-Release to Premium by the way just took 1 hour for the meeting server, community server and proxy server all togehter!

A STUN server is actually a TURN server, taking care that server and client can talk to each other if a NAT environment is involved.

This can hit you even in an intranet depending on the network segmentation with IPv4 addressing.


In case NAT is involved you would need an internal TURN server. If no NAT is involved you still have to disable the Google STUN servers.


Disable STUN Servers in intranet without NAT


To disable the STUN servers you have to modify the hidden internal configuration file .env.  (the file has a leading dot which makes it hidden on Linux).
The line to disable looks like this by default:


JVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302


In addtion you have to set to set the DOCKER_HOST_ADDRESS to the exposed, accessible IP address in your  custom.env file.

This should be the primary interface of your Docker host!


# IP address of the Docker host. Check LAN configuration of the system. If the host has multiple interfaces,

# choose the one which is considered the routable IP for the host.

DOCKER_HOST_ADDRESS=192.168.96.15



After you made the change, you have to restart your environment.

The easiest way is to use  "
docker-compose down" and "docker-compose up -d".

In one case my containers have not been removed cleanly and I had to use a "
docker-compose rm".

Tip:
To ensure the changes are applied you should remove the jitsi-config folder before your bring up the server again.


Side note: This will overwrite your private key and certificate for the web-server usually you have replaced it with your own key and you have to copy it again.
In case the server created a self signed, you are getting a new one and all users get a security warning.

You should always deploy a real certificate! And keep a copy outside the directory to copy it back again.
The keys are located in jitsi-config/jibri_web/keys and they are called cert.crt and cert.key


Test if you can access the Google STUN servers


There is a client you can install to check the connection.


Here is an example how to install and test.
You can use the same test on your own TURN server later.


yum install -y epel-release
yum install -y coturn-utils


turnutils_uclient -v -p 19302 stun.l.google.com




Installing your own TURN server


In case you have NAT connections internally you can install your own TURN server.

If running on CentOS or RHEL this is very easy.  The most used TURN server project is
https://github.com/coturn/coturn
I have installed the server locally without any modification.


Installation


yum install coturn


Enable and start systemd service


systemctl enable coturn

systemctl start coturn


The configuration is located here -->
/etc/coturn/turnserver.conf

The default used port 3478 and 3479 and you have to open those ports in your firewall for TCP and UDP!!! (can be OS firewall and/or corporate internal firewalls)


Afterwards you can change your STUN server configuration in .env like this and start the ST meeting server again:


JVB_STUN_SERVERS=192.168.96.213:3478



Reference for the general info an topology configurations.
https://help.hcltechsw.com/sametime/11.5/admin/topology.html

Conclusion


A NAT environment can also be an intranet environment. It doesn't need to be an outside connection.

So you either disable the STUN server as described if no NAT is involved or install your own TURN server.


Thanks to the HCL Sametime Support team to quickly help us to figure out what was going wrong!!
Most of it is documented but not exactly with this background and in one place.


-- Daniel

Links

    Archives


    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]