быстрое “выключение” Asterisk

Утро 3 января. Хорошо выспался, настроение приподнятое. Решил проверить сервера, а заодно еще у приятеля.
У него 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, а сразу два.

Ну вот собственно и все.
Всех с наступившим Новым Годом. Удачи всем и хорошего настроения.

оригинал 

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *