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

Видео и голосовая связь Блоги (Voice and Video)

21 просмотров
0 Комментариев

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

Я недавно столкнулся с проблемой - на CUCM версии 8.6.2.20000-2 в меню User Management - End User отсутствуют кнопки Add New, Select All, Clear All, Delete Selected. Возможно, у пользователя, под которым я захожу не хватает каких-то прав. Подскажите, пожалуйста, какие права нужно добавить? 

1750 просмотров
0 Комментариев

Привет всем Cisco folk!

Почти 4 года назад я начал работать с подключением корпоративной телефонии к telephony providers. Подключений сделано немало за это время к разным провайдерам по телефонии с разными типами подключений (E1\ISDN, SIP, H.323). Хотелось поделиться немного опытом в данном блоге по такому важному аспекту – что нужно узнать у SIP-провайдера о его возможностях перед тем как выбрать его в качестве поставщика услуги? Как говорится: «Какую яхту вы берете, на той и поплывете». Конечно, можно и в процессе плавания понять, что это не та яхта, что хотел бы повернуть обратно и поменять ее, но время и деньги будут потрачены, ну и статус пострадает тоже. Так что, попытаемся рассмотреть критерии для подбора того, с кем нам плыть как с поставщиком телефонии на волнах российских реалий. Главным образом, коснемся технические параметров, тех что нужно узнать прежде подключения к поставщику телефонии. Итак, какие вопросы стоит задать сначала себе (своему руководству), а затем поставщикам телефонии, когда есть задача подключить городской номер (номера) к корпоративной телефонии? В моем случае она построена на основе Cisco UCM и CUBE, на мой взгляд это наилучший вариант с технических позиций по тех. возможностям, качеству и управляемости.

Итак, получили от бизнеса задачу на подключение со следующими требованиями:

- 2 городских номера в местном коде

- основной номер под звонки должен пропускать 5 звонков одновременно

- 2-й номер нужен для приема-передачи факса

- на основном номере должно быть приветствие и голосовое меню для выбора опций

 

Получив задачу, определяемся с технологией.

SIP или ISDN – что брать?

Считается, что ISDN (E1\T1) надежнее, т.к. это соединение точка-точка, а SIP зачастую идет через общий канал с интернет-трафиком. Не буду спорить. Однако есть несколько аргументов в пользу SIP- подключения:

  •     обычно SIP значительно дешевле чем Е1
  •     не все локальные операторы могут дать E1
  •     гибкость по количеству одновременных звонков. Дело в том, что далеко не все операторы готовы дать не полный E1, а только половину или скажем четверть, а тем более 4-5 линий, и платить придется за полный E1, не смотря на то, что использовать вы будете только часть тайм слотов.
  •     на вашей стороне для приема SIP не нужен спец. модуль для приема ISDN, все идет через Ethernet

Trunk SIP или H.323 – что лучше?

Здесь, смотря кому что удобнее и смотря, что может дать оператор связи… Я скажу только несколько плюсов в моих глазах в пользу SIP.

  •      SIP- более удобен в плане troubleshooting – все легко и удобно читается и в компактной форме
  •      Большинство современных провайдеров предлагают подключение именно по SIP
  •      Многие современные телефоны в т.ч. и Cisco делаются под SIP

Мы выбрали, что подключаемся к провайдеру по SIP и у нас имеются провайдеры предлагающие данный вид подключения.

Все критерии услуги, можно разделить на 3 группы: функциональные, безопасности и менеджмента. Я их свел в таблицу (она в приложении) и я буду рассматривать вопросы проходя последовательно по пунктам таблицы.

  • Функционал

Версия SIP- обычно version 2.0 – на самом деле других вариантов и не видел в практике.

Число тайм-слотов – или одновременных звонков. Если бизнес сказал пять – пять и заказываю, потому что бизнес обычно говорит уже с запасом. И тем более с SIP – транком – обычно нет никаких проблем добавить 2-3 по необходимости. И провайдер всегда более охотно идет на увеличение числа тайм-слотов нежели на уменьшение. Здесь, стоить помнить про bandwidth, но я вернусь к этому вопросу в пункте про codec.

Поддерживаемые кодеки: чаще всего провайдеры дают G.711-A, G.711-U, G.729, но у кого-то я видел и iLBC, но это – редкость на наших просторах.

