I've done the same, switching to iPhone temporarily.
Not sure if this is graphene specific, I don't believe it is but rather is a pixel related issue, but the phone ringing when a call comes in is kind of non-negotiable...
I've done the same, switching to iPhone temporarily.
Not sure if this is graphene specific, I don't believe it is but rather is a pixel related issue, but the phone ringing when a call comes in is kind of non-negotiable...
To my knowledge, this has happened twice:
I have received two phone calls that did not ring. ADDITIONALLY, there is no record of a voicemail being left, in spite of the fact that both people did leave a voicemail (they also sent me an email). This is happening randomly for me, as other phone calls (after the missed ones) are coming thru just fine.
One of the calls was for a job interview.
For a job interview, jeez. Hopefully you were able to get back to them in a timely fashion, that is unfortunate.
Carlito ADDITIONALLY, there is no record of a voicemail being left, in spite of the fact that both people did leave a voicemail (they also sent me an email).
To be clear, if you manually dial the carrier's voicemail number, is the voicemail present? If so, that would suggest that the carrier's message to the phone to turn on the voicemail indicator was lost (perhaps the same way that the call was).
Can we get a comment from any of the graphene devs that might offer some insight? I'm willing to reflash yet again if a log or something would be of assistance. My phone does not ring at all when testing with family.
Might as well sign up and chime in as I have this issue too.
Pixel 7
Build number - 2024062000
Country - Australia
Carrier - Telstra
SIM or eSIM - Physical SIM
Is Wi-Fi calling on or off? - ON (I rely on it)
WiFi - ON
VPN provider (or "none") - none
Preferred network type - Mobile data ON (off at home); Roaming ON; VoLTE ON, WiFi Calling on (at home), 5G preferred when in reception areas
Battery saver on or off - OFF
"Do not disturb" on or off - OFF
Phone app - DEFAULT
I live in on a rural property where the only way I can currently get reception is WiFi calling, except when I go out to town of course. Similar to everyone rise, message comes through to say I missed a call, but no call actually happened. Restarting the phone sure enough fixes it temporarily.
I will say I've only noticed it happen while at home on WiFi calling, but then again I'm at home most of the time I get calls so it's a little hard to say. Even when it does happen though, I can make calls OUT just fine.
I had the same symptoms of this issue caused by call forwarding.
It is sad to see this important issue is neglected by the geapheneOS team. It ocurred to me twice today. After it did not ring the first time (mobile was calling) I immediately triedcalling from a landline and the Grapheneos Pixel did not ring as well. There was no voicebox in both cases and it took a long time until the busy sign came.
The problem occured much more often with an Airtel Tanzania SIM card. The problem was not present when I put this SIM in any other phone.
How can we prove where this problem arises?
schweizer It's unfortunate that some users are missing some phone calls. But so far it seems as if Google may have shipped some unstable code several months ago, and then shipped an update that appears to have worked for a great many people, and then a much smaller number of people are still having missed-call issues.
This sort of problem might be due to multiple factors -- maybe glitches in the cellular modem that miss calls, or glitches in some part of the OS that fail to wake the device, or due to problems in a carrier's network, or thin cellular signal strength. It's even possible, if some users frequently experience missed calls primarily in one particular location, that a particular cell site has a problem (I have personally experienced this). It is quite possible that different users experiencing "the same problem" are troubled by different causes.
In this thread, since June 16 (so let's say two months), if I am counting correctly, there have been seven user reports. One thing that stands out is that I think 7/7 reports were for physical SIMs rather than eSIMS (though I doubt that's relevant). I think I see 7 different carriers in 6 different countries. Though I am by no means an expert on cellular carriers, to my eyes it looks like maybe two large-ish carriers and then five smaller carriers / MVNOs (where technical expertise may be a little thinner). I think two(?) of the reports are from rural areas, where signal strength may be lower.
By comparison, when Google shipped janky Bluetooth code earlier this year, the forum lit up with many threads and many people posting. I say that not to suggest that there isn't a problem when an incoming phone call is dropped! But when an issue has multiple possible causes and not a lot of data points, there may not be a quick path toward diagnosing a particular causal factor. If a GrapheneOS user experiencing this problem happened to be nearby a GrapheneOS developer, that would be useful, but it's not clear that's that's the case.
Personally I live in a bowl on top of a hill, and LTE coverage is terrible. I have a Samsung "femtocell", which makes a huge difference. Amusingly, by sniffing around the neighborhood, it appears that a bunch of my neighbors also have installed femtocells, which makes sense because we all live in a bowl on top of a hill. It's not cheap, but it might be something to try. If a femtocell makes missed calls go away, the problem may have been low signal strength; if not, that might be useful evidence for diagnosing whatever is going on.
Sometimes a carrier will issue a femtocell for free to a customer who complains a lot, though my sense is that may happen only with larger carriers.
Edit: Please note that I do not speak for the GrapheneOS project.
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.