100% support for Firefox (and other non-Chrome browsers)

jans23 commented 5 years ago

I'm using Jitsi Meet (The public service hosted at https://meet.jit.si/) for two years now and in my experience it doesn't work reliably with Firefox. I even think as soon as one of the conference members uses Firefox, sooner or later the conference will experience some audio or video issues. Consequently we can't use Jitsi Meet well for a wider/external audience because we can't demand them to use Chrome.

The actual issues experienced range from voice and video drop outs, to connectivity issues (poor connectivity or connection lost). As soon as the Firefox members leaves, the issues stop appearing. Because these issues are so blur I can't provide any details at the moment. Therefore I have the general question, if you plan to support Firefox 100%? If I should provide more technical details about the issues, where can I find description how to gather those details?

damencho commented 5 years ago

Sorry for the late answer. The situation is that we haven't added simulcast support to Firefox and if you have several people with Firefox in a conference they will significantly increase traffic to every participant which can cause issues like CPU spikes, like a problem with filling up the available download bandwidth for user ... We have and a known issue with Firefox which is not addressed, but the good news is that we will soon start working on better Firefox support, so stay tuned for the time being using chrome is the best option out there for the moment.

MatthieuPERIN commented 4 years ago

Several attempts to use internal Jitsi instance with Firefox 71.0 (64 bits) windows client have bring some issues :

Lack of sound (work fine within Chrome) for my client
No microphone detected (the other participant)

If needed, I can provide any dump/config needed.

Have a great day 👍 (and please bring 100% support for Firefox 😄 )

damencho commented 4 years ago

@jallamsetty1 Is currently working on it :) Cheers.

Mte90 commented 4 years ago

