When I decide to enter a room with the video off, then I activate it later, no one sees me

we have the 6865 stable version of Jitsi meet.

We have noticed that if I enter a room with the camera disabled, and then try to reactivate it, this operation only affects me, everyone else continues to see me with the video turned off.
Same anomaly for all those who do the usual operation.

I noticed that on https://meet.jit.si/ everything works correctly but I think it is because the p2p enable is present.
We have disabled p2p on our version.

Did you know about this anomaly?


When connecting to meet.jit.si you can pass “#config.p2p.enabled=false” in the url to disable p2p.
Do you reproduce it there?

I didn’t know you could do these kinds of tests, great!

So are you telling me that i could test jisti without the prejoin active just by setting this:

after https://meet.jit.si


Yes. As long as the config is in the whitelist you can override per user using url params or using options in IFrame API.

If you want to quickly play around with url params, try Jitsi URL Generator.

P.S. it has not yet been updated to use the new prejoinConfig.enabled format, but the old config style should still works (for now).

1 Like

Thank you ,
very interesting.

I think I have identified the problem.

We do not use the active prejoin (false on config.js) but we use it only in the case of Lobby on.

There is one thing to know, we enable the lobby when the room is opened on the server side with the relative hook:

host_module: hook ('muc-set-affiliation', function (event)
            if jid_split (event.jid) ~ = 'focus' and event.affiliation == 'owner' then
            handle_create_lobby (event);

inserted in mod_muc_lobby_rooms.lua


I verified that if I activate the prejoin on config.js, the management of the webcam works correctly (the participant enters off and then when he activates it the others see him).

On the other hand, when I take advantage of the prejoin that is triggered by the activation of the server-side lobby, this prejoin has different effects, in fact the participant enters the room with the video off and then turns it on but whoever is inside does not see any changes.

This problem was introduced by merging with stable 6865. Our code merged with stable 5390 worked perfectly.

5390 was on Plan B, 6865 is on Unified Plan. Perhaps the change to support Unified Plan made your custom code incompatible.

I understand but the activation or deactivation of the camera in the prejoin page, is not touched by my code …

Not directly, but with Unified Plan, Chrome changed how streams are handled, so changes needed to be made to align with that. If you check your old deployment for instance, without an origin trial, you’ll find out you don’t see remote videos using Chrome even though the cameras are on.

Yes, we have temporarily buffered this problem with the Chrome token …

Do you have any other suggestions? I don’t know how to fix this…

I did the test on meet.jit.si and the anomaly does not manifest itself. Is the version on meet.jit.si stable 6865 or is it updated to the latest commit?

AFAIK, meet.jit.si is not always on stable and will often be a release candidate from unstable build. If you want to test against the most recent changes, use http://alpha.jitsi.net/.

To find out version, I usually start a 2 party call then search for “version” in console. For example:

That shows JVB version of 2.1.620-g93f4d88c which corresponds to a 08-Feb-2022 build in unstable and not from stable.

There are cleverer ways to find version numbers of a live deployment if you want to do this often.

1 Like

Okay, I think I have located the bug.

I have set up a solution based on the 6865 stable version clean, without custom code.

  1. prejoin disabled
  2. moderator opens the room and enables the lobby
  3. a participant tries to enter the room and is presented with the prejoin page
  4. the participant enters with the webcam turned off, then inside the room he enables the webcam → no one sees him

When I redid everything but with the prejoin enabled, both the moderator and the participant go to the prejoin page, and following points 2, 3 and 4 the final result is that the participant is seen correctly by the others.

So the problem only comes up if the prejoin Page is disabled.

Are you aware of this bug?

ps. we want to keep the prejoin page disabled.
For us the moderator is whoever opens the room.
We do not want the moderator to see the prejoin, because this further preparation step does not make sense since it will be the only one in the room.

Do you see errors in the console when this happens?

No no mistakes.

The difference I noticed is on the writing of the button in prejoin Page.

With the prejoin page enabled, it shows the message “Ask to Join”, instead with the prejoin disabled but the lobby active, present “Join meeting”.

Apparently they are called two different prejoin pages …

Yeah those are different in this case, open an issue in jitsi-meet project on github.