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.

      alankeny

      Alan, I thought I'd share this here, and ask for your thoughts.

      As I wrote earlier, the problem I've had is that after several minutes of not actively using Cheogram, when someone calls me my phone rings far too long after the caller has already hungup, but this happens only when relying on cell service, I've never been able to make this problem happen on wifi.

      The jmp folks told me they believe that, for some reason, Cheogram was "losing its connection". Not exactly sure what that means, and they didn't offer to do anything about it. So, I didn't/don't know if it is a Cheogram problem, or a Graphene problem..... or both, or neither.

      I hit upon this idea to test things, and to rely on as a workaround until some smart person fixes this. (The workaround I need is to somehow make my phone reliably ring without delay when I am called.)

      I already had Cheogram running, using xmpp account X , but of course suffering with this problem we're discussing. I installed the Snikket app on my phone, and connected it to the same account X. Then, I waited several minutes when I knew I'd have the problem with Cheogram losing its connection and not ringing for a call. Then I called my phone. As expected, the Cheogram app did not ring. But, Snikket did immediately. So, from this, I concluded that (A) There likely is something wrong with Cheogram, and not Graphene; and, (B) In the short term my workaround is to turn on my xmpp account X in Snikket when I'm relying on cell service.

      Interested in your thoughts on my test and conclusion before I turn to the jmp support people with this.

      • de0u replied to this.

          dln949 Good debugging move! Hopefully one or another developer will ask you to submit an AOSP bug-report dump, which contains an event log. Comparing one for each app could be very revealing to the right set of eyes.

            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?

              alankeny

              "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?"

              Yes, I was using dialer integration. So, I turned the dialer integration off in Cheogram, but I still had the same problem with Cheogram not responding.

              Question: What is your opinion - Is what I've been trying and seeing enough to pass to the JMP support people in the hope they'll take interest in this and pursue it? I'm not a tech person at all, so I don't know how to evaluate if this is enough information to generate interest in them.

                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.

                  alankeny

                  I'm very interested in hearing how your LineageOS tablet test works.

                  I'm wondering: I thought that there were a lot of people using Cheogram on GrapheneOS, but why aren't there lots of other people complaining about this same problem? Or are they complaining about this in other places I might not be aware of???? Otherwise, could it be we have some oddball combination of settings or whatever that causes us to bear this burden?

                  Not sure what this might tell us, but here goes: I ran another test. As you know, I've never had problems receiving calls while on Wifi. So, I turned off both the cell radio signal AND Wifi to my phone. Then, I called the device - I let it ring five times and hung up, so never got the jmp recording to leave a voicemail. Then, I waited five minutes. Then I turned just the wifi back on. IMMEDIATELY my phone rang with the popup saying that there is an incoming call. Of course, there wasn't an incoming call at that time, since I had hung up five minutes earlier. And of course, this is not the expected action: If my phone is off when someone calls me, when the phone comes back on, I expect a missed call notification, not a (false) currently incoming call notification. Is this related to what we've been discussing? I'm not techy enough to say.

                  • de0u replied to this.

                      dln949 Also an impressively creative experiment! Thanks for sharing.

                        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.

                          alankeny

                          Your plan makes sense, and I think the developers should pursue seeing why Snikket "helps" when Cheogram could not maintain a connection. But.......

                          Yesterday I upgraded to GOS 20230050500. The problem seems to have gone away. Whether on cell signal or wifi, no matter how long Cheogram is idle, all calls now ring immediately as they should.

                          At first blush I'd say, Well, there was a problem with GOS. But, on the older versions of GOS, why would Snikket work but not Cheogram? That is why I would want the Cheogram people to look into this - I don't want the next upgrade of GOS to mysteriously break Cheogram again.

                          What version of GOS are you using? If you can without disturbing your testing plans, can you see if the new version of GOS solves your problem as it has mine? (I'm also using version 2.12.1-5+free from F-Droid of Cheogram.)

                              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.

                                5 days later

                                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.