Codecquality vs bandwidth. Понятно, что качество звука выше – bandwidth больше, но если это не спутниковый канал, то вопрос bandwidth не столь критичен. На 6 звонков 523kbps для 711 или 187kbps для 729. В общем на практике на 5-6 звонков – просто накидываем 1Mbps bandwidth – интернет канала и этого достаточно, даже с шифрованием. Кроме того, меньше 1 Mbps – все равно провайдер не будет отделять, если это не спутниковый канал.  

Codec- for IVR. В нашем случае даже более важную роль играет не bandwidth, а то что у нас на CUBE будет IVR с голосовым приветствием. Поэтому для нас гораздо удобнее принять от провайдера на входящем dial-peer G.711-A и записать au-файл приветствия в том же codec, чем отыскивать потом не тривиальные решения состыковывая 729 от провайдера с 711 –на IVR.

Support of RTP-NTE DTMF. Дело в том, что у нас заявлена возможность голосового меню, поэтому DTMF нам определенно понадобится. Соответственно, для нас лучше, чтобы провайдер передавал сразу DTMF в формате RTP-NTE. Это и надежнее и проще в обработке. Мы сможем просто сразу обрабатывать это на нашем входящем dial-peer, на котором у нас работает application (IVR). В противном случае нам придется строить дополнительные call-legs на CUBE и выделять dial-tone из общего RTP и преобразовывать в это в RTP-NTE опять же. И для этого, опять же, придется задействовать media- ресурсы CUBE. Благо, что Cisco IOS на CUBE может все это делать. Понятно, что провайдер, может сказать вначале, что все дадут, а на практике это у них не всегда получается… Но по крайней мере – нужно запросить то, что нужно, чтобы избежать лишних проблем.

Форматы номеров А (calling number) и В (called number)-  нужно просто знать эти форматы от провайдера, чтобы настроить свой голосовой шлюз сразу правильно на получение и выполнение звонков. Иначе они просто не будут проходить. Дело в том, что номера могут передаваться\приниматься в форматах: E164 – 11 цифр или в урезанном виде -10 цифр или в локальном 6 или 7 цифр. И если это не узнать, то придется просто пробовать все комбинации. И когда, что –то при этом еще не так в стыковке параметров с провайдером, то это будет небыстрый процесс…

Сall modification – возможности управлением уже принятого звонка через сообщения (update, reinvite). Это бывает важно, для того, чтобы взять звонок на HOLD, или перевести на кого-то звонок (transfer) или объединить в конференцию. Это нормально для SIP (принципиально это все описано в нем), но по факту – не всегда провайдеры (по причине их софта, оборудования или настроек) способны это обрабатывать правильно. В итоге, звонок может просто отключаться ровно через 15 мин. или не возвратиться с HOLD. И снова скажу – что и эти минусы можно обойти благодаря гибким возможностям Cisco IOS, но лучше их просто избежать.

IP –адреса и порты для signaling – это нужно просто получить от провайдера. UDP или TCP-? 5060 или что-то другое. И на практике я встречал, когда порт был не 5060, а 5063.

IP –адреса и порты для media (RTP) – и здесь бывает разнообразие, кто-то шлет с одного IP, кто-то с целой сети- /24. Порты обычно 16384 - 32767 UDP, но может быть и уже диапазон.

Поддержка Передачи факсов по протоколу T.38. Несмотря на то, что T.38 - наиболее распространенный протокол для передачи факса по VoIP, тем не менее не все провайдеры поддерживают это нормально, в особенности на МГМН – направлениях.

Режимы: early offer, early media Cisco CUBE поддерживает и то, и другое, поэтому особых затруднений здесь не должно быть.

Другие опциональные возможности: если хочется мониторить транк через keepalive, то стоит спросить у провайдера про поддержку OPTIONS- сообщений, если нужен VAD (мне не разу это не было нужно), то стоит про это спросить.

Поддержка QoS. Если мы работаем не через выделенный канал (но даже и с ним), стоит узнать у провайдера поддерживает он QoS для signaling и RTP – трафика и как маркирует пакеты при этом. Понятно, что в интернете QoS никто не гарантирует, но если сохранится раскраска, то можно будет хотя бы обрабатывать его на своем маршрутизаторе соответственно.

II - Security

Нельзя обойти вопрос безопасности в подключении к telephony-providers. И в этом вопросе security должна быть обеспечена на обоих сторонах SIP-trunk.

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

