call not received when device locked after a long time

Issue generated from Tuleap's migration script. Originally submitted by: Romain B. (rbertozzi)

If the device is locked since a long time, when someone calls, the device does not ring.

If the device has just been locked, then it is ringing.
 

Submitted by Guillaume Roguez (guillaume)

I'm not sure it's a bug from Ring: the such situation the system may put us or the network into sleep mode (my phone does that, ALL applications don't receive anything from network as the wifi is stopped).
Please make sure that you phone replies to ping in lock state and check the daemon log to see if anything is received or not (the socket may simply be shutdown by the system)

Submitted by Guillaume Roguez (guillaume)

@alision update?

Submitted by Alexandre Lision (alision)

I think this issue may have been fixed by enabling UPnP by default.

It was not the case and devices could become unreachable when  switching from different networks.

We should close this ticket. If problem still exists we will open a new one.

Submitted by Alexandre Lision (alision)

Cyrille seems to say this issue is still occuring.

I am going to mark this as reproductible, and we will investigate on it.

changed title from android: call not received when device locked after a long time to call not received when device locked after a long time

This could be due to routers clearing its the NAT table (timeouts, or new IP due to re-connects) and the OS shutting down long running connections.

And at least in the F-Droid version, due to the removal of google push messaging. You could try using the IMAP-push infrastructure (email) instead.

Testing this, won't even require to include any extra code or library for all the UI and encryption things needed (https://github.com/deltachat/deltachat-core). A small pull request could make the existing front-end app (https://github.com/deltachat/deltachat-android) automatically call configurable "intents", i.e. waking up the Ring app, upon receiving specific messages.

EDIT: processNewMessages() https://github.com/deltachat/deltachat-android/blob/c5701745ebbd031c2aaa536ad47c194cc595c9f3/MessengerProj/src/main/java/com/b44t/messenger/NotificationsController.java#L377

This issue is solved with push notifications when activated.

OpenDHT will be compatible with other push systems like mqtt for example (https://github.com/savoirfairelinux/opendht/issues/241) or indeed we can try IMAP-push, But this issue is located in OpenDHT, not really the android client.

This is a quite complex issue that involves:

• battery power management on device is very restrictive in our case. We need to preserve user experience. See https://developer.android.com/training/monitoring-device-state/doze-standby#whitelisting-cases
• we need to choose a client-server protocol to push information: MQTT seems to be the answer here.
• TCP sessions can be shut down by various elements on a network. Google seems to be experimenting the same issue with firebase. See https://productforums.google.com/forum/#!topic/nexus/fslYqYrULto%5B1-25%5D.

Right independent push messaging isn't that easy, there have been a couple of attempts https://gitlab.com/foss-push/planning/wikis/home but most of the times it also requires providing infrastructure.

Only imap-push can rely on the users' (own or providers') servers. The idea to patch the well working deltachat-android client, was just for testing, proof-of-concept if it solves the problem. The app works nicely, even when the devices are not online all the time, after all it's just an email client to try.

But IIUC OpenDHT would just need to send simple email messages, for testing, that shouldn't need any special tool or lib for testing. (Not even any autocrypt.org functionality)

This issue is solved with push notifications when activated

Forgot to mention, but as known, (un)fortunately, IIUC it is not suitable for F-Droid.

I know, that's why I talk about alternatives just after this ;)

Great, I found news at: https://github.com/savoirfairelinux/opendht/issues/241

As the dht proxy mode already implements a protocol to hold a connection open and subscribe to notifications, maybe another option could be to add the dht proxy protocol to a push-client service that connects to a dht proxy, and implements the tricks to stay running in the background: https://gitlab.com/foss-push/planning/wikis/home

closed

added severityhigh label