A familiar picture?[root@pbx scripts]
Host dnsmgr Username Refresh State Reg.Time
sipnet.ru:5060 Y XXXXXXXXXXX 102 Request Sent Fri, 20 Mar 2020 09:19:31
87.103.236.26:5060 N XXXXXX 105 Request Sent Fri, 20 Mar 2020 09:20:55
sbc.megafon.ru:5060 Y XXXXXXXXXXX@ 165 Request Sent Fri, 20 Mar 2020 09:20:28
login.mtt.ru:5060 Y XXXXXXXXXXXXXX 105 Request Sent Fri, 20 Mar 2020 09:19:50
Once she got me too, and I wrote a script.I tried to search for ready-made recipes, the majority boiled down to this: I got a ping of the addresses, turned on the debug and saw in it exactly what was said in the first sentence of the quote "packets go, but the answers do not come." But why? Point number 1 was ruled out elementary. Point number 2 - too, because a test connection from the same IP address but a different internal host worked. Point number 4 is absolutely "zhost". But number 3 is already closer. It just doesn’t block, but for some reason it does not allow the host to exchange packets with Asterisk. And this happens in 99% of cases after point 2, when the PPPoE session breaks. The session is then restored, and access to the Internet from LAN is also available, but UDP sessions are stuck. Here is what Mikrotik tells us through which these sessions go:, .
1) .
2)
3)
4) .
..[admin@MikroTik] > /ip firewall connection print where dst-address~":5060" and srcnat
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 SAC s udp 10.X.X.X:5060 80.75.130.83:5060 59m48s 0bps 0bps 2 172 2 191 1 358 335
1 SAC s udp 10.X.X.X:5060 193.201.229.35:5060 59m47s 0bps 0bps 1 611 1 662 996 786
2 SAC s udp 10.X.X.X:5060 212.53.40.40:5060 59m44s 0bps 0bps 1 837 1 830 1 114 259
3 SAC s udp 10.X.X.X:5060 87.103.236.26:5060 59m21s 0bps 0bps 2 501 2 509 1 614 239
This is the state of the sessions in normal mode when everything is working. In the absence of registrations, if memory serves me correctly, there is no flag S - seen-reply.We try to cut down the stuck sessions with the command:[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]
And, lo and behold, literally in a second trunks are restored, calls go on, life blooms with bright colors! So we are writing a script!First, we need to control Mikrot based on information from Asterisk. Therefore, the script will be run in cron every 5 minutes on the host with Asterisk, and we will manage Mikrot via ssh with a certificate. Here there perfectly painted everything - how to create the key and tied it to a new user on the microtia.Well, the script itself:#!/bin/sh
if /usr/sbin/asterisk -x "sip show registry" | grep -q "Request Sent"; then
echo "$(date) Resetting UDP connections on Mikrotik" >> /var/log/asterisk/mikrotik
ssh -l admin-ssh -i /XXXX/.ssh/id_dsa 10.X.X.X 'ip firewall connection remove [find where dst-address~":5060" and srcnat]'
sleep 2
asterisk -x "sip reload"
fi
Just in case, 2 seconds after the reset of the hung-up sessions, we update the registration - so that it definitely works!From September 4, 2019, the script worked 273 times, judging by the log. You can calculate how much he saved me time, and the managers and their client nerves.PS A similar situation occurs on all routers that I came across in conjunction with Asterisk. And only Mikrot can solve the problem without affecting other services. The rest of the routers need to be stupidly overloaded.