VOIP app intermittently not notifying for incoming calls

@dln949: Your problem may have the same underlying cause as mine, but I'm not prepared to do much testing for your use case right now. I signed up for a data-only SIM from JMP, but haven't received an invite yet. The rates on my current data-only SIM are really high, so my testing has been limited to Wi-Fi only. I also wanted to eliminate data-saver as a possible cause, and I don't need it enabled on Wi-Fi. Just for clarification though, are you saying you never experience missed call notifications while on Wi-Fi?

@SilkSow: I experienced something similar and asked Cheogram Support about it too:

As a result of the network issue, the phone receives a call request, but a cancel request is never sent because the other side sees the connection failure and does not send the cancel request as it assumes it is unnecessary. So when your device finally connects, it still receives the call request that was queued up on the server, but never a cancel request.

Devs forgive me if I'm way off base here. It's been years since I've done this kind of troubleshooting, and Android has changed a lot since then. I'm wondering if this is a message buffering issue rather than a network issue. The phone receives the incoming call notification from the server, but doesn't process it because the screen is asleep. Waking up the screen flushes a buffer and the notification comes through. Ping requires a response from the phone, which may also flush a buffer.

Answering my own question regarding other workarounds: I'm going to test a few different notification settings. I'm wondering if changes to any of these will make the phone process the incoming call notification more consistently.

As a last resort I will also try enabling always-on-display. Normally I'd worry about battery life, but that's been so good with GrapheneOS, it may be a viable solution.

dln949

I'm probably using an old name for the setting. I've enabled it under Settings > Display > Lock Screen > Always show time and info. After enabling this option, I still had missed calls or delayed notifications. As soon as I touch the screen to "wake" the phone, even though the screen is already on, the incoming call notification pops up immediately.

If I leave the phone plugged in to power, I don't seem to have any problems with missed calls or delayed ringing. In this case it doesn't seem to matter if I use a screensaver to keep the screen powered on or if I let the screen completely power off.

A recent post on the JMP blog mentioned that a new version was released or soon to be released. JMP support didn't say anything about possible fixes in the new version though. They specifically noted a change in GrapheneOS about five or six months ago that seemed to be the start of the problem. I'll try out the new version though as soon as I can get it from F-Droid.

The last time I tried to make VOIP work reliably on mobile, I was testing SIP clients on various Android devices. That included a bunch of nastiness related to NAT, push notifications, and power management. At the time some of the developers I was talking to indicated that Android offered multiple ways to open network connections that only differed in how they worked with power management. Some of these differences were supposedly based on the way the app opened the connection to the server, and other differences were the result of the way the underlying Android operating system processed those connections.

I never found out if this was something unique to Android's socket handling, or if they were really just talking about SIP over UDP versus SIP over TCP. At the time everyone seemed to think one worked so much better than the other, but they couldn't agree on which. Spoiler alert: they both sucked, and I gave up on SIP clients entirely.

All of this is to say I don't know if GrapheneOS has a role in this or not depending on how Cheogram and Snikket open their connections. The simplest answer is that GrapheneOS doesn't, and it's all up to the app handling the connections, so I'm going to start there.

I've configured Cheogram and Snikket with the same XMPP account I'm using for my JMP.Chat phone number. It looks like I can tell which app handles the incoming call based on the color of the notification when the call comes in. Unfortunately I have to let my phone idle for a few hours on Wi-Fi to get Cheogram to consistently miss a call.

I'll run a test this evening and another over night. I've disabled dialer integration in Cheogram to make the tests as similar as possible. If Cheogram misses the call and Snikket doesn't, I'll have something to compare for more troubleshooting.

@dln949 Are you using Android system dialer integration in Cheogram? If you are, does disabling this feature make Cheogram behave the same as Snikket for you?

In my case JMP Support has already told me they think something changed in GrapheneOS five or six months ago, so they don't think it's their app. I feel like it's probably their app, but I'm going to need to rule out several other variables to focus on just their app. I don't think they're going to take any serious interest in my issue, until I can isolate the problem to Cheogram.

My test calls last night and this morning rang through Cheogram successfully both times without the dialer integration enabled but with Snikket running in the background. I'm going to run the test this again without Snikket running in the background and without dialer integration enabled. If that combination works, it probably means my problem is related to the dialer integration feature.

Keep in mind I'm just trying to get where you already are: reliable incoming calls on WiFi. I haven't been able to test incoming calls over LTE data yet.

I also realized I've got an Android tablet running a comparable version of LineageOS. I'll setup a similar test on it. If Cheogram has the same problem on GrapheneOS and LineagOS, it's harder for JMP support to point the finger at GrapheneOS.

I suspect that the majority of Cheogram users are focused on SMS and text chat rather than VOIP calls. It seems like for many people, unreliable incoming calls are a feature not a bug, because the calls are easy to ignore. I may just be really cynical though too.

