Opening a Room with a password for the first time causes the Call to stay open when hanging up

[AliKarpuzoglu]

Description

---

When I have a self hosted jitsi, and I open a room on my iOS device while entering a password, after hanging up the app behaves as if a call is still ongoing, even though you have left the room

Current behavior

---

see description

Expected Behavior

---

When hanging up, you want the app to close

Possible Solution

---

Finding the cause of why the App stays open only when entering a password, but not when a password is saved.

Steps to reproduce

---

1. on a self hosted jitsi (with a password requirement) open a room
2. enter the password (it can't be a saved password)
3. hang up, or have people join and then hang up
4. the app still has an indicator saying that the phone call is ongoing

Environment details

---

iOS 13.3.1
iPhone 11 - also happening on iPads
Jitsi Version 20.2.1 build 68

(not happening on android)

[AliKarpuzoglu]

If I see it correctly, the App starts multiple different Call UUID

[JitsiMeetSDK] [RNCallKit][startCall] callUUID = 5F033A27-69EE-
[JitsiMeetSDK] [RNCallKit][startCall] callUUID = 1374246C-583A-4523-BE3D-72E9B8D3E49C

etc. Could this be the cause of the call not hanging up?

react-native-webrtc/react-native-callkit#3 had a similar issue

[AliKarpuzoglu]

Further info: A 'call' is being started before an authentication is finished. Could this call be the background call that stays open afterwards?

[AliKarpuzoglu]

@saghul I think you are part of the iOS development team, right? If you need to reproduce this error, I can give you access to a jitsi instance.

[AliKarpuzoglu]

I just see that this might have been the same problem as in #4853 @pdarcos did you manage to fix the issue?

[pdarcos]

Hi @AliKarpuzoglu

No unfortunately this behavior is still ongoing (I just compiled latest master to test) and makes it a pain to use the iOS app on a self-hosted install. I wonder why it only happens on self-installs and not on meet.jit.si

My workaround was to disable CallKit integration but I don't remember how I ended up doing it.

Maybe @saghul can help?

[pdarcos]

My latest attempt to disable CallKit (at least until we figure out why this happens) failed.

I inserted [builder setFeatureFlag:@"call-integration.enabled" withBoolean:NO]; in AppDelegate.m here thinking this would disable it but it didn't work. It is still enabled.

[AliKarpuzoglu]

I also tried to disable CallKits integration, but it didn’t work. I’m currently trying to cancel all call uuids when you hang up. The reason why it works with meet.jit.si is that you don’t have to enter a password. It also works for self hosted instances if you have the password saved. (Try connecting twice)

I am pretty sure the problem is that you start a call on iOS before you even enter the passsword, and then you start even more calls.

You can see this, when you connect and press the home button ( or slide up ) before entering the password. There will be a ‘call’ in progress.

I’m trying to fix it, but I am not really experienced with react native. I’ll update you if i get it done. Thank you for your time.

[pdarcos]

No problem.
Have you tried without setting a password? In my case it happens with or without a password set.

[AliKarpuzoglu]

The call stays on after hanging up, even when there was no password? I have not seen that happen, I’ll try it out tomorrow though

[AliKarpuzoglu]

the workaround from #4970 works - by disabling callkit, you don't have a call staying open. I am going to use this, until I or someone here finds the issue

[saghul]

Yeah, this is a known issue. The problem is the auth window retries the connection, creating multiple calls on CallKit. We need to make sure all that is cleaned up properly.

Alas I don’t think I’ll have the time to work on this soon, but thanks for reporting it!

[AliKarpuzoglu]

Are there any unforeseen downsides to just disabling CallKit? Except for not being able to hang up without opening the app?

[AliKarpuzoglu]

This also happened to me just now, I think when entering a lobby with a password. (for #7514 ) We disabled native call integration in our fork quite a while ago and I have not noticed any adverse effects.
I feel like disabling it will make a lot of users feel better about the usability of the app, especially since a lot of similar apps don't use native call integration.