I have found multiple long discussions on the Sky Help Forum containing reports of very similar Wi-Fi Calling issues. A recent discussion, in which several users report problems with Wi-Fi Calling and incoming calls: https://helpforum.sky.com/t5/Broadband/Wifi-calling-through-sky-max-router/m-p/5359748 There is also a much older and considerably larger discussion that contains numerous reports of unstable Wi-Fi Calling, calls dropping, and devices apparently losing Wi-Fi Calling connectivity: https://helpforum.sky.com/t5/Broadband/Sky-broadband-stopping-WiFi-calling/td-p/4850826/page/7 What I find particularly interesting is that these reports appear to involve different iPhone models, routers, mobile carriers, and network configurations. Some users also report that Wi-Fi Calling works temporarily after restarting or reconnecting, before eventually becoming unavailable again. Of course, these reports do not prove that the issue is caused by iOS, Sky Broadband, the router, or the carrier individually. However, given the number of similar reports, it seems possible that there may be an interaction between iOS, the carrier’s Wi-Fi Calling implementation, and certain network environments or configurations. Another potentially relevant aspect is that Sky Broadband uses MAP-T (Mapping of Address and Port with Translation) as part of its network architecture. Since VoWiFi relies on persistent network connectivity and IPsec/NAT traversal, I wonder whether this type of architecture could potentially expose an interoperability issue or require specific handling on the iPhone side. I am not suggesting that MAP-T is necessarily the cause, but given the recurring reports specifically involving this network environment, could it be worth investigating whether the interaction between iOS VoWiFi connectivity and MAP-T behaves as expected, particularly after a period of device inactivity? In my case, I have also tested different routers, configurations, and Wi-Fi networks, yet I continue to experience the same behaviour. The Wi-Fi connection itself remains healthy, and other applications with persistent network connections continue to work normally. The issue appears to specifically affect VoWiFi. Would it be possible to investigate this type of event specifically? In particular, I would be interested in understanding what happens when the Wi-Fi connection remains fully functional, but the VoWiFi connection silently becomes unavailable after a period of inactivity or is randomly lost. Given the recurring reports and the apparent correlation between this particular network environment and iPhone behaviour, I wonder whether it could be useful for Apple and Sky Broadband to investigate the issue together. If there is an interoperability problem between the network’s MAP-T implementation, the carrier’s VoWiFi infrastructure, and iOS, collaboration between the two sides might help identify the underlying cause.

Thank you for the detailed explanation. I understand that a network or NAT-related issue could cause a persistent connection to become stale while the device still appears to have a perfectly healthy Wi-Fi connection. However, I have already tried several different configurations, routers, and Wi-Fi networks, and the issue seems to occur consistently across all of them. One aspect that makes the issue particularly difficult to understand is that it appears to affect VoWiFi specifically. Other third-party applications that maintain persistent network connections continue to work normally and do not appear to disconnect or require reconnection after the iPhone has been idle for several minutes. For this reason, I would like to better understand how I could test whether the network is actually contributing to the issue. Are there any specific tests, diagnostics, packet captures, or network conditions you would recommend checking to determine whether NAT timeouts, UDP/IPsec sessions, or another network-related issue could be causing the VoWiFi connection to become unavailable? I would be happy to perform any tests that could help isolate whether this is caused by the network, the carrier infrastructure, or iOS itself.