MikroTik

Posted: **Mon Jan 07, 2019 7:32 am**

About a month ago, Wi-Fi calling (iPhone via AT&T) stopped working in my home. After between 10-15 seconds, the person I am talking to can't hear me anymore, but I can hear them just fine. It's like I am on mute, or all my outbound packets are being eaten. Oddly, it doesn't happen right away. I don't recall changing anything on my MikroTik cloud router, but it seems to be the culprit.

Simplified Topology: iPhone (P) -> MikroTik Cloud Router (R) -> AT&T modem (M) -> AT&T broadband

I use AT&T for my cell service as well. I understand that Wi-Fi calling sets up some sort of IPsec tunnel, but don't understand those nuances.

When I use P with Wi-Fi calling, connected to M's WiFi, everything is great.
When I use P with Wi-Fi calling, connected to R's WiFi, I get the broken behavior as described above. Notes:

This also happens if I use a Mac with WiFi calling wired to R (so no Wi-Fi), or if I access R using other Wi-Fi access points.

I am on 6.43.8, and have also downgraded to 6.43.4 to see if that helps (it did not).

I don't know how to debug this.

Help!

Posted: **Mon Jan 07, 2019 9:18 am**

When things go haywire, does any sort of traffic shaping kick in?

What's the UL speed of your wired subscription? What type of device is your MT router? How do FW rules look like? (paste output of /ip firewall filter export in [ code] ... [ /code] environment).

I was[*] successfully using WiFi calling without any problems on my VDSL (30/5 Mbps) with torrents running in UL most of time. I never allowed torrents to use up all available bandwidth though.

[*] I've since changed my mobile provider and the new one doesn't support VoLTE let alone WiFi calling. What a pity.

Posted: **Mon Jan 07, 2019 4:21 pm**

Thanks.

When things go haywire, does any sort of traffic shaping kick in?

Not that I have setup, but not sure if RouterOS is doing something behind the scenes. I don't know how to check. Nothing changed in my configuration from when it was working to when it stopped working, other than possible iOS and RouterOS updates (I guess AT&T could have also updated broadband and/or carrier things). In other words, I didn't explicitly change anything.

What's the UL speed of your wired subscription? What type of device is your MT router? How do FW rules look like? (paste output of /ip firewall filter export in [ code] ... [ /code] environment

50/10 connection, I get about 45/11 Mbps per Ookla speed test

MT router: CRS125-24G-1S-2HnD running 6.43.8

Results from /ip firewall export below. Note that I have tried with all filter drop rules disabled, and WiFi calling still breaks:

/ip firewall filter
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="For L2TP/IPSec" port=1701,500,4500 protocol=udp
add action=accept chain=input comment="For L2TP/IPSec" protocol=ipsec-esp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

I understand that the phone is establishing and IPsec tunnel with the carrier, is the masquerade possibly getting in the way (and if so, why would it work for 15-20 seconds?). On a different forum for Ubiquiti products, I did see someone else with a iPhone that was exhibiting similar behavior, and they said the are able to see that after 15-20 seconds the outbound packets aren't making it to/through the router.

Posted: **Mon Jan 07, 2019 4:49 pm**

I'm not sure if this is related to Wi-Fi calling, but it shouldn't hurt. The SIP helper that's built in to Mikrotik and most other routers tends to break SIP. Disable it.

/ip firewall service-port
set sip disabled=yes

I've also had a Brighthouse ISP modem cause problems too. ISP tech support wasn't helpful, but a few months later when the modem was replaced SIP started working fine again.

Posted: **Mon Jan 07, 2019 5:06 pm**

For WiFi calling, if done as per 3gpp standards, indeed phone establishes a VPN connection to providers IMS core. So SIP helper has nothing to do with it.

As to service disruptions: I've had experience (with some other party's router) that phone seemingly successfully registered to IMS core (and displayed WiFi calling icon), but no actual calls could be established (neither incoming nor outgoing). Rebooting the router fixed the problem ... for a few weeks. As that router was crappy HO (not even SO

) device, it was replaced by a RB.

