Here's something that catches a lot of network teams off guard: a good chunk of the phone calls happening in your building right now aren't touching a cell tower. They're riding your WiFi. Users enabled WiFi Calling on their iPhones and Androids at some point, probably forgot about it, and now your access points are carrying voice traffic you never explicitly designed for.
That's not necessarily a problem — unless call quality is bad, and then it becomes your problem. This post digs into the two technologies at play here: WiFi Calling (VoWiFi), which routes actual phone calls over WiFi, and WiFi Offload, where carriers redirect mobile data onto your network to ease congestion on their cell sites. They sound similar but work differently, and the infrastructure requirements can surprise you.
What Is WiFi Calling (VoWiFi)?
If you've ever been in a building basement with zero cell bars and still made a phone call, you've used WiFi Calling. The phone quietly switches to routing your call over the WiFi connection instead of cellular. Same phone number, same dialer — the user doesn't notice the difference (when it works well, anyway).
What happens under the hood is more interesting. The phone builds an encrypted IPSec tunnel through your WiFi network, across the internet, to the carrier's ePDG (evolved Packet Data Gateway). Think of the ePDG as a doorway that lets WiFi-connected phones back into the carrier's voice network. From there, the call gets handed to the carrier's IMS core, the same system that handles calls from cell towers.
For carriers, this is a win: they get indoor coverage without installing femtocells. For users, it means calls work in places where cellular doesn't — concrete-heavy buildings, underground parking garages, remote offices with broadband but no cell signal. The tricky part is that the WiFi network operator (that's you) is now in the critical path for voice quality, and you may not even know it.
VoWiFi Adoption
Over 90% of smartphones sold today support WiFi Calling, and most carriers have turned it on by default. It's everywhere, but most IT teams haven't adjusted their network design to account for it.
What Is WiFi Offload?
WiFi Offload is a different animal. Instead of routing voice calls, it's about moving general mobile data traffic — web browsing, streaming, app updates, all of it — off the cellular network and onto WiFi. Carriers love this because licensed spectrum is expensive, and every gigabyte they can push to WiFi is a gigabyte they don't have to carry on their cell sites.
There are two flavors, and the difference matters:
Managed offload (Passpoint/Hotspot 2.0) is the polished version. The phone discovers compatible WiFi networks automatically, authenticates using the SIM card through RADIUS, and connects without the user doing anything. No splash page, no password, no "select a network" popup. It just works — or at least that's the idea.
Unmanaged offload is what happens when your employees connect to "CorpWiFi" and their phone stops using cellular. This is the vast majority of WiFi offload in practice. It works, but the carrier has no visibility into it, and there are no QoS guarantees.
By some estimates, WiFi already carries more than half of all mobile data globally. Most of that is unmanaged — which is fine for email and web browsing, but becomes an issue when you need reliable, carrier-grade connectivity.
Managed vs. Unmanaged Offload
Managed offload via Passpoint gives you automated discovery, SIM-based authentication, QoS awareness, and carrier analytics. Unmanaged offload — someone picking a WiFi network from a list — gives the carrier nothing: no visibility, no auth guarantee, no QoS. If you're building infrastructure that carriers will actually want to use, managed is the only serious option.
The Architecture Behind WiFi Calling
It's worth walking through what actually happens when someone makes a WiFi call, because once you see the packet flow, a lot of the network requirements start to make sense.
The carrier runs an ePDG (evolved Packet Data Gateway) — essentially a VPN concentrator that terminates IPSec tunnels from phones on WiFi. The phone authenticates to the ePDG using EAP-AKA or EAP-AKA', which pulls credentials from the SIM card. The tunnel negotiation happens over IKEv2. If your firewall blocks any of this, WiFi Calling silently fails — and the user just thinks "the WiFi is bad."
Once the tunnel is up, the phone registers with the carrier's IMS core through it. From that point, voice packets travel encrypted through your WiFi network, out to the internet, into the IPSec tunnel, through the ePDG, and into the carrier's voice infrastructure. Your network is the first hop, and every millisecond of latency and every dropped packet happens on your watch.
- WiFi Association: Phone connects to your WiFi — could be open, PSK, or 802.1X. Nothing special here.
- ePDG Discovery: Phone does a DNS lookup to find the carrier's ePDG. The FQDN is derived from the carrier's PLMN identity — so if DNS is slow or broken, WiFi Calling won't start.
- IPSec Tunnel: Phone initiates IKEv2 with the ePDG. SIM-based EAP-AKA/AKA' handles authentication. This needs UDP 500/4500 and ESP (IP protocol 50) through your firewall.
- IMS Registration: Through the tunnel, the phone registers with the carrier's voice system and gets a P-CSCF address. At this point, it's ready for calls.
- Call Flow: Voice goes as encrypted SIP/RTP inside the IPSec tunnel. Your network sees encrypted UDP — you can't inspect it, but you can prioritize it.
Enterprise Network Requirements for WiFi Calling
Technically, WiFi Calling works on any WiFi network. Practically, call quality ranges from "perfectly fine" to "completely unusable" depending on how the network is set up. Here's where enterprise networks often fall short.
QoS and WMM: This is the single biggest factor. WMM defines four priority buckets: Voice (AC_VO), Video (AC_VI), Best Effort (AC_BE), and Background (AC_BK). WiFi Calling traffic needs to land in AC_VO. If it's sitting in Best Effort alongside someone's Windows Update download, audio quality tanks. Make sure your DSCP markings on the wired side map correctly to WMM on the wireless side — a surprising number of networks get this wrong.
Signal strength and AP density: A -75 dBm signal is fine for loading a webpage. It's not fine for a phone call. Voice needs -67 dBm or better, consistently. That dead spot by the elevator that nobody complains about for data? It drops calls. If you're serious about WiFi Calling, do a proper RF survey with voice in mind, not just data coverage.
Fast roaming (802.11r/k/v): Someone walking down a hallway during a call will roam between APs. If that handoff takes more than about 50 milliseconds, the caller hears a gap or the call drops entirely. 802.11r pre-authenticates with the next AP before the device actually moves. 802.11k tells the device what APs are nearby so it doesn't waste time scanning. 802.11v lets the network nudge devices toward a better AP before the signal gets too weak. You want all three enabled.
Voice VLAN separation: Put voice on its own VLAN with dedicated QoS policies. When someone kicks off a multi-gigabyte backup and your voice traffic is sharing the same VLAN, you'll understand why. It's basic network hygiene, but it makes a real difference.
| Requirement | WiFi Calling | Standard Data WiFi |
|---|---|---|
| WMM QoS | Required (AC_VO priority) | Optional |
| Signal Strength | -67 dBm minimum | -75 dBm acceptable |
| Roaming Speed | <50ms (802.11r/k/v) | Seconds acceptable |
| VLAN Separation | Dedicated voice VLAN | Single VLAN common |
| Firewall Rules | ESP, UDP 500/4500 required | Standard HTTP/HTTPS |
| Packet Loss Tolerance | <1% | 5-10% acceptable |
| Latency | <150ms one-way | <300ms acceptable |
How Passpoint Enables Carrier WiFi Offload
Passpoint (also called Hotspot 2.0) is what turns WiFi offload from a hack into a real system. Without it, offload just means "the user happened to join a WiFi network." With it, the device discovers and connects to compatible networks automatically, using credentials the user already has.
Here's how it works: before the phone even associates with an AP, it sends ANQP queries (Access Network Query Protocol) to find out what the network supports. What auth methods? What roaming consortiums? Is this a network my carrier trusts? All of this happens in the background, invisible to the user.
Authentication for carrier offload uses SIM-based EAP methods — EAP-SIM for older 2G SIMs, EAP-AKA for 3G/4G, and EAP-AKA' which adds stronger key derivation. The WiFi network validates the subscriber through the carrier's AAA system, the same way a cell tower would. No username, no password, no captive portal.
That last point is worth emphasizing. Compared to captive portals, Passpoint is night and day. No splash page, no "enter your email," no "accept terms and conditions" button. The phone connects automatically because the SIM card proves who the user is. It's the experience WiFi should have had from the start.
OpenRoaming takes this a step further by federating identity across networks globally. A T-Mobile subscriber can roam onto a venue's WiFi in another country and offload data automatically, even if T-Mobile has no direct agreement with that venue — because both participate in the OpenRoaming federation. That's a big deal for carrier offload at scale.
The Role of RADIUS in WiFi Calling Quality
People sometimes overlook this, but the RADIUS server sitting behind your WiFi has a direct impact on WiFi Calling quality. The phone can't start building its IPSec tunnel to the carrier until it's on the WiFi network, and it can't get on the WiFi network until RADIUS says "yes."
802.1X authentication: If your enterprise runs WPA-Enterprise (and it should), every device authenticates through RADIUS before getting network access. A slow RADIUS response — maybe your server is overloaded, maybe there's a DNS issue in the EAP chain — delays everything downstream, including WiFi Calling setup. Users experience this as "it takes forever before I can make a call after connecting to WiFi."
Dynamic VLAN assignment: RADIUS can put different devices on different VLANs based on who they are or what they are. This is how you get phones onto a voice VLAN with proper QoS while keeping laptops on a data VLAN. Without this, you're relying on the phone self-marking its traffic correctly — which sometimes works and sometimes doesn't.
Fast re-authentication: When a phone roams to a new AP, it might need to re-authenticate. If RADIUS has to do a full EAP exchange every time, that's hundreds of milliseconds — way too slow for a voice call in progress. PMKSA caching and EAP session caching let the device skip the full handshake on roam. This isn't optional for voice; it's a requirement.
Accounting and troubleshooting: RADIUS accounting logs tell you which devices are roaming frequently, where re-auth events cluster, and how long sessions last. When someone reports "calls drop when I walk from my desk to the conference room," accounting data shows you exactly which AP transition is the problem.
If you're running certificate-based authentication (EAP-TLS), you get the best of both worlds: strong security and the fastest possible re-auth, since there's no password exchange in the EAP handshake. For buildings where WiFi Calling quality really matters, EAP-TLS is hard to beat.
Deployment Strategies
How you deploy depends on who's driving the project and what the relationship with carriers looks like. In practice, we see three models.
Carrier-led. The carrier owns the APs, manages the network, controls the whole stack. You see this at major airports and stadiums — places where the carrier has enough skin in the game to justify the investment. As an enterprise, you mostly stay out of the way and provide power and backhaul.
Enterprise-enabled. This is the most common scenario for offices and campuses. You own and run the WiFi. You just make sure it's configured properly for voice: QoS enabled, firewall rules allowing IPSec, adequate signal coverage. The carrier handles the voice service; you handle the transport. Most of the guidance in this post is aimed at this model.
Neutral host. A third party deploys WiFi that works for multiple carriers at once. A shopping mall or transit hub uses Passpoint and OpenRoaming so that any carrier's subscribers can offload automatically. Nobody has to negotiate individual carrier agreements — the federation handles it. This model is growing fast, especially in venues where no single carrier wants to foot the bill alone.
Build Your WiFi Calling Infrastructure
IronWiFi provides the RADIUS and Passpoint infrastructure for all three models. Whether you're an enterprise enabling WiFi Calling or a venue building a neutral host deployment, our cloud platform handles EAP-SIM, EAP-AKA, EAP-TLS, and OpenRoaming out of the box.
WiFi Calling Solutions Passpoint PlatformCommon Challenges and Solutions
These are the issues that come up in almost every deployment. If you're planning a WiFi Calling rollout, you'll probably hit at least two of these.
"Calls sound choppy" or "one-way audio." Nine times out of ten, this is a QoS problem. Either WMM isn't enabled, DSCP markings are getting stripped somewhere in the wired path, or voice traffic is landing in the wrong WMM queue. Check your AP configs, check your switch QoS policies end-to-end, and look at airtime utilization on your busiest APs. Once you're above 70% airtime usage, voice quality falls off a cliff.
"Calls drop when I walk to the break room." This is a roaming problem. The phone moves between APs and the handoff takes too long. Enable 802.11r for pre-authentication, 802.11k so the phone knows which AP to roam to, and 802.11v so the network can push devices to a better AP before they hit the edge of the current one's range. All three work together; enabling just one usually isn't enough.
"WiFi Calling takes forever to become available." The phone is spending too long authenticating to the WiFi network before it can even start the IPSec tunnel. Implement PMKSA caching so roaming re-auth is near-instant. If you're on EAP-TLS with certificates, re-auth is already fast. If you're on PEAP with passwords, make sure your RADIUS server supports session caching and that your APs are actually using it.
"We need to support Verizon and AT&T and T-Mobile subscribers." You don't want separate SSIDs or infrastructure for each carrier. Deploy Passpoint with OpenRoaming — the ANQP protocol handles multi-carrier discovery, and OpenRoaming federates the authentication so any participating carrier's subscribers can connect to your single network. One SSID, multiple carriers, no per-carrier agreements needed on your side.
Firewall Configuration Required
This is the one that bites people most often: WiFi Calling needs ESP (IP protocol 50) and UDP ports 500 and 4500 through your firewall. Many enterprise firewalls block these by default. If they're blocked, WiFi Calling fails silently — the phone just falls back to cellular (if available) and nobody realizes it's broken until they're in a spot with no cell signal.
Frequently Asked Questions
WiFi Calling (VoWiFi) is specifically about voice calls — your phone builds an IPSec tunnel over WiFi to the carrier's ePDG and routes calls through it. Same phone number, same dialer. WiFi offload is broader: it moves general mobile data (browsing, streaming, app updates) from cellular to WiFi, typically using Passpoint for automatic SIM-based authentication.
It'll connect on most WiFi networks, yes. But "works" and "works well" are different things. Quality depends on QoS configuration, signal strength (-67 dBm or better for voice), and whether the firewall allows IKEv2 traffic on UDP 500/4500 and the ESP protocol. Block those ports, and WiFi Calling fails silently.
SIM-based EAP methods: EAP-SIM, EAP-AKA, or EAP-AKA', all validated through RADIUS. The Passpoint/Hotspot 2.0 framework handles network discovery and connection automatically — no user interaction required. The phone's SIM card is the credential.
IronWiFi provides cloud-based RADIUS that supports EAP-SIM, EAP-AKA, and EAP-TLS authentication, plus Passpoint and OpenRoaming. That covers the full stack for enterprise WiFi Calling, carrier offload, and neutral host deployments.
The short list: WMM QoS enabled with voice in AC_VO, signal strength of -67 dBm or better everywhere, 802.11r/k/v for fast roaming, voice traffic on its own VLAN, and firewall rules allowing ESP and UDP 500/4500 to the carrier's ePDG. Miss any one of these and you'll get complaints.