jitsi-meet icon indicating copy to clipboard operation
jitsi-meet copied to clipboard

Losing video when 3rd participant enters

Open mathieumd opened this issue 1 year ago • 11 comments

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

  • [X] Chrome (or Chromium based)
  • [X] Firefox
  • [ ] Safari
  • [ ] Other desktop browser
  • [X] Android browser
  • [ ] iOS browser
  • [ ] Electron app
  • [ ] Android mobile app
  • [ ] iOS mobile app
  • [ ] Custom app using a mobile SDK

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 [email protected]/5ad6b77f {isReplaceParticipant: 0, affiliation: 'owner', role: 'moderator', jid: '[email protected]/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: '[email protected]/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: [email protected]/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

  • [X] The problem is reproducible on meet.jit.si

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)

mathieumd avatar Oct 08 '24 12:10 mathieumd

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

jallamsetty1 avatar Oct 08 '24 13:10 jallamsetty1

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!

mathieumd avatar Oct 08 '24 13:10 mathieumd

Does the issue reproduce with Chrome?

jallamsetty1 avatar Oct 08 '24 14:10 jallamsetty1

  • Working with more than 2 clients: DuckDuckGo (LineageOS) + Chromium (Ubuntu) + Falkon (Ubuntu)
  • Failing with more than 2 clients: Fennec (LineageOS) + Chromium (Ubuntu) + Falkon (Ubuntu)

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

mathieumd avatar Oct 08 '24 14:10 mathieumd

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?

jallamsetty1 avatar Oct 08 '24 16:10 jallamsetty1

Yes:

  • Falkon(Ubuntu) + Fennec(LineageOS): Both see each other video;
  • Chromium(Ubuntu) + Fennec: Idem;
  • Falkon + Chromium: Idem;
  • Falkon + Chromium + Fennec, both Falkon and Chromium continue to see each other, but they lost Fennec video. Fennec is actually seeing all 3 videos.

mathieumd avatar Oct 10 '24 07:10 mathieumd

I can display normally by opening UDP port 10000

lvreninfo avatar Oct 10 '24 08:10 lvreninfo

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.

mathieumd avatar Oct 10 '24 08:10 mathieumd

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.

lgrn avatar Oct 17 '24 11:10 lgrn

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! :-)

mathieumd avatar Oct 17 '24 13:10 mathieumd

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.

jallamsetty1 avatar Oct 17 '24 13:10 jallamsetty1

@jallamsetty1 Do you know how to get the console log from Fennec? AFAIK, it's not available in Android versions of Firefox.

mathieumd avatar Oct 21 '24 08:10 mathieumd

I am not sure, maybe @saghul does?

jallamsetty1 avatar Oct 24 '24 15:10 jallamsetty1

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Dec 24 '24 02:12 github-actions[bot]