For those of you with a little patience, and a thirst for knowledge, read below. For those in the tl;dr set: It's more complicated than you think. No, it doesn't "just work." Nothing is free.
In addition to my previous comments, there is also another reason why WiFi calling may or may not be enabled on a specific carriers network for a specific device. It is mainly due to the fact that network authentication, billing and call handoff all need to pass through what is called an IMS Core (
https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem) in order to actually initiate, bill for and pass speech data between the networks. To support this, Apple (and Republic Wireless) built their *own* IMS Cores to enable their phones (iPhone 6/6+, and Moto G) to authenticate to the carrier's networks and hand off calls between the two networks. Republic had to create their own dialer for this, and integrate it directly into Sprint's core network to make this happen. Apple created their IMS Core first, then strong-armed each of the networks in turn to support them. TMO was the first, as they already supported (non-handoff capable) WiFi calling for some time, then Sprint, then AT&T. VZW is the last in line because upgrading their IMS core for their entire network (which is considerably larger than you think, it also includes a large number of rural networks joined together) is an extremely expensive and time-consuming project. They were also waiting to see if they would lose business to other carriers if they didn't play ball, which is precisely what happened.
For Android, there are two problems:
1. Android phones need new dialers
2. Carriers can't use Apple's IMS Core for Android phones.
So each carrier must upgrade their current IMS cores in a backwards-compatible way, so they don't kick older phones (or MVNO systems) off the network, and convince the Android OEMs to update the dialers on their phones to support WiFi calling. Google, having foreseen some of these issues, has included SIP (
https://en.wikipedia.org/wiki/Session_Initiation_Protocol) dialer code for some time, but it needs to be enabled by the carrier (or MVNO) in order to work. Newer versions of these dialers will correctly send the protocol signals for switching networks, but they require compatible IMS Cores to work properly.
Lastly, MVNOs come in a couple of flavors (realtime/prepaid, offline and postpaid). Postpaid and offline MVNOs are usually corporate or government MVNOs who get billed after the fact, and leave the call routing, session initiation/teardown to the carriers themselves. They basically just get bills in the mail like we've all done since the 90's. They merely need to negotiate new MO/MT rates based on network usage. For realtime/prepaid MVNOs the situation is *very* different. Basically, customers pay into a 'wallet' or 'card' and as minutes are used, the funds are decremented to zero. In order to facilitate this, the prepaid MVNO's billing system(s) & SCP must implement a suite of protocols:
SS7 (
https://en.wikipedia.org/wiki/Signalling_System_No._7) for switching SIP/POTS/GPRS
WIN-II/IS826 (
https://en.wikipedia.org/wiki/Wireless_Intelligent_Network) for passing billing/rating/roaming info between networks
GTP (
https://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol) for actually tunneling the voice/SMS/MMS data over the various networks.
WIN-II/IS826 is the most important for billing, as that is the protocol that allows a customer's phone to originate (MO) or terminate (MT) a call to/from a particular network. Before the call goes through, the phone connects to the carrier network and asks for permission to initiate a call or data session, the carrier then asks the MVNO if there is enough money in the 'wallet' to complete the connection. If so, the call connects. If not, the user gets an error signal or a friendly message telling them to pay up. Once connected, the phone periodically sends a message through the carrier network to the MVNO asking if the call can continue. If the wallet is empty (or close to it) it will receive a disconnect message. If a 3-way call, or call waiting/forwarding session occurs, the wallet is decremented twice, etc. That's a cartoon version of the complexity, but hopefully that is enough for you to get the gist of the protocol.
The above has been the standard system for POTS, analog wireless and digital wireless through today. Internet calling adds a totally new process. With SIP (which I'll use as a shorthand for VoIP) does away with all of the signaling and switching inherent in cellular calls, because it is network agnostic. Calls can be placed to/from devices on *any* IP network, either directly (P2P) or through a hub (switched). FaceTime & Skype use P2P, where something like Go2Meeting, Verizon's VoIP App, and TMO's (previous) WiFi calling feature use switched. To enable SIP calls to connect to a standard phone network (wired or wireless), there is usually a Gateway which takes the digital signal, filters it, and then connects to a phone. Usually, this is one way SIP > phone, and does *not* require special signaling to enable real-time billing. The owner of the gateway gets a bill at the end of the month and all calls just go through. The gateway owner may bill you depending on the *terminating* network (Skype, NetworkIP), but this does not require any changes to your phone for this to work. However, if you change IP networks, the call *will* disconnect. Needless to say, the traffic nearly always initiates on an IP network (because the phone # of the IP phone may not be known or reachable from the other direction), and terminates on a telephone network which charges the gateway owner a fee.
Still with me?
In order to make WiFi calling (as currently described) work as we expect, the handset needs to reverse the process, and be able to *seamlessly* switch between them. This is facilitated by creating a third *virtual* network on the handset itself. When a handset powers up, it will attempt to connect and authenticate to a cell network first, it will then create a virtual network which is authenticated to that network, and register the new network node with the IMS Core (Apple, Carrier, MVNO). When a call is initiated, it first goes to the virtual network, which tells the IMS core to reserve a line and hold on to a call identifier. When the caller moves out of range of that particular network but onto another (cell > wifi, wifi < cell) the phone attempts to pickup that call identifier in realtime, transparent to the caller(s). Usually this process is quick enough that no one will notice. If the identifier is not picked up, the call is disconnected. If an MVNO is realtime capable, the billing queries and routing information also have to be translated, collected, held and transmitted. In addition, there may be WiFi-connected devices on both ends of the call! 3-way calling, voicemail, call-waiting and forwarding all need to be sent over the correct network at the correct time. That takes many many man-months of coding and testing which cannot simply be enabled or 'offered'.
All of the components to build WiFi calling already exist (as I hopefully demonstrated above), but they hadn't been put together in a way that was transparent to a user before now. Apple calls this 'continuity' which was sorely lacking before, and many startups have tried and failed to achieve this (with the notable exception of Republic Wireless) because they didn't control enough of the infrastructure to make it seamless. Republic had Sprint's full support, and Moto gave them the resources required to implement this virtual network dialer for the Moto G (which is a major achievement, few OEMs would have done so). Apple controls iOS and they built their own international IMS Core(s) and exert enough influence on the carriers to get them to modify theirs. None of the other actors in the marketplace had enough time energy or resources (or desire) to push this technology out. Google doesn't own any phone infrastructure, and can't force OEMs to support this, and in any case Google doesn't actually make any money for the carriers or have the ability to update the currently available handsets to support any of these services. OEMs get paid in advance of actual sales, so unless a carrier or MVNO requests >100k handsets with a particular feature, *it will not be included.* Notice that AT&T rolled out NumberSync (WiFi calling from non-phone devices with the account's MDN) with the release of iOS 9.2. It's very unlikely that will ever be extended to any currently shipping Android tablet or Windows PC.
To circle back to the beginning of these comments, VZW has taken so long because they were *dragged* into it by Apple and competition. It's not supported on most Android devices because neither the software nor infrastructure to support them actually exists in a functional form yet. In the near future, I think we (and the industry) can expect a global standard for multi-network 'continuity' that will enable us to blithely flit between any number of networks without special software or hardware, but for now, we'll just have to wait a while longer.
I'm just going off what my customers say. I'm not saying that T-Mobile's coverage is better than Verizon's across the board, just that neither is significantly better than the other now (at least where I live). Of course, there's also that "the grass is greener on the other side" mentality with customers too, so it's hard to say anything factual about it.
