борьба с PJSIP

[Rom1kz]

Друзья, прошу не бить меня сразу и больно, вопрос может не содержать достаточного объема конкретики, однако я уперся в проблему и потерял пути решения

более 10 лет благополучно сидел на chan_sip и, можно сказать, бед не знал, но случился pjsip и объявление chan_sip как deprecated
попытки перейти на новый стек я предпринимал раньше, еще с версии 13, но в те времена это выглядело достаточно сыро, например я не редко получал блокировку канала с потреблением 100% процессора.. но истема продолжала работать, отваливался один оператор, он не мог принимать звонки из очереди, так как находился в системе в состоянии In Use, ручное прерывание подвисшего канала никак не влияло на ситуацию - канал продолжал висеть, решалась проблема полным ребутом.

спустя время я начала повторный попытки перехода на pjsip уже на версии 16, надеясь что все критические проблемы уже давно решены.
первая попытка вывести pjsip в прод была совершена в конце 2019 года и она оказалась крайне неудачной - работоспособность блокировалась полностью в какой-то рандомный момент, без криков в логи
при этом проблема не отличалась частотой повторения - раз в неделю-две, как при пиковых нагрузках, так и при штатных (в сутки проходило всего 2000 звонков)
cli оставалось доступной, я мог выполнить core show channels и прочие запросы, но verbose вывода со стороны системы в консоль не было абсолютно никакого - то есть при входящем звонке абонент слышал тишину, а в консоли астера было пусто, будто сип стек находится в какой-то глобальной блокировке и не обрабатывает пакеты сигнализации.
при этом ни один из активных каналов невозможно завершить принудительно через channel request hangup
потребление процессора было штатное, без пиков, в общем с виду астериск был в порядке, но сип стек переставал работать.
из каких-то особенностей - все звонки обрабатываются системой роутинга по fastagi. перезагрузка системы роутинга не имеет никакого влияния на ситуацию.

последняя моя попытка снова перейти на pjsip состоялась на версии 16.21.1, проблема повторилась через несколько дней после вывода системы в прод

астериск собирается из исходников с --with-pjproject-bundled

да, пытался анализировать бэкстеки потоков зависшего астериска через gdb, но каких-то явных зацепок не увидел
что можно в этом случае посмотреть и куда покопать ?

[sasa]

Варианты
1 Открываете баг репорты на оффициальном сайте астериска, пусть там разбираются.
2 Открывате hh ru и ищете специалиста который будет заниматься или публикуете вакансию и рассматриваете предложение.
3 Продолжаете ехать дальше на chan_sip и периодически тестируете pjsip пока он вас не насчет устраивать.

Имея непродолжительный опыт с одной обзванивающей компанией из сша
где астериск основной инструмент
а chan_sip и модуль очередей основной функционал

То они нанимали разработчиков которые им фиксили все мютекс блокировки для того что бы поднять кол пер секонд и добиться при этом всего лишь 20-35% загрузки cpu при обзвонах, но это было для 1.6 астериска.

Теперь когда они захотели перепрыгнуть на новый астериск и новый pjsip, с новым функционалом очередей который и новыми плюшками которые им нужны.
То сильно обламались, кол персеконд очень не большой
а загрузка cpu 40-60%
и нет на рынке специалистов способных разобраться в проблеме "пропатчить кде под фрибсд"

[ded]

1. +
2. + +
3. + + + ! (Сами так едем много лет).
Пугают народ chan_sip deprecated, как будто его завтра вообще аннулируют и аннигилируют.

[sasa]

Все депрекейтед модули удалят из основного состава астериска, вроде уже помечают и создают какие то заметки в сорурс трии.
Всякие мордочки для управления и готовые дистрибутивы более менее привязываются к версии астериска.
Плюс иногда может быть нужда в каком то новом фунционале нового астериска.

А так в целом да, если функционал устраивает там где он уже много лет крутиться, обновлять почти нет смысла

[amateur]

да, пытался анализировать бэкстеки потоков зависшего астериска через gdb, но каких-то явных зацепок не увидел
что можно в этом случае посмотреть и куда покопать ?

Это сильно зависит от того, что конкретно удалось увидеть.
Боюсь, что тут нельзя дать совета в духе "возьми ключ на 13 и прикрути ту гайку".

Надо во-первых, иметь достаточно отладочной информации - скомпилировать Asterisk с включением debug symbols и отключением оптимизации компилятора.
Во-вторых, найти объект, который подвергся мертвой блокировке (deadlock) и попытаться найти фрагмент кода, который это спровоцировал. Это очень творческий процесс, для успешности которого надо хорошо понимать "как всё работает". Но может не "всё", но все-равно "многое"

Попробуйте. Бывало, что именно таким образом рождались весьма полезные для общества программные продукты. К тому же, в мире opensource нельзя только брать. Надо что-то и давать...

[Rom1kz]

Попробуйте. Бывало, что именно таким образом рождались весьма полезные для общества программные продукты. К тому же, в мире opensource нельзя только брать. Надо что-то и давать...

да, желание есть, и есть возможность неспешно пытаться в этом разобраться, вывел одну из машин кластера и оставил её на PJSIP, будет зависать - буду изучать, может быть появятся какие-то зацепки

я писал вопрос, возможно, даже не с надеждой получить волшебную пилюлю, а с целью понять использует ли кто pjsip под нагрузкой, так как в интернете (и на хабре) то и дело рассказывают как перейти с chan_sip на pjsip и как всё замечательно после этого работает.
а я что ни попытка, то провал )) поэтому стал задаваться вопросом "что я делаю не так?"
да, я уже однажды писал о дедлоках в жиру по поводу модуля realtime, но там история была более понятна изначально и проблему в исходниках найти не составило труда (правда мой патч отклонили, кто-то другой потом выложил свой)
https://issues.asterisk.org/jira/browse/ASTERISK-25218.