отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Мониторинг голосовых транков на базе CUBE и CUCME в сети Enterprise.

New Member

1. Введение.

Когда я пришел в мир  голосовых технологий, то почти сразу столкнулся с такой проблемой как мониторинг голосовых транков. В СПД там все боле-менее  ясно и предсказуемо эхо– ответ (ping)  проходит, Telnet на порт  есть (устанавливается), значит с большой долей вероятности можно сказать, что и остальной трафик пройдет. А с голосом не все так просто. То что, сейчас звонок прошел на сотовый  еще не значит, что следующий пройдет успешно. Кроме того голосовые транки  еще и разные по технологии бывают и, соответственно – разные методы для их мониторинга нужны. Иногда мне вообще казалось, что голосовые транки живут своей жизнью и вот я мало-по-малу исследовал этот вопрос. Этим и хотел поделиться, может быть кому-то будет полезно, а может кто-то добавит, что-то из своего опыта.

1.1 Область применения:

Сразу скажу, что эта статья ориентирована на  сети - Enterprise. Рассматриваются следующие типы голосовых подключений к провайдерам по телефонии: E1, SIP и отчасти  FXO.  Оборудование  для построения  транков – это Cisco Routers, работающие в качестве голосовых шлюзов (CUBE) или  CUCME. Написал, про то, с  чем имел  опыт. Т.е. все, что описано, проверено на практике. Поэтому про другие протоколы и типы подключений не пишу.

1.2 Цель внедрения или бизнес-выгода:

Главная задача, которая здесь рассматривается – это успешное прохождение звонков и оптимизация расходов  на телефонию при использовании голосовых транков сервис-провайдеров.

1.3 Документация: Как всегда здесь не так много документов, которые описывают не отдельные features, или что-то в общих фразах, а концепции внедрения  «От задачи и от проблемы», но они все же есть.  К примеру, и этот документ был в основе моих исследований – это “Cisco Unified Border Element (CUBE) Management and Manageability Specification”. Кое – что еще собиралось с разных сайтов инета.

 1.4 Системы мониторинга: В данной статье рассматривается возможность обеспечения мониторинга голосовых транков при наличии SNMP-server, syslog-server, mail-server, Cisco IOS и ответственного сетевого инженераХотя, возможно, имеются специальные системы мониторинга  для голоса, которые обладают еще каким-то могучим функционалом и аналитикой, но в моем распоряжении на предприятии были только MS SCOM (SNMP-server), PRTG monitor (SNMP-server), Kiwi syslog  server от Solar Winds (syslog-server).

1.5 Схема реализации будет выглядеть примерно так: 

 

2. Методология мониторинга или от задачи к реализации.

2.1 Превентивный мониторинг.

Не знаю, кто как, а я как сетевой инженер очень не  приятно себя чувствую, когда кто-то вдруг неожиданно звонит мне и говорит- «у нас никто в офисе не может наружу дозвониться». Для меня это звучит так примерно: «У Вас тут ничего не работает, а Вы сидите и ничего не знаете». Такой путь обнаружения проблемы  тоже есть, конечно, дождаться, когда тебе все выскажут и тогда начать решать проблему. Но наш подход в статье, все же попытаться предотвратить не успешные звонки для пользователей, успеть решить проблему, прежде чем они ее обнаружат или уж как минимум, быть в курсе проблемы, когда пользователи позвонят и попытаются что-то сказать тебе. А ты им в ответ: «Да, мы в курсе.  Провайдер уже решает проблему. Временно Вы  поработаете через другой транк». И бизнес доволен (не теряет время и клиентов на безуспешных звонках) и технарь доволен – «у меня все под контролем».

Собственно, все результаты сведены в 2 таблицы* для краткости и удобства:

*таблицы в формате Excel продублированы в прикрепленных файлах и доступны по гипперссылке, в наименованиях таблиц.

Таблица1. Мониторинг состояния и утилизации транков.

 
SNMP monitoring system* (MS SCOM, PRTG monitor, etc.)
** - it depends on the Monitoring system

 

2.1.1 Мониторинг  состояния транка E1

