Call Manager или CUCM поражает своим размахом и обилием настроек. CUCM мало чем похож на его "собрата" Call Manager Express (CUCME), и иногда кажется что и называться они должны по другому, - настолько различны их настройки. Но от него могут звонить те же самые телефоны, а из океана мануалов можно вычленить некий сухой остаток того с чего следует начать, избежав множества ошибок и подводных камней.

В данной статье обсуждается краткая теория, а также практические шаги, необходимые для подготовки к настройке базовой конфигурации CUCM на примере версии 8.5. Статья также подойдет и для версий CUCM 6.x и 7.x, а также всех более поздних версий 9.x и 10.x, которые очень похожи.

Раннее нами обсуждались вопросы настройки CUCME или Call Manager Express в двух частях:
Настройка CUCME с нуля Часть 1
Настройка CUCME с нуля Часть 2
Как уже было отмечено, имеются существенные отличия в настройках продуктов CUCME и CUCM, но базовые принципы работы все равно те же: работают те же телефоны, те же протоколы и т.д.

CUCM - может быть установлен в двух видах:

• в виде Appliance, т.е. сервер под Linux с установленным приложением.
• в виде виртуальной машины всё того же сервера Linux.

Установочный диалог CUCM

Итак, к вам приехали коробки с оборудованием Call Manager или CUCM. Обычно его поставляют в виде кластера. В кластер чаще всего входят два сервера:
- Publisher - на нем производятся все изменения конфигурации
- Subscriber - "подсасывает" копию базы от Publisher.
Оба сервера из коробки должны иметь предустановленное ПО, и при их включении нужно будет пройти "установочный" диалог.

Для того чтобы сервер вернуть в это предустановочное состояние, нужно его загрузить с установочного диска, после установки ОС и последующей перезагрузки сервер будет готов к "установочному" диалогу. Роль сервера (Publisher/Subscriber) определяется этим диалогом.

Установка Publisher

Более подробно см. статью Пошаговая начальная установка CUCM 8.x
При вопросе Is this server first node in the cluster отвечаем YES

В процессе диалога спросят три пароля которые нужно записать и хранить в надежном месте:
- Platform Admin
Используется для доступа к консоли SSH, Disaster Recovery system

- Application User
Используется для доступа к Cisco Unified CM Administration, Cisco Unified Serviceability, Cisco Unified Reporting

- Пароль для БД
Используется внутри системы и в повседневной деятельности не нужен. Может понадобиться при восстановлении.

Так же мастер установки спросит:
- Имя сервера
- IP адрес
- Primary DNS server
- Secondary DNS server
- Domain
- Default Gateway

В среде, где будет работать CUCM, нужно чтобы клиенты могли разрешать его имя в адрес как с доменным суффиксом так и без него.
Т.е. в DNS серверах нужно вбить запись нашего CUCM
Это нужно обязательно проверить с помощью nslookup.
Например если имя сервера cucmsrv1 а домен office.local, то разрешать в его адрес должны имена:
- cucmsrv1
- cucmsrv1.office.local
В противном случае возможно кривизна в работе телефонов и их переключении при сбое основного CUCM.

Также отмечу может не для всех очевидную вещь:
Все компоненты комплекса VOIP должны иметь связь друг с другом.
Если у вас есть межсетевые экраны то лучше их отключить на время установки и "затягивать гайки" когда все заработает, а еще лучше вообще убрать все ограничения для связи между всеми компонентами, а именно:
- IP телефоны
- Ноды кластера CUCM
- VoIP Gateway
- Conference Bridge
и т.д.

