Call Manager CUCM - это центральный элемент комплекса IP телефонии. Если вам порекомендовали или вы пришли к выводу что вам нужен CUCM, то у вас весьма крупная (и богатая) организация для которой необходима сложная и надёжная компьютерная или телефонная сеть.
В первой части Настройка Call Manager CUCM с нуля: подготовка (Часть 1) мы рассматривали все что необходимо для подготовки перед разворачиванием
В второй части "CUCM с нуля" обсуждаются практические шаги, т.е. что необходимо настроить чтобы зазвонили цифровые телефоны под управлением Call Manager.

Рассмотрим практический пример со схемой представленной ниже:

Мы соединим единой телефонией два офиса в Москве и в Питере.

В сети московского офиса в наличии коммутатор c2950, на котором будут созданы два VLAN-а для компьютеров и телефонов; маршрутизатор с2951, задача которого в маршрутизации пакетов 3-го уровня между VLAN-ами; телефоны + компьютеры пользователей.
И, конечно же, кластер CUCM, представляющий по сути две отдельных машины, каждая из которых подключена к своему порту, имеет свой IP и т.д.

Dial-Plan

В первой части Настройка Call Manager CUCM с нуля: подготовка (Часть 1) мы подробно рассматривали выбор и построение диалплана.
Выберем для нашего случая плоский (Flat) диалплан со следующей нумерацией:
0ХХХ - Для будущего развития
1ХХХ - Московский офис
2ХХХ - Питерский офис
3XXX - Для будущего развития
4XXX - Для будущего развития
5XXX - Для будущего развития
6XXX - Для будущего развития
7XXX - Для будущего развития
8XXX - Для будущего развития
9Т - Зарезервирован для выхода в город

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

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

(1) Настройка Voice VLAN

Вообще с некоторых пор существуют понятия Voice VLAN и DATA VLAN. С точки зрения настроек отличия между ними заключаются только названием.
Cisco рекомендует помещать телефоны в отдельный VLAN. Это продиктовано тем, что войсовый трафик очень "прихотлив" а разделение позволит как можно меньше "задевать" трафик между телефонами, упростить QoS-маркировку пакетов (если такая понадобится), да и вообще упростить настройки и жизнь инженеру.
Надо сказать, что телефоны прекрасно будут работать и в том же ВЛАН-е что и компьютеры и даже на каком-нибудь "левом" коммутаторе, но поиск проблем (и вероятность в их возникновения) будет значительно усложнен.

Мы создадим два VLAN-a:
VLAN 10 для компьюетров
VLAN 20 для телефонов
Собственно VLAN 20 и будет называться как Voice VLAN.

Т.к. у коммутатора кофигурация отсутствовала, минимальные настройки:
hostname c2950
vtp mode transparent

Создадим VLAN-ы
vlan10
name comp

vlan 20
name voip

Настроим порты коммутатора для телефонов:
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport voice vlan 20
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport voice vlan 20
spanning-tree portfast

По сути при такой настройке между портом и телефоном поднимается транк, т.е. через одно соединение идет трафик обоих VLAN-ов.

На рисунке видно, что трафик компьютера, т.е. VLAN 10 никак не тагируется и передается компьютеру, при этом телефон работает как обычный коммутатор.
Трафик VLAN 20 же тагируется. Это позволяет в одном линке пересылать фреймы обих VLAN-ов.
Телефон Cisco "узнает", что голосовым VLAN-ом является VLAN 10 через CDP, делая на коммутатор запрос voip vlan query.
Что получится если на порту отключить CDP? Телефон окажется в том же VLAN-е что и компьютер и получит адрес и компьютерной подсети.
Кстати если цисковский телефон будет подключен через какой-нибудь Dlink, т.е. без VLAN-ов, он также попадет в ту же подсеть что и компьютер, только будет подольше загружаться из-за таймаутов CDP.

Маршрутизатор в данной схеме является шлюзом по умолчанию для обоих подсетей. Поэтому соединение маршрутизатора и коммутатора будет транковым

