That is a great summary! One note I'll make (as someone who did experience this calling issue), if I took the same exact physical SIM card out of my pixel and put it in my iPhone 14, it worked perfectly.
I think that is what made it seem to many ppl that this must be either a phone hardware or software issue vs. something to do with a carrier or signal strength.
treenutz68 One note I'll make (as someone who did experience this calling issue), if I took the same exact physical SIM card out of my pixel and put it in my iPhone 14, it worked perfectly.
I think that is what made it seem to many ppl that this must be either a phone hardware or software issue vs. something to do with a carrier or signal strength.
That may well be a useful clue. But I suspect it would be useful to the kind of person who drives around in a truck full of $100,000 worth of cell-site diagnostic equipment, much more than it would be useful to the GrapheneOS development team -- who likely aren't RF experts, likely don't have access to cellular diagnostic equipment, and definitely don't have access to cellular-modem firmware source code.
There are a lot more iPhones than Pixels. If -- hypothetically but plausibly -- there is a carrier issue that affects Pixels more than iPhones in marginal-signal conditions, a carrier might decide to invest zero effort in fixing the Pixel issue. I think it is plausible, because the cellular modems in iPhones and Pixels, when coupled with their respective antenna systems, quite plausibly behave better/worse in different parts of a carrier's spectrum.
Cellular systems are complicated. If something breaks completely, it's often not too hard to figure out what that thing is. But if something -- something in a cell site or something in a handset -- is intermittent, that's genuinely much harder to diagnose, even for an on-site expert.
For a user experiencing dropped calls, getting a definitive diagnosis for a complex problem may be completely irrelevant. The best solution for such a user might be switching to an iPhone... or switching carriers... or installing a femtocell. But this problem may well be non-diagnosable by the GrapheneOS team. Even if it's diagnosed, it is likely non-solvable by the GrapheneOS team. I suspect they would like to be able to solve this problem for everybody, but that plausibly is not possible.
This happened to me again today. Last time was a couple of weeks ago. Doesn't happen too often for me but still happens.
Agreed, my sample size of 1 experience likely isn't useful in the grapheneos team diagnosing anything. But it certainly proves to me that in my particular circumstances (carrier/signal strength), an iphone with ios works better at making/receiving calls reliably than a pixel 8 with grapheneos.
If I had to bet, it is more likely a hardware issue than a grapheneos issue. It is unfortunate as I've had issues with the fingerprint sensor as well with my pixel. I know its not quite as expensive as an iPhone, but things I'd consider basics like making/receiving calls and the primary way to unlock the phone should be fairly high on the priority list for google.
treenutz68 Hopefully as Google builds up a fleet of devices with firmware-support and parts-support lifetimes of many years that will help them focus on quality.
Back when one planned to support modem firmware for only three years it might not have seemed worthwhile to fix every bug. But for the recent devices if a bug is found in the third year that's not even halfway through the support lifetime. So it will be interesting to see what happens.
I am waiting for Pixel 9 (new modem) and Android 15 to see if it fixes the issues. Will report when I use both for a while.
I've been having this problem too (Pixel 6a; GOS). I'm on Belong, which is running on the Telstra network. Others in this thread have seen the problem on Telstra, and also on Boost Mobile (also Telstra). I also see some on T-Mobile with this issue.
This might sound a bit out of left-field, but I suspect the problem is 464XLAT. Telstra and T-Mobile are the only two telcos I know of that have deployed 464XLAT.
I found a way to make this issue far easier to replicate. I enabled 4X4XLAT and DNS64/NAT64 on WiFi. I set the "v6-only-preferred" flag on kea DHCP, the "nat64prefix" flag on radvd, and the "dns64" property in BIND9. I had to use radvd 1.20 RC1, as the current stable version (1.19) does not support nat64prefix" (RFC8781).
This caused my phone to connect with a standard IPv6 address, and a 192.0.0.x IPv4 address. You can observe this on the "About phone" page in GOS. The IPv4 address in that range signifies that CLAT is being used. If you're on Telstra, you'll see a similar IP configuration when Wifi is disabled.
When the phone is in this state, it almost always dropped the call. It even happens with a VoWifi call on the same WLAN. Interestingly, my wife's phone (Pixel 7 Pro; Stock Google ROM; Optus) started to have the same issue when connected to WiFi. I don't think this issue is limited to just GOS. It may be a Pixel thing as some have suggested.
If you hook the phone up to adb logcat and call it, you'll see it log when the phone call comes in. It does this without reacting to the incoming call in any way. Sometimes it will display the missed call SMS while the other phone is still off-hook and waiting for the other end to pick up.
If would be great if someone could see if it's just me, or if there is some truth to this.
I've raised issue #4389 on the bug tracker. The handset is sending out VoLTE keepalive packets with a MAC address of 00:00:00:00:00:00, and it breaks the connection to the server.
https://issuetracker.google.com/issues/381164175
I'd like to post this here in case anyone can capture an android bug report on the stock OS. The issue is so intermittent for me that I haven't been able to get one yet. Looks like it might get closed without a bug report.
A bit late to reply:
Having VoLTE or Wi-Fi calling enabled when it doesn't work with your carrier will cause problems.
Many cell providers in plenty of countries have dropped GSM and 3G in the last few years.
VoLTE or Vo5G is the only way to make voice calls.
I don´t use the standard phone calls much, but when I needed it, I missed two important calls yesterday and today.
I am not sure how other brands (like Samsung or others) are avoiding this issue if it is related to AOSP.
I think that I have found a workaround!
I've installed some app which automatically sends an SMS every 1 hour. That's all.
With that activated for almost 1 month now, I did not receiv any "you were unreachable" notification from my mobile provider. Before that It was almost every day and it was escalated in December 2024 with a few missed calls a day.
Device: Pixel 7
Country - Serbia
Carrier - mts
SIM or eSIM - Physical SIM
Is Wi-Fi calling on or off: I don't have that in settings at all. (Why?)
WiFi - always ON
VPN provider (or "none") - none
Mobile data - always ON
Preferred network type - 5G (enabling/disabling 2G doesn't affect the solution)
Battery saver on or off - OFF
"Do not disturb" on or off - OFF
Phone app - DEFAULT
My assumption was that something (GSM modem or some Android's subsystem) goes to deep sleep or something like that and it's not responsive... That was my idea because I have a missed calls in situations when I don't touch my phone for a few hours. So decided to wake it up periodically.
Please report does this helped on your devices.
AND PLEASE: Can you recommend me a FOSS app which can do the same thing. I'm currently using some app from Play Store and I'd like to replace it with some app from F-Droid.
donotworrybehappy yes. I called my cell from my work phone and it went straight to voicemail. No ring on my phone laying right in front of me and no missed call notification.
After more than 2 months I can say that my workaround for this problem (see 2 posts above) works very well.
Zero missed calls during this period.
Since I don't see any comment related to my previous post, I suspect that I wrote it on a wrong place :/
@GrapheneOS , @other8026 , can we do something that more people be informed about the solution of this annoying problem?