Итак после того как мы пройдем установочный диалог, мы уже сможем подключаться к серверу через HTTPs. Вообще, в отличие от CUCME подавляющее количество операций можно делать только через WEB.
Существуют шесть отдельных интерфейсов:
■ Cisco Unified Communications Manager Administration (https://ip_address/ccmadmin)
■ Cisco Unified Serviceability (https://ip_address/ccmservice)
■ Disaster Recovery System (https://ip_address/drf)
■ Cisco Unified Operating System Administration (https://ip_address/cmplatform)
■ Cisco Unified Reporting (https://ip_address/cucreports)
■ Command-Line Interface (CLI)

Установка лицензий CUCM
Обычно лицензия из себя представляет pdf файл, в котором мы найдем PAK Number

Также нам понадобится MAC адрес Паблишера:
Cisco Unified Communications Manager Administration -> System -> Server -> выбираем сервер, в его свойствах должно быть написано:
Database Replication Издатель (или Publisher)
Копируем из того же окна его MAC адрес

Далее идем на http://www.cisco.com/go/license и логинимся под логином, который должны дать при покупке CUCM
- Вводим PAK number
- Вводим MAC адрес publisher
- Скачиваем файлы лицензий. Если они в архиве, то нужно разархивировать. Файл должен быть в формате *.lic
- подгружаем файлы лицензий:
Cisco Unified Communications Manager Administration -> System -> licensing -> License file upload

Если лицензии успешно загрузились, это отразится на их количестве в:
Cisco Unified Communications Manager Administration -> System -> licensing -> lisence unit report

Активируем необходимые сервисы
Cisco Unified Serviceability -> Tools -> Service Activation -> Выбираем сервер
Активируем там все сервисы кроме Cisco Messaging Interface (используется для внешних серверов Voice mail)

Конечно, в большой организации, с большим количеством серверов и с большой загрузкой по хорошему надо распределять роли между серверами. Но практика показывает, что железо прекрасно несет все функции одновременно, а утилита RTMT (Real Time Monitoring Tool) позволяет мониторить загрузку CPU и памяти.

Установка Subscriber

При установке Subscriber происходит репликация БД на него, поэтому Publisher должен его "знать".
Для ввода Subscriber подключимся к Publisher:
SUCM Administration -> System -> Server
Выбираем Add new и вбиваем имя.

При установке мы вводим аналогичные параметры
-При вопросе Is this server first node in the cluster – NO
-Вводим данные First Node Server

После установки аналогично активируем все доступные сервисы

Проверка репликации

Для проверки установки Subscriber проверим репликацию баз. Если репликация в порядке, скорее всего все остальное тоже прошло нормально.

Узнать статус репликации мы можем из нескольких источников:
RTMT
RTMT (Real Time Monitoring Tool) - очень полезный инструмент не только для проверки репликации но и многих других задач.
На левой панели выбираем Call Manager, затем Database summary.
Нас интересует "replication status" - если его значение одинаковое для всех нодов, значит все нормально.

CUCM Unified Reporting
Unified Reporting > System Reports > Unified CM Database Status > Generate new Report
Если все нормально мы должны там найти фразу All servers have a good replication status

CUCM OS Admin CLI
Даем команду:
admin:utils dbreplication status

No Errors or Mismatches found.
Replication status is good on all available servers.

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

Разработка Диал Плана (DialPlan)

Dial plan - это один из ключевых элементов системы IP Telephony. Его планирование можно сравнить с планированием IP адресации: чем больше организация тем более важен хорошо продуманный диалплан.

Как будет выглядеть номер телефона в центральном офисе и филиалах? Как они будут звонить друг другу? Как производить выход в город?

Шаг 1
Первое что нужно - это прикинуть каково общее количество абонентов сейчас и сколько будет в будущем.
Сколько абонентов может быть в каждом филиале.

Шаг 2
Понять какую адресацию использовать:
- Flat addressing
Каждый телефон в организации имеет уникальный номер. Например:
1XXX Филиал 1
2XXX Филиал 2
3XXX Филиал 3
Т.е. независимо от того, звоним мы в своем офисе или в филиале, мы набираем4-х значный номер.
Какой тип адресации прост и потому называется Flat, плоский (также он встречается под терминами Uniform, Non-Overlapping). Например такой тип адресации используется в мобильных телефонах, все номера имеют длину 10 знаков. При этой адресации проще дебагить проблемы и такая адресация рекомендуется cisco.
Неудобство начинается когда количество абонентов становится слишком большим и требуется длина номера уже не 4 цифры, а 5 и выше.
"Зачем мне набирать 6-значный номер чтобы дозвониться в соседнюю комнату?" - спросит начальство.
Тут конечно можно использовать методы трансляции, но длинный номер всегда будет смущать неподготовленного пользователя.

- Partitioned addressing
При таком типе адресации в организации телефоны в разных филиалах могут иметь идентичные номера, а для звонка в другой филиал нужно будет набрать код этого филиала.
Такой тип адресации позволяет использовать короткие номера при внутренних звонках независимо от размера организации.
Это может быть удобно пользователям, но с точки зрения системы и администрирования гораздо сложнее:
- В логах нужно будет учитывать не только номер, но и партицию. Не все программы это умеют делать, например Tariscope в отчетах подставляет только внутренний номер и совершенно непонятно куда производился звонок.
- Для звонков между филиалами нужно создавать два правила трансяции для каждой пары филиалов. Если число филиалов будет более 20 число шаблонов будет исчисляться сотнями

Планирование диалплана при использовании Flat addressing
Благодаря простоте этого типа и диалплан будет тоже простой. Все что нам нужно знать - заложиться на максимальное число всех абонентов.
Например если у нас центральный офис 500 человек и 20 филиалов по 100, то нужно заложиться на 2500 номеров. Получаем что нам требуется четырехзначный диалплан, который обеспечивает до 10000 номеров, его можно сделать например таким:
0XXX - зарезервирован для выхода в город
1XXX - большой филиал 1
2XXX - большой филиал 2
3XXX - большой филиал 3
4[0-4]XX- средний филиал 1
4[5-9]XX- средний филиал 2
51XX - Малый филиал 1
52XX - Малый филиал 2
........
59XX - Малый филиал 9
6XXX - Для будущего развития
7XXX - Для будущего развития
8XXX - Для будущего развития
9XXX - Зарезервирован для выхода в город

Как видно в данном типе диалплана для системы абсолютно не важно какой номер будет находиться в каком городе. Распределение делается только для удобства.

Планирование диалплана при использовании Partitioned addressing
В данном случае нам нужно знать максимальное ожидаемое количество абонентов в одном филиале и максимально возможно количество филиалов.
Например если в филиале ожидается не более 300 абонентов, и всего не более 20 филиалов:
0 - зарезервирован для выхода в город
[1-5]XX - внутренняя номерация
[6-7]X - код филиала
8 - Для будущего развития
9 - зарезервирован для выхода в город

Таким образом внутренний звонок будет выглядеть как трехзначный номер [1-5]XX, а звонок в другой филиал как пятизначный номер [6-7]X[1-5]XX

Partitions и Calling Search Spaces

Мы разработали диалплан, т.е. как звонки должны ходить в теории.
Для практического внедрения диалплана важную роль играют Partitions и Calling Search Spaces - фундаментальные понятия системы CUCM, благодаря которым тысячи телефонов, находящиеся в десятках разных городов, могут управляться с одного кластера. Этот раздел статьи довольно объемный, но автор очень рекомендует все прочесть и понять. Если вы поймете что такое CSS и партиции, вы сможете планировать и затем "жонглировать" (не побоюсь этого слова) звонками из города в город.

Как обеспечить, чтобы в каждом городе при наборе "9" звонок выходил на свой локальный шлюз?
Как реализовать перекрывающуюся номерацию при Partitioned addressing?
Как сделать бесплатными звонки из одного города в другой не платя за межгород, но используя внутреннюю сеть?
Здесь нам как раз и приходят на помощь Partition и CSS.

Partition
Каждый номер телефона (DN), т.е. ТО, куда можно позвонить - ассоциируется со своей партицией.
Можно сказать, что партиция ассоциируется с объектами на которые можно позвонить (например номера телефона).
Партиция - это группа номеров с одинаковой доступностью и её можно сравнить с понятием VLAN. Телефоны находящиеся в разных партициях недосягаемы друг для друга и могут иметь идентичные номера.
Можно сказать, что "обычные" офисные телефонные станции оперируют в одной партиции.
По умолчанию существует только одна партиция "none", но использовать ее не рекомендуется, т.к. данная партиция доступна для всех телефонов. Конфигурация с партицией "none" вполне работоспособна при работе только с одним офисом, но и в самый неожиданный момент могут происходить разнообразные пренеприятные чудеса в маршрутизации, т.к. партиция "none" доступна для любого CSS. Даже если у вас только один офис, создайте отдельную партицию и работайте с ней.
Никогда не помещайте DN в партицию "none".

В общем случае с партицией могут быть ассоциированы:
■ DNs
■ Route Patterns
■ Translation Patterns
■ Voicemail Ports
■ Meet-Me Conference Numbers

Calling Search Space (CSS)
Как понятно из названия, CSS определяет то куда можно сделать звонок.
Можно сказать, что CSS ассоциируется с объектами, которые могут совершать звонок (например телефон)
CSS подобно группам могут в себя включать партиции. Для объекта с данной CSS становятся доступны объекты ассоциированные с указанными партициями.
Как и с партициями, мы можем для телефона выставить CSS . Такая CSS имеет доступ только к партиции none.
Не ассоциируйте никакие девайсы с CSS =

Пример1

Например пусть у нас будет два офиса в Москве и в Питере.
Для построения схемы Flat addressing мы создадим следующее:
- Партицию Oncluster_pt
Все телефоны организации будут ассоциированы с этой партицией и соответственно доступны друг для друга при наборе DN
- В Москве создадим партицию MSK_PSTN_pt
С этой партиций будут ассоциированы шаблоны для выхода в город, межгород и зарубеж для московских телефонов.
- В Питере создадим партицию PTR_PSTN_pt/
Как уже понятно, эта партиция для ассоциацией с шаблонами питерских телефонов

Теперь самое интересное - создадим CSS-ы
- В Москве мы создадим MSK_Internal_CSS. В него, как в группу мы включаем партиции:
Oncluster_pt
MSK_PSTN_pt
Также с этим CSS мы будем ассоциировать все московские телефоны.
- В Питере мы создадим PTR_Internal_CSS. В него включим
Oncluster_pt
PTR_PSTN_pt
И с ним ассоциируем все питерские телефоны.

Что у нас получилось: Всем телефонам доступна Oncluster_pt, т.е. партиция с которой ассоциированы все телефоны. Поскольку MSK_Internal_CSS включает в себя MSK_PSTN_pt, но не включает PTR_PSTN_pt, то при наборе "девятки" московские телефоны будут попадать в свой PSTN-шаблон, а соответственно на свой PSTN-шлюз. Питерские же пойдут на свой.
Таким образом мы добиваемся, что при наборе одной и той же "девятки" телефоны идут на разные шлюзы.

Работу партиций и CSS можно (и нужно) изображать схематично.

Кстати нам ничто не помешает ассоциировать питерский телефон с MSK_Internal_CSS и тогда он пойдет на московский шлюз. Телефону абсолютно все равно где он находится, какой у него IP адрес, в скольких сотнях километров он удален от CUCM, главное чтобы правильно были настроены Partitions и CSS.

А что будет если мы включим в MSK_Internal_CSS обе партиции PTR_PSTN_pt и MSK_PSTN_pt? Получится что при наборе 9 будут доступны оба шаблона и поскольку они равноценны система будет отправлять звонки согласно приоритету, в котором выставлены партиции в CSS MSK_Internal_CSS. Хотя подобная ситуация "разрулится", следует избегать подобных случаев пересечения, поскольку это очень сложно дебагить.

Структуру партиций и CSS нужно тщательно планировать. Даже в небольшом предприятии можно необдуманно нагородить такое, в чём разобраться будет очень сложно. Структура партиций и CSS должна четко соответствовать диалплану.

В структуре партиций и Calling Search spaces легко запутаться, поэтому DialPlan изображают схематично.
Пример схемы Flat addressing
На данной схеме все номера находятся в общей партиции Oncluster_pt.
Партиция Oncluster_pt входит во все CSS организации и потому все ассоциированные с ней номера и шаблоны доступным всем телефонам организации. Например это можно использовать для междугородних звонков: шаблон 98687XXX (междугородний номер города филиала REMO) доступен всем и при наборе номера, удовлетворяющего его условиям, звонок идет не по платному межгороду МГТС а напрямую через IP телефонию на шлюз REMO.
Для того, чтобы у каждого филиала была своя "девятка" (выход в город), для каждого сделан свой шаблон 9.T (9 и далее), который входит только в свой CSS.
MSK_Translations_pt используется для того чтобы внутри офиса можно было использовать 3-х значные номера, вместо 5-ти. При наборе [1-5]XX к номеру добавляется 77, и он становится пятизначным и понятным для системы.
На схеме фигурируют также Route Lists и Route Groups, эти понятия будут освещены в последующих статьях.

Пример схемы Partitioned Addressing

В данном примере отображена классическое решение для нескольких офисов и с применением Partitioned Addressing.
Здесь отображен новый элемент - Translation Pattern.
С помощью Translation Pattern мы можем получить возможность дозваниваться на телефоны из другой партиции.
Если продолжить аналогию Partition и VLAN, Translation Pattern подобен маршрутизатору.

При наборе номера из Москвы 70101, этот номер попадает под обработку соответствующего Translation Pattern, поскольку он находится в партиции MSK_Phones_pt.
Translation Pattern производит трансляции с двумя параметрами для нашего звонка:
- Called Party Transformation: Поскольку в партиции BGE_Phones_pt номера телефонов трехзначные, мы отнимаем от номера "70".
- Calling Party Transformation: Для того, чтобы номер звонящего нормально отображался, и на него можно было легко перезвонить, мы должны добавить к нему "77".
Далее, после произведения необходимых трансляций, звонок отдаётся уже в другую CSS, соответствующую данному Translation Pattern и повторно производится процесс Call-Routing Decision, но уже применительно к новой партиции.

Поток данных при звонке

Для того чтобы совершить звонок с одного телефона на другой, используются протоколы сигнализации, а также собственно сам аудио поток.
Сигнализация - это служебная информация, включающая номер телефона абонента, номер источника, кодек и другие данные, необходимые для того чтобы мог состояться сам звонок. Важно понимать, что CUCM является посредником между двумя аппаратами для передачи сигнализации. Даже для подачи гудка, который мы слышим при поднятии трубки, Call Manager передает соответствующий "приказ" телефонному аппарату.
Аудио поток - это собственно разговор абонентов. Важно понимать, что поток имеет место быть только непосредственно между двумя телефонами, Call Manager никак не участвует.

Централизованная топология

Существуют различные топологии, в которой может работать CUCM.
Можно в каждый офис поставить по кластеру CUCM, можно в центральный поставить CUCM а в филиалы CUCME и т.д.

Наиболее распространенным и недорогим вариантом является централизованная топология, в которой в центральном офисе расположен кластер CUCM, который осуществляет управление звонками как в центральном офисе, так и в филиалах.
Мы будем рассматривать разворачивание именно этой топологии, т.к. в ней будут задействованы все основные элементы маршрутизации CUCM.
Даже если в задачу входит развернуть телефонию в одном офисе, отталкиваться следует именно из общей топологии, т.е. полноценное создание партиций и CCS (хотя все это в принципе не нужно в одном офисе) - она позволяет при необходимости легко расширяться без перестройки диалплана, партиций и других фундаментальных элементов.

Централизованная топология подразумевает участие центрального Call Manager во всех звонках. Например даже для того чтобы в филиале могли созвониться два телефона, необходимо участие центрального CUCM.

Заключение

В статье были освящены шаги по установке серверов CUCM, а также необходимое планирование.
Следующим этапом будет собственно настройка комплекса телефонии, что будет описано в следующих статьях.
Настройка Call Manager CUCM с нуля: основные настройки (Часть 2)

Самоваров Владимир