I’m trying to make sense of the available modems/LTE bands and match them up to US MVNOs. Since my current phone (Galaxy S3) is on the Sprint network, I’m leaning that way for the L5, even though the BM818-A1 seems to fully cover both Sprint and Verizon.
T-Mobile seems to use custom SIP over IPSec. WiFi calling only works when you buy a phone from them. They store something custom in the phone’s firmware. It might be possible to extract the IPSec key and use a modified SIP client to authenticate over HTTPS. Unless if someone has done this already, I doubt that this is happening any time soon.
Other carriers might do something different. After the T-Mobile-Sprint merger, WiFi calling might change, or even go away. They are merging for increased spectrum/coverage, and WiFi was created to solve their coverage problems.
I did a live chat with Twigby the other day. They don’t do Wi-Fi calling, but considering the bands covered by the BM818-A1, they were optimistic that they would be able to provide service for the L5 – especially after the Sprint/T-Mobile merger completes.
They said that they would need to check the IMEI to be sure, but they had no restrictions regarding phone manufacturers and were OS-agnostic and the thought of a Linux phone didn’t put them off at all.
It is all very well with WiFi calls because then I can use our fiber net at home. However, I would much prefer a small LTE stsation connected to the fiber net. The LTE protocols are much better the the WiFi protocols. I know that Nokia has a small LTE station but the problem is that the law makers do not provide bands for using these. I suppose the situation is different in the US. Considering the lousy signal strength we have in our village it would be nice to have an own relay station. And it would give us the possibility to have internal phone calls (and data connections) locally.
Another way to do WiFi calls is to use a VoIP provider who provides SIP and call forwarding at the same time, or if the SIP fails. That phone number will not be able to receive texts, but you will get a call over WiFi if it is available, and failing that, it will forward to your cell number.
WiFi 6 will make WiFi more suitable for voice in crowded bands, and WiFi 7 will improve upon that even further. The Librem 5 uses Wi-Fi 4 (802.11n). I hope that the next phone skips to WiFi 6 as it will bring battery life improvements, and the improvements in WiFi 5 are more suitable to power and bandwidth hungry desktops/laptops.
In residential VoIP service terms, you are looking for a “Bring Your Own Device” softphone option, with call forwarding or a ring list. On the Librem 5, you will run a SIP client for the BYOD option, and call forward to the phone number on the Librem 5’s modem. If you use a simultaneous ring list, you will get the call in both places at once, which might be annoying depending on how receiving calls in both places at once works, GUI wise. Maybe someone can customize the software to make this kind of solution easy. The call forward feature or sequential ring list will probably ring the softphone first, and if it does not pick up or is not connected, it will forward to the cell modem.
After a simple search, 1-voip.com looks like it might work, but I have no experience with their service, and I am sure that there are plenty of other options, so do you own research.
Because the VoIP solution is not integrated into the cell modem, service will not transparently switch between WiFi and cell calls. Although a call transfer feature, if available, can be used to make this happen manually. In theory, someone could make a VoIP provider and VoIP softphone bundle that makes this transparent by establishing calls through both WiFi and cell simultaneously and quickly flip the conversation between the 2 when needed.
One downside to this solution is that outgoing calls on the modem will use a different caller ID by default. There is an upside too. You get an incoming number that does not change no matter what phone or carrier you use.
Please note that this is not “WiFI calling” as commonly understood.
Usually “WiFi calling” refers to voice calls via WiFi over the IMS network of a provider.
It is an open standard and widely available in various phones.
Republic wireless does use WiFi and does support calls over WiFi, but it is not “WiFi calling” over IMS.
Instead it is an entirely proprietary VoIP system that is not compatible with any phone, any 3rd party implementation or even interoperable with other networks.
Republic handles the gateways from their proptierary VoIP system to other networks.
Their apps are closed source, use proprietary transport mechanisms and are not compatible with any other network.
Custom firmware is not required.
However, carriers do whitelist phones and their VoLTE/VoWiFi implementations, which is quite unfortunate and I whish it wasn’t the case.
That said, it is their IMS and their choice which clients they allow.
There likely are providers that do not use whitelists (though they are likely rare), but more importantly, there are 3rd party IMS implementations, including open source ones, which could be used with the VoWiF clients on any phone, which certainly qualifies it as an open standard, and certainly is quite an advantage over “Republic”, where no open source implementation exists on either end.
Edit: it also should be noted, that an opensource VoWiFi client could be developed and might be certified by various carriers free of charge if it works correctly, which is an approach that certainly should be attempted.
Not a verification in any way that it will be implemented, but in the mockups by Purism to redesign the wi-fi and cellular pages in Gnome Settings include a toggle switch for Wi-Fi calling.
So, at the least Purism are not ignoring it completely!
My understanding is that “every” carrier implements WiFi calling (and WiFi SMS for that matter) slightly differently even if it’s only configuration data. So there would be a fair amount of code changes, testing, fielding of support requests, … before even the most relevant carriers world-wide would be working. Maybe VoLTE is considered more urgent and higher priority (suffering as it does from a similar problem of trying to test “every” carrier, understand what is working and what is not, and get solutions where needed).