Типы Call Information Records

В этой главе описывается два типа call information records, генерируемые CUCM

CUCM генерирует два раздельных типа call information records: Call Detail Records (CDR) и Call Management Records (CMR), их также называют диагностические записи вызова. CDRs предоставляет информацию о конечных точках вызова и других аспектах вызова контроль/маршрутизация. CMRs содержит диагностическую информацию о качестве аудио потока вызова. CDR запись может содержать более одного CMR.

CMRs поддерживаются Cisco IP Phones, телефонами серии Cisco 7960 и шлюзами MGCP. Если одна из этих конечных точек принимает участие в вызове, будут сгенерированы CMR записи после завершения вызова.  Каждая конечная точка в вызове создает отдельную CMR запись. Если в вызове участвуют конечные точки, которые не поддерживают диагностику вызова, записи не будут генерироваться для этих конечных точек. Вызов от Cisco 7960 phone к H.323 шлюзу будит генерировать одну CMR запись (от Cisco 7960 phone.)

CDRs с CMRs имеет две общие колонки globalCallID: globalCallID_callManagerId и globalCallId_callId.

Когда параметр Call Diagnostics установлен в True, система генерирует до двух CMRs для каждого вызова. Каждый тип вызова, такой как конференцсвязь, переадресация вызова, переадресованный вызов и вызов, с использованием шлюза, производят множество записей в тестовый (ASCII) файл в конце вызова. CUCM не выполняет никакую постобработку CDR или CMR.

Global Call Identifier (Глобальный идентификатор вызова)

CUCM назначает глобальный идентификатор вызова (GlobalCallID_callId) каждый раз, когда на Cisco IP Phone поднимается трубка или вызов принимается со стороны шлюза. GlobalCallID_callId  назначается последовательно на сервере CUCM, независимо от вызовов работающих (происходящих) на других серверах кластера.  Для каждой тысячи вызовов CUCM фиксирует значение GlobalCallID_callId в файл, который хранится на диске. При любом перезапуске CUCM производится сопоставление тысячного вызова со следующим GlobalCallID_callId.

Например, когда вызов завершен успешно, значение GlobalCallID_callId в CDR устанавливается 1001. При следующем вызове, GlobalCallID_callId значение устанавливается 1002 и т.д. Когда CUCM перезагружается, значения для следующих вызовов в CDR начинается с 2001.  Последовательность продолжается пока CUCM неперезагрузится снова.  При следюющей перезагрузки значение GlobalCallID_callId будит равно 3001.

Максимальное значение, которое будит присвоено GlobalCallID_callId ограничено 24 бит. Когда этот предел достигнут, значение GlobalCallID_callId сбрасывается до 1.

GlobalCallID_callIds в CDR файле может идти не по порядку в текстовом CDR файле. Если вызов с  GlobalCallID_callId = 1 длится долше, чем вызов с GlobalCallID_callId = 2, в CDR файл идентификатор GlobalCallId_callId = 2  запишется раньше GlobalCallId_callId = 1. GlobalCallID_callIds может  полностью отсутствовать в  CDR файле. Если первая CDR запись имеет GlobalCallID_callId = 1, а вторая  GlobalCallID_callId = 3, это не означает, что GlobalCallID_callId = 2 потеряна. GlobalCallID_callId = 2 не соответствует критериям для создания CDR. CDR может отсутсвовать, потому что пока первый и третий вызов были успешно завершены, второй вызов не был завершен, или, GlobalCallID_callId = 2 может быть частью конференции. Каждой участнику конференции (call leg) присваивается свой GlobalCallID_callId, который переписывается в GlobalCallID_callId конференции. Исходный GlobalCallID_callId может не появится в CDR файле.

Если поле GlobalCallID_callId отсутствует в CDR записи, CAR сообщает об ошибке для этой конкретной записи. Дополнительная информация о ошибках CDR доступна в главе "Configuring CDR Error Reports" руководства  the CDR Analysis and Reporting Administration Guide.

Преобразование номера

CUCM может выполнять преобразование цифр, которые набрал пользователь. В CDR появляется номер после преобразования (translated number), а не фактически набранные цифры.

