Wi-Fi Calling disabling itself on iPhone 16 Prox Max iOS 18.2

+ meant to comment on the appearance of "Carrier Wi-Fi" instead of "Spusu-WiFi." This often indicates a failed authentication / can occur if your device cannot retrieve the carrier’s public key, preventing it from identifying the Wi-Fi calling service as "Spusu-WiFi." Really you should never see anything but the correct carrier named WiFi calling facility.

DNS filtering services like Pi-hole, AdGuard, and NextDNS can block this authentication by obstructing access to essential carrier domains (albeit rare if a carrier profile is documented). Ideally, a well-configured DNS should respond always; but, many such services such as PiHole perform silent drops by default causing devices to endlessly retry. iOS 18.2 has improved in this regard, as it no longer falls back to insecure DNS when secure methods fail but this has resulted in some things breaking too.

Additionally, Internet Service Provider (ISP) configurations add complexity. For example, Virgin Media’s DNS interception on the Hub 5 had conflicts with iCloud Private Relay iOS 18.2 (believe this is remedied now), as iOS 18.2 did not automatically revert to Virgin Media’s intercepting DNS but would instead hit a stalemate of sorts.

Sky's got a rather sophisticated traffic management system. I think it categories network traffic into multiple priority buckets and uses Weighted Round Robin scheduling to manage bandwidth. A firmware update 2 or so weeks back appears to prioritise Sky services, such as TV and Stream far more vigorously than before. I know this firmware was in response to issues with digital voice services for even full fibre customers.

The recent firmware update for my Sky Hub 4 (SR203) seems to prioritise all "sky" things, even non essential apps like ROXI Karaoke are allocated priority bandwidth. The hub is designed for high loads, with alerting thresholds set at 95% for CPU and memory use, significantly above the standard 70-80% I see out in the field. As a result, if the CPU usage hits 90%, it won't be logged, creating a "business as usual" scenario. While this may help with tasks like streaming SKYQ to multiple screens, it could mask underlying performance issues without intervention. At 95% load I would argue almost always there's "high utilisation that is service affecting."

In my opinion, this aggressive resource allocation and strict traffic prioritization can easily degrade Wi-Fi calling as it seems it is not given appropriate focus. Searching the latest config file on my Sky Hub reveals 415 instances of “queue,” indicating the complexity of traffic management, which likely results in unintended consequences. Currently, Wi-Fi calling seems deprioritized compared to Sky landline services, SkyQ, and even the ROXI Karaoke app *(LOL)! Ultimately, the Weighted Round Robin bounds activities by time. If the rating is higher, it gets more total time. Sticking things before say WiFi calling means that call will "drop." After all you cannot "queue" the back and forth chat during a wifi call.

Ultimately, we have no control over these configurations, and ISPs typically don't disclose their quality of service rules, often claiming their hubs lack support for it. Virgin Media encrypts their configurations, offering no visibility, while Sky allows access to raw configs, which is at least somewhat helpful.

The standard deployment for WiFi calling in the absence of a carrier profile overriding it is that WiFi calling is only enabled during periods where the main carrier network would be inadequate. This can be confusing because you can be staring at 1 bar and WiFi calling is not enabled. This can be due to your mobile being connected to a higher frequency band. Higher frequencies travel less far but typically carry more data, as in, they are "faster" for data even at lower signal.

Just because you are connected to a higher frequency band such as Band 7 (2600 MHz) does not mean a lower frequency signal is unavailable (such as band 20 - 800 MHz). Note 800 is less than 2600.

In this case, if the network is indicating a call would drop down to a lower frequency band, there's no need for WiFi calling. What should happen is the user makes the call, and the signal suddenly jumps from 1 bar to say 3 bars (as it switches over to that lower frequency band).

It should be noted that whilst Spusu has access to lower frequency bands (which some MVNOs of EE do not), it still operates in a prioritized manner. IE if a lower frequency is congested and filled up, but needed for a call to be stable, a native EE customer on say a contract plan should in theory take priority over spusu. I suspect what may be happening is that the network is declining the handover to a lower frequency due to capacity and you're hovering between what is deemed acceptable and unacceptable for WiFi calling to be utilised.

Re the frequencies: to put this into perspective, a WiFi signal is often 2.4GHz (2400MHz) or 5GHz (5200MHz) and a Freeview HD channel may be as low as 50MHz. This is why Freeview can travel 30 or so miles from transmission.

I use EE as my primary carrier and their carrier profile actually overrides the spusu one. This means that my spusu APN is as follows:

The password for all is secure (iOS hides the PW field) and the MMS prof URL in full is http://www.apple.com/mms/uaprof.rdf

I am unsure if this works as I have a working native EE sim also, or whether it works on spusu more broadly. However; using the spusu standard APN means the EE eSIM breaks (RCS breaks, iMessage breaks) and eventually it seems to think I've done a sim swap and deletes the oldest eSIM of the two and merges the numbers into the EE number. It becomes a right mess, so we let spusu run as EE's APN. So far, all good.

Also ensure VOLTE is enabled:

I keep data roaming on also, not sure if necessary but I had dropped calls initially with it off? Perhaps it thinks it's roaming 247... not sure :)

I do not get drops once WiFi calling kicks in but generally it doesn't seem to think my service is bad enough to warrant it. It comes up as spusu-wifi:

Let me know if this helps! You can reset the APN if this "breaks" anything.