My thinking is that if the service is disrupted after some time of normal behaviour, it might be due to some congestion somewhere (related question: if you keep voice call running, does the service resume normally?) ... as WiFi calling per-se doesn't offer any QoS, it might be some other uplink-intensive app which saturates your UL and disrupts ongoing WiFi call. It would help if you could monitor WAN interface load during such events to see if UL doesn't get up to physical capacity of your line (DSL presumably). If this is the case, you might be able to construct some QoS setup which would prioritize WiFi calling traffic in UL. The other thing to note is that CRS is not a very powerful router and that it might have hard time routing traffic at desired rate. Things might get even worse if HW offload is not active for switching between ports. If you post complete setup of your unit we can check for some deficiencies in your setup.

Posted: **Mon Jan 07, 2019 5:32 pm**

Thank you for the quick response. I don't think it's congestion on while in a call, as it happens repeatedly on every call about 15-20 seconds in.

But, if there is congestion, it would have to be in the LAN and not upstream. What is the best way for me to monitor this within the CRS?

1- You mention that the CRS is not a very powerful router. I don't believe I am doing anything wrong, and it should be hw switching at 1Gbps, no? With that said, which do you recommend as a 24-port GB router?

2- Here is a post of my entire setup (some sensitive information replaced with "qqq":

# jan/07/2019 09:21:10 by RouterOS 6.43.8
# software id = SFJZ-9Q04
#
# model = CRS125-24G-1S-2HnD
# serial number = 49C70422EE85
/interface bridge
add admin-mac=4C:5E:0C:91:81:09 auto-mac=no comment=defconf name=_LAN
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
    disabled=no distance=indoors frequency=2427 hide-ssid=yes mode=ap-bridge \
    ssid=MyRouter wireless-protocol=802.11
/interface ethernet
set [ find default-name=ether1 ] comment="Broadband - ethernet 1" name=_WAN
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys \
    supplicant-identity=MikroTik wpa-pre-shared-key=qqq \
    wpa2-pre-shared-key=qqq
/ip pool
add comment="pool for vpn connections" name=vpn-pool ranges=\
    10.10.128.2-10.10.128.15
add comment="overflow pool for dhcp" name=overflow ranges=\
    192.168.2.100-192.168.2.199
add name=dhcp next-pool=overflow ranges=192.168.3.1-192.168.3.199
/ip dhcp-server
add address-pool=dhcp disabled=no interface=_LAN name=dhcp-main
/ppp profile
set *0 local-address=10.10.128.1 remote-address=vpn-pool
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0
/interface bridge port
add bridge=_LAN comment=defconf interface=ether2
add bridge=_LAN comment=defconf interface=ether3
add bridge=_LAN comment=defconf interface=ether4
add bridge=_LAN comment=defconf interface=ether5
add bridge=_LAN comment=defconf interface=ether6
add bridge=_LAN comment=defconf interface=ether7
add bridge=_LAN comment=defconf interface=ether8
add bridge=_LAN comment=defconf interface=ether9
add bridge=_LAN comment=defconf interface=ether10
add bridge=_LAN comment=defconf interface=ether11
add bridge=_LAN comment=defconf interface=ether12
add bridge=_LAN comment=defconf interface=ether13
add bridge=_LAN comment=defconf interface=ether14
add bridge=_LAN comment=defconf interface=ether15
add bridge=_LAN comment=defconf interface=ether16
add bridge=_LAN comment=defconf interface=ether17
add bridge=_LAN comment=defconf interface=ether18
add bridge=_LAN comment=defconf interface=ether19
add bridge=_LAN comment=defconf interface=ether20
add bridge=_LAN comment=defconf interface=ether21
add bridge=_LAN comment=defconf interface=ether22
add bridge=_LAN comment=defconf interface=ether23
add bridge=_LAN comment=defconf interface=ether24
add bridge=_LAN comment=defconf interface=sfp1
add bridge=_LAN comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface l2tp-server server
set allow-fast-path=yes default-profile=default enabled=yes ipsec-secret=qqq \
    use-ipsec=required
/interface list member
add comment=defconf interface=_LAN list=LAN
add comment=defconf interface=_WAN list=WAN
/ip address
add address=192.168.2.254/23 comment=defconf interface=ether2 network=\
    192.168.2.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=_WAN
/ip dhcp-server lease
add address=192.168.2.244 client-id=1:80:2a:a8:86:5b:52 comment=\
    "Unifi AP (office)" mac-address=80:2A:A8:86:5B:52 server=dhcp-main
add address=192.168.2.11 client-id=1:c0:56:e3:10:ab:47 comment=\
    "SwannView Camera (Port 85)" mac-address=C0:56:E3:10:AB:47 server=\
    dhcp-main
add address=192.168.2.2 client-id=1:0:14:fd:12:5a:ac comment=\
    "TM NAS (Port 80)" mac-address=00:14:FD:12:5A:AC server=dhcp-main
add address=192.168.2.1 client-id=1:0:11:32:66:11:85 comment=\
    "Synology Diskstation" \
    mac-address=00:11:32:66:11:85 server=dhcp-main
add address=192.168.2.10 client-id=1:30:59:b7:4f:34:a4 comment=\
    "XBox One (UDP 3074)" mac-address=30:59:B7:4F:34:A4 server=dhcp-main
add address=192.168.2.242 client-id=1:44:d9:e7:2:28:b1 comment=\
    "Unifi AP (kitchen)" mac-address=44:D9:E7:02:28:B1 server=dhcp-main
add address=192.168.2.241 client-id=1:44:d9:e7:90:55:ef comment=\
    "Unifi AP (family)" mac-address=44:D9:E7:90:55:EF server=dhcp-main
add address=192.168.2.240 client-id=1:80:2a:a8:53:2d:c comment=\
    "Unifi AP (master)" mac-address=80:2A:A8:53:2D:0C server=dhcp-main
add address=192.168.2.243 client-id=1:44:d9:e7:f6:4e:be comment=\
    "Unifi AP (upstairs)" mac-address=44:D9:E7:F6:4E:BE server=dhcp-main
/ip dhcp-server network
add address=192.168.2.0/23 comment=defconf dns-server=192.168.2.254 gateway=\
    192.168.2.254 netmask=23
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.2.254 name=router
add address=192.168.2.1 name=nas
add address=192.168.2.2 name=tm-nas
add address=192.168.2.11 name=camera
/ip firewall address-list
add address=0.0.0.0 comment="qqq" list=port_forward_whitelist
/ip firewall filter
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="For L2TP/IPSec" port=1701,500,4500 \
    protocol=udp
add action=accept chain=input comment="For L2TP/IPSec" protocol=ipsec-esp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=_WAN type=external
add interface=_LAN type=internal
/lcd interface pages
set 0 interfaces=wlan1
/ppp secret
[[redacted-qqq]]
/system clock
set time-zone-name=America/Chicago
/system identity
set name=MikroTik-main
/system scheduler
add comment="Check and update DDNS settings every 1m" interval=1m name=dynDNS \
    on-event=dynDNS-google policy=read,test start-time=startup
/system script
add comment="Update DDNS record at Google DDNS" \
    dont-require-permissions=no name=dynDNS-google owner=admin policy=\
    read,test source="# Variables\
    \n\
    \n# Username and word are the long cryptic ones Google Domains provide\
    s,\
    \n# not your regular Google account ones\
    \n:local GoogleDNSUsername \"qqq";\
    \n:local GoogleDNSPassword \"qqq";\
    \n:local hostName \"qqq\";\
    \n:local currentIP \"\";\
    \n:local setResults \"\";\
    \n:local previousIP \"\";\
    \n\
    \n# Script\
    \n:set currentIP [/ip cloud get public-address];\
    \n:set previousIP [:resolve \"\$hostName\"];\
    \n:put (\"currentIP is \$currentIP\");\
    \n:put (\"previousIP is \$previousIP\");\
    \n\
    \n:if (\$currentIP != \$previousIP) do={\
    \n:do {\
    \n:local url \"https://\$GoogleDNSUsername:\$GoogleDNSPassword@domains.goo\
    gle.com/nic/update\?hostname=\$hostName&myip=\$currentIP\"\
    \nput \"doing work with url: \$url\";\
    \n/tool fetch url=\$url mode=https dst-path=GoogleDNS.txt;\
    \n:set setResults [/file get GoogleDNS.txt contents];\
    \nput \$setResults;\
    \n:log info (\"GoogleDNS said this: \$setResults\")\
    \n} on-error={ \
    \n:log error (\"GoogleDNS: script failed to set new IP address\") \
    \n};\
    \n};"
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Thanks!

Posted: **Mon Jan 07, 2019 6:50 pm**

I'm not sure if this is related to Wi-Fi calling, but it shouldn't hurt. The SIP helper that's built in to Mikrotik and most other routers tends to break SIP. Disable it.
Code: Select all
/ip firewall service-port
set sip disabled=yes
I've also had a Brighthouse ISP modem cause problems too. ISP tech support wasn't helpful, but a few months later when the modem was replaced SIP started working fine again.

I tried this, didn't fix the issue

Posted: **Mon Jan 07, 2019 8:32 pm**

CRS is a great switch. If you'll decide to change something, you should add a router (hAP ac2 seems a decent router for a very low price) and keep CRS for switching/WAP only.

Nothing in the config caught my eye.
Can you check if HW offload is actually used on ether ports? Output of /interface bridge port should reveal that ...

You can follow utilization of different resources (i.e. ether ports) using one of GUIs (either WebFig or winbox) ... another thing to check is CPU load (and if found high also profiling it to see which process is choking it).

Posted: **Mon Jan 07, 2019 8:42 pm**

Thanks

1 - Yes, all ports other than WAN have HW "yes".

2 - You bring up a good point about adding a specific router and letting the CRS just do switching/AP. The reason why I have 50 Mbps internet is because I have never been able to get more than about 80 MBps through my Mikrotik (I can get faster speeds connected directly to the edge modem). Are you saying that if I offload routing to a more powerful router that I may get faster performance to my broadband?

2b - To accomplish #2, is all that I have to do is to move ether1 into my bridge? Can the CRS still function as DHCP server (I suspect yes), and VPN server (I suspect no).

Thanks in advance for all the help. I will debug the loads when Wi-Fi calling stops working and report back.

Posted: **Mon Jan 07, 2019 8:58 pm**

1 - Yes, all ports other than WAN have HW "yes".

This is showing the setting. Actual value is shown with a letter H displayed in front of interface name (next to other state indicators) when HW offload is active..

2 - You bring up a good point about adding a specific router and letting the CRS just do switching/AP. The reason why I have 50 Mbps internet is because I have never been able to get more than about 80 MBps through my Mikrotik (I can get faster speeds connected directly to the edge modem). Are you saying that if I offload routing to a more powerful router that I may get faster performance to my broadband?

Yes.

2b - To accomplish #2, is all that I have to do is to move ether1 into my bridge? Can the CRS still function as DHCP server (I suspect yes), and VPN server (I suspect no).

I'd advise to move all L3 functions (routing, firewall, DHCP server, VPN, ...) to the router device and leave only switching to CRS.

Posted: **Mon Jan 07, 2019 9:19 pm**

Got it.

There is an "H" next to each of the interfaces except my WAN port (ether 1).
A bunch are also tagged "I" (inactive), but I suspect that is a function of traffic (though oddly WAN / ether 1 is also tagged I).

The other answers make complete sense. Is there an easy way for me to know that all L2 activities are off?

Posted: **Mon Jan 07, 2019 9:26 pm**

Is there an easy way for me to know that all L2 activities are off?

You can't really ... unless thoroughly inspecting behaviour of your switch ... in the line of my suggestions a few posts back.

Posted: **Tue Jan 08, 2019 8:17 am**

Use a router for routing and a switch for switching. If using one device only go for a decent router. A router can do switching with ease, a switch cannot do routing decently.

Posted: **Tue Jan 08, 2019 3:51 pm**

Sounds like good advice. I am thinking of using a RB4011iGS+RM for routing. I'll plug wireless 5-access points into this directly, then use port 10 to be connected to my current CRS-125 (configured with no layer-3, all ports bridged and hw switched).

I suspect this will resolve my current CRS choke point when my broadband is faster than about 100 MBps. Any reason to believe I won't be able to get up to 400-500 mpbs routed?

Also, and more importantly, I have an update on the Wi-Fi calling. I changed the brand of residential gateway from AT&T (from Pace to Motorola), and everything magically started working again. Either AT&T introduced a bug in a Pace software update, some software update there exposed a nuanced bug/incompatibility with the 'Tik.

Thanks!

Posted: **Tue Jan 08, 2019 3:52 pm**

Sounds like good advice. I am thinking of using a RB4011iGS+RM for routing. I'll plug wireless 5-access points into this directly, then use port 10 to be connected to my current CRS-125 (configured with no layer-3, all ports bridged and hw switched).

I suspect this will resolve my current CRS choke point when my broadband is faster than about 100 MBps. Any reason to believe I won't be able to get up to 400-500 mpbs routed?

Also, and more importantly, I have an update on the Wi-Fi calling. I changed the brand of residential gateway from AT&T (from Pace to Motorola), and everything magically started working again. Either AT&T introduced a bug in a Pace software update, some software update there exposed a nuanced bug/incompatibility with the 'Tik.

Thanks!

Posted: **Tue Jan 08, 2019 6:19 pm**

everytime this happens to our customers on our mikrotik network its because fragmented packets are getting dropped (silently). connection-tracking will stop fragmented packets if you arent letting them thru, because it cant handle a fragmented packet until it reassembles it.

Posted: **Tue Jan 08, 2019 6:27 pm**

everytime this happens to our customers on our mikrotik network its because fragmented packets are getting dropped (silently). connection-tracking will stop fragmented packets if you arent letting them thru, because it cant handle a fragmented packet until it reassembles it.

It appears that i am allowing established connections to go through prior to dropping invalid. From /ip firewall filter:

...
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
...

Is there something else I need to do to allow them through?

Posted: **Tue Jan 08, 2019 7:36 pm**

im not in front of a router to check, but can you allow fragmented packets in the raw chain? probably not a good idea long term but a proof of concept. typically i do not use connection-tracking and so turning it off fixes our problems but with NAT you cant do that. wait ... actually its the fact there is a single or more firewall filter without connection tracking that breaks it in my case. kinda hard to explain, but it has to do with fragmented packets not making it through the router. run a pcap of it coming and leaving that router and you will see they dont make it through.

Posted: **Fri Apr 12, 2019 9:16 pm**

I am having the same issue with three different Routers. Just started within the last month or so. No config changes or upgrades.

Posted: **Sat Apr 13, 2019 5:43 pm**

The first thing to be done here is to find out whether Mikrotik is causing it or not. Using /tool sniffer, you can check whether the IPsec transport packets from the phone's IP address continue being sent or not after the other party stops hearing you. You'd sniff on the phone-facing interface first, filtering on phone's IP address and UDP port 4500, and then on the WAN, filtering on the other IP address (found during the previous sniff) and UDP (port 4500 may not be used at WAN side if you're running some other IPsec tunnel from the router itself or from some other device on its LAN side). If during the first call the packets stop coming from the phone, the phone itself is guilty; if they disappear from WAN in the second call after a while but they didn't from the phone-facing interface in the first call, the Mikrotik is guilty; and if they leave the WAN although the remote party doesn't hear you, both the phone may be guilty (sending silence inside the packets) and the IMS network. Or there is an even less likely scenario, Mikrotik starting to change the packets' contents causing them to be incomprehensible to the recipient. It would require sniffing at both interfaces simultaneously into a file and analysing the packets using Wireshark to check this.