Настройки коммутатора:
interface FastEthernet0/24
switchport mode trunk

Настройки порта маршрутизатора:
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/0.10
description Comp
encapsulation dot1Q 10
ip address 10.0.10.1 255.255.255.0
!
interface GigabitEthernet0/0.20
description voip
encapsulation dot1Q 20
ip address 10.0.20.1 255.255.255.0

Прочие настройки: настроим на коммутаторе IP адрес и доступ
interface Vlan10
ip address 10.0.10.5 255.255.255.0

aaa new-model

username admin privilege 15 password 0 adm

line vty 0 4
privilege level 15

enable secret 0 adm
service password-encryption

Аналогичные настройки дадим на c2951
aaa new-model
username admin privilege 15 password 0 adm
ip http secure-server
ip http authentication local

line vty 0 4
privilege level 15

enable secret 0 adm
service password-encryption

Таким образом, на данном этапе маршрутизатор уже должен успешно пинговать адрес коммутатора:

Если подключить телефон, то он конечно включится, но будет отображать "Phone not Registered".
У него еще нет IP настроек, которые он должен получить от сервера DHCP.

Мы в этом кстати можем убедиться, заглянув в сам телефон и выбрав Phone Information - там поле IP адреса будет пустым.
Также можно на коммутаторе дать команды:
show cdp neighbors
show cdp entry

Проверка кластера

Первоначальная настройка серверов CUCM описана в первой части Настройка Call Manager CUCM с нуля: подготовка (Часть 1).
Мы же на всякий случай проверим все ли в порядке:
- Проверим сетевые настройки.
Применительно к нашей схеме, кластер будет находиться в VLAN 10, т.е. в сети компьютеров. Как было сказано в первой части, трафик между CUCM и телефонами есть трафик сигнальный и его приоритет не наивысший как для телефонов. Поэтому с точки зрения сети CUCM следует размещать как сервер.
Сетевые настройки мы можем посмотреть здесь:
Cisco Unified Operating System Administration (https:/cmplatform) > Show > Network
Нас тут интересуют правильность параметров:
IP Address
IP Mask
Gateway
DNS Primary
DNS Secondary
Domain

Также еще откроем страницу:
Cisco Unified Operating System Administration (https:/cmplatform) > Show > Cluster
Сервера DNS должны уметь разрешать имя hostname в адрес на этойже странице IP Address как с суффиксом, так и без него, - проверьте nslookup-ом.
Эти же DNS сервера должны быть прописаны на всех компонентах комплекса телефонии включая телефоны, шлюзы, конферц станции и т.д.

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

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

CUCM Unified Reportingg
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.

Наконец следует просмотреть общий Report по кластеру:
Cisco Rnified Reporting > Unified CM Cluster Overview
Отчет содержит комплекс проверок параметров кластера: везде должны быть зеленые флажки.

Замена имен нодов на IP адреса

По умолчанию, после установки машина CUCM представлена как имя, но не IP адрес. Использование имен подразумевает использование DNS серверов.
Cisco рекомендует не использовать DNS в работе с CUCM, поскольку (дословно) "позволяет телефонам не обращаться к DNS серверам для разрешения имени в адрес".

Использование IP адресов позволит избавиться от некоторой задержки при разрешении DNS-запроса при каждом звонке и при обращении к TFTP.
Работает и так и так, в новой инсталляции имен имеет смысл избавиться от имен. Имеет ли смысл трогать инсталляцию старую? - это скорее на страх и риск администратора.

Процедура перехода на адреса не сложна:
1) CUCM Administration > System > Server
2) Выбираем сервер и меняем его имя в поле Host-name/IP Address на соответствующий IP адрес. Сохраняемся и выполняем тоже самое для всех серверов.
3) System > Enterprise Parameters > Phone URL Parameters
В каждом поле находим URL и меняем в нем имя на соответствующий IP адрес.

Enterprise Phone Configuration

