Как стать автором
Поиск
Написать публикацию
Обновить

Автоматизированная проверка каналов связи

При эксплуатации большого количества каналов связи, организованных разнородными системами в том числе аналоговыми, и высокими требованиями к их готовности, проверку, а так-же документирование состояния можно возложить на Asterisk. Такая необходимость возникает, например в различных диспетчерских и ситуационных центрах. Каналов на управляемые объекты организованно много, ежедневно они не используются (ЧС не каждый день слава богу) но при необходимости любой канал должен быть в работе! Можно посадить «девушку» для ежедневного «об звона» и ей хватит рабочего дня с учетом обеда и перекуров для проверки 350 — 400 каналов. А можно решить эту задачу за пол часа.

Схема будет выглядеть так.

image

Каков алгоритм работы?

1. Первое что необходимо сделать -это определить перечень каналов которые необходимо проверять;
2. Затем необходимо создать приложение которое используя данный перечень будет производить вызовы по каналам (набирать необходимые номера);
3. Далее необходимо анализировать состояние вызова, и при ответе абонента воспроизвести ему заранее записанное сообщение (что это автоматическая проверка ...);
4. Как в случае ответа так и неудачного вызова необходимо записать «результат» для возможности дальнейшего анализа;
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.





Не тратим время и силы на мониторинг и проверку — а только на работу по восстановлению не работоспособных каналов. Как «побочный продукт» получаем статистику за:



  • месяц
  • квартал
  • год

и основания обоснованно предъявлять претензии оператору оказывающему услуги (или к себе).


Ну вот собственно и все.

Теги:
Хабы:
Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.