Asterisk: внешние транки в состоянии Request Sent

[root@pbx scripts]# asterisk -x "sip show registry" 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 

Однажды она меня тоже достала, и я написал скрипт.

Пытался искать готовые рецепты, большинство сводилось к такому:
ну это значит что пакеты уходят, а ответы не приходят.
варианты
1) у вас нет интеренета.
2) у вас упал провайдер
3) у вас фаервол все блочит
4) у вас нет дефаулт гейтевея в системе.
попробуйте попингать те же адреса.. дебаг включите
Попингать адреса получалось, дебаг включал и видел в нём ровно то, о чем говорится в первом предложении цитаты «пакеты уходят, а ответы не приходят». Но почему?
Пункт №1 исключался элементарно. Пункт №2 — тоже, т.к. тестовое соединение с того же IP-адреса, но другого внутреннего хоста работало. Пункт №4 это совсем «жость». А вот №3 — уже ближе. Только не блочит, а почему-то не дает обмениваться пакетами именно хосту с Asterisk’ом.
И происходит это в 99% случаях после пункта №2, когда рвется PPPoE сессия. Сессия-то потом восстанавливается, и доступ в инет из локалки тоже, а вот UDP-сессии залипают.
Вот что нам говорит Mikrotik, через который эти сессии проходят:

[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  #          PR.. SRC-ADDRESS           DST-ADDRESS           TCP-STATE   TIMEOUT     ORIG-RATE REPL-RATE ORIG-PACKETS REPL-PACKETS      ORIG-BYTES  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 

Это состояние сессий в нормальном режиме, когда всё работает. При отсутствии регистраций, если мне не изменяет память, отсутствует флаг S — seen-reply.
Пробуем срубить залипшие сессии командой

[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]

И, о чудо, буквально через секунду транки восстанавливаются, звонки идут, жизнь расцветает яркими красками! Значит пишем скрипт!
Первое — нам надо управлять Микротом на основе информации с Asterisk. Поэтому скрипт будет запускаться в cron каждые 5 минут на хосте с Asterisk, а управлять Микротом будем по ssh с сертификатом. Вот тут прекрасно всё расписано — как создать ключ и привязать его к новому пользователю на Микроте.
Ну и сам скрипт:

#!/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 

На всякий случай через 2 секунды после сброса зависших сессий обновляем регистрации — чтобы уж точно заработало!
С 04.09.2019 скрипт отработал 273 раза, судя по логу. Можно посчитать, сколько он сэкономил мне времени, а менеджерам и их клиентом нервов.

P.S. Подобная ситуация происходит на всех роутерах, которые мне попадались в связке с Asterisk. И только Микрот позволяет решить проблему без затрагивания других сервисов. Остальные роутеры надо тупо перегружать.