[How to] How to customize meeting options

Jitsi Meet conferences are started with a default set of options, optimized for the best experience for most situations. However, there are many meeting options available for you to customize.

Want do disable YouTube videos? No problem. Want everyone to start muted? You got it!

:star:This topic will help you understand how to enable and disable common features.

Option Categories and Locations

Options are split into two main categories, UI configuration (interface_config) and system & feature configuration (config). The table below highlights the difference between the two.

interface_config config
Info mainly UI related options a mix of settings and feature options
File Location (self-hosted) /usr⁩/share⁩/jitsi-meet⁩/interface-config.js /etc/jitsi/meet/[your-domain-name]-config.js
iframe variable interfaceConfigOverwrite configOverwrite
URL parameter interfaceConfig config
Honored by mobile client? No Yes
All Options link link
Options available to URL & iframe link link
iframe Example link link
URL Example Filmstrip Only mode: https://meet.jit.si/example-101#interfaceConfig.filmStripOnly=true Prejoin page enabled: https://meet.jit.si/example-101#config.prejoinPageEnabled=true

:bulb: If you are overwriting options in the URL or iframe, you cannot access all options. Only a subset of options have been whitelisted. For example, you cannot remove the Jitsi logo. See the “Available to URL overwriting & iframe” row above

Learn By Example

Let’s start with an example. Let’s enable the prejoin page and disable the ability to ‘Kick’ others.

1. Single Meeting Example

Disable kick and enable the prejoin page for a single meeting by adding #config.prejoinPageEnabled=true&config.remoteVideoMenu.disableKick=true to the URL you share with your meeting invitees.

For example: https://meet.jit.si/example-102#config.prejoinPageEnabled=true&config.remoteVideoMenu.disableKick=true

:triangular_flag_on_post: A word of caution with disabling kick using the URL: If you share this link with a participant, they can simply modify their URL before they join and still be able to kick others.

(keywords: URL overload, URL override, URL overriding, URL overwriting, URL options)

2. All Meetings Example

Disable kick and enable the prejoin page for all meetings by setting prejoinPageEnabled and disableKick to true in your config.

If you are hosting your own server:

First, edit your /etc/jitsi/meet/[your-domain-name]-config.js (not interface_config) and uncomment the remoteVideoMenu section to make it look like this:

...
    remoteVideoMenu: {
        disableKick: true
    }
...

Next, uncomment // prejoinPageEnabled: false, and change it to prejoinPageEnabled: true,. Save the file

If you are using the iframe API, use:

...
    configOverwrite:
    {
        remoteVideoMenu:
        {
            disableKick: true,
        },
        prejoinPageEnabled: true,
    },
...

Other iframe examples:

Rinse and Repeat

Using the list of available options in the table above, use this same technique for other options.

:globe_with_meridians: Here is a complex URL example with settings from both “config” and “interface_config”. Give it a try and notice the difference in toolbar buttons and profile options:
https://meet.jit.si/example-103#config.startWithVideoMuted=true&interfaceConfig.TOOLBAR_BUTTONS=%5B%22microphone%22%2C%22camera%22%2C%22desktop%22%2C%22fullscreen%22%2C%22hangup%22%2C%22profile%22%2C%22settings%22%2C%22videoquality%22%5D&interfaceConfig.SETTINGS_SECTIONS=%5B%22devices%22%2C%22language%22%5D&interfaceConfig.TOOLBAR_ALWAYS_VISIBLE=true

By the way those are url encoded characters, above. The %22 is a double quote " and %2C is a comma ,. %5B and %D are [ and ] respectively.

Hope this helps!

17 Likes

This is a very useful write-up, @corby. Thanks for sharing! :clap:t5:

I noticed you have the security shield, sharing icon and a lot of options removed from the pop-up menu. I imagine this is set for meeting attendants (the moderator still has full access to the entire library of settings). Is there any reference in the knowledge-base here on how to do this? Please direct, if so.

Thanks!

@Freddie,

Yes. The URL example at the end of the post above is showing how to combine many parameters into a single link. This would apply to everyone who joins the meeting using that link. It’s true a moderator could join using another link with different options.

1 Like

Great! Thank you!

Hi @corby,

Great work !! Thanks for sharing !

I was wondering if we could add our own interfaceConfig field.

Such as we could pass a speaker array in the API while loading a room.
interfaceConfigOverwrite:

{
    speakerList: [ {XX},{YY} ]
}

And access them in our React functions as per our need.

I know it is a long shot, but can we do something similar currently.

I’m just curious !!

@damencho

You will also need to add it in the whitelist of configs that are allowed

Thanks @damencho

I was able to add a custom field in the interfaceConfigOverwrite. Anyone you us interested refer the following steps:

Add your field in the below file
Whilelist file path : jitsi-meet/react/features/base/config/interfaceConfigWhitelist.js

For including your field in react component add following lines in your component:
In my case I edited react/features/base/premeeting/components/web/CopyMeetingUrl.js

declare var interfaceConfig: Object;

const your_custom_field = interfaceConfig.yourcustomfield;