Что здесь нужно пояснить:

В первой части таблицы – проверяем (щупаем) жив ли транк?

Для E1 у Cisco IOS есть команда show isdn status – вывод ее ниже – у L2 State должно быть MULTIPLE_FRAME_ESTABLISHED, что соответствует «3» при  SNMP запросе OID .1.3.6.1.2.1.10.20.1.3.4.1.2.

Нюансы:

- т.к. транков, модулей на платформе м.б. несколько, на конце OID – добавится цифра соответствующая номеру ISDN интерфейса. Номер надо выяснить опытным путем с помощью, например, SNMP walk и т.д.

- для некоторых SNMP – мониторинговых систем (PRTG -monitor) нужно загрузить соответствующие MIB с сайта Cisco.com.

 

RTR03#sh isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)

 

2.1.2 Мониторинг  состояния SIP -транка

По поводу мониторинга SIP транка – прописываем  на исходящем dial-peer команду:

dial-peer voice 33 voip
 destination-pattern 08..........
  session protocol sipv2
 session target sip-server
 voice-class sip options-keepalive

И наблюдаем  вывод командой: sh dial-peer voi sum

             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE
33         voip  up   up                             08..........       1    syst          dns:SIP-server                               active  

 

Состояние должно быть – active, а если busyout, то значит не получаем мы 200 Ok от провайдера.

Вот именно это и наблюдает script описанный в документе - Cisco Unified Border Element (CUBE) Management and Manageability Specification  п.2.7.1 стр. 25.

Нюанс: к описанию applet для event manager нужно добавить еще строку если у Вас настроена AAA  authorization должным образом – иначе скрипт не отрабатывает. Выглядит это так:

event manager environment dial_peer_number 3
event manager environment check_interval 60
event manager directory user policy "flash:/"
event manager session cli username "user_admin"

…. остальная чать конфига опущена

Здесь - user_adm – username от имени, которого будет запускаться скрипт

2.1.3 Проблемы превентивного мониторинга транков (Caveats&Limitations):

Проблема состоит в том, что это очень ограниченная технология мониторинга. Таблица их состояний с точки зрения гарантированности будущего звонка будет выглядеть так:

Технология
Status
is it ensure future call-?
ISDN
ОК (3)
may be
ISDN
bad (1-2)
NO
SIP keepalive
OK
may be
SIP keepalive
bad
may be

 

Т.О. У E1 (ISDN )  это гарантированно работает, только в одну сторону, что если ISDN state не MULTIPLE_FRAME_ESTABLISHED – то звонок точно не пройдет, а вот если Ок, то только возможно, что пройдет, т.к. на практике, бывает что и не проходит. Видимо из-за других проблем у провайдера предоставляющего сервис.

C SIP – дело еще хуже, т.к. не всегда (замечено на практике, что в 15-20%), даже если провайдер не присылает 200 Ok, звонок может пройти, все равно. Видимо, это связано с тем, что работа с данными пакетами keepalive не настроена корректно у провайдера. Это стоит сразу проверить при настройке мониторинга.

Полезное применение: E1- стоит наблюдать этим методом, ради только того, чтобы заметить падение транка, а «дерганье»- Down-Up  или просто падение в Down – будет подсказывать о плохом состоянии SIP транка процентах в 75%. Так что стоит этот транк проверить  исходящим звонком, чтобы точно понять его состояние. Это не однократно помогало мне обнаружить проблемы с транками – до появления жалоб  от пользователей.

 

По поводу FXO – превентивных средств для мониторинга состояния –  ничего простого и удобного – не нашел. Так что о состоянии подключения можно делать выводы только после выполнения звонка.

 

2.2 Мониторинг утилизации транков.

2.2.1 Полезность. Следующий раздел мониторинга – количество одновременных звонков на транке – очень полезная опция, на мой взгляд. Потому что позволяет ИТ-отделу оптимизировать расходы на услуги связи. Например, подключается в каком-то новом офисе голосовой транк. Сколько брать timeslots? Предполагают, количество линий с запасом обычно. И.. так взяли — половину E1- 15ts. А далее — сколько из них линий максимально одновременно  по факту использует подразделение-? Из опыта — я обнаруживал, что иногда из 15 ts — занимаются одновременно только 3 максимум- т.е. за 12 компания платит — бессмысленно. По опыту скажу, что урезали почти везде более чем наполовину количество линий в транке, когда ввели данный мониторинг- вот тебе и экономия. Бизнес доволен.

2.2.2 Как работает мониторинг этого? Каждые  30-60 сек. (это как ваша система мониторинга позволяет) происходит SNMP опрос по указанным в таблице OID. Конечно, это не 100% точность, но если поразмыслить насколько реально деловые разговоры могут быть менее 30 сек. За 15-20 сек только — люди только успевают идентифицировать друг друга и обменяться приветствием, остается 10-15 сек на деловой разговор. Так обычно не бывает, тем более с учетом того, что это все off-net звонки. А спустя 30 сек (в худшем случае) занятость ts уже будет зафиксирована нашей системой мониторинга. В общем я полагаю, что это достаточная точность. Практически, тоже проблем с этим пока так же не возникало.

  1. Нюансы:

- не забываем, про подбор последней цифры в OID, соответствующей номеру вашего голосового порта, модуля. Подбираем его практически с помощью SNMP walk и запускаем опрос в работу.

- С SIP-транком все несколько сложнее, так как у него нет такого как у E1- MIB четко определяющего число занятых (наружу) линий в силу его архитектуры. У него и наружу и внутрь смотрят call-legs одинакового типа -VoIP. Поэтому можно проводить мониторинг либо по конкретному dial-peer (но у нас их наружу смотрят -три), либо наблюдать общее число call-legs, а потом делить на 2. Второй вариант, вполне нормально работает для нормально настроенного CUBE, на котором нет всяких каких-то дополнительных переходов внутри коробки, создающих на один звонок дополнительные call-legs. Дополнительный бонус — увидите, нет ли у Вас лишних переходов на CUBE- оптимально, ли настроены dial-peerы.

- Для CUCME c SIP подключением наружу такой мониторинг — будет не совсем честный, ввиду того, что, на нем все звонки даже внутри локации, будут учитываться по данному MIB. Поэтому если хочется больше уверенности, то для него можно взять мониторинг по числу активных линий на трех dial-peer-ах (зоновые и межзоновые) и на входящем и все суммировать. Хотя это будет тоже не совсем точно.

3. Ретроспективный метод или мониторинг успешности звонков

Почему появилась такая необходимость за этим наблюдать? Потому что как раз- превентивные средства мониторинга голосовых транков абсолютно не гарантирует прохождение звонка в будущем, а это именно то, для чего наши они существуют. Поэтому если хочется действительно знать, что происходит на голосовых транках, то без постфактумного анализа звонков здесь не обойтись. Т.е. Теперь мы рассматриваем ситуацию, что обыкновенный звонок (попытка звонка) была через CUBE или с CUCME и анализируем результат с каким он завершился. И вот как раз именно cause code нам сообщит нам, что у нас все сработало нормально или имеются проблемы на транке и характер проблемы. Если при превентивном подходе для нас большую роль играла SNMP-система мониторинга, то при пост-фактумном требуется syslog – сервер, который может выдавать нам alarm разных видов, например , на почтовый ящик сисадмину по определенным условиям. Причем, alarm посылается без промедления.

Так например, вся последующая цепочка событий проходит в течение 1 минуты:

завершился звонок на CUBE-> log-сообщение о завершенном звонке на syslog-server → email на почтовый ящик админа-> наличие email о проблеме в почтовом ящике сисадмина.

Так что это получается практически on-line monitoring. Данные виды мониторинга для удобства сведены в таблицу 2.

Таблица 2 Мониторинг успешности звонков.

Теперь об этом немного в деталях.

3.1 Мониторинг затянувшегося звонка

3.1.1 Полезность. Следующая полезная вещь, на мой взгляд, мониторинг  затянувшихся звонков. Полезно это по следующим причинам:

