Хорошо выспался, настроение приподнятое. Решил проверить сервера, а заодно еще и у приятеля.
У него uptime показал 86 дней — прекрасно, а вот Asterisk… ВСЕГО 3 дня и 20 часов!!!
— Так, что у вас случилось? Почему Asterisk перезапускался?
— Просто у нас совещание было. Вот я его и вырубил, чтобы звонки не шли!!!
Вот это ДА! Т.е. когда у них началось «совещание» — просто УБИЛИ всю телефонию!
Ну звери, честное слово! :)
Надо сделать нормальное решение.
Предсказать ТОЧНО когда состоится очередной корпоратив или же настоящее совещание просто невозможно. Что ж, будем делать нормальное решение — пусть на такой период все звонки приходят, но не на офисные телефоны, а на ту же голосовую почту.
Для этого написал резервный extensions.conf в котором указал маршруты входящих на VoiceMail и не забыл вставить кусок для разблокировки. Назвал его extensions.conf.mute.
Далее в оригинальном диалплане сделал следующее:
exten => 666,1,Answer
exten => 666,n,System(cp /etc/asterisk/extensions.conf /etc/asterisk/extensions.conf.back)
exten => 666,n,System(cp /etc/asterisk/extensions.conf.mute /etc/asterisk/extensions.conf)
exten => 666,n,System(asterisk -rx 'dialplan reload')
exten => 666,n,Hangup
Т.е. по набору 666 происходит резервирование текущего диалплана, далее его подмена «праздничным» и перечитывание состояния. Аналогичный кусок для разблокировки в файле extensions.conf.mute только наоборот :)
Вот вроде бы и все. Правда потом еще попросили сделать голосовое уведомление в каком же режиме работает станция, а потом еще и меню выбора режимов и т.д. и т.п. А я-то думал что легко отделался :)
Корпоратив — святое дело…
Еще из опыта.
Пару лет назад такая же аналогичная задача стояла для операторского зала. Дело в том, что смена операторов менялась в 10 утра и 18 часов. Для каждой смены операторов необходимо было вести статистику их работы — сколько за смену принято или пропущено звонков, уровень обслуживания и т.д.
Этот показатель есть в статистике очереди, но он НАКОПИТЕЛЬНЫЙ, а необходимо было его сбрасывать в 0 перед началом новой смены. При этом отработавшая смена должна сначала записать свои показатели.
По идее — просто. Однако простой queue reload all не дает сброса, если не увидел изменений параметров в файле queue.conf.
Поступили тогда простым методом: был написан скрипт на perl, который парсил queue.conf и создавал «двойника». Если обнаруживал «хитрую» строку-флаг — отбрасывал ее, если нет — добавлял. Т.е. получали на выходе постоянно изменяемый новый файл конфигурации очередей, что приводило к сбросу статистики.
Правда обнаружили небольшую странность: у нас в agents.conf установлен парамтер acceptdtmf=#
который позволяет отвечать на вызов нажатием клавиши на телефоне, а не автоматически. Так вот. После таких перезагрузок получалась ситуация с точность наоборот — будто срабатывал ТРИГГЕР — то отвечать по клавише, то автоматически. Решили это просто — не один раз давали queue reload all, а сразу два.
Ну вот собственно и все.
Автор: , Блог компании MyAsterisk / Записки Астерискера. Корпоратив — святое дело…
