asterisk.ru

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

ноги растут из системного вызова, который резолвит адреса. Он синхронный. chan_sip, использует его (этот вызов) в основном потоке, поэтому если резолв будет медленным, встает весь стек. В pjsip этот вызов выведен в отдельный поток, поэтому он менее подвержен задержкам в ДНС

примерно это и происходило. Подключено около сотни sip транков для ВАТС. Спустя минуту после перезагрузки хоста очень сильно начинала падать производительность

примерно это и происходило. Подключено около сотни sip транков для ВАТС. Спустя минуту после перезагрузки хоста очень сильно начинала падать производительность

там она не падает, она сдохнет, если днс будет не в порядке

ну были избыточные ресурсы на виртуалке, просто замечена было очень медленная отзывчивость. Даже банальное подключение через putty отвечало на запрос пароля около 20 секунд ?, при загрузке процессора около пары процентов

Коллеги, а почему в FreePBX может не срабатывать переадресация (установленная звонком *72) если звонок на внутренний номер идёт из очереди?
Установлена опция Call is Dialed, которая вроде должна способствовать такому поведению

а в логе почему *73@from-internal ?

а в логе почему *73@from-internal ?

?‍♂️ тоже обратил на это внимание

Сам я не набирал)

Вот сам не понимаю. У нас недавно случилась ситуация:
Набор абонента, около 10-15 сек ожидание
Через этот промежуток вижу что цифры набранные зарезолвились в имя, опять 10-15 сек ожидание
Тишина в трубке, начался гудок, опять 10-15 сек ожидание
Только после этого пошел вызов набираемому

У нас так было когда nat криво настроили

не, исключено. Изменений не было никаких

ну были избыточные ресурсы на виртуалке, просто замечена было очень медленная отзывчивость. Даже банальное подключение через putty отвечало на запрос пароля около 20 секунд ?, при загрузке процессора около пары процентов

это специально так делается
чтобы подбиральщики паролей не могли это быстро делать