I’d like to make wifi calling working but everything I tried seem doesn’t work.
Please could someone share his/her settings for that?
Operator states:
Minimal parameters: to successful call must used Wi-Fi router support transfer of internet security IP Sec and have this parameters: IP Protocol Type ESP 50 and/or IP Protocol Type UDP (Port 500), IP Protocol Type UDP (Port 4500), NAT translation time out under 2 minutes. Upload min. 100 kb/s for voice call and 1 Mb/s for video call.
I have hAP ac with RouterOS 6.47 (stable)
Service is enabled on provider. Settings are enabled in settings of my mobile - latest Android 10.
I don’t see any possible transmission regard VoWIFI in Torch
My experience is that home gateway (e.g. Mikrotik) has to be transparent enough for outgoing connections and that’s about it. It’s phone which establishes IPsec tunnel to MNO’s core network and it does that immediately after registering to WiFi-enabled network.
Default ROS setup should be fine.
Ah, yes, also ISP has to allow IPsec (originating from customers), I can imagine some ISPs might block it for some reason.
Apparently it’s some kind of IPsec passthrough issue on Mikrotik…unfortunately I’ve haven’t found a way to solve this yet. May be the Mikrotik team can help us on that issue…
Make sure you are not blocking IPSec traffic (protocols or ports) in the forward table coming from your LAN side.
Also, check your DNS cache to see if the devices are resolving 3gpp FQDN pointing to the telco core network for VoWiFi (you can also setup QoS for that traffic):
In my case, the iPhone still connect to IMS core and I can even make and receive calls…but it looses the registry regularly and fallbacks to the cellular network.
I’ve tested on a simple TP-Link mesh router, and this symptom doesn’t occurs.
I’m afraid only sniffing the traffic on the Tik may give a clue here. The only things to come to my mind are that the iPhone would not send keepalives frequently enough and the Mikrotik firewall would close the UDP pinhole (the default lifetime of a UDP pinhole is 3 minutes), or that the iPhone’s LAN IP would change and so the pinhole would become obsolete. Both seem quite unlikely to me, though. So sniff to file and see what happens before the registration is lost.
I think in my case it’s the mobile (Xiaomi A2) issue - I don’t see any related traffic in Torch (nor packet sniffer in android). Weird - the VoWiFi is enabled.
I should see some related traffic in torch, right?
As I wrote: when mobile connects to WLAN, it tries to establish IPsec tunnel to MNOs core network. So torch should show some related activity at that time. If mobile can’t establish the tunnel, I don’t think it retries as long as it’s registered to same LAN. And int that case torch won’t show anything further.
If, OTOH, IPsec tunnel is established, there will be activity (voice calls, text messages, other mobile signalling), but torch will only see encrypted traffic.
Just to be sure: SIM card subscription includes VoWiFi service? It’s not automatic/mandatory service for LTE subscribers …
Yes, VoWiFi service is active and verified by provider (I asked their support).
What is enough to tell phone to try initiate VoWiFi connection again? Toggle Flight mode, WiFi or reboot?
Toggle WiFi (keep WiFi disabled few tens of seconds to allow phone properly resume operations natively using mobile network before changing to WiFi again). Toggling flight mode would probably do it as well.
This is nonsense! VoWIFI is not a SIP service. It uses IPsec.
Phones will make outgoing traffic to UDP port 500 of their service provider, then to UDP port 4500.
They will exchange regular packets to keep the connection alive.
No special configuration is required for this under normal circumstances, unless you have firewalled everything shut.
You are probably talking about installation of a SIP app and configuring that to make calls via some SIP server.
That is not what is commonly known as VoWIFI. VoWIFI is a service provided by telecom companies in addition to their VoLTE service (voice over 4G/5G), that does not use SIP directly on the network, but rather sets up an IPsec tunnel over UDP port 500/4500 and does not require an ALG on the local router.
On this forum, feature requests can be only raised within a specific topic dedicated to them. You can also issue a support ticket. The official way to open feature requests is via your distributor.
I have a rough idea of an ugly workaround which involves a hairpin tunnel and spoofing of UDP packets that would update the pinhole created for the VoWiFi connection. But your mobile operator must be really specific if their VoWiFi gateway doesn’t send the IPsec keepalives on its own.
