Get best of the week

星号：外部中继处于“请求发送”状态

熟悉的照片吗？

[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

一旦她也得到我，我就写了剧本。

我试图搜索现成的食谱，大多数都归结为这一点： 我对地址进行了ping操作，打开了调试程序，并在其中看到了报价第一句话中的确切含义：“数据包走了，但答案没有来。”但为什么？ 点1被排除为基本。第二点-也因为来自相同IP地址但不同内部主机的测试连接正常工作。点号4绝对是“ zhost”。但是3号已经越来越近了。它只是没有被阻止，但是由于某种原因，它不允许主机与Asterisk交换数据包。 在PPPoE会话中断的第2点之后，这种情况发生在99％的情况下。然后恢复该会话，并且也可以从LAN访问Internet，但是UDP会话被卡住了。 这是Mikrotik告诉我们这些会议进行的过程：

, .

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
 #          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-可见答复。

我们尝试使用以下命令减少卡住的会话：

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

而且，瞧，实际上是在第二条树干中恢复了声音，通话继续进行，生命绽放着鲜艳的色彩！因此，我们正在编写脚本！

首先，我们需要基于来自Asterisk的信息来控制Mikrot。因此，该脚本将在具有Asterisk的主机上每5分钟在cron中运行一次，并且我们将通过带有证书的ssh管理Mikrot。这里有完美的画的一切-如何创建密钥，并将其拴在小耳畸形的新用户。

好吧，脚本本身：

#!/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秒后，我们会更新注册-这样就可以正常工作了！

从日志来看，从2019年9月4日起，该脚本工作了273次。您可以计算出他为我节省了多少时间，以及经理和他们的客户的神经。

PS我与Asterisk一起遇到的所有路由器都发生了类似的情况。而且只有Mikrot可以解决问题，而不会影响其他服务。其余路由器需要愚蠢地过载。

More articles:


All Articles