jitsi / jitsi-meet

Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
https://jitsi.org/meet
Apache License 2.0
23.07k stars 6.7k forks source link

Losing video when 3rd participant enters #15178

Open mathieumd opened 1 week ago

mathieumd commented 1 week ago

What happened?

I freshly installed jitsi on a local Ubuntu VM, and while a 2 persons conference is working well, when a third person enters, all participants lose video (but audio and screen sharing both continue to work).

I saw there are lot of similar reports for video stop working with more than 2 participants, and most seems to be resolved by applying NAT configuration as documented. However this didn't fix my case.

And moreover, I have the exact same problem with meet.jit.si instance. Which makes me think that maybe the problem is not on my install setup?

Platform

Browser / app / sdk version

Chromium 129.0.6668.89 ; Firefox 131.0 ; Falkon 3.2.0 ; Fennec 129.0.2 (via F-Droid)

Relevant log output

This is the Chromium console log when the 3rd person enters room:

ChatRoom.js:675 2024-10-08T12:51:33.391Z [modules/xmpp/ChatRoom.js] <Lc.onPresence>:  entered bentimprisonmentsrecycleoverall@conference.meet.jit.si/5ad6b77f {isReplaceParticipant: 0, affiliation: 'owner', role: 'moderator', jid: '5ad6b77f-32b1-4c73-840a-3219ec3b8457@guest.meet.jit.si/aUpn-ie5lENL', isFocus: false, …}
JingleSessionPC.js:1189 2024-10-08T12:51:33.391Z [modules/xmpp/JingleSessionPC.js] <cl.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=9qisvih17cl0s] setVideoCodecs: codecList=vp9,vp8,h264, screenshareCodec=undefined
BridgeChannel.js:245 2024-10-08T12:51:33.412Z [modules/RTC/BridgeChannel.js] <Pl.sendReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"1ca8db3f-v0":{"maxHeight":360}},"defaultConstraints":{"maxHeight":0},"lastN":10,"onStageSources":[],"selectedSources":[]}
JingleSessionPC.js:1465 2024-10-08T12:51:33.414Z [modules/xmpp/JingleSessionPC.js] <cl.setReceiverVideoConstraint>:  JingleSessionPC[session=P2P,initiator=false,sid=a2d69c441b71] setReceiverVideoConstraint - constraints: {}
JingleSessionPC.js:1445 2024-10-08T12:51:33.416Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=P2P,initiator=false,sid=a2d69c441b71] sending content-modify for source-name: 1ca8db3f-v0, maxHeight: 360
subscriber.ts:141 2024-10-08T12:51:33.418Z [features/video-quality] <Object.listener>:  Video quality level for thumbnail height: 573, is: 360, override: false, max full res N: 1
subscriber.ts:141 2024-10-08T12:51:33.479Z [features/video-quality] <Object.listener>:  Video quality level for thumbnail height: 573, is: 360, override: false, max full res N: 1
conference.js:1505 2024-10-08T12:51:33.486Z [conference.js] <uo.<anonymous>>:  USER 5ad6b77f connected: os {_jid: 'bentimprisonmentsrecycleoverall@conference.meet.jit.si/5ad6b77f', _id: '5ad6b77f', _conference: $m, _displayName: 'Falkon', _supportsDTMF: false, …}
JitsiConference.js:3400 2024-10-08T12:51:33.486Z [JitsiConference.js] <$m._maybeStartOrStopP2P>:  Will stop P2P with: bentimprisonmentsrecycleoverall@conference.meet.jit.si/1ca8db3f
JitsiConference.js:3216 2024-10-08T12:51:33.487Z [JitsiConference.js] <__webpack_modules__.473.$m._resumeMediaTransferForJvbConnection>:  Resuming media transfer over the JVB connection...
TPCUtils.js:757 2024-10-08T12:51:33.487Z [modules/RTC/TPCUtils.js] <Yu.setMediaTransferActive>:  TPC[id=1,type=JVB] Resuming media transfer.
JitsiConference.js:3206 2024-10-08T12:51:33.487Z [JitsiConference.js] <__webpack_modules__.473.$m._removeRemoteTracks>:  Removing remote P2P track: RemoteTrack[userID: 1ca8db3f, type: video, ssrc: 3364097597, p2p: true, sourceName: 1ca8db3f-v0, status: {readyState: live, muted: false, enabled: true}]
JitsiConference.js:3206 2024-10-08T12:51:33.498Z [JitsiConference.js] <__webpack_modules__.473.$m._removeRemoteTracks>:  Removing remote P2P track: RemoteTrack[userID: 1ca8db3f, type: audio, ssrc: 2975301744, p2p: true, sourceName: 1ca8db3f-a0, status: {readyState: live, muted: false, enabled: true}]
JitsiConference.js:3515 2024-10-08T12:51:33.506Z [JitsiConference.js] <__webpack_modules__.473.$m._stopP2PSession>:  Stopping remote stats for P2P connection
JingleSessionPC.js:1617 2024-10-08T12:51:33.507Z [modules/xmpp/JingleSessionPC.js] <cl.terminate>:  JingleSessionPC[session=P2P,initiator=false,sid=a2d69c441b71] Sending session-terminate
JingleSessionPC.js:1642 2024-10-08T12:51:33.507Z [modules/xmpp/JingleSessionPC.js] <cl.onTerminated>:  JingleSessionPC[session=P2P,initiator=false,sid=a2d69c441b71] Session terminated undefined undefined
JitsiConference.js:3258 2024-10-08T12:51:33.508Z [JitsiConference.js] <__webpack_modules__.473.$m._setP2PStatus>:  Peer to peer connection closed!
JitsiConference.js:3001 2024-10-08T12:51:33.510Z [JitsiConference.js] <__webpack_modules__.473.$m._addRemoteTracks>:  Adding remote JVB track: RemoteTrack[userID: 1ca8db3f, type: video, ssrc: 3966744237, p2p: false, sourceName: 1ca8db3f-v0, status: {readyState: live, muted: true, enabled: true}]
TrackStreamingStatus.ts:239 2024-10-08T12:51:33.516Z [modules/connectivity/TrackStreamingStatus.ts] <new Uu>:  RtcMuteTimeout set to: 10000
JitsiConference.js:3001 2024-10-08T12:51:33.527Z [JitsiConference.js] <__webpack_modules__.473.$m._addRemoteTracks>:  Adding remote JVB track: RemoteTrack[userID: 1ca8db3f, type: audio, ssrc: 3619968289, p2p: false, sourceName: 1ca8db3f-a0, status: {readyState: live, muted: false, enabled: true}]
TraceablePeerConnection.js:1104 2024-10-08T12:51:33.564Z [modules/RTC/TraceablePeerConnection.js] <__webpack_modules__.473.ep._removeRemoteTrack>:  TPC[id=2,type=P2P] Removing remote track stream[id=1ca8db3f-video-0-1,trackId=40597089-996d-493c-9476-b6acf87f0431-1]
TraceablePeerConnection.js:1104 2024-10-08T12:51:33.564Z [modules/RTC/TraceablePeerConnection.js] <__webpack_modules__.473.ep._removeRemoteTrack>:  TPC[id=2,type=P2P] Removing remote track stream[id=1ca8db3f-audio-0-1,trackId=7305c23c-1671-4433-953b-eb8fc4c8ec64-1]
TraceablePeerConnection.js:2590 2024-10-08T12:51:33.564Z [modules/RTC/TraceablePeerConnection.js] <__webpack_modules__.473.ep.close>:  TPC[id=2,type=P2P] Closing peerconnection
JitsiConference.js:3219 2024-10-08T12:51:33.578Z [JitsiConference.js] Resumed media transfer over the JVB connection!
strophe.jingle.js:114 2024-10-08T12:51:33.689Z [modules/xmpp/strophe.jingle.js] <hl.onJingle>:  invalid session id: a2d69c441b71
r @ Logger.js:155
onJingle @ strophe.jingle.js:114
run @ strophe.umd.js:2507
(anonymous) @ strophe.umd.js:3843
(anonymous) @ strophe.umd.js:3840
forEachChild @ strophe.umd.js:1502
_dataRecv @ strophe.umd.js:3838
_onMessage @ strophe.umd.js:6187
(anonymous) @ strophe.umd.js:5920
Show 8 more frames
Show less

