jitsi-meet
jitsi-meet copied to clipboard
Audio/Video problem after leaving and rejoining
Description:
The problem occurs in settings with 3 users. Initial start works with no problem. Everybody can see and hear each other. So if one of the participants leaves and rejoins the call, one of the participants can't see and hear the rejoined user. After disabling p2p connections the problem disapears.
Steps to reproduce:
- Start a video call with 3 participants
- One of them leaves the call and rejoins
- One of the remained participants can't hear and see the rejoined user
Expected behavior:
All users can see and hear each other after rejoining
Actual behavior:
The user who rejoined can hear and see only one other participiant The second user can't see the rejoined participiant. Mic symbol shows the rejoined mic is off.
Server information:
- Jitsi Meet version:
- Operating System: Ubuntu 20.04
- Jitsi: Mainserver: jitsi-meet 2.0.6826-1, Videobridges: jitsi-videobridge2 2.1-607-g1537e4e-1
Client information:
- Browser / app version: Microsoft Edge 97.0.1072.62 / Rocket.Chat 3.7.5
- Operating System: Windows 10
Additional information:
After disabling p2p in jitsi-meet config (/etc/jitsi/meet/<
Thank you, can you collect js console logs from a problem session?
I just ran into this same issue as well, I'll collect logs if it happens again.
3 users, at any given time, one of us could not hear one other user. It seemed to change depending on who last join/rejoined. At first it was user A could not hear user B. User C could hear both. When user C left and rejoined, they could hear user A but not B. A and B could now hear each other. User C and B both had cameras on and there was no issue with that. User A had their camera off the whole time.
I think this is the same as https://github.com/jitsi/jitsi-meet/issues/10826
Hi @damencho , I see the same issue on the lastest stable version (v6865). We can reproduce this issue on meet.jit.si with this scenario :
All users in Chrome (or Chromium based browser).
- User A create the room
- User B arrived in the room and the media are connected in P2P.
- User C arrived and media switch to Videobridge.
- User B leave
- Wating user A and user C switch to P2P media
- User D arrived ===> User A don't see User C | user C see A and D | D see C and A. In the user A the stream from C is mark as muted.
It seems to be an issue in the switch between P2P and jvb media, does it ?
Regards, Damien
Hello @daimoc, Thanks a lot for the steps to reproduce. I tried it a couple of times to replicate the problem with your steps. But the only issue I ran into a couple of times is that after user D joins user A sees C and D as inactive with no video for some time. After a few seconds both switch from inactive to good and their videos start to render. My guess is that the bandwidth estimator is not happy after switching to the bridge again and needs some time to adjust.
I'm wondering if I'm missing something here. I'm testing all from different tabs on the same browser. User B using the hangup button or just closing the window doesn't seem to make a difference.
This is happening A LOT currently. =/
Hi @nils-ohlmeier , Thank you for your tests. It's strange that you're not able to reproduce it because it happens every time when I test it even in a local deployment based on last stable (v6865). But I notice a recent patch in lib-jitsi-meet about some issue on m-lines recycling (https://github.com/jitsi/lib-jitsi-meet/commit/f881b3c745016c045162f9a608ed22d4ac307ecf) . After applying it my local jitsi-meet environment based on v6865 my p2p issues are gone. It seems to be related (or it's a pure coincidence......).
If someone like @aDwCarrazzone still experiencing this rejoin issue you can test unstable version witch includes the m-lines patch or wait for the next stable release.
We have this problem. server is ubuntu 22.04, jitsi meet 2.0.9111-1 clients chrome 120 windows or chromium 120 ubuntu. p2pTestMode: true helps
Looks like like if we use firefox 120, then there is no such problem...
btw, I don't think it is 10826 related, we had only audio problem, video always works.
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.