We have been having Wifi Calling issues for quite some time post iOS 12 in our facility. At first I thought it was isolated to Apple devices but I found out yesterday that it is affecting Samsung devices as well. Previously I have opened up cases with SonicWall with no luck. I’ve done everything that their online documentation says to do but it still continues to fail after a certain period of time and the logs haven’t helped. Has anyone else had Wifi Calling issue and if so have you found ways to fix them? I can’t vouch for other providers but it seems to definitely affect Verizon customers.
Generally, for Wifi Calling, you’re going to need to allow DNS to resolve whatever Verizon wants, and allow outbound IPSEC tunnels to their servers. You’ll also want to confirm wifi calling works on the devices normally (on another network) as this is not available to all users on all plans and all devices. Additionally, if your network doesn’t provide a better experience than Verizon’s they will often not choose to use yours.
Since Verizon doesn’t publish a list, you may also just need to sniff what traffic happens on an unfiltered network to see what should be allowed.
AT&T and T-Mobile do publish lists of what they need to work, so going through those lists and not doing any IP Address filtering should in theory be enough.
There may be another reason why your calls fail, which is bandwidth demand related. WiFi, Ethernet and all data networks, especially the Internet, have a default mode of ‘best-effort’ delivery, with no Quality of Service guarantees. It is normal when implementing VoIP via DSL or Ethernet for the Service Provider to implement full QoS capability to ensure call packets are prioritised over any other data to avoid calls being dropped. This does not happen on WiFi calling. Thus if your network, Internet connection or any intermediate system between your WiFi and the WiFi calling Service Provider gets congested, your user’s call can be dropped and you will never know.
In order to make if work effectively, you need to implement VoIP QoS measures on all infrastructure you have control over and try to get your ISP to do the same. You also need to consider increasing your Internet bandwidth to the site to cope with any possible congestion. Allow 120kbit/s bandwidth per simultaneous WiFi-calling or VoIP connection in your external bandwidth link.
I’ll run more tests and see what I can come up with. Thx for the info.
We currently have a 500/250 on our private network and it’s hardly ever over utilized and we have a 10gb backbone between all of our switches and looking at AP utilization it’s nothing. We have a completely separate network for our VoIP desk phones (with 10gb backbone…yes overkill for VoIP for our needs) and a third isolated network for our IP cameras (also on a 10gb backbone due to the amount of cameras we have, all at 8 megapixel for our facility). The phone network does hit a different interface on our SonicWall (NSA 4650) to get out to the Internet. When I say isolated network I’m meaning completely separate switching and fiber backbone infrastructure (not just using vlans).
Currently we have limited QoS setup on our main network but we are in the process of implementing Q-Sys core system as part of a new construction project at our main campus so we have been changing our QoS up lately to the recommendations of Q-Sys (but the WiFi calling issue has been going on for almost a year) but I will dig more into our QoS to see if that may help. We also have a separate media vlan that has quite a bit of Dante traffic on Sundays and Wednesday’s and we also use Living as One for our simulcasts and for our Web Stream (we have 2 encoders) and also use LiveStream for Facebook Live. We may start testing LaO FBLive that is in beta soon and phase our LiveStream. With all we do on Sundays I could understand if we have some issues then but we have issues during the week when nothing is going on.
What is weird with our issue is I can turn off my WiFi on my phone and turn it back on and WiFi calling enables and it will work but shortly thereafter the phone says it’s on WiFi calling but I don’t get phone calls, I cannot make phone calls, and I don’t get SMS messages (iMessages work fine due to regular WiFi data) so it seems something is causing a block somewhere that the phone doesn’t know about.
Anyhow thx for the info and I’ll talk to our ISP to see if they are doing anything on their end that could adversely impact us.
It’s possible your NAT sessions are expiring or getting pushed out of the session table on the NSA, a 4650 “only” does a max of 30,000 when DPI + SSL Decryption is enabled. Not sure if you have a way to monitor your session table size, but that might be the most obvious issue.
Your response and an email to Ministry Business Solutions has hopefully helped fix the issue. When Gary from MBS read your response to me after I sent them an email, he said it made him think about an issue they had with another customer that had VoIP phones dropping the connection to their hosted VoIP server. He told me what they did to fix it so I gave it a try. I added a rule on the SonicWall for UDP 500 and 4500 (Wifi Calling Ports) extending the UDP Connection Inactivity Timeout from 30 seconds to 200 seconds and we have been rock solid for over 2 hours. Normally it dies after like 5-10 minutes if that long. I’m going to keep monitoring in the rest of the day and see how it goes Sunday since the day is almost over but this appears to have been the fix!
Actually, that was Gary’s idea. Glad it is working for you!
You are correct! That was Gary I was working with on that issue! I guess I had you on the brain because I had asked you about the directory sort issue. ha! I edited the post for the proper credit! 
Here are some steps you can take to try and fix the problem.
- Make sure Wi-Fi calling is turned on.
- Eject and reinsert the SIM card.
- Reset Network Settings.
- Contact your wireless carrier.