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

[emrahcom]

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

[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 👍

[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

[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?