Это глобальные настройки для телефонов, которые имеет смысл посмотреть и при необходимости под себя поправить, но только в том случае ели это действительно глобально. Лучше подобные настройки выставлять на уровне Common Phone Profile.
К ним относятся например включать ли на телефоне порт USB , или когда включать подсветку экрана.
System > Enterprise Phone Configuration

Эти параметры можно "перекрыть" на уровне более приоритетных настроек. Их приоритеты следующие:
1) Device Configuration window settings
2) Common Phone Profile window setting
3) Enterprise Phone Configuration

Правка некоторых Service Parameters

Service Parameters в отличие от Enterprise Parameters влияют не на предприятие в целом, но на определённый сервис на определённом сервере.
По умолчанию некоторые важные параметры не соответствуют рекомендованным значениям. Мы это исправим:

T302 Timer
Это таймаут между цифрами когда мы набираем номер телефона. Например когда набираешь номер и обновременно проверяешь правильно ли все набрал - нужно чтобы таймаут дал время. А когда набираешь международный номер, то в конце набора нужно выждать полностью, чтобы номер попал на дальнейшую обработку.
По умолчанию таймаут равен 15 секунд.
Лучшие практики рекомендуют уменьшить до 10 секунд.
- Cisco Unified CallManager Administration > System > Service Parameters
- Выбираем соответствующий сервер Call Manager
- Выбираем сервис Cisco Call Manager
В строке T302 Timer выставляем 10000
То же самое проделываем на всех серверах кластера.

Включение генерации CDR/CMR
CDR/CMR - это файлы, который затем могут быть использованы для учета звонков
Включение CDR
- Cisco Unified CallManager Administration > System > Service Parameters
- Выбираем соответствующий сервер Call Manager
- Выбираем сервис Cisco Call Manager
- Выставляем system parameter CDR Enable Flag to True
- Выставляем CDR Log Calls with Zero Duration Flag to True (если нужно логировать неудачные или звонки с длительностью менее 1с)
То же самое проделываем на всех серверах кластера.

Включение CMR
- Cisco Unified CallManager Administration > System > Service Parameters
- Выбираем соответствующий сервер Call Manager
- Выбираем сервис Cisco Call Manager
- Выставляем Call Diagnostics Enabled parameter to Enabled Only When CDR Enabled Flag Is True
То же самое проделываем на всех серверах кластера.

Codec
Это настройки кодеков по умолчанию внутри региона и между регионами.
- Cisco Unified CallManager Administration > System > Service Parameters
- Выбираем соответствующий сервер Call Manager
- Выбираем сервис Cisco Call Manager
- Выставляем Intraregion Audio Codec Default G911/722
- Выставляем Interregion Audio Codec Default G911/722

Создание группы серверов для redundancy.

Cisco Unified CM Group - это группа нодов, в которой ноды расставлены в порядке приоритета.
Группа вешается на Device pool, а затем на телефон. При регистрации телефон использует приоритетный первый нод в группе.
Можно создать несколько групп с разными нодами и в разной последовательности этих нодов, - таким образом мы обеспечим redundancy, а также load balancing.
Заморачиваться насчет load balancing циска рекомендует при количестве телефонов более 7500. (источник CIPT1)

System > Cisco Unified CM Group
Переименовываем дефолтную группу и включаем в нее второй node

После этого в свойствах телефона мы сможем увидеть Active server и Stand by server

Настройка DHCP сервиса

В качестве DHCP сервера можно сделать сам CUCM, маршрутизатор Cisco или использовать сервис DHCP из Windows.
Сервис DHCP из Windows
Здесь мы создаем Scope как обычно, единственное, нужно добавить дополнительную опцию:
Щелкаем правой кнопкой на имя сервера и выбираем Set predefined Options

Далее добавляем опцию как на скриншоте.
В качестве значений указываем IP адреса севреров кластера CUCM:

После этого в Scope мы сможем добавить эту опцию:

CUCM как DHCP
CUCM как DHCP способен работать максимум с 1000 клиентами.
Идем в Cisco Unified Communications Manager Serviceability > Tools > Service Activation
Активируем сервис DHCP Monitor Service