Just saw this yesterday :-(

Looking on bugzilla there are 2 tickets like https://bugzilla.mozilla.org/show_bug.cgi?id=1600698 that need to fixed or also https://bugzilla.mozilla.org/show_bug.cgi?id=1468700

mirh commented 4 years ago

Also https://bugzilla.mozilla.org/show_bug.cgi?id=1210175 ?

mestaritonttu commented 4 years ago

Is this FF issue also still a blocker: https://bugzilla.mozilla.org/show_bug.cgi?id=1164187 ?

mimi89999 commented 4 years ago

Hello, Two days ago I tried Jitsi Meet with 3 other people. Three of us were using Firefox. During the meeting there were constantly issues with one participant not being able to hear another one. The meeting ended quickly and they said that they will never use Jitsi Meet again.

If this is an issue with Firefox, I think that Jitsi Meet should show a bigger warning (the small one is just clicked through without being read) or even completely block Firefox users. For people not wanting to use Chrome nor Chromium, an Electron app could be easily offered.

aiomaster commented 4 years ago

I agree this should be fixed, cause people think jitsi meet is buggy. Just to be fair: There is an electron app: https://github.com/jitsi/jitsi-meet-electron Last official release is from 2018, but it seems to be developed and it is working, at least for me.

J0WI commented 4 years ago

If this is an issue with Firefox, I think that Jitsi Meet should show a bigger warning (the small one is just clicked through without being read) or even completely block Firefox users.

Please do not block clients based on their user agent string. Clients should rather be tested for available features to provide the best experience for all. Custom Add-ons, privacy settings, unstable branches or even network issues (IPv4/6, NAT) can all affect the behavior of a client and it's not possible to detect all of them. Even if some features are not supported it's still better if you're able to join with limitations than not at all.

mcnesium commented 4 years ago

I have been in several video conferences with >2 participants on different self-hosted Jitsi instances deployed using the Docker setup during the last week with my Firefox 74/Linux, so I can assure it does work with Firefox.

My experience shows that it did not work on setups where ports 4443 and 10000 were blocked on the server by a firewall. Maybe this helps…

weiss commented 4 years ago

Clients should rather be tested for available features

You cannot easily test for the feature in question.

jallamsetty1 commented 4 years ago

We appreciate all the feedback ! Firefox has a very different implementation of the WebRTC SDP format than Chrome and we had decided to focus our efforts on keeping chrome up to date in the past. The WebRTC spec has evolved a lot in the last 1-2 years and all the browsers are merging towards WebRTC 1.0 which makes it easier for us. We have made a lot of progress on getting our Firefox and Safari support up to speed lately and we are in the process of merging these changes. This is how these implementation changes manifest to the users

Signaling issues will be gone, i.e., one of the participants not receiving audio/video.
Better video quality since we are introducing simulcast support for FF.
Better statistics as we are moving to the spec compliant stats.

I will update this issue once these changes make it to a Jitsi Meet release.

jallamsetty1 commented 4 years ago

Is this FF issue also still a blocker: https://bugzilla.mozilla.org/show_bug.cgi?id=1164187 ?

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

cjhille commented 4 years ago

If this is an issue with Firefox, I think that Jitsi Meet should [...] or even completely block Firefox users.

@mimi89999 If i'm not mistaken you can quite easily do that yourself by adding firefox to the list of UNSUPPORTED_BROWSERS in interface_config.js. See: https://github.com/jitsi/jitsi-meet/blob/f5a0a1ef8c50871deec77c7441115accd65e5fe2/interface_config.js#L182

nils-ohlmeier commented 4 years ago

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

Just to be factual correct: implementations can retransmit lost packets also without RTX. Otherwise calls with Firefox on other services would hang all the time, which they don't. Jitsi favors RTX for retransmissions, and as you can see in the Firefox bug integrating the feature into non-Chrome browsers is challenging.

freechelmi commented 4 years ago

My experience shows that it did not work on setups where ports 4443 and 10000 were blocked on the server by a firewall. Maybe this helps…

But This should be the case for any browser if there is no TURN server to route the traffic on some 443 port to jvb.

emcho commented 4 years ago

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

Just to be factual correct: implementations can retransmit lost packets also without RTX. Otherwise calls with Firefox on other services would hang all the time, which they don't. Jitsi favors RTX for retransmissions, and as you can see in the Firefox bug integrating the feature into non-Chrome browsers is challenging.

Just to be factually correct. RTX is the IETF recommended way. If this was about pragmatical approaches, FF would be supporting Plan B SDP and this entire Jitsi/FF situation wouldn’t have been a thing!😉

mordae commented 4 years ago

Sometimes other clients lose incoming streams after a Firefox client rejoins the meeting. This might be the same issue as #5439.

Our latest test setup: 5 users (1x iOS client, 2x Firefox, 2x Chromium) Tested on: a private instance, meet.jit.si/test-to, beta.meet.jit.si/test-to

Steps to reproduce:

Clients join the meeting.
One of the Firefox users presses F5.
After they reconnect, the other Firefox user presses F5.
The first Firefox user is affected and cannot see, hear or both some or all other clients. Videos just freeze.

Historically we have seen other variations of the issue, such as affected user not using Firefox.

Please advise on debugging this issue.

(We can try to reproduce the issue on your infrastructure, if you are willing to manage us. We are available approximately from 10:00 to 20:00 UTC. Drop me an SMS at +420723671732.)

chagai95 commented 4 years ago

I used jitsi yesterday with a participant using Firefox - when she was not muted we could all hear each other twice, why did this happen? also, we were all muted several times automatically but that might be a general problem not sure that is connected to that participant with Firefox. We tried Zoom and that worked fine on said participants Computer

awienecke commented 4 years ago

Just tried recently, everything seems to work, but screen sharing is only visible from non-firefox clients.

Specifically: browser that is sharing doesn't matter; Browsers receiving, only non-firefox browsers can view the shared screen.

chagai95 commented 4 years ago

Ok maybe she is using an older version of Firefox? Could that be the case?

awienecke commented 4 years ago

Firefox version 74 on my end, can't speak for the other end other than they should be the latest version available on windows.

jallamsetty1 commented 4 years ago

Just tried recently, everything seems to work, but screen sharing is only visible from non-firefox clients.

Specifically: browser that is sharing doesn't matter; Browsers receiving, only non-firefox browsers can view the shared screen.

Thank you for reporting about this issue. We are aware of this and have a fix that will be merged soon.

jallamsetty1 commented 4 years ago

Ok maybe she is using an older version of Firefox? Could that be the case?

Do you happen to know what kind of audio device this particular user was using ? There seems to be something wrong with echo cancellation on her machine. When you say you were automatically muted several times during the call, did you mean you stopped receiving video/audio or you stopped sending audio/video. If it is the send side, will you be able to check with the participants if someone was doing "mute everyone else" ? I don't see how you all can be muted otherwise.

jallamsetty1 commented 4 years ago

Using Firefox 74.0, 64 bits, windows10. I must say using https://meet.jit.si with Firefox was OK except not working in p2p, and no information displayed into the session info, cpu 98%, gpu 50%, ethernet 5.5 Mbps If testing on a latest version like https://vidconf.tech4good.ch, or https://www.free-solutions.org no audio or image at all...

Thank you for the feedback. We are aware of the p2p and stats issue and we are working on fixing those.

chagai95 commented 4 years ago

Ok maybe she is using an older version of Firefox? Could that be the case?

Do you happen to know what kind of audio device this particular user was using ? There seems to be something wrong with echo cancellation on her machine. When you say you were automatically muted several times during the call, did you mean you stopped receiving video/audio or you stopped sending audio/video. If it is the send side, will you be able to check with the participants if someone was doing "mute everyone else" ? I don't see how you all can be muted otherwise.

I don't, I'll try checking and getting back to you. I also thought so at the beginning but like I mentioned the same device worked fine with zoom's desktop application...

What I meant with "muted" is literally the mute button on jisti was set to mute and we had to all unmute ourselves manually before we talk, a few times...(I doubt somebody clicked on mute all because we were only 5 participants and ALL of us were muted when you click on mute all you personally stay unmuted and this wasn't the case here.)

samtygier commented 4 years ago

Bug 1600698 JITSI bandwith usage and status info partially fixed upstream. Support added, but needs media.navigator.video.use_transport_cc setting to true to use.

nils-ohlmeier commented 4 years ago

Bug 1600698 JITSI bandwith usage and status info partially fixed upstream. Support added, but needs media.navigator.video.use_transport_cc setting to true to use.

Our current plan is to not enable transport-cc by itself without RTX as we are concerned that this would be a feature combination which nobody has ever tested. Therefore our plan is to wait for RTX to become available in Firefox Nightly and then turn both feature on together.

rmueller83 commented 4 years ago

Here is a list of all jitsti-meet tagged bugs for Firefox: https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=jitsi-meet

everdha commented 4 years ago

Hi, I am really looking forward for this issue to be resolved in Firefox. Thank you for not forgetting and working on this <3 Just a question, which is important I think for people who care about data-friendly and libre tools (which Chrome is not) : is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome? Because if this is not the case, is it necessary to keep talking about Chrome by default?

Thank you for your work again.

jonassmedegaard commented 4 years ago

is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome?

The Free licensed Chromium is the basis (i.e. a subset) of non-free Chrome - signalling parts of WebRTC is same, but Chrome includes additional audio/video codecs that maybe is used in WebRTC, and possibly if you subscribe to Google account then you are more likely to avoid problems when behind a masqueraded (a.k.a. NAT) network due to access to Google TURN services. Here's a random comparison: https://fossbytes.com/difference-google-chrome-vs-chromium-browser/

Instead of interpreting this issue as Jitsi being biased towards a non-free browser, I find it is more fair to describe the situation as jitsi having done WebRTC since very early, when Chrome/Chromium were the only reliable client implementation. Some of the design choices in Chrome/Chromium has caused headaches and has only very recently been reimplemented to align with those of Firefox - see e.g. https://www.callstats.io/blog/what-is-unified-plan-and-how-will-it-affect-your-webrtc-development

tuxayo commented 4 years ago

@jonassmedegaard

parts of WebRTC is same, but Chromium include additional audio/video codecs that maybe is used in WebRTC

You mean «Chrome include additional audio/video codecs» right?

That hopefully isn't a problem. For example, I see that on Arch Linux, there is a dependency on ffmpeg, same for Debian and Ubuntu. So we should be okay about codec support. However I don't know if the software implementation of these codecs is significantly faster in the Chrome one's. Same about hardware acceleration support.

saghul commented 4 years ago

Just a question, which is important I think for people who care about data-friendly and libre tools (which Chrome is not) : is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome? Because if this is not the case, is it necessary to keep talking about Chrome by default?

Any browsser using the Chromium engine should Just Work (TM). We mention Chrome because... it's shorter to type I guess? :-)

everdha commented 4 years ago

We mention Chrome because... it's shorter to type I guess? :-)

Oh I see ^^, how did I not think about that ;-) But ... Edge is even shorter... And you know what else is even shorter? Tor ;) Not based on the same engine though, but based on Firefox. And to get back to Firefox, that's not shorter for sure ... but hey it begins with an "F" as in Free software, that's another niiiiiice reason to keep working on this issue ;-)

