wkamlun
December 21, 2021, 3:21am
1
I am not able to dial out wifi-call from mobile phone with a layer 2 AP connect to RB4011 with details:
Phone A connected to the wifi and dial a call out, Phone B with no wifi will ring and can pick up the call but without sound.
Any help?
sindy
January 11, 2022, 9:31am
3
When talking about “wifi call”, do you have in mind the “WiFi calling” or “VoWiFi” service (same thing, different marketing names) provided by the mobile operator, or some IP phone application where an app on the smartphone registers with some other account not related to the mobile operator?
wkamlun
January 12, 2022, 12:46am
4
My issue is just concerning the WiFi Call service provided by the mobile operator.
My cellular service outside the house is “ok”.
So I have wifi calling turned on, in my phone. As soon as I get in range of my wifi my phone flips to wifi calling. I work from home most days and make about 40 calls per day. They all show as over wifi…
Getting to the point.
I can see a connection to Verizon’s Calling Gateway on port 4500.
When I am actually on the phone… I can see the packets between when they talk and when I talk.
So…
Then you can start trouble shooting.
I can see the connection of the IP for the port 4500, but how can I track to that to the WAN port?
sindy
January 12, 2022, 8:01am
7
And in particular - the symptoms you describe (outgoing call ringing at the called party but nothing happens when the called party accepts it), it seems as if the answer message (SIP 200 OK) did not make it to your router from the mobile operator’s exchange, or the router has failed to forward it to the phone.
So open a command line window to the router, make it as wide as your screen allows, and run/tool sniffer quick ip-address=ip.of.mobile.exchange port=4500
While there is no call, you should see some keepalive packets every 20 seconds or so. Leave it like that for, say, two minutes, then stop the sniffer (Ctrl-C), do /tool sniffer packet print , copy the output as text and post it here (if you have a public IP on WAN of the router, replace it systematically by my.pub.lic.ip or so before posting).
You should see each packet multiple times - in via wlanX, then in via bridge, then out via ether1 (WAN), and then the response in reverse order, if your RB4011 is more or less in the factory default configuration.
Once we get past this, we can debug the actual issue.
sindy
January 12, 2022, 8:39am
9
Because WiFi calling = VoWiFi establishes an IPsec tunnel from the phone to the operator’s exchange, so that no one could wiretap the calls on the packet network. Apparently this turned out simpler than to deal with SIPS (SIP/TLS) and SRTP.
wkamlun
January 13, 2022, 12:36am
10
sindy:
And in particular - the symptoms you describe (outgoing call ringing at the called party but nothing happens when the called party accepts it), it seems as if the answer message (SIP 200 OK) did not make it to your router from the mobile operator's exchange, or the router has failed to forward it to the phone.
So open a command line window to the router, make it as wide as your screen allows, and run/tool sniffer quick ip-address=ip.of.mobile.exchange port=4500
While there is no call, you should see some keepalive packets every 20 seconds or so. Leave it like that for, say, two minutes, then stop the sniffer (Ctrl-C), do /tool sniffer packet print , copy the output as text and post it here (if you have a public IP on WAN of the router, replace it systematically by my.pub.lic.ip or so before posting).
You should see each packet multiple times - in via wlanX, then in via bridge, then out via ether1 (WAN), and then the response in reverse order, if your RB4011 is more or less in the factory default configuration.
Once we get past this, we can debug the actual issue.
This is the result. I just fine tune to include the "via WAN traffic".
/tool/sniffer/packet/print
0 6.581 ether10 192.168.1.8:4500 dest-pub-ip:4500 udp 60 2
Any idea?
sindy
January 13, 2022, 7:27am
11
OK. This shows that the phone has a local address of 192.168.1.8, is connected via a WiFi AP connected via ether10, ether10 is a member port of bridge local, and ether1 is a WAN.
So now you can run the sniffer again, not restricting it to a particular interface, try the outgoing call, and try to answer the call on the called phone. Since the traffic is encrypted, you cannot identify the SIP registration updates and call control messages and RTP media packets from one another and from the IPsec keepalive traffic by anything else but size. But all the SIP and RTP packets should be larger than the 122 bytes of the IPsec DPDs you can see in the “idle time” capture as above. Which means that when printing the captured packets, you’ll use /tool/sniffer/packet/print where size>122 in order to get rid of the “background noise” and only see the SIP & RTP.
So the pattern we are looking for is the following:
as you press “call”, there should be a single large message from the phone to the exchange (the INVITE), responded by a multiple smaller ones from the exchange (100 Trying, 180 Ringing, 183 Media Change - cannot say whether all of them will be there, but at least one should)
many same-size packets (RTP ones) should follow, carrying the alerting tone, unless the exchange asks the phone to generate the tone - both cases are possible
once you answer the called phone, one packet larger than the RTP ones should be seen from the exchange to the phone (200 OK), “responded” with another “larger-than-RTP” one from the phone (ACK). Following the 200 OK, the RTP should start flowing in both directions.
What we are looking for is whether the 200 OK arrives to ether1 (WAN) and whether the router delivers it all the way to ether10. That’s basically all we can find - if it does, the only other wrongdoing of the router could be that it malforms the contents of the packet as delivering it; to find out, it would be necessary to sniff into a file, open the file using Wireshark, and compare the payload of the two packets - the Ethernet and IP headers will be different due to NAT and different MAC addresses.
If the router did nothing wrong, it must be the exchange, the phone, or the wireless AP.
What can interfere with the message exchange outlined above is the periodic SIP registration, which has its own timing, independent from the call establishing messages. So better to do the complete procedure (two separate sniffings) for two calls and compare the results. You can filter out also the RTP by size to have only the SIP packets printed, or you can sniff into files and open them using Wireshark for better filtering and graphing possibilities.
As you specifically mention outgoing calls, do I read it right that incoming calls work normally for this phone and this home network? What about outgoing calls in another wireless network?
wkamlun
January 14, 2022, 12:55am
12
sindy:
OK. This shows that the phone has a local address of 192.168.1.8, is connected via a WiFi AP connected via ether10, ether10 is a member port of bridge local, and ether1 is a WAN.
So now you can run the sniffer again, not restricting it to a particular interface, try the outgoing call, and try to answer the call on the called phone. Since the traffic is encrypted, you cannot identify the SIP registration updates and call control messages and RTP media packets from one another and from the IPsec keepalive traffic by anything else but size. But all the SIP and RTP packets should be larger than the 122 bytes of the IPsec DPDs you can see in the “idle time” capture as above. Which means that when printing the captured packets, you’ll use /tool/sniffer/packet/print where size>122 in order to get rid of the “background noise” and only see the SIP & RTP.
So the pattern we are looking for is the following:
as you press “call”, there should be a single large message from the phone to the exchange (the INVITE), responded by a multiple smaller ones from the exchange (100 Trying, 180 Ringing, 183 Media Change - cannot say whether all of them will be there, but at least one should)
many same-size packets (RTP ones) should follow, carrying the alerting tone, unless the exchange asks the phone to generate the tone - both cases are possible
once you answer the called phone, one packet larger than the RTP ones should be seen from the exchange to the phone (200 OK), “responded” with another “larger-than-RTP” one from the phone (ACK). Following the 200 OK, the RTP should start flowing in both directions.
What we are looking for is whether the 200 OK arrives to ether1 (WAN) and whether the router delivers it all the way to ether10. That’s basically all we can find - if it does, the only other wrongdoing of the router could be that it malforms the contents of the packet as delivering it; to find out, it would be necessary to sniff into a file, open the file using Wireshark, and compare the payload of the two packets - the Ethernet and IP headers will be different due to NAT and different MAC addresses.
If the router did nothing wrong, it must be the exchange, the phone, or the wireless AP.
What can interfere with the message exchange outlined above is the periodic SIP registration, which has its own timing, independent from the call establishing messages. So better to do the complete procedure (two separate sniffings) for two calls and compare the results. You can filter out also the RTP by size to have only the SIP packets printed, or you can sniff into files and open them using Wireshark for better filtering and graphing possibilities.
As you specifically mention outgoing calls, do I read it right that incoming calls work normally for this phone and this home network? What about outgoing calls in another wireless network?
Incoming calls work normally for this phone in this home network.
I will try the outgoing call again in these days and let you know the result.
wkamlun
January 14, 2022, 9:08am
13
0 19.502 ether10 dst-pub-ip:4500 192.168.1.8:4500 udp 174 0
This is a outgoing call capture, any ideas?
sindy
January 14, 2022, 10:16am
14
Yes. What happens is that the exchange sends a packet so large that it exceeds the L2 MTU of the AP or the phone, or the L3 MTU of the phone, and the L3 MTU configuration on bridge local is too optimistic so the router sends that packet to the phone without fragmentation.
You can see that e.g. frame #106 in the list has 1514 bytes on ether1 ; the subsequent frame on interfaces local (the bridge) and ether10 (the port of the bridge to which the AP is connected) has 1582 bytes. It is not “inflated” by your router - what actually happens is that you sniff with port=4500 as requested, and because port numbers are not present in fragments, the frame carrying the 2nd fragment of that packet whose 1st fragment has arrived in frame #106 has not been captured into the sniff. But since the packet is routed between ether1 and local , the router reassembles it from the two fragments first.
/interface bridge set local mtu=1500 should resolve the issue. There is a negligible chance that it will break something else, so just for the case, remember that change if you eventually start encountering some problems with other devices.
Sindy,
Thanks for taking the lead on this and digging in.
wkamlun
January 17, 2022, 9:01am
16
Sindy, thanks a lot.
sindy
January 17, 2022, 9:43am
17
You’re welcome. So the only thing left is to mark my previous post as the solution for others searching for a solution of same or similar problem.
7.1.1 firmware seems solved problems with VoWIFI I experienced. I updated yesterday and still testing it, but for these two days it works well.
sindy
January 17, 2022, 3:10pm
19
Could it be that the issues you’ve encountered before the upgrade were actually configuration problems similar to the one discussed in this topic, and that the default settings of 7.1.1 are just “safer” from this perspective? The thing is that from the point of view of the router, VoWiFi is yet another UDP flow initiated by a LAN client to be forwarded and src-nated.
pe1chl
January 17, 2022, 4:01pm
20
I wonder why the effective MTU is above 1500 for these users.
It also is “interesting” that RouterOS performs reassembly for the received packets, and that this even works across IP packets that form a single UDP packet.
Finally, it is strange that the VoWIFI service sends UDP packets that are too large to fit in a 1500 byte ethernet packet. Usually those packets are much smaller, to reduce latency.