Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Отваливается регистрация клиентов [решено]

0

Периодически (очень избирательно) отваливается регистрация клиентов. Все клиенты находятся за 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

Пробовал два варианта подключения:

  1. Для каждого extension указывать nat=force_rport,comedia.
  2. Убирал nat и указывал для устройств STUN сервер (stun.l.google.com)

В обоих случаях все клиенты регистрировались, звук проходил в обоих направлениях. Работали (да и работают) исходящие и входящие звонки.

Танцы с 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

В какую сторону двигаться? Что может быть причиной?

удалить закрыть спам изменить тег редактировать

спросил 2016-03-24 00:56:08 +0400

sergey Gravatar sergey
1 1 1 2

обновил 2016-03-24 16:45:53 +0400

Comments

судя по многоликости оборудования (разные шлюзы и 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 )редактировать

1 Ответ

0

Похоже на проблему с register timeout, попробуйте уменьшить его на клиенте или увеличить на сервере.

ссылка удалить спам редактировать

ответил 2016-03-24 13:40:19 +0400

desmoquattro Gravatar desmoquattro
1 1

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2016-03-24 00:56:08 +0400

Просмотрен: 7,406 раз

Обновлен: Mar 24 '16

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.