search

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.09k stars 6.71k forks source link

Sometimes participants can't hear other participants #5230

Closed jonnius closed 3 years ago

jonnius commented 4 years ago

Description

Sometimes some participants can't hear some other participants. Some findings:

Current behavior

There is an audio-only meeting with n>7 participants. Some participants cannot hear all other participants, e.g. participant 4 cannot hear participant 3 and 7.

Expected Behavior

Every participant can hear every other participant.

Possible Solution

Steps to reproduce

Start a Jitis Meeting with as many users as possible, only enable Audio and try to speak to each other.

Environment details

Version: jitsi-meet v1.0.4101-1 Browsers tested: Chrome, Firefox on Win10 and Ubuntu 16.04

rettichschnidi commented 4 years ago

Pretty sure this is related to #4758

Also, other users (including me) have the same problem:

damencho commented 4 years ago

Is Firefox involved?

rettichschnidi commented 4 years ago

Yes We could test again without Firefox, but it is very unlikely that we can get all our users to not use Firefox.

damencho commented 4 years ago

We are working on improving Firefox experience, but that is for now. Firefox sometimes does not send or receive any streams ... and leads to problems. That's why we put a notification when you are on Firefox and using meet.jit.si, to warn people.

jonnius commented 4 years ago

We experienced the issues also on Chrome.

We just updated to jitsi-meet v1.0.4296-1 and disabled Peer-to-Peer connections. On a test with 10 participants the issue did not occur on Chrome any more. On a test with everyone on Firefox 1 out of 10 could not hear some others.

damencho commented 4 years ago

We will update very soon stable.

Jasper-Ben commented 4 years ago