- через специально выделенный Vlan для VoIP и private IP- адреса. С одной стороны, здесь все просто- выделенный Vlan от SIP – сервера (голосового шлюза) до нашего голосового шлюза (CUBE - например) и все звонки, что идут через него, стало быть легитимные. Кроме того, на выделенной линии вопрос с QoS гораздо проще решается. С другой стороны, для этого Vlan – нужна либо дополнительная физическая линия, либо это должен быть один и тот же поставщик и Интернета и VoIP. Первое слишком дорого выходит, а второе ограничивает вашу свободу в смене поставщика интернета. Мы не однократно кусали локти по этому поводу, потому что, например, Интернет-провайдер дорогой слишком, а приходится его оставлять, т.к. телефон работает через его инфрастуркуру, а менять номер бизнес не готов.

- Аутентификация –Авторизация (AAA) Здесь нужно сказать, что провайдер иногда дает и User name и Authorization User Name, и здесь стоит уточнить, что и когда посылать?

- аутентификация & realm –значение выделил отдельно, специально – потому что мало кто из провайдеров, готов назвать этот realm, а у Вас регистрация SIP- User Agent не пройдет иначе. Поэтому, спросить его нужно, но, если провайдер – дует в щеки при этом вопросе- не отчаивайтесь: debug на Cisco – железках отличный, так что просто отыщите его потом в логах.

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

Некоторые провайдеры делают double-check, т.е. проверяют IP и пароль, и Вы не свободно можете поменять интернет провайдера при этом. На мой взгляд – это лучший вариант.

III – Разное.

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

- грамотная техподдержка -понятны ли ей ваши тех вопросы и устраивают ли Вас ее ответы

- возможность получения детальных отчетов о выполненных звонках

- возможность forwarding входящих звонков на другой номер и как это будет оплачиваться

- возможность управления услугой через личный кабинет на сайте

- возможность заключения федерального контракта

- доступность, грамотность и адекватность менеджера

 

Заключение

В целом хотелось бы сказать, что на сегодняшний день очень много различных поставщиков SIP- телефонии, с разными тех возможностями, уровнем безопасности и ценами. Поэтому очень важно, знать- что спросить у провайдера и как это потом проверить, чтобы получить требуемое качество сервиса. Кроме этого, важно чтобы у Вас самих было качественное оборудование и софт, чтобы и принять звонок, и посмотреть, его capabilities и обработать его так как нужно. Ни рекламы ради, а по достоинству из опыта еще раз повторюсь, что Cisco IOS на CUBE предоставляют реально хорошие возможности для обработки звонков и для обеспечения их безопасности.

Всем успехов и  Ваш выбор за Вами!

Таблица choose SIP-provider в приложении.

90 просмотров
0 Комментариев

мне пришла в голову идея как создать улучшенный DISA  скрипт и избавить звонящих людей от необходимости донабора внутреннего номера но только в тех случаях когда звонок идет всегда на один и тот же внутренний номер. например моя жена звонит и всегда набирает мой внутренний.

реализовать улучшенный DISA достаточно просто. к примеру нужно два внешних номера. на первом номере обычный DISA скрипт но он еще пишет в базу все звонящие номера и набранные номера. а на втором внешнем номере модифицированный скрипт DISA при внешнем звонке проверят в базе и если звонящий всегда набирает один и тот же внутренний то скрипт сразу же переадресует на внутренний.

2788 просмотров
12 коммент.

В этой статье мы рассмотрим функционал Mobile Connect (или как его иногда называют Single Number Reach) и процесс его конфигурации в CUCM. Mobile Connect - это функционал, который позволяет при входящем вызове на короткий номер (Directory Number) внутри кластера направить вызов не только на сам DN, а еще и на некий внешний номер, по которому вызываемый абонент тоже может оказаться доступным. Таким номером может служить номер мобильного телефона сотрудника, или его домашний номер. На самом деле Mobile Connect позволяет настроить подобную маршрутизацию одновременно на группу внешних номеров, принадлежащих сотруднику. Отсюда, собственно, и название Single Number Reach: позвонив на короткий корпоративный номер сотрудника, можно фактически дозвониться до него, независимо от того, находится он реально возле телефона или нет. Mobile Connect направит такой вызов на указанную группу внешних номеров, по одному из которых вызываемый абонент сможет ответить. Рассмотрим принцип работы Mobile Connect на примере:

