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

CUCM это приложение, написанное на языке C++ и функционирующее в ОС Red Hat.

Внутри приложения функционируют C++ Objects или SDL Processes (Signal Distribution Layer). Все эти объекты функционируют и взаимодействуют между собой.
Часть объектов существуют всегда, часть объектов создаются и уничтожаются при необходимости.

Все SDL Processes можно разделить на несколько логических уровней:

1. Feature Layer - отвечает за Transfer, Forward и другие подобные функции.
2. Call Control Layer - уровень полностью отвечает за установление вызовов и обработку всех звонков внутри CUCM.
3. Media Control Layer
4. Device Layer

Как видно из схемы, помимо перечисленных уровней присутствуют также Aggregator Layer и Link Layer.
Aggregation Layer в контексте наших задач рассматривают вместе с Call Control Layer
Link Layer же отвечает за сетевое взаимодействие на уровне TCP UDP и нас вовсе не интересует.

Классификация процессов CUCM

Мы рассмотрим классификацию процессов CUCM на примере уровня Feature Layer.

• Parent Processes - Процессы, которые живут в системе постоянно, такие процессы создаются вместе с запуском приложения Call Manager: Transfer Manager, Forward Manager, Conference Manager, Recording Manager. Эти процессы будут отвечать за ВСЕ конференции, форвардинги в системе.
• Child Processes - это процессы, создаваемые при выполнении определённой операции. Например при выполнении операции Forward будет создан подпроцесс Forwarding, который будет жить пока операция форвадирга не будет завершена, т.е. после перевода он будет уничтожен.

Процессы уровня Device Layer

• Edge Processes - процессы, отвечающие за один сигнальный протокол внутри CUCM. Данные процессы относятся к классу Parent Processes и на каждом ноде их существует лишь по одной штуке. Например, если у нас есть 50 SCCP телефонов, то все они будут взаимодействовать с единственным процессом StationInit.
  • StationInit (SCCP)
  • SIPHandler (SIP)
  • H225Handler (H323)
  • MgcpHandler (MGCP)
  • MgcpBhHandler (MGCP PRI)
• Control Processes - таких процессов может быть несколько одного вида. Например для каждого зареганного SCCP телефона будет создан свой процесс StationD, предназначенный для контроля этого телефона, т.е. для 50-ти SCCP телефонов будет создано 50 процессов StationD.
  • SipStationD
  • SIPD
  • StationD

В случае с 20-ю телефонами SIP на ноде будет создан один процесс SipHandler, промежуточный процесс SipStationInt, и 20 штук процессов SipStationD. Для SIP Trunk используется процессы SIPD - каждый для своего транка.

Рассмотрим теперь что происходит когда юзер поднимает трубу:
В этом случае телефон передаёт сообщение CUCM, и далее происходят события: StationInit передаёт сообщение процессу телефона StationD. И далее StationD создаст процесс StationCdpc. Процесс StationCdpc отвечает за один звонок с определённого телефона (С(all)D(ependent)), и будет уничтожен если положить трубу на рычаг.

Аналогично, если телефон выключить и пропадёт его регистрация - будет уничтожен его процесс StationD.

Процессы уровня Call Control

Для обработки введённого на телефоне номера в работу вступают процессы другого уровня - уровня Call Control.
Процессы данного уровня участвуют в установлении вызова и в обработке этого вызова:

• Call Control (CC) - отвечает за все звонки, проходящие через данную ноду CUCM, 1 процесс на ноду
• Call Dependent Call Control (CdCc) - отвечает за один звонок. Каждый новый звонок порождает подобный процесс.
• DA - Digit Analysis: здесь происходят все трансляции, применяются соответствующие CSS и Partitions, и определяется направление куда отправить данный звонок. Здесь также система понимает разрешен данный звонок или нет.
• Device Manager (DM) - содержит таблицы со всеми устройствами, подключёнными к данному кластеру CUCM (телефоны транки, шлюзы, Route lists). DM позволяет определить куда в конечном итоге отправить звонок физически.
• Line Control - процесс отвечающий за все DN, зарегистрированные в системе

Давайте посмотрим как будет обрабатываться звонок пошагово:
Call Control (CC) создаёт под данный звонок отдельный процесс Call Dependent Call Control (CdCc). На этот процесс будет переданы набранные цифры.
Для обработки звонка CdCc передаст на обработку номера в DA, где произойдут необходимые трансляции и будут определены привилегии для данного звонка.
Далее звонок отдаётся на Device Manager (DM), где будет определено устройство на которое необходимо передать наш звонок.
Информация от DM возвращается на DA и затем на CDCC.
Далее начнётся у