Possibility of self-managed react-native-callkeep, i.e. with "setConnectionProperties(PROPERTY_SELF_MANAGED)"?

[sunweiyang]

UPDATE: This is now a feature request. Can react-native-callkeep be updated so that it can be used with setConnectionProperties(PROPERTY_SELF_MANAGED)?

---

Our use case is this: we have a cross-platform video chat app that uses opentok-react-native, and we currently use just push notifications to get users to pair with each other (using react-native-onesignal). When our users tap the push notification, they simply get dropped into our app.

We would instead want these video chat requests to look like phone calls. This means that we want the phone-call-esque screen to just act as a glorified push notification (tapping the answer button would trigger the exact same behavior that our push notification currently triggers -- opening the app, nothing more and nothing less).

It seems to me that such a functionality must be possible to do in CallKit and ConnectionService without all the other things that other typical VoIP apps need. For example, requesting the BIND_TELECOM_CONNECTION_SERVICE permission on Android shouldn't be needed, and it would be great to not have to show this to the user. (Or I may be misunderstanding ConnectionService.)

Is it possible to use react-native-callkeep as something like a full-screen push notification that just happens to look like an incoming phone call?

[manuquentin]

Hi @sujameslin.
Unfortunately, the documentation express that to use ConnectionServer we have to require permission for BIND_TELECOM_CONNECTION_SERVICE.

I haven't tried without it, maybe you can do some tests and check if it possible, but I'm not very sure about it.

[ghost]

Would it not be possible to accomplish this using a self managed ConnectionService?

https://developer.android.com/guide/topics/connectivity/telecom/selfManaged

[sunweiyang]

Even better if react-native-callkeep has the ability to do either self-managed or system-managed depending on availability (API 26 and API 23, respectively), or self-managed only, depending on developer's preferences.

[sanjaypojo]

Also looking for this feature! Are there any plans to support this?

[manuquentin]

Hi @sanjaypojo @sunweiyang,
We do not plan to implement this in the short term.
You can make a PR and we can work on it.

[jayrenteria]

@sunweiyang did you ever find a solution for this? We are using almost exactly the same stack and looking to accomplish the exact same thing.

[Arlen22]

What would it take to do this? I don't understand what the difference is but the Android docs make it seem identical.

[ksitko]

Has anyone worked on this problem at all? The major discrepancy between how android and ios handle this is a bit of a headache.

[johnjoshuadablo]

+1

[danjenkins]

Theres a branch over at https://github.com/Telzio/react-native-callkeep/tree/feature-android-self-managed but its not documented at all, and hasn't been tested generally - if you wanted to help put some effort into documenting it, testing it, etc etc then I'm sure the devs at Telzio would love that

[mmatheusmmiguel]

Existe uma ramificação em https://github.com/Telzio/react-native-callkeep/tree/feature-android-self-managed mas não está documentada e não foi testada em geral - se você quisesse ajudar se esforçar para documentá-lo, testá-lo etc. etc, então tenho certeza que os desenvolvedores da Telzio adorariam isso.

Has anyone managed to test this?

[Arlen22]

Apparently if you're a native app developer this stuff is all obvious, but to us Javascript junkies it's a completely different world.

[namnm]

Hi all, I have been able to look at the diff and perform some experiment with https://github.com/Telzio/react-native-callkeep/tree/feature-android-self-managed:

• Whenever a call is incoming, it will try to call onShowIncomingCallUi
• I modified it to call backToForeground so that it can display the incoming call UI in RN

It works well on all foreground/background/killed. But when screen is locked, it can not show anything.
I also tried with this original repo by call backToForeground when user click answer, but if screen is locked, it can not open the app too. (In this case the call are connected after answer and Im able to hear the audio, but phone still locked)

Any idea?

[jayrenteria]

Hi all, I had managed to wrangle most of the functionality to work in this fork. This is from a few months ago, so it is quite a bit behind the current version of CallKeep, which seems to have addressed some issues (mainly around backToForeground amongst other things).

I may look to upgrade this over the next couple weeks, but take a look and see if you get any ideas. I ended up using a combination of approaches that are mentioned in this thread, and made use of the wake lock stuff from android in a new headless task (in my app, not in this fork) to deal with lock screen states. I can post that code if anyone is interested.