Некий абонент с номером 4795551555 набирает следующую последовательность цифр: 15115552001. Этот вызов через публичную телефонную сеть маршрутизируется до некого голосового гейта, через который попадает в CUCM кластер. Для простоты будем считать, что этот входящий вызов предназначен для DN 2001 (допустим, что последние 4 цифры публичного номера сотрудника соответствуют его корпоративному номеру). Это, конечно же, означает, что телефон, на который назначен DN 2001, зазвонит, но если для этого сотрудника был настроен Mobile Connect, то CUCM направит этот входящий вызов еще и на внешний (например, мобильный) номер 4085551001, который тоже принадлежит тому же сотруднику. Соответственно ответить на этот вызов сотрудник сможет либо на офисном телефоне, либо на мобильном. Фактически можно считать, что настройка Mobile Connect приводит к организации того же самого shared line с той лишь разницей, что классический shared line организуется между несколькими телефонами внутри кластера, а при использовании Mobile Connect - между офисным телефоном и каким-то внешним устройством, которое к кластеру может не иметь никакого отношения. Схематично эту конфигурацию можно можно изобразить следующим образом:

 

Как видно из этой схемы, Mobile Connect действительно организует shared line между обычным офисным телефоном и такой сущностью, как Remote Destination Profile (RDP), который в конфигурации CUCM отражает группу внешних номеров. С привязкой DN к RDP ассоциирован один или несколько Remote Destination, который фактически описывает сами внешние номера. Remote Destination Profile и Remote Destination являются неотъемлемыми элементами конфигурации Mobile Connect. Но помимо них, нам понадобятся еще следующие сущности:


User - это End User, известный CUCM, для которого включен функционал Mobile Connect. Фактически, когда речь заходит о какой-то мобильности в CUCM, во главу угла всегда ставится пользователь, а не устройство, поскольку речь идет о предоставлении collaboration сервисов какому-то человеку, а не конкретному устройству. С пользователем у нас будут ассоциированы офисный телефон и RDP.
IP phone и Softkeys. С телефоном в целом несложно: как уже было сказано, с ним надо ассоциировать конкретного пользователя. Но возможно, на телефоне в режиме on-hook нам понадобится софтовая кнопка Mobile. С ее помощью наш пользователь сможет перебросить уже активный вызов на офисный телефон, если вызов уже организован на мобильный телефон. В этом случае кнопку Mobile придется добавить на телефон через Softkey Template.
Access list. Это необязательный элемент, однако его использование позволяет фильтровать входящие вызовы на мобильный телефон на основании номера вызывающего абонента. Достаточно удобно, если требуется, чтобы до Remote Destination добирались не все вызовы, а только определенные. Access List формируется в конфигурации отдельно, а затем привязывается к RDP.


Конфигурация Mobile Connect является достаточно несложной. Начать стоит с создания End User, поскольку, как было показано выше, он является центральным элементом всей логики Mobile Connect. Пользователь может быть создан любым возможным способом, важно лишь включить для него фичу Mobile Connect, поставив в настройках галочку Enable Mobility:



Здесь же, кстати, можно обозначить максимальное количество Remote Destination (то есть внешних номеров), которыми этот End User сможет пользоваться.
После этого необходимо привязать данного пользователя к офисному телефону, которым он пользуется. Делается это с помощью стандатной опции Owner User ID в настройках самого телефона:


После этого можно переходить к настройке сущностей, специфичных именно для функционала Mobile Connect. Начнем мы с создания Remote Destination Profile. Создаются и настраиваются они в меню Device > Device Settings > Remote Destination Profile. В настройках нового RDP в обязательном порядке нужно указать того же самого End User, о котором мы говорили ранее. Делается это в поле User ID. Стоит обратить внимание также на поле Rerouting Calling Search Space. Это CSS, который CUCM будет использовать для исходящего вызова в сторону Remote Destination номеров, когда будет обрабатывать входящий вызов на офисный телефон. Этот CSS должен обеспечить доступность Route Pattern, который используется для маршрутизации исходящего вызова на Remote Destination:


После сохранения конфигурации RDP у нас появится возможность задать для него какие-то линии. На одну из линий назначаем тот же DN, который используется на офисном телефоне сотрудника, и для которого необходимо поведение, к которому приводит Mobile Connect, тем самым формируя shared line.


Далее переходим по ссылке Add a New Remote Destination, и попадаем в меню задания внешних номеров:

