ast_sockaddr_copy (res < 0)

[donat]

Привет всем. Перевёл сервер с железа на контейнеризацю (гипервизор - 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 страниц вперёд, дал много полезной информации, но решить всё же проблему не получилось;

[Vlad1983]

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

[donat]

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

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

[Vlad1983]

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

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

[ded]

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

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

[donat]

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

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

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

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

[donat]

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

[Vlad1983]

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

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

[donat]

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

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