Video tracks not being received/send

Hello,

We are implementing a custom UI based on Angular and Ionic using JitsiMeetJS for our video conferencing needs. In general, everything is working fine, except for a few issues that we struggle to understand and reproduce.

The first issue is that sometimes other particpants of the conference wont receive the information that a new video track has been added by a remote participant. The audio tracks are always being received. The issue occurs more often when Firefox is involved (FF 60 ESR and FF 68 ESR), but also occurs on Chrome, though very rarely. Also the issue seems to occur mostly upon joining an existing (as in “particpants have been communicating”) conference and upon rejoining a conference after leaving. It is also possible that another participant that is joining a conference where at least 2 participants are seeing this bug, the third one can see all streams correctly.
Debugging this issue we see that the RTCPeerConnection is not being notified that a new track has been added. Upon joining and adding the local track to the conference we dont see any errors client or server-side.

In the jicofo logs we see that both users create their sources with video and audio ssrcs, weirdly enough those “first” streams are being removed shortly after, and recreated. If we are interpreting those logs correctly, then the participants recreate their sources and resubmit them to jicofo, while keeping using the first streams as the local ones.

The second issue seems related, but unfortunately we have even less information about that - in the same use cases as above the participant seems to receive an “empty” stream. We see everything being correct in the logs, we receive and attach the tracks as usual, but the video just remains empty.

Things we tried to resolve our issues that did not help at all:

  • We connected to the official meet.jit.si API instead of our own on-prem instance
  • We updated the JitsiMeetJS version to the newest release and to github master HEAD
  • We updated Strophe to the newest release
  • We used google STUN servers
  • We played around with settings:
    – disabled Simulcast
    – disabled p2p
    – dis-/enabled experimental settings
  • We refactored our stream/track handling in the UI

Nothing of this brought any kind of improvement, and we currently lack any other ideas on how to keep debugging this issues, so any help or hint of what we could check would be greatly appreciated.

Thanks in advance.

Hi seems we have the similar issue:

Hello lixiran1,

It seems that the symptoms of the issue are similar, but we additionally have the issue of the WebRTC MediaTrack completely missing on participants.

We managed to wire up a kinda minimal example using the dependency versions and environment of our project, together with a description of how to reproduce. GitHub: https://github.com/x1gma/jitsi-track-issues

The steps to reproduce are documented there, npm install && ionic serve --ssl to wind up the application.

The issue is visible both on our on-prem Jitsi backend aswell as the official API and Beta-API.

The UI is slightly all over the place. You can see that a video track is present by looking for the red border, that is the actual video element that is being hidden when no track is present.

I wonder what the actual Jingle traffic looks like between:

  1. the new participant that joins the call <-> Jicofo
  2. the existing participants <-> Jicofo.

The IQs should be visible in the Jicofo logs, if you enable the appropriate logging levels, but I don’t remember the exact class names. @damencho do you have that handy? And since we’re attaching logs, it would also be nice to have the JVB logs.

Presumably empty here means that the video element doesn’t render anything. Does this happen both on Chrome and on Firefox? I wonder if the bridge sends packets for that track. A webrtc-internals dump would be useful here.

You can add in /etc/jitsi/jicofo/config in JAVA_SYS_PROPS the following -Dsmack.debugEnabled=true -Dsmack.debuggerClass=org.jivesoftware.smack.debugger.ConsoleDebugger this will enable smack debug and all exchanged xmpp messages will end up in the jicofo log.

Hello and thanks for your answers.

The IQs should be visible in the Jicofo logs, if you enable the appropriate logging levels, but I don’t remember the exact class names. @damencho do you have that handy? And since we’re attaching logs, it would also be nice to have the JVB logs.

The jicofo log with the enabled smack debug is attached. Please let me know if you actually need the JVB logs for further analysis. There are a few disconnects in between since the problem occurs after one of the participants has disconnected at least once. Both participants used Firefox 68.1.0esr (64-Bit).

jicofo.debug.log (342.6 KB)

Presumably empty here means that the video element doesn’t render anything. Does this happen both on Chrome and on Firefox? I wonder if the bridge sends packets for that track. A webrtc-internals dump would be useful here.

Yes, it also happens on Chrome, but from what we experienced with a much lesser frequency. Firefox seems to be the main troublemaker here.