Выполняем необходимые глобальные настройки:
Cisco Unified Communications Manager Administration > System > DHCP Server Configuration

Настраиваем DHCP subnet:
Cisco Unified Communications Manager Administration > System > DHCP Subnet Information

DHCP на маршрутизаторе
Маршрутизатор также может выступать в роли DHCP сервера.
Его конфигурирование можно посмореть в статье Настройка CUCME с нуля: основные настройки (Часть 1)

Настройка NTP

Настройка точного времени необходима в работе множества сетевых сервисов.
В среде CUCM точное время необходимо для следующих служб:

• Время отображаемое на экране телефонов
• Время в отчётах звонков Call Deatail Records
• Системные логи и события
• Время может использоваться в маршрутизации звонков (Time of Day Routing)

В большой сети и при большом количестве устройств имеет смысл синхронизировать минимум одно (рекомендуется 3) устройства с источниками извне, а все остальные (В том числе и CUCM) в свою очередь синхронизировать с мастерами.
В качестве главных устройств обычно делают маршрутизатор или контроллер домена.
В статье Настройка NTP на устройствах Cisco описываются необходимые настройки для маршрутизатора, чтобы он стал мастером NTP.

Cisco Unified Operating System Administration > Settings > NTP Servers
Здесь рекомендуется прописать минимум три внешних NTP сервера, причем первый из них должен быть stratum1.
К этим NTP серверам будут обращаться сервисы CUCM, причём только Publisher обращается к внешним серверам NTP. Subsribers, в свою очередь синхронизируются с Publisher.

Phone NTP Reference

CUCM Administration > System > Phone NTP references
Phone NTP Reference - это сервера NTP, куда будут обращаться SIP телефоны для синхронизации часов. Это не относится телефонам SCCP которые свое время синхронизируют в сообщениях SCCP.

Кстати Cisco SIP-телефоны тоже умеют синхронизироваться по SIP, используя ответ CUCM "200 OK" (там есть временной штамп), но прибегают к этому способу только в случае недоступности Phone NTP Reference.

Создание Partitions и CSS

Партиции и CSS мы создаем согласно нашему плану.

Создание Partitions:
Call routing > Class of control > partitions
При создании партиции ничего кроме названия не нужно.

Создание CSS:
Call routing > Class of control > Calling Search Space
Тут тоже никаких особых настроек нет: даем имя, и включаем в CSS другие партиции как в группу.

Date/Time Group Configuration

Организация CUCM может быть разнесена по всей стране и значит по разным часовым поясам.
Date/Time groups определяют временные зоны для устройств подключенных к CUCM.
Cisco Unified CM Administration > System > Date/Time Group

Обратите внимание, по умолчанию после установки будет только группа CMLocal.
CMLocal синхронизирует время для OS CUCM. Не переименовывайте имя группы по умолчанию CMLocal.

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

Configure regions

Как уже упоминалось, во время звонка между телефонами устанавливается сессия RTP.
Голосовой поток может кодироваться с различной степенью сжатия, что напрямую влияет на требуемую пропускную способность канала данных.
Степень сжатия определяется типом кодека (codec). В системе CUCM в основном используются два типа кодеков:
G711 - сжатия нет, требует 64кбит/с на звонок.
G729 - сжатие есть, требует 8кбит/с на звонок.
Regions позволяет выбрать в каком направлении использовать какой кодек.
Например можно сделать так чтобы внутри офисов использовался G711, а между ними G729.

Каждый Region настраивается на определённый кодек следующим образом:
- Кодек внутри данного Region
- Кодек на определённый сторонний Region
- Кодек на все остальные регионы

Забегая вперёд, Region навешивается на Device pool, а Device pool навешивается на конечные устройства.
Если два устройства пытаются созвониться, конечным используемым кодеком будет кодек:
- Поддерживаемый обоими девайсами
- Не превышающий по своим характеристикам параметры, выставленные в обоих регионах. Например если у одного 711, а у другого 729, то будет выбран 729.
Если устройства не смогли договориться с кодеком, запускается Transcoder.