- длительные междугородние звонок и -  это увеличение расходов, поэтому за ними всегда стоит наблюдать,  все ли они легитимны и по производственным вопросам?

- CUCME не  предоставляет ограничения длительности звонка так же просто как CUCM – изменением параметра в настройках….  и поэтому звонок на нем может висеть  так долго – пока оператор не отключит его

- на FXO портах из-за не точных тоновых настроек – сессия может «висеть» достаточно долго и опять же добавить расходы на связь или просто занимать линию

- возможно наличие «залипших» сессий на CUBE, CUCME хотя на самом деле звонок уже закончился – в таком случае увидев это – можно проверить наличие таковой и почистить ее принудительно.

3.1.2 Нюансы и решение: нет штатного простого средства мониторинга длительности звонка на CUBE и CUCME, пока он еще не закончен. И тут нам на помощь приходит EMM встроенный в IOS со всеми своими доп. возможностями и гибкостью.

Немного труда и  для данной задачи был разработан вот такой примерно скрипт:

event manager session cli username "user_admin"
event manager applet LongCall-5m
 event timer cron name Test cron-entry "0-59/20 * * * *"
 action 070 set lines "0"
 action 075 cli command "sh call act voice brief duration more 3600 | i Answer|Originate|audio tos:0x0|audio tos:0xB8"
 action 080 foreach line "$_cli_result" "\n"
 action 085  increment lines
 action 090 end
 action 095 if $lines gt 1
 action 100  decrement lines
 action 105  foreach line "$_cli_result" "\n"
 action 110   if $lines gt 0
 action 115    syslog priority alerts msg "Moscow  Warning Long Call - $line"
 action 120   end
 action 125   decrement lines
 action 130  end
 action 135 end

 

Про скрипт стоит пояснить, что он каждые 20 мин проверяет наличие  сессий с длительностью более 3600 сек. При обнаружении таковой – выдает на syslog сообщение о ее наличии. Ну а далее все как обычно – попадает в email админа. Далее на совести админа – делать этим что-то или нет. Если через 20 мин. звонок все еще висит – придет снова e-mail. Из опыта -таких писем из одного места более – 2-3 обычно не получал. Это как правило – какие-нибудь расширенные планерки и совещания.

3.2 Мониторинг международного звонка

3.2.1 Полезность. Особо пристальное внимание со стороны финансовой вызывают международные звонки, по следующим причинам:

- ввиду их особой важности обычно

- ввиду относительно более  высокой стоимости

- ввиду того, что они являются целью – tall fraud

Поэтому  была внедрена возможность наблюдения за данным видом звонков. Если на предприятии таких звонков не так много – 2-3 десятка в день – максимум. То вполне реально наблюдать за их количеством и успешностью через  сообщения  syslog- сервер.  Так можно видеть – дозвонились боссы или нет, если не дозвонились – посмотреть причину. Ну  и если где-то прорвало защиту от tall-fraud, то можно увидеть эти непонятные частые звонки в непонятном направлении. Дело в том, что со временем в процессе  наблюдения  за этими звонками – в сознании админа выстраивается определенная baseline, т.е. куда обычно звонят по международным направлениям, длительность звонка, откуда разрешен звонок или нет  и т.д. Соответственно при появлении новых направлений и т.д. всегда стоит обратить на это внимание.

3.2.2 Реализация. Вариантов мониторинга два (я использую оба).

- on-line  мониторинг поднятия  числа call-legs  на  определенном outgoing  dial-peer , что обслуживает  международные звонки – 810... Как и в мониторинге  транков – опрашиваем по SNMP через соответствующий OID  голосовой шлюз. Наблюдаем наличие звонков на этих dial-peer и их количество.

- пост фактумный мониторинг – по горячим следам, через  логирование  завершенных звонков на голосовом шлюзе и syslog – сервер.

3.3 Мониторинг не успешных звонков

3.3.1 Реализация этого очень проста с точки зрения настройки на голосовом шлюзе:

Выполняем настройки для логирования на syslog-сервер, даем команду отправки CDR также в качестве log-сообщений. И все.

logging source-interface Loopback0