Например, некоторые компании преобразуют вызов «911» в «9-911», таким образом вызывающему не нужно набирать выход на внешнюю линию (в данном примере 9) в экстренных ситуациях. В данном случае CDR содержит «9911» даже если пользователь набрал «911».

Примечание

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

Партиции и Номера

В пределах CDR, сочетание extension number (номера) и партиций определяет каждый телефон, на который ссылается, если партиции определены.  Когда партиции определены, для полного распознавания телефона требуются оба значения потому, что extension number (номер) может быть не уникальным.

Поле Partition остается пустым, при входящем вызове (call ingresses) со стороны шлюза. При исходящем вызове (call egresses) для шлюза, поле Partition показывает партицию, которой принадлежит шлюз.

Если dial plan позволяет абоненту использовать # для быстрого набора, то # записывается в базу данных при ее использовании. Например, поле Called Party Number может содержать значение, такое как  "902087569174#".

Поле Party Number может содержать SIP URIs вместо обычных номеров вызывающего/вызываемого абонента.

CDRs используется Partition/Extension Numbers, которые представлены в таблице 1.

Таблица 1

Phone Number	Description
callingPartyNumber	Это сторона совершающая вызов. При переадресации вызовов она становится передающей стороной.
originalCalledPartyNumber	Указывает на  первоначально набранный номер, после того как произошло любое преобразование номера.
finalCalledPartyNumber	Для переадресованных вызовов, этот указывается последняя сторона (абонент), которая приняла вызов. Для нереадресованных вызовов – это  поле показывает первоначальный номер абонента.
lastRedirectDn	Для переадресованных вызовов, это поле обозначает последнюю сторону (абонент), перенаправившую вызов. Для не переадресованных вызовов, это поле показывает последнюю сторону перенаправившую вызов.
originalCalledPartyNumberPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
finalCalledPartyNumberPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
lastRedirectDnPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
outpulsedCallingPartyNumber	The calling party number outpulsed from the device.
outpulsedCalledPartyNumber	The called party number outpulsed from the device.

Временные отметки
Временные метки в CDR показываются в формате UTC. Это значение остается постоянным при переходе на летнее время.

Беззнаковое 32-разрядное целое число представляет все значения времени. Это значение отображается в базе как одно целое.  Это поле показывает значение time_t, которое было получено от операционной системы.

CDR включает в себя временные метки, которые показаны в таблице 2
Таблица 2

Field	Description
dateTimeOriginatio	Для исходящих вызовов – это поле указывает время, когда на телефоне подняли трубку. Для входящих вызовов – это поле указывает время, когда было принято сообщение SETUP.
dateTimeConnect	Это поле показывает время, когда соединение установлено и начался разговор. Это поле показывает ноль, если звонок «не прошел».
dateTimeDisconnect	Это поле показывает время, когда соединение было разорвано. Это поле показывает ноль, если звонок «не прошел».

Причины разрыва соединения
CDR включает в себя два кода причины разрыва соединения: OrigCause и DestCause. Когда инициатор вызова завершает вызов – заполняется OrigCause. Когда вызываемая сторона завершает вызов или вызов сброшен – заполняется DestCause.  Когда поля не заполнены, оторбражается ноль.

Для внутренних звонков (On Net call legs) CUCM определяет значение кода причины. Для внешней части соединения (Off Net call legs), значение кода определяется на дальнем конце.
Список кодов завершения вызова согласно спецификации ITU Q.850 представлены в таблице, на странице оф. документации.


P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Процесс инициализации Cisco IP Phone: часть 1

При рассмотрении процесса инициализации будит использоваться топология:

топологии при внутрикластерном вызове

Далее следует процедура, объясняющая в деталях процесс инициализации (загрузки) Cisco IP Phone:

Шаг 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. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Вот такие вот зарплаты в Дом.ru

Пришла очередная рассылка с hh, теперь Дом.ru решил не отставать от Ростелекома. Они сообща решили довести зарплаты своих сотрудником до уровня Газпрома.