Since the update from 1.4 to 1.5 (Android 10 to 11) on my FP3 WiFi-Calling no longer works.
On 1.4 WiFi-Calling was working without any problems. So Provider supports Wifi-Calling, Wifi-Calling is activated on the Phone and prefered when dialing
I hoped that 1.6 will fix it but it didn’t. So I rolled back to Fairphone-OS and installed a fresh /e/OS 1.6.
→ WiFi-Calling is still not working.
I tried every Tipp or Workarround an this Forum, but nothing fixed the Problem.
OS Verision now: /e/OS 1.6-20221129238947-stable-FP3
I called my provider (congstar), they checked everything and told me it’s all correct and Wifi-Calling should be working. I also made a Wifi-Call with my SIM in another Phone. It worked.
I think it must be my phone because wifi-Calling stopped working directly after the update from 1.4 to 1.5 (Android 10 to 11).
Usually I don’t use Wi-Fi Calling, so I don’t know much about what could go wrong (apart from the whole thing in general for more or less comprehensible reasons).
For testing I …
enabled Settings - Network and Internet - SIMs (I only have one) - Wi-Fi Calling
in the same place made sure Calling Preference was set to Call over Wi-Fi
In Settings - Advanced Privacy my real IP address is exposed.
Thank you for your answer. I tried everything you said and other things too. I checkt allot of the settings twice, but still no Wifi-Calling.
But today something strange happend: I got a Call with Wifi and Airplanemode on and it said: incomming Wifi-Call !!! So I was surprised by it.
Immediately after the call I tried to make a call over Wifi. But then the old message popped up again:
“Mobile network isn’t available. Connect to a wireless network to make a call.”
What is going on? Seems like there is only a problem with MAKING a call and not getting one!
Its frustrating…
do you set any DNS servers yourself, either on-device or custom ones via dhcp? if so, give the ISP supplied a try. But this used to be only an issue with Vodafone that infers eligibility from the used DNS - might be moot with congstar. Incoming working but outgoing? really weird. Do you filter udp port 500 and 4500 ?
looking at “adb logcat” while trying to place a wifi call (you can set it to prefered so it will give it a try first) maybe yields a verbose reason for it to fail?
From your description the reason must be on-device. But still would be helpful to tcpdump at the router if any dns querys for 3gppnetwork.org occur and packets to udp 500/4500 leave the device.
here’s a (lengthy) german article on the wifi perspective, but as I said I think issue must be on-device.
This post does not give conclusive advice, nor does it mention wifi-Calling, but does demonstrate some of the issues found with #apn + #fp3FP3 roaming/APN not working.
Of course they cannot see the APN settings on your device, and they may think that their settings have been issued to you on the fly. I suggest you call them again and ask to have the full APN settings sent direct to your device.
Less recommended
You can check your settings and try to edit them manually from Congstar’s own published APN settings. In my searches I found unusual variance in recommended settings as in this article (which I do not particularly recommend, but include only because it seems to show up unusual issues with Congstar’s settings).
Thanks for your answer. It took a while and I talked to congstar asking them for the right APN Config. I changed some settings back an forth, but no luck with the Wifi-Call. Still the same problem.
from the log it seems it stays in the cellular connection at all times, no try at wificall at all. I’ll be with a FP3 next weekend that has known to work wificall (with telefonica) and document the loglines. I found these relevant, but hardly a hint on what is going on or missing:
The cne is a connectivity helper determining network quality and capability. Maybe it’s denying the use of the wificon - lots of speculation. Will update next weekend.
Wow… thanks allot for your help. I’m excited. After month of trying I’m so happy to see some progress - no matter where it will lead to at the end.
Wifi-Call at my home is very important because very often there is no mobile connection. So most of the time Wifi is the only way of getting mobile calls at all.
imho you have missing system libs at /system/ for whatever reason. But the comparison isn’t clean as my FP3 is already on Android S, maybe it had different libs in R but that’s unlikely.
WifiCalls were possible at all times with the FP3 and Telefonica. I could post the full log of successful call initiation, but I think it’s obvious you’d need to solve the “dlopen failed” (well, file missing) at
[ 01-29 15:02:13.576 1999: 2648 E/AndroidRuntime ]
FATAL EXCEPTION: FrameworkReceiver
Process: .qtidataservices, PID: 1999
java.lang.NoClassDefFoundError: com.qualcomm.qti.VndFwkDetect
at com.qualcomm.qti.cne.relay.WlanStaInfoRelay$CountryCodeRetriever.getIsVendorEnhancedFramework(WlanStaInfoRelay.java:540)
at com.qualcomm.qti.cne.relay.WlanStaInfoRelay$CountryCodeRetriever.retrieveCountryCode(WlanStaInfoRelay.java:605)
at com.qualcomm.qti.cne.relay.WlanStaInfoRelay$2.onCapabilitiesChanged(WlanStaInfoRelay.java:217)
at android.net.ConnectivityManager$CallbackHandler.handleMessage(ConnectivityManager.java:3624)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:223)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/system_ext/lib64/libvndfwk_detect_jni.qti.so" needed or dlopened by "/apex/com.android.art/lib64/libnativeloader.so" is not accessible for the namespace "vendor-classloader-namespace"
at java.lang.Runtime.loadLibrary0(Runtime.java:1087)
at java.lang.Runtime.loadLibrary0(Runtime.java:1008)
at java.lang.System.loadLibrary(System.java:1664)
at com.qualcomm.qti.VndFwkDetect.<clinit>(VndFwkDetect.java:40)
... 7 more
On my phone there’s the lib-file at the same path, too. So it’s not missing.
I can make a clean install again. But I wonder why at first place the system libs didn’t come back. I mean, I already rolled back to FairphoneOS as the problem first appeared. Then I installed /e/OS 1.6 over EasyInstaller.
Why didn’t this fix the missing system libs? Do I this time have to do it different? Should I include or consider this time something more? Is there a way to “clean” the phone-memory?
don’t know… selinux has also a say in what can be accessed. Really don’t know what went wrong, but the exception is obvious that a this time the process can’t access it - can be a permissions issue. Welp, not sure how to think of reasons, I’d just reflash