logging 10.x.x.x

gw-accounting syslog 

Syslog – сервер получает примерно такое сообщение:

11838: May 14 2015 10:17:58.130 EKB: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId 6A293AB3F92F11E48314E6F3FBE497A3, SetupTime 10:17:58.050 EKB Thu May 14 2015, PeerAddress 8xxxx300, PeerSubAddress , DisconnectCause 29  , DisconnectText temporary failure (41), ConnectTime 10:17:58.130 EKB Thu May 14 2015, DisconnectTime 10:17:58.130 EKB Thu May 14 2015, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0
 

Из которых, можно не мало почерпнуть полезной инфы, но нас особо интересует –DisconnectCause.  Этот параметр  расскажет, о том как закончился звонок. И выдаст причину такого завершения звонка.

Отфильтровываем на Syslog –server – только не успешные звонки и причина которых не связана с поведением абонента удаленной стороны (т.е. например – абонент – занят- нам не интересно для анализа).

Пример фильтра на kiwi-syslog  сервере выглядит так:

3.3.2 Полезность:

Сколько интересного  я узнал про свои голосовые шлюзы и телефонию, с того момента как включил этот мониторинг, что всего и не расскажешь. Но вот кратко, что можно увидеть, имея его включенным:

- проблемы на определенном  голосовом транке ведущем к провайдеру. Если пошли письма с неуспешными звонками – один за другим – там есть проблема, нужно туда обратить внимание, пока кто-то не «ткнул» тебя в нее носом.

- не совершенный dial-plan – пользователи забывают добавлять всякие доп. цифры впереди для выхода наружу (какие-нибудь твои два «0») и это бывает можно поправить.

- не наученность пользователей – кто-то тупо пытается дозвониться в конференцию. Которая еще не создана и можно предпринять какие-то организационные меры.

-  наличие лишних переходов (call-legs) во время звонка

3.3.3 Издержки просвещенности: Мониторинг  не успешных звонков придаст не бывалую живость почтовому ящику админа. Писем будет много особенно поначалу (до 100 в день), пока не отстроишь фильтр, на то, что стоит внимания. И здесь есть нюанс, что включить в фильтр. Например вот следующий  код  мне пришлось оставить, потому что  оператор связи возвращал нам его не из-за не правильного номера, а из-за того, что внутризоновые звонки на сотовые телефоны он нам блокировал из-за проблем с договором.

DisconnectCause 1C  , DisconnectText invalid number (28)
 

 Нюанс 2 – можно ограничить фильтром, чтобы  алерты приходили только с call-leg со стороны, что инициировала вызов, но тогда не будет видно куда он звонил. И я решил оставить.

Нюанс 3- одиночный алерт (с одного call-leg) можно игнорировать, так как при не успешном звонке – такого не бывает в реальности.

4 Вывод:

Осведомленность  или  тихий омут.  Я думаю. Что со временем, наработав еще более статистики – можно еще оптимизировать фильтр, но полагаю, что все-равно,  здесь в 10 писем в день не уложишься никак. И здесь каждый админ должен выбрать, насколько ему подходит такой тип мониторинга. Меня, скажем, особо не затрудняет, скидывать письма в корзину из своего ящика, а копии кладутся локально в соответствующую папку. Зато есть ясность – что происходит, кто не дозвонился, кто-то долго висит на линии, или имеется сбой, как прошел международный звонок? Все это видно – сразу по горячим следам. Можно дальше повышать эффективность корпоративной телефонии. 

2 Комментарии
New Member

Здравствуйте!

У нас на данный момент мониторится утилизация SIP транков так же как написано в вашей статье.

Хотели бы таким же образом мониторить CPS на CUBE который выводится через show call history stats cps table.

Нашел в документации OID cvCallRateMonitor (1.3.6.1.4.1.9.9.63.1.3.11). Подскажите, он позволит собирать информацию о CPS?

New Member

Сорри, не подскажу.

Надо пробовать и смотреть что будет получаться - то ли, что Вы хотели бы.

1330
Просмотры
30
Полезный материал
2
Комментарии