tuxayo commented 4 years ago

Instead of "Jitsi is biased towards a non-free browser" it is more fair to describe the situation as "jitsi began doing WebRTC very early, when Chrome/Chromium were the only reliable client implementation".

Thanks for the clarification.

Actually, Chromium is also recommended: https://web-cdn.jitsi.net/meetjitsi_3962.622/static/recommendedBrowsers.html

It looks like you're using a browser we don't fully support.

Maybe the phrasing puts too much burden on Jitsi Meet's side. As we see it seems that this is also a lot of work on the side of Firefox to do for apps like Jitsi Meet to work correctly.

One of the factor we have to be conscious is that the huge difference of means between Chrome and Firefox. And that the fact that Google has web conferencing apps since years (Google Hangout and Google Meet) which means they obviously focuses enough resources to make it work great. And also they can abuse their power due to market share to do things in the way that is the most convenient for them. And if they lead the work on a given web standard, they will have the advantage that the final spec will be very close to their own implementation on which they started to work on it much earlier.

tuxayo commented 4 years ago

As users, I think one of the things we can do it fund Firefox well. And also Jitsi Meet because it's one of our best tools out there for libre video calling.

An analysis (I Am Not An Accountant) of Mozilla's budget report[1] shows that 90% of Mozilla's income is from contracts with search engines. And only 0.74% of funding is from individuals. That's a 120/1 difference.

