Since the era of 4G, the voice function of cellular networks is no longer supported by traditional circuit-switched systems, but is replaced by IP networks. This means that currently, voice calls on pure LTE or higher-level networks (NR) are essentially implemented as VoIP, which brings an opportunity: why do we have to implement VoIP within the operator's cellular network? We can completely access this IP-based core network externally and use mobile voice and multimedia functions. This is UMA (Unlicensed Mobile Access), also known as "Wi-Fi Call / VoWiFi" that we know today.
The essence of Wi-Fi Call is to establish an IPSec tunnel to the operator's GAN (Generic Access Network) and connect to the IMS core network to transmit voice and multimedia services.
Current Situation#
Using Wi-Fi Call is very simple. For iOS, we only need to enable it in Settings > Cellular > Carrier > Wi-Fi Calling. For Android, there are differences due to system fragmentation, but generally, it can be enabled in the settings of the "Phone" app.
It should be noted that operators do not always (or never) treat customers equally. Similar to eSIM, many operators only provide this feature to postpaid customers (specifically, customers with long-term service contracts), while prepaid customers cannot use it.
When you are in your local area, the only purpose of Wi-Fi Call may be to help you have stable calls and messages in areas with poor cellular signals. Only a few operators may provide special offers for customers using Wi-Fi Call that are different from cellular networks.
However, the situation is different when you are overseas. Since Wi-Fi Call directly accesses the operator's core network, it avoids roaming charges, which can save you a considerable amount of money. However, for operators, this means they lose revenue. This leads them to impose restrictions to prevent you from using Wi-Fi Call overseas. Some operators may also block their customers from using Wi-Fi Call in specific regions due to local regulatory reasons or other factors.
Changes#
How do operators know your location? Generally, there are two main ways: one is the access restrictions built into mobile devices, and the other is the IP Geo information when accessing the operator's IMS.
Mobile Device Restrictions#
Modern iOS and Android devices have network configuration profiles provided by each operator, which define various information about the operator and network connection. For example, whether to allow connection to 4G/5G networks, network access points (APN), and network operator display names. The IPCC (iOS Carrier Profiles) in iOS provides more features, including the operator's regional restrictions on Wi-Fi Call.
For example, operators in Hong Kong generally restrict the use of Wi-Fi Call only within Hong Kong. You may think that you can connect to the operator's core network by using a proxy in Hong Kong. However, you will find that no matter what proxy you use, you cannot connect to Wi-Fi Call. This is because the IPCC in iOS restricts the device from attempting to connect to Wi-Fi Call only when it considers the device to be in Hong Kong. The "region detection" in iOS is actually unrelated to GPS, but rather another set of judgment mechanisms:
- For devices with cellular network connections, the location is determined based on base station information.
- For devices without cellular network connections, the location is determined based on network information.
When you have a device connected to a cellular network, iOS can easily obtain the MNC/MCC from the base station and determine the region you are currently in. When you use a device without cellular network capabilities or in a state without a network/flight mode, iOS will use network-based region detection. Specifically, it uses the country code returned by https://gspe1-ssl.ls.apple.com/pep/gcc to determine the region.
Therefore, when we put the device in flight mode and let Apple's network region detection API access through a network proxy in the specified region, we can bypass the operator's restrictions on Wi-Fi Call on our device.
Is there a more direct solution? Yes, just go to Settings > Privacy and Security > Location Services > System Services, and disable the location permission for "Wi-Fi Calling" (known as "WLAN Calling" on models sold in mainland China). Of course, you still need to put your phone in flight mode to bypass the region detection based on cellular network base stations.
Updated on August 25, 2023: After further practice, it was found that this option does not affect the WiFi Call detection on iOS. It is speculated that this feature may be used for e-911 geolocation detection and transmission.
GAN Access Restrictions#
Since device restrictions mostly only apply to iOS devices, some operators further restrict GAN access based on IP Geo. For example, ClubSIM in Hong Kong not only restricts access to devices in Hong Kong in the IPCC but also restricts access to only Hong Kong IP addresses.
In addition, readers in mainland China also need to consider the issue of the national network firewall (GFW). In the second half of 2022, the GFW blocked some T-Mobile Wi-Fi Call access point IP addresses, causing many people's Wi-Fi Call to be intermittent or unable to connect at all. Various methods had to be used to find and try to connect to the IP addresses that had not been blocked.
Bypassing IP restrictions is simple. We only need a network proxy to solve it. However, by default, Wi-Fi Call IPSec traffic is not routed through the local VPN (including traditional VPN and VPN interfaces created by applications). Android users can solve this problem by using iptables after rooting, but iOS did not have a way to do this until version 16.4. However, things have changed after iOS 16.4. iOS provides a new API that allows the routing of cellular IP service traffic through Network Extension, and Surge for iOS was the first to support this. If the reader meets the conditions of iOS 16.4+ and has the latest feature subscription for Surge, just add the following module:
(Updated on August 25, 2023: Currently, this feature does not work on the new version of Surge, and it also does not work when reverting to the initial version of Surge that added this feature. It is suspected that iOS may have restricted NE's takeover of low-level connections in the system.)
#!name= Enable Wi-Fi Call for Local VPN
#!desc= Allow Wi-Fi Call traffic to be proxied through local VPN
#!system=ios
[General]
include-all-networks = true
include-cellular-services = true
If you want to have more fine-grained control over Wi-Fi Call traffic, such as using SIM cards from different countries on dual SIM phones, you just need to refer to the Surge rule below.
For readers who are already using gateway proxies (transparent proxies at the gateway level, including various bypass routing schemes), you only need to add a few rules to the gateway proxy to achieve it. However, if you do not want all device traffic to be routed through the gateway proxy for various reasons, then we need a little bit of routing magic.
Policy Routing#
As mentioned at the beginning of this article, the essence of Wi-Fi Call is an IPSec tunnel, and IPSec tunnels use port 500 UDP and port 4500 UDP. We only need to mark the traffic on these two ports on the gateway and forward it to the proxy or bypass router. If you are using a bypass gateway proxy scheme and the main gateway is based on Linux's control plane, you can refer to the author's solution. The author uses UniFi Dream Machine Pro as the main gateway and Surge for Mac as the bypass proxy. However, if you understand this part, the concept is applicable to any device.
#!/usr/bin/env bash
# Pre Env
touch /run/routing-zero-wifi-call.lock
if [ -f /run/routing-zero-wifi-call.lock ]; then
iptables -t mangle -D PREROUTING -p udp -m multiport --dports 500,4500 -s 10.1.1.0/24 ! -d 10.1.1.0/24 -j WIFI_CALL
iptables -t mangle -F WIFI_CALL
iptables -t mangle -X WIFI_CALL
ip r flush table wificall
ip ru d fwmark 0x65
sed -i "/wificall/d" /etc/iproute2/rt_tables
fi
# Create Routing Table
echo "101 wificall" >> /etc/iproute2/rt_tables
# Create Routing Rules
ip ru a fwmark 0x65 lookup wificall
ip r a default via 10.1.1.233 dev br0 table wificall
# Set Firewall Mark
iptables -t mangle -N WIFI_CALL
iptables -t mangle -A WIFI_CALL -s 10.1.1.233/32 -j RETURN
iptables -t mangle -A WIFI_CALL -p udp -m multiport --dports 500,4500 -j MARK --set-mark 0x65
iptables -t mangle -A PREROUTING -p udp -m multiport --dports 500,4500 -s 10.1.1.0/24 ! -d 10.1.1.0/24 -j WIFI_CALL
In this script, 10.1.1.0/24 is the IP range of the LAN network, and 10.1.1.233 is the IP address of the device where Surge for Mac is located. Our idea is to forward all traffic in the subnet, except for the traffic sent by the bypass proxy gateway, with the destination ports of 500 and 4500 UDP and the destination IP not being the local network, to the bypass gateway for processing. The method is to set a firewall mark (FwMark) for all traffic that meets the above conditions and add a policy route to let the main gateway forward traffic with these marks to the bypass proxy gateway.
Afterwards, we need to add some rules to the proxy program to make all traffic on port 500 UDP and port 4500 UDP be forwarded using the proxy of the corresponding country based on its destination IP Geo. Taking the Wi-Fi Call using US/HK/UK SIM cards by the author as an example:
[Proxy Group]
US Wi-Fi Call = select, US Proxy 1, US Proxy 1
HK Wi-Fi Call = select, HK Proxy 1, HK Proxy 2
UK Wi-Fi Call = select, UK Proxy 1, UK Proxy 2
...
[Rule]
AND,((GEOIP,US),(AND,((PROTOCOL,UDP),(OR,((DEST-PORT,500),(DEST-PORT,4500)))))), US Wi-Fi Call
AND,((GEOIP,HK),(AND,((PROTOCOL,UDP),(OR,((DEST-PORT,500),(DEST-PORT,4500)))))), HK Wi-Fi Call
AND,((GEOIP,GB),(AND,((PROTOCOL,UDP),(OR,((DEST-PORT,500),(DEST-PORT,4500)))))), UK Wi-Fi Call
...
Clash and other mainstream proxy software have similar logic judgment rules, and you can try to modify and use them yourself.
IMS Status#
It should be noted that some operators, such as all operators in Hong Kong (except for CSL series, including sub-brands like ClubSIM), only implement voice access and do not have access to multimedia systems. This means that when you are not connected to a cellular network at all, you will not receive text messages! These operators literally provide Wi-Fi "Call" to customers.
In Settings > General > About, click on "Carrier" to switch display information and view IMS status in Wi-Fi Call mode.
The following is an update on April 14, 2023
Things are changing. After the release of the iOS 16.4 update and the CMHK 54.0 IPCC update, CMHK allows sending and receiving text messages in Wi-Fi Call mode, making it finally complete!
