Подготовка за настройка на Call Manager CUCM от нулата (част 1)
Тази статия обсъжда кратка теория, както и практическите стъпки, необходими за подготовка за настройка на основна CUCM конфигурация, използвайки версия 8.5 като пример. Статията ще работи и за CUCM 6.x и 7.x, както и за всички по-късни версии 9.x и 10.x, които са много сходни.
CUCM - може да се инсталира по два начина:
- под формата на Уред, т.е. сървър под Linux с инсталирано приложение.
- като виртуална машина на същия Linux сървър.
Диалогов прозорец за настройка на CUCM
И така, кутии с Call Manager или CUCM оборудване са пристигнали. Обикновено се доставя под формата на клъстер. Клъстерът най-често включва два сървъра: - Publisher - на него се правят всички промени в конфигурацията - Subscriber - "изсмуква" копие на базата данни от Publisher. И двата сървъра трябва да се доставят предварително инсталирани със софтуер от кутията и когато ги включите, ще трябва да преминете през диалоговия прозорец „инсталация“.
За да върнете сървъра в това състояние преди инсталацията, трябва да го стартирате от инсталационния диск; след инсталиране на операционната система и след това рестартиране, сървърът ще бъде готов за диалоговия прозорец "инсталация". Ролята на сървъра (Издател/Абонат) се определя от този диалогов прозорец.
Инсталация на издателя
За повече информация вижте Инсталиране стъпка по стъпка на CUCM 8.x При въпрос Този сървър първи възел в клъстера ли е, отговорете с ДА
По време на диалога ще бъдете помолени за три пароли, които трябва да запишете и съхраните на сигурно място: - Администратор на платформата Използва се за достъп до SSH конзолата, системата за възстановяване след авария
- Потребител на приложението Използва се за достъп до 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 Администриране на унифицирана операционна система (https://ip_ad dress/cmplatform ) ■ Cisco Unified Reporting (https://ip_address/cucreports ) ■ Интерфейс на командния ред (CLI )
Инсталиране на CUCM лицензи Обикновено лицензът е pdf файл, в който ще намерим PAK номера
Ако лицензите са заредени успешно, това ще бъде отразено в броя на лицензите в: Cisco Unified Communications Manager Administration -> Система -> лицензиране -> отчет на лицензионната единица
Активиране на необходимите услуги Cisco Unified Serviceability -> Инструменти -> Активиране на услугата -> Изберете сървър Активирайте всички услуги там с изключение на Cisco Messaging Interface (използван за външни сървъри за гласова поща)
Разбира се, в голяма организация, с голям брой сървъри и с голямо натоварване е добре ролите да се разпределят между сървърите. Но практиката показва, че хардуерът перфектно изпълнява всички функции едновременно, а помощната програма RTMT (инструмент за наблюдение в реално време) ви позволява да наблюдавате натоварването на процесора и паметта.
Абонатна инсталация
Когато Абонатът е инсталиран, базата данни се репликира към него, така че Издателят трябва да го „познае“. За да влезетеСвързване на абонат с издател: SUCM Administration -> Система -> Сървър Изберете Добавяне на нов и въведете име.
По време на инсталацията въвеждаме подобни параметри - При запитване Този сървър първи възел в клъстера ли е - НЕ - Въведете данни Първи възел сървър
След инсталирането активираме всички налични услуги по същия начин.
Проверка на репликацията
За да проверим инсталацията на абоната, нека проверим репликацията на базата данни. Ако репликацията е наред, най-вероятно всичко останало също е наред.
Можем да разберем състоянието на репликацията от няколко източника:RTMT RTMT (инструмент за наблюдение в реално време) е много полезен инструмент не само за проверка на репликация, но и за много други задачи. В левия панел изберете Мениджър на повикванията, след това Резюме на базата данни. Интересуваме се от "статус на репликация" - ако стойността му е еднаква за всички възли, тогава всичко е наред.
Унифицирано отчитане на CUCM Унифицирано отчитане > Системни отчети > Състояние на унифицирана CM база данни > Генериране на нов отчет Ако всичко е наред, там трябва да намерим фразата Всички сървъри имат добро състояние на репликация
CUCM OS Admin CLI Издайте командата: admin:utils dbreplication status
Няма открити грешки или несъответствия. Състоянието на репликация е добро на всички налични сървъри.
И така, първоначалната инсталация е завършена. Сървърите са готови за работа и по-нататъшна конфигурация. От следващия етап настройките вече ще варират в зависимост от конкретните изисквания.
Разработване на план за набиране (DialPlan)
Стъпка 1 Първото нещо, което трябва да направите, е да оцените общия брой абонати сега и колко ще бъдат в бъдеще. Колко абонати могат да бъдат във всеки клон.
Планиране на диалплан с помощта на плоско адресиране Поради простотаот този тип и диалпланът също ще бъде прост. Всичко, което трябва да знаем, е да заложим на максималния брой на всички абонати. Например, ако имаме централен офис от 500 души и 20 клона по 100 всеки, тогава трябва да резервираме 2500 номера. Получаваме, че имаме нужда от четирицифрен диалплан, който осигурява до 10 000 номера, може да се направи по следния начин: 0XXX - запазен за достъп до града 1XXX - голям клон 1 2XXX - голям клон 2 3XXX - голям клон 3 4[0-4]XX- среден клон 1 4[5-9]XX- среден клон 2 51XX - Малък клон 1 52 XX - Малък клон 2 . 59XX - Малък клон 9 6XXX - За бъдещо развитие 7XXX - За бъдещо развитие 8XXX - За бъдещо развитие 9XXX - Запазено за градски достъп
Както се вижда при този тип диалплан, за системата няма значение кой номер в кой град ще се намира. Разпределението е само за удобство.
Планиране на диалплан при използване на разделено адресиране В този случай трябва да знаем максималния очакван брой абонати в един клон и максималния възможен брой клонове. Например, ако се очаква клонът да има не повече от 300 абонати и общо не повече от 20 клона: 0 - запазено за градски достъп [1-5]XX - вътрешно номериране [6-7]X - код на клон 8 - За бъдещо развитие 9 - запазено за градски достъп
Така едно вътрешно обаждане ще изглежда като трицифрено число [1-5]XX, а обаждането до друг клон като петцифрено число [6-7]X[1-5]XX
Раздели и пространства за търсене на извиквания
Как да се гарантира, че във всеки град при набиране на "9" повикването отива към собствения му локален шлюз? Как да внедрите припокриващо се номериране с разделено адресиране? Как да извършвате безплатни разговори отот един град до друг, без да плащате междуселищни, но използвайки вътрешната мрежа? Тук Partition и CSS идват на помощ.
По принцип даден дял може да бъде свързан с: ■ DNs ■ Модели на маршрути ■ Модели за превод ■ Портове за гласова поща ■ Номера за срещи с мен
Какво се случва, ако включим иPTR_PSTN_pt иMSK_PSTN_pt дялове вMSK_Internal_CSS ? Оказва се, че при набиране на 9 и двата шаблона ще бъдат налични и тъй като са еквивалентни, системата ще изпраща повиквания според приоритета, в който са зададени дяловете в CSSMSK_Internal_CSS. Въпреки че тази ситуация ще се "развали", трябва да избягвате такива случаи на пресичане, тъй като е много трудно да се отстранят грешки.
Структурата на дяловете и CSS трябва да бъдат внимателно планирани. Дори в малко предприятие можете необмислено да натрупате нещо, което ще бъде много трудно да разберете. Структурата на дяловете и CSS трябва ясно да съответства на диалплана.
Пример за схема на разделено адресиране
Поток от данни за обаждане
Централизирана топология
Има различни топологии, в които CUCM може да работи. Възможно е да инсталирате CUCM клъстер във всеки офис, можете да инсталирате CUCM в централния офис, а CUCME в клоновете и т.н.