Попробуйте подключиться микросипом, если паузы не будет, то пинайте разрабов софтфона, пусть подключают ice tricks

щас попробуем спасибо за совет

когда говорят по 5 сек. то наверняка avaya и знаю что делать надо, а тут "акела промахнулся" с доводом :)))

Расскажи пожалуйста? У нас такого не было, но вдруг

avaya session manager надо перезагружать, такое встречается 1-2 раза в год

если не экстремальные условия работы avaya то вам это не светит увидеть в живую

У нас сейчас с ним другая проблема: ни с того ни с сего начинает бомбить ренвайтами через полсекунды-секунду, хотя получил уже 100 trying. Переходит на второй выбор, потом передаёт на второй sm и в результате валится с 504

И, как ни странно, с 1.6.20 это почему-то гораздо реже

это нормально :)))

fs тормозит с доступом в бд чтобы чиркануть туда что-то

Не, он отвечает через несколько миллисекунд.

Как бы это отрегулировать отдебажить? :) ну ппц же

Я бы понял действительно медленный ответ, а так то что.. И почему на старой версии фс это реже

я столкнулся с такой задержкой в начале передачи звука.
у меня задержки доходили до 45 секунд,
и раскопал следующее:
1. Проблема только у браузерных клиентов
2. одинаково и у JSSIP и у VERTO
3. происходит из за странного алгоритма согласования ICE между fs и клиентом. В fs алгоритм примерно такой - -копить ошибки согласования до 10 раз, с паузами между ними в секунды.
4. Как я понял - это из за конфигурации сети клиента и fs в конкретном случае.
5. Для решения - пришлось отказаться от fs из репов, качать исходники и патчить switch_rtp.c.
Патч в какойто мере костыль, т.к. ломает заложенный алгоритм, но в 99.9% случаев помогает

Можно по подробнее
Кто кого бамбит sm -> fs или fs -> sm

Первое - SM бомбит FS

Ясно, переходи на tcp

мм-м.. а зачем?! Неужели это лекарство?

оно же медленее

Сними траффик на fs, удивишся что от sm бывают пакеты udp которые превышают mtu и без фрагментации