Jitsi-meet

Jitsi is a set of open-source projects that allows you to easily build and deploy secure videoconferencing solutions. At the heart of Jitsi are Jitsi Videobridge and Jitsi Meet, which let you have conferences on the internet, while other projects from the community enable other features such as audio, dial-in, recording, and simulcasting.

Installation

Jitsi-meet consists of severals components:

  • jitsi-meet: the files for the webinterface, accessed via files served by a webserver
  • jitsi-meet-prosody: the prosody plugins for jitsi
  • jitsi-meet-turnserver: the configs example to run a stun/turn server
  • jitsi-videobridge: the video bridging service providing video streams to all participants
  • jicofo: the Jitsi conference focus determining who is speaking
  • Prosody: a free XMPP server serving as the base of the setup

A graphical overview of the interfaces to the user and towards each other is given here.

You can either use the git versions, the nightly version or the stable versions.

It is possible to install them at the same time, but you will need to use separate port and several instances of prosody (the plugins cannot be scope by virtual host).

You need to choose between the normal or the bin version. The bin one conflicts with the normal version (i.e. nightly and nightly-bin can not be installed at the same time, but stable and nightly can be).

Try to stick with only one of them:

Some packages install configuration examples in /usr/share/doc, ensure to comment this line in /etc/pacman.conf:

#NoExtract = usr/share/gtk-doc/html/* usr/share/doc/*

You need those optionals packages to run a standalone server:

Configuration

Note: This configuration yields an open server for everyone to connect. Refer to the Jitsi philosophy for rationale. See #Tips and tricks for authentication.

If your server name is example.com then a common choice for your jitsi will be , but you can choose freely. It is however strongly encouraged from security standpoint to host webapps on their own subdomain. You will need to update DNS record for your server with an entry of your chosen subdomain, in the above example . The remainder assumes that you have done this.

Also you should have SSL/TLS certificates for your domain, on how to obtain free certificates see certbot.

In the following, the following placeholders are used:

  • : your jitsi-meet domain, e.g.
  • : password for the videobridge
  • SECRET_FOCUS_USER: password for the authenticator

Passwords should be obtained in a safe way, e.g. via or via . Make sure to use different and safe passwords!

Configuration paths

Package Configuration path
colspan="2"

jitsi-meet-binAUR


jicofoAUR
/etc/jicofo

colspan="2"


/usr/lib/jitsi-meet-prosody-nightly
jitsi-meet-turnserver-nightlyAUR


Git
jitsi-meet-prosody-gitAUR
/etc/jitsi-videobridge-git

Loopback

Let us jitsi-meet components reach each other with local ip. It works even if your domain is behind a proxy like Cloudflare which does not return the real ip of the server.

In :

Configure prosody

is a prerequisite and you will need to add a configuration to it for your Jitsi services. If you do not already have a prosody server set up, install  and  now. The rest of the prosody configuration assumes you have a local install of prosody. 

The package provides a configuration you can easily customize:

# cd /etc/prosody
# mkdir conf.d
# cp /usr/share/doc/jitsi-meet-prosody/prosody.cfg.lua-jvb.example conf.d/jitsi.cfg.lua

Then add this at the end of:

Customize your configuration:

You need now to generate the certificate for JITSIFQDN and auth.JITSIFQDN.

If you use certbot, you can import the certificate with:

# prosodyctl --root cert import /etc/letsencrypt/live

If you want to use self generated certs, you can use:

Let us register the users jvb and focus:

Then restart (or start/enable it if it was just installed).

Configure jitsi-videobridge

The configuration for jitsi-videobridge. Add -nightly or -git to /etc/jitsi-videobridge for nightly and git version.

For MUC_NICKNAME, use uuidgen command:

/etc/jitsi-videobridge/sip-communicator.properties
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.'''JITSIFQDN'''
org.jitsi.videobridge.xmpp.user.shard.PASSWORD='''SECRET_JVB_USER'''
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.'''JITSIFQDN'''
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME='''UUIDGEN_RESULT'''

Then start/enable .

Configure jicofo

The configuration for jicofo. Add -nightly or -git to /etc/jitsi-videobridge for nightly and git version.

Then start/enable .

Configure jitsi-meet

The configuration for jitsi-meet webapps. Add -nightly or -git to /etc/jitsi-videobridge for nightly and git version.

