asterisk.ru

Всех приветствую.
Прикольный параметр, позволяет увеличить время ожидания возврата к аттенданту при переводе с уведомлением.
По-умолчанию равен 15 секундам. При вводе строки вида atxfernoanswertimeout = 60 в features.conf таймаут действительно увеличивается, но образуется глюк. Итак, немного уточню схему. Екстеншн А звонит экстеншну B, тот его переключает на C. Затем через пару секунд экстеншену B надоедает ждать пока ответит C, тот кладет трубу, А остается ждать С один. потом и ему надоедает, и А бросает трубу. Но Астериск не хочет в это верить и все равно трезвонит С. Это хорошо видно на панели BLF. Как будто А и С заняты (красненькие), хотя А давно "положил трубу". Длится это безобразие как раз то время, которое задано параметром atxfernoanswertimeout. Потом все приходит в норму и даже на blf панели оба экстеншна одновременно зеленеют.
Обновление астериска с 1.6.2.7 на 1.6.2.13 не решило проблему, в связи с чем вопрос: может надо еще какой параметр указать?

Поболтать, похоже, некогда. Кому не лень попробуйте на 1.8, глюк присутствует?

У меня тут другая история.. Не менее веселая, и тоже с трансфером. В feauters.conf есть параметр transferdigittimeout. Его значение по умолчанию - 3 секунды. Чего маловато... пользователи поискать номера.. установка переменной в значение 60 секунд (но у меня нет стопроцентной уверенности, что только это) вызывает сбой ядра системы под нагрузкой в 50-70 каналов. Причем сбой крайне интересный - текущие каналы остаются соединенными, новые не создаются, диалплан не отрабатывает, CLI ничего не выдает, в full лог, который запущен на максимум, по десятку метров в сутки пишет, ни полбуквы, что астер повис. Узнаю только от пользователей, что им не набрать номер. Под нагрузкой в два-десять каналов все работало как часики. Таки такой тут вопрос - слышал ли уважаемые гуру что-нибудь про глюк подобный? Да, до того, как я полез в фичеконф - аптайм составлял 41 день, средняя нагрузка в рабочее время около 50 каналов одновременно, с записью и микшированием в ogg/vorbis