Automatical Switching to the speaker does not work with the latest update

Good day! Dear developers, I want to thank you for your wonderful product! With the installation of the latest current version, namely:
Ubuntu server 20.04.
jitsi-archive-keyring / stable 1.0.1 all
jitsi-meet-prosody / stable, now 1.0.5415-1 all [installed, automatic]
jitsi-meet-tokens / stable 1.0.5415-1 all
jitsi-meet-turnserver / stable, now 1.0.5415-1 all [installed, automatic]
jitsi-meet-web-config / stable, now 1.0.5415-1 all [installed, automatic]
jitsi-meet-web / stable, now 1.0.5415-1 all [installed, automatic]
jitsi-meet / stable, now 2.0.6433-1 all [installed]
jitsi-upload-integrations / stable 0.15.15-1 all
jitsi-videobridge2 / stable, now 2.1-570-gb802be83-1 all [installed, automatic]
jitsi-videobridge / stable 1126-1 amd64
jitsi-videobridge / stable 1126-1 i386

There was a problem, when the speaker starts to speak, there is no automatic focus on this speaker. Please help with the solution of this problem. Thanks.

Any js console errors, sounds like your websocket to the bridge is not working.

It happened to me in a version from May of this year. but when I updated to the current one it did not happen again. I would recommend you to check the jvb that this is the current version, if not install it again manually.
https://download.jitsi.org/stable/jitsi-videobridge2_2.1-570-gb802be83-1_all.deb

Indeed, it is a websocket issue. Is everything hosted on the same server?

yes, everything is on one server.

Do another test meeting with the js console open, try to get a screenshot from the very first error that shows up.


and after connecting another user to the conference, websocket errors appear

Check your nginx log for errors

yes, could you check every component logs and startup logs. (jicofo, prosody, jvb, web) and put errors here.

conference failed authentication failed : is it possible that some password or auth mechanism are wrong.
btw, you will probably get the right track on logs for sure.

can you put your prosody / jicofo configuration here ? because there are some settings that have changed in the last versions since websocket are used

Hi,
Your issue with last speaker is a result of your websocket error.
Could you share your nginx and videobridge config file ?

sip-communicator.properties.txt (46 Bytes)
logging.properties.txt (1.9 KB)
jicofo_conf.txt (391 Bytes)
jicofo_config.txt (925 Bytes)
Prosody_conf.txt (4.3 KB)


Nginx_domain.conf.txt (4.6 KB)
nginx.conf.txt (1.5 KB)

error_log_nginx.txt (10.1 KB)

Can you share jvb.conf also please.

if the nginx config is not valid for jvb websockets, errors are showing up as 404 codes in access.log, not in error.log files that are useless in this case.

Снимок экрана от 2021-10-31 12-13-12

Hi,
It seems you have an issue with your websocket proxy config.
In your nginx you’re doing a websocket proxy over http and in your jvb you have tls=true.
Try with tls=false because the connection between your nginx and the jvb is done with ws and not wss.

I have tls in the jvb.conf of my test server and websockets are working very well. I can tshark the dialog on the server and I see all the dialog in clear. I think that tls=true may inform the client that the dialog uses tls (what it does even if it is nginx that is providing the termination), but it does not force jvb to accept only tls traffic.
For the OP:
take a look at the access.log nginx files (or attach them), that’s where the interesting messages are.
you can use tshark (I have never found an incantation for use tcpdump on the local interface) as this on the server:
tshark -s 0 -w mywsfile -i lo port 9090
and if there are captured packets (wireshark display this information) grab the saved file and observe it on your workstation using wireshark (in this example, wireshark mywsfile)