Итак, есть шлюз GrandStream GXW4004, прошивка последняя не beta. Настроен на регистрацию через инет на астериск, каждый порт expiry = 60 сек.
Доступ в интет сделан через нат, в качестве роутера используется DLink Dir320 на котором настроено pptp соединение с провайдером, выдается динамический ip.
Все работает нормально до момента перерегистрации соединения (раз или два в день).
После чего GS упорно не хочет регистрироваться, точнее если посмотреть то проскакивают попытки регистрации, но опять теряются.
Ребутим GS - ноль эффекта.
Ребутим Dlink - регистрация с полпинка, все зашибись до следующего обмирания.
Как и что настроить (если это возможно) в шлюзе или длинке, чтоб было все хорошо?
Помнится мучился с 320 длинком. проблема оказалось в корявой реализации нат, понял только тогда когда задампил пакеты от роутера в сторону провайдера. Заменил 320 на линксис. Сижу курю.
Прописать host= статикой для данного шлюза, еще externip подменить астеру на внутренний для данного пира. Еще nat=never. Далее включить сип отладку и посмотреть приходят ли отклики от астера
Dir320 имеет привычку не пропускать регистрацию, я такой эффект наблюдал после того как торренты запускал (количество соединении думаю проблема) :)
решается перезагрузкой DIR-320.
Попробуй залить туда DD-wrt там можно настроить лимит.
По личному опыту - это болезнь ВСЕХ файрволов SPI, которые используют исходящее соединение PPTP или PPPoE. Механика болезни:
Поднятие канала PPTP или PPPoE занимает длительное (с точки зрения компьютера) время. С момента реального поднятия порта и до окончания поднятия всей его обвязки порта проходит 1-4 сек (этакий переходной процесс).
Если за это время с клиента пытается установиться соединение, то на него в "мозгах" файрвола создаётся сессия, по которой файрвол отслеживает состояние и разрешает пакеты относящиеся к этой сессии без углублённого их анализа.
Если соединение с клиента попытается подняться в момент "переходного процесса", то сессия на него получается кривая. Если TCP быстро отвалится, т.к. сессия реально не установится, то UDP-сессия отваливается только по timeout, который обычно в районе 120 сек (в силу отсутствия в UDP понятия окончания сессии).
Получаем: клиент попал в "переходной процесс", получил кривую UDP-сессию, и постоянно стучится пытаясь аутентифицироваться, постоянно поддерживая timeout этой кривой UDP-сессии, не давая ей умереть.
У кого видел такую болезнь:
Аппаратные маршрутизаторы SPI (типа DLink, TPLink, ASUS, LinkSys и т.д.).
Программные маршрутизаторы SPI (типа Kerio Winroute Firewall и ему подобные).
Как лечить (варианты):
Уйти от PPTP и PPPoE. StaticIP и DHCP этой проблеме вроде не подвержены.
Установить время повторных попыток неудачной аутентификации больше времени жизни UDP-сессии на маршрутизаторе с SPI.
Отключить на маршрутизаторе SPI.
Мониторить состояние VoIP регистраций. Если более 3-4 попыток, попытаться дёрнуть канал PPTP/PPPoE, что бы "убить" кривые UDP-сессии из расчёта, что второй раз наше устройство так не влетит.
Убить кривые UDP-сессии на маршрутизаторе, в случае их появления.
Задан: 2011-04-08 16:20:10 +0400
Просмотрен: 3,424 раз
Обновлен: Apr 12 '11
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.