Reproducibility

More details?

jitsi-meet 2.0.9753-1

Enabling testing.p2pTestMode: true in /etc/jitsi/meet/$FQDN-config.js makes the video not working even with only 2 participants. (audio is good)

jallamsetty1 commented 1 week ago

@mathieumd Can you please share the full browser console log and webrtc-internals dump for the second participant when a third participant joins the call?

mathieumd commented 1 week ago

Looks like it's my LineageOS' Fennec which seems to be blocking something. By replacing it by another browser (I tried with DuckDuckGo Browser, but i guess any other would work too), a room with 3 participant still display the video. It must be some addon I added to Firefox. Sorry for the noise!

jallamsetty1 commented 1 week ago

Does the issue reproduce with Chrome?

mathieumd commented 1 week ago

The issue was clearly caused by my Fennec, but I don't know specifically by what. Disabling uBlock Origin did not change anything.

jallamsetty1 commented 1 week ago

For the failing case, does media between Chromium and Falkon work? Are these 2 users able to see and hear each other when Fennec user is in the call?

mathieumd commented 1 week ago

Yes:

lvreninfo commented 1 week ago

I can display normally by opening UDP port 10000

mathieumd commented 1 week ago

It's opened:

nc -vz -u webconf.example.com 10000
Connection to webconf.example.com 10000 port [udp/*] succeeded!

Moreover, I've got the same pb with official https://meet.jit.si/, so I guess it's not (not only? ;-)) a problem in my Jitsi setup, but more probably on my Fennec/LineageOS/Android.

lgrn commented 2 days ago

Fennec claims to have "improved tracking protection", it's quite possible that it has disabled certain browser settings out of the box that breaks this. I've seen similar issues with LibreWolf which is also a "hardened" Firefox, so I'd recommend establishing that video calls in the browser work at all before looking further into whether it's Jitsi.

From your description it sounds like p2p actually works (since Falkon + Fennec has bi-directional video), but that Fennec breaks when moving away from p2p. You can verify this by disabling p2p on the server side, trying Falkon + Fennec again and see if it breaks.

If it does, at least you know it's likely caused by how Fennec attempts to communicate with the JVB on the server, so you could check the logs server-side and dig around for any clues.

I've never used Fennec so I don't know if it gives you access to the about:config page, but one place to start looking could be the media.peerconnection settings mentioned at https://wiki.mozilla.org/Media/WebRTC/Privacy -- for example, it's possible that default_address_only, relay_only etc. do not correspond to the defaults stated in the wiki in Fennec.

mathieumd commented 2 days ago

Yes, I tried with testing.p2pTestMode: true and video did not work at all, so you are probably right.

AFAIK, Fennec is just a Firefox compiled by F-Droid. But I still checked all the media.peerconnection.* settings from Mozilla's page, and they are all the same in Fennec. It looks like F-Droid don't change much preferences (looking for pref(", there are only 4 entries).

But anyway, there is surely something! :-)

jallamsetty1 commented 2 days ago

Can you share the full browser console log from Fennec browser? If it is related to DTLS 1.3 changes in Firefox, we may see that the ICE connection never gets established.