Помимо достаточно очевидного задания внешнего номера тут можно обратить внимание на следующие параметры:
Answer Too Soon Timer - регламентирует минимальный период времени, в течение которого вызов должен посылаться на Remote Destination перед ответом абонента. Если Remote Destination отвечает на вызов до истечения этого таймера, то вызов сбрасывается с Remote Destination и направляется на корпоративный VoiceMail (если таковой имеется). Этот таймер позволяет быть уверенным в том, что если мобильный телефон у сотрудника выключен или находится вне зоны действия сети, то вызов не попадет на мобильный VoiceMail.
Answer Too Late Timer - определяет, максимальную продолжительность посылки вызова на Remote Destination. Здесь нужно указать время, которого будет достаточно для того, чтобы абонент успел ответить.
Delay Before Ringing Timer - определяет задержку, с которой CUCM направит вызов на Remote Destination после получения входящего вызова на офисный телефон сотрудника.
Значения всех параметров задаются в милисекундах.
При настройке Remote Destination необходимо не забыть поставить галочку Line Association рядом с тем DN, с которым мы хотим ассоциировать внешний номер. Также обязательно ставим галочку Enable Mobile Connect. Опция Mobile Phone позволит перебросить активный вызов с мобильного телефона на офисный по нажатию на кнопку Mobility на офисном телефоне.



Если необходима какая-то фильтрация вызовов на Remote Destination, то далее можно перейти к настройке Access List. Настраиваются они в меню Call Routing > Class of Control > Access List. При настройке необходимо выбрать, какой именно лист мы формируем: Black List или White List, выбрав опцию Blocked или Allowed соответственно. Далее с помощью кнопки Add Member можно заполнить лист соответствующими номерами или их диапазонами:



Привязка созданного листа производится на странице настройки Remote Destination. Можно выбрать два варианта: направлять вызов на внешний номер, если вызывающий абонент присутствует в листе, или наоборот - не направлять, если присутствует. Обратите внимание, что помимо этого в настройках Remote Destination можно задать Ring Schedule. Это позволяет указать расписание, по которому вообще разрешено направлять вызовы на внешний номер. Здесь можно указать, например, только рабочие часы нашего сотрудника. Или наоборот: только нерабочие часы, чтобы после окончания рабочего дня наш сотрудник мог отвечать на входящие вызовы, но не по офисному телефону, а по мобильному:

При этом есть такая особенность: если одновременно настроено и расписание и Access List, то расписание проверяется первым. То есть, если вызов приходит в неразрешенное время, то Access List даже не проверяется, и вызов на внешний номер, конечно же, не направляется.

Эта несложная процедура позволит настроить функционал Single Number Reach, позволяющей сотрудникам отвечать на входящие вызовы на свой офисный номер с личных мобильных или домашних телефонов вне зависимости от того, откуда эти вызовы совершаются.

---

Андрей Петрунин,

учебный центр Fast Lane.

636 просмотров
0 Комментариев

Cisco Unified Serviceability предоставляет инструменты трейсов, помогающих решать проблемы приложений для совместной работы. Cisco Unified Serviceability поддерживает следующие трейс-опции:

  • SDI трейсы: это локальные лог-файлы. Каждый сервис Cisco Unified Communications Manager использует трейс лог файл по умолчанию. IP адрес, TCP handle, имя устройства, отсечка по времени и многое другое может быть использовано при анализировании SDI трейса для мониторинга прохождения запроса. SDI трейсы логируют события времени-выполнения, возникающих при выполнении программных процессов.
  • SDL трейсы: (Для Cisco CallManager и Cisco CTIManager сервисов, которые применимы к Cisco Unified Communications Manager и  Cisco Unified Communications Manager Business Edition). Лог файлы с SDL трейсами содержат информацию обработки вызовов от таких сервисов как Cisco CallManager и Cisco CTIManager. Система отслеживает SDL  звонка и логирует его состояния в лог-файл. Этот тип трейсов был исключен из CUCM, начиная с 10-й версии.

Инженеры Cisco используют SDL трейсы для нахождения причины ошибки. Чаще всего эта информация требуется при решении кейсов  в Cisco TAC.

  • Log4J используется для Java-приложений. Чтобы  определить уровень информативности трейсов, а также тип получаемой информации необходимо использовать окно Trace Configuration. Эта информация попадает каждый трэйс файл.