Надо отметить (IMHO), что на практике качество разговора G729 сильно проигрывает G711, также могут появиться проблемы с передачей факсов и с тональным набором (DTMF), и в то же время 64кбит по современным меркам не проблема. Даже в самом захолустье в России подают минимум 2мбит, и проблем возникает больше из-за потери пакетов, нежели со скоростью, а в случае с G.729 потери пакетов еще более губительны. Поэтому смысл играться с кодеками появляется разве что при использовании спутниковой связи, где имеются специфические требования.

Исходя из этих соображений сделаем дефолтный кодек G711:
- Идем System > Service Parameters
- Выбираем сервер Call manager
- Выбираем сервис Cisco CallManager (Active)
- Находим Clusterwide Parameters (System - Location and Region) и выставляем параметры:
Intraregion Audio Codec Default G711/G722
Interregion Audio Codec Default G711/G722

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

Таким образом при звонке в регион "CMET-region" ,eltn bcgjkmpjdfnmcz 729 кодек. В остальные же будет использоваться дефолтный 711.

Configure locations

Locations - это часть Call Admission Control.
Call Admission Control позволяет контролировать использования полосы пропускания, или проще говоря количество одновременных звонков.
Если у нас пропускания способность канала 150Кбит/с, понятно, что 10 одновременных звонков G711 не поделят пропускную способность, и все они начнут "квакать". Мы можем настроить locations так, что через этот канал будут проходить одновременно только один звонок, а при попытке позвонить пользователь услышит "занято".

Как уже говорилось, для разных кодеков требуется разная пропускная способность. (G711 - 64kbit/s, G729 - 8kbit/s).
Но на практике же внутри канала провайдера часто строят VPN, в результате чего на каждый пакет увеличивается нагрузка из-за заголовков GRE и IPSec. Голосовые пакеты очень малы (особенно у сжатых кодеков), и размер заголовка сопоставим с размером полезной информации.
Не вдаваясь в подробности, если у вас между офисами поднят IPSec VPN, реальная нагрузка на один звонок будет следующей:
G.729 - 54,400 bits per second
G.711 - 112,000 bits per second

Например пусть у нас у Питера есть канал на 1024кбит, а у Москвы 10Мбит.
Значит результирующая скорость между ними будет 1024кбит. Для 5-ти звонков нам понадобится:
112,000 bits per second * 5 = 560 000 bits per second или 560 kbits per second
Т.е. этот трафик мы можем приоритезировать, а остальной трафик можно отдать на неголосовой трафик с низшим приоритетом. Впрочем это уже задача построения QoS и тема другой статьи.
Хотя тут стоит отметить что QoS будет работать в выделенной линии, с гарантированной пропускной способностью, например в услуге IPVPN или VPLAN. В российских же реалиях, где-нибудь в глубинке хорошо если из 4мбит в договоре будет "чистый" 1мбит. Лучше всего перенаправить трафик через туннель на центральную проксю и контролировать его утилизацию средствами QoS в этом туннеле - в этом случае нужен хороший канал в центральном офисе. Можно использовать полисинг см Ограничение интернет-трафика пользователей, но это менее эффективно, т.к. мы не можем контролировать входящий трафик: торренты и UDP могут забить всю полосу.

Итак, мы расчитали что 5 звонков займут 560kbit/s, это вполне "влазит" в канал 1мбит, больше и не надо, ибо мало ли чего..

Теперь мы ограничим количество звонков между Питером и Москвой максимом до 5-ти - идем:
CM Administration > System > Location
Создаем две location PTR_location и Moscow_location
В PTR_location Audio Banwidth нужно выставить на 64kbps * 5 = 320kbps
Да, в настройках CUCM мы вводим "чистый" bandwidth для кодека G711, Call Manager не "волнует" последующие шифрования и инкапсулирования пакета.

Для проверки работы нелишним будет мониторить качество связи, см. статью Мониторинг качества связи с помощью технологии IP SLA

