asterisk.ru

Привет всем. Перевёл сервер с железа на контейнеризацю (гипервизор - proxomox, контейнер соотвественно - OpenVz).
Сервер магистральный и достаточно нагруженный SIP-сессиями, до 150 диалогов в секунду.
Изначально планировал переводить по нормальному на KVM, но решил всё же попробовать контейнер (учитывая его особенности, suspend dump, миграция по lvm разделам и т.д.).

В общем нагрузка контейнера ~20% процессорного времени (работает всего 2 ядра по 3GHz), и до 1,5Гб оперативки (всего имеется 4Гб).
С ядром гипервизора проблемы не фиксирую, работает еще несколько контейнеров (все конечно же linux-based), все дебианы от 6 до 8 версии.

В целом сервер (контейнер) ведёт себя адкеватно, в syslog ничего плохого не выбрасывает, та же ситуация с логами гипервизора.

Но на длинные дистанции стали появлятся потери RTP трафика, а именно, в от UAC не передаётся RTP трафик.
Зафиксирована данная проблема далеко не с одиним UAC, разные схемы включения (SIP - DSS1 gw / SIP to SIP / SIP to analog via ATA) и один и тот же симптом.
Хотя другие сервера работающие через тот же longdistnace аплинк ведут себя нормально, так же вёл себя и сервер на железке, до переезда в контейнер.

Конфиг перенесён идентично, единственное пугал скачек в ревизии астериска - с 1.8 до 12.5. Но проблем с загрузкой жизненоважных модулей не обнаружено, сервер стартует без проблем и ошибок.


Ближе к делу. Имеется вот эта строка:
"RTCP SR transmission error to XXX.XXX.XXX.XXX:port, rtcp halted Operation not permitted"
Где: XXX.XXX.XXX.XXX - Ip адрес софтсвитч-сервера, куда поднят транк от проблемного сервера (софтсвитч нужен чтобы разруливать аплинки).
port - RTP порт по которому передаётся голосовой трафик.

Судя по логам проблемных звонков и появляения этого сообщения, выбрасывается ошибка во время проблемного звонка.

Вот собственно исходный код астера, который отвечает за условие появления данной ошибки:

ast_sockaddr_copy(&remote_address, &rtp->rtcp->them);
res = rtcp_sendto(instance, (unsigned int *)rtcpheader, len, 0, &remote_address, &ice);
if (res < 0) {
ast_log(LOG_ERROR, "RTCP %s transmission error to %s, rtcp halted %s\n",
sr ? "SR" : "RR",
ast_sockaddr_stringify(&rtp->rtcp->them),
strerror(errno));
return 0;
}


Несколько ремарок:
-ulimit'ы пока что не повышены от стандартных, что будет опробовано сегодня ночью;
-Хардварный фаервол за которым всё это дело живёт, пропускает нужные порты и айпишники, проверено дебагом;
-Iptables на проблемном сервере не имеет правил и форвардит по INPUT/OUTPUT цепочкам всё, что приходит и уходит;
-Selinux не включен ни на гипервизоре, ни на контейнере.
-Рейндж портов разрешенных на сервере 10к-20к, собственно этого достаточно для того, чтобы протолкнуться множеству RTP/RTCP сессий;
-Сервер принудительно слушает сигнализацию на определённую айпишку и порт.
-Важно: Гугл прочёсан на +5 страниц вперёд, дал много полезной информации, но решить всё же проблему не получилось;

попробовать сдампить трафик
искать есть ли попытки отправки на XXX.XXX.XXX.XXX:port из лога вообще
или просто прилетает icmp от туда что что что-то не так

Есть такая задача - одна из первостепенных.
Но тяжело осуществима, так как дамп нужно произвести первого и второго плеча от проблемного сервера, что является сложной задачей на продакшн сервере (с нагрузкой выше 100 SIP-сессий в секунду).

Согласен, нужно постараться повторить проблему.
Но буду очень благодарен, если кто-то будет делиться информацией (имею ввиду тех людей, которые сталкивались с подобного рода проблемами).

можно попытаться воспроизвести без дампа

делаете вызов на любой подопечный астериск под линём
в 200 Ok смотрите порт RTP
соответствующий ему порт RTCP забиваете в iptables REJECT с различными вариантами опций
смотрите что в логах

donat писал(а):Конфиг перенесён идентично, единственное пугал скачек в ревизии астериска - с 1.8 до 12.5.

Исходя из чего выбрали 12.5 ?
Есть некоторая условность в нумерации последних версий (после 1.Х): начиная с последующих после 1.8 - первую цифру отбросили, и стали придерживаться нечётные версии - стабильные, чётные - девелоперские. То есть ваша 12.5 - не та, чтобы в продакшн вот так сразу. Лучше бы взяли 11-ю.

Vlad1983 писал(а):можно попытаться воспроизвести без дампа

делаете вызов на любой подопечный астериск под линём
в 200 Ok смотрите порт RTP
соответствующий ему порт RTCP забиваете в iptables REJECT с различными вариантами опций
смотрите что в логах

Вы предполагаете, что всё же проблема в iptables ?
На самом деле данный тепмлит openvz (debian 8), предоставлен без как такового iptables, имею ввиду демона нет.

Но это тоже хорошая идея, думаю что нужно попробовать, но на тестовом стенде.

Версию астера выбирал исходя из проведённых ранее препродакшн тестирований.
На стенде показал себя адекватно + запускал несколько кастомеров на данной версии, критических ошибок/багов замечено не было (но тут стоит сказать, что колл центры организованные на данной версии, не имели такой порядок нагрузки, как имеет в данный момент проблемный сервер).

donat писал(а):Вы предполагаете, что всё же проблема в iptables ?

никакой проблемы с iptables нет
iptables просто как инструмент для попытки воспроизведения, т.к. снять дамп трафика проблема

Ребята всем спасибо за помощь.

Перенёс сервер на KVM, поднял на 11ой LTS. Теперь всё норм - ошибки больше нет.
Тему закрываю, но с контейнером еще думаю разбираться, интересно в чём все-таки проблема.