Multiple Problems with Video and/or Audio Not Working in Calls on via browser

Hi Jitsi team,

We’ve got a community of people using Jitsi to match up for calls and sessions, within the last few weeks users have had increasing problems using for these connections.

Everything from dropped connections, to video and audio not working on one side or the other, sometimes both sides.

My question is, has anything significant changed in the last couple weeks that would generate these types of issues using

These are often users who have had no problems or much fewer problems using the video sessions before now and it’s not clear yet if there’s a pattern to what is causing the issue.

Are you receiving other reports like this, I don’t seem to see much in the forums here about issues.

I’m wondering if variables we are passing in a url are part of the problem have or if there’s just an increase of usage that’s making the connections problematic.

I’d be interested if you have any insight into what might potentially be the issue here. We’ve got users on Mac and Windows, Firefox and Chrome, some mobile users as well but I haven’t heard any reports of issues with Mobile yet.

Sometimes it seems reloading helps, other times it doesn’t.

Any insight you might have into this issue, I know that I’m providing just general information at the moment but if there’s more I could do to provide helpful info for troubleshooting please let me know.

I will look at the chrome://webrtc-internals to try to investigate more as well, based on some info that was shared in another thread too.

Thanks for your help

@saghul Interested in your thoughts on this if possible, thanks!

Hi Natahn,

Thanks for taking the time to provide feedback, and sorry you’re running into trouble. Let’s see if there is anything I can do to help.

Dropped connections are hard to avoid, but we are actively working on being more relisient to those, in addition to improving the UX when it happens. Can you elaborate a bit on the audio / video not working on one side? What media types were people using? Was there screen-sharing involved?

We recently discovered a bug in Octo and disabled it. This might have had an impact if you have participants in multiple regions, is this your case?

We are aware of another issue that may have affected you, if you were using screen-sharing: it may cause audio degradation, because of a bug in our bandwidth allocation mechanism, this is also being worked on at the moment.

We are not receiving these kind of reports lately, but that doesn’t mean we are problem free :slight_smile:

What URL parameters are you passing? Regarding usage, while we do see growth, I don’t think it can explain what you are experiencing.

In this scenario there are 2 actors that may contribute to a subpar experience for the receiver: Firefox and Android devices. We don’t yet support simulcast on either of those (it’s coming to Android soon) so this means they’ll be sending 720p all the time, and there is nothing we can do about it on the server side.

@saghul Thank you for the detailed reply! I’ll post some replies below and I have also sent you a DM to follow up with some private details.

Mainly we are doing 1 on 1 video sessions, no screensharing or additional group members involved. Various problems happen and it’s not consistent across users, I will try to document those specifically and share more details but essentially people who have had no problems in the past suddenly have issues with getting the camera/audio to work and I’ve also troubleshooted with them so it’s not specifically user error or permissions problems because even resetting them doesn’t resolve the issue.

Reloading often helps when dropped connections happen, I think this points to an issue with reconnecting after a drop on p2p connections specifically, not sure about JVB. I think I read something where others were having a similar problem in this scenario.

Definitely sounds like this would affect us, a huge percentage of sessions involve participants in multiple regions. Is this live on now?

Here’s one set of variables we’ve used, I was worried maybe something there was causing our issues or not helping the situation at least…

I know a lot of this was added to try and combat some issue people had reported in the past, there’s a % of user who find that Jitsi takes up too much resource wise on their systems and since the purpose of our sessions are to get work done, it becomes a real challenge. Anything we can do to limit the resource use we are trying. It seems in P2P sessions none of the url variables seem to be respected though so we have to direct people to manage call quality manually but still some people have too much resource usage.

This definitely seems like it would be a factor, some people in our community have switched to Firefox and mobile to try and deal with the resource usage problem or the connection issues they were having in Chrome.

Thanks again for your detailed replies, I really appreciate it!

Let me know if there’s anything else I can provide to get more insight. I also sent you a DM with some additional private info.

Yes please document those and let us know. Knowing the involvied devices is also important: we don’t support P2P mode on Firefox, so traffic will needlessly go through the bridge even in 1-1 calls, for example. should be working ok now, in this regard.

Those options should be harmless. The “Manage Call Quality” options won’t apply to P2P calls, but the URL parameters should.