Install jitsi-meet for a local network

I would like to install jitsi-meet on a LAN, to use it on a classroom. Why would I want to do this? Because of screen sharing. I would like to share my screen with the students. This is very useful for example when teaching programming (especially when there is no projector).
Another useful feature is the chat. I can send students url-s that they can open (served from local servers, for example from my computer).

I tried to install it on a VirtualBox machine (built and managed with vagrantup). I forwarded the ports 443, 4443 and 10000 to the virtual machine, I disabled HSTS on apache configuration, etc. However couldn’t make it work.

Is it possible to make it work locally? If yes, how?

Or if you think that using jitsi just for desktop sharing and local chat on a LAN is overkill, what would you suggest to use?

This can be done. No it is not an overkill, but mind that running it on a desktop station is not a good idea, as today most of the desktop stations use wifi, make sure it is wired. And make sure the AP for the wifi the students use is good enough. Cause 20-30 people joining from the same AP in a video conference can the AP can be easily blown. Yo are in case where there should not be much traffic it may be ok, but saying it cause I have seen this in a classroom :slight_smile:
By default VM run in NAT environment, had you set to jvb its internal and external address?

It works: https://gitlab.com/docker-scripts/jitsi
When it is installed on a VPS on the cloud, it needs the NAT fix that you mention, and it works fine (for example: https://meet.fs.al)

When I install it locally, I add something like this on /etc/hosts: “127.0.0.1 meet.example.org” and it does not even need the NAT fix. I can open https://meet.example.org on the browser and it works fine.

The problem is that when I try something like https://192.168.0.233/ or https://192.168.0.233:8443/ (where 8443 is forwarded to 443) it does not work. In a LAN it cannot be used with a fake name that I have added on /etc/hosts, it has to be accessed from the IP.

Is there some way to fix it?

There is a way to config it with nginx. You need to make sure your config.js generates bosh different address that depends on the link you used, I recently posted the config in another thread, need to find it.

You need

bosh: '//<!--# echo var="http_host" -->/<!--# echo var="subdir" default="" -->http-bind'

I am basically installing it with apt install jitsi-meet, as described here: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
This installs by default apache2.

In order to be able to make this fix I have to follow the manual installation as described here: https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

So, it turns out this is not just a small hack for me, after all.
Thanks anyway for your suggestion.

The quick install installs by default with jetty. If you are using apache2 it is because it is installed before installing jitsi-meet. I suppose same can be made with apache, maybe, not sure.

You are right. If it finds apache2 installed it configures apache2, if it finds nginx it configures nginx.
But I still don’t get how to fix the configuration of nginx so that it works both with a domain name (something like meet.example.org) and an IP (something like 192.168.0.10, or even 127.0.0.1).
I understand that this is not a jitsi-meet issue but rather an apache2/nginx configuration issue, however I still have to find out how to fix it.

Does it work just with a domain? If yes, then change your config.js replacing the bosh url with:

bosh: '//<!--# echo var="http_host" -->/<!--# echo var="subdir" default="" -->http-bind'

I still don’t understand what is the advantage to change domain name with ip-address, you cannot install a valid cert when using ip-address…

I works with a fake domain like meet.example.org, if I add to /etc/hosts a line like: 127.0.0.1 meet.example.org

The use case that I am thinking about is this:
I am in a room (or classroom) with a few other people, each of them having a laptop. I start a hotspot on my laptop (like this: https://gitlab.com/docker-scripts/desktop/blob/master/misc/hotspot.sh#L26) Then I start a jitsi-meet container on my laptop and invite the other to connect (probably with an IP like 10.42.0.1). Then I can use screen sharing of jitsi-meet to share my screen with the other people. We can all block audio and video since it is not needed in this case (we are all present on the same room).

Actually this is a corner case, not quite frequent or useful, since I want to do this because I don’t have a projector (otherwise I can share my desktop using the projector). So it is not such a big issue if it does not work.

Now that I think about it, since I am starting my own hotspot on my laptop and the other people are connecting to it, maybe I can start a dnsmasq service as well and let them resolve meet.example.org to the IP that I want (in this case 10.42.0.1), and this would make everything work.

So, it seems that this is not such a big issue after all, even if it is not solved.
Thanks for your help and support.

After the install itunes on windows 7 when I tried to connect the local network and access the internet connectivity it was not connecting to the internet at all.

While accessing streaming server in local network without internet, the second user stream is not getting to the first user and vice versa. Do any one encounter this issue?

I gave up installing it in a local network. I don’t remember exactly, but maybe this was one of the issues that I encountered.

1 Like

:disappointed:

Getting below error while accessing through LAN network

Are these the first errors you see?

1 Like

Yes. This should work without internet right? If the server is in LAN then how about below config params value? How to configure this which will work fine in LAN without internet connection.24%20PM

And I can see an external API call from my LAN which is continuously failing in LAN without internet,
22%20PM

You need to enable disableThirdPartyRequests https://github.com/jitsi/jitsi-meet/blob/master/config.js#L316

Hum … what is the browser you use, seems it is missing navigator.mediaDevices. Are you accessing it using https connection?

I’m already using that. My updated config looks like below,

Im using latest chrome and I’m using http connection instead of https because it’s in my local network. I have added two systems to my LAN. My server is running jitsi docker and my .env looks like below,

#
# Basic configuration options
#

# Directory where all configuration will be stored.
CONFIG=~/.jitsi-meet-cfg

# Exposed HTTP port.
HTTP_PORT=80

# Exposed HTTPS port.
HTTPS_PORT=8443

# System time zone.
TZ=Europe/Amsterdam

# IP address of the Docker host. See the "Running on a LAN environment" section
# in the README.
DOCKER_HOST_ADDRESS=192.168.0.100


#
# Let's Encrypt configuration
#

# Enable Let's Encrypt certificate generation.
#ENABLE_LETSENCRYPT=1

# Domain for which to generate the certificate.
#LETSENCRYPT_DOMAIN=meet.example.com

# E-Mail for receiving important account notifications (mandatory).
#LETSENCRYPT_EMAIL=alice@atlanta.net


#
# Basic Jigasi configuration options (needed for SIP gateway support)
#

# SIP URI for incoming / outgoing calls.
#JIGASI_SIP_URI=test@sip2sip.info

# Password for the specified SIP account as a clear text
#JIGASI_SIP_PASSWORD=passw0rd

# SIP server (use the SIP account domain if in doubt).
#JIGASI_SIP_SERVER=sip2sip.info

# SIP server port
#JIGASI_SIP_PORT=5060

# SIP server transport
#JIGASI_SIP_TRANSPORT=UDP

#
# Authentication configuration (see README for details)
#

# Enable authentication.
#ENABLE_AUTH=1

# Enable guest access.
#ENABLE_GUESTS=1

#
# Advanced configuration options (you generally don't need to change these)
#

# Internal XMPP domain.
XMPP_DOMAIN=meet.jitsi

# Internal XMPP domain for authenticated services.
XMPP_AUTH_DOMAIN=auth.meet.jitsi

# XMPP domain for the MUC.
XMPP_MUC_DOMAIN=muc.meet.jitsi

# XMPP domain for the internal MUC used for jibri, jigasi and jvb pools.
XMPP_INTERNAL_MUC_DOMAIN=internal-muc.meet.jitsi

# XMPP domain for unauthenticated users.
XMPP_GUEST_DOMAIN=guest.meet.jitsi

# Custom Prosody modules for XMPP_DOMAIN (comma separated)
XMPP_MODULES=

# Custom Prosody modules for MUC component (comma separated)
XMPP_MUC_MODULES=

# Custom Prosody modules for internal MUC component (comma separated)
XMPP_INTERNAL_MUC_MODULES=

# MUC for the JVB pool.
JVB_BREWERY_MUC=jvbbrewery

# XMPP user for JVB client connections.
JVB_AUTH_USER=jvb

# XMPP password for JVB client connections.
JVB_AUTH_PASSWORD=passw0rd

# STUN servers used to discover the server's public IP.
JVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302

# Media port for the Jitsi Videobridge
JVB_PORT=10000

# TCP Fallback for Jitsi Videobridge for when UDP isn't available
JVB_TCP_HARVESTER_DISABLED=true
JVB_TCP_PORT=4443

# A comma separated list of APIs to enable when the JVB is started. The default is none.
# See https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest.md for more information
#JVB_ENABLE_APIS=rest,colibri

# XMPP component password for Jicofo.
JICOFO_COMPONENT_SECRET=s3cr37

# XMPP user for Jicofo client connections. NOTE: this option doesn't currently work due to a bug.
JICOFO_AUTH_USER=focus

# XMPP password for Jicofo client connections.
JICOFO_AUTH_PASSWORD=passw0rd

# XMPP user for Jigasi MUC client connections.
JIGASI_XMPP_USER=jigasi

# XMPP password for Jigasi MUC client connections.
JIGASI_XMPP_PASSWORD=passw0rd

# MUC name for the Jigasi pool.
JIGASI_BREWERY_MUC=jigasibrewery

# Minimum port for media used by Jigasi.
JIGASI_PORT_MIN=20000

# Maximum port for media used by Jigasi.
JIGASI_PORT_MAX=20050

# Disable HTTPS. This can be useful if TLS connections are going to be handled outside of this setup.
# DISABLE_HTTPS=1

# Redirects HTTP traffic to HTTPS. Only works with the standard HTTPS port (443).
#ENABLE_HTTP_REDIRECT=1

I have tried by uncommenting DISABLE_HTTPS=1 flag but the result is same. Do I missing anything in this .env file.?

No idea about the docker setup, but disableThirdPartyRequests is a config property and you need to pass it in configOverride…

You need to make sure you access the deployment using https from your browser, and what is the browser and version you use to test?

1 Like