Для анализа трейсов прежде всего необходимо четко понимать что происходит внутри 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.
Далее начнётся установление звонка (CcSetupReq) и через цепочку RouteListControl > RoutelistCdrc будет выбрано устройство для выхода.

Также отметим здесь процесс Line Control: процесс отвечает за все DN-ы зарегистрированные в системе.

Итак, телефон начал звонить, пользователь поднял трубку, и следующим шагом у нас будет "поднятие" media или RTP потока.
Мы спускаемся на уровень ниже и передаём звонок на уровень Media Layer.

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

Как уже было сказано, на данном уровне располагаются процессы, отвечающие за установление RTP потока.

Тут также есть постоянно живущие процессы: ConnectionManager и MediaCoordinator.

Процессы MediaManager и MediaExchange создаются и уничтожаются вместе с вызовами. Они отвечают за все характеристики вызова между двумя абонентами: кодеки, DTMF.
Далее создаются процессы int или интерфейсы, которые взаимодействуют непосредственно с устройствами и отвечают за взаимодействие между Media Layer и Device Layer: передают устройствам кодеки, IP адреса, порты и др.

Рассмотрим случай, когда между телефонами не согласовались характеристики

Предположим совершается звонок с Телефона А на Телефон С.
Но в процессе установления соединения стало понятно, что телефоны не могут договориться с кодеком.
Для установления подобного соединения необходим транскодер.
Выделение транскодера обеспечат MediaManager и MediaExchage - они поймут какой транскодер необходимо использовать. Будет создан отдельный процесс MediaExchange или MX, который обеспечит согласование между первым телефоном и транскодером и между транскодером и вторым телефоном.
После того как разговор завершится, будут уничтожены все процессы, за исключением ConnectionManager и MediaCoordinator.

Идентификатор процесса PID

В SDI и SDL Traces каждый процесс обозначается определённым образом:

Process Type будет соответствовать типу процесса, т.е. для StationD это будет 37.
Process Instance - идентификатор процесса данного типа. В нашем случае "50" отражает что всего зарегано как минимум 50 телефонов и данный телефон 50-ый. Для Parent Processes это значение всегда Единица (1).

Таким образом данное обозначение процессов делает их уникальными и очень поможет нам в процессе анализа трейсов.

Итог по архитектуре CUCM

Рассмотрим звонок телефона А на Телефон B.

• На уровне Device Layer живут такие процессы как StationD, StationCdpc, отвечающие за взаимодействие непосредственно с телефоном.
• После обработки поднятия трубы на Device Layer, информация передаётся на уровень обработки звонка Call Control Layer, на котором живёт Digit Analysis - здесь происходят все трансляции, применяются соответствующие CSS и Partitions. Будет найден получатель, которому будет передан наш звонок. Параллельно будет запрос на Feature Layer на предмет необходимости форварда звонка для юзера B..
• CC Layer передаёт сообщение на Device Layer, но уже на процесс для телефона B. Телефон B зазвенит.
• У телефона B поднимают трубу и начинается установление Media. С помощью Connection Manager и Media Coordinator будут созданы процессы для согласования характеристик вызова между двумя телефонами: Media Manager и Media Exchange, которые будут общаться с телефонами через Interfaces.
• Начнется разговор между абонентами.

Используемые материалы: https://supportforums.cisco.com/ru/document/12689811