Jitsi meet not working on Chrome 86?

Hi there,

We use Jitsi every morning with colleagues for daily standup, and recently (Monday I’d say), many of us had difficulties joining a room with their browser. It appears it works on Mozilla Firefox, and that mainly failing users are on Chrome 86.

I suspected our install first (jvb, turnserver and the rest on 3 separate machines, to use only https 443 port), then tried a fresh new standalone install, and then directly on meet.jt.si, and all these 3 cases are failing on Chrome 86.

I’m quite shocked not seeing many issues here reporting the same problem (we do not have corporate VPN, we are on remote office/house connexions, etc…).

We encounter various errors in the console, like this one (on our servers):

[JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: null Script: null Line: null Column: null StackTrace: Error: Strophe: Error: Failed to execute 'createEncodedStreams' on 'RTCRtpSender': Encoded audio streams not requested at PC initialization

Or this one (on meet.jit.si) :

react_devtools_backend.js:2273 2020-10-14T15:07:15.556Z [modules/xmpp/JingleSessionPC.js] “session-initiate” error null
overrideMethod @ react_devtools_backend.js:2273
o @ Logger.js:154
(anonymous) @ JingleSessionPC.js:1009
(anonymous) @ strophe.umd.js:2732
run @ strophe.umd.js:1938
_onIdle @ strophe.umd.js:3869
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
17:07:16.029 react_devtools_backend.js:2273 2020-10-14T15:07:16.028Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: null Script: null Line: null Column: null StackTrace: Error: Jingle error: {“reason”:“timeout”,“session”:“JingleSessionPC[p2p=true,initiator=true,sid=79612ff2b1af]”}
at JingleSessionPC.js:2458
at I.TimedHandler.handler (strophe.umd.js:2732)
at I.TimedHandler.run (strophe.umd.js:1938)
at I.Connection._onIdle (strophe.umd.js:3869)
at strophe.umd.js:3886
overrideMethod @ react_devtools_backend.js:2273
o @ Logger.js:154
getGlobalOnErrorHandler @ JitsiMeetJS.js:613
window.onerror @ middleware.js:107
callErrorHandler @ GlobalOnErrorHandler.js:61
(anonymous) @ JingleSessionPC.js:2457
(anonymous) @ strophe.umd.js:2732
run @ strophe.umd.js:1938
_onIdle @ strophe.umd.js:3869
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
setTimeout (async)
_onIdle @ strophe.umd.js:3885
(anonymous) @ strophe.umd.js:3886
17:07:16.651 react_devtools_backend.js:2273 2020-10-14T15:07:16.650Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: null Script: null Line: null Column: null StackTrace: Error: Jingle error: {“reason”:“timeout”,“session”:“JingleSessionPC[p2p=true,initiator=true,sid=79612ff2b1af]”}
at JingleSessionPC.js:2458
at I.TimedHandler.handler (strophe.umd.js:2732)
at I.TimedHandler.run (strophe.umd.js:1938)
at I.Connection._onIdle (strophe.umd.js:3869)
at strophe.umd.js:3886

Am I the only one to experience this issues?

Best

2 Likes

does it mean shocked ? did you try to click the search icon and enter ‘chrome 86’ ?

You’re right. There is actually 2 issues related to Chrome 86.x.

Unfortunately those two issues answer is “update your jitsi version” and I did it on my infra / installed fresh one / tested on meet.jit.si (that should be always up to date ?), and still falling for me. I’ll update these issues with my problem here.

I remember having seen more than 2. Anyway did you try to use the Jitsi electron app ? It may not have been updated to the latest Chrome engine yet.

No, I use it through the Google Chrome broswer (Version 86.0.4240.75 (Official Build) (x86_64)). Jitsi simply doesn’t work for me on that browser, I’m forced to use Firefox to make it working.

try the Electron app then. It’s basically the same engine than Chrome, but the update is not fixed by Google but by the Jitsi project.

Can you attach JVB logs?

I saw @damencho reply in another topic, he told to upgrade to the last version.

I did it now, but i still have an issue in my enviroment when 3+ peopple join the room.
My udp port 10000 is opened

jvb.log (209.2 KB) here is my jv log @bbaldino

Help =D

Your config is probably the problem:

2020-10-14 14:21:22.435 INFO: [11] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Using org.ice4j.ice.harvest.MappingCandidateHarvester, face=/10.10.1.33, mask=/200.223.36.165
2020-10-14 14:21:22.435 INFO: [11] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Using org.ice4j.ice.harvest.StunMappingCandidateHarvester, face=/10.10.1.33, mask=/45.190.12.239

You should use only one of the harvesters, and the strange thing is you have configured one address where the stun mapping auto-discovers another address that is used.
And make sure the port forwarding works on the correct public IP address.

1 Like

It was in my face and i didnt saw. Thanks again

jvb.log (1.4 MB) @damencho

Facing same issue when multiple users join into the meeting, application not working in chrome.

2020-10-15T11:43:48.072Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: Uncaught InvalidStateError: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded audio streams not requested at PC initialization Script: https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127 Line: 17 Column: 26242 StackTrace: DOMException: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded audio streams not requested at PC initialization
at a.handleReceiver (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:17:26242)
at se._setupReceiverE2EEForTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:196212)
at se.onRemoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:174750)
at a.emit (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:1:128930)
at A._createRemoteTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:121004)
at A._remoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:120545)
at A._remoteStreamAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:118798)
at RTCPeerConnection.A.m.a.usesPlanB.peerconnection.onaddstream (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:114652)
s @ Logger.js:154
E2EEContext.js:72 Uncaught DOMException: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded audio streams not requested at PC initialization
at a.handleReceiver (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:17:26242)
at se._setupReceiverE2EEForTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:196212)
at se.onRemoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:174750)
at a.emit (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:1:128930)
at A._createRemoteTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:121004)
at A._remoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:120545)
at A._remoteStreamAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:118798)
at RTCPeerConnection.A.m.a.usesPlanB.peerconnection.onaddstream (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:114652)
Logger.js:154 2020-10-15T11:43:48.072Z [modules/RTC/TraceablePeerConnection.js] <A._remoteTrackAdded>: TPC[1,p2p:false] remote track added: 58651fd9-ce56-bc44-8c77-c5a718aec607-1 video
Logger.js:154 2020-10-15T11:43:48.072Z [modules/RTC/TraceablePeerConnection.js] <A._remoteTrackAdded>: TPC[1,p2p:false] associated ssrc 7643cde2 2876456268
Logger.js:154 2020-10-15T11:43:48.073Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: Uncaught InvalidStateError: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded video streams not requested at PC initialization Script: https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127 Line: 17 Column: 26242 StackTrace: DOMException: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded video streams not requested at PC initialization
at a.handleReceiver (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:17:26242)
at se._setupReceiverE2EEForTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:196212)
at se.onRemoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:174750)
at a.emit (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:1:128930)
at A._createRemoteTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:121004)
at A._remoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:120545)
at A._remoteStreamAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:118870)
at RTCPeerConnection.A.m.a.usesPlanB.peerconnection.onaddstream (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:114652)
s @ Logger.js:154
E2EEContext.js:72 Uncaught DOMException: Failed to execute ‘createEncodedStreams’ on ‘RTCRtpReceiver’: Encoded video streams not requested at PC initialization
at a.handleReceiver (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:17:26242)
at se._setupReceiverE2EEForTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:196212)
at se.onRemoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:174750)
at a.emit (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:1:128930)
at A._createRemoteTrack (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:121004)
at A._remoteTrackAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:120545)
at A._remoteStreamAdded (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:118870)
at RTCPeerConnection.A.m.a.usesPlanB.peerconnection.onaddstream (https://meet.remokly.com/libs/lib-jitsi-meet.min.js?v=4127:10:114652)

Sharing log

Any information from Jitsi developers on how to solve the problem?

Update to latest stable.

1 Like

Confirmed - we had similar issues with lost connection/no video when participants when using Chrome 86 based browsers, particularly when 3+ participants (which uses the bridge).

Solution was to update lib-jitsi-meet within the web project and we also took the opportunity to upgrade the video bridge and associated components.

Ensure the bridge is picking up the correct internal and external IPs from the logs too.

Hi there. I do not understand why it did not worked yesterday, but since this morning, my fresh update / fresh install / meet.jit.si, I can confirm that everything working fine again with update to latest and restart all services.

@damencho under the hood, what were the reasons of this bug? What BC break Chrome did introduce in v86? Is something that might happen again in the future?

Thanks for your lights

It was some change in encoding for vp8 or something which result bigger buffers being sent, the one on the bridge were 1240 and we saw getting buffers up to 1244 (https://github.com/jitsi/jitsi-videobridge/issues/1483) which resulted higher times in GC which resulted bad quality because of bridge spending more time in garbage collecting. The buffer was increased to 1500 to catch future changes.

1 Like

Thanks a lot for this explanation. When did you found that issue and solved it? Is there a reliable way for me to subscribe somewhere to receive info about bugs/updates and things like that. We sell Jitsi integration to corporates and I could not afford again to wait for my clients to ping me when they have this kind of problem :wink:

Best

In other words you get reliable resources from support contracts ? maybe it’s time for the Jitsi project to roll out platinum sponsoring with exclusive access to real time info :slight_smile:

I’m not sure that how successful OS projects works. Imagine node.js, Django, Symfony, Express, etc… requiring users to pay to be live informed about updates, security issues, important bugs, roadmap ?!?

Jitsi could:

  • sell premium hosting (like meet.jit.si with guaranteed SLAs, etc…)
  • sell custom support/installation or integration

Things that many small business are already doing on top on jitsi software. But paying to be informed to updates/upgrades/security patches ??

Jitsi should have a clearer roadmap, more detailed releases (https://github.com/jitsi/jitsi-meet/releases seriously ?!), a mailing list or something else that could inform thousands of devs/smbs that are developing on top of it when there are big changes like the one we are talking in this issue. Maybe I’m mistaken and @damencho could point me to something like that that already exist.

Best

There is no point in having a roadmap, this had been proven to us, as priorities change daily and whatever we put there it will be outdated in a week or two.
We have now https://github.com/jitsi/jitsi-meet-release-notes/blob/master/CHANGELOG-WEB.md
And you can follow the community call on youtube where we give updates: what we work on, what will be working on in the following weeks, what we will release, and so on. The Call is open for everybody and you can come and ask your questions live.