So far the results of my testing with LineageOS have been entirely random. There's nothing consistent between GrapheneOS and LineageOS. Both have successful incoming calls most of the time, but both also randomly fail. An idle time on the device of some time-frame longer than one hour seems to be a factor, but I haven't found the actual cut off point yet.

@dln949: Your test seems to confirm what JMP support told me, and I noted in my reply to @SilkSow earlier. The JMP Chat server queues up an incoming call notification for your phone, but it can't be delivered. When the caller gives up, their side doesn't bother sending a cancel request, because the call never went through. When your phone goes back online, the incoming call notification in the queue goes through, but there's no call available any more.

While this notification flow is less than ideal, I'm guessing it has something to do with the way Conversations / Snikket / Cheogram use unified push notifications that are separate from the actual voice call. It may also have something to do with the way voice calls are layered over the top of chat sessions in XMPP.

I think your issue and my issue are related in that Cheogram isn't maintaining a reliable connection to the server for notifications. In my case part of the WiFi or network stack is going to sleep, so Cheogram loses the connection. In your case the connection isn't being reestablished when you switch from WiFi to the cell radio. The phantom call is a result of the lost connection, so we have to figure out how to keep Cheogram from losing the connection in the first place.

I've run several more tests over the last few days. I haven't found any reliable fixes yet, but I can rule out some things that don't seem to matter.

Dialer integration enabled or disabled in Cheogram doesn't seem to matter. Incoming calls are missed at roughly the same rate.

GrapheneOS vs LineageOS doesn't seem to matter either. Incoming calls random fail on both at roughly the same rate. Neither one consistently receives calls better than the other.

I've noticed that devices may randomly take longer to answer than others. After leaving a Pixel 4a running GOS, a Pixel 7 running GOS, and a tablet running LineageOS idle over night, when I called my number the next morning, the tablet rang through immediately, the Pixel 7 rang through after two rings, and the Pixel 4a rang through just before the call went to voicemail. Given my earlier test results, I don't think these differences are related to hardware or OS as much as what the device was doing when the call came in.

I've extended the time before the call goes to voicemail to see if makes it easier to receive an incoming call notification. This isn't a real solution though, because most people aren't going to wait around for eight or nine rings on their side to leave a voicemail.

Since the hardware and OS don't really seem to matter, I'm going to switch to concurrent tests of Cheogram on the Pixel 4a running GrapheneOS and Snikket on the tablet running LineagOS. If I can consistently show that Snikket receives calls when Cheogram doesn't, I can ask the developers if there are any fixes to Snikket they could merge that would make Cheogram more reliable.

dln949
I upgraded to GOS 20230050500 and Cheogram 2.12.1-5+free on Saturday on my Pixel 4a and Pixel 7. I also upgraded my tablet running LineageOS to Cheogram 2.12.1-5+free. Each device also has Snikket 2.12.2+free installed. My tests have been run with either Snikket or Cheogram, but not both at the same time. All of my tests have been limited to WiFi, because I don't have a cheap data plan for my Pixel 4a yet. Since the upgrades on Saturday here's what I've found.

• Snikket handles incoming calls on all devices reliably. I've honestly never seen Snikket fail to handle an incoming call.

• Cheogram seems to be reliable on LineageOS, but this also could be the hardware / power management just being different on a tablet.

• Cheogram on GrapheneOS on the Pixel 4a reliably handles incoming calls after two to two-and-a-half hours of idle time while not plugged in.

• Cheogram on GrapheneOS on the Pixel 4a does not handle an incoming call after being left idle over night for eight hours while not plugged in.

• If I leave the Pixel 4a running Cheogram idle over night and call it the next morning, it won't handle the call, but as soon as I ping the Pixel 4a, it immediately starts ringing.

Latest observations:

• Testing idle times on a phone for longer than two or three hours during the day is extremely difficult. So many other things happen that might wake the device, testing overnight seems to be the only way to get reliable idle tests that run longer than a few hours.

• Snikket is clearly doing something right. No matter the device, idle time, or power conditions, incoming calls just work. If it had the Android dialer integration features, using Snikket over Cheogram would be the obvious choice.

• I should load stock Android on my Pixel 4a next. While Snikket is doing something right, it's not yet possible to conclude that Cheogram is doing something wrong. If Cheogram can't handle an incoming call on stock Android after idling over night, I think it should be safe to conclude Cheogram has a problem that needs to be addressed.

I decided to leave my Pixel 4a alone for a few days and continue testing with GOS 20230050500 and Cheogram 2.12.1-5+free. The problem of Cheogram not handling incoming calls after being left idle and unplugged over night hasn't happened since that first test. I've called my JMP.Chat number every morning over the last several days, and the incoming call notification has worked every time.

I too have concerns that this will break after an upgrade. I'll continue to monitor incoming call notifications closely. If things break at least I'll know which versions were known to work together, so I can try to go back.

For now it looks like GOS 20230050500 and Cheogram 2.12.1-5+free have resolved my issues.