Happy Coding !!

1 Like

Great info, thanks.
I think this post should considered to be added to the official documentation.

Consider me a newbie when it comes to javascript, iFrame API and Jitsi but I have a couple of questions.

  1. I’d like to use a URL like https://meet.jit.si/example-103 with the DisplayName and eMail added to the URL.
  2. I’d like to have a form that could interact with the iFrame API to create the RoomName, DisplayName and email.

On submit of the form it would open in a new window calling the Jitsi server with those 3 values.

I’d pay good money for those two solutions.

Hi @Jim_Eddins, for your question one. You can pass data with information for URL like in the examples showed before. You must take into account the information provided by the documentation for the IFRAME.
For your question two, you should know that with change the url it will create a new room automatically, so it’s possible that other person create a room with the same name as your room (so that you don’t have this problem you should consult Self-Hosting Guide)

Docs Self-Hosting Guide: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-start

Now, the API IFRAME don’t have form for pass data in the room, you must pass data for medium of Objects javascript in the config.

Docs API IFRAME: https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-iframe.

Excuse my english, I’m not a speaker

Hello, how to enable the screen sharing automatically on a meeting?

hallo

@mdev - You can’t.

@Philipp_Hollendong - hi :raising_hand_man:

Hat geklappt

I’m using the standalone Jitsi Meet.app (v2.4.2) on macOS (v10.10.5 (14F2511)) to join moderately sized meetings (~15 participants). (My browser is already overloaded with ~1000 open tabs; it doesn’t need to host any other apps!)

We had a slideshow presentation in a recent meeting, so one user was sharing their desktop. No-one else had live video; all avatars were either still-photos or initials. Jitsi suddenly start eating 350% of CPU in my MacBook Pro (MacBook Pro (Retina, 15-inch, Late 2013))! And I started researching settings…

Why are so many “client preference” settings, about which meeting organizers may not care at all (and which will typically not reach the server, as they’re in the client-side fragment identifier space [#], rather than the server-side query argument space [?]), exiled to the connection URL which meeting organizers will tend to propagate in its simplest form – i.e., only with any settings they do care about, which is likely to be zero?

I can find no *config.js in any apparently relevant directory. I want to apply the #config.channelLastN=3 and &disableAudioLevels=true to all future launches of Jitsi Meet.

I don’t want to edit every URL supplied by meeting organizers to add these not-really-fragment-identifiers (following #) that are really query parameters (and should follow ?). HTTP URIs do not support multiple fragment identifiers in a single URI (&), nor do they support setting=value as a fragment identifier!

Now… Looking at the list of all available Options, I find –

    // Default value for the channel "last N" attribute. -1 for unlimited.
    channelLastN: -1,

    // Provides a way to use different "last N" values based on the number of participants in the conference.
    // The keys in an Object represent number of participants and the values are "last N" to be used when number of
    // participants gets to or above the number.
    //
    // For the given example mapping, "last N" will be set to 20 as long as there are at least 5, but less than
    // 29 participants in the call and it will be lowered to 15 when the 30th participant joins. The 'channelLastN'
    // will be used as default until the first threshold is reached.
    //
    // lastNLimits: {
    //     5: 20,
    //     30: 15,
    //     50: 10,
    //     70: 5,
    //     90: 2
    // },

“The ‘channelLastN’ will be used as default until the first threshold is reached.” That appears to say that if I set channelLastN: 2, it will only have effect until the participant count reaches 5 (or is it 30 ?), at which point channelLastN will become 20 (or 15), far above what I’ve set!

I would suggest that if both are set the lower of channelLastN or lastNLimits should be in effect, until the participant count exceeds that which would result in the active channelLastN setting, at which point the threshold-based lastNLimits values take control.

(If only one of these is intended to be set, both should say so.)

(And really, truly, omg, please – all these client-side settings should be in the settings dialog [or, if absolutely necessary, in some arcane local config file that is properly documented for every OS targeted by an official port], not in connection URLs!)

Why are so many “client preference” settings, about which meeting organizers may not care at all (and which will typically not reach the server, as they’re in the client-side fragment identifier space [#], rather than the server-side query argument space [?]), exiled to the connection URL which meeting organizers will tend to propagate in its simplest form – i.e., only with any settings they do care about, which is likely to be zero?

I’m using Jitsi Meet (v2.4.2) on macOS (v10.10.5 (14F2511)). I can find no *config.js in any apparently relevant directory. I want to apply the #config.channelLastN=3 and &disableAudioLevels=true to all future launches of Jitsi Meet.

I don’t want to edit every URL supplied by meeting organizers to add these not-really-fragment-identifiers (following #) that are really query parameters (and should follow ?). HTTP URIs do not support multiple fragment identifiers in a single URI (&), nor do they support setting=value as a fragment identifier!

It’s a server side configuration file; setup by those that host their own Jitsi servers for their users.

All the more reason that these URL-suffix-based client-side settings should become dialog-based client-side settings.

Glad I could help :+1:. If you have ideas about new features, feel free to create a new topic outside of this [How to], here:

1 Like