При рассмотрении процесса инициализации будит использоваться топология:
 |
| топологии при внутрикластерном вызове |
Шаг 1
Если вы включили соответствующие опции на DHCP сервере (такие как опции 066 (имя TFTP сервера) или 150 (IP-адрес TFTP-сервера)), Cisco IP Phone отправляет запрос на инициализацию к DHCP серверу, для получения IP адрес, адрес DNS сервера и имя или адрес TFTP сервера. Он также получает адрес шлюза по умолчания, если вы включили эту опцию на DHCP сервере (опция 003).
Шаг 2
Если DHCP передает DNS имя TFTP сервера, вам понадобится IP адрес DNS сервера, для перевода имени в IP адрес. Этот шаг можно пропустить, если DHCP сервер передает IP адрес TFTP сервера. В данном примере DHCP сервер передает IP адрес TFTP потому, что DNS не настроен.
Шаг 3
Если ответ DHCP не включает в себя имя TFTP сервер, Cisco IP Phone использует имя сервера по умолчанию.
Шаг 4
Конфигурационные файлы (.cnf) находятся на TFTP сервере. Все .cnf файлы имеют имя формата SEP.cnf. Если телефон первый раз регистрируется на CUCM, по умолчания загружается файл SEPdefault.cnf. В этом примере, первый телефон Cisco IP Phone использует IP адрес 172.16.70.230 (его MAC address - SEP0010EB001720), а второй Cisco IP Phone использует IP адрес 172.16.70.231 (его MAC address - SEP003094C26105).
Шаг 5
Все .cnf файлы содержат IP адрес главного и вторичного CUCM. Cisco IP Phone использует этот IP адрес для соединения с главным CUCM и регистрации.
Шаг 6
После подключения телефона и его регистрации на CUCM, CUCM сообщает телефону о том, какую версию исполняемого файла нужно использовать. Если указанная версия не соответствует версии исполняемого файла на телефоне, телефон отправит новый запрос к TFTP серверу и автоматически перезагрузится.
CUCM процесс инициализации
В этом разделе объясняется процесс инициализации CUCM, с перехваченного traces от Unified CM1 (определяется по IP адресу 172.16.70.228). SDI traces представляет собой очень эффективный инструмент по поиску и устранению неисправностей потому, что он представляет детальную информацию по каждому пакету, пересылаемому между конечными точками.
Описываются события, которые происходят, когда инициализирован. Понимание того,как читать поможет правильно найти различные неисправные процессы и устранить влияние этих процессов на сервисы, такие как конференция и переадресация вызова.
Следующие сообщения, полученные утилитой SDI trace от CUCM показывает процесс инициализации на CUCM в данном случае, Unified CM1.
- Первое сообщение указывает, что CUCM начал процесс инициализации
- Второе сообщение показывает, что CUCM читает значения базы данных по умолчанию (в этом случае он является основной базой данных)
- Третье сообщение показывает, что CUCM принимает различные сообщения по TCP порту 8002
- Четвертое сообщение показывает, что после получение этого сообщения первичный (главный) CUCM добавляет вторичный CUCM в этот список (Unified CM2 172.16.70.229)
- Пятое сообщение указывает, что CUCM стартовал (это актуально начиная с версии Cisco Unified Communications Manager 3.1(1))
16:02:47.765 CCM|CMProcMon - Communications ManagerState Changed - Initialization Started. 16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CCMDatabase Defaults Read 16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002] 16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229] 16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3 .1=""> started
Self-Starting
Processes
После того, как CUCM загрузился и работает,он стартует несколько других своих процессов. Некоторые из этих процессов выполняют в том числе MulticastPoint Manager, UnicastBridge Manager, digit analysis, and route list. Вы увидите, что сообщения, которые получены в ходе этих процессов очень полезны при устранении проблем, которые относятся к функциям CUCM. Например,предположим, что route list не работает и настроен не правильно. Для решения этой проблемы, вы можете просмотреть traces, чтобы определить запустил ли CUCM RoutePlanManage и пытается ли он загрузить RouteLists. Следующий простой пример показывает, что RouteListName=''ipwan'' and RouteGroupName=''ipwan'' загружены и запущены.
16:02:51.031 CCM|MulicastPointManager - Started 16:02:51.031 CCM|UnicastBridgeManager - Started 16:02:51.031 CCM|MediaTerminationPointManager - Started 16:02:51.125 CCM|MediaCoordinator(1) - started 16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started 16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started 16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started 16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists 16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists 16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups 16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan 16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order 16:02:51.671 CCM|RouteList - RouteListName=''ipwan'' 16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan'' 16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order 16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''
Следующий trace показывает RouteGroup, к которому добавляется устройство Unified CM3 с адресом 172.16.70.245, который расположен в Cluster 1 и считается H.323 устройством. В этом случае RouteGroup производит маршрутизацию вызовов к Unified CM3 в кластер1 с разрешения Cisco IOS Gatekeeper. Если проблемы возникают, когда вызов передается к Cisco IP Phone, который расположен в Cluster 1, следующие сообщения помогут вам найти причину проблемы.
16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245'' 16:02:51.671 CCM|RouteGroup –AllPorts
Часть процесса инициализации показывает, что CUCM добавляет DNs (абонентские номера). Просмотрев это сообщение, вы можете определить, прочитал ли CUCM абонентский номер из базы.
16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started 16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = ,RouteThisPattern, NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause = 16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1 16:02:51.859 CCM|ForwardManager - Started 16:02:51.984 CCM|CallParkManager - Started 16:02:52.046 CCM|ConferenceManager - Started
Следующий traces показывает, что Device Manager в CUCM производит статическую инициализацию двух устройств. Устройство с IP адресом 172.17.70.226 является gatekeeper, и устройство с адресом 172.17.70.245 получает другой CUCM в другом кластере.
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226 16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245
P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.
Комментариев нет:
Отправить комментарий