iOS app not connecting properly to meet when app is not active

We’ve recently updated our jitsi sdk to version 5.0.2. and have run into an issue.

We use VoIP notifications and jitsi to handle calls between users, which behaves normally in most instances. User A sets a meeting with user B, user B gets a VoIP notification, user B accepts, user B gets put into a jitsi meet with user A.
However if the phone screen is locked, or the app is inactive for some other reason, jitsi starts and connects user B to the meeting (User A sees their video and hears their sound), but user B only sees the “Connecting you to your meeting” spinner screen.
This seems to be fixed by adding a check before constructing and connecting the jitsi call, to wait for the app state to become active, however we aren’t trilled by having to do this workaround.

My question is, is this a jitsi related issue, which will hoepfully be fixed in the future, or is this something we have to handle on our end by ensuring jitsi only ever starts when the application is active?

We’ve received a couple of similar reports, but given we don’t implement incoming calls not much progress has been made.

How exactly are you handling this? Do you think the SDK thinks the app is active even though it’s still inactive, if you join too fast?

We added a check for UIApplicaiton.shared.applicationState, if the state isn’t active, we add an observer in NotificationCenter for UIApplication.didBecomeActiveNotification, which runs a helper function to start jitsi and remove the observer, if the state is active we just start jitsi as normal.

That seems to be the issue. The problem doesn’t appear if we say add a 3 second delay to starting jitsi and the application becomes active in those 3 seconds.
That was our original attempt at fixing our issue, but we ended up on the notification variant since it makes sure the application will be active when we start jitsi, while not adding unnecessary wait time for cases where our application is active already.

Hum, interesting. Is this still the case if the phone is locked?

The phone has to be unlocked within the 3 seconds, or however much delay we give, for jitsi to start properly, but if it is then it has no issue.

Aha, so if the phone is never unlocked then it won’t work, right?

I might have worded myself a bit poorly, let me give you all the details.
So, if the phone is locked when the user answers, jitsi will start, join the user into the meeting while still locked, and pass through audio. Then, if the user unlocks the phone, it starts passing video as well, but the user only sees the “Connecting you to your meeting screen”.
If the user never unlocks the phone, only audio is ever passed through.
If we give jitsi a delay to start after a call is accepted, then the same thing happens if the user fails to unlock their phone in the given delay, user ends up in the meeting but sees the wrong ui.
If the user does unlock the phone in the given delay, that is, before jtisi start, jitsi will work normally (properly display the meeting screen).

Ah, gotcha. I think we have fixed this in master already. A new SDK will be released shortly.