Wi-Fi Calling is a carrier-offload feature which enables compatible mobile phones to make and receive cellular phone calls in poor coverage areas over a supported Wi-Fi connection.
A growing number of carriers and devices now support Wi-Fi Calling and I think it is a great feature when implemented properly, as I will discuss in this post. Consideration is needed for a good experience with this feature especially as it is increasingly available in enterprise wireless networks, it is not as simple as being enabled at both the carrier and device ends.
Recently a customer reported issues with Wi-Fi Calling dropouts on their network after updating their firewall configuration to allow the service. It turned out while the network supported the transport of Wi-Fi Calling packets, the wireless network was not designed to support Voice-over-Wi-Fi (VoWi-Fi)!
So I will provide some details around what is needed to ensure a good Wi-Fi Calling experience with reference to some WLAN vendor documentation and packet captures.
First and foremost, your mobile carrier needs to support Wi-Fi Calling. You can expect to receive an SMS and/or email from your carrier advising if and when the service is available.
Here is a page from Telstra in Australia providing details on how Wi-Fi Calling can be used and some FAQs.
Secondly, your device needs to support Wi-Fi Calling. For the testing in this post I have used an iPhone 8. Your carrier should provide a list of supported devices. Telstra have listed theirs here.
Once you have enabled Wi-Fi Calling on your device you should see “Wi-Fi Call” next to your carrier name:
Wi-Fi Calling requires the establishment of an IPsec (specifically Encapsulating Security Payload, or ESP) tunnel between the device and the carrier. Authentication occurs with a key exchange using details on the device SIM card, and a TLS certificate handshake.
The Telstra Wi-Fi Calling article mentions “our current supported handsets use certificates to authenticate, ensuring that both Telstra and the mobile handset confirm their identities securely and the voice call is protected by industry standard SHA2”.
I confirmed this with a packet capture of the Wi-Fi Calling tunnel setup, and confirmed the cipher suite used is ECDHE-RSA with SHA256:
For Wi-Fi Calling tunnels to be supported your network and firewalls need to allow TCP/443 (HTTPS/TLS), UDP 500 and UDP 4500 (ESP). If you need to secure to specific external IP addresses, please consult your carrier for a list or FQDNs to match against.
Once the tunnel is established we can see ESP communications between the carrier and iPhone (in this case 192.168.128.26).
Here’s what a lot of people overlook – Wi-Fi Calling is simply another VoIP service running over your wireless (and wired) network.
Following vendor and wireless design best practices will help ensure a reliable and high quality Wi-Fi Calling experience. The following Wireless Voice Deployment Guide from Meraki is an example of the considerations required and related configuration elements recommended to support VoWi-Fi:
- Design your access point deployment for high density and voice requirements, ensuring wireless clients have adequate access to multiple access points at your required signal strength to facilitate BSSID roaming.
- If your WLAN infrastructure and endpoints are capable, such as Cisco/Meraki + Apple iPhones, ensure you test and implement fast roaming optimisations including 802.11r Fast Transition, 802.11k Neighbor List, and 802.11v BSS Transition to help your endpoints make better roaming decisions and roam between BSSIDs smoothly.
- Either set your VoWi-Fi WLAN to 5GHz only, or test and implement band steering to ensure endpoints operate on the less-congested 5GHz spectrum. Of course, you still need to consider your AP deployment has considered 5GHz signal propagation, cell sizes/mandatory data rates, and optimal channel configurations (look out for 80MHz-wide vendor defaults!).
- Prepare for an increase in traffic – Wi-Fi Calling uses around 100-120kbps, which can add up quickly if there are many simultaneous calls (especially in addition to any planned VoWi-Fi calls from existing softphone clients).
- Ensure that round trip latency is no more than 150ms.
Quality of Service (QoS)
Lastly, but most importantly – Quality of Service! Ensure your QoS configuration right throughout your network correctly honours and marks Wi-Fi Calling traffic as DSCP 46 Expedited Forwarding (EF).
In my testing I found my iPhone was correctly marking packets outbound, however due to testing over a consumer-grade Internet service there is no QoS support over my Internet service; therefore Wi-Fi Calling packets inbound from my carrier were marked as DSCP unknown (aka 0). However in an enterprise network you can mark packets across your WAN and inbound to your network to ensure the packets are delivered to your endpoints with the correct EF marking intact. Also ensure your policing policies allow for adequate bandwidth for the expected number of concurrent Wi-Fi Calling and softphone calls.
In summary, ensure your network is ready for Wi-Fi Calling; as it may not be available in your country or with your selected carriers today, but it will come in future. And your staff will either request for it to be a supported service, or once it is in use you will receive complaints about call quality and connection issues if you haven’t properly planned to support Wi-Fi Calling.
This was helpful today. Thank you for writing it up.
You’re welcome! Glad it was useful.