Настройка SRST Reference

SRST (Survivable Remote Site Telephony) - позволяет маршрутизатору в филиале обрабатывать звонки в то время как главный CUCM оказался недоступным.

В нашем случае SRST понадобится для Питера:

Если кратко, это работает следующим образом: телефон при загрузке получает конфигурацию, в том числе и настройки SRST, а по сути IP адрес SRST-маршрутизатора. При сбое связи с CUCM телефон регистрируется на SRST-маршрутизаторе. Маршрутизатор берет конфигурацию с телефонов и программирует сам себя. Благодаря этому не нужно вбивать в его конфиге DN-ы и Phone. В результате телефоны будут способны звонить друг другу звонить в город и принимать звонки из города, используя SRST-маршрутизатор.

Настройка Device pools

Мы настроили CUCM Group, Date/Time Group, Regions, Location - все эти настройки объединяет в себе Device pool, т.е. общие настройки можно собрать вместе в Device pool и повесить на телефон.
Device pool "одевается" в свою очередь на конечное устройство.
Device pool содержит настройки "device-related" и "location-related".

Подобно Device poolк телефону может привязываться еще и Common Device Configuration.
Common Device Configuration в себе собирает можно сказать User oriented information, такие как softkey template, locale, User Hold MOH Audio Source и т.д. Это необязательно, но может понадобиться при большом количестве пользователей.

Тогда как Device pool привязан к конкретному месту, их создают например для Питера и Москвы: Piter_pool, MSK_pool.
Common Device Configuration привязывается к пользователям, их группе. Например для секретарей можно создать Secretar_cdc и на нее повесить Русскую User Locale, а также Softkey template Standard Assistant

Мы создадим Moscow_pool и Piter_pool:
Cisco Unified CM Administration > System > Device Pool
В свойствах каждого пула мы вводим соответствующие:
Cisco Unified Communications Manager Group
Date/Time Group
Region
Location
SRST Reference

Еще кстати возможно понадобится выставить Media Resource Group List.
Для пользователя это окажется актуально для создания конференций, т.е. чтобы при попытке создания HW конференции, она создавалась на локальном маршрутизаторе (conference Bridge), а также грамотно расставить приоритеты.
Подробнее см. Работа с медиа-ресурсами: конференции Meet-Me и Ad-Hoc

Настройка Autoregistration

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

Cisco Unified CM Administration > Sysem > Enterprise Parameters
Здесь мы выставляем Auto Registration Phone Protocol как SCCP.

Далее: Cisco Unified CM Administration > System > Cisco Unified CM Group
Ставим галку Auto-registration Cisco Unified Communications Manager Group

Cisco Unified CM Administration > System > Cisco Unified CM

Вводим диапазан и партицию.
Кстати имеет смысл для этого завести специальную "временную" партицию как в примере REMO_phones_pt. Она также пригодится в случае если понадобится отключить какой-нибудь pattern: вместо того чтобы его удалять, достаточно перенести его во временную партицию, и он перестанет влиять на "боевую".

Подключение телефона

У нас все готово для подключения телефона.
Новый телефон должен автоматически зарегистрироваться и на нем должны появиться число, время, номер и тд.
В CUCM появится его запись:
Cisco Unified CM Administration > Phones
Время загрузки телефона 1-2 минуты. Возможно предварительное закачивание новой прошивки от CUCM, если телефон начал что-то качать значит как минимум он "увидел" Call Manager.

Если на телефоне долгое время высвечивается "Phone not registered" придется разбираться в чем дело:
Сперва начните с того чтобы сбросить настройки телефона на дефолтные, для этого на телефоне выбираем:
Admin settings > Reset settings > All

При включении телефон должен получить IP адрес. Это можно проверить с самого телефона:

