При эксплуатации большого количества каналов связи, организованных разнородными системами в том числе аналоговыми, и высокими требованиями к их готовности, проверку, а так-же документирование состояния с фиксацией в базе данных, можно возложить на Asterisk.
Структурная схема комплекса
Прежде чем приступить к реализации, необходимо определить цели и задачи, которые мы ставим перед комплексом и как он собственно будет работать?
- Первое что необходимо сделать -это определить перечень каналов которые необходимо проверять;
- Затем необходимо создать приложение которое используя данный перечень будет производить вызовы по каналам (набирать необходимые номера);
- Далее необходимо анализировать состояние вызова, и при ответе абонента воспроизвести ему заранее записанное сообщение (что это автоматическая проверка …);
- Как в случае ответа так и неудачного вызова необходимо записать «результат» для возможности дальнейшего анализа;
- И в заключении необходимо приложение предоставляющее удобный интерфейс для просмотра, анализа и при необходимости редактирования результатов проверки ( для корректного в дальнейшем расчета коэффициента готовности и т.д.);
В целом поставленная задача, я полагаю, понятна.
Выбираем «движок» для комплекса
И так теперь после подготовительных (проектных :)…) работ, можно приступать к реализации. Вероятно существует большое количество таких решений на базе предположим siemens или avaya… ,но приобретение дорогостоящих платных решений( или просто платных), как вы поняли не входит в наши планы и не рассматривается.Работаем с Asterisk. Что нам потребуется?
- Установленный и настроенный asterisk с выходом на сеть связи;
- Для хранения перечня каналов можно использовать как средства asterisk так и файловые, мы используем — СУБД — MYSQL.
- Для создания приложения реализующего логику работы будем использовать доступный для любого администратора /bin/sh;
- Большинство пользователей используют ОС -Windows (надо же!) поэтому приложение для анализа результатов разрабатываем для Win32;
- По той же причине (хотя не обязательно) настраиваем систему тарификации CDR (Call Detail Records) — на базу MSSQL;
Установка Asterisk и необходимых компонентов
С чего начать? Скачать и установить asterisk из пакетов, исходного кода, готовый дистрибутив или выбрать и купить готовую предустановленную станцию. Читаем подробный материал «Установка» на asterisk.ru. «Полное собрание сочинений» — Документация. Выбор за Вами. Остановлюсь только на «отклонениях от стандарта». Прочитаем «Asterisk Reference Information Version 1.6.1.5» и для обеспечения выгрузки информации о звонках в базу MSSQL — компилируем и устанавливаем последний(на момент описания) пакет FreeTDS:
- tar -zxvf freetds-0.62.4.tar.gz &&
- cd freetds-0.62.4 &&
- ./configure —prefix=/usr —with-tdsver=7.0
- make &&
- make install
Устанавливаем asterisk (или собираем вновь если он был установлен ранее) с поддержкой cdr tds.
- make clean && ./configure —with-tds &&
- make update &&
- make &&
- make install
Редактируем файл /etc/asterisk/cdr_tds.conf — пароль, имя пользователя и базы ( на MSSQL).
- [global]
- hostname=192.168.1.25
- port=1433
- dbname=voipdb
- user=voipdbuser
- password=voipdpass
- charset=BIG5
И наконец создаем таблицу ‘cdr’в базе данных MSSQL.
- CREATE TABLE cdr (
- [accountcode] [varchar] (20) NULL ,
- [src] [varchar] (80) NULL ,
- [dst] [varchar] (80) NULL ,
- [dcontext] [varchar] (80) NULL ,
- [clid] [varchar] (80) NULL ,
- [channel] [varchar] (80) NULL ,
- [dstchannel] [varchar] (80) NULL ,
- [lastapp] [varchar] (80) NULL ,
- [lastdata] [varchar] (80) NULL ,
- [start] [datetime] NULL ,
- [answer] [datetime] NULL ,
- [end] [datetime] NULL ,
- [duration] [int] NULL ,
- [billsec] [int] NULL ,
- [disposition] [varchar] (20) NULL ,
- [amaflags] [varchar] (16) NULL ,
- [uniqueid] [varchar] (150) NULL ,
- [userfield] [varchar] (256) NULL
- )
Контролируем что все работает нормально.
С этого момента, все необходимые для нашей работы сведения о производимых вызовах, фиксируются в базе данных MSSQL в табличке CDR. Особый интерес представляет поле -«disposition» принимающее значения — «ANSWERED» и «NO ANSWER».
К этому полю мы еще вернемся когда будем рассматривать клиентское приложение, а сейчас перейдем к перечню каналов. Разместим его в таблице в базе данных MYSQL, где основными параметрами являются «номер» абонента и его «имя». Используем пакетный режим работы MYSQL для получения необходимых данных:
/usr/bin/mysql -h host -D base -u user —password=password < /etc/asterisk/sql_table
Где файл /etc/asterisk/sql_table предварительно формируется в зависимости от необходимых нам данных примерно так:
/bin/echo «SELECT * FROM table ORDER BY id» > /etc/asterisk/sql_table
Полученный номер абонента используется для формирования файла в директории /var/spool/asterisk/outgoing. Asterisk отслеживает папку outgoing на наличие текстовых файлов,содержащих информацию запросов вызовов. Эти файлы позволяют производить вызов, просто перемещая правильно структурированный файл в папку outgoing/.Файлы вызовов, помещенные в папку outgoing/, могут содержать полезную информацию, такую как Context (Контекст), Extension (Расширение) и Priority (Приоритетность), соответственно которой должен начинаться ответ на вызов, или просто приложение и его аргументы. Так-же в них можно задать переменные и определить код учетной записи для Call Detail Records (Записи параметров вызовов).
Файлы вызовов записываются в следующем формате. Сначала определяем, куда будем звонить:
- Channel: канал
Можно задать время ожидания ответа на звонок (по умолчанию 45 с),время между повторными попытками дозвониться и максимальное число попыток. Если параметр MaxRetries (максимальное число попыток) опущен, выполняется только одна попытка вызова:
- WaitTime: число
- RetryTime: число
- MaxRetries: число
Если ответ на звонок получен, здесь мы определяем, где он должен обрабатываться:
- Context: имя-контекста
- Extension: добавочный номер
- Priority: приоритет
Таким образом запрос номера из базы данных MYSQL и формирование необходимого файла в директории outgoing/ для совершения вызова Asterisk легко реализуется без использования каких либо языков программирования, при помощи shell с организацией цикла по всем записям таблицы.
Чуть не забыл! При ответе абонента на вызов в трубке будет «глухая тишина», кто то должен объяснить что это автоматическая проверка. Для этого необходимо сделать предварительную запись сообщения, «проигрываемую» при ответе. Без «излишеств» это выглядит так:
- [msg]
- exten => 5555,1,Wait(2)
- exten => 5555,2,Record(ru/vm-msg:gsm)
- exten => 5555,3,Wait(2)
- exten => 5555,4,Playback(vm-msg)
- exten => 5555,5,Wait(2)
- exten => 5555,6,HangUp()
После сигнала Вам представляется возможность записать сообщение, а затем прослушать что получилось. Добавляем необходимые строки в конфигурационный файл и данное сообщение слушает ответивший абонент.
- [out]
- exten => s,1,Wait(1)
- exten => s,2,Answer()
- exten => s,3,BackGround(ru/vm-msg)
- exten => s,4,HangUp()
Ну и наконец результат поле -«disposition» принимающее значения — «ANSWERED» и «NO ANSWER».Именно анализируя состояние этого поля мы делаем вывод о том , был ли ответ абонента и соответственно о работоспособности канала. Для удобства анализа применим простое приложение Win32.
Не тратим время и силы на мониторинг и проверку — а только на работу по восстановлению не работоспособных каналов. Как «побочный продукт» получаем статистику за:
- месяц
- квартал
- год
и основания обоснованно предъявлять претензии оператору оказывающему услуги (или к себе).
Ну вот собственно и все.