[1] french resource with some English citations from the report: https://colibris-wiki.org/revlibre/?PayeTonLL I can translate it if there is interest.

Does anyone from the Jitsi team can point to the issue that would help the most Firefox users currently? So we could create a bounty and thrown some bucks at it. (this one is too generic for a bounty)

On the Firefox side, is the one about RTX for WebRTC a good one?

Lennie commented 4 years ago

@tuxayo this also exists: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc Maybe some people who want this but can't help directly can donate to this ? (I got the link from the bugzilla entry)

tuxayo commented 4 years ago

@tuxayo this also exists: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc

That is indeed the one linked in the previous message.

tuxayo commented 4 years ago

For further clarification @jonassmedegaard

Instead of "Jitsi is biased towards a non-free browser"

That's not an actual citation right? That's a translation of the perceived frustration on this thread about Firefox & Jitsi Meet not working well together right?

Frustration against Jitsi Meet which I had until I found out that they also recommend Chromium in their warning.

edit: original message was rephrased, no need to worry

mordae commented 4 years ago

I would like to add that my report is not related to the TCC/RTX issue. We were having issue even without video and everyone was comfortably way below their line capacities. Still, Firefox user entering the session somehow messed up someone else's connection.

Also, we have tested https://v3demo.mediasoup.org/ and the issue was not present.

If you need more data, let me know. I can arrange a manual testing session if you tell us what you need.

XANi commented 4 years ago