Если адрес не получен - проблема чаще всего в DHCP, настройке VLAN helper-address.
По этому IP адресу можно зайти непосредственно на телефон по http.
Там наиболее ценна страница "Network Settings". Если телефон не регистрируется тут нужно проверить правильно ли выставлен шлюз, tftp сервер.
CUCM должен пинговать телефон, проверить это можно:
Cisco Unified OS Administration > Services > ping
Проверьте работу DNS, должны разрешаться (имя в адрес и адрес в имя) имена нодов CUCM с доменным суффиксом и без.
Также известны случаи связанные со старой прошивкой телефонов: если у телефона версия прошивки ниже 9.0.3-b, может быть этот случай ваш.

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

Заведение пользователя

Для нормальной работы учета звонков для каждого телефона необходимо завести пользователя, также продвинутые юзера получат возможность работать в своем web интерфейсе, где могут редактировать свою тел книгу, производить звонки и самостоятельно настривать перенаправление.
Строго говоря телефон будет работать и без пользователя, но лучше сделать все "по правильному", чтобы в дальнейшем было минимум головной боли.
- Заходим на страницу User Management -> End User -> Add New, заполняем следующие поля:
o User ID: izolotov (первая буква имени и фамилия)
o Password для удобства ввести цифрами. может совпадать с PIN
o PIN
o Last name: Zolotov
o First name: Ivan
o Telephone Number: 2101 (этот номер будет отображаться в адресной книге)
o Department: Piter dep (название отдела латиницей)
o Нажимаем Save
o После этого необходимо включить пользователя в группу: нажимаем Add to User Group – в появившемся окне выбираем группу Standard CCM End Users и нажимаем кнопку add selected
o Нажимаем Save

Настройка телефона

Итак, наш телефон зарегистрировался и получил номер из пула авторегистрации.
Идем
CUCM Admin > Device -> Phone –> Найти

- На данной странице отображаются все телефоны организации. Новый телефон можно найти по его номеру 4XXX, для этого можно воспользоваться поиском, Например, если на телефоне отобразился номер 4077, то мы выберем:
Найти phone по условию: Directory number
Начинается с: 4077
Жмем кнопку найти

- Зайдем в его свойства щелкнув на имя телефона и заполним следующие поля на примере Питера:
o Description: 2101 -- Piter -- Ivan Zolotov
o Device pool: Piter_pool
o Common Phone Profile: Standard Common Phone Profile
o Media Resource Group List: PTR_rgl (если не выставлено на уровне Device pool)
o Calling Search Space: PTR_internal_CSS
o Location: PTR_location
o User Locale: Выставляем язык интерфейса
o Owner User ID: izolotov (Только что заведенный нами пользователь)
o Жмем Save, затем для применения параметров Apply. При этом телефон перезагрузится

o На той же странице слева вверху щелкнем “Line 1” и зайдем в свойства линии и заполним следующие поля:
 Directory Number: 2101
 Route Partition: Oncluster_pt
 Alerting name: 2101 Ivan Zolotov
 ASCII Alerting name: 2101 Ivan Zolotov
 Description: 2101 -- Piter -- Ivan Zolotov
Собственно таким образом от Петрова будет отображаться на телефоне другого абонента
 Calling Search Space: PTR_internal_CSS
 Display (Internal Caller ID) 2101 Ivan Zolotov
 ASCII Display (Internal Caller ID) 2101 Ivan Zolotov
 Line Text Label 2101 Ivan Zolotov
 ASCII Line Text Label 2101 Ivan Zolotov
 Нажимаем Save (без этого не появится кнопка Associate end users)
 Users Associated with Line – выбираем заведенного пользователя
 Нажимаем Save – Apply

- Ассоциируем пользователя с телефоном в свойствах пользователя:
User Management -> End User -> Найти
Заходим в свойства пользователя izolotov
Device Associations – находим телефон и добавляем его

После всех этих настроек мы сможем звонить с одного телефона на другой.

Мы рассмотрели настройки CUCM, которые необходимы для того чтобы зазвонили телефоны.
В следующей статье мы обсудим вопросы организации маршрутизации, связь с внешним миром, настройку шлюзов H323, MGCP и SIP.
Предыдущая статья по теме: Настройка Call Manager CUCM с нуля: подготовка (Часть 1)

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