KokaKiwi/nixcfg
1
0
Fork 0
forked from Deuxfleurs/nixcfg
Code Pull requests Activity
nixcfg/cluster/prod/app/jitsi/integration/README.md

5.8 KiB
Raw Blame History

About Jitsi

Several server components:

  • prosody XMPP (ext)
  • jitsi videobridge aka JVB
  • jitsi conference focus aka jicofo aka focus
  • jitsi meet
  • octo
  • jigasi
  • jibri
  • etc.

Some libs:

  • libjitsi seems deprecated
  • jicoco contains some parent classes to handle Jitsi's Configuration
  • jitsi-utils contains the Logger definition for example
  • ice4j contains jitsi's implementation of WebRTC
  • etc.

Client components:

  • jitsi meet electron
  • jitsi android/ios
  • etc.

Conf

Base conf:

the following is used in videobridge.conf: jicoco/MucClientConfiguration

How the new configuration is read in jicoco: https://github.com/jitsi/jicoco/blob/master/jicoco-config/src/main/kotlin/org/jitsi/config/JitsiConfig.kt#L83-L91 They use this library: https://github.com/lightbend/config We are particularly interested by: https://github.com/lightbend/config#standard-behavior Using 'application.conf' with classpath does not seem to work. But, specifying the file path as -Dconfig.file=/etc/jitsi/jicofo.conf works!

Some parameters are also set independently of lightbend hocon config. They are seen in jicofo entrypoint: https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/jicofo/Main.java Many of these parameters can be in fact read from the HOCON file except one: the --secret parameter or the JICOFO_SECRET env variable. But we can see this is a deprecated thing, it has been already removed from master: c9e5b50a8b For now (as per v5390) we will keep JICOFO_SECRET environment variable but will assume no other environment variable is set But maybe this value is deprecated: the check is still here but it is not used anymore?!

Run the integration suite

start a maintainance container

docker run --rm -it -v `pwd`/prosody/certs/:/var/lib/prosody/ -v `pwd`/prosody/prosody.cfg.lua:/etc/prosody/prosody.cfg.lua:ro --user root superboum/amd64_jitsi_xmpp:v12 bash

then generate certificates from inside this container

cd /var/lib/prosody/
chown -R prosody .
prosodyctl cert generate auth.jitsi
prosodyctl cert generate jitsi

then start the stack

docker-compose up

go to the URL by using a LAN/WAN IP (not localhost) and accept the self signed cert.

https://192.168.1.143

Generate certs with prosody

prosodyctl cert generate auth.jitsi
prosodyctl cert generate jitsi

An example prosody configuration file

https://github.com/jitsi/jitsi-meet/blob/master/doc/example-config-files/prosody.cfg.lua.example

but this one is not the one used by the debian postinst script instead, we should look at this one: https://github.com/jitsi/jitsi-meet/blob/master/doc/debian/jitsi-meet-prosody/prosody.cfg.lua-jvb.example

Jitsi can be configured to authenticated through tokens, the postinst file is here: https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet-tokens.postinst

Remote debug

Add this parameter to the java process you want to debug (either jicofo or jvb). It must be added by modifying the entrypoint script, next to the respective Dockerfile of each container.

-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005

Be careful

jiti-videobridge (jvb) does not start to listen on ICE ports (both TCP and UDP) at boot. Instead, listening is triggered on the creation of the first conference (a 2 people P2P conference is enough). A nice entrypoint to check with your debugger is:

Resources to understand jitsi