Пропадание регистрации под нагрузкой
Добавлено: 14 фев 2011, 08:14
Здравствуйте. На сервере с asterisk 1.6.2.16.1 и freepbx 2.8 регистрируем 3 двухканальных сип-телефона, подключены напрямую к провайдеру, нат отсутствует. С недавнего времени провайдер чтото сменил у себя в настройках изза чего у нас периодически (в моменты пиков звонков) теряется регистрация (год все работало нормально, без сбоев). Провайдер сообщает, при исходящем звонке что наш астериск совершает множество одинаковых ивайтов, что, дескать, не есть хорошо, заставили отключить qualify, т.к. лишние запросы на их сервер рассматривают как ДДОС атаку (!) и временно банит. После срыва регистрации минут пять отсутствует исходящая связь (звонок в тишину) и входящая тоже (абонент вне зоны), затем само все восстанавливается. Разбираюсь с сип-протоколом, снял дампы с сетевой, подключенной к провайдеру. В Wiresharke видно, будто сервер провайдера перестает отвечать на наши запросы в моменты пропадания регистраций (попытки зарегистрироваться не получают ответа). До конца не могу понять, кто виноват, провайдер, отключающий нас в моменты пиков звонков или у нас чтото не так настроено (в подавляющее время все работает нормально, проблемы только в часы пик). Вот пример моих конфигов:
[sip500500]
type=friend
username=XXXXXXXX
secret=YYYYYYYY
host=sip.telecom.kz
nat=no
fromuser=XXXXXXXX
fromdomain=sip.telecom.kz
dtmfmode=rfc2833
canreinvite=no
insecure=port,invite
qualify=no
disallow=all
allow=alaw
context=from-trunk
Просьба глянуть дамп, может у кого будут мысли, что можно предпринять. Дамп залил сюда: http://rghost.ru/4348679 , в нем проблема зафиксирована примерно на временном промежутке 08:49-09:55. С уважением, Юрий
[sip500500]
type=friend
username=XXXXXXXX
secret=YYYYYYYY
host=sip.telecom.kz
nat=no
fromuser=XXXXXXXX
fromdomain=sip.telecom.kz
dtmfmode=rfc2833
canreinvite=no
insecure=port,invite
qualify=no
disallow=all
allow=alaw
context=from-trunk
Просьба глянуть дамп, может у кого будут мысли, что можно предпринять. Дамп залил сюда: http://rghost.ru/4348679 , в нем проблема зафиксирована примерно на временном промежутке 08:49-09:55. С уважением, Юрий