The outgoing video channel becomes irreparable if xmpp-websocket is enabled and startVideoMuted is set

[emrahcom]

Description:

If xmpp-websocket is enabled and startVideoMuted is set by using a value less than the number of the active videos, the outgoing video stream becomes irreparable after a temporary network failure.

Steps to reproduce:

1. Deploy a Jitsi server with secure domain and enabled guest domain

• authentication is enabled in jicofo
• internal_hashed is the authentication method for prosody
• guest domain is enabled in prosody and in config.js

2. Set 2 as the value of startVideoMuted
3. Enable xmpp-websocket

• enable in config.js
• enable in prosody
• enable smacks module and set its parameters

smacks_max_unacked_stanzas = 5;
smacks_hibernation_time = 60;
smacks_max_hibernated_sessions = 1;
smacks_max_old_sessions = 1;

4. Join a meeting with 2 participants from a device (for example by using two browser tabs)
5. Join the same meeting from a second device (for example from a VM)
6. Enable camera for all participants (so we have 3 active videos but the value of startVideoMuted is 2)
7. Disconnect the network of the second device
8. Wait until getting the fourth Websocket closed unexcectedly message (this takes ~2 minutes in my setup)
   
9. Reconnect the network of the second device again
10. Enable camera again for this device (when the network is up again it becomes disabled because of startVideoMuted )

Expected behavior:

Getting the camera view of the second device in other participants' UIs

Actual behavior:

The second participant can get the camera views of other participants but the other participants cannot get the camera view of the second device.

Server information:

• Ubuntu 20.04
• prosody 0.12.4-1~focal1
• jicofo 1.0-1062-1
• jitsi-meet 2.0.9220-1
• jitsi-videobridge2 2.3-67-gb2d4229f-1
• jitsi-meet-* 1.0.7762-1
• lua5.2 5.2.4-1.1build3

Client information:

• Debian Bookworm 12.4
• Chromium 121.0.6167.139

Additional information:

• Looks like this issue related with When using websockets a client with a bad connection comes back without sound or video #14132
• I think the same issue exists for startAudioMuted too but not well tested
• When guest domain is disabled, I can't reproduce the same issue
• After reconnecting the network, the following messages in the browser console:
  
  
  

[emrahcom]

Now, I can reproduce the same issue without enabled guest domain too.

Step 8 is different for this case. Instead of waiting for the fourth message, I'm waiting for the third message. Otherwise the second device rejoins and reloads UI.

[bgrozev]

Can you include the xmpp logs (APP.conference.saveLogs()) from the device that reconnects?

[emrahcom]

Sure

meetlog.json

[bgrozev]

Initially the client sends a session-accept, then adds a video and an audio source with source-add. Then after the network impairment/recovery sends a restart request (the session-terminate message). It receives a new session-initiate and responds with session-accept with no sources. It doesn't add any with source-add either. So it hasn't advertised sources for the new session, which is why it isn't seen/heard.
@jallamsetty1 , any idea why this happens?

[jallamsetty1]

Not sure, the session-accept for the new session should have the sources info. @emrahcom, do you have the full browser console log by any chance?

[emrahcom]

Sure @jallamsetty1

This is the log of the participant who has a network issue:
jitsi.yourdomain.com-disconnected.log

This is the log of the participant with a stable network but cannot get the video of the first participant:
jitsi.yourdomain.com-observer.log

[jallamsetty1]

Thanks for the logs, I do see an issue with track addition after ICE restarts when startVideoMuted and startAudioMuted are set. I will work on a fix.

[emrahcom]

I can confirm that the issue is fixed by this commit and cannot be reproduced in jitsi-meet v9315.

Thank you 👍