Browser refresh needed intermittently to get camera and sound to work

Install & Config
1

Our users are getting intermittent failures to get camera and sound to work, we have seen this ourselves as well. Its similar to when ICE fails. The issue seems to appear in p2p mode as well.

The only solution, and simple one, is to refresh the webbrowser and voilá everthing works.

jvb logs shows a couple of warnings:

…MergingDatagramSocket.initializeActive#599: Active socket already initialized

…MergingDatagramSocket$SocketContainer.runInReaderThread#770: Failed to receive: java.net.SocketException: Socket closed
…MergingDatagramSocket.close#142: Closing
…MergingDatagramSocket.doRemove#349: Removing the active socket. Won’t be able to send until a new one is elected.

…BandwidthAllocator.allocate#271: Sources suspended due to insufficient bandwidth (bwe=449094 bps): [00feba2e-v0, 74689657-v0]

Any advice to troubleshoot this is highly appreciated

2

Managed to get web console logs on this behavior today, they show the following (this was during a p2p meeting). Issue has appeared on larger meetings as well but we are suspecting this occurs when going from p2p and “upgrade” to jvb

This logs shows a p2p meeting where we could see eachother over video but no sound:

2023-02-17T09:34:43.286Z [modules/RTC/TraceablePeerConnection.js] <Bd._processLocalSSRCsMap>: TPC[id=1,type=P2P] No SSRCs found in the local SDP for track=LocalTrack[3,audio], stream=audio-0
r @ lib-jitsi-meet.min.js?v=6776:2
lib-jitsi-meet.min.js?v=6776:2

   2023-02-17T09:34:43.839Z [modules/RTC/TraceablePeerConnection.js] <Bd._processLocalSSRCsMap>:  TPC[id=2,type=JVB] No SSRCs found in the local SDP for track=LocalTrack[3,audio], stream=audio-0

r @ lib-jitsi-meet.min.js?v=6776:2
lib-jitsi-meet.min.js?v=6776:2

   2023-02-17T09:35:04.377Z [modules/RTC/JitsiLocalTrack.js] LocalTrack[3,audio] 'bytes sent' <= 0:                         0

r @ lib-jitsi-meet.min.js?v=6776:2
lib-jitsi-meet.min.js?v=6776:2

   2023-02-17T09:35:59.190Z [modules/RTC/TraceablePeerConnection.js] <Bd._processLocalSSRCsMap>:  TPC[id=1,type=P2P] No SSRCs found in the local SDP for track=LocalTrack[3,audio], stream=audio-0

r @ lib-jitsi-meet.min.js?v=6776:2
lib-jitsi-meet.min.js?v=6776:2

   2023-02-17T09:39:37.688Z [JitsiMeetJS.ts] <Object.getGlobalOnErrorHandler>:  UnhandledError: Failed to execute 'setParameters' on 'RTCRtpSender': Failed to set parameters since getParameters() has never been called on this sender Script: null Line: null Column: null StackTrace:  Error: Failed to execute 'setParameters' on 'RTCRtpSender': Failed to set parameters since getParameters() has never been called on this sender

r @ lib-jitsi-meet.min.js?v=6776:2
getGlobalOnErrorHandler @ lib-jitsi-meet.min.js?v=6776:2
window.onunhandledrejection @ app.bundle.min.js?v=6776:178
synkkp:1

   Uncaught (in promise) DOMException: Failed to execute 'setParameters' on 'RTCRtpSender': Failed to set parameters since getParameters() has never been called on this sender

Could this be related to this issue that was fixed in a 2.0.8218

lib-jitsi-meet

  • fix(p2p) Fix an issue where unmute fails on p2p with channelLastN=0. Always initiate a sRD->cA->sLD cycle since renegotiation fails in the following scenario. In a p2p call when channelLastN=0, the direction on the video tranceiver is set to’inactive’. At this point, if the user unmutes, the track is replaced on the video sender. If a cO->sLD->sRD is triggered, the browser adds a third m-line which isn’t expected and possibly is a bug. All renegotiations fail as a result. However, the browser does not add a third m-line in the answer it generates and renegotiation succeeds.
3

Thanks for the report, we have seen this happen in our calls and we are looking into this.

1 Like
4

Thanks @jallamsetty for lettings us know. Keep us/community updated on when you believe a solution is available.

Please let us know if we can assist in any way

1 Like
5

@keda82 On larger calls involving only the jvb connection, have you seen this error in the console logs when this issue is encountered ?
[modules/RTC/JitsiRemoteTrack.js] <$d._containerEventHandler>: error handler was called for a container with attached RemoteTrack

6

I was testing latest 2.0.8319 yesterday and had similar issue but only if av moderation is on.
Once permission is granted and participant starts camera, camera can be started but other participant do not see any video.
Will do some more tests and will provide more details.

7

we will try to gather logs next time it occurs :+1:

8

We are able to reproduce this and will be working on a fix.

2 Likes
9

@kkd The issue with A/V moderation has been fixed in the master and will be available in the next stable release.

1 Like
10

@keda82 We have applied a probable fix to master. Please let us know if you still experience the issue with the next stable release.

11

@jallamsetty thanks for lettings us know, much appreciated! We will try this out in the next stable release and let you know the result. When is it release scheduled?

12

No plan for now … but maybe the following two weeks.

13

Any news on the next stable release? We are keen on tryin the fix

Is there a PR reference for the fix?

14

No ETA now, maybe next week or the week after. I think this is the fix:
The AV moderation issue is fix: Fixes video unmuting in case of av moderation. · jitsi/jitsi-meet@4ffc2bc · GitHub
While the setParameters issue is in lib-jitsi-meet
fix(TPC) Chain all RTCRtpSender.setParameters calls. (#2242) · jitsi/lib-jitsi-meet@9f3ed24 · GitHub
and Made updating video sender parameters in sequential manner in order t… · jitsi/lib-jitsi-meet@b3ceca8 · GitHub

1 Like
15

@damencho how are things progressing with the next release?

16

You can install latest jitisi and then rebuild master branch and replace jitsi-meet folder.
It will have all changes from nightly.
Or you can install jitisi with nightly build

17

Thanks @kkd we are aware of this. Looking for the next stable release :+1:t2: