Is there a recommended default configuration?

I am overwhelmed with all the customization options. I need a NON-customized starting point that maximizes compatibility for users joining a meeting room.

I have a recommended configuration from a friend but some users are having problems and I can’t figure out what things are standard and which things are customizations.

Thanks.

The default installation/configuration works fine out of the box.

1 Like

I agree, it sure does.

Great. Where can I get a “clean” copy of Jitsi’s system.config?
If I reinstall Jitsi, will it overwrite/reset my modified system.config?

From my experience, I don’t think a reinstall will over write, but if you delete your old Jitsi folders or build a new server, then the reinstall would have to recreate the new files.

I would build a second server and then take a clean copy of its config files from the second server, delete the second server, and restore or modify my original jitsi server based on the copy I made of the second server.

I am curious, as to which config files you are thinking about? Is it the ones ones in /etc/jitsi ?

I only have one server. (How many servers do you have? Oooo) yes it is the file with all the option settings in /etc/Jitsi. I’ll make a copy of the file and uninstall Jitsi and do a new install.

Or, would it work be if I delete the parameters file and reinstall? Fewer steps

As I use virtual machines, I can easily spin up another server for testing and delete it later. I don’t use the server so much that I have to keep it running 24/7, I can turn off my production server and spin up another test server in its place for a few hours and then take it down and put the production server back up.

If it was me, I would take a backup/copy of all files/folders under /etc/jitsi and then delete all files and folders in /etc/jitsi, then follow the instructions for removing and reinstalling (if you have not seen these at the end of the install please let me know and I will send you a link).
# rm -rf /etc/jitsi (only after taking a backup of these files and folders)

Hope this helps…

As others have pointed out, the default configs works well out of the box and is always a good start.

I’ve been down that road. I made trial-and-error changes based on configs from friends, and from snippets from different forum posts until things kinda worked. And then it doesn’t :slight_smile: and it is hard to tell what has been customised or what configs you have in place is actually applicable since Jitsi configs do evolve over time.

Here’s what I do now:

I always do fresh installs instead of in-place upgrades (so I can test new version before replacing live instance), and I always keep a backup of the original configs that were created by a fresh install. This gives me 3 versions of configs files when building a new instance:

  • “live configs” – config I am using on my live instance running on previous Jitsi version
  • “old defaults” – default config installed by previous version of Jitsi package
  • “new defaults” – default config installed by latest version of Jitsi package

This allows me to:

  1. Diff old defaults vs new defaults, giving me a view of which configs have been added, removed, have new comments, or have new values.
    • For anything that has changed, I can then find out more about how it might be applicable to my deployment
    • If a config has not changed, then I know my live config can be applied verbatim
  2. Diff “live configs” vs “old defaults”, giving me a list of customisations that I have made.
    • Very useful during debugging to answer question like “what have I changed that might have broken this”
    • Also useful when previous step shows lots of diffs between old and new defaults – sometimes cleaner to reapply customisation to new fresh version than porting diffs to customised old config.

Yes, this is an elaborate process and by no means something I am pushing as a recommended approach. But it works for me, for now. As you mentioned, there are lots of customization options and can be overwhelming; so started with defaults, tweak it over time, then use this process to keep track of ongoing changes. YMMV.

1 Like

shawn, I like your approach.

Thank you for a reminder of good practice. I am not (yet) skilled with Linux and I am too eager to get things done. I hope to get a new install later this week.

My new install is failing. What does the error message mean?
● jitsi-videobridge2.service - Jitsi Videobridge
Loaded: loaded (/lib/systemd/system/jitsi-videobridge2.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Tue 2021-05-11 12:24:12 HST; 810ms ago
Process: 143957 ExecStart=/bin/bash -c exec /usr/share/jitsi-videobridge/jvb.sh ${JVB_OPTS} < /dev/null >> ${LOGFILE} 2>&1 (code=exited, status=1/FAILURE)
Process: 143958 ExecStartPost=/bin/bash -c echo $MAINPID > /var/run/jitsi-videobridge/jitsi-videobridge.pid (code=exited, status=0/SUCCESS)
Main PID: 143957 (code=exited, status=1/FAILURE)

What do I need to change?

I’m afraid I’m not able to guess what’s going on with just that information.

What errors do you see in jvb logs?

I found the jvb.log. It doesn’t timestamp the entries so I don’t know how old some entries are. However the last part of the files are filled with one error.

Blockquote
Unrecognized VM option ‘UseConcMarkSweepGC’
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Where is that option used?
I guess that is now my next treasure hunt.

I searched this forum for that error message and found this:

Are you using either OpenJDK 8 or 11?

Two steps forward, one step backwards.
1- I was running openjdk 16.
2- successfully installed openjdk11.
3- where do I find the jvm.log??? Today I couldn’t find the file. (And I didn’t write a note where I found the file two days ago.)

Jitsi is running. Onward with the testing. I hope my other app is happy with openjdk 11.
Thank you.

Did you mean JVB? If so, /var/log/jitsi/jvb.log

:+1:t4:

I finally had a 8 user test. FAIL!
We all could see ourselves! Camera compatibility is working much better.
We all see the other participants as if the camera was off. We could not see each others video.

I hope some one can help me understand this log.
jvb.log (6.4 KB)

Thank you

That log doesn’t show any request to jvb. You need to start debugging a problem like this from the client js console, do you see errors. You can just test by opening 3 tabs in chrome.

Your jvb is announcing only its internal ip address and clients cannot reach it.
Do you have this line org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443 in your jvb config in /etc/jitsi/videobridge/sip-communicator.properties?

Probably you have it … but it failed:

JVB 2021-05-14 08:18:47.884 INFO: [21] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Initialized mapping harvesters (delay=125ms).  stunDiscoveryFailed=false

You have some firewall rule that blocks the udp traffic from jvb to that address on port 443 and jvb fails to discover its public address and is not announcing it and clients media cannot reach it.

Thank you for your suggestion. However I don’t know how to interpret what you suggest.
1- can I just open 3 tabs in chrome pointed to google?
2- “client js console” - does this mean I want to look at js console of Chrome?
Are you suspecting that. all 8 users were having js errors?

I’ll be giving this a try.