Meanwhile could the warning for firefox be worded more strongly? Vague "it might not work perfectly" does not really convey the impact of the issue, considering that FF users can make it bad for everyone.

awlx commented 4 years ago

We (@FreifunkMUC) for now added the Browser to UNSUPPORTED_BROWSERS list and adjusted the warning to also refer the Apps ...

https://twitter.com/FreifunkMUC/status/1247103136856145920

everdha commented 4 years ago

We (@freifunkMUC) for now added the Browser to UNSUPPORTED_BROWSERS list and adjusted the warning to also refer the Apps ...

https://twitter.com/FreifunkMUC/status/1247103136856145920

Hi, isn't this a little bit strong? I am actually using Jitsi from different instances/servers on Firefox with classes of more then 30 students, I am not having problems due to Firefox that I can name that they are due to Firefox. Maybe on Chromium based browsers (not only Chrome by the way, because you only mention Chrome) things would have been better, but clearly her I am able to use it on Firefox with 30 students. That's not nothing.

awlx commented 4 years ago

Hi, isn't this a little bit strong? I am actually using Jitsi from different instances/servers on Firefox with classes of more then 30 students, I am not having problems due to Firefox that I can name that they are due to Firefox. Maybe on Chromium based browsers (not only Chrome by the way, because you only mention Chrome) things would have been better, but clearly her I am able to use it on Firefox with 30 students. That's not nothing.

We have too many complaints and always Firefox was the issue :/. And as we are all volunteers we cannot keep up with the support requests so this decision was made until Firefox works stable with Jitsi. So yes, we don't like this solution but at the moment we see no other way to keep 600 - 700 concurrent users happy.

But we also added a bit more explanation :). https://ffmuc.net/wiki/doku.php?id=knb:meet-downloads https://ffmuc.net/wiki/doku.php?id=knb:meet-en

And for now users seem to accept the change: https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1&refresh=1m

everdha commented 4 years ago

We have too many complaints and always Firefox was the issue :/. And as we are all volunteers we cannot keep up with the support requests so this decision was made until Firefox works stable with Jitsi. So yes, we don't like this solution but at the moment we see no other way to keep 600 - 700 concurrent users happy.

Oh I see, I understand.

But we also added a bit more explanation :). https://ffmuc.net/wiki/doku.php?id=knb:meet-downloads https://ffmuc.net/wiki/doku.php?id=knb:meet-en

Jes, I see :) By the way the Jitsi Meet app is also available from F-Droid : the FOSS alternative store to Google Play Store that you mention on the wiki :) Without F-Droid, no free andoid telephone would be possible, a little bit like the wifi world would be without Freifunk :) <3

rasos commented 4 years ago

I've heard in today's Jitsi community call, that the team is working hard to improve the Firefox compatibility with an ETA of 1-3 weeks.

Meanwhile, we've made the page with recommended browsers look a bit nicer for our community. Feel free to copy/adapt: https://fairmeeting.net/static/recommendedBrowsers.html

tuxayo commented 4 years ago

Good to know Jitsi Meet can still improve things on their side :D

Is/are there a specific/s ticket/s to follow?

steve-clickacall commented 4 years ago

I was in yesterday's community call (thank you for organising this guys!!). As @rasos says above it was mentioned in the call that firefox "and safari" will be improved in 1-3 weeks. But for those of us not as technical as the amazing jitsi dev team and who haven't followed the history for very long, can somebody please explain what the changes will be and what improvements users will see? and when it says Safari, I presume this means on iOS mobile devices so that we can now deliver jitsi Meet onto mobile browsers?

PeterTheOne commented 4 years ago

Community Call https://youtu.be/feksoqPCAhI?t=2951

pdarcos commented 4 years ago

Hi guys, How about Brave browser? I use it all the time and haven't noticed any issues at all (except that the first time you go to jitsi meet server you have to allow auto-play on that page).

And it's also FOSS and very privacy friendly. Shouldn't we add it to the supported - and maybe even recommended - supported browsers?

jitsi / jitsi-meet

100% support for Firefox (and other non-Chrome browsers) #4758