/etc/webapps/jitsi-meet/config.js
var config = {
  hosts: {
    domain: ''''JITSIFQDN'''',
    // ...
    muc: 'conference.'''JITSIFQDN''''
  },
  bosh: '//'''JITSIFQDN'''/http-bind',
  // ...
}

Configure nginx

Configure nginx with TLS as described in nginx#TLS.

Let us copy the provided example.

Then include it in your main configuration:

Then changes the jitsi configuration with yours:

Then restart .

Tips and tricks

Running the server behind a NAT

The following ports need to be forwarded to your server:

HTTPS:

  • TCP/443

Jitsi Videobridge:

  • UDP/10000

Jitsi gateway to SIP (Jigasi)

To interface the Jitsi-meet meetings with traditional SIP install or jigasi-gitAUR and edit the prosody config:

fill the SIP access credentials ( and )

To change the default room name SIP is connecting to, change org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME in the above config.

Then edit the jigasi configuration

and then start/enable .

Access restrictions for room creation

To restrict video conference room creation to authenticated users, you can do the following steps. Note that participants to the meeting are still not authenticated!

Add authentication to the jitsi domain in prosody and add a new virtual host for guests:

/etc/prosody/conf.d/jitsi.cfg.lua
-- change authentification of your domain
VirtualHost "'''JITSIFQDN'''"
    authentification = "internal_plain"

-- add guest virtual host to allow anonymous user to join your room
VirtualHost "guest.'''JITSIFQDN'''"
    authentication = "anonymous"
    c2s_require_encryption = false
    modules_enabled = {
        -- copy the content of the modules_enabled
        -- of the VirtualHost "'''JITSIFQDN'''"
        -- remove only the module "muc_lobby_rooms" of the list
        -- example:
        "bosh";
        "pubsub";
        "ping"; -- Enable mod_ping
        "speakerstats";
        "external_services";
        "conference_duration";
    }

Edit the configuration file for jitsi-meet:

Add authentication for jicofo:

Then create the desired users via

Only if you are using (if you do not know, you do not) edit the SIP interface to not allow anonymous authentication:

These steps are taken from this guide.

Access restrictions with JWT token

To restrict video conference room creation to users authenticate with a JWT token (external service for authentication), you can do the following steps. Note that participants to the meeting are still not authenticated!

Install those dependencies:

Add authentication to the jitsi domain in prosody and add a new virtual host for guests:

Edit the configuration file for jitsi-meet:

Add authentication for jicofo:

Then restart (or start/enable it if it was just installed). And restart (or start/enable it if it was just installed).

Now you can use a JWT token to authenticate an user.

You can read the spec here: Jitsi Meet Tokens

Here an quick example in nodejs:

const jwt = require('jsonwebtoken')
const crypto = require('crypto');
const words = require('random-words')
const yourDomain = "JITSIFQDN"
const appId = "APP_ID"
const appSecret = "APP_SECRET"
const userName = "YOUR_USERNAME"
const userEmail = "YOUR_EMAIL"

function getBody(domain, appId, name, email, room) {
    const md5Email = crypto.createHash('md5').update(email).digest("hex");
    const id = crypto.createHash('sha1').update(`${name}:${email}`).digest("hex")

    return {
        context: {
            user: {
                avatar: `https:/gravatar.com/avatar/${md5Email}`,
                name,
                email,
                id,
            },
            group: 'users'
        },
        "aud": "jitsi",
        "iss": appId,
        "sub": domain,
        room,
    }
}

const room = process.argv[2] || words({exactly: 3, join: '-'})

const data = getBody(
    yourDomain,
    appId,
    userName,
    userEmail,
    room,
)

const options = {
    algorithm: 'HS256',
    expiresIn: '2h',
}

const jwtToken = jwt.sign(data, appSecret, options)

console.log(`https://${yourDomain}/${room}?jwt=${jwtToken}`)

Log evaluation

For a publicly available IP address the above configuration leads to a public video conference server. To monitor server use one can use journalctl to get an at least vague idea of the usage:

# journalctl --unit=jicofo.service --grep="created new conference" --output cat

shows all events of new chat room creation and

# journalctl --unit=jicofo.service --grep="Stopped" --output cat

shows all events of chat room destruction.

Grepping for 'member' also gives you (anonymous!) information on the participants.

Running own STUN server

By default, Jitsi Meet uses STUN servers from jitsi.org. You can easily run your own STUN server using coturn and setting it in jitsi-meet's config.

Troubleshooting

Check your logs

You can stop all service units (i.e., , , and ), start them one at a time, and follow new messages in the journal for each service unit to see if something is wrong. Most problems are due to password or configuration issues.

If you have an upgrade from a very different version, or you mess up with your config, start other. It will be faster than trying to findout which part is wrong.

Ask help on Matrix rooms

You can join matrix rooms and ask help there:

gollark: Suuuuuure.
gollark: If people believe things which cause them to make stupider decisions, too bad, they shouldn't do that.
gollark: Maybe with children, sure, as they can't really meaningfully decide very well.
gollark: You seem to be pushing the definitions of "harm" pretty far.
gollark: Tolerating as "you may say/do this" versus "I support you saying/doing this", maybe.

See also

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.