Налаштування Call Manager CUCM з нуля підготовка (Частина 1)

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

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

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

Отже, після того як ми пройдемо настановний діалог, ми вже зможемо підключатися до сервера через 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

Якщо ліцензії успішно завантажилися, це відобразиться на їх кількості: Cisco Unified Communications Manager Administration -> System -> licensing -> lisence unit report

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

Звичайно, у великій організації, з великою кількістю серверів і з великим завантаженням, по хорошому, треба розподіляти ролі між серверами. Але практика показує, що залізо чудово несе всі функції одночасно, а утиліта Realtime Monitoring Tool (RTMT) дозволяє моніторити завантаження 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)

Крок 1 Перше що потрібно - це прикинути яку загальну кількість абонентів зараз і скільки буде в майбутньому. Скільки абонентів може бути в кожній філії.

Планування діалплану при використанні 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

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

У загальному випадку з партицією можуть бути асоційовані: ■ DNs ■ Route Patterns ■ Translation Patterns ■ Voicemail Ports ■ Meet-Me Conference Numbers

А що буде якщо ми включимо вMSK_Internal_CSS обидві партиціїPTR_PSTN_pt таMSK_PSTN_pt ? Вийде що при наборі 9 будуть доступні обидва шаблони і оскільки вони рівноцінні система надсилатиме дзвінки згідно з пріоритетом, в якому виставлені партиції в CSSMSK_Internal_CSS. Хоча подібна ситуація "розрулиться", слід уникати таких випадків перетину, оскільки це дуже складно дебагити.

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

Приклад схеми Partitioned Addressing

Потік даних під час дзвінка

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

Існують різні топології, у яких може працювати CUCM. Можна в кожен офіс поставити за кластером CUCM, можна в центральний поставити CUCM а в філії CUCME і т.д.