Mobile 7.0.1 SDK Has Audio but no Video

Developers Client dev
,
1

Hi, since updating our SDK to the new 7.0.1, we are no longer getting screen share or other video feeds when connecting to some of our meeting servers, but we have audio. Previous SDK (5.1.0) works fine on all servers. Config.js on both working and non-working servers are the same. Anyone have any other ideas or tips on what to check?

2

What is the backend version?
Do you have these 4 lines in the config
jitsi-meet/config.js at 17ed45799c028d5b5a1198f50833ac646babce32 · jitsi/jitsi-meet · GitHub?

3

We don’t have those 4 lines in our mobile config. When were those added? I will add those today and test again. Thanks!

4

@damencho adding those 4 lines to the mobile code didn’t fix the problem. I have these console logs from Xcode if they help:

**[JitsiMeetSDK] [VideoTrackAdapter] Mute event for pc 0 track c4854d62-ae12-470c-b43e-52baf24c0d9a-1**

**[JitsiMeetSDK] [modules/RTC/JitsiRemoteTrack.js] "onmute" event(1677846782000): RemoteTrack[userID: 4c86c2a9, type: video, ssrc: 532809016, p2p: false, sourceName: 4c86c2a9-v0, status: {readyState: live, muted: true, enabled: true}]**

**[JitsiMeetSDK] [modules/connectivity/TrackStreamingStatus.ts] Detector track RTC muted: 4c86c2a9-v0 1677846782000**

**[JitsiMeetSDK] [modules/connectivity/TrackStreamingStatus.ts] Set RTC mute timeout for: 4c86c2a9-v0 of 10000 ms**

**[JitsiMeetSDK] [modules/connectivity/TrackStreamingStatus.ts] Figure out conn status for 4c86c2a9-v0, is video muted: false video track frozen: true p2p mode: false is in forwarded sources: true currentStatus => newStatus: active => restoring**

**[JitsiMeetSDK] [modules/connectivity/TrackStreamingStatus.ts] Emit track streaming status(1677846792010) 4c86c2a9-v0: restoring**

**[JitsiMeetSDK] [modules/connectivity/TrackStreamingStatus.ts] Figure out conn status for 4c86c2a9-v0, is video muted: false video track frozen: true p2p mode: false is in forwarded sources: true currentStatus => newStatus: restoring => restoring**
5

And audio works?

6

Yes, audio works fine. Here is what we have so far:
both working and non-working servers are running the same server version (Release stable-7439-2: release · jitsi/docker-jitsi-meet · GitHub). Our scenario is a browser client and mobile client in the same meeting. When the browser shares, the browser avatar drops to the filmstrip like a share is starting, but the image never displays. When the browser stops sharing, the display shows the browser user avatar again. If we switch the mobile client back to the 5.1.0 SDK, all is fine.

7

Can you try same test with 3 participants in the call?
Are the colibri-ws working on the non-working server?
Hum… I think if you disable p2p on the non-working server it will work.
It’s hard to connect the dots using an older version, there were no unified in the old sdks also there was some problem between those in older version and mobile and that’s why p2p was disabled. But everything is fixed in latest, but not sure about such a combination …

8

Okay, here is what we have determined:
Our servers that are “working” are using the latest Jitsi-videobridge (Release 2.0.8194 · jitsi/jitsi-videobridge · GitHub) and that’s why it’s working with the mobile 7.0.1 SDK. Our “non-working” servers are using a previous Jitsi-videobridge (Release 2.0.7439 · jitsi/jitsi-videobridge · GitHub) which we’ve determined is not compatible with the mobile 7.0.1 SDK. Backward compatibility seems to be broken.

The problem here is that our “shipped” product is using the older video bridge and that means we can’t update our mobile with the latest (7.0.1) SDK unless there is a fix to take care of the backward compatibility. Is there a chance to get some sort of fix or can you recommend an earlier SDK that is backward compatible? We know the mobile SDK 5.1.0 works just fine.

9

Sorry, I cannot help here.
In our experience, the backend is moving quicker than the mobile SDK, so we normally test it that way whether we break older SDKs and we make sure we do not push stuff that will break all mobiles that are stuck to an older version. At some point, breakage cannot be avoided with very old versions.
But we are not taking care of the other way around where SDK is newer and needs to work with such old versions.
Not sure what can be the problem … so your best bet is to dissect which SDK works …

10

Thanks for your help with this. I know how fast you guys put stuff out so I can understand the huge test effort required to be backwards compatible. It does mean, however, that we can’t take advantage of your latest stuff. We are somewhat crippled by the fact that our customers don’t always update to our latest meeting servers which means we need to provide support for our past releases. Our very latest release used the 2.0.7439 release which if I am reading the information at the link above correctly just came out in June which seems fairly recent. The 7.x SDK came out in December and is already not compatible. We know it is compatible with the 5.1 sdk and we will be trying the latest 6.x SDK next week and can report our results here. But it sounds like we are stuck at one of these levels because of this issue. I am worried that eventually some xcode requirement will force us to update and we will be in a real pickle.

11

@damencho FYI, I’ve gone back to the 6.0.0 mobile SDK and determined that both audio and video are flowing just fine on all levels of servers that we support. The 6.1.0 SDK is where everything stops. No audio, no video for the Release 2.0.7439 · jitsi/jitsi-videobridge · GitHub level of servers.

12

I did some digging.

So my guess is that you need to enable multistream in your backend and it should start working. Your client is signaling multistream support and is acting as this is turned on … where your backend has that turned off.

multi-stream {
    enabled = true
  }