Posted: **Mon Jun 29, 2020 11:16 pm**

Hi. I had this problem and found that it was caused by the IPv4 FastTrack feature. I was able to correct it by excepting IPsec traffic from FastTrack using connection marking.

/ip firewall mangle
add action=mark-connection chain=forward comment=\
    "mark outbound IPsec connections to exclude them from fasttrack" \
    ipsec-policy=out,ipsec new-connection-mark=ipsec
add action=mark-connection chain=forward comment=\
    "mark inbound IPsec connections to exclude them from fasttrack" \
    ipsec-policy=in,ipsec new-connection-mark=ipsec

;;; replace your existing FastTrack rule with this one
/ip firewall filter
add action=fasttrack-connection chain=forward comment=\
    "fasttrack all non-IPsec traffic" connection-mark=!ipsec

Posted: **Sat Jul 11, 2020 1:08 pm**

I wonder how this is related to the issue - your mangle rules rely on ipsec policies to exist on the router itself, but WiFi calling does not use IPsec on the router itself.

Posted: **Mon Jul 13, 2020 5:36 pm**

I think it has to do with fragmented packets getting dropped on mikrotik if they aren't run thru the firewall. Not sure if there is a way in RAW filter to just accept them or not.

MikroTik

Mikrotik breaking Wi-Fi Calling?

Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?

Re: Mikrotik breaking Wi-Fi Calling?