We are experiencing the same issue with 9 people in the same room, even between users using chromium-based browsers. We also tried to connect with all participants using said browsers (which I'm 90% sure we archived) and issues still persists. So maybe not just a firefox issue?

jonnius commented 4 years ago

We did as well before updating. Which version are you using?

Jasper-Ben commented 4 years ago

the latest jitsi-meet package currently available from jitsis debian repository: jitsi-meet/stable,now 1.0.4101-1

It used to work when microphone and cam where enabled by default when joining a room during our testing phase. But since we disabled that in the jitsi server settings it is completely unreliable. So for me it seems the issue is related to the (lack of) video or audio streaming. Out of privacy concerns I am unfortunately unable to reactivate said settings to see if it makes any difference, as 20+ users in our company now expect it to be disabled by default.

Also I was able to reproduce the issue in a two-participants room (although one was using firefox), so this issue does not seem to be bound to the number of users in a room as suggested in the initial report. There might have been users in other rooms at that time though, so it might be a question of how many users are connected in general, regardless of room. The two of us then switched to my private jitsi instance without disabled devices by default and it worked as expected.

jonnius commented 4 years ago

You are using the very same version we experienced this issue a lot with. After updating to the 4296 build we did not see this issue on Chrome any more. We also have mic and cam disable by default.

Jasper-Ben commented 4 years ago

thanks for the info! will try the nightly branch then and install the same version. I will report back, if we continue to experience issues.

jonnius commented 4 years ago

We just had a meeting with 11 participants, all on Chrome, where one participant could not be heard by some others. Reloading the page for the one fixed it. Build: 4296

saghul commented 4 years ago

Thanks for chiming in @jonnius !

Jasper-Ben commented 4 years ago

We just had a test meeting with 20 participants (all on chromium) and it worked flawlessly. Also build 4296. Seems to be fixed :+1:

Jasper-Ben commented 4 years ago

P.S.: we actually had one minor issue with a participant using Vivaldi. After he switched to chrome it worked as expected. We didn't investigate further but my guess would be that Vivaldi might use an old chromium base. Just something to be aware of.

Isolator70 commented 4 years ago

Hello, using Jitsi sporadically, but due to Corona crisis now more often. Today I had a 2 person call between Chromium@LinuxMint_18.3_PC and Jitsi App@Android. Everything fully up-to-date. After some minutes it was not possible anymore for the Person at Android to hear the Person from the PC. At the PC one could observe, that the microphone indicator did not react to volume put into the microphone. Going to the settings of Jitsi in Chromium browser one could see "Permission not granted" for the audio stuff (although it was done and checked at the beginning of the meeting). Checking the audio permission in Chromium itself, camera and audio stuff was enabled. After closing and restarting the meeting everything was fine again, but broke down some minutes later again. Do you think it is the same issue or shall I create another ticket? Thank you

Isolator70 commented 4 years ago

Okay, I have to add following information: Today I was in a 35 minutes video call with up to 17 participants, most of them without activated camera, 5 with camera activated. I'm sure most of them were on Windows machines, 1 maybe on Mac, 1 with iPhone, 1 with Android, From my point of view, everything ran perfect - I couldn't see the issue of yesterday again! So I will observe the behaviour if it is random.

keinstein commented 4 years ago

Hi, on March 27th, we had a meeting with 3 people on meet.jit.si (I don't know which version they run). All using web browsers and we had the problem that the 3rd person connected but did not receive any audio or video. After he managed to setup his audio and video settings, person 1 could hear both 2 and 3, 2 could hear only 1, 3 only 2. So every one was streaming something to someone. But somehow the streams stopped working.

real-or-random commented 4 years ago

We observed this today in 3-person call on 4384. A Jigasi/SIP peer couldn't hear an electron peer. Everything else worked. "Restarting" the stream by changing the microphone device on electron and changing back fixed this.

thomaswucher commented 4 years ago

We also observed this problem today on a self-hosted instance using the latest official docker images and the master branch of docker-jitsi-meet (0177765f) in a conference with 5 participants.

All participants were using Firefox. The ones which had video enabled didn't experience the problem, those with audio only could sometimes not hear all other participants. For those experiencing problems, reconnecting sometimes helped.

Jasper-Ben commented 4 years ago

All participants were using Firefox.

Hi Thomas, as things stand right now I'd suggest you enforce a policy of chromium based browsers only, as issues with Firefox are still being resolved. And although the related issue https://github.com/jitsi/jitsi-meet/issues/4758 is marked as resolved, this to my understanding only fixes any issues on the jitsi side of things. There are still open upstream issues in Firefox (linked at the bottom of the thread).

We enforce our chromium only policy by changing the following in the interface_config.js:

OPTIMAL_BROWSERS: [ 'chrome', 'chromium', 'nwjs', 'electron' ],
UNSUPPORTED_BROWSERS: ['firefox','safari'],

This causes users trying to open jitsi with a Firefox or Safari Browser to be prompted to install the latest Google Chrome. For anyone who doesn't want to use Chrome out of privacy concerns we recommend using Chromium or Brave, as they are both open-source and (for the most part) do not include the Google tracking stuff.

jonnius commented 4 years ago

Things should improve with Firefox 76.

btsimonh commented 4 years ago

I'm currently investigating a problem with jitsi which sounds very much like this and previous descriptions.

We had 3 people on the call, All Chrome 81.0.4044.129 on windows 10 64 bit using embedded jitsi from 'https://meet.jit.si/external_api.js'. - So this may highlight that it's not a firefox only issue, and hopefully may provide some more pointers.... Certainly the 'unheard' person was sending audio, because they were heard by another, yet not heard by the third person. The 'unheard' person could hear the person who could not hear them.... The person who could not hear them could hear the other person.

Prior to integrating, we tested 7-10 calls using meet.jit.si for bulk family calls (always with video?), and apart from once on MAC which didn't screenshare whatever we did (it had previously), we had no (apparent) problems.

I find this in the browser log as a yellow: Logger.js:154 2020-05-04T15:56:33.440Z [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant 02b26f22, local audio levels: [null,null], remote audio levels: undefined

If I separately join the room using meet.jit.si/roomname, then I too could hear the person, but not through the embedded version (could i just have been lucky?). But this was not an extensive test (3 times, it worked).

I start all the instances like this: (i.e. video muted; which could be related/ these ones because they mess with my audio mojo (i.e. I'm also recording quality audio from the mic, and these seem to mess with Chrome's global mic gain). enableNoisyMicDetection:false, - I don't need or want the 'pip-pip-pip' indication by audio... enableNoAudioDetection:false, enableTalkWhileMuted:false, disableAudioLevels: true, )

            let config = {
              enableNoisyMicDetection:false,
              enableNoAudioDetection:false,
              enableTalkWhileMuted:false,
              disableAudioLevels: true,

              // whole room by creator?
              //startAudioOnly:true,
              startWithAudioMuted: true,
              // only this person
              startWithVideoMuted: true,
              enableCalendarIntegration: false,
              disableThirdPartyRequests: true,
              disableRecordAudioNotification: true,
              //testing:{
                //noAutoPlayVideo:true,
              //},
              //chromeExtensionBanner: {},
              disableInviteFunctions: true,
              disableRemoteMute: true,
            };

            let interfaceConfig = {
              DISPLAY_WELCOME_PAGE_CONTENT: false,
              MOBILE_APP_PROMO: false,

            };

            this.jitsi_api = new JitsiMeetExternalAPI('meet.jit.si', {
              parentNode: this.$refs['putithere'],
              roomName: this.settings.roomName,
              configOverwrite: config,
              interfaceConfigOverwrite: interfaceConfig,
            });

it's important I work around this in the very short term; any ideas?

Simon

Jasper-Ben commented 4 years ago

video muted; which could be related/

In my experience the issue described here only occurs when disabling audio on entering the room. So changing startWithAudioMuted: true, to startWithAudioMuted: false, might be a short term workaround?

Other than that, I cannot really help as I am unfamiliar with the api.

btsimonh commented 4 years ago

something else; watch out for The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu I think this prevented one of my jitsi clients from starting audio?

tomkel commented 4 years ago

I still have this bug in rel 4548. In a call with ~15 people

luixxiul commented 4 years ago

I still have this bug in rel 4548. In a call with ~15 people

As this issue has been closed and the thing has been changed since then, there is actually nothing actionable here. You are expected to open a new issue, with steps to reproduce the error, server / client information, etc.

dandv commented 4 years ago

DISPLAY_WELCOME_PAGE_CONTENT: false,

@btsimonh, I see you've configured DISPLAY_WELCOME_PAGE_CONTENT. Have you figured out what it does?

tomkel commented 4 years ago

@luixxiul That's easier said than done, it's an intermittent issue and it usually takes 10-15 clients before the issue starts happening. What kind of logs are needed and how do I get them?

btsimonh commented 4 years ago

@dandv - no. I just scanned the code for all possible configurations, and threw in random ones :). @tomkel - I regularly have sessions with 3-4 clients where one client can't hear another, but others can hear them. It seems like a very complex issue, and probably multiple subtle issues. I'd love to have it happen when I have easy access to the clients in question, so I could try to diagnose, but it's rather difficult. My application is a simple audio only intercom, and it fails regularly enough for me to be moving away from JitSi to a much simpler audio intercom over websockets with dedicated self-hosted servers. This also saves me a load of CPU, but costs me a load of dev time :(. I may retain JitSi, but only as a link to be used when screenshare is useful (it's a collaborative app, where some need help setting up).

Nicramus commented 4 years ago

something else; watch out for The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu I think this prevented one of my jitsi clients from starting audio?

good point - in my case that was the problem

loelkes commented 3 years ago

I still have this issue with the most recent release. Can someone point out what qualifies as "user gesture"? Must the page be reloaded after a user gesture?

damencho commented 3 years ago

Using pre-join page and there shouldn't be a problem. It needs a gesture or webrtc session before playing it is how Google changed it ... not sure about FF though.

arianox commented 3 years ago

We have had the problem since the last release too. But very strange as it only occurs sometimes.

damencho commented 3 years ago

What is the browser and version you experience the problem with?

arianox commented 3 years ago

What is the browser and version you experience the problem with?

damencho commented 3 years ago

It would be helpful if you can get the js console logs from a participant that is not hearing someone, but also note which participant is not heard (by checking its participant id from the extended local sstats) image

And note is the participant not hearing from the beginning of the session or stopped hearing at some point...

arianox commented 3 years ago

The problem is from the beginning. We can see following log:

Logger.js:154 2021-05-10T08:40:53.031Z [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant b68cda91, local audio levels: [null,null], remote audio levels: undefined o @ Logger.js:154 (anonym) @ AudioOutputProblemDetector.js:122 _onLocalAudioLevelsReport @ AudioOutputProblemDetector.js:111 a.emit @ events.js:157 m._processAndEmitReport @ RTPStatsCollector.js:877 m.processStatsReport @ RTPStatsCollector.js:735 (anonym) @ RTPStatsCollector.js:386 Logger.js:154 2021-05-10T08:40:53.031Z [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant fa1bfcd8, local audio levels: [null,null], remote audio levels: undefined o @ Logger.js:154 (anonym) @ AudioOutputProblemDetector.js:122 _onLocalAudioLevelsReport @ AudioOutputProblemDetector.js:111 a.emit @ events.js:157 m._processAndEmitReport @ RTPStatsCollector.js:877 m.processStatsReport @ RTPStatsCollector.js:735 (anonym) @ RTPStatsCollector.js:386 Logger.js:154 2021-05-10T08:40:53.031Z [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant 17de70e2, local audio levels: [null,null], remote audio levels: undefined o @ Logger.js:154 (anonym) @ AudioOutputProblemDetector.js:122 _onLocalAudioLevelsReport @ AudioOutputProblemDetector.js:111 a.emit @ events.js:157 m._processAndEmitReport @ RTPStatsCollector.js:877 m.processStatsReport @ RTPStatsCollector.js:735 (anonym) @ RTPStatsCollector.js:386 Logger.js:154 2021-05-10T08:40:54.268Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 17de70e2,3a127420 Logger.js:154 2021-05-10T08:40:54.629Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 17de70e2 Logger.js:154 2021-05-10T08:40:54.997Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 3a127420 Logger.js:154 2021-05-10T08:40:55.622Z [modules/UI/videolayout/LargeVideoManager.js] hover in 17de70e2 Logger.js:154 2021-05-10T08:40:59.566Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 17de70e2 Logger.js:154 2021-05-10T08:40:59.588Z [modules/UI/videolayout/LargeVideoManager.js] hover in 17de70e2 Logger.js:154 2021-05-10T08:40:59.597Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 3a127420 Logger.js:154 2021-05-10T08:40:59.902Z [modules/UI/videolayout/LargeVideoManager.js] hover in 17de70e2 Logger.js:154 2021-05-10T08:41:00.632Z [modules/xmpp/strophe.jingle.js] <g.onJingle>: on jingle source-add from klasse1d@muc.meet.jitsi/focus <iq xmlns=​"jabber:​client" to=​08fcf344-4b5d-4052-9f1c-d8c890b7caad@guest.meet.jitsi/​_AowwNJ8 type=​"set" from=​klasse1d@muc.meet.jitsi/​focus id=​"MDhmY2YzNDQtNGI1ZC00MDUyLTlmMWMtZDhjODkwYjdjYWFkQGd1ZXN0Lm1lZXQuaml0c2kvX0Fvd3dOSjgAajY2bGwtOTY3MzI0AH0woAvbu4tWGr+r3rCiV8U=">​…​​ Logger.js:154 2021-05-10T08:41:00.639Z [modules/xmpp/JingleSessionPC.js] Processing addRemoteStream Logger.js:154 2021-05-10T08:41:00.639Z [modules/xmpp/JingleSessionPC.js] ICE connection state: connected Logger.js:154 2021-05-10T08:41:00.651Z [modules/RTC/TraceablePeerConnection.js] <A._remoteTrackAdded>: TPC[1,p2p:false] remote track added: ff49ce28-7dd9-40a5-9d56-744ea4ec206f-3 audio Logger.js:154 2021-05-10T08:41:00.652Z [modules/RTC/TraceablePeerConnection.js] <A._remoteTrackAdded>: TPC[1,p2p:false] associated ssrc 2826541f 2567393685 Logger.js:154 2021-05-10T08:41:00.672Z [modules/xmpp/SdpConsistency.js] <o.makeVideoPrimarySsrcsConsistent>: TPC[1,p2p:false] sdp-consistency replacing new ssrc123536166 with cached 123536166 Logger.js:154 2021-05-10T08:41:00.683Z [modules/xmpp/JingleSessionPC.js] addRemoteStream - OK, SDPs: s {media: Array(2), raw: "v=0 ↵o=- 2851163778622828160 2 IN IP4 127.0.0.1 ↵s…p:SIM 123536166 12550179 4024355335 ↵a=rtcp-mux ↵", session: "v=0 ↵o=- 2851163778622828160 2 IN IP4 127.0.0.1 ↵s…7-ab88-71d21305c3bb ↵a=group:BUNDLE audio video ↵"} s {media: Array(2), raw: "v=0 ↵o=- 2851163778622828160 3 IN IP4 127.0.0.1 ↵s…p:SIM 123536166 12550179 4024355335 ↵a=rtcp-mux ↵", session: "v=0 ↵o=- 2851163778622828160 3 IN IP4 127.0.0.1 ↵s…7-ab88-71d21305c3bb ↵a=group:BUNDLE audio video ↵"} Logger.js:154 2021-05-10T08:41:00.684Z [modules/xmpp/JingleSessionPC.js] <C.notifyMySSRCUpdate>: removal not necessary Logger.js:154 2021-05-10T08:41:00.685Z [modules/xmpp/JingleSessionPC.js] <C.notifyMySSRCUpdate>: addition not necessary Logger.js:154 2021-05-10T08:41:02.295Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 770d7f89,17de70e2 Logger.js:154 2021-05-10T08:41:02.312Z [modules/UI/videolayout/LargeVideoManager.js] hover in 17de70e2 Logger.js:154 2021-05-10T08:41:02.520Z [modules/RTC/BridgeChannel.js] <p.sendSelectedEndpointsMessage>: Sending selected endpoints: 08fcf344,17de70e2,3a127420,770d7f89,fa1bfcd8,b68cda91,2826541f,b360a939,3b95f36c. Logger.js:154 2021-05-10T08:41:02.526Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 2826541f Logger.js:154 2021-05-10T08:41:02.921Z [modules/UI/videolayout/LargeVideoManager.js] hover in 2826541f Logger.js:154 2021-05-10T08:41:03.594Z [modules/RTC/BridgeChannel.js] : New forwarded endpoints: 17de70e2 Logger.js:154 2021-05-10T08:41:03.602Z [modules/UI/videolayout/LargeVideoManager.js] hover in 2826541f

damencho commented 3 years ago

For this log, do you know the participant id, that was not heard?

jallamsetty1 commented 3 years ago

@arianox, Can you please share the full log if possible ? The logs attached in your last comment do not show anything wrong with the source addition. You can ignore the warning from AudioOutputProblemDetector, they are misleading and do not indicate a real problem with remote audio.

arianox commented 3 years ago

@jallamsetty1 OK. I will try to get the data at the next conference.

jallamsetty1 commented 3 years ago

@jallamsetty1 OK. I will try to get the data at the next conference.

Thank you, can you please make a note of the endpointId for the user that wasn't heard ? You can find this information on the connection stats on the thumbnail for the remote participant.

ssb22 commented 3 years ago

We had this problem this morning on a 3-way conversation where A could hear only C but B and C could hear each of the other two. The issue persisted over two separate sessions of the same meeting room.

Participant A was using Safari on an iPhone SE from 2016 running iOS 14 with all updates accepted. Jitsi app was not installed because the phone was getting full, so Safari was used. Cameras were off as participants were blind (it's risky to turn on a camera when you can't see what it's pointing at).

Ark74 commented 3 years ago

I've seen that with firefox if you are the first on the room you don't have issues.

If you are 2nd or later and last, then you'll have sound issues. If you are 2nd or later, you'll have issues 'til another user join the room, that kind of triggers sound discovery.

ssb22 commented 3 years ago

Well one of the things we tried was to have participant B leave the meeting and re-join, but this did not trigger participant A's Safari to work any better.

jallamsetty1 commented 3 years ago

The audio issues with Safari and Firefox have already been fixed and will be deployed to meet.jit.si early this week.

jamesbrooks commented 3 years ago

The audio issues with Safari and Firefox have already been fixed and will be deployed to meet.jit.si early this week.

Awesome! Looking forward to seeing this fix merged in :)

jallamsetty1 commented 3 years ago

The audio issues with Safari and Firefox have already been fixed and will be deployed to meet.jit.si early this week.

Awesome! Looking forward to seeing this fix merged in :)

The fix has been deployed on meet.jit.si already. Please give it a try and let me know if it fixes your issue, thanks!

domrim commented 3 years ago

@jallamsetty1 we have the same issues as everyone else here. Is this fix allready present in jitsi/stable? or better: which commit fixed the issue?

loelkes commented 3 years ago

Hi Dominik ;)

@jallamsetty1 we have the same issues as everyone else here. Is this fix allready present in jitsi/stable? or better: which commit fixed the issue?

Check your JavaScript console logs on the clients facing the audio issues. If there are AudioContext errors than try enabling the pre-join page. If the browser enforces the requirement for an user gesture before accessing the AudioContext it seems there's no way around the pre-join page. It seems a bit random how strictly browser implement this.

Enabling the Pre-Join page solved an incredible amount of issues related to audio on all my setups.