Since the corona virus is forcing many of us into home office there is a high demand for video conference solutions. A popular free and open source tool for creating video conferences similar to Google’s hangouts is Jitsi Meet. It enables you to create a conference room from within your browser for which you can then share a link to your coworkers. No client software is needed at all (except mobile devices).
The installation of Jitsi Meet is super straight forward – if you have a dedicated server sitting around. Simply add the jitsi repository to your package manager and (in case of debian based systems) type
sudo apt-get install jitsi-meet
The installer will guide you through most of the process (setting up nginx / apache, installing dependencies, even do the letsencrypt setup) and in the end you can start video calling! The quick start guide does a better job explaining this than I do.
Jitsi Meet is a suite of different components that all play together (see Jitsi Meet manual). Part of the mix is a prosody XMPP server that is used for signalling. That means if you want to have the simple easy setup experience, your server must not already run another XMPP server. Otherwise you’ll have to do some manual configuration ahead of you.
I did that.
Since I already run a personal ejabberd XMPP server and don’t have any virtualization tools at hands, I wanted to make jitsi-meet use ejabberd instead of prosody. In the end both should be equally suited for the job.
Looking at the prosody configuration file that comes with Jitsi’s bundled prosody we can see that Jitsi Meet requires the XMPP server to serve two different virtual hosts.
The file is located under /etc/prosody/conf.d/meet.example.org.cfg.lua
VirtualHost "meet.example.org"
authentication = "anonymous"
ssl = {
...
}
modules_enabled = {
"bosh";
"pubsub";
"ping";
}
c2s_require_encryption = false
Component "conference.meet.example.org" "muc"
storage = "memory"
admins = { "focus@auth.meet.example.org" }
Component "jitsi-videobridge.meet.example.org"
component_secret = "<VIDEOBRIDGE_COMPONENT_SECRET>"
VirtualHost "auth.meet.example.org"
ssl = {
...
}
authentication = "internal_plain"
Component "focus.meet.example.org"
component_secret = "<JICOFO_COMPONENT_SECRET>"
There are also some external components that need to be configured. This is where Jitsi Meet plugs into the XMPP server.
In my case I don’t want to server 3 virtual hosts with my ejabberd, so I decided to replace auth.meet.jabberhead.tk with my already existing main domain jabberhead.tk which already uses internal authentication. So all I had to do is to add the virtual host meet.jabberhead.tk to my ejabberd.yml.
The ejabberd config file is located under /etc/ejabberd/ejabberd.yml
or /opt/ejabberd/conf/ejabberd.yml
depending on your ejabberd distribution.
hosts:
## serves as main host, as well as auth.meet.jabberhead.tk for focus user
- "jabberhead.tk"
## serves as anonymous authentication host for meet.jabberhead.tk
- "meet.jabberhead.tk"
The syntax for external components is quite different for ejabberd than it is for prosody, so it took me some time to get it working.
listen:
-
port: 5280
ip: "::"
module: ejabberd_http
request_handlers:
"/http-bind": mod_bosh
tls: true
protocol_options: 'TLS_OPTIONS'
-
port: 5347
module: ejabberd_service
hosts:
"focus.meet.jabberhead.tk":
password: "<JICOFO_COMPONENT_SECRET>"
The configuration of the modules was a bit trickier on ejabberd, as the ejabberd config syntax seems to disallow duplicate entries. I ended up moving everything from the existing main modules:
block into a separate host_config:
for my existing domain. That way I could separate the configuration of my main domain from the config of the meet subdomain.
Update: I migrated my server (and this tutorial) to the new videobridge2 component. This means that we no longer need to configure the videobridge as an XMPP component in ejabberd’s configuration.
host_config:
## Already existing vhost.
jabberhead.tk:
s2s_access: s2s
## former main modules block, now further indented
modules:
mod_adhoc: {}
mod_admin_extra: {}
...
## ADD THIS: New meeting host with anonymous authentication and no s2s
meet.jabberhead.tk:
## Disable s2s to prevent spam
s2s_access: none
auth_method: anonymous
allow_multiple_connections: true
anonymous_protocol: both
modules:
mod_bosh: {}
mod_disco: {}
mod_muc:
access: all
access_create: local
access_persistent: local
access_admin: admin
mod_muc_admin: {}
mod_ping: {}
mod_pubsub:
access_createnode: local
As you can see I only enabled required modules for the meet.jabberhead.tk service and even disabled s2s to prevent the anonymous Jitsi Meet users from contacting users on other servers.
Last but not least we have to add the focus user as an admin and also generate (not discussed here) and add certificates for the meet.jabberhead
.tk subdomain. This step is not necessary if the meet domain is already covered by the certificate in use.
certfiles:
- ...
- "/etc/ssl/meet.jabberhead.tk/cert.pem"
- "/etc/ssl/meet.jabberhead.tk/fullchain.pem"
- "/etc/ssl/meet.jabberhead.tk/privkey.pem"
...
acl:
admin:
user:
- "focus@jabberhead.tk"
...
That’s it for the ejabberd configuration. Now we have to configure the other Jitsi Meet components. Lets start with jicofo, the Jitsi Conference Focus component.
My /etc/jitsi/jicofo/config
file looks as follows.
JICOFO_HOST=localhost
JICOFO_HOSTNAME=meet.jabberhead.tk
JICOFO_SECRET=<JICOFO_COMPONENT_SECRET>
JICOFO_PORT=5347
JICOFO_AUTH_DOMAIN=jabberhead.tk
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=<FOCUS_USER_SECRET>
JICOFO_OPTS=""
# Below can be left as is.
JAVA_SYS_PROPS=...
Respectively the videobridge configuration (/etc/jitsi/videobridge/config
) looks like follows.
JVB_SECRET=<VIDEOBRIDGE_COMPONENT_SECRET>
## Leave below as originally was
JAVA_SYS_PROPS=...
Note that since the update to videobridge2, most config options have become obsolete and were replaced by options in the sip-communicator.properties file. So lets change /etc/jitsi/videobridge/sip-communicator.properties
:
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=jabberhead.tk
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=<JVB_USER_SECRET>
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@conference.meet.jabberhead.tk
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=<some UUID, just leave the original value>
Now we can wire it all together by modifying the Jitsi Meet config file found under /etc/jitsi/meet/meet.example.org-config.js
:
var config = {
hosts: {
domain: 'meet.jabberhead.tk',
anonymousdomain: 'meet.jabberhead.tk',
authdomain: 'jabberhead.tk',
focus: 'focus.meet.jabberhead.tk',
muc: 'conference.meet.jabberhead.tk'
},
bosh: '//meet.jabberhead.tk/http-bind', // NOTE: or /bosh, depending on your setup
clientNode: 'http://jitsi.org/jitsimeet',
focusUserJid: 'focus@jabberhead.tk',
testing: {
...
}
...
}
Finally of course, I also had to register the focus and jvb users as XMPP accounts:
ejabberdctl register focus jabberhead.tk <FOCUS_USER_SECRET>
ejabberdctl register jvb jabberhead.tk <JVB_USER_SECRET>
Remember to replace the placeholders with strong password and also stop and disable the bundled prosody! That’s it!
I hope this lowers the bar for some to deploy Jitsi Meet next to their already existing ejabberd. Lastly please do not ask me for support, as I barely managed to get this working for myself 😛
Update (11.04.2020)
With feedback from Holger I reworked my ejabberd config and disabled s2s for the meet vhost, see above.
Someone also pointed out that it may be a good idea to substitute prosody with a dummy package to save disk space and possible attack surface.
Update (16.06.2020)
I migrated this guide to use the new videobridge2 package. The changes in a gist:
- Remove videobridge component configuration from ejabberd config
- Register new jvb@yourdomain user for the videobridge
- Update videobridge config and sip-communicator.properties files (see further up)
What I might look into next is how to use ejabberd’s bundled (since 20.04) STUN/TURN server instead of the default one…
Note: The Jitsi Meet components do some regular health checks. They do this by (as far as I understand) creating temporary MUC rooms every few seconds. Since ejabberd stores entity capabilities indefinitely, this may cause the caps_features table of ejabberd’s database to quickly fill up with lots of junk. Apparently this was fixed in later versions of ejabberd, however, if you still need a workaround, you may try deleting unused caps entries periodically.
21 responses to “Install Jitsi-Meet alongside ejabberd”
@Vanitasvitae :xmpp: thanks a lot for this. I knew it was possible to unbundle jitsi from the build in Prosody server, but I could never find a guide for it.
@vanitasvitae @nuron guckst du hier, vielleicht hilft dir das ein Stück weiter
@vanitasvitae Oh nice we were talking about this!! I'm gonna have to migrate our server to NixOS and then I can feel confident trying this out 🙂
Thank you for this post, I think it will come in handy. Yesterday I tried the manual installation as I also wanted to integrate it with my existing xmppd (prosody) instead of using the all-in-one Debian package but I gave up when some piece of it required ancient openjdk-7-jre. Is your setup working with openjkd-11-jre?
“Remember to […] stop and disable the bundled prosody! That’s it!”
Do you know if I can prevent it from starting it after installation? I don’t want to risk f*ing up my prosody by installing jitsi.
My machine (buster) has only openjdk-11 installed.
As far as I know, the installation of jitsi-meet should detect your prosody and use that instead of installing another one. I also think that jitsi-meet should add its own configuration into /etc/prosody/conf.d/meet.your-domain.cfg.lua, so you probably don’t have to configure anything?
It just used my existing prosody as I already had the virtual hosts and components configured due to my earlier approach with the manual set up.
When you use your normal xmpp for authentication instead of auth.meet.jabberhead.tk, does it mean people can create conferences with their “normal xmpp account” credentials?
As far as I understand no.
@vanitasvitae I'm actually very interested to what extend it actually can "integrate" with the ejabberd XMPP server. Does it just use it silently in the background? Or is there some level of integration possible?F.e. it looks like your meet.jabberhead.tk page looks quite exactly like the public Jisti Meet without any authentication or so.
This might be helpful:
https://apt.debalance.de/pool/main/p/prosody-dummy/
Hey! I was playing with this 2 days after you posted, so thank your for sharing your experience.
I have a working setup now, but I have a problem. maybe you also have it: users losing connection abruptly (you can kill the browser to reproduce it) never leave the room until you send them a message or write in the chat. Are you also experiencing this?
Best,
I don’t have said issue I guess. Maybe you don’t have the ping module enabled or some sort of connection timeout disabled?
Thanks for this article! Before I start: was this with videobrigde or videobridge2? If it is 2, is it also working for you?
With videobridge2 you have this:
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.tld.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=**
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.tld.com
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=..-da11-4d09-83ec-e025d50a730f
Is this the same with videobridge?
This was written for videobridge. videobridge2 switched to using MUC instead of the component protocol, so the configuration for videobridge2 slightly varies from what I wrote above, but you should be able to apply any upgrade tutorial to my write-up 🙂
@vanitasvitae I used your great tutorial to setup a Jitsi Meet instance together with a already existing Ejabberd chat service.Configuration seems to be correct so far but Jitsi Meet users are kicked out with a error message after a few seconds.I have timeouts between ejabberd and jicofo and jitsi-videobridge in the logs of jicofo and jitsi-videobridge.Do you have a idea how I can fix that?
I have the same error. How did you solve this?
@vanitasvitae Thank you for this! Are you able to share the ejabberd.yml config file? I am having issues with timeout and I think its cause of missing configuration. Thank you!
I can’t share my config file, but I have updated the tutorial and there should be all necessary parts present in the snippets 🙂
Thank you very much for the article, it has helped me a lot
Hi
Thanks for this article. Any news about the STUN/TURN server ?
Thx
Hi,
Please help me with the following error.
Accessing the room, ejabberd has the following error log.
BOSH Incoming data: <<"”>>
Send XML on stream = <<"Access denied by service policy”>>