Wi-Fi Calling on Unleashed

[daniel_m]

First I just want to say thank you for adding this to Unleashed!  I have configured a Profile for this and enabled it on a WLAN, but I am not seeing my Wi-Fi Calling Client, even after refreshing, on the Summary tab even though I’m currently on a Wi-Fi Call.  How do I go about troubleshooting this?

Thank you!

[tony_heung]

Can you share the profile you created?  And a screenshot on the WLAN that you had enabled it.

[daniel_m]

Sure Tony:

[tony_heung]

Thanks Daniel.  It looks good.  To rule out the possible DNS factor, try to add the first entry TMobile (ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org) with the ip 208.54.88.35 and second entry Verizon (233.sub-141-207-229.myvzw.com) with ip 141.207.229.233.  Even though the ip address is optional but worth to test.  I think the Verizon one been pretty much static to this ip but TMobile been changing depending on location, you can use the host ss.epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org as it includes the geo subdomain for the dns lookup based on your location for the closest ePDG server ip address.

Another test you can try is to just keep one server line in your Wi-Fi Calling profile, just a better controlled setup for troubleshooting for now.

If you are not 100% sure if your operator supports Wi-Fi Calling (suppose you did see the Wi-Fi Call icon on your phone),  you can start a Wireshark capture on or behind the AP and then activate Wi-Fi calling on the device to capture the FQDN that the device is looking for and can use that for your profile.  

[daniel_m]

Hey Tony!

In reviewing your reply, I did the following:

• Used tcpdump to verify the DNS lookup that the Wi-Fi Calling client is using
• Used tcpdump to confirm IPsec connectivity for Wi-Fi Calling
• Confirmed adding an IP Address for the ePDG does not change the behavior
• Confirmed adding the actual IP Address that my Wi-Fi Calling client is actually using for the ePDG does not change the behavior
• Confirmed using one ePDG/server does not change the behavior

Some more detail:

The actual DNS lookup performed by the Wi-Fi Calling client is:

$ sudo tcpdump -ni vlan19 host 198.51.100.200 and port 53
tcpdump: listening on vlan19, link-type EN10MB
...
13:06:02.082764 198.51.100.200.42157 > 198.51.100.254.53: 24301+ A? epdg.epc.mnc260.mcc310.pub.3gppnetwork.org.(60) (DF)

The host above as well as ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org are just CNAMEs for their respective “geo” names:

$ host -t A epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
epdg.epc.mnc260.mcc310.pub.3gppnetwork.org is an alias for epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org.
epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org has address 208.54.37.80
$ host -t A ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org is an alias for ss.epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org.
ss.epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org has address 208.54.83.96

The IP addresses returned for epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org and related are highly dynamic, change frequently and have a very short TTL.. 

Lastly, after changing the ePDG to epdg.epc.mnc260.mcc310.pub.3gppnetwork.org, which is what the client actually uses, the web UI started to populate for some reason, but it’s not clear why; it is also very possible my testing results are highly skewed due to the delay between when a change is made and what’s reflected in the Wi-Fi Calling Summary tab.  Subsequent Wi-Fi calls appear to eventually get reflected in the web UI—they don’t readily show up with frequent refreshes—but this is definitely not reflected in real-time and this hampers troubleshooting.  I guess I’ll consider the matter closed for now unless you are interested in me trying some more things.

Are there any command line operations I can run on the AP to gain greater insight that might be omitted or delayed in relation to the web UI?

Thanks Tony!