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

Проблема с sip rtcache mysql

0

Коллеги, с добрым днем вас!
Давеча словил ну уж очень странный баг. Сразу оговорюсь, гугля в паре с КО не помогла.
И так, что имеем на входе:
Asterisk 11.21.2, x86_64, Gentoo 4.1.15, клиент Mysql 5.6.28. Второй ящик - без Астера, но с полным мускулом, т.е. сервер БД.
SIP-клиенты прописаны во втором ящике и подгружаются в первый по realtime.
Абоненты (около 200) и сервер находятся по сути в одной сети, за роутерами, но без всяких ограничений в обе стороны

Все ровно работает (самовар ставится, блины жарятся) до тех пор, пока через некоторое время в логах не начинает появляться заветные записи:

chan_sip.c: Registration from <sip:100@serverip:5060> failed for 'clientip:5060' - Wrong password

При этом, номера абонентов могут быть каждый раз разными, а иногда повторяться. Ребут "проблемных" девайсов в большинстве случаев не решает проблемы.
Не хочу вдаваться в дальнейшие подробности па с бубном, но временным решением оказалось отключение кэширования в sip.conf

rtcachefriends=no

Что интересно, при наблюдении за веб-мордой проблемного телефона и включенном кэшировании, вижу в статусе 403 ошибку.
Выключаем кэширование и через таймаут failure register девайса вижу в морде - Registered
Та что грешить на неправильный пассворд и восьминога - не стОит.
Параметр match_auth_username=no. Изменение его статуса не помогает.
Номера "проблемных" телефонов оказывались во встроенной таблице users (sip show users).
И еще один момент... Эта проблема возникла после "вливания" еще около 80 абонентов и на версии Астера 11.21.1
На прежнем ящике результат этого "вливания" был намного интересней! Через 10-15 минут работы сервера было переполнение таблицы nf_conntrack и сервер вообще отказывался работать.
В старом модуль nf_conntrack был в ядре, в новом - как модуль. Вручную загруженный модуль или без него, также не решал проблемы.
Да, теперь я не вижу в консоли своих хомячков, но при этом таблица в БД удачно апдейтится.
Вроде проблема решена, НО(!), до этого при 120 абонентах такой проблемы не было! Если необходима доп.инфа, готов поделится.

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

спросил 2016-03-18 17:12:01 +0400

TandemK Gravatar TandemK
175 3 10

Comments

на мысли вот это разве не наводит nf_conntrack ? у вас банально обращений к базе от клиентов есть проблемы - не могут получить доступ. Что у вас еще на сервере крутится ? или какие самописные скрипты лезут в mysql ?

awsswa ( 2016-03-19 13:36:15 +0400 )редактировать

В сервере, кроме Астера, больше никого нет. Никаких скриптов тоже нет. Наводил на мысли, но, если бы при выключенном кэшировании были бы те же проблемы, то копал в эту сторону. А так - в полной растерянности.

TandemK ( 2016-03-21 10:32:20 +0400 )редактировать

проведите эксперимент - просто рестартоните mysql когда будут снова эти проблемы - не трогая при этом asterisk

awsswa ( 2016-03-21 22:14:24 +0400 )редактировать

1 Ответ

0

к чему этот опус здесь? у вас скорее всего просто не хватает скилов на настроку базы и фаервола.

вот смотрите

asterisk -rx "sip show peers"|tail -n 1
3529 sip peers [Monitored: 320 online, 481 offline Unmonitored: 729 online, 1999 offline]

у этого клиента вообще астериск падал, они тоже грешили на "плохой астериск", оказалося они поставили две разных(и обе неправильные) spandsp библиотеки.

Говорить о какихто проблемах с sip realtime можно приблизительно с 10000 пиров, не раньше.

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

ответил 2016-03-19 04:07:55 +0400

meral Gravatar meral flag of Ukraine
21228 23 18 169
http://pro-sip.net/

обновил 2016-03-19 04:08:51 +0400

Comments

Александр, заранее простите, что описал проблему в несколько фамильярной форме. О каких скилах и к какой БД идет речь? Файервола нет. Если бы даже и был, то отказ в регистрации попадали аккаунты, вне зависимости от статуса кэширования. Логично? Насколько помню, то раньше Астер кэшированные записи складывал в БД sqlight себе "под ноги". Теперь в этой БД я вижу только те аккаунты, которые прописаны статично. И еще, просветите, как завязан spandsp к кэшированию записей sip? Еще раз уточню, при выключенном кэшировании авторизация проходит нормально, при включенном, абсолютно случайные аккаунты попадают в таблицу users и им идет отказ в регистрации.

TandemK ( 2016-03-21 10:57:42 +0400 )редактировать

проблемы глобально нет. у вас может быть локальная блокировка в базе, криво собранные библиотеки(генту же), все что угодно. spandsp как пример неверной сборки астериска. может влиять например timing_pthread(тоже видел, тоже на gentoo, тоже влияет на регистрацию, тоже лечится персбором библиотек). еще раз уточню, существуют сотни только поставленных мною систем на которых нет такой проблемы.

meral ( 2016-03-21 11:19:21 +0400 )редактировать

Ваш ответ

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-18 17:12:01 +0400

Просмотрен: 82 раз

Обновлен: Mar 19

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