Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Руководство по устранению неполадок в системах IP-телефонии Cisco для Cisco CallManager версии 3.0(x)

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв


Содержание


Введение

Это руководство по поиску и устранению проблем описывает программные средства и служебные программы, используемые, чтобы настроить, контролировать, и устранить неполадки Релиза Cisco CallManager 3.0 (1), Cisco шлюзы IOS� и сторожевое устройство. В этом документе приводятся подробные примеры трех различных схем вызовов и освещается практическое применения для дальнейшей иллюстрации приводимых понятий.

В первом случае исследование, Cisco IP Phone вызывает другой Cisco IP Phone в кластере (внутрикластерный вызов). Во втором примере практического применения Cisco IP Phone звонит через шлюз Cisco IOS к телефону связанный через локальную УАТС или на открытой коммутируемой телефонной сети (PSTN). В третьем примере практического применения Cisco IP Phone вызывает другой Cisco IP Phone в другом кластере (межкластерный вызов).

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

Если необходимо связаться с Центром технической поддержки Cisco (TAC), многие программные средства, объясненные здесь, будут способствовать сбору данных, требуемых TAC. Если вы уже собрали эти данные перед вызыванием TAC, устранение проблемы будет быстрее.

Предварительные условия

Требования

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

  • Топология, которая показывает все сетевые устройства и критически важные компоненты с портом/номерами интерфейса, к которому они подключены и которой VLAN они принадлежат (если применимо). Специальные обозначения должны использоваться для портов, которые находятся в транкинге или режиме разделения каналов.

  • Root связующего дерева должен быть настроен, и все обычно-блокирующие-порты должны быть определены.

  • Любые каналы глобальной сети (WAN) должны быть определены с суммой пропускной способности (CIR в случае frame-relay).

Примечание: Cisco IP Phone 7960 имеет 10/100-switched сетевой порт и 10/100 порт ПК. Cisco не поддерживает "каскадные" телефоны прочь порта ПК. Мы не рекомендуем подключить и сеть и порты ПК к коммутатору (таким образом, создающий физическую петлю в сети).

Любой Интерфейс WAN потребует специальных вопросов, так как это - потенциальный источник перегрузки. Cisco IP Phone и шлюзы устанавливают потоковое поле приоритета IP-трафика Протокола RTP в пять, однако это только помечает пакет RTP. Это до администратора сети, чтобы гарантировать, что сеть настроена для приоритизации и управления контролем доступа так, чтобы Передача голоса по IP (VoIP) трафик могла быть обслужена с минимальной задержкой и конкуренцией для ресурсов. Для дополнительных сведений об этой теме обратитесь к:

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

Примечание: Все обсуждения в этом документе записаны для Релиза Cisco CallManager 3.0 (1), если не указано иное.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. в Условные обозначения технических терминов Cisco.

Общие сведения

Топология

У вас должна быть точная топология сети, содержащая порты, с которыми различные компоненты связаны, такие как VLAN, маршрутизаторы, коммутаторы, шлюзы, и т.д. Хорошо задокументированная топология помогает при устренении проблем с системой. Убедитесь, что у вас есть точная топология, вместе с доступом ко всем сетевым устройствам и сервисам терминалов для управления Сisco CallManager.

Существенное планирование требуется для успешного добавления IP-телефонии к новому или существующей сети. Так как трафик в реальном времени имеет другие требования, чем трафик данных, сеть должна быть разработана с низкой задержкой и качеством обслуживания (QoS) в памяти. Как с любой сетью, которая переносит критически - важный трафик, обязательно, чтобы администратор сети поддержал точный, подробные графические представления топологии сети. В кризисной ситуации важно знать не только широкий обзор сети, но также и какие порты связаны с сетевыми компонентами (маршрутизаторы, коммутаторы, Cisco CallManager server, шлюзы и другие критические устройства). Важно запланировать сеть с резервированием и масштабируемостью в памяти.

caution Внимание.  : Cisco не поддерживает использование концентраторов для возможности совместного подключения к коммутаторам. Концентраторы могут вмешаться в нормальную работу системы IP-телефонии.

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

Словарь терминов

Таблица ниже приводит некоторые распространенные слова и акронимы, которые могут использоваться в этом документе.

