I have an FP6 running e OS 3.5 official, and am unable to get wifi calling working under e OS 3.5, but under the stock non-de-googled FPOS, SMS and wifi calling works perfectly.
I have tried everything I can think of. I was on e OS 3.4 and the earlier versions, and realised that wifi calling wasn’t working but let it go for a while. I then got around to following the recommendation of “Reinstall stock FP OS and use it for a while to activate IMS” and under the stock FPOS, wifi calling is enabled, it has the wifi calling/VoWifi status bar icon showing, and functions as expected (making phone calls and sending SMS over wifi when in aeroplane mode, is the way I test it).
Once confirming that it wasn’t a hardware issue because wifi calling works under the non-de-googled FPOS, I then wiped the phone and re-installed e OS 3.5 and relocked the boot loader. I can (and have always been able to) toggle wifi calling ON under e OS, however no status bar icon has ever shown up, and I cannot send/receive SMS over wifi nor make phone calls over wifi when in aeroplane mode under e OS (currently v3.5 but was also an issue on v3.4 and also earlier versions).
Are there any hidden special settings that need to be checked or adjusted? Yes, I have located and toggled wifi calling to ON, and ensured that it is set to make calls over wifi as the preferred option. I have rebooted, I have turned aeroplane mode off and back on and back off, over and over again, trying to trigger it to work, but it doesn’t. Yes, my account allows wifi calling, and yes it always works under FPOS or on any other stock Android or iPhone device, so it isn’t a telco account problem.
I have also experimented with changing the internet APN from telstra.wap to telstra.internet and this also didn’t make any difference (am located in Australia).
Is there anything else I can try, or is wifi calling just not supported on FP6 with e OS?
*#*#INFO#*#* (~equal to *#*#4636#*#*) gives you status information. Imo most useful to show if IMS registration is successful. It too will tell if vowifi (or volte) is available at that point in time. When I checked on my FP3, it said “wificall unavailable”, rebooted to trigger SIM re-registration, wificall was available and it made the next call on wificall.
Do you do anything custom for DNS? providers want you to use their DNS for their tunnel endpoints to work.
tunnel?..
VoWifi is a negotiated ipsec tunnel on UDP port 500 / 4500 with your providers endpoint - then “volte” minus the -lte happening over that. One can passively watch at the router level if it occurs.
Wifi calling also does not work on my FP6 with e/OS 3.5. Both VoLTE and VoWIFI are enabled in settings. VoLTE works fine because my phone number appears next to IMS. But when I enable airplane mode and then enable wifi, there is nothing next to IMS. I’m running a private DNS on the phone but disabling it did not make a difference. So IMS is registering correctly with VoLTE but when only wifi is active, it does not register. Is this a e/OS issue, a firmware issue or doesn’t my carrier support VoWIFI on phones running custom ROMS? Unfortunately I installed e/OS straight away and did not test VoWIFI on FPOS. I just tested wifi and mobile data as well as regular phone calls while on FPOS.
Hello! Nothing custom for DNS, just stock e OS official.
Attached is a screenshot showing that the voice over WiFi is showing as “Unavailable”.
Yes it is enabled/toggled on, and yes I’ve powered off and back on many times. Every other phone I’ve tried with my sim card works with WiFi calling/Vowifi without issues, it is only e OS that doesn’t do it. The same FP6 hardware I have does WiFi calling if running stock FPOS, but it no worky if e OS is used on that same hardware. Very strange!
as said, “unavailable” only tells you so much, it’s not a general judgement for all times (outside the issue you describe).
The value in that screenshot is: the device+sim can register with the IMS stack at the provider, that is good, it’s the basis for any of the Vo* things.
If you’re getting adept at reading adb logcats there could be a clue what’s hindering the tunnel building for vowifi. I did FP3 (not FP6) debugging with ims things and this user had for whatever reasons missing libs.
If vowifi is a widespread issue on the device I’d think it should’ve made its way to the backlog tracker on the FP6 tag.
Since e os 3.4 on FP6 I have the same issue (currently on 3.5 official). And the network is quite bad since then. Before e os 3.4 I never had network issue but since I miss a lot of calls as my FP6 is offline (but the internet connection over 5G is working fine). voWifi not working, voLTE works (when the network is very strong).
And when I’m in a call, network is like full, as soon as I hang up, network status bar drops to almost no network.
All these issues appeared since e os 3.4. Network carrier is not faulty there, as other people in my home do not have any problem on Samsung phones.
And my carrier (Sunrise in Switzerland) is listed as supported for wifi calling on the official Fairphone website… But even with VoWifi option set, I get a not available message in IMS status.
Hope this issue will be solved soon, it’s very frustrating to miss calls (pizza delivery not possible anymore ^^).
I have shared this thread with the developers. Wanted the names of the carriers and location where this issue is being observed.
Those who are facing this issue please provide country you are located in and the service provider name.
I passed the details to the QA team who checked and found it is working. This may be a carrier specific issue. Please can you create an issue on gitlab and attach logs. That will help the developers to understand what is happening with some of the carriers. Please mark the issue as confidential as it may include personal details in the logs.
There are 2 different log file generation commands listed. Which log is needed? Please let me know. Also please advise which specific part of the log file(s) is needed.
I suggest the second “on device” method (as per Manoj’s link) would be best … quite where the problem is seems uncertain … devs can be disadvantaged where users try to select “the problem” so they often prefer “whole logs” to start.
The problem with this method is that it is rather difficult to remove all personal identifiers. The way Gitlab works round this is to have such unredacted logs only on an issue which is marked confidential.
When you used this method did your device generate a Zip file with several logs? This is not so hard to add to a Confidential issue. Edit, if this is a concern (??) the hazard in redacting logs is not that the logs will tell readers “all about your life” only that they contain identifiers of you, your phone, PC, and network details like IP address maybe also regional by coordinates.
For added benefit to others you could link your hidden (confidential) issue to 9208 opened by @Fibo16 while your logs still stay hidden.
I believe issues like this are quite important for devs to research.