В окне Alarm Configuration есть возможность настроить направление передачи аварий в различные места назначения, включая SDI или SDL лог файлы. Настроить трейсы для аварий можно  в Cisco Unified RTMT.  Файлы с логами трейсов накапливаются и могут быть просмотрены с помощью опции Trace & Log Central в Cisco Unified RTMT. С ее помощью есть возможность  собирать SDL и SDI трейсы, логи приложений, системные логи ( такие как логи событий, логи безопасности и , системные логи) и дамп файлы крешей. Есть возможность загружать на локальную рабочую станцию трейс файлы с серверов Cisco Unified Communication Manager и просматривать их локально.

Трейсы можно активизировать двумя путями:

  • Activate troubleshooting traces (Разрешение   трейсов для поиска и устранения неисправностей). Настраивается в Cisco Unified Serviceability > Trace > Troubleshooting Trace Settings. Это действие включает практически все возможные опции по трейсам  для выбранных серверов и сервисов. Получаемые трейсы содержат очень много детальной информации часть которой может оказаться не очень полезной для решения проблемы, в результате придется искать полезную информацию в большом количестве данных сгенерированных  трейсов. Такого типа трейсы оказывают влияние на производительность сервера,
  • Enable and configure traces (Разрешение и конфигурирование трейсов): Эта опция доступна из Cisco Unified Serviceability > Trace > Configuration и позволяет разрешать и запрещать трейсы для сервера или сервиса (также как и для трейсов для поиска и устранения неисправностей). Однако в данном случае есть возможность применения фильтров - разрешая или запрещая определенные поля для трейсов. Такие трейсы генерируют гораздо меньше информации и по этому могут быть более информативными. В результате анализировать такую информацию более удобно и быстро. К тому же в данном случае нагрузка на сервер не сопоставима с первым вариантом настройки трейсов.


Cisco Unified Communications Manager позволяет настраивать трейсы таким образом, чтобы получить максимум необходимой информации при минимальном размере трейс лог файла.
 

Основной поиск и решение проблем осуществляется на Cisco CallManager service targeting dial plan и устройствах.
При анализирование ошибок набора цифр в Cisco Unified Communications Manager необходимо иметь ввиду то, что трейсы Cisco Unified Communications Manager по умолчанию не включают детали о translation patterns и alternate matches—отображается только результат. Такое поведение не зависит от сконфигурированного уровня информативности трейса. Есть возможность настроить получение более детальной информации во время цифрового анализирования  путем изменения сервисного параметра Cisco CallManager Digit Analysis Complexity с значения по умолчанию StandardAnalysis (которое показывается в выводе трейса как dac=“0”) на TranslationAndAlternatePatternAnalysis ( показывается как dac=“1”).
С помощью изменения параметра Max Number of Device Level Trace в Cisco Unified
Communications Manager Administration можно определить по какому количеству устройств могут  одновременно получаться  трейсы если в Trace Configuration в Cisco Communications Manager Serviceability был выбран трейс по имени устройства.  По умолчание это 12 устройств.
Если требуется генерировать аварию на появление требуемой строчки поиска в отслеживаемом трейс файле необходимо разрешить аварию LogFileSearchStringFound в Cisco Unified RTMT. Аварию LogFileSearchStringFound можно найти LpmTctCatalog. В Cisco Unified Serviceability, надо выбрать  Alarms > Definitions. В Find
Alarms Where drop-down меню выбрать System Alarm Catalog. В Equals drop-down меню, выбрать LpmTctCatalog.
Есть возможность настройки получения трейсов для определенного сервиса.
Если используются кластер Cisco Unified Communications Manager, можно сконфигурировать трейсы для сервиса на одном сервере или на всех серверах кластера. Настройки можно конфигурировать на экране Trace Configuration в Cisco Unified Serviceability.

Для анализа трейсов, есть очень удобная программа - TranslatorX.

---

Modest Sokolov
инструктор-консультант учебного центра Fast Lane в России

2525 просмотров
2 коммент.

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 писем в день не уложишься никак. И здесь каждый админ должен выбрать, насколько ему подходит такой тип мониторинга. Меня, скажем, особо не затрудняет, скидывать письма в корзину из своего ящика, а копии кладутся локально в соответствующую папку. Зато есть ясность – что происходит, кто не дозвонился, кто-то долго висит на линии, или имеется сбой, как прошел международный звонок? Все это видно – сразу по горячим следам. Можно дальше повышать эффективность корпоративной телефонии.