Глоссарий
Акроним/Условие Определение
.cnf Файл конфигурации используется устройствами.
�-law ("мю-закон") Метод компандирования обычно используется в Северной Америке. �-law стандартизирован как кодек на 64 кбит/с в G.711 ITU-T.
А-закон Стандарт компандирования ITU-T используется в преобразовании между аналоговыми и цифровыми сигналами в системах импульсно-кодовой модуляции (PCM). А-закон используется прежде всего в европейских телефонных сетях и подобен североамериканскому стандарту �-law.
ACF Подтверждение приема.
ANI Вызывающий номер.
ARQ Запрос на прием.
Канал B Несущий канал. В ISDN это - полнодуплексный, канал на 64 кбит/с, используемый для передачи пользовательских данных.
Calling Search Space (Пространство поиска вызовов) Пространство поиска вызова определяет, какие номера каталога и шаблоны маршрута данное устройство может вызвать. Это - группировка отделений, посредством которых можно посмотреть при звонке. Например, предположите, что существует несколько отделений в Пространстве поиска вызова, которые называют "Исполнительными". В данном примере номер IP-телефона Cisco находится в "Исполнительном" Пространстве поиска вызова. При инициировании вызова номер IP-телефона Cisco перерывает "NYInternationalCall", "NYLongDistance", "NYLocalCall" и "NY911" доступные отделения. Номеру IP-телефона Cisco, который имеет "Гостевое" Пространство поиска вызова, например, можно было бы только позволить перерыть отделения "NYLocalCall" и "NY911". Поэтому, если пользователь попытается набрать международный номер, то количество не найдет соответствие, и вызов не будет направлен.
CCAPi API управления вызовами. Используемый Cisco IOS для обработки обработки вызова VoIP.
CCO Cisco Connection Online (http://www.cisco.com). Предоставляет последнюю информацию о продуктах Cisco, сведениях о технической поддержке и технической документации.
CDR Подробная запись о вызове. Предоставляет сведения о генерации вызова, назначении и продолжительности. Это используется для создания записей информации для выставления счетов.
Cisco IOS Системное программное обеспечение Cisco, которое предоставляет общие функциональные возможности, масштабируемость и безопасность для всех продуктов под Архитектурой CiscoFusion. Cisco IOS позволяет централизованный, интегрированный, и автоматическая установка и управление межсетевым обменом, при обеспечении поддержки большого разнообразия протоколов, сред, сервисов и платформ.
Кластер Кластер Cisco CallManager. Логическая группировка нескольких Cisco CallManager server.
CMR Записи управления вызовами, также известные как Диагностические КОМАНДИРЫ. Это записи, которые содержат количество передаваемых байтов, переданные пакеты, дрожание, задержка, отброшенные пакеты, и т.д.
codec Кодер - декодер. Алгоритм ПО доменной части (DSP) использовал сжимать/распаковывать речь или аудиосигналы.
Канал D Канал данных. Полнодуплексный, 16 кбит/с (BRI) или 64 кбит/с (PRI) канал ISDN. Используемый для сигнализации и контроля.
DCF Расцепите подтверждают.
DHCP Протокол динамической настройки узла сети. Предоставляет механизм для выделения IP-адресов динамично так, чтобы адреса могли быть снова использованы, когда хосты больше не требуют их.
DN Directory Number (Абонентский номер). Это - номер телефона конечного устройства. Это может быть количество, назначенное на Cisco IP Phone, программный IP-телефон Cisco, факс или аналоговый телефон, подключенный к шлюзу. Примеры включают 1000 и 24231.
DNIS Сервис идентификации набранного номера.
DNS Система доменных имен. Это - система, используемая в Интернете для перевода названий узлов сети в адреса.
DRQ Запрос на освобождение канала.
DTMF Двухтональный многочастотный набор. Это - использование двух одновременных речевых тонов для вызова номера (таких как сенсорный тон).
Поток Поток данных, перемещающийся между двумя оконечными точками по сети (от одной станции LAN до другого, например). Множественные потоки могут быть переданы на одиночном канале.
Полный дуплекс Возможность одновременной передачи данных и от посылающей станции и от принимающей станции.
G.711 Описывает способ кодирования речевого сигнала PCM на 64 кбит/с. В G.711 закодированные голосовые данные уже находятся в правильном формате для передачи цифровых голосовых данных в PSTN или через PBXs. Это описано в стандарте ITU-T в его Рекомендациях по серии G.
G.729 Описывает сжатие линейного предсказания с кодовым возбуждением (CELP), где голос кодирован в потоки на 8 кбит/с. Существует два изменения этого стандарта (G.729 и приложение A G.729), которые отличаются в основном по вычислительной сложности; оба предоставляют качество речевого сигнала, подобное адаптивной дифференциальной кодово-импульсной модуляции (ADPCM) на 32 кбит/с. Это описано в стандарте ITU-T в его Рекомендациях по серии G.
H.225 Стандарт ITU, который управляет установкой сеанса H.225 и пакетизацией. H.225 фактически описывает несколько других протоколов: RAS, использование Q.931 и использование RTP.
H.245 Стандарт ITU, который управляет контролем за оконечной точкой H.245.
H.323 Расширение H.320 стандарта ITU-T, который включает видеоконференцсвязь по LAN и другим сетям с коммутацией пакетов, а также видео по Интернету.
Полудуплекс Возможность передачи данных только в одном направлении за один раз между посылающей станцией и принимающей станцией. Бинарная синхронная связь (BSC) является примером полудуплексного протокола.
Hookflash Короткий период с положенной трубкой, обычно генерируемый подобным телефону устройством во время вызова, чтобы указать, что телефон пытается выполнить повторный вызов тонального сигнала готовности линии от УАТС. Hookflash часто используется для выполнения передачи вызова.
ICCP Внутрикластерный протокол управления
ISDN (Цифровая сеть интегрированных служб). Протокол связи, предлагаемый телефонными компаниями, который разрешает телефонным сетям переносить данные, голос и другой исходный трафик.
Дрожание Изменение во времена прибытия голосовых пакетов.
MGCP MGCP (протокол управления шлюзом-носителем). Протокол для Сisco CallManager для управления Шлюзами VoIP (оконечные точки MGCP).
MTP Media Termination Point.
Разделение Разделение является логической группировкой номеров каталога (DN) и шаблонов маршрута с подобными характеристиками достижимости. Для простоты они обычно названы по имени их характеристики, таковы как "NYLongDistance", "NY911", и т.д. Когда DN или шаблон маршрута размещены в определенное, некоторый разделение, это создает правило для того, кто может вызвать тот список устройств или список маршрутов.
УАТС Обмен частной ветки. Цифровой или коммутационная панель аналоговой телефонной связи расположился на помещениях абонента и используемый для соединения частный и телефонные сети общего пользования.
PRI Интерфейс первого уровня. Доступ на основной скорости состоит из одиночного канала D на 64 кбит/с плюс 23 (T1) или 30 (E1) каналы B для голоса или данных.
PSTN Коммутируемая телефонная сеть общего пользования. Общий термин, относящийся к различным телефонным сетям и услугам, используемым во всем мире.
Q.931 Стандарт ITU, который описывает Сигнализацию ISDN. Стандарт H.225.0 использует вариант Q.931, чтобы установить и разъединить сеансы H.323.
RAS Протокол регистрации, входа и состояния. Это - протокол, используемый в наборе протоколов H.323 для обнаружения и взаимодействия со сторожевым устройством.
Route Filter (Фильтр маршрута) Фильтр маршрута может использоваться не только, чтобы ограничить вызов номера, но также и определить подмножество шаблона подстановочного знака (при использовании подстановочный знак в североамериканском Плане нумерации для дозвона). Например, это могло использоваться для блокирования вызова номера 900 кодов зоны. В может также использоваться в сочетании с отделениями и Пространствами поиска вызова для устанавливания сложных правил. Например, предположите, что у вас есть три установленные группы пользователей: Руководитель, Штат и Гость. Фильтр маршрута может позволить Группе пользователей Executive набирать международные номера, Группа штатных пользователей для набирания локальных номеров или междугородних вызовов и Гостевой группы пользователей, чтобы только набрать локальные номера, 911, и 800 количества.
Группа маршрутов Группа маршрутов является списком одного или более шлюзов или портов на шлюзах, которые замечены как равный доступ. Это походит на группу транков в традиционной терминологии АТС. Например, у вас может быть два канала PRI к тому же носителю, который может использоваться произвольно. Шлюз (или определенный порт на шлюзе) может только быть добавлен к одной группе маршрутов.
Список маршрутов Раньше вызванная точка маршрута, список маршрутов позволяет Сisco CallManager искать через список групп маршрутов в настроенном порядке предпочтения. Несколька маршрутных списков могут указать к тем же группам маршрутов.
Route Pattern Определенное количество или, более обычно, диапазон набранных номеров, которые будут использоваться для маршрутизации вызовов к устройству (таких как DT-24 Доступа Cisco + шлюз или маршрутизатор с поддержкой голосового трафика) или косвенно через список маршрутов. Например, 1XXX показывает 1000 - 1999. 'X' в 1XXX показывает одиночную цифру; подстановочный знак. Существуют другие такие подстановочные знаки (такой как.! и т. д. Шаблон маршрута не должен быть уникальным в разделении, пока фильтр маршрута является другим.
RRJ Отказ в регистрации.
RTP Протокол транспорта в реальном времени, один из протоколов IPv6. RTP разработан для обеспечения функций сквозной транспортировки по сети приложениям, передающим данные в режиме реального времени, например, аудио, видео, данные имитации по широковещательным или одноадресным сетевым службам. . RTP обеспечивает такие услуги, как идентификация типа полезной нагрузки, нумерация последовательностей, временные отметки и мониторинг доставки для приложений, функционирующих в режиме реального времени. .
SEP Телефон Ethernet Selsius. Этот акроним предшествует MAC-адресам на Cisco IP Phone и представляет уникальный идентификатор устройства.
Подавление пауз (речевое обнаружение активации) Подавление пауз позволяет Cisco IP Phone обнаруживать отсутствие звукового сигнала и поэтому не передает пакеты по сети. Качество звука может быть немного ухудшено, но соединение может также использовать меньше пропускной способности. Подавление пауз отключено по умолчанию.
SNMP Simple Network Management Protocol. Протокол управления сетями используется почти исключительно в сетях TCP/IP. SNMP является средством контроля и управления сетевыми устройствами, управления конфигурациями, сбора статистики, управления производительностью и безопасностью.
SQL SQL (structured query language). Язык международного стандарта для определения и доступа к реляционным базам данных.
T1 CAS T1 является цифровым средством передачи данных по глобальным сетям (WAN), передавая DS-1-formatted в 1.544 Мбит/с через сеть коммутации телефонных вызовов, с помощью кодирования B8ZS или AMI. CAS является интерфейсом Сигнализации по выделенному каналу.
T1/PRI T1 является цифровым средством передачи данных по глобальным сетям (WAN), передавая DS-1-formatted в 1.544 Мбит/с через сеть коммутации телефонных вызовов, с помощью кодирования B8ZS или AMI. PRI является Интерфейс первого уровня. Доступ на основной скорости состоит из одиночного канала D на 64 кбит/с плюс 23 (T1) или 30 (E1) каналы B для голоса или данных.
TCP  /* Протокол управления передачей. Это - протокол уровня передачи на основе соединений, который предоставляет надежный, передача полнодуплексных данных. TCP является частью Стека протоколов TCP/IP.
TFTP Trivial File Transfer Protocol. Упрощенная версия FTP, который позволяет файлам быть переданными от одного компьютера до другого по сети.
Шаблон трансляции Используемый для перевода названный (DNIS) и вызывающий количество автоматического определения номера (ANI) прежде, чем направить вызов. Например, вызов может войти к ряду количества (919 392-3XXX), который должен быть преобразован в ряд Cisco IP Phone, которые находятся в диапазоне 2XXX. Сisco CallManager устанавливали шаблон трансляции для 919 392-3XXX. Этот образец преобразовывает продвижение 919 392-3 просто к 2 при оставлении оставшихся разрядов неповрежденными. Затем вызов направлен к соответствующему Cisco IP Phone. Шаблоны трансляции используются только для истинных трансляций и не должны использоваться для простого цифрового чередования данных и задание префиксов.
UDP Протокол дейтаграмм пользователя. Это - протокол транспортного уровня без предварительного соединения в Стеке протоколов TCP/IP. UDP является простым протоколом, который обменивается дейтаграммами без подтверждений или гарантированной доставки, требуя что ошибочная обработка и повторная передача быть обработанным другими протоколами. UDP определен в RFC 768.
Речевое обнаружение активации (подавление пауз) Речевое Обнаружение активации позволяет Cisco IP Phone обнаруживать отсутствие звукового сигнала и поэтому не передает пакеты по сети. Качество звука может быть немного ухудшено, но соединение может также использовать меньше пропускной способности. VAD/Подавление пауз отключен по умолчанию.
VoIP Voice over IP.
Сети VLAN Виртуальная локальная сеть. Группа устройств на одной или более LAN, которые настроены (использование программного обеспечения для управления) так, чтобы они могли связаться, как будто они были присоединены к тому же проводу, когда фактически они расположены в ряде других сегментов LAN. Поскольку VLAN основываются логический вместо физических соединений, они чрезвычайно гибки.

Средства и служебные программы для мониторинга и устранения неполадок системы Cisco CallManager

Этот раздел обращается к программным средствам и служебным программам, чтобы настроить, контролировать и устранить неполадки Сisco CallManager.

Детали управления Cisco CallManager

Управление Cisco CallManager предоставляет сведения о версии для системы, базы данных и других компонентов. На вводной странице щелкните по кнопке Details и запишите версии в использовании.

ccm_admin.gif

Больше подробного объяснения Управления Cisco CallManager доступно в онлайн-документации Сisco CallManager.

Пропускная способность Microsoft

Производительность (Монитор) является приложением Сервера Windows 2000, которое может отобразить действия и статус Системы Cisco CallManager. Это сообщает обе общей и частной информации в режиме реального времени. Можно использовать Производительность Windows 2000 для сбора и система отображения и статистика устройства для любой установки Сisco CallManager. Эти средства администрирования позволяют вам получать полное понимание системы, не изучая операцию каждого из ее компонентов.

Можно использовать Производительность для мониторинга множества системных переменных в режиме реального времени. После добавления параметров Сisco CallManager можно определить сроки, в соответствии с которыми Сisco CallManager отобразит статистику, генерируемую системой. Например, можно контролировать количество идетов звонок в любое время или количество вызовов, в настоящее время проходящих через определенный шлюз. Производительность показывает и общий и Cisco характерные для CallManager сведения о статусе в режиме реального времени.

/image/gif/paws/30266/ms_perf.gif

Вводная вкладка Быстродействие в Microsoft Windows

Для открытия Производительности на ПК сервера рабочий Сisco CallManager нажмите Start> Settings> Control Panel> Administration Tools> Performance.

Настройка производительности

Монитор производительности должен быть настроен для просмотра связанных с Сisco CallManager параметров, которые вы хотите контролировать. Выберите объект, счетчик и экземпляр, который вы хотите включать. Обратитесь к Настройке Удаленное Удобство обслуживания для Сisco CallManager, Выпуск 3.0 для инструкций о том, как использовать объекты и счетчики для настройки вкладки Быстродействие в Microsoft Windows для операций Сisco CallManager.

Microsoft Event Viewer

Microsoft Event Viewer является приложением Сервера Windows NT Server, которое отображает систему, безопасность и события приложения (включая Сisco CallManager) для Сервера Windows NT Server. Если сервис (включая TFTP) не может считать базу данных (где это получает конфигурацию следа), это добавит ошибки к Просмотру событий. Просмотр событий является единственным местом, где появятся эти типы ошибок. Следующий рисунок показывает журналы приложения, работающие на Сервере Windows NT Server.

ms_event_viewer.gif

Средство просмотра открытия

Для открытия Журнала событий на ПК сервера рабочий Сisco CallManager нажмите Start> Settings> Control Panel> Administrative Tools> Event Viewer. Просмотр событий предоставляет журналы ошибок для Системы, Безопасности и Приложений. Ошибки Сisco CallManager зарегистрированы под Журналом приложения.

Подробные сведения о событиях

Можно дважды нажать событие в журнале для узнавания больше информации о событии.

/image/gif/paws/30266/event_prop.gif

SDI-запись

Следы SDI являются локальными файлами журнала. IP-адрес, маркер TCP, имя устройства или штамп времени могут использоваться при рассмотрении следа SDI для мониторинга возникновения или расположения запроса. Это имя устройства могло быть отслежено назад в здание файла, который показывает аппаратный пул и модель. Аппаратный пул и модель могут быть отслежены назад в здание прототипа файла конфигурации, который перечислит сетевой адрес Сisco CallManager () и порта TCP - подключения.

При наблюдении следов SDI заметьте, что класс C++ и стандартные названия включены с большинством линий трассировки. Большинство подпрограмм, привязанных к обслуживанию определенного запроса, включает идентификатор потока в стандартный формат.

Следы SDI будут объяснены подробно в примерах практического применения.

Выходные данные трассировки SDI

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

Файлы трассировки сохранены в придерживающемся расположении по умолчанию: C : \Program Files\cisco\bin. Когда определяемое количество линий было достигнуто, новый файл трассировки запущен каждый раз перезапуски Сisco CallManager, или.

Придерживающееся является рисунком настройки интерфейса следа Управления Cisco CallManager. Необходимо разрешить трассировку, выбрать уровень на информации, необходимой, и проверить маску пользователя для получения нужного уровня информации.

/image/gif/paws/30266/trace_config.gif

Если след не будет настроен должным образом, то он будет генерировать большое количество информации, делающей его очень трудный изолировать проблемы. Следующий раздел объясняет, как должным образом настроить полезный след.

Следы Настройки

Следы составлены из флагов маски пользователя (также известный как биты) и уровни трассировки. Открытое Управление Cisco CallManager. Для включения отслеживания установите параметры следа (включая настроенный сервис, биты, и т.д.) на экране Service> Trace. Обратитесь к Руководству Управления Cisco CallManager, Выпуску 3.0 (1) для полной информации о включении и выключении отслеживания, и для описаний Масок пользователя и Уровней для каждого настроенного сервиса и т.д.

Придерживающееся является двумя примерами битов маски следа, которые были бы включены на основе конкретной проблемы.

  • Для отладки обычного сообщения включите биты подсистемы 5, 6, 7, 8, 11, и 12

  • Для отладки шлюзов включите биты подсистемы 3, 4, 5, 6, 7, 8, 9, 11, 12, и 13

Придерживающееся является двумя примерами требуемых уровней трассировки на основе конкретной проблемы

  • Для обычной отладки уровень трассировки должен быть установлен в SDI_LEVEL_ARBITRARY

  • Для системы работающая в штатном режиме уровень трассировки должен быть установлен в SDI_LEVEL_ERROR

SDI-запись

Инженеры Cisco используют следы SDL для обнаружения причины ошибки. Вы, как ожидают, полностью не поймете информации, содержавшейся в следе SDL. Однако при работе с TAC, вас можно попросить разрешить трассировку SDL и предоставить его TAC. Файлы трассировки SDL могут быть сохранены к локальным каталогам, Просмотру событий Windows NT и CiscoWorks 2000. Чтобы избежать любого снижения производительности на сервере, быть уверенным, что вы выключаете Трассировку SDL, после, след был перехвачен.

След SDL предоставляет интерфейс C для отслеживания и сигналы тревоги. Сигналы тревоги используются для информирования администратору непредвиденных событий, такому как неспособность для доступа к файлу, базе данных, Winsock или неспособности для выделения других ресурсов операционной системы.

Разрешение трассировки SDL

Трассировки SDL разрешены в Службе> область параметров службы в Управлении Cisco CallManager. Помните, что эти следы должны быть включены только, когда запросил инженер TAC. Примечание значения, выбранные для включения следа SDL в следующем рисунке.

/image/gif/paws/30266/serv_param_config.gif

Как только трассировки SDL разрешены, собирают следы. Если следы передаются локальному устройству, то можно получить их в подкаталоге Cisco\Trace. Также файлы трассировки могут быть переданы журналу событий или CiscoWorks 2000.

Флаговые биты SDL, описанные в следующей таблице, установлены в области Service> Service Parameters в Управлении Cisco CallManager. Придерживающееся является двумя примерами желаемых значений на основе конкретной проблемы.

  • Рекомендуемое значение для отладки обычного вызова является SdlTraceTypeFlags=0x00000b04

  • Рекомендуемое значение для нижнего уровня отлаживающие или отлаживающие шлюзы является SdlTraceTypeFlags=0x00004b05

Определения SdlTraceTypeFlags
SDLTraceTypeFlag Значение Определение
traceLayer1 = 0x00000001 Весь след Уровня 1 на
TraceDetailLayer1 = 0x00000002 Подробный Уровень 1 отслеживает на
TraceSdlLinkAdmin = 0x00000004 Отследите ссылки меж-Сisco CallManager в кластере
traceUnused = 0x00000008 Не используется
traceLayer2 = 0x00000010 Весь след Уровня 2 на
traceLayer2Interface = 0x00000020 След интерфейса 2 уровня на
traceLayer2TCP = 0x00000040 TCP Уровня 2 отслеживает на
TraceDetailLayer2 = 0x00000080 Больше подробного дампа кадров Уровня 2.
traceLayer3 = 0x00000100 Весь след Уровня 3 на
traceCc = 0x00000200 Весь след управления вызовами на
traceMiscPolls = 0x00000400 Отследите разные опросы
traceMisc = 0x00000800 Разный след на (Сигналы базы данных)
traceMsgtrans = 0x00001000 Сигналы Преобразования сообщений (TranslateIsdnToSdlReq, TranslateIsdnToSdlRes TranslateSdlToIsdnReq, TranslateSdlToIsdnRes)
traceUuie = 0x00002000 Выходные данные UUIE отслеживают на
traceGateway = 0x00004000 Сигналы шлюза

Биты данных, описанные в следующей таблице, установлены в области Service> Service Parameters в Управлении Cisco CallManager. Придерживающееся является двумя примерами желаемых значений на основе конкретной проблемы.

  • Рекомендуемое значение для отладки нормальной системы является SdlTraceDataFlags=0x110

  • Рекомендуемое значение, когда отслеживание проблем со ссылками SDL является 0x13D (неуплотненный след; если компактный след требуется, разрядный 0x200 должен быть установлен. Это может быть установлено в сочетании с любыми другими битами),

Определения SDLTraceDataFlags
SDLTraceDataFlag Значение Определение
TraceSdlLinkState = 0x001 Разрешите трассировку Инициализации Ссылки SDL
TraceSdlLowLevel = 0x002 Позвольте отследить низкоуровневых событий SDL, fileOpen и событий сокета (например),
TraceSdlLinkPoll = 0x004 Позвольте отследить сообщения Опроса Ссылки SDL
TraceSdlLinkMsg = 0x008 Позвольте отследить сообщения Ссылки SDL
traceRawData = 0x010 Разрешите трассировку данных необработанного сигнала на всех сигналах
TraceSdlTagMap = 0x020 Включите сопоставление метки
traceCreate = 0x100 Включите процесс, создают и останавливают следы
TraceNoPrettyPrint = 0x200 Отключите структурированную печать файлов трассировки

Предупреждение дискового пространства

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

Журнал анализатора трафика

Анализатор является программным приложением, которое контролирует IP - трафик в сети и предоставляет сведения в форме следа. Отслеживание средств прослушивания предоставляет сведения о количестве и типе сетевого трафика в сети. TCP/IP или пакеты UDP являются протоколами, используемыми Сisco CallManager и оконечными устройствами, такими как телефоны и шлюзы. Отслеживание средств прослушивания может также помочь вам определять высокие уровни широковещательного трафика, который мог привести к речевым проблемам со звуком или разрывам связи. Стандартные приложения отслеживания включают SnifferPro Сетевых специалистов, интернет-Советника Hewlett Packard и Acterna Domino. Предложения Domino, осуществляющие сниффинг решений для программного и аппаратного обеспечения и анализатора сети. Если вы хотите использовать Domino, мы рекомендуем использовать программное обеспечение для анализа для оценки перехваченного файла проверки анализатора трафика (такой как из приложения SnifferPro).

Записи данных вызовов (CDR) и записи управления вызовами (CMR)

CDR является опцией создания отчетов, которая регистрирует каждый выполненный вызов (или предпринятый) от любого Cisco IP Phone. Существует два вида КОМАНДИРОВ: основные КОМАНДИРЫ и Диагностические КОМАНДИРЫ (или CMR). После того, как включенный, можно открыть КОМАНДИРОВ или Диагностических КОМАНДИРОВ (CMR) в SQL Server Enterprise Manager. Файлы CDR сохранены в базе данных SQL, которая может быть экспортирована в почти любое приложение, включая Microsoft Access или Excel.

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

Если Сisco CallManager отказывает, прежде чем любые записи записаны, никакая запись вызова не будет существовать. Это означает, что никакая запись не будет записана для вызовов, которые активны на данном Сisco CallManager, когда он отказывает перед оконечными вызовами.

Обратитесь к разделу Подробных записей о вызовах этого документа для получения дальнейшей информации о КОМАНДИРАХ и CMR.

Предоставленная информация включает:

  • Чтение и запись записей

  • Типичные ошибки

  • Список типов записи генерируется

  • Список полей содержал в каждой записи и описании того, что представляет то поле

  • Описание типов вызовов, зарегистрированных, и поля, зарегистрировано с каждым из них

  • Список кодов причин, которые могут появиться в Записях CDR

Включение или отключение КОМАНДИРОВ

Когда система установлена, создание записи CDR отключено по умолчанию. Если вы хотите иметь данные CDR, необходимо включить КОМАНДИРАМ в области Service> Service Parameters Управления Cisco CallManager. В то время как система в действии, обработка CDR может быть включена и отключена в любое время. Вы не должны перезапускать Сisco CallManager для включения или отключения КОМАНДИРОВ для вступления в силу. Система ответит на все изменения в течение нескольких секунд. Данные CMR или диагностические данные включены отдельно от данных CDR. Данные CMR не будут генерироваться, пока обоим КОМАНДИРАМ и Диагностике Вызова не включат, но данные CDR могут генерироваться и зарегистрированы без данных CMR.

Используйте следующие шаги, чтобы включить КОМАНДИРАМ.

  1. Открытое управление Cisco CallManager.

  2. Выберите Service> Service Parameters.

  3. Выберите IP-адрес установки Сisco CallManager.

  4. От списка Параметров выберите CDREnabled.

  5. Определите тип как булевскую переменную.

  6. Выберите T for True.

    /image/gif/paws/30266/serv_param_config2.gif

  7. Обновление.

    Результат: Подробные записи о вызовах начнут регистрировать сразу.

    caution Внимание.  : Отслеживание подключения голосовых данных требует, чтобы Регистрация CDR была включена на каждой установке Сisco CallManager в кластере.

    /image/gif/paws/30266/log_enable.gif

КОМАНДИРЫ

КОМАНДИРЫ предоставляют основные сведения, которые могут помочь вам понимать более подробную информацию, содержавшуюся в следах SDI. Основные КОМАНДИРЫ предоставляют сведения, такие как вызывающий номер, вызываемый номер, инициируя IP-адрес, IP - адрес назначения, длительность вызова, и т.д. КОМАНДИРЫ могут помочь вам устранять телефонные проблемы. Например, если пользователь сообщает о проблеме с вызовом, происходящим в специфическом времени, можно консультироваться с КОМАНДИРАМИ, которые произошли примерно во время обозначенный для обучения дополнительных сведений о том вызове и других. КОМАНДИРЫ обычно используются для составления счетов.

Диагностические КОМАНДИРЫ (также известный как CMR)

Диагностические КОМАНДИРЫ предоставляют подробную информацию о вызовах, такую как количество пакетов, переданных, полученных и потерянных, и сумма дрожания и задержки. Эта степень детализации может предоставить пояснения для некоторых проблем, таких как односторонняя передача аудиоданных. Например, проблема односторонней передачи аудиоданных обозначена, если размер пакета 10,000 передается, но полученный размер - только 10.

Устранение неполадок CallManager при использовании Windows NT и IIS (Internet Information Server)

Этот раздел обращается к некоторым категориям типичной проблемы, которые могут произойти с Сisco CallManager и отнесенными устройствами. Каждая категория проблемы предлагает средства устранения проблем, которые необходимо использовать, чтобы помочь изолировать проблему. Этот документ предоставляет общие категории потенциальных проблем и предложений о том, как устранять те проблемы. Это не предоставляет полный список проблем и разрешений. Если вы встречаетесь с проблемой, которая не может быть решена с помощью программных средств и служебных программ, описанных в этом документе, консультироваться с Центром технической поддержки Cisco (TAC) для помощи. Обязательно имейте в наличии Подробности администрирования Cisco CallManager, плюс любая диагностическая информация (такие как следы) вы собрали на грани вызова TAC.

КАЧЕСТВО ГОЛОСА

Проблемы качества голосовой связи включают потерянное или искаженное аудио во время телефонных звонков. Типичные проблемы включают перерывы в звуке, которые заставляют аудио быть неустойчивым (как нарушенные обещания), или присутствие нечетных шумов, которые искажают аудио (эхо) или эффекты, которые заставляют произнесенные слова звучать водянистыми или автоматизированными. Односторонняя передача аудиоданных, т.е. диалог между двумя людьми, где только один человек может услышать что-либо, не является фактически проблемой качества голосовой связи. Это будет обсуждено позже в этом разделе.

Один или больше придерживающихся компонентов может вызвать проблемы со звуком:

  • Шлюз

  • Телефон

  • Сеть

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

Потерянное или искаженное аудио

Одна из самых обычных проблем, с которыми встречаются, является "разбиванием" аудио (часто описываемый как искаженная речь или потеря слогов в слове или предложении). Существует две типичных причины для этого: потеря пакета и/или дрожание. Потеря пакета означает, что аудиопакеты не прибывают к своему месту назначения, потому что они были отброшены или поступили слишком поздно, чтобы быть полезными. Дрожание является изменением во времена прибытия пакетов. В идеальной ситуации все Пакеты VoIP от одного телефона до другого поступили бы точно в скорость 1 каждого 20 мс. Заметьте, что это не упоминает, сколько времени это берет для пакета, чтобы заставить от точки указывать B, просто изменение во времена прибытия.

Существует много источников переменной задержки в реальной сети. Некоторые из них не могут управляться, и некоторые могут. Переменная задержка не может быть устранена полностью в сети речевых пакетов. Цифровые процессоры сигналов (DSP) по телефонам и другим звуковым устройствам разработаны для буферизации части аудио, в ожидании переменной задержки. Этот "dejittering" сделан только, когда аудиопакет достиг своего назначения и готов быть помещенным в стандартный аудиопоток (т.е. играться в ухо пользователя, передаваемое PSTN через цифровой поток PCM). Cisco IP Phone 7960 может буферизовать столько же сколько одна секунда образцов голосовых данных. Буфер дрожания адаптивен, означая, получен ли пакет пакетов, Cisco IP Phone 7960 может закончить их в попытке управлять дрожанием. Администратор сети должен минимизировать изменение между временами получения пакета путем применения качества обслуживания (QoS) и других мер заранее (особенно, если вызовы пересекают глобальную сеть).

Когда сталкивающийся с потерянной или искаженной проблемой со звуком, необходимо сначала попытаться изолировать путь аудио. Попытайтесь определить каждое сетевое устройство (коммутаторы и маршрутизаторы) в пути аудиопотка вызова. Следует иметь в виду, что аудио может быть между двумя телефонами между телефоном и шлюзом, или оно могло иметь множественные ветви (с телефона на устройство транскодирования и оттуда к другому телефону). Попытайтесь определить, происходит ли проблема только между двумя сайтами, только через определенный, некоторый шлюз, на определенной, некоторый подсети, и т.д. Это поможет сужать, какие устройства необходимо исследовать более тщательно. Затем, часто лучше отключить подавление пауз (также известный как Речевое Обнаружение активации или VAD), если это уже не было сделано. Когда существует тишина, но может вызвать примечательный (и недопустимый) отсекающий в начале слов, этот механизм действительно сохраняет пропускную способность "not transmitting" любое аудио. Можно отключить это в Управлении Cisco CallManager под Service> Service Parameters. Оттуда, выберите сервер и Сервис Cisco CallManager. Установите SilenceSuppressionSystemWide в "F" (альтернативно, можно установить SilenceSuppressionWithGateways в "F", но это не применяется к шлюзам H.323 или шлюзам MGCP). Когда в сомнении, выключите обоих путем выбора Value F для каждого.

/image/gif/paws/30266/serv_param.gif

Если анализатор сети доступен, проверенный вызов между двумя телефонами должен иметь 50 пакетов в секунду (или 1 пакет каждые 20 мс), когда отключено подавление пауз. Если пакеты теряются или задерживаются чрезмерно, с надлежащим фильтрованием должно быть возможно определить.

Помните, что задержка отдельно не вызовет отсечение, только переменная задержка будет. В таблице ниже, который представляет совершенный след, времена прибытия между аудиопакетами (который будет иметь заголовок RTP) будут 20 мс. В вызове низкого качества (таком как вызов с большим количеством дрожания), времена прибытия варьировались бы значительно.

Совершенный след
Пакетное количество Время: абсолютный (мс) Время: дельта (мс)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

Размещение анализатора пакетов в различные точки в сети поможет сужать от того, куда прибывает задержка. Если никакой анализатор не будет доступен, то другие методы будут требоваться. Важно исследовать интерфейсную статистику каждого устройства в пути аудио. Другое программное средство для отслеживания вызовов с низким качеством голосовой связи является Диагностическими Подробными записями о вызовах (КОМАНДИРЫ). Посмотрите раздел Программных средств и служебных программ и раздел Подробных записей о вызовах для получения дополнительной информации о КОМАНДИРАХ.

Значения для дрожания и задержки могут быть получены для всех вызовов (но только после того, как вызов завершился). Придерживающееся является типовым Диагностическим CDR (CallDetailRecordDiagnostic является фактическим именем таблицы). Количество пакетов, переданных, полученных, потерянных, дрожание и задержка, все зарегистрировано. Значение globalCallID может использоваться для обнаружения вызова в обычной таблице CDR так, чтобы могли быть получены причина разъединения и другая информация. Приведенный ниже рисунок показывает обе открытые таблицы. Заметьте, что в Диагностическом CDR, включено каждое устройство, которое может возможно сообщить эту информацию. Так, если проблема между двумя Cisco IP Phone, мы видим два элемента таблицы на вызов. Если у нас есть вызов через шлюз Cisco IOS, например, мы только видим диагностическую информацию от Cisco IP Phone, не шлюз, потому что нет никакого механизма для него для уведомления базы данных SQL с этой информацией.

ibutton.gif

я Снабжаю кнопками Справку

Cisco IP Phone 7960 предоставляет другое программное средство для диагностирования возможных проблем со звуком. На активном вызове можно нажать кнопку меня дважды (быстро) и дисплеи телефона информационный экран, который содержит пакет, получают и передают статистику, а также счетчики максимальных колебаний задержки и среднее число. На этом экране, не, что дрожание является средним числом последних пяти пакетов, которые поступили; максимальные колебания задержки являются наибольшим возможным значением для средних колебаний.

Наиболее распространенные источники для задержки и потери пакета являются устройствами, где интерфейс с более высокой скоростью питается в низкоскоростной интерфейс. Например, маршрутизатору можно было подключить интерфейс Fast Ethernet на 100 Мбит с LAN и медленным frame-relay, связанным с глобальной сетью (WAN). Когда низкое качество происходит только при передаче с удаленным сайтом (только удаленный сайт может сообщать о низком качестве голосовой связи, в то время как в другом направлении все, кажется, прекрасно), ниже наиболее вероятные причины проблемы:

  • Маршрутизатор не был должным образом настроен для предоставления приоритета речевого трафика над трафиком данных.

  • Существует слишком много вызовов, активных для глобальной сети (WAN) для поддержки (т.е. нет никакого управления контролем доступа для ограничения количества вызовов, которые могут быть размещены).

  • Существуют ошибки физического порта.

  • В самой глобальной сети (WAN) существует перегрузка.

На LAN самые обычные проблемы являются ошибками физического канала (такими как ошибки CRC) вызванный поврежденными кабелями и интерфейсами, или неправильно-настроенными-устройствами (такими как скорость порта или несогласованность дуплексных параметров). Удостоверьтесь, что трафик не пересекает устройства общей среды, такого как концентратор. Могли также быть ситуации, где трафик берет более медленный путь через сеть, чем ожидаемый. Если QoS было настроено правильно, возможно, что нет никакого управления контролем доступа. В зависимости от топологии это может быть выполнено с помощью Местоположений в конфигурации Управления Cisco CallManager, или при помощи маршрутизатора Cisco IOS как сторожевое устройство. В любом случае необходимо всегда знать, сколько вызовов могло поддерживаться по глобальной сети (WAN). Если возможно, тест это путем отключения подавления пауз, как описано ранее, то размещают вызовы между этими двумя сайтами. Не размещайте вызовы в ожидании или на бесшумном режиме, так как это будет мешать пакетам быть переданным. С максимальным числом вызовов по глобальной сети (WAN) вызовы должны все иметь приемлемое качество. Тест, чтобы удостовериться, что сигнал занятости возвращен при попытке выполнить еще один вызов.

Треск

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

Проверьте загрузки

Кроме того, необходимо всегда проверять телефоны и шлюзы, чтобы гарантировать, что используются загрузки последних версий программного обеспечения. Когда в сомнении, проверьте CCO (Cisco Connection Online в www.cisco.com) для загрузок последних версий программного обеспечения, новых исправлений или Комментариев к выпуску, касающихся проблемы.

Эхо

Когда мощность речевого сигнала говорящего, переданная вниз путь основного сигнала, связана в тракт приема от дальнего конца, эхо (также известный как "эхосигнал источника") происходит. Говорящий тогда слышит его собственный голос, задержанный общим временем задержки тракта эха.

/image/gif/paws/30266/voice.gif

В схеме выше, голос Джона (в синем) отражается назад. Это может произойти, но остаться незамеченным в традиционной голосовой сети, потому что задержка так низка. Пользователю это больше походит на местный эффект, чем эхо. В Сети VoIP это всегда будет примечательно, так как пакетизация и сжатие всегда вносят достаточно задержки. Важная вещь для запоминания - то, что причина эха всегда с аналоговыми компонентами и проводным соединением. Например, пакеты IP не могут просто обернуться и вернуться к источнику в более низком уровне громкости. То же невозможно на цифровых каналах T1/E1. Таким образом на вызове от одного Cisco IP Phone до другого, никогда не должно быть никакой проблемы. Единственное исключение может быть то, если одна сторона использует динамик телефона, который имеет громкость слишком высоко или некоторую другую ситуацию, где создана аудио петля.

При устранении проблем проблем эхо удостоверьтесь, что телефоны, которые тестируются или исследуются, не используют динамик телефона и что им установили громкость гарнитуры в разумные уровни (запустите с 50 процентов максимального уровня громкости). Большую часть времени проблемы произойдут при приложении с PSTN посредством цифрового или аналогового шлюза. Пользователи Cisco IP Phone могут жаловаться, что слышат свой собственный голос, отражаемый назад им. Несмотря на то, что истинный источник проблемы почти всегда на дальнем конце, почти всегда невозможно изменить что-либо в PSTN. Так, первый шаг должен определить, какой шлюз используется. Если цифровой шлюз используется, может быть возможно добавить дополнительное заполнение данными в направлении передачи (к PSTN) в надеждах, что мощность более низкого сигнала приведет к меньшему количеству отраженной энергии. Кроме того, можно отрегулировать получить уровень так, чтобы любое отраженное аудио было уменьшено еще больше. Очень важно не забыть вносить маленькие корректировки за один раз. Слишком много затухания сигнала сделает аудио невозможным услышать с обеих сторон. Также можно связаться с носителем и запросить проверить линии. На типичном канале T1/PRI в Северной Америке входящий сигнал должен составить-15 дБ. Если уровень сигнала будет намного выше (-5 дБ, например), то эхо будет вероятным результатом.

Поддержите журнал всех вызовов то эхо опыта. Время проблемы, исходного номера телефона и вызванного количества должно все быть зарегистрировано. Шлюзы имеют установленное время 16 мс подавления эха. Если задержка отраженного аудио более длинна, чем это, канцлер эха будет неспособен работать должным образом. Это не должно быть проблемой для локальных вызовов, и междугородним вызовам нужно встроить канцлеров внешнего эхокомпенсатора в сеть в центральной АТС. Это - одна из причин, почему важно обратить внимание на внешний телефонный номер вызова, который испытывает эхо.

Проверьте загрузки

Шлюз и нагрузки телефона должны быть проверены. Проверьте CCO (Cisco Connection Online в www.cisco.com) для загрузок последних версий программного обеспечения, новых исправлений или Комментариев к выпуску, касающихся проблемы.

Односторонняя передача аудиоданных или никакое аудио

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

Существует много причин для односторонней передачи аудиоданных или никакого аудио во время вызова. Наиболее распространенной причиной является неправильно-настроенное-устройство. Например, Сisco CallManager обрабатывает настройку вызова для Cisco IP Phone. Фактический аудиопоток происходит между этими двумя Cisco IP Phone (или между Cisco IP Phone и шлюзом). Так, полностью возможно, что Сisco CallManager в состоянии сигнализировать к телефону получателя (заставляющий его звонить), когда телефон, инициирующий вызов, не имеет IP route к телефону получателя. Когда шлюз по умолчанию в телефоне неправильно настроен (вручную или на сервере протокола динамической конфигурации узла (DHCP)), это обычно происходит.

Если вызов последовательно имеет одностороннюю передачу аудиоданных, попытайтесь пропинговать целевой Cisco IP Phone с помощью ПК, который находится в той же подсети как телефон и имеет тот же шлюз по умолчанию. Возьмите ПК, который находится в той же подсети как телефон получателя (с тем же шлюзом по умолчанию как телефон получателя), и пропингуйте исходный телефон. Оба из тех тестов должны работать. На аудиотрафик могут также влиять межсетевой экран или фильтр пакета (такой как списки доступа на маршрутизаторе), который может блокировать аудио в одном или обоих направлениях. Если односторонняя передача аудиоданных происходит только через с поддержкой голоса шлюз Cisco IOS, проверьте конфигурацию тщательно. IP routing должен быть включен (исследуйте конфигурацию, чтобы удостовериться, что никакая IP маршрутизация не найдена около начала конфигурации). Кроме того, при использовании Сжатия заголовка RTP для сохранения пропускной способности по глобальной сети (WAN), удостоверьтесь, что это включено на каждом голосовом трафике переноса маршрутизатора, который подключает к каналу глобальной сети (WAN). Не должно быть ситуации, где заголовок RTP сжат на одном конце, но не может быть распакован с другой стороны глобальной сети (WAN). Анализатор очень полезный инструмент при устренении проблем односторонней передачи аудиоданных, потому что можно проверить, что телефон или шлюз фактически передают или получают пакеты. Диагностические КОМАНДИРЫ полезны в определении, если вызов испытывает одностороннюю передачу аудиоданных, потому что они регистрируют переданный, и полученные пакеты (обратитесь к Потерянному или Искаженному Аудио). Можно также нажать кнопку меня дважды (быстро) на Cisco IP Phone 7960 во время активного вызова, чтобы посмотреть детали о переданном и полученных пакетах.

Примечание: Когда вызов будет отключен звук (кнопка отключения звука, нажатая по телефону), никакие пакеты не будут переданы. Клавиша временного останова останавливает аудиопоток, таким образом, никакие пакеты не переданы ни в одном направлении. Когда Клавиша временного останова освобождена, все счетчики пакетов перезагружены. Помните, что Подавление пауз должно быть отключено на обоих устройствах для TX и счетчиках RX для пребывания равным. Отключение Подавления пауз в масштабе всей системы не будет влиять на шлюзы Cisco IOS.

MTP и односторонняя передача аудиоданных

При использовании Media Termination Point (MTP) в вызове (для поддержки дополнительных сервисов тех, которые держат и передают с устройствами H.323, которые не поддерживают версию 2 H.323), проверьте, чтобы видеть, работает ли выделенный MTP правильно. Маршрутизаторы Cisco IOS поддерживают версию 2 H.323, начинающуюся в NA выпуска 11.3 (9) и 12.0 (3) T. Начиная с Cisco IOS Release 12.0 (7) T, Открывается/Закрывает дополнительный H.323, LogicalChannel поддерживается, так, чтобы программный MTP больше не требовался для дополнительных сервисов.

Устройство MTP, а также Мост конференц-связи и перекодировщик, соединит два или больше аудиопотка. Если MTP, Мост конференц-связи или перекодировщик не работают должным образом, односторонняя передача аудиоданных или потери аудио-сигнала могли бы быть испытаны. MTP завершения работы, чтобы узнать, причиняет ли MTP проблему.

Телефон перезагружается

Телефоны подвергнут циклу включения и выключения питания или перезагрузят по одной из придерживающихся двух причин:

  • Сбой TCP, соединяющийся с Сisco CallManager, или

  • Сбой для получения подтверждения к Сообщениям поддержки активности телефона.

Ниже шаги для устранения проблем телефонного сброса:

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

  2. Проверьте CCO (Cisco Connection Online в www.cisco.com) для загрузок последних версий программного обеспечения, новых исправлений или Комментариев к выпуску, касающихся проблемы.

  3. Проверьте Просмотр событий для экземпляров сброса телефона (ов). Телефонный сброс считают Информационными событиями, как показано в следующем рисунке.

    /image/gif/paws/30266/event_prop.gif

  4. Ищите их и любые ошибки, которые, возможно, произошли примерно в то время, когда сброс телефона (ов).

  5. Запустите след SDI и попытайтесь изолировать проблему путем определения любых общих характеристик в телефонах, которые перезагружают. Например, проверьте, расположены ли они все в той же подсети, той же VLAN, и т.д. Посмотрите на след и определите если:

    • сброс происходит во время вызова или происходит периодически, или

    • существуют любые общие черты модели телефона: Cisco IP Phone 7960, Cisco IP Phone 30VIP, и т.д.

  6. Запустите Отслеживание средств прослушивания по телефону, который часто перезагружает. После того, как это перезагрузило, посмотрите на след, чтобы определить, существует ли какое-либо появление повторных попыток TCP. Если так, это указывает на проблему сети. След может показать некоторую непротиворечивость в сбросе, таком как телефон, перезагружающий каждые семь дней. Это могло бы указывать на истечение аренды DHCP каждые семь дней (это значение настраиваемо и могло быть каждые две минуты, и т.д.).

Сброшенные вызовы

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

Первый шаг должен определить, изолирована ли эта проблема к одному телефону или группе телефонов. Возможно, телефоны, на которые влияют, - все на конкретной подсети или местоположении. Следующий шаг должен проверить Просмотр событий для сброса шлюза или телефона.

/image/gif/paws/30266/drop_call.gif

Должно быть Предупреждение того и одно Сообщение об ошибках для каждого телефона, который перезагружает. В этом случае проблема часто в том состоит, что телефон не может поддержать свой TCP - подключение к Сisco CallManager живым, таким образом, Сisco CallManager перезагружает соединение. Это может быть то, потому что телефон был выключен или в сети может быть проблема. Если это - периодическая проблема, может быть полезно использовать вкладку Быстродействие в Microsoft Windows для записи регистраций телефона.

/image/gif/paws/30266/drop_call2.gif

Если проблема, кажется, происходит только через определенный, некоторый шлюз, такой как DT-24 Доступа Cisco +, лучший курс действий должен позволить отследить и/или просмотреть КОМАНДИРОВ. Файлы CDR дадут Причину завершения (COT), которая может помочь определять причину проблемы.

drop_call3.gif

Значения причины разъединения (origCause_value и destCause_value, в зависимости от которого сторона зависла вызов), карта с кодами причины разъединения Q.931 (в десятичном числе), который может быть найден в Типах коммутатора ISDN, Кодах и Значениях. В приведенном выше примере причина 16 относится к обычному сбросу вызова. Если вызов выходит шлюз в PSTN, CDR может использоваться для определения, какая сторона вешает вызов. Большая часть той же информации может быть получена путем включения отслеживающий на Сisco CallManager. Используйте программное средство следа только как последнее прибежище или если еще не работает сеть.

Проверьте загрузки

Как с любой проблемой, проверьте телефон и загрузки шлюза и CCO (Cisco Connection Online в www.cisco.com) для загрузок последних версий программного обеспечения, новых исправлений или Комментариев к выпуску, касающихся проблемы.

Проблемы с Cisco CallManager

Проблемы могут произойти с функциями, такими как Мост конференц-связи или Media Termination Point, которые используются в сочетании с Сisco CallManager. Некоторые из этих проблем функции вызваны ошибками конфигурации или отсутствием ресурсов. Например, если заданный номер ресурсов Разовой конференции был превышен, пользователи могут не быть в состоянии к циркулярным вызовам. Когда пользователь попытался инициировать функцию конференции, результатом был бы разрыв связи. Это, могло казаться, было проблемой Функции Cisco CallManager, когда фактически это - проблема с количеством доступных циркулярных ресурсов. Число раз циркулярный ресурс требовался, но не доступный, является одним из счетчиков, вошел во вкладку Быстродействие в Microsoft Windows. То же поведение происходит, если существуют доступные циркулярные ресурсы, но остановился сервис конференц-связи.

Кодек/Области: Несоответствие кодека

Если пользователь получает сигнал занятости при использовании, это мог бы быть результат разногласия кодека между областями. Проверьте, что оба конца вызова поддерживают по крайней мере один стандартный кодек (например, G.711). В противном случае необходимо будет использовать перекодировщики.

Область задает диапазон поддерживаемых кодеков, которые могут использоваться с каждой из других областей. Каждое устройство принадлежит области.

Примечание: Согласование кодека с маршрутизатором Cisco IOS не поддерживается.

Region1 <-> Region2 = G.711 означает, что вызов между устройством в Region1 и устройством в Region2 может использовать G.711 или любой другой поддерживаемый кодек, который требует того же или меньшего количества пропускной способности как G.711 (любые поддерживаемые кодеки в G.711, G.729, G.723, и т.д.).

Примечание: Придерживающиеся кодеки поддерживаются для каждого устройства:

  • Cisco IP Phone 7960 G.711A-law/�-law, G.729AnnexB

  • Cisco IP Phone, серии SP12 и VIP 30 G.711A-law/�-law, G.723.1

  • DE30 Шлюза доступа Cisco и DT-24 + G.711A-law/�-law, G.723.1

Местоположения

Если пользователь получает сигнал занятости после набирания номера, это могло бы быть, потому что распределение пропускной способности Сisco CallManager для местоположения одного из конечных устройств вызова было превышено (меньше, чем 24k). Сisco CallManager проверяет для 24k доступной пропускной способности для каждого устройства перед звонком. Если меньше, чем 24k пропускная способность будут доступны, то Сisco CallManager не установит вызов, и пользователь услышит сигнал занятости.

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

Как только вызов установлен, Сisco CallManager вычитает пропускную способность из местоположений в зависимости от кодека, используемого в том вызове. Если вызов использует G.711, Сisco CallManager вычитает 80k; если вызов использует G.723, Сisco CallManager вычитает 24k; если вызов использует G729, Сisco CallManager вычитает 24k.

Мост конференц-связи

Используйте следующую информацию для помощи устранению проблем "Никакого Моста конференц-связи доступная" проблема. Это могло быть или программным обеспечением или неполадкой в оборудовании.

Во-первых, проверьте, чтобы видеть, есть ли у вас какие-либо доступные ресурсы Моста конференц-связи, зарегистрированные в Сisco CallManager (или программное обеспечение или аппаратные средства). Для этого можно использовать вкладку Быстродействие в Microsoft Windows для проверки количества "Индивидуальной рассылки AvailableConferences".

Программа речевой связи Cisco IP Voice Media выполняет функцию моста конференц-связи. Одна установка программного обеспечения Потоковой передачи Cisco IP Voice Media поддержит 16 Индивидуальных рассылок Доступные Конференции (3 человека/конференции), как показано в придерживающемся следе.

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

Один порт E1 (карта WS-X6608-E1 содержит 8x порты E1) предоставляет пять Индивидуальных рассылок Доступные Конференции (Max. размер конференции = 6), как показано в придерживающемся следе.

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

Придерживающийся аппаратный след на Cisco Catalyst 6000 8 T1/E1 Голосового модуля Port Voice и Сервисный модуль указывают, что порт E1 4/1 в карте зарегистрировался как Мост конференц-связи в Сisco CallManager.

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

Во-вторых, проверьте максимальное число настроек пользователя на конференции (Оперативно или MeetMe), чтобы определить, произошла ли проблема, потому что было превышено это количество.

Проблемы перекодировки

Если вы установили аппаратный транскодер в Cisco Catalyst 6000 8 T1/E1 Голосового модуля Port Voice и Сервисный модуль, и это не работает как ожидалось (значение, что вы не можете выполнить вызовы между двумя пользователями без стандартного кодека), проверьте, чтобы видеть, есть ли у вас какие-либо доступные Ресурсы транскодера, зарегистрированные в Сisco CallManager (это должно быть аппаратными средствами). Используйте вкладку Быстродействие в Microsoft Windows для проверки количества доступного "MediaTermPointsAvailable".

Один порт E1 (карта WS-X6608-E1 содержит 8x порты E1) предоставляет ресурсы Transcoder/MTP для 16 вызовов, как показано в придерживающемся следе.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Придерживающийся аппаратный след на Cisco Catalyst 6000 8 T1/E1 Голосового модуля Port Voice и Сервисный модуль указывают, что порт E1 4/2 в карте зарегистрировался как MTP/перекодировщик в Сisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Примечание: Тот же порт E1 не может быть настроен и для Моста конференц-связи и для Transcoder/MTP

Для звонка между двумя устройствами с помощью кода Low Bit Rate (такими как G.729 и G.723), которые не поддерживают тот же кодек, ресурс транскодера требуется. Рассмотрите следующий рисунок:

/image/gif/paws/30266/ccm_ill.gif

Предположите, что Сisco CallManager был настроен так, что, кодек между Region1 и Region2 является G.729. Придерживающиеся сценарии возможны:

  • Если абонент по Телефону A инициирует вызов, Сisco CallManager понимает, что это - Cisco IP Phone 7960, который, оказывается, поддерживает G.729. После того, как цифры были собраны, Сisco CallManager решает, что вызов предназначен для Пользователя Д, который находится в Области 2. Так как целевое устройство также поддерживает G.729, вызов установлен, и аудио течет непосредственно между Телефоном A и Телефоном D.

  • Если абонент по Телефону B, у кого есть Cisco IP Phone 12SP +, должен был инициировать вызов Позвонить D, на этот раз Сisco CallManager поймет, что инициирующий телефон только поддерживает G.723 или G.711. Сisco CallManager должен был бы выделить ресурс перекодировки так, чтобы аудио текло как G.711 между Телефоном B и перекодировщиком, но как G.729 между перекодировщиком и Телефоном D. Если бы никакой перекодировщик не был доступен, телефон Телефонного D звонил бы, но как только вызову ответили, то вызов разъединил бы.

  • Если бы пользователь по Телефону B должен был вызвать Телефон F (Cisco IP Phone 12SP +), два телефона фактически использовали бы G.723, даже при том, что G.729 настроен как кодек для использования между областями. G.723 используется, потому что обе оконечных точки поддерживают его, и он использует меньше пропускной способности, чем G.729.

  • Если система голосовой почты Cisco uOne добавлена (который только поддерживает G.711), или маршрутизатор Cisco IOS, настроенный для G.711 к Области 1, то устройство транскодирования должно использоваться при вызове от Области 2. Если ни один не будет доступен, то вызов откажет.

Проблемы ресурса MTP

Проблемой ресурса MTP мог быть преступник, если вызов установлен, и дополнительные сервисы не доступны на устройстве H.323, которое не поддерживает H323v2. Во-первых, определите, есть ли у вас какие-либо доступные ресурсы MTP (или программное обеспечение или аппаратные средства) зарегистрированный в Сisco CallManager. Можно сделать так при помощи вкладки Быстродействие в Microsoft Windows для проверки количества "MediaTermPointsAvailable".

Software Application Support MTP 24 вызова (использующий MTP для поддержки дополнительные сервисы с устройствами H.323, которые не поддерживают H.323v2), как показано в придерживающемся следе.

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

Один порт E1 (карта WS-X6608-E1 содержит 8x порты E1) предоставляет ресурсы MTP для 16 вызовов, как показано в придерживающемся следе.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Придерживающийся аппаратный след, от Cisco Catalyst 6000 8 T1/E1 Голосового модуля Port Voice и Сервисный модуль, указывает, что порт E1 4/2 в карте зарегистрировался как MTP/перекодировщик в Сisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Во-вторых, посмотрите, установлен ли флажок Media Termination Point Required на экране Gateway Configuration Управления Cisco CallManager.

В-третьих, проверьте, что Сisco CallManager выделил нужное количество устройств MTP.

От файла SDI:

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

Планы дозвона

Схема набора номеров является списком количества (и группы количества), который говорит Сisco CallManager, к которым устройствам (телефоны, шлюзы, и т.д.) для передачи вызовов когда собрана определенная, некоторый строка цифр. Аналогом является таблица статической маршрутизации в маршрутизаторе. Будьте определенны, некоторый, которым понятия схемы набора номеров, базовую маршрутизацию вызова и планирование тщательно рассмотрели и должным образом настроили прежде, чем попытаться решить потенциальную проблему схемы набора номеров. Очень часто проблема связана с планированием и конфигурацией.

Рассмотрите придерживающиеся вопросы при устренении проблем схем набора номеров:

  • Что Номер каталога (DN) инициирует вызов?

  • Каково Пространство поиска вызова этого DN?

  • Если применимо, каково Пространство поиска вызова устройства (такого как Cisco IP Phone), к которому привязан DN? Удостоверьтесь, что вы определяете правильное устройство; появления нескольких линий поддерживаются, и возможно иметь DN на составных устройствах. Примечание Пространство поиска вызова устройства. Если вызов инициируется Cisco IP Phone, помните, что частичный канал (DN) и устройство, к которому привязана та линия, будет каждый иметь Пространства поиска вызова. Они будут объединены при звонке. Как пример, предположите, что экземпляр линии 1000 имеет Пространство поиска вызова AccessLevelX и Cisco IP Phone, которому настроили расширение 1000 на нем, имеет AccessLevelY как его Пространство поиска вызова. Поэтому при звонке от того появления линии, Сisco CallManager перероет отделения, содержавшиеся в AccessLevelX Пространства поиска вызова и AccessLevelY.

  • Какие отделения привязаны к Пространству (ам) поиска вызова?

  • Каково разделение устройства, к которому вызов должен (или не должен) идти?

  • Каков номер, который набирается? Примечание, если и когда абоненты получают дополнительный тональный сигнал на любом этапе. Кроме того, что слышат абоненты после того, как все цифры были введены (повторный заказ, короткий сигнал занято)? Они получают тональные сигналы о прохождении соединения, прежде чем они будут ожидать слышать что-нибудь? Удостоверьтесь, что абоненты ждут спустя по крайней мере 10 секунд после ввода последней цифры, так как им, вероятно, придется ждать межзнакового таймера для истечения.

  • Генерируйте Отчёт о Таблице маршрутизации в Управлении Cisco CallManager. Используйте его для исследования всех шаблонов маршрута на отделения, которые находятся в Пространстве поиска вызова для вызова.

  • Если необходимо, добавьте или модифицируйте Фильтры Маршрута или Шаблоны маршрута.

  • Если можно найти Шаблон маршрута, которому передается вызов, обратите внимание на Список маршрутов или шлюз, к которому указывает образец.

  • Для Списка маршрутов проверьте, какие Группы маршрутов являются частью списка и который шлюз (ы) часть Групп маршрутов.

  • Проверьте, что применяемые устройства зарегистрированы в Сisco CallManager.

  • Если нет никакого доступа к Сisco CallManager, заставьте технологию показа перехватывать эту информацию и проверять.

  • Не упустите знак. Это - макрос, который может расшириться для включения многих разных вещей. Это часто используется в сочетании с параметрами фильтра.

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

  • Если вы набираете внешний номер, который совпадает с 9. образец и это берут за 10 секунд до того, как вызов проходит через, проверьте параметры фильтра. 9. образец, при набирании 7-разрядного номера, будет (по умолчанию) ждать 10 секунд. Необходимо применить Фильтр Маршрута к образцу, который говорит LOCAL-AREA-CODE DOES-NOT-DOES-NOT-EXIST END-OF-DIALING и EXIST.

Отделения

Отделения маршрута наследовали возможности обработки ошибки Программного обеспечения Cisco СallManager. Т.е. консоль и след файла SDI предоставлены для регистрационной информации и сообщений об ошибках. Эти сообщения будут частью компонента анализа цифровой информации следов. Даже со следами ниже, понимание Отделений и конфигураций Пространств поиска вызова и какие устройства находятся в каждом разделении, вместе с его cвязанным пространством поиска вызова, жизненно важно в определении проблемы.

След ниже является примером номера, набранного, который находится в Пространстве поиска вызова устройства. Для большего количества подробных объяснений о следах SDI рассмотрите примеры практического применения в этом документе.

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

В компоненте Анализа цифровой информации следа (выше), "pss" (Пространство поиска разделения, также известное как Пространство поиска вызова), перечислен для устройства, размещающего вызов. Ниже, вы видите это "RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP" являются отделениями, которые этому устройству позволяют вызвать.

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

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

Ниже след, где количество, которое было предпринято, чтобы быть набранным (1001), не находится в Пространстве поиска вызова устройства. Снова, это является ключевым, что вы обращаете внимание, что подпрограмма анализа цифровой информации имела потенциальные соответствия до, только первая цифра была набрана. Шаблон маршрута, привязанный к цифре "1", находится в разделении, которое не находится в пространстве поиска вызова устройства, "RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP". Поэтому телефон передавался Сигнал занятости.

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

Отделения маршрута работают путем соединения имени раздела к каждому номеру каталога в системе. Номер каталога можно вызвать, только если вызывное устройство содержит разделение в списке отделений, к которым разрешено разместить вызовы в свое пространство поиска разделения. Это предоставляет чрезвычайно мощный контроль над маршрутизацией.

Когда вызов размещается, Анализ цифровой информации пытается решить набранный адрес только в тех отделениях, которые задает пространство поиска разделения. Каждое имя раздела включает дискретный поднабор адресного пространства глобального пространства адресов с возможностью вызова. От каждого перечисленного разделения Анализ цифровой информации получает образец что лучшие соответствия последовательность цифр набора. Затем из числа соответствующих образцов Анализ цифровой информации выбирает лучшее соответствие. Если два образца одинаково совпадают с последовательностью цифр набора, Анализ цифровой информации выбирает образец, привязанный к разделению, перечисленному сначала в пространстве поиска разделения (для получения дополнительной информации, рассмотрите документацию о Самом близком Match routing).

Безопасность

Сisco CallManager может быть настроен для создания безопасного плана нумерации для дозвона для пользователей. Это может быть сделано с помощью отделений и пространств поиска вызова, в дополнение к более общему фильтрованию на основе разделов макрос (который обозначает North American Numbering Plan) в шаблоне маршрута, таком как Код зоны. Отделения и Пространства поиска вызова являются составляющей часть безопасности и особенно полезны для сред с несколькими арендаторами и создания уровня отдельного пользователя. Фильтрация является подмножеством Пространства поиска вызова / понятие Разделения, которое может добавить дополнительную глубину детализации к плану обеспечения безопасности.

Это - расширение к разделу Схемы набора номеров, выше. Советуйте, не желательно выполнить след SDI при попытке решить проблему фильтрования. Существует недостаточно информации, и потенциал для того, чтобы нанести дополнительный ущерб является слишком большим.

Выполните технологию показа на Сisco CallManager. Следующая информация появляется в разделе Фильтра Маршрута.

Show tech
Name dialPlanWizardG Пункт
CiscoDallasInte 1 (МЕЖДУНАРОДНЫЙ -
CiscoRTPTollByP 1 (AREA-CODE == 9
CiscoRTPLongDis 1 (AREA-CODE EXIS
CiscoDallasToll 1 (AREA-CODE == 9
CiscoDallas911R 1 (СЕРВИС == 911
CiscoRTPLocal7D 1 (AREA-CODE ДЕЛАЕТ
CiscoDallasLong 1 (AREA-CODE EXIS
CiscoRTP911RF 1 (СЕРВИС == 911
CiscoRTPInterna 1 (МЕЖДУНАРОДНЫЙ -
CiscoDallasLoca 1 (LOCAL-AREA-COD

К сожалению, этот показ является неполным. Это действительно, однако, дает распечатку всего Маршрута, Просачивается система. Команда показа не позволяет вам видеть, какие фильтры привязаны к который Шаблон маршрута. Другой метод, чтобы лучше понять схему набора номеров должен перейти к странице Route Plan Report. Ниже опция на далекой правой стороне для "Просмотра В Файле".

file_dl.gif

Выходные данные будут разделенным от запятой файлом, который может быть просмотрен в Microsoft Excel или подобном приложении:

Выходные данные файла показывать-технологии
Образец/DN Разделение Использование образца Названия устройств Описание устройства
1000 Устройство SEP003094C2635E Telecaster
1010   Устройство SEP003094C2635E Telecaster
1111   Устройство SEP00308062CDF1 SEP00308062CDF1
1211   Устройство SEP00308062CDF1 SEP00308062CDF1
2999   Устройство SAA0010EB007FFE SAA0010EB007FFE
4444   Устройство SEP003094C26302 Гость
4500   Конференция  
9. CiscoRTPLocalPT Маршрут CiscoRTPLocalRL
9. CiscoDallasLocalPT Маршрут CiscoDallasLocalRL
9. CiscoRTPIntlPT Маршрут CiscoRTPIntlRL
9. CiscoDallasLongDistPT Маршрут CiscoDallasLongDistRL
9. CiscoRTP911PT Маршрут CiscoRTP911RL
9. CiscoRTPLongDistPT Маршрут CiscoRTPLongDistRL
9. CiscoTollByPassToDallasPT Маршрут CiscoTollByPassToDallasRL
9. CiscoDallasIntlPT Маршрут CiscoDallasIntlRL
9. CiscoDallas911PT Маршрут CiscoDallas911RL
9. CiscoTollByPassToRTPPT Маршрут CiscoTollByPassToRTPRL

Это показывает Шаблоны маршрута и их соответствующие отделения. Это не показывает Фильтры Маршрута или Пространства поиска вызова номеров каталога. Дополнительные сведения доступны на Отчёте о Плане фактического маршрута. Если необходимо связаться с Центром технической поддержки Cisco, необходимо передать эту страницу по электронной почте (если Сisco CallManager недоступен).

Ниже план Шаблонов маршрута, Отделений и Списка маршрутов / Группа/Шлюз Маршрута.

route_plan_rpt.gif

Медленный ответ сервера

Если дуплекс коммутатора не совпадает с дуплексом Cisco CallManager server, медленный ответ от сервера мог закончиться. Для оптимальной производительности, набор и коммутатор и сервер к "100/полный". Мы не рекомендуем использовать "Автоматический" или на коммутаторе или на сервере. Необходимо перезапустить Cisco CallManager server для изменения для вступления в силу.

Переупорядочение тоновых сигналов, проходящих через шлюзы

Пользователи, заказывающие телефонный разговор через шлюз, могли бы получить сигнал занятости, если они пытаются выполнить ограниченный вызов или вызвать количество, которое было заблокировано. Сигнал занятости может произойти, если набранный номер Out Of Service или если PSTN имеет оборудование или сервисную проблему. Убедитесь, что зарегистрировалось устройство, дающее сигнал занятости. Кроме того, проверьте конфигурацию схемы набора номеров, чтобы гарантировать, что может быть успешно направлен вызов.

Шаги для устранения проблем сигналов занятости через шлюзы:

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

  2. Проверьте CCO (Cisco Connection Online в www.cisco.com) для загрузок последних версий программного обеспечения, новых исправлений или Комментариев к выпуску, касающихся проблемы.

  3. Запустите след SDI и воссоздайте проблему. Сигналы занятости могли быть результатом проблемы конфигурации с основанным на местоположении контролем доступа или основанным на сторожевом устройстве контролем доступа, где Сisco CallManager мог бы ограничить количество допустимых вызовов. В следе SDI найдите вызов определить, было ли это заблокировано преднамеренно шаблоном маршрута или пространством поиска вызова, или каким-либо другим параметром конфигурации.

  4. Сигналы занятости могут также произойти при вызове через PSTN. Проверьте след SDI для сообщений разъединения Q.931. Если сообщение разъединения Q.931 присутствует, это означает, что другая сторона вызвала разъединение, и мы не можем исправить это.

Трудности при регистрации шлюза

Одна из наиболее распространенных проблем, с которыми встречаются со шлюзами на Сisco CallManager, является ошибкой регистрации. Регистрация может отказать по ряду причин.

Этот раздел имеет дело с двумя подобными, но другими, категориями шлюзов. AS-X Аналогового доступа, AT-X и DT-24 Цифрового доступа + и DE-30 + принадлежат одной категории. Эти шлюзы являются автономными устройствами, которые непосредственно не связаны с Процессором управления сетями (NMP). Вторая категория включает WS-X6624 Аналогового доступа и WS-X6608 Цифрового доступа. Эти шлюзы являются блейдами, установленными в шасси Catalyst 6000 с прямым подключением к NMP для контроля и statusing.

В примерах ниже, объясняемые сообщения определены с помощью полужирного текста. Это должно упростить для вас видеть. В фактических отображаемых выходных данных текст не является полужирным. Примеры от WS-X6624.

Первая вещь проверить состоит в том, что шлюз в порядке. Все шлюзы имеют светодиод "биения", который мигает 1--секундный на, 1--секундный прочь, когда программное обеспечение шлюза работает обычно. Если этот светодиод не закрывает глаза на все или мигает очень быстро, то программное обеспечение шлюза не работает. Обычно, это приведет к автоматической перезагрузке шлюза. Кроме того, это обычно для шлюза для сброса себя, если это не может завершить процесс регистрации приблизительно после 2 - 3 минут. Так, можно оказаться, посмотрели на светодиод биения, в то время как устройство перезагружает. Если обычный дьявольский образец не появляется через 10 - 15 секунд, то шлюз перенес серьезный сбой. На AS-X или шлюзе AT-X, светодиод биения является крайним справа показом зеленого индикатора на лицевой панели. На DT-24 + или DE-30 + шлюз, это - дальний слева красный светодиодный индикатор на верхнем краю карты. На WS-X6624 Аналогового доступа это - зеленый индикатор в блейде (не видимый от лицевой панели) на крайнем справа краю карты около передней стороны. Наконец, на WS-X6608 Цифрового доступа существует отдельный светодиод биения для каждого из 8 промежутков на блейде. Существует 8 красных светодиодных индикаторов по карте (не видимы от лицевой панели) о 2/3 пути к спине.

Вторая вещь проверить состоит в том, что шлюз получил свой IP-адрес. Одиночный шлюз должен получить свой IP-адрес через DHCP или BOOTP. Шлюз Catalyst может получить свой IP-адрес DHCP, BOOTP, или настройкой вручную через NMP. Если у вас есть доступ к DHCP server, лучший способ проверить, что одиночный шлюз должен проверить, что устройство имеет выдающийся арендный договор относительно IP-адреса. Если шлюз обнаруживается на сервере, это - хорошая индикация, но не категоричное. Удалите арендный договор в DHCP server, и затем перезагрузите шлюз. Если шлюз вновь появляется на сервере с арендным договором в течение нескольких минут, то все хорошо работает в этой области. В противном случае тогда любой, шлюз не может связаться с DHCP server (Разве маршрутизатор неправильно настроен и не передача широковещательных рассылок DHCP? Сервер работает?), или не может получить положительный отклик (Пул IP-адреса истощен?) . Если проверка этих предложений не приводит к ответу, используйте отслеживание средств прослушивания для определения определенной проблемы.

Для шлюза Catalyst 6000 необходимо удостовериться, что NMP может связаться со шлюзом. Можно проверить это путем попытки пропинговать его внутренний IP-адрес от NMP. IP-адрес находится в формате:

127.1.module.port

Так, в нашем примере мы сделали бы:

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

Если прозванивание будет работать, то команда show port будет адресная информация show IP. Удостоверьтесь информация о IP-адресе и IP-адрес TFTP корректны также. Если шлюз не в состоянии получать верную информацию DHCP, утилита Tracy (который может быть предоставлен Центром технической поддержки Cisco), может использоваться для определения проблемы. Выполните команду от CLI Cat6000:

порт mod tracy_start

В данном примере WS-X6624 является модулем 7, и это только имеет одиночные 860 процессоров, таким образом, это - порт 1. Команда, которую мы выполнили бы, является tracy_start 7 1

Следующий результат фактически от 860 консольных портов на самой плате шлюза. Однако выходные данные команды tracy являются не чем иным как удаленной копией 860 консольных портов.

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

Если вышеупомянутое сообщение о времени ожидания продолжает переходить, то существует проблема, связывающаяся с DHCP server. Проверьте, что порт шлюза Catalyst 6000 находится в корректной VLAN.

Эта информация находится в команде show-++ port до. Если DHCP server не находится на той же VLAN как шлюз Catalyst 6000, то удостоверьтесь, что соответствующие Вспомогательные IP - адреса были настроены для передачи запросов DHCP DHCP server. Для шлюза возможно застрять в Состоянии инициализации после изменения номера виртуальной локальной сети (VLAN) до сброса шлюза. Когда в этом состоянии, можно попытаться перезагрузить шлюз. Каждый раз, когда эти 860 перезагружены, сеанс Tracy будет проигран. Поэтому необходимо закрыть существующий сеанс и восстановить новый путем запуска следующих команд:

порт mod tracy_close

порт mod tracy_start

Если все это проверяет, и вы все еще видите DHCPState = сообщения INIT, то проверяете, чтобы видеть, функционирует ли DHCP server правильно. Если так, запустите отслеживание средств прослушивания, чтобы видеть, отправляются ли запросы и если отвечает сервер.

Как только DHCP работает правильно, шлюз будет иметь IP-адрес, который позволит использование утилиты отладки Tracy. Эта утилита является встроенной функцией набора команд NMP для Шлюзов Catalyst и доступна как вспомогательное приложение, которое работает на/NT/2000 Windows 98 для одиночных шлюзов. Для использования утилиты Tracy вспомогательного приложения необходимо "Соединиться" со шлюзом при помощи IP-адреса, на который это назначено. Это приложение tracy работает на все шлюзы, предоставляет отдельное окно следа для каждого шлюза (до восьми могут быть отслежены сразу), и позволяет следам быть зарегистрированными непосредственно к файлу, который вы задаете.

Следующий шаг должен проверить, что IP-адрес сервера TFTP был правильно предоставлен шлюзу. Это обычно предоставляется DHCP или в Опции 66 (по имени или в IP-адресе), Параметр 150 (Только IP-адрес), или si_addr (Только IP-адрес). Если серверу настроят составные опции, то si_addr будет иметь приоритет по Параметру 150, который будет иметь приоритет по Опции 66. Если Опция 66 предоставляет DNS_NAME TFTP server, то IP-адрес (а) сервера (ов) DNS, должно быть, был задан DHCP, и имя, введенное в Опции 66, должно решить к корректному IP-адресу сервера TFTP. Шлюз Catalyst мог быть настроен NMP для отключения DHCP, и оператор NMP должен тогда ввести все параметры конфигурации вручную в консоль, включая адрес сервера TFTP.

Кроме того, шлюзы будут всегда пытаться решить название "CiscoCM1" через DNS. Если успешный, IP-адрес CiscoCM1 будет иметь приоритет по чему-либо, DHCP server или NMP говорят его для адреса сервера TFTP, даже если NMP отключили DHCP.

Можно проверить текущий IP-адрес сервера TFTP в шлюзе при помощи утилиты Tracy. Введите следующую команду для получения количества задачи конфигурации:

TaskID: 0

Cmd: покажите временной предел

Ищите линию с "config" или "cfg" и используйте соответствующее количество в качестве taskID для следующей строки. Например, для шлюза WS-X6624 Цифрового доступа, команда для формирования дампа сведений DHCP:

TaskID: 6

Cmd: show dhcp

IP-адрес сервера TFTP тогда ясно показывают. Если это не корректно, проверьте, что параметры DHCP и другая информация, которую это предоставляет, корректны.

Как только адрес TFTP корректен, следующий шаг должен гарантировать, что шлюз получает свой файл конфигурации от TFTP server. Если вы видите придерживающееся в выходных данных tracy, Сервис TFTP может не работать правильно, или шлюз не мог бы быть настроен на Сisco CallManager:

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

Шлюз попытается соединиться с тем же IP-адресом как TFTP server, если это не получит файл конфигурации. Это прекрасно, пока вы не находитесь в кластерной среде, в которой шлюз должен получить свой список избыточных Сisco CallManager. Если карта не получает свою информацию TFTP правильно, проверьте Сервис TFTP на Сisco CallManager и удостоверьтесь, что это работает. Кроме того, проверьте след TFTP на Сisco CallManager также.

Другая типичная проблема - то, что шлюз не настроен правильно на Сisco CallManager. Типичная ошибка вводит неверный MAC - адрес для шлюза. Если это верно, для шлюза Catalyst 6000, вы будете, вероятно, получать следующие сообщения на консоли NMP каждые две минуты:

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

Это - то, на что были бы похожи выходные данные tracy, не находится ли шлюз в Базе данных Cisco CallManager:

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

Другая возможная ошибка регистрации могла быть то, если данные нагрузки являются неправильными, или файл загрузки поврежден. Проблема может также произойти, если сервер TFTP не работает. В данном случае tracy явным образом показывает, что согласно отчету сервера TFTP данный файл не найден:

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

В этом случае вы видите, что шлюз является загрузкой запрашивающего приложения A0021300, невзирая на то, что корректное загрузочное имя было бы A0020300. Когда загрузка нового приложения должна получить свою соответствующую загрузку DSP также, для шлюза Catalyst 6000 может произойти та же проблема. Если новая загрузка DSP не будет найдена, то подобное сообщение появится.

Когда WS-X6224 Аналогового доступа был настроен для получения неправильной загрузки приложения, придерживающееся показывает выходные данные. Выходные данные выглядят подобными тому из шлюза, который не был настроен на Сisco CallManager:

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

Различие здесь - то, что шлюз застревает на этапе LoadResponse и в конечном счете испытывает таймаут. Эта проблема может быть решена путем исправления имени файла загрузки в Области параметров по умолчанию для устройства Управления Cisco CallManager.

Проблемы привратника

Прежде, чем запустить любое устранение проблем передачи от шлюза к привратнику, проверьте, что существует возможность подключения с помощью IP-адреса в сети. Предположение, что существует возможность подключения с помощью IP-адреса, использует информацию в этом разделе для устранения проблем шлюза.

Межкластерные магистрали только

Обратите внимание на то, что контроль за сторожевым устройством для Релиза Cisco CallManager 3.0 (1) только доступен для межкластерных магистралей. Контроль за сторожевым устройством конфигурируем для других устройств, но не поддерживается конфигурация.

Отказы от приема (ARJ)

Когда Сisco CallManager зарегистрировался в Сторожевом устройстве, но не может передать телефонный звонок, ARJ выполнены. Когда сторожевое устройство выполняет ARJ, проблемы конфигурации на сторожевом устройстве должны быть основным вниманием. Однако ниже общие указания для устранения проблем:

  1. Проверьте возможность подключения с помощью IP-адреса от шлюза до сторожевого устройства.

  2. Show gatekeeper status: проверьте, что произошло состояние сторожевого устройства.

  3. Существует ли zone subnet, определенный на сторожевом устройстве? Если так, проверьте, что подсеть шлюза находится в позволенных подсетях.

Отказы в регистрации (RRJ)

Когда Сisco CallManager не может зарегистрироваться в Сторожевом устройстве, RRJ выполнены. Когда сторожевое устройство выполняет RRJ, проблемы конфигурации на сторожевом устройстве должны быть основным вниманием.

Однако вот общие указания для устранения проблем:

  1. Проверьте возможность подключения с помощью IP-адреса от шлюза до сторожевого устройства.

  2. Show gatekeeper status: проверьте, что произошло состояние сторожевого устройства.

  3. Существует ли zone subnet, определенный на сторожевом устройстве? Если так, проверьте, что подсеть шлюза находится в позволенных подсетях.

Учащенный сигнал "занято" при наборе сервисного номера голосовой почты

Если вы остановили и запустили Call Manager после внесения некоторых изменений, удостоверьтесь, что вы запускаете utel, ulite, ulogremover и процессы upilot. Это было протестировано в лабораторной работе предъявителем CM 2.4.3 и uone 4.1e. По существу устройства UM не будут повторно регистрировать с Call Manager, пока не будут перезапущены процессы.

Пример практического применения I: Внутрикластерные вызовы между IP-телефонами Cisco

Этот пример практического применения обсуждает подробно поток вызовов между двумя Cisco IP Phone в кластере, названном внутрикластерным вызовом. Этот пример практического применения также фокусируется на Сisco CallManager и инициализации Cisco IP Phone, регистрации и Процессах поддержки активности. Это придерживается подробным объяснением потока внутрикластерного вызова. Эти процессы объяснены с помощью служебных программ отслеживания и программных средств, обсужденных в предыдущем разделе.

Образец топологии

Придерживающаяся схема изображает пример топологии для этого примера практического применения. В схеме существует два кластера под названием Кластер 1 и Кластер 2. В то время как эти два Сisco CallManager в Кластере 1 называют CCM1 и CCM2, эти два Сisco CallManager в Кластере 1 называют CCM3 и CCM4. Следы, собранные для этого примера практического применения, от CCM1, который расположен в Кластере 2. Поток вызовов основывается на этих двух Cisco IP Phone в Кластере 2. IP-адреса этих двух Cisco IP Phone 172.16.70.230 (номер каталога 1000) и 172.16.70.231 (номер каталога 1001), соответственно.

ios_gatekeeper.gif

Процесс инициализации IP-телефона Cisco

Инициализация Cisco IP Phone (или "загружаются") процесс объяснена подробно ниже.

  1. В инициализации Cisco IP Phone отправляет запрос к DHCP server для получения IP-адреса, адреса сервера DNS, и названия TFTP server или адреса, в подходящих случаях. Опции установлены в DHCP server (Опция 066, Параметр 150, и т.д.). Это также получает адрес шлюза по умолчанию, если установлено в DHCP server (Опция 003).

  2. Если имя DNS TFTP разъединяет, передается DHCP, то DNS разъединяет IP-адрес, требуется, чтобы сопоставлять название к IP-адресу. Если DHCP server передает IP-адрес Tftp server, этот шаг обходится. В этом примере практического применения DHCP server передал IP-адрес TFTP, потому что не был настроен DNS.

  3. Если название TFTP server не включено в ответ DHCP, то Cisco IP Phone использует имя сервера по умолчанию.

  4. Файл конфигурации. cnf), файл получен от TFTP server. Все файлы .cnf имеют SEP названия <mac_address> .cnf, где "SEP" является акронимом для Телефона Ethernet Selsius. Если это первоначально, телефон регистрируется в Сisco CallManager, то файл по умолчанию, SEPdefault.cnf, загружен к Cisco IP Phone. В этом примере практического применения первый Cisco IP Phone использует IP-адрес 172.16.70.230 (его MAC-адрес является SEP0010EB001720), и второй Cisco IP Phone использует IP-адрес 172.16.70.231 (его MAC-адрес является SEP003094C26105).

  5. Все файлы .cnf включают IP-адрес (а) основного и вторичного Сisco CallManager (). Cisco IP Phone использует IP-адрес для контакта с первичным Cisco CallManager и регистром.

  6. Как только Cisco IP Phone соединился и зарегистрировался в Сisco CallManager, Сisco CallManager говорит Cisco IP Phone который исполнимая версия (названный идентификатором нагрузки) работать. Если указанная версия не совпадет с выполняющейся версией на Cisco IP Phone, то Cisco IP Phone запросит новый исполняемый файл от TFTP server и перезагрузит автоматически.

Следующий пример Отслеживания средств прослушивания суммирует процесс инициализации телефона. Этот пример трассировки не взят для примера топологии этого примера практического применения, но это действительно предоставляет пример серий событий, которые происходят во время процесса инициализации Cisco IP Phone.

sniffer_trace.gif

Процесс регистрации Skinny Station

Cisco IP Phone связываются с Сisco CallManager с помощью Протокола облегченной станции Cisco. Процесс регистрации позволяет Облегченную станцию, такую как Cisco IP Phone, чтобы сообщить Сisco CallManager о его существовании и сделать вызов возможным. Придерживающиеся данные показывают другие сообщения, которыми обмениваются между Cisco IP Phone ("станция") и Сisco CallManager.

/image/gif/paws/30266/skinny.gif

Первичные сообщения в процессе регистрации Облегченной станции описаны в следующей таблице.

Описания процесса регистрации облегченной станции
Сообщение Описание
Регистр станции Станция передает это сообщение для объявления о его существовании управлению Сisco CallManager.
Сброс станции Сisco CallManager передает это сообщение, чтобы дать команду, чтобы станция перезагрузила свои процессы.
Порт IP станции Станция передает это сообщение для обеспечения Сisco CallManager портом протокола пользовательских датаграмм (UDP), который будет использоваться с потоком RTP.
Регистр станции подтверждает Сisco CallManager передает это сообщение для подтверждения регистрации станции.
Отклонение регистра станции Сisco CallManager передает это сообщение для отклонения регистрационной попытки с обозначенного телефона.
char text[StationMaxDisplayTextSize]; 

};
Где: text является символьной строкой, максимальной длиной 33 байтов, содержа текстовое описание причины, что отклонена регистрация.
Запрос возможностей станции Сisco CallManager передает это сообщение для запроса текущих возможностей станции. Возможности станции могут включать стандарт сжатия и другие возможности H.323.
Запрос версии станции Станция передает это сообщение для запроса номера версии загрузки ПО для станции.
Ответ версии станции Сisco CallManager передает это сообщение для информирования станции соответствующего номера версии программного обеспечения.
Ответ возможностей станции Станция передает это сообщение к Сisco CallManager в ответ на Запрос Возможностей Станции. Возможности станции кэшируются в Сisco CallManager и используются для согласования о возможностях оконечного устройства с совместимым терминалом H.323.
Запрос шаблона кнопки станции Станция передает это сообщение для запроса определения шаблона кнопки на тот определенный терминал или Cisco IP Phone.
Ответ шаблона кнопки станции Сisco CallManager передает это сообщение для обновления информации о шаблоне кнопки, содержавшейся в станции.
Запрос даты времени станции Станция передает это сообщение для запроса текущей даты и времени на internal usage и на показ как текстовая строка.
Станция определяет время и дату Сisco CallManager использует это сообщение для предоставления информации о дате и времи станции. Это предоставляет временную синхронизацию для станций.

Поток вызовов между IP-телефонами Cisco внутри кластера

В этом разделе описываются Cisco IP Phone (номер каталога 1000) вызывающий другой Cisco IP Phone (номер каталога 1001) в том же кластере. Кластер является группой Сisco CallManager, имеющих одну общую базу данных SQL издателя и много Баз данных SQL подписчика.

В нашем примере топологии CCM1 является издателем, и CCM2 является абонентом. Эти два Cisco IP Phone (1000 и 1001) зарегистрированы к CCM1 и CCM2, соответственно. Поток вызовов показывают в приведенном ниже рисунке. Эти два Сisco CallManager в кластере связываются друг с другом использующим Внутрикластерный протокол управления (ICCP). Когда Cisco IP Phone используется, он открывает сеанс Облегченной станции контроля (с TCP как базовый протокол) с Сisco CallManager. После того, как сигнализация управления вызовами установлена между этими двумя Cisco IP Phone и их соответствующими Сisco CallManager, поток RTP начинает течь непосредственно между двумя телефонами, как показано в приведенном ниже рисунке. Сообщения Потока вызовов облегченной станции для этого внутрикластерного вызова объяснены в следующем разделе.

/image/gif/paws/30266/1000_calls_1001.gif

Обмен сообщениями между облегченными станциями IP-телефонов Cisco в потоке вызовов

Придерживающиеся данные показывают типовой обмен сообщениями между двумя Облегченными станциями. Облегченная станция или Cisco IP Phone, инициирует соединение с Сisco CallManager, и затем Сisco CallManager выполняет анализ цифровой информации прежде, чем открыть сеанс контроля с целевой Облегченной станцией. Как придерживающаяся схема указывает, Сообщения облегченной станции записаны с помощью простого английского языка, таким образом, они могут быть с готовностью поняты под конечными пользователями. Из-за этого эти сообщения не объяснены в этом разделе. Когда следы исследуются, Однако эти Сообщения облегченной станции потока вызовов объяснены более подробно в последующих разделах.

/image/gif/paws/30266/call_flow.gif

Процесс инициализации Cisco CallManager

В этом разделе процесс инициализации Сisco CallManager будет объяснен с помощью следов, которые перехвачены от CCM1 (определенный IP-адресом 172.16.70.228). Как описано ранее, следы SDI очень программное средство эффективного устранения проблем, потому что они детализируют каждый пакет, переданный между оконечными точками. Этот раздел опишет события, которые происходят, когда инициализируется Сisco CallManager. Понимание, как считать след, помогает вам должным образом устранять неполадки различных процессов Сisco CallManager и эффекта тех процессов на сервисах, таких как конференц-связь, переадресация вызовов, и т.д.

Следующие сообщения от служебной программы отслеживания SDI Сisco CallManager показывают процесс инициализации на одном из Сisco CallManager, в этом случае, CCM1. Рассмотрите описания каждого сообщения ниже.

  • Первое сообщение указывает, что Сisco CallManager запустил свой процесс инициализации.

  • Второе сообщение указывает, что Сisco CallManager считал значения базы данных по умолчанию, которые были бы основным или базой данных сервера публикаций (для этого случая).

  • Третье сообщение указывает, что Сisco CallManager слушал различные сообщения на порту TCP 8002.

  • Четвертое сообщение показывает, что после слушания этих сообщений Сisco CallManager добавил второй Сisco CallManager к своему списку: CCM2 (172.16.70.229).

  • Пятое сообщение указывает, что Сisco CallManager запустил и выполняет Версию Cisco CallManager 3.0.20.

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database 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.0(0.20)> started

Самозапускающиеся процессы

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

Например, предположите, что списки маршрутов не функционируют и неприменимы. Для устренения этой проблемы вы контролировали бы эти следы, чтобы определить, запустил ли Сisco CallManager RoutePlanManager и если это пытается загрузить списки маршрутов. В примере конфигурации ниже, RouteListName = 'ipwan'' и 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''

Придерживающийся след показывает RouteGroup, добавляющий устройство 172.16.70.245, который является CCM3, расположенным в Кластере 1, и рассмотрел устройство H.323. В этом случае RouteGroup создан для маршрутизации вызовов к CCM3 в Кластере 1 с разрешениями Сторожевого устройства Cisco IOS. Если бы существует проблема, направляющая вызов к Cisco IP Phone, расположенному в Кластере 1, то следующие сообщения помогли бы вам находить причину проблемы.

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

Часть процесса инициализации показывает, что Сisco CallManager добавляет DN. Путем рассмотрения этих сообщений можно определить, считал ли Сisco CallManager номер каталога из базы данных.

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

В придерживающихся следах Менеджер устройств в Сisco CallManager статически инициализирует два устройства. Устройство с IP-адресом 172.17.70.226 является сторожевым устройством, и устройством с IP-адресом 172.17.70.245 является другой Сisco CallManager в другом кластере. Тот Сisco CallManager зарегистрирован как Шлюз H.323 с этим Сisco CallManager.

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

Процесс регистрации Cisco CallManager

Другая важная часть следа SDI является процессом регистрации. Когда устройство включено, оно получает информацию через DHCP, подключения к TFTP server для его файла .cnf, и затем соединяется с Сisco CallManager, заданным в файле .cnf. Устройством мог быть Шлюз MGCP, Тонкий шлюз или Cisco IP Phone. Поэтому важно быть в состоянии обнаружить, зарегистрировались ли устройства успешно в сети Cisco AVVID.

В придерживающемся следе Сisco CallManager получил новые соединения для регистрации. Регистрирующиеся устройства являются "MTP_nsa-cm1" (сервисы MTP на CCM1), и "CFB_nsa-cm1" (Сервис моста конференц-связи на CCM1). Они - программные сервисы, работающие на Сisco CallManager, но обработаны внутренне как другие внешние сервисы и поэтому назначены TcpHandle, номер сокета, и номер порта, а также имя устройства.

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

В придерживающемся следе Сообщения облегченной станции передаются между Cisco IP Phone и Сisco CallManager. Cisco IP Phone (172.16.70.231) регистрируется в Сisco CallManager. Сошлитесь на описания Сообщений облегченной станции ранее в этом разделе для получения дополнительной информации. Как только Сisco CallManager получает запрос регистрации от Cisco IP Phone, это назначает количество TcpHandle на это устройство. Это количество остается тем же, пока не перезапущены устройство или Сisco CallManager. Поэтому можно придерживаться всех событий, отнесенных к конкретному устройству путем поиска или отслеживания количество TcpHandle устройства, которое появляется в hex. Кроме того, заметьте, что Сisco CallManager предоставляет идентификатор нагрузки Cisco IP Phone. На основе этого идентификатора нагрузки Cisco IP Phone выполняет исполняемый файл (полученный от TFTP server), который соответствует устройству.

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Процесс проверки активности Cisco CallManager

И станция, устройство, или сервис и Сisco CallManager используют следующие сообщения для поддержания знания канала передачи между ними. Сообщения используются для начала последовательности KeepAlive, которая гарантирует, что коммуникационный канал между Сisco CallManager и станцией остается активным. Следующие сообщения могут произойти или из Сisco CallManager или из станции.

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

Сообщения в придерживающемся следе изображают последовательность KeepAlive, которая указывает, что коммуникационный канал между Сisco CallManager и станцией активен. Снова, эти сообщения могут произойти или Сisco CallManager или станцией.

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Трассировка потока внутрикластерных вызовов Cisco CallManager

Придерживающиеся следы SDI исследуют подробно поток внутрикластерного вызова. Cisco IP Phone в потоке вызовов могут быть определены DN, tcpHandle и IP-адресом. Cisco IP Phone (DN=1001, tcpHandle=0x4fbbc30, IP address=172.16.70.231) расположенный в Кластере 2 вызывает другой Cisco IP Phone в том же Кластере (DN=1000, tcpHandle = 0x4fbb150, IP-адрес = 172.16.70.230). Помните, что можно придерживаться устройства через след путем рассмотрения значения маркера TCP, штампа времени или названия устройства. Значение маркера TCP для устройства остается тем же, пока устройство не перезагружено или идет офлайн.

Придерживающиеся следы показывают, что использовался Cisco IP Phone (1001). След ниже показов уникальные сообщения, маркер TCP и вызываемый номер, которые отображены на Cisco IP Phone. На этом этапе нет никакого вызывающего номер, потому что пользователь не попытался набрать любые цифры. Информация ниже находится в форме Сообщений облегченной станции между Cisco IP Phone и Сisco CallManager.

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

Следующий след показывает Сообщения облегченной станции, идущие от Сisco CallManager до Cisco IP Phone. Первое сообщение должно включить лампу на Cisco IP Phone вызывающей стороны.

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Сообщение stationOutputCallState используется Сisco CallManager для уведомления станции определенной, некоторый связанной с вызовом информации.

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

Сообщение stationOutputDisplayPromptStatus используется Сisco CallManager, чтобы заставить связанную с вызовом подсказку быть отображенной на Cisco IP Phone.

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

Сообщение stationOutputSelectSoftKey используется Сisco CallManager, чтобы заставить Облегченную станцию выбирать определенный набор программируемых клавиш.

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

Следующее сообщение используется Сisco CallManager для инструктирования Облегченной станции относительно корректного контекста линии для показа.

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

В следующем сообщении процесс анализа цифровой информации готов определить входящие знаки и проверить их для потенциальных соответствий маршрутизации в базе данных. Запись, cn=1001, представляет номер вызывающего абонента. dd = "" представляет цифры набора, которые показали бы вызванный номер изделия. Обратите внимание на то, что сообщения инициализации станции передаются телефоном, сообщения StationD передаются Сisco CallManager, и анализ цифровой информации выполнен Сisco CallManager.

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

Придерживающееся сообщение отладки показывает, что Сisco CallManager предоставляет внутренний тональный сигнал готовности к набору номера Cisco IP Phone вызывающей стороны.

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

Как только Сisco CallManager обнаруживает входящее сообщение и распознает, что кнопка клавиатуры 1 была нажата на Cisco IP Phone, это сразу останавливает выходной тон.

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

Как только Сisco CallManager получил достаточно цифр для соответствия, он предоставляет результаты анализа цифровой информации в формате таблицы. Любые дополнительные цифры, нажатые по телефону после этой точки, будут проигнорированы Сisco CallManager, так как было уже найдено соответствие.

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

Следующий след показывает, что Сisco CallManager отсылает эту информацию в телефон вызываемой стороны (телефон определен количеством tcpHandle).

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

Следующий след указывает, что Сisco CallManager упорядочивает лампу мигать для индикации входящего вызова на Cisco IP Phone вызываемой стороны.

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

В придерживающихся следах Сisco CallManager предоставляет вызывное устройство, экранное уведомление и другую связанную с вызовом информацию к Cisco IP Phone вызываемой стороны. Снова, вы видите, что все сообщения направлены к тому же Cisco IP Phone, потому что тот же tcpHandle используется всюду по следам.

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Заметьте, что Сisco CallManager также предоставляет подобную информацию Cisco IP Phone вызывающей стороны. Снова, tcpHandle используется для дифференциации между Cisco IP Phone.

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

В следующем следе Сisco CallManager предоставляет предупреждающий тоновый сигнал или тональный сигнал вызова к Cisco IP Phone вызывающей стороны, уведомляя, что было установлено соединение.

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

На этом этапе Cisco IP Phone вызываемой стороны используется. Поэтому Сisco CallManager прекращает генерировать тон вызывного устройства к вызывающей стороне.

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

В следующих сообщениях Сisco CallManager заставляет Облегченную станцию начинать получать поток RTP Индивидуальной рассылки. Для этого Сisco CallManager предоставляет IP-адрес вызываемой стороны, а также сведений о кодеке и размера пакета в msec (миллисекунды). PacketSize является целым числом, содержащим интервал дискретизации в миллисекундах, используемых для создания пакетов RTP.

Примечание: Это значение обычно устанавливается в 30 мс. В этом случае это установлено в 20 мс.

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Точно так же Сisco CallManager предоставляет сведения к вызываемой стороне (1000).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Сisco CallManager получил сообщение подтверждения от вызываемой стороны для установления открытого канала для потока RTP, а также IP-адреса вызываемой стороны. Это сообщение должно сообщить Сisco CallManager двух частей информации об Облегченной станции. Во-первых, это содержит статус открытого действия. Во-вторых, это содержит получить адрес порта и количество для передачи к удаленному концу. IP-адрес передатчика (вызывающий часть) потока RTP является ipAddr, и PortNumber является номером порта IP потокового передатчика RTP (вызывающая сторона).

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

Следующие сообщения используются Сisco CallManager, чтобы упорядочить станцию начинать передавать аудиопоток к IP-адресу и номеру порта обозначенного удаленного Cisco IP Phone.

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

В придерживающихся следах ранее объясненные сообщения передаются вызываемой стороне. Эти сообщения придерживаются сообщениями, указывающими, что поток мультимедиа RTP начался между вызываемыми и вызывающими сторонами.

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Cisco IP Phone вызывающей стороны наконец кладет трубку, который завершает все управляющие сообщения между Облегченной станцией и Сisco CallManager, а также потоком RTP между Облегченными станциями.

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

ILS примера практического применения: Звонки с IP-телефона Cisco на IOS-шлюз

В предыдущем примере практического применения поток вызовов и методики поиска и устранения проблем внутрикластерного вызова были обсуждены подробно. Этот пример практического применения исследует Cisco IP Phone, звонящий через шлюз Cisco IOS к телефону, связанному через локальную УАТС или где-нибудь на PSTN. Концептуально, когда вызов достигает шлюза Cisco IOS, шлюз переведет вызов или к телефону, "зависающему" прочь его порта станции внешнего обмена (FXS), или к УАТС. Если вызов переведен к УАТС, он мог бы завершиться к телефону, "зависающему" прочь локальной УАТС, или УАТС передаст его по PSTN, и вызов завершится где-нибудь на PSTN.

Образец топологии

Придерживающаяся схема показывает пример топологии для этого примера практического применения. Вызовы направлены через шлюзы Cisco IOS и интерфейс к PSTN, или УАТС является или T1/CAS или T1/PRI. Шлюзы могут быть моделями 26XX, 36XX, 53XX или 6K.

/image/gif/paws/30266/ios_gatekeeper2.gif

Трассы потоков звонков

В этом разделе рассматриваются поток вызовов через примеры от файла CCM000000000 Трассировки Cisco CallManager (обратитесь к предыдущему разделу для местоположения файла). Следы в этом примере практического применения фокусируются только на самом потоке вызовов, поскольку более подробная информация о трассировке была уже объяснена в предыдущем примере практического применения (инициализация, регистрация, Механизм поддержки активности, и т.д.).

В этом потоке вызовов Cisco IP Phone (номер каталога 1001) расположенный в кластере 2 вызывает телефон (номер каталога 3333) расположенный где-нибудь на PSTN. Помните, что можно придерживаться устройства через след путем рассмотрения значения маркера TCP, штампа времени или названия устройства. Значение маркера TCP для устройства остается тем же, пока устройство не перезагружено или идет офлайн.

В придерживающихся следах использовался Cisco IP Phone (1001). След показывает уникальные сообщения, маркер TCP и вызывающего номер, который отображен на Cisco IP Phone. Нет никакого вызываемого номера на этом этапе, потому что пользователь не попытался набрать любые цифры.

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

В придерживающихся следах пользователь набирает эти 3333, одна цифра за один раз. Количество 3333 является назначенным номером телефона, который расположен где-нибудь на сети PSTN. Процесс анализа цифровой информации Сisco CallManager в настоящее время активен и анализирует цифры для обнаружения, где должен быть направлен вызов. Больше подробного объяснения анализа цифровой информации было предоставлено в предыдущем примере практического применения.

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

В придерживающихся следах был завершен анализ цифровой информации, с вызывающей и вызываемой стороной совпали, и информация была проанализирована.

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

В придерживающихся следах количество 0 указывает на инициирующее местоположение, и количество 1 указывает на размещение получателя. Пропускная способность инициирующего местоположения определена BW = 1. Значение 1 подразумевает, что пропускная способность бесконечна. Пропускная способность бесконечна, потому что вызов инициировался из Cisco IP Phone, расположенного в среде локальной сети. Пропускная способность размещения получателя определена BW = 64. Получатель вызова к телефону, расположенному в PSTN, и тип кодека используется, G.711 (64 Кбит/с).

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

Придерживающиеся следы показывают информацию о вызывающей и вызываемой стороне. В данном примере имя и номер вызывающей стороны является тем же, потому что администратор не настроил название показа, такое как "Джон Смит".

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

Прежде, чем рассмотреть придерживающиеся следы, важно понять H.323 значения слова. Посредством краткого объяснения существует несколько протоколов, которые используются при установлении сеанса H.323. Один протокол является H.225, который прежде всего используется для передачи вызовов и является подмножеством Q.931. Другой протокол является H.245, который используется для обмена возможности. Одной из более важных функций H.245 является Компрессор/Декомпрессор (кодек) согласование типа, такое как G.711, G.729, и т.д., между вызовом и вызванной стороной. Как только обмен возможности завершен, следующая важная функция H.245 выполняет согласование порта UDP между вызовом и вызванными сторонами.

Придерживающийся след показывает, что код H.323 инициализировался и передает сообщение SETUP H.225. Можно также видеть традиционные Сообщения SAPI HDLC, IP-адрес вызванной стороны в hex и номера портов.

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

Придерживающийся след показывает информацию о вызывающей и вызываемой стороне, а также сообщение предупреждения H.225. Также показанный сопоставление шестнадцатеричного значения Cisco IP Phone к IP-адресу. 172.16.70.231 IP-адрес Cisco IP Phone (1001).

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

Придерживающийся след показывает тип сжатия, используемый для этого вызова (G.711 �-law).

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Как только сигнальное сообщение H.225 было передано, следующая часть H.323, инициализируйте: H.245. Придерживающийся след показывает информацию о вызывающей и вызываемой стороне и сообщения H.245. Заметьте, что значение маркера TCP совпадает с прежде, указывая, что это - продолжение того жя самого вызов.

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

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

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

Следующее сообщение показывает, что получается сообщение с положенной трубкой от Cisco IP Phone (1001). Как только сообщение с положенной трубкой получено, H.225 и Skinny сообщения разъединения передаются, и все сообщение H.225 замечено. Это заключительное сообщение указывает, что был завершен вызов.

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Сообщения отладки и команды show на Cisco IOS Gatekeeper

В предыдущем разделе след SDI Сisco CallManager был обсужден подробно. В топологии для этого примера практического применения debug ras был включен в Сторожевом устройстве Cisco IOS.

Придерживающиеся сообщения отладки показывают, что Сторожевое устройство Cisco IOS получает запрос на доступ (ARQ) для Сisco CallManager (172.16.70.228), придерживавшийся другими сообщениями об успехе RAS. Наконец, Сторожевое устройство Cisco IOS передает "Допуск подтвержден" (ACF) сообщение к Сisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

Придерживающиеся сообщения отладки показывают, что вызов происходит.

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

Придерживающиеся сообщения отладки показывают, что Сторожевое устройство Cisco IOS получило разъединенный запрос (DRQ) от Сisco CallManager (172.16.70.228), и Сторожевое устройство Cisco IOS передало расцепление подтвержденного (DCF) к Сisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

Команда show gatekeeper endpoints на Сторожевом устройстве Cisco IOS показывает, что все четыре Сisco CallManager зарегистрированы в Сторожевом устройстве Cisco IOS. Помните, что в топологии для этого примера практического применения, существует четыре Сisco CallManager, два в каждом кластере. Это Сторожевое устройство Cisco IOS имеет две зоны, и каждая зона имеет два Сisco CallManager.

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Сообщения об отладке и команды show на шлюзе Cisco IOS

В предыдущем разделе команды показа Сторожевого устройства Cisco IOS и выходные данные отладки были обсуждены подробно. Этот раздел фокусируется на выходных данных отладки и командах показа на шлюзе Cisco IOS. В топологии для этого примера практического применения вызовы проходят через шлюзы Cisco IOS. Шлюз Cisco IOS взаимодействует к PSTN или УАТС или с T1/CAS или с интерфейсами T1/PRI. Выходные данные отладки команд, таких как debug voip ccapi inout, debug h225 events и debug h225 asn1 показывают ниже.

В следующих выходных данных отладки шлюз Cisco IOS принимает запрос соединения TCP от Сisco CallManager (172.16.70.228) на порту 2328 для H.225.

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

Следующие выходные данные отладки показывают, что данные H.225 прибывают из Сisco CallManager на этом сеансе TCP. В этих выходных данных отладки важно заметить protocolIdentifier, который указывает на используемую версию H.323. Придерживающаяся отладка показывает, что используется версия 2 H.323. Номера вызываемой и вызывающей стороны также показывают.

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

Ниже приводится выходные данные отладки для Интерфейса прикладного программирования управления вызовами (CCAPi). CCAPi указывает на входящий вызов. Информация о вызываемой и вызывающей сторонах может также быть замечена в следующем результате. CCAPi совпадает с точкой вызова 0, который является одноранговым телефонным соединением по умолчанию. Это совпадает с точкой вызова 0, потому что CCAPi не мог найти никакую другую точку вызова для вызывающего номер, таким образом, это использует одноранговое телефонное соединение по умолчанию.

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

CCAPi совпадает с точкой вызова 1 с шаблоном назначения, который является вызываемым номером 3333. Помните это, peer_tag означает точку вызова. Заметьте вызов и номер вызываемого абонента в пакете запроса.

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

Следующие выходные данные отладки показывают, что сообщения Предупреждения H.225 возвращаются к Сisco CallManager.

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

Заметьте в этом пакете, что Cisco IOS также передает адрес H.245 и номер порта к Сisco CallManager. Иногда шлюз Cisco IOS будет передавать недостижимый адрес, который мог вызвать или аудио или одностороннюю передачу аудиоданных.

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

Следующие выходные данные отладки показывают, что подходит сеанс H.245. Вы видите индикацию возможности для согласования кодека, а также сколько байтов будет присутствовать в каждом голосовом пакете.

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

Следующие выходные данные отладки показывают, что обе стороны выполнили согласование правильно и договорились о кодеке G.711 с 160 байтами данных.

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

Подключение H.323 и сообщения разъединения могут быть замечены ниже.

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

Шлюз Cisco IOS с интерфейсом T1/PRI

Как объяснено ранее, существует два типа вызовов, проходящих через шлюзы Cisco IOS: шлюз Cisco IOS взаимодействует к PSTN или УАТС, или с T1/CAS или с интерфейсами T1/PRI. Когда шлюзы Cisco IOS используют интерфейс T1/PRI, ниже приводятся выходные данные отладки.

Команда debug isdn q931 на шлюзе Cisco IOS была включена. Это включает Q.931, уровень Три протокола сигнализации для канала D в среде ISDN. Каждый раз, когда вызов размещен из интерфейса T1/PRI, пакет настройки должен быть передан. Пакет настройки всегда имеет (дескриптор протокола) фунт = 8, и это генерирует случайное шестнадцатеричное значение для callref. Callref используется для отслеживания вызова. Например, если два вызова размещены, значение callref может определить призыв, какое (полученное) сообщение RX предназначено. Пропускная способность информационного канала 0x8890 означает 64kb/s вызов данных. Если бы это был 0x8890218F, то это был бы 56kb/s вызов данных. Это был бы 0x8090A3, если бы это был голосовой вызов. В выходных данных отладки ниже, пропускная способность информационного канала является 0x8090A3, который является для голоса. Номера вызываемой и вызывающей стороны также показывают.

Callref использует другое значение для первой цифры (для дифференциации между TX и RX), и второе значение является тем же (НАСТРОЙКА имела 0 для последней цифры, и CONNECT_ACK также имеет 0). Маршрутизатор абсолютно зависит от PSTN или УАТС для присвоения Несущего канала (B-канал). Если PSTN или УАТС не назначат канал на маршрутизатор, то вызов не будет направлен. В нашем случае сообщение CONNECT получено от коммутатора с тем же номером ссылки, как был получен для ПРЕДУПРЕЖДЕНИЯ (0x800B). Наконец, вы видите обмен сообщением DISCONNECT, придерживавшимся ВЫПУСКОМ и ВЫПУСКОМ _COMP сообщения, поскольку разъединяется вызов. Сообщения RELEASE_COMP придерживаются ID причины для подавления вызова. ID причины является шестнадцатеричным значением. Значение причины может быть найдено путем декодирования шестнадцатеричного значения и добивания поставщика.

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

Шлюз Cisco IOS с интерфейсом T1/CAS

Как объяснено ранее, существует два типа вызовов, проходящих через шлюзы Cisco IOS: интерфейс шлюза Cisco IOS к PSTN или УАТС, или с T1/CAS или с интерфейсами T1/PRI. Когда шлюзы Cisco IOS имеют интерфейс T1/CAS, ниже приводятся выходные данные отладки. Debug cas на шлюзе Cisco IOS был включен.

Придерживающееся сообщение отладки показывает, что шлюз Cisco IOS передает сигнал ответа абонента к коммутатору.

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

Придерживающееся сообщение отладки указывает, что коммутатор передает подмигивание после получения сигнала замыкания контура от шлюза Cisco IOS.

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

Придерживающееся сообщение отладки указывает, что используется шлюз Cisco IOS.

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

Когда вызов происходит, ниже приводится выходные данные краткого описания show call active voice на шлюзе Cisco IOS. Номер вызываемой и вызывающей стороны и другие полезные сведения также показывают.

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

Сигнал "занято" после набора международного номера

Проблема

У пользователя есть CM 2.4.4 с образцом правильного маршрута, назначенным на его DT-24 + шлюз. Он в состоянии набрать локальный и междугородные номера US без проблем. Однако, когда он перфорирует цифры для международного номера, он слышит паузу, и затем сигнал занято.

Решение

Это было замечено в прошлом, где коммутатор CO не знает, как иметь дело должным образом с IE вызова (информационный элемент). Это может быть исправлено, заставляя тип IE Вызывающей стороны Call Manager "Установить Вызов и Вызвать DN типа к неизвестному" под DT24 + параметры промежутка.

Пример практического применения III: Межкластерные вызовы между IP-телефонами Cisco

В предыдущих примерах практического применения поток вызовов и методики поиска и устранения проблем внутрикластерного вызова и вызова Cisco IP Phone через шлюз Cisco IOS к телефону, "зависающему" прочь локальной УАТС или где-нибудь на PSTN, были обсуждены подробно. Этот пример практического применения исследует Cisco IP Phone, вызывающий другой Cisco IP Phone, расположенный в другом кластере. Этот тип вызова также известен как вызов Cisco IP Phone промежуточного кластера.

Образец топологии

Ниже приводится пример топологии, используемый в этом примере практического применения. Эта топология имеет два кластера, каждый имеющий два Сisco CallManager. Существуют также шлюзы Cisco IOS и Сторожевое устройство Cisco IOS на месте.

/image/gif/paws/30266/ios_gatekeeper3.gif

Межкластерная связь H.323

Как вы можете видеть в топологии, Cisco IP Phone в Кластере 1 звонит к Cisco IP Phone в Кластере 2. Промежуточный кластер связь Сisco CallManager имеет место с помощью протокола Версии 2 H.323. Существует также Сторожевое устройство Cisco IOS для контроля доступа. Подробное объяснение выходных данных отладки и команд показа и взаимодействия между Сторожевым устройством Cisco IOS и шлюзом Cisco IOS и Устройствами Cisco CallManager, может быть рассмотрено в предыдущих разделах.

Процесс потока вызовов показывают в приведенном ниже рисунке. Cisco IP Phone может говорить с Сisco CallManager через Протокол облегченной станции, и Сisco CallManager может говорить со Сторожевым устройством Cisco IOS с помощью протокола RAS H.323. Сообщение Запроса на доступ (ARQ) передается Сторожевому устройству Cisco IOS, которое передает сообщение "Допуск подтвержден" (ACF) после проверки, что межкластерный вызов может быть сделан с помощью протокола версии 2 H.323. После того, как сделанный, аудиопуть сделана с помощью протокола RTP между Cisco IP Phone в других кластерах.

/image/gif/paws/30266/gatekeeper_flow.gif

Трассы потоков звонков

В этом разделе рассматриваются поток вызовов с помощью примеров трассировки SDI, перехваченных в файле CCM000000000. Местоположение этого файла может быть найдено в предыдущем разделе. Следы, обсужденные в этом примере практического применения, фокусируются только на самом потоке вызовов, потому что более подробная информация о трассировке была уже объяснена в предыдущем примере практического применения (инициализация, регистрация, Механизм поддержки активности, и т.д.)

В этом потоке вызовов Cisco IP Phone (2002) расположенный в Кластере 2 называет Cisco IP Phone (1001) расположенным в Кластере 1. Помните, что можно придерживаться устройства через след путем рассмотрения значения маркера TCP, штампа времени или названия устройства. Значение маркера TCP для устройства остается тем же, пока устройство не перезагружено или идет офлайн.

В придерживающихся следах использовался Cisco IP Phone (2002). След показывает уникальные сообщения, маркер TCP и вызывающего номер, который отображен на Cisco IP Phone. Вызываемый номер (1001), подключение H.225 и H.245 подтверждает, что сообщения могут быть замечены в следующих выходных данных отладки. Тип кодека является G.711 �-law.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

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

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

Придерживающиеся следы показывают размеры пакета и MAC-адрес Cisco IP Phone (2002). Эти следы придерживаются разъединением, тогда сообщения с положенной трубкой.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Сбой потока вызова

Следующий раздел описывает неуспешный поток межкластерного вызова, как замечено в следе SDI. В следах ниже, использовался Cisco IP Phone (1001). Маркер TCP назначен на Cisco IP Phone.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

В придерживающихся следах пользователь набирает вызываемый номер (2000) из Cisco IP Phone, и процесс анализа цифровой информации пытается совпасть с количеством.

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

Анализ цифровой информации был теперь завершен, и результаты показывают в придерживающихся следах. Следует отметить, что ссылка PotentialMatches=NoPotentialMatchesExist ниже указывает, что Сisco CallManager неспособен совпасть с этим номером каталога. Наконец, сигнал занятости передается вызывающей стороне (1001), который придерживается сообщением с положенной трубкой.

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Детальная регистрация вызовов

Этот раздел предоставляет подробные сведения о Подробных записях о вызовах (КОМАНДИРЫ) и Записи управления вызовами (CMR, также известные как Диагностические КОМАНДИРЫ).

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

Базой данных является Microsoft SQL Server 7.0 баз данных. Доступ к базе данных может быть сделан через Подключение открытых баз данных (ODBC).

Доступ предоставлен всем таблицам в базе данных формой только для чтения и к CDR и таблицам CMR в чтении-записи форма.

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

Сохранение записей

Сisco CallManager пишет Записи CDR в базу данных SQL, поскольку вызовы выполнены способом, соответствующим конфигурации каждого отдельного Сisco CallManager. Эта конфигурация сделана через экран Service Parameters в Управлении Cisco CallManager.

Все записи записаны в первичную базу данных для кластера. Если первичная база данных не будет доступна, то записи будут записаны в любую из других архивированных баз данных. Как только первичная база данных становится доступной, затем писание новых записей продвинется, первичная база данных и локально записанные записи будут перемещены в основного.

Просмотр записей

Самый простой путь к чтению данных от базы данных SQL может состоять в том, чтобы использовать ODBC. Строка хорошего соединения была бы похожа:

ДРАЙВЕР = {сервер SQL}; SERVER=machineX; DATABASE=CCM0300

Обязательно используйте корректное имя базы данных. Если Релиз Cisco CallManager 3.0 (1) версия программного обеспечения установлена по существующей установке, база данных могла бы быть перемещена, если требуется новой установкой. В этом случае старая база данных будет все еще существовать, и новая база данных будет также существовать. Названия будут отличаться путем добавления одного к количеству названия. Например, исходное имя является CCM0300. После миграции более новое имя базы данных будет CCM0301. База данных самого большого количества должна использоваться.

Первичная база данных (машина и название) использующийся в настоящее время кластером может быть найдена путем щелчка по кнопке Details Управления Cisco CallManager (нажмите Help для достижения Экрана приветствия, где кнопка Details расположена). Реестр на машинах, размещающих базу данных, может также быть проверен. Посмотрите на ключ реестра: \\Системы HKEY_LOCAL_MACHINE\Software\Cisco Inc.\DBL для элемента под названием DBConnection0. Этот элемент строки содержит строку подключения, подобную показанному выше с именем машины и именем базы данных первичной базы данных.

Доступ управляется при помощи Пользователей SQL. Следующая таблица задает Имя и пароль пользователя, которое должно использоваться при доступе к Базе данных Cisco CallManager.

Таблицы Идентификатор пользователя SQl Password Возможность
CallDetailRecord, CallDetailRecordDiagnostic CiscoCCMCDR dipsy Чтение-запись
(Другой) CiscoCCMReader ковбои Устройства, предназначенные только для чтения:

Удаление записей

Так как Сisco CallManager полагается на приложения от стороннего разработчика для постобрабатывания данных CDR, необходимо удалить данные CDR, когда все приложения закончены с данными. Так как это включает изменение базы данных, пользователь CiscoCCMCDR должен использоваться.

Если Записи CDR накопятся до настраиваемого максимального значения (10,000,000 Записей CDR), то самые старые Записи CDR будут удалены вместе со связанными записями CMR один раз в день.

При удалении данных CDR после анализа, убедиться удалить все связанные записи CMR, также.

Схема таблицы

Подробные сведения о формате и использовании каждого поля в CDR предоставлены позже в этом разделе.

Используемые первичные таблицы являются таблицей CallDetailRecord (который держит Записи CDR), и таблица CallDetailRecordDiagnostic (который держит записи CMR). Таблица CallDetailRecord отнесена к таблице CallDetailRecordDiagnostic через два столбца GlobalCallID, GlobalCallID_callManagerId и GlobalCallID_callId. Может быть несколько CMR на CDR.

Таблица CallDetailRecord содержит данные об оконечных точках вызова и другого управления вызовами / маршрутизация аспектов вызова. Сведения таблицы CallDetailRecordDiagnostic о качестве переданного потоком аудио вызова.

Типичные ошибки

Релиз Cisco CallManager 3.0 (1) имеет несколько известных неполадок с данными CDR. Несколько из них упомянуты ниже.

IP к трансляции имени устройства

Таблица CDR приводит IP-адреса для оконечных точек вызова. Эти IP-адреса легко не преобразованы в имена устройства так, чтобы мог быть определен тип устройства.

OnNet по сравнению с OffNet

Трудно знать, остался ли вызов полностью на IP - сети, или по крайней мере внутренний к локальной системе. Одна подсказка должна проверить тип устройства обоих концов вызова. Если оба - телефоны, то можно предположить, что это осталось OnNet. Однако, если вы - шлюз, большие предположения должны быть сделаны. Если шлюз является типом Аналогового доступа устройства с POTS или портом станции, вызов, возможно, просто перешел к локальному аналоговому телефону или, возможно, вышел в PSTN. Посмотрите на набранный номер и коррелируйте это к известной схеме набора номеров, чтобы оценить, пошел ли вызов OffNet. В противном случае вызов, вероятно, пошел OnNet.

Номеронабиратель цифр OffNet

Если вызов размещен шлюз, цифры, набранные для получения до шлюза, могут не быть цифрами, передаваемыми PSTN. Шлюз может быть интеллектуальным и модифицировать номер каталога далее. Если это верно, Сisco CallManager не знает, и CDR не отразит, что фактические цифры передали OffNet.

Поля записи деталей вызова

Этот раздел определяет все поля в текущих записях. Типы поля - используемые Сisco CallManager, и не обязательно определенными в Записи CDR в базе данных. Определения поля базы данных соответствуют, чтобы хранить данные, но интерпретация данных должна принять во внимание типы поля, определенные здесь.

Все целые числа без знака являются целыми числами без знака на 32 бита.

Полевые преобразования данных

Существуют некоторые поля, которые требуют преобразования от десятичного формата до другого формата для показов. Этот раздел определяет их значения, и как преобразовать их или где получить информацию о том, как преобразовать их.

Значения времени

Все значения времени представлены как целые числа на 32 бита без знака. Это целое без знака значение отображено от базы данных как целое число со знаком.

Это поле является значением time_t, которое получено из Windows NT (2000) системные процедуры. Значение является согласованным текущим временем (UTC) значение и представляет кол-во секунд с Полуночи (0:00:00) 1 января 1970.

Дешифровка штампа времени

Использование Microsoft Excel, можно записать формулу, чтобы заставить преобразование на этот раз штамповать немного проще. Если значение находится в ячейке A1, можно сделать другую ячейку:

=A1/86400+DATE (1970,1,1)

Через день существует 86400 секунд.

Затем отформатируйте получающуюся ячейку как поле даты/времени в Excel.

IP-адреса

Все IP-адреса сохранены в системе как целые числа без знака. База данных отображает их как целые числа со знаком. Для преобразования десятичного значения со знаком в IP-адрес сначала преобразуйте значение в Шестнадцатеричное число (учет, что это - действительно число без знака). Шестнадцатеричное значение на 32 бита представляет четыре байта. Четыре байта в обратном порядке (стандарт Intel). Для получения IP-адреса инвертируйте заказ байтов и преобразуйте каждый байт в десятичный номер. Получающиеся четыре байта представляют четырехбайтовые поля IP-адреса в точечной - десятичной нотации.

Примечание: Когда младшему байту IP-адреса установили Most Significant Bits, база данных отображает его как отрицательное число.

Преобразование IP-адресов

  • Пример 1 :

    Например, IP-адрес 192.168.18.188 был бы отображен следующим образом:

    Показ базы данных =-1139627840.

    Это преобразовывает в Шестнадцатеричное значение 0xBC12A8C0.

    Инвертируйте Шестнадцатеричные байты = C0A812BC

    CO A8 12 BC

    Байты, Преобразованные от Hex до Десятичного числа = 192 168 18 188, который был бы отображен как 192.168.18.188.

  • Пример 2:

    IP-адрес 192.168.18.59

    Показ базы данных = 991078592

    Это преобразовывает в Шестнадцатеричное значение 0x3B12A8C0

    Обратный Порядок байтов = C0A8123B

    C0 A8 12 3B

    Байты, Преобразованные от Hex до Десятичного числа = 192 168 18 59, который был бы отображен как 192.168.18.59.

Определение поля CDR

Следующая таблица предоставляет определения поля для КОМАНДИРОВ.

Определения поля
Поле Определение
cdrRecordType Тип этого рекордного целого числа без знака Задает тип этой определенной записи. Это могла быть запись Начала вызова (0), Запись конца вызова (1), или запись CMR (2).
globalCallIdentifier Идентификатор Глобального вызова Идентификатор Глобального вызова состоит из двух полей, которые являются оба целыми числами без знака. Значения должны быть обработаны как целые числа без знака. Эти два поля: Целый без знака GlobalCallID_CallManagerID Целого числа без знака GlobalCallID_CallID Это - идентификатор вызова, который назначен на весь вызов. Все записи, привязанные к стандартному вызову, будут иметь тот же идентификатор глобального вызова.
origLegCallIdentifier Целое число без знака идентификатора вызова исходной ветви Это - уникальный идентификатор, который используется для отслеживания исходной ветви вызова. Это уникально в кластере.
dateTimeOrigination Целое число без знака происхождения даты/времени вызова Это представляет время, когда исходное устройство вызова ушло обработчик прерываний, или время, когда внешний вызов был сначала распознан системой (это получило Сообщение SETUP). Значение является согласованным текущим временем (UTC) значение и представляет кол-во секунд с Полуночи (0:00:00) 1 января 1970.
origNodeId Целое число без знака идентификатора узла инициатора Это поле представляет узел в Кластере Cisco CallManager, где инициатор вызова был зарегистрирован во время этого вызова.
origSpan Промежуток инициатора или целое число без знака порта, Это поле содержит порт инициатора или количество промежутка, если вызов произошел через шлюз. В противном случае это поле содержит ноль (0).
callingPartyNumber До 25 символов номера вызывающего абонента Это - номер каталога устройства, из которого произошел вызов.
origIpPort Целое число без знака порта IP вызывающей стороны Это поле содержит порт IP устройства, из которого произошел вызов.
origIpAddr Целое число без знака IP-адреса вызывающей стороны Это поле содержит IP-адрес устройства, из которого произошел вызов.
originalCallingPartyNumberPartition Разделение вызывающей стороны до 50 символов Это поле содержит разделение, привязанное к вызывающей стороне.
origCause_Location Целое число без знака значения расположения ISDN Это поле содержит значение расположения от информационного элемента причины.
origCause_Value Причина вызывающей стороны целого числа без знака прекращения вызова, Эта причина представляет причину вызов исходному устройству, была завершена. В случае передач, вперед, и т.д., причина прекращения вызова может быть другой для исходного устройства и прекращающего устройства. Таким образом существует два поля причины, привязанные к каждому вызову. Обычно они будут тем же.
origMediaTransportAddress_IP IP-адрес для целого числа без знака соединения сред инициатора, Это - IP - адрес назначения, с которым был связан Поток мультимедиа от инициатора.
origMediaTransportAddress_Port Порт для целого числа без знака соединения сред инициатора, Это - порт назначения, с которым был связан Поток мультимедиа от инициатора.
origMediaCap_payloadCapability Тип кодека, используемый целым числом без знака инициатора, Это поле содержит Тип кодека (сжатие или тип полезных данных), который инициатор использовал на отправляющей стороне во время этого вызова. Это может быть другим, чем тип кодека, используемый на его получающей стороне.
origMediaCap_maxFramesPerPacket Количество миллисекунд данных на пакетное целое число без знака Это поле содержит количество миллисекунд данных на пакет, переданный назначению инициатором этого вызова. Размер реальных данных зависит от типа кодека, используемого для генерации данных.
origMediaCap_g723BitRate Битовая скорость, которая будет использоваться целым числом без знака G.723, Определяет битовую скорость, которая будет использоваться G.723. Существуют двухбитовые значения скорости: 1 =5.3K битовая скорость и 2 = 6.3K битовая скорость.
lastRedirectDn Номер каталога стороны, которая в последний раз перенаправила этот призыв к 25 символам, Это - номер каталога последнего устройства, которое перенаправило этот вызов. Это поле применяется только к вызовам, которые были перенаправлены, такие как циркулярные вызовы, вызывают переадресованные звонки и т.д.
lastRedirectDnPartition Разделение телефона, который в последний раз перенаправил этот призыв к 50 символам, Это - Разделение последнего устройства, которое перенаправило этот вызов. Это поле применяется только к вызовам, которые были перенаправлены, такие как циркулярные вызовы, вызывают переадресованные звонки и т.д.
destLegIdentifier Идентификатор вызова для ветви назначения целого числа без знака вызова, Это - уникальный идентификатор, который используется для отслеживания ветви назначения этого вызова. Это уникально в кластере.
destNodeId Идентификатор узла для узла, где назначение вызова было зарегистрировано целое число без знака узел в Кластере Cisco CallManager, где целевое устройство было зарегистрировано во время этого вызова.
Промежуток dest Целевой промежуток или целое число без знака порта, Это поле содержит порт назначения или количество промежутка, если вызов был завершен через шлюз. В противном случае это поле содержит (0) ноль.
destIpAddr IP-адрес, которому вызову отправили целое число без знака Это поле, содержит IP-адрес сигнального соединения на устройстве, которое завершило вызов.
destIpPort Порт IP, которому вызову отправили целое число без знака Это поле, содержит порт IP сигнального соединения на устройстве, которое завершило вызов.
originalCalledPartyNumber Назначение получило от инициатора вызова до 25 символов, Это поле содержит Номер каталога, на который вызов был первоначально расширен на основе цифр, набранных инициатором вызова. Если вызов обычно завершает (значение, что он не был передан), этот Номер каталога должен всегда совпадать с "finalCalledPartyNumber". Если вызов был переведен, это поле содержит исходную точку назначения вызова, прежде чем это было передано.
originalCalledPartyNumberPartition Разделение вызываемой стороны до 50 символов Это поле содержит разделение, привязанное к вызываемой стороне.
finalCalledPartyNumber Назначение, которому вызову отправили до 25 символов Это поле, содержит Номер каталога, на который был фактически расширен вызов. Если вызов обычно завершает (значение, что он не был передан), этот Номер каталога должен всегда совпадать с "originalCalledPartyNumber". Если вызов был переведен, это поле содержит Номер каталога конечного назначения вызова после того, как были завершены все форварды.
finalCalledPartyNumberPartition Разделение связалось с конечным назначением вызова. до 50 символов Это поле содержит разделение, привязанное к назначению, на которое был фактически расширен вызов. В обычном вызове это поле должно совпасть с "originalCalledPartyNumberPartition". Если вызов был переведен, это поле содержит разделение конечного назначения вызова после того, как были завершены все форварды.
destCause_location Целое число без знака местоположения причины вызываемой стороны Это - Значение расположения ISDN от Информационного элемента причины.
destCause_value Причина вызываемой стороны целого числа без знака прекращения вызова, которое представляет Эта причина, почему был завершен вызов к прекращающему устройству. В случае передач, вперед, и т.д., причина прекращения вызова может быть другой для получателя вызова и инициатора вызова. Таким образом существует два поля причины, привязанные к каждому вызову. Обычно они будут тем же. Когда попытка предпринята для расширения вызова до занятого устройства, которое передано, код причины отразит "Занятый" даже при том, что вызов был связан с адресатом переадресации.
destMediaTransportAddress_IP IP-адрес для целого числа без знака назначения исходящего соединения для передачи медиа-данных, Это - IP-адрес происхождения, от которого был связан Поток мультимедиа от назначения.
destMediaTransportAddress_Port Порт для целого числа без знака назначения исходящего соединения для передачи медиа-данных, Это - порт инициатора, от которого был связан Поток мультимедиа от назначения.
destMediaCap_payloadCapability Тип кодека, используемый назначением на целом числе без знака отправляющей стороны, Это поле содержит Тип кодека (сжатие или тип полезных данных), который назначение использовало на его отправляющей стороне во время этого вызова. Это может быть другим, чем тип кодека, используемый на его получающей стороне.
destMediaCap_maxFramesPerPacket Количество миллисекунд данных на пакетное целое число без знака Это поле содержит количество миллисекунд данных на пакет, переданный инициатору назначением этого вызова. Размер реальных данных зависит от типа кодека, используемого для генерации данных.
destMediaCap_g723BitRate Битовая скорость, которая будет использоваться целым числом без знака G.723, Определяет битовую скорость, которая будет использоваться G.723. Существуют двухбитовые значения скорости: 1 =5.3K битовая скорость и 2 = 6.3K битовая скорость.
dateTimeConnect Дата/время целого числа без знака подключения, Это - дата и время, что вызов был связан между возникновением и оконечными устройствами. Значение является согласованным текущим временем (UTC) значение и представляет кол-во секунд с Полуночи (0:00:00) 1 января 1970.
dateTimeDisconnect Дата/время целого числа без знака разъединения, Это - время, когда вызов был разъединен между возникновением и оконечными устройствами, или когда вызов был разъединен, даже если это никогда не связывалось. Значение является согласованным текущим временем (UTC) значение и представляет кол-во секунд с Полуночи (0:00:00) 1 января 1970.
продолжительность Длительность вызова Это - кол-во секунд, что был связан вызов. Это - различие между датой/временем подключения и датой/временем разъединения.

Определения поля CMR

Следующая таблица предоставляет определения поля для CMR (диагностические КОМАНДИРЫ).

Определения поля
Поле Определение
cdrRecordType Тип этого рекордного целого числа без знака Задает тип этой определенной записи. Это будет установлено в запись CMR.
globalCallIdentifier Идентификатор Глобального вызова для этого вызова, Идентификатор Глобального вызова состоит из двух полей, которые являются оба целыми числами без знака. Значения должны быть обработаны как целые числа без знака. Эти два поля: Целый без знака GlobalCallID_CallManagerID Целого числа без знака GlobalCallID_CallID Это - идентификатор вызова, который назначен на весь вызов. Все записи, привязанные к стандартному вызову, будут иметь тот же идентификатор глобального вызова.
nodeID Идентификатор узла Сisco CallManager узел в Кластере Cisco CallManager, где генерировалась эта запись.
callIdentifier Целое число без знака Идентификатора вызова Это - идентификатор ветви вызовов, который определяет, которой ветви вызовов принадлежит эта запись.
directoryNum Номер каталога использовал на этом вызове, Это - номер каталога устройства, от которого они диагностика были собраны.
directoryNumPartition Разделение связалось с номером каталога, Это - разделение номера каталога в этой записи.
dateTimeStamp Завершение даты/времени вызова Это представляет приблизительное время, когда устройство пошло на обработчик прерываний. Когда телефон отвечает на запрос о диагностической информации, время помещено в запись. Это - значение time_t.
numberPacketsSent Количество пакетов передало общее число пакетов данных RTP, переданных устройством начиная со стартовой передачи на этом соединении. Если соединение было установлено в режиме "receive only", значение является нолем.
numberOctetsSent Количество Октетов (байты) данных, передаваемых другой стороне общее число байтов полезных данных (т.е. не включая заголовок или дополняющий) переданный в пакетах данных RTP устройством начиная со стартовой передачи на этом соединении. Если соединение было установлено в режиме "receive only", значение является нолем.
numberPacketsReceived Количество пакетов данных получило во время этого вызова общее число пакетов данных RTP, полученных устройством начиная со стартового приема на этом соединении. Количество включает пакеты, полученные от других источников, если это - многоадресный вызов. Если соединение было установлено в режиме "send only", значение является нолем.
numberOctetsReceived Количество октетов (байты) данных получило во время этого вызова общее число байтов полезных данных (т.е. не включая заголовок или дополняющий) полученный в пакетах данных RTP устройством начиная со стартового приема на этом соединении. Количество включает пакеты, полученные от других источников, если это - многоадресный вызов. Если соединение было установлено в режиме "send only", значение является нолем.
numberPacketsLost Потерянные пакеты RTP во время этого соединения общее число пакетов данных RTP, которые были потеряны с начала приема. Это количество определено как количество ожидаемых пакетов, меньше количество пакетов, фактически полученных, где количество полученных пакетов включает любого, которые являются поздними или копии. Таким образом пакеты, которые поступают поздно, не посчитаны, как потеряно, и потеря может быть отрицательной, если существуют копии. Количество ожидаемых пакетов определено, чтобы быть расширенным последним полученным порядковым номером, как определено затем, меньше полученный исходный порядковый номер. Если соединение было установлено в режиме "send only", значение является нолем. (Для получения дополнительной информации посмотрите RFC 1889),
дрожание Дрожание между получением во время этого соединения оценка статистического различия пакетного времени между поступлениями данных RTP, измеренного в миллисекундах и выраженного как целое число без знака. Дрожание между получением J определено, чтобы быть срединным отклонением (приглаженное абсолютное значение) различия D в пакетном интервале в получателе по сравнению с отправителем для пары пакетов. Подробные алгоритмы вычисления найдены в RFC 1889. Если соединение было установлено в режиме "send only", значение является нолем.
задержка Задержка, испытанная во время этого соединения значение, является оценкой задержки сети, выраженной в миллисекундах. Когда эти сообщения получены, это - приблизительное значение различия между меткой времени Протокола NTP, обозначенной отправителями Протокола управления RTP (RTCP) сообщения и меткой времени NTP приемников, измеренных. Среднее число получено путем подведения итогов всех оценок, затем деления на количество сообщений RTCP, которые были получены. (Для получения дополнительной информации посмотрите Запрос на комментарий (RFC) 1889),

Записи вызовов, зарегистрированные согласно типу вызова

Каждый обычный вызов между двумя сторонами регистрирует одну Запись конца вызова CDR. Каждая Запись конца вызова содержит все поля, определенные выше, но не могут использоваться некоторые поля. Если поле не будет использоваться, то это будет пробел, если это будет поле Строки ASCII, или "0", если это - числовое поле. Когда дополнительные сервисы вовлечены в вызов, больше Записей конца вызова может быть записано.

В дополнение к Записи конца вызова CDR, может быть до одной записи CMR для оконечной точки, вовлеченной в вызов. В обычном вызове между двумя сторонами каждое использование Cisco IP Phone будет две письменные записи CMR: один для инициатора и один для назначения вызова.

В этом разделе описываются записи, записанные для других типов вызова в системе.

Обычные вызовы (Cisco IP Phone-to-Cisco)

Обычные вызовы регистрируют три записи на вызов. Они - EndCall плюс две диагностических записи, один для каждой оконечной точки. В записи EndCall все поля могут содержать достоверные сведения. Продолжительность всегда будет ненулевой, пока флаг "CdrLogCallsWithZeroDurationFlag" не будет включен (установленный в True). Поле "originalcalledpartynumber" будет содержать тот же номер каталога как поле "finalCalledPartyNumber".

Несостоявшиеся вызовы

Регистрация вызовов с нулевой продолжительностью является дополнительной. Обычно, эти записи не будут зарегистрированы. Если регистрация вызовов с нулевой продолжительностью включена, на придерживающиеся вещи нужно обратить внимание.

  • Если от вызова отказались (такой как тогда, когда телефон взят от обработчика прерываний и разместил назад с отключенной линией), различные поля не будут содержать данные. В этом случае "originalCalledPartyNumber", "finalCalledPartyNumber", отделения, привязанные к ним, "destIpAddr", и dateTimeConnect полям, будут пробелом. Все вызовы, которые не были связаны, будут иметь "продолжительность" нулей секунд. Когда от вызова отказываются, код причины "0".

  • Если пользователь набрал номер каталога и затем отказался от вызова, прежде чем он был связан, поля "First Dest" и "Final Dest" и их cвязанные отделения будут содержать номер каталога и разделение, на которое был бы расширен вызов. Поле "Dest Ip" будет пробелом, и продолжительность будет нолем.

Переданные или перенаправленные вызовы

Записи вызова для переадресованных звонков совпадут с теми для обычных вызовов за исключением поля "originalcalledpartynumber" и "originalCalledPartyNumberPartition" полей. Эти поля будут содержать номер каталога и разделение для назначения, которое было первоначально набрано инициатором вызова. Если вызов был переведен, "finalCalledPartyNumber" и "finalCalledpartyNumberPartition" поля будут другими и будут содержать номер каталога и разделение конечного назначения вызова. Кроме того, когда вызов будет переведен, "lastRedirectDn" и "lastRedirectDnPartition" поля будут содержать номер каталога и разделение последнего телефона, который передал или перенаправил этот вызов.

Вызовы с занятыми или плохими назначениями

Эти вызовы будут зарегистрированы как обычный вызов со всеми соответствующими полями, содержащими данные. Поле Called Party Cause будет содержать код причины, указывающий, почему вызов не был связан, и IP Вызываемой стороны и поля Connect Даты/Времени будут пробелом. Если инициатор отказался от вызова, причина будет "NO_ERROR" (0). Продолжительность всегда будет нулями секунд. Эти вызовы не будут зарегистрированы, пока не будет включен "CdrLogCallsWithZeroDurationFlag".

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

Каждый обычный вызов между двумя Cisco IP Phone регистрирует точно две записи CMR. Каждая запись CMR вызова содержит все поля, определенные выше. Когда дополнительные сервисы вовлечены в вызов, несколько записей могут быть записаны. Когда диагностические записи записаны для других типов вызова в системе, этот раздел описывает.

Обычные вызовы

Обычные вызовы регистрируют точно две записи CMR на вызов, один для каждого телефона, вовлеченного в вызов. В настоящее время только Cisco IP Phone и шлюзы MGCP способны к ответу на запрос диагностической информации. Все поля будут содержать достоверные сведения.

Несостоявшиеся вызовы

Если от вызова отказались (такой как тогда, когда телефон взят при снятой трубке и разместил назад с отключенной линией), все поля, отнесенные к потоковой передаче данных, будут пробелом (ноль). Это вызвано тем, что никакое соединение потоковой передачи не было установлено, и поэтому никакие данные не были переданы. Если "CdrLogCallsWithZeroDurationFlag" будет отключен, никакие записи с пустыми полями не будут зарегистрированы.

Переадресованные звонки

Записи вызова для переадресованных звонков совпадут с теми для обычных вызовов.

Вызовы с занятыми или плохими назначениями

В обычном случае только будут зарегистрированы записи, которые представляют вызовы, которые были фактически связаны. Для регистрации вызовов с плохими назначениями необходимо включить "CdrLogCallsWithZeroDurationFlag". Если это будет включено, то все вызовы будут зарегистрированы включая случай, где пользователь используется и затем при положенной трубке снова.

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

Типы кодека (типы компрессии/полезной нагрузки)

Следующая таблица предоставляет значения и описания для типов кодека.

Описание кодека
Codec Описание
1 NonStandard
2 G711A-законы 64k
3 G711A-законы 56k
4 G711�-law 64k
5 G711�-law 56k
6 G722 64k
7 G722 56k
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 Данные 64k
33 Данные 56k
80 GSM
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

Коды причин

Следующая таблица предоставляет список кодов причин, которые могут появиться в полях Cause.

Описания кода причины
Код причины Описание
0 Никакая ошибка
1 Освобожденное (неприсвоенное) количество
2 Никакой маршрут к указанной транзитной сети (национальное использование)
3 /* нет маршрута к пункту назначения
4 Отправка специального информационного сигнала
5 Префикс транка Misdialed (национальное использование)
6 Канал неприемлем
7 Назовите награжденными и отправляемый в установленном канале
8 Приоритетное прерывание обслуживания
9 Переключение, канал зарезервирован для повторного использования (Preemption, circuit reserved for re-use)
16 Обычный сброс вызова
17 User-Busy;
18 Пользователь не отвечает
19 Никакой ответ от пользователя (пользователь предупредил),
20 Абонент отсутствует
21 Вызов отклонен
22 Номер изменился
26 Разъединение из-за отсутствия назначенного пользователя
27 Место назначения неисправно
28 Недопустимый формат номера (обращаются неполный),
29 Отклоненное средство
30 Отклик на запрос STATUS ENQUIRY
31 Нормальный, не уточненный
34 Никакой доступный канал/канал
38 Сеть неработоспособна
39 Постоянное подключение режима кадра не действует
40 Постоянное подключение режима кадра работоспособно
41 Временный сбой
42 Перегрузка коммутационного оборудования
43 Информация о доступе отклонена
44 Запрошенный канал, не доступный
46 Приоритетный вызов заблокировался
47 Ресурс, недоступный, неуказанный
49 Качество обслуживания, не доступное
50 Отсутствует подписка на запрашиваемую функцию
53 Сервисная операция нарушена
54 Входящие вызовы запрещены
55 Входящие вызовы запрещены в Закрытой группе пользователей (CUG)
57 Возможность однонаправленной передачи не авторизована
58 Пропускная способность однонаправленного канала в настоящий момент недоступна
62 Несоответствие в определяемых исходящих данных доступа и классе абонента
63 Служба или параметр недоступны, не определены
65 Пропускная способность однонаправленного канала не реализована
66 Тип канала не реализован
69 Не выполняется запрашиваемая функция
70 Только ограниченная пропускная способность информационного канала цифровых данных доступна (национальное использование)
79 Сервис или опция, не внедренная, неуказанная
81 Недопустимое значение метки соединения
82 Определенный канал не существует
83 Приостановленный вызов существует, но эта идентичность вызовов не делает
84 Идентичность вызовов в использовании
85 Нет приостановленных вызовов
86 Звоните наличие идентичности затребованного вызова было очищено
87 Пользователь не участник Закрытой группы пользователей (CUG)
88 Несовместимое место регистрации
90 Без вести пропавшие назначенного номера и DC, не подписанный
91 Неправильный выбор транзитной сети (национальное использование)
95 Неверное сообщение, неопределенное
96 Элемент обязательных сведений отсутствует
97 Не существующий тип сообщения или не внедренный
98 Сообщение не совместимо с режимом вызова, или тип сообщения не существует или не внедренный
99 Информационный элемент или параметр не существуют или не внедрены
100 Недопустимые контенты элемента сведений
101 Сообщение не совместимо с режимом вызова
102 Когда таймер, с истекшим сроком и программа восстановления, выполнялся для восстановления с ошибки, вызов был завершен
103 Не существующий параметр или не внедренный - перешел (национальное использование)
110 Сообщение с неопознанным параметром, от которого сбрасывают
111 Ошибка протокола, неопознанная
126 Вызовите разделение. Это - определяемый Cisco код. Это используется, когда вызов завершен во время функционирования передачи, потому что это было отколото и завершилось (не была часть заключительного переведенного вызова). Это может помочь определять, какие вызовы были завершены как часть функционирования передачи.
127 Межсетевые, неустановленные

Сигналы тревоги

Сигнал тревоги выполнен, когда данные CDR или диагностические данные включены, и система неспособна записать данные в базу данных.

Неспособный записать данные CDR. (Встревожьте # 1711 - Основной сигнал),

Система попыталась открыть базу данных и была неуспешна. Вероятные причины включают:

  • Сisco CallManager не имеет достаточных привилегий для открытия файла для записи в базу данных. Удостоверьтесь, что Сisco CallManager имеет привилегии, которые разрешат операции записи.

  • Путь является "not set", или сервер базы данных не работает.

Обращение в центр технической поддержки (TAC)

Если у вас есть проблема, которая не может быть решена посредством собственного устранения проблем, вызовите TAC для помощи. Перед вызыванием TAC имейте следующую информацию в наличии:

  • Подробные данные Сisco CallManager

  • Топология

  • Журналы и следы вы работали во время устранения проблем, включая следы SDL и SDI

  • Файлы Stackwalk.txt из каталога WINNT\system32 и подкаталога Трассировки Cisco CallManager

  • sh-технология на шлюзах Cisco IOS, если применимо

  • sh-технология на Сisco CallManager

  • Если проблема с вызовами через шлюз Cisco IOS, также предоставьте:

    • голос отладки ccapi изменяемый

    • debug isdn q931

    • [Только AS5300] sh vfc xboard

    • [Только AS5300] sh vfc x версия dspware

    • [Только AS5300] sh vfc x версия vcware

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения