Периодически (очень избирательно) отваливается регистрация клиентов. Все клиенты находятся за NATом. Asterisk имеет внешний IP адрес.
В одном офисе находится один телефон (с одной сип учетной) + база с двумя учетками (Panasonic KX TGP600). В другом офисе база с двумя учетками (Gigaset A510 IP). Оба офиса живут с статичными IP. В iptables открыт доступ с каждого к sip & rtp портам:
-A INPUT -i eth1 -s %office_ip% -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -i eth1 -s %office_ip% -p tcp -m tcp --dport 5060 -j ACCEPT
-A INPUT -i eth1 -s %office_ip% -p udp -m udp --dport 10000:20000 -j ACCEPT
На каждой из баз постоянно теряет регистрацию один и тот же клиент (202 - Panasonic, 302 - Gigaset, 903 - Zoiper):
pbx*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
101/101 %office_1_ip% D Auto (No) Auto (No) A 5061 OK (65 ms)
201/201 %office_1_ip% D Auto (No) Auto (No) A 5063 OK (56 ms)
202/202 (Unspecified) D No No A 0 UNKNOWN
301/301 %office_2_ip% D Auto (No) Auto (No) A 40069 OK (24 ms)
302/302 %office_2_ip% D Yes Yes A 40069 OK (38 ms)
903/903 (Unspecified) D Auto (No) Auto (No) A 0 UNKNOWN
sip_general_additional.conf:
nat=force_rport,comedia
externip=%my_ip%
ALLOW_SIP_ANON=no
localnet=%my_gateway%/28
localnet=172.16.0.0/24
localnet=172.16.3.0/24
canreinvite=no
Пробовал два варианта подключения:
В обоих случаях все клиенты регистрировались, звук проходил в обоих направлениях. Работали (да и работают) исходящие и входящие звонки.
Танцы с sip set debug peer & tcpdump ни к чему не привели. Asterisk может преспокойно засылать клиента пакетами OPTIONS (хоть с qualify=1), и клиент будет отвечать, но через секунду регистрация клиента может потеряться. В большинстве случаев потеря регистрации происходит через случайные (не понятные мне) промежутки времени и не предваряется запросом OPTIONS (хотя казалось бы qualify как раз за это и отвечает).
Выглядит это так:
[2016-03-23 19:49:51] DEBUG[1403] devicestate.c: No provider found, checking channel drivers for SIP - 302
[2016-03-23 19:49:51] DEBUG[1403] chan_sip.c: Checking device state for peer 302
[2016-03-23 19:49:51] DEBUG[1403] devicestate.c: Changing state for SIP/302 - state 5 (Unavailable)
[2016-03-23 19:49:51] DEBUG[1407] app_queue.c: Extension '302@ext-local' changed to state '5' (Unavailable) but we don't care because they're not a member of any queue.
[2016-03-23 19:49:51] DEBUG[1407] app_queue.c: Extension '*80302@ext-local' changed to state '5' (Unavailable) but we don't care because they're not a member of any queue.
[2016-03-23 19:49:51] DEBUG[1651] app_queue.c: Device 'SIP/302' changed to state '5' (Unavailable) but we don't care because they're not a member of any queue.
В разных офисах разные роутеры, разные устройства. Доходит до абсурда - софтофон (Zoiper), работающий в одной локальной сети с сервером, - работает замечательно. Но как только подключается через шлюз (debian + squid) к АТС, то спустя некоторое время начинает (периодически) терять регистрацию.
ОС Debian 8 Jessie Asterisk 13.6.0 + FreePBX 13.0.58
В какую сторону двигаться? Что может быть причиной?
Похоже на проблему с register timeout, попробуйте уменьшить его на клиенте или увеличить на сервере.
Задан: 2016-03-24 00:56:08 +0400
Просмотрен: 7,403 раз
Обновлен: Mar 24 '16
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
судя по многоликости оборудования (разные шлюзы и linux в придачу) вам надо нанимать эксперта кто будет разбирать с вашей проблемой - снимать дамп, менять прошивки, разбираться с NAT и Linux шлюзом. Потому то что можно было попробовать - вы судя по всему уже попробовали. PS Если честно - я бы поднял сеть VPN и забыл бы проблему с NAT
awsswa ( 2016-03-24 07:45:56 +0400 )редактироватьmodules.conf noload=>timing_pthread.so
meral ( 2016-03-24 14:34:32 +0400 )редактировать1.5 часа, полёт нормальный. Спасибо, meral!
sergey ( 2016-03-24 16:39:15 +0400 )редактироватьнезашо. используйте centos и не будет такой фигни.
meral ( 2016-03-25 12:49:23 +0400 )редактировать