It also relies on a notification extension service, which we were already using for something else, that I modified to fire off certain services. We use OneSignal, but honestly it has not been very reliable. We are currently making the switch to FireBase in hopes that it improves connection rates, as that seems to be our biggest issue now.

Happy to talk more about this or answer any questions.

[mmatheusmmiguel]

Olá a todos, consegui reunir a maior parte da funcionalidade para funcionar neste fork . Isso é de alguns meses atrás, então está um pouco atrás da versão atual do CallKeep, que parece ter resolvido alguns problemas (principalmente em torno de backToForegroundoutras coisas).

Posso tentar atualizá-lo nas próximas semanas, mas dê uma olhada e veja se você tem alguma ideia. Acabei usando uma combinação de abordagens mencionadas neste tópico e usei o recurso wake lock do Android em uma nova tarefa sem cabeça (no meu aplicativo, não neste fork) para lidar com os estados da tela de bloqueio. Posso postar esse código se alguém estiver interessado.

Ele também depende de um serviço de extensão de notificação, que já estávamos usando para outra coisa, que modifiquei para disparar certos serviços. Usamos OneSignal, mas, honestamente, ele não é muito confiável. No momento, estamos mudando para FireBase na esperança de melhorar as taxas de conexão, pois esse parece ser nosso maior problema agora.

Fico feliz em falar mais sobre isso ou responder a quaisquer perguntas.

Hi @jayrenteria
It would be wonderful if you update it and show us this wake lock code.

Thank you for your interest in helping the community.

[jayrenteria]

@mmatheusmmiguel no problem, I have added the code I use for the notification extension service and the headless task here in this gist.

The headless task code includes the wake lock, the notification extension calls it.

Keep in mind, we send everything we need from opentok (session id, username, token, etc) from our backend to the push notification payload under a specific android channel id, and we listen for that in our extension service. Once we get that, we prep the data to send to the event emitter, and then parse it out in the RN app accordingly.

For example, when we get the data we need from the notification, we store that in asyncstorage, and navigate to our video chat screen where we connect to the session using the data. We also use a custom incoming call screen written in JS, that is the main approach to using a self hosted version of this library. So you will need to make that, which is where you will handle answering and rejecting calls. It can be super simple, just display a name of who is calling, and 2 buttons to answer and reject calls.

Also you'll notice that we only allow this for android versions >= 8, this is because self managed connection services were not introduced until android 8! Keep this in mind!

Hopefully this helps!

[mmatheusmmiguel]

@mmatheusmmiguel no problem, I have added the code I use for the notification extension service and the headless task here in this gist.

The headless task code includes the wake lock, the notification extension calls it.

Keep in mind, we send everything we need from opentok (session id, username, token, etc) from our backend to the push notification payload under a specific android channel id, and we listen for that in our extension service. Once we get that, we prep the data to send to the event emitter, and then parse it out in the RN app accordingly.

For example, when we get the data we need from the notification, we store that in asyncstorage, and navigate to our video chat screen where we connect to the session using the data. We also use a custom incoming call screen written in JS, that is the main approach to using a self hosted version of this library. So you will need to make that, which is where you will handle answering and rejecting calls. It can be super simple, just display a name of who is calling, and 2 buttons to answer and reject calls.

Also you'll notice that we only allow this for android versions >= 8, this is because self managed connection services were not introduced until android 8! Keep this in mind!

Hopefully this helps!

Thank you @jayrenteria

Do you use a native module for these codes or is it in the CallKeep library itself?

[jayrenteria]

@mmatheusmmiguel both of these live right in the android app itself, alongside the MainActivity and MainApplication java files.

[mmatheusmmiguel]

@mmatheusmmiguel ambos vivem diretamente no próprio aplicativo Android, junto com os arquivos Java MainActivity e MainApplication.

Hey @jayrenteria
Is this notificationextensionservice.java a standard Android intentservice?

[jayrenteria]

@mmatheusmmiguel They are, and you can find more info about them here (this is OneSignal specific documentation though): https://documentation.onesignal.com/docs/service-extensions

[HarshitPadalia]

@sunweiyang can you tell me how did you implement it with opentok react native sdk I also want to implement this sdk with my react native project using opentok react native sdk thanks in advance

[manuquentin]

Fixed by #395