Голосовая связь и система унифицированных коммуникаций : Cisco Unity Express

Проблемы JTAPI CUE и примеры практического применения

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

Содержание

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

Введение

Этот документ предоставляет сведения о том, как устранить неполадки Интерфейса программирования приложений телефонии Java (JTAPI) Cisco Unity Express (CUE). Кроме того, этот документ предоставляет информацию и дает команду о том, как включить, собрать и просматривает другие следы и журналы с устранением проблем примеров примера практического применения.

Внесенный Майклом Мендосой и Бэктэвэтсэлом Мурэлидхараном, специалистами службы технической поддержки Cisco.

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

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Базовые знания о том, как настроить и использовать Cisco Unified Communications Manager (CUCM) через веб-административный интерфейс.
  • Общее представление с портами Computer Telephony Interface (CTI) и Точками маршрута (RP) в CUCM.
  • Общее представление с интерфейсом командной строки Cisco Unity Express.

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

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

  • Версия 3.x Cisco Unity Express или позже.
  • Версия 7.x Cisco Unified Communications Manager или позже.

Используемый метод интеграции применяется только для Cisco Unity Express с Cisco Unified Communications Manager; не с Cisco Unified Communications Manager Express (CUCME). 

Cisco Unity Express должен лицензироваться для CUCM, не CUCME. CUE может или интегрироваться с CUCM или CUCME в любое время и лицензироваться соответственно.

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

Интеграция JTAPI CUE с обзором CUCM

Возможно интегрировать CUE с CUCM через протокол JTAPI для функциональности автоответчика (AA) и голосовой почты (VM). Это решение рекомендуется, когда вы хотите обеспечить функции VM и/или основную обработку вызова AA для одной или множественных узлов филиала с небольшими числами пользователей, зарегистрированных к серверу CUCM. Это не требует законченного Сервера голосовой почты Cisco Unity, но намного более доступной реализации. В то же время, когда подключение к CUCM потеряно, CUE также предоставляет возможности жизнеспособности для своих ответвлений и переключений при отказе к Сеансу инициировал протокол (SIP).

CUE в состоянии зарегистрироваться в CUCM через JTAPI и управляет порты CTI и точки маршрута CTI. Это позволяет вам управлять CUE как дополнительной оконечной точкой через CUCM, а также упрощать конфигурации и взаимодействия с другими оконечными точками в кластере.

Высокоуровневый пример потока вызовов

Конечный пользователь с номером каталога (DN) 1005 вызовов пользователь с DN 1001. Если вызову не отвечают, Переадресация вызовов при отсутствии ответа (CFNA), к количеству VM, настроенному на пользователе 1001 профиль VM, после нескольких секунд переведен вызов. CUCM тогда передает вызов настроенному Пилоту VM 5000, который указывает к RP CTI с DN 5000, который управляется CUE. Приложение VM CUE вызвано, и вызов перенаправлен через JTAPI к доступному порту CTI (DN 5501) для установления сред. Звучит приветственное сообщение, и пользователь может оставить сообщение или пообщаться с системой через набор двухтональных сигналов DTMF. Когда абонент заканчивает вызов, CUE сигнализирует CUCM для установки лампы Индикатора ожидания сообщения (MWI) для расширения 1001 к "На" через JTAPI. CUCM тогда передает сообщение Skinny Client Control Protocol (SCCP), чтобы включить свет по телефону, а также показать индикацию конверта относительно показа, таким образом, пользователь 1001 знает, что существует новое сообщение VM в почтовом ящике.

Включение и набор следов

Существует два типа следов:

  • Следы Сети связи Cisco (CCN) JTAPI в реальном времени
  • CCN JTAPI отслеживает журналы

Следы CCN JTAPI в реальном времени

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

Введите эти команды для разрешения трассировок:

no trace all
trace ccn SubsystemJtapi all

Введите эту команду, чтобы проверить, что им включают:

CUE# show trace
MODULE ENTITY SETTING
ccn SubsystemJtapi ffffffff

Введите эту команду для сбора выходных данных:

CUE# show trace buffer ?
containing Only display events matching a regex pattern
long Show long format
short Show short format
tail Wait for events and print them as they occur !!

Введите CTRL-C для остановки регистрации в реальном времени к консоли.

CCN JTAPI отслеживает журналы

Повторная загрузка модуля CUE требуется после того, как журналы следа CCN JTAPI позволены для журналов стать заполненными. Эти журналы, messages.log и atrace.log, могут быть очень подробными или загадочными, а также намного более информативными и подробными. Существует четыре других журнала:

  • atrace.log
    • Включенный по умолчанию на сетевых модулях (NMs), но отключенный по умолчанию для Модулей Расширенной интеграции (СТРЕМИТСЯ). Введите команду log trace local enable для включения.
    • Это пишет до 10 Мбит локально или к серверу FTP.
    • Для перезапуска журнала введите команду log trace local disable или команду no log trace local enable; тогда введите команду log trace local enable. Введите ясную команду файла трассировки для очистки atrace.log.
    • Данные должны декодироваться Центром технической поддержки (TAC).
  • messages.log
    • Это журналы, которые содержат Сообщения системного журнала, такие как Информация, Предупреждение, Ошибка, и Фатальный.
  • CiscoJtapi1.log и CiscoJtapi2.log
    • Они регистрируют всю связанную с JTAPI сигнализацию и события.
    • Эти журналы намного проще понять и очень информативный.
    • Когда CiscoJtapi1.log становится полным и наоборот, CiscoJtapi2.log начинает заполнять.

Независимо от которого установлены следы, система возвращается к уровням трассировки по умолчанию после повторной загрузки. Для изменения этих настроек по умолчанию так, чтобы они пережили перезагрузку, необходимо ввести команду log trace boot. Вот команда, чтобы включить им:

CUE#(CONFIG)> log console info  !! 
ccn trace jtapi deb all
ccn trace jtapi info all
ccn trace jtapi warn all
log trace boot
reload

Введите эту команду, чтобы проверить, что им включают:

CUE# show ccn trace jtapi
Warning: 1
Informational: 1
Jtapi Debugging: 1
Jtapi Implementation: 1
CTI Debugging: 1
CTI Implementation: 1
Protocol Debugging: 1
Misc Debugging: 1

Вот шаги для просмотра журналов:

  1. Введите команду show log для просмотра списка файлов журнала, сохраненных в CUE.
  2. Расширение файла .prev означает, что это - резервная копия более старого файла трассировки а не текущего файла активного журнала.
  3. Можно извлечь их к внешнему серверу FTP.
  4. Можно также просмотреть выходные данные сообщений, которые зарегистрированы к этим файлам, в реальном времени от terminal monitor CUE.

Соберите файлы журнала следа

Извлеките журналы к внешнему FTP с этими командами:

   copy log CiscoJtapi2.log url ftp://username:password@192.168.105.1/
copy log CiscoJtapi1.log url ftp://username:password@192.168.105.1/
copy log messages.log url ftp://username:password@192.168.105.1/
copy log atrace.log url ftp://username:password@192.168.105.1/

Показ регистрирует к terminal monitor CUE с названием show log команда <logname>. Например:

CUE# show log name messages.log ?
containing Only display events matching a regex pattern
paged Display in page mode
tail Wait for events and print them as they occur
<cr>

atrace.log закодирован; поэтому можно не только отобразить его в реальном времени с командой show log name.

Обязательные подробные данные перед проверкой журналов

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

  • Вызывающий номер
  • Вызываемый номер
  • Количество перенаправления
  • DN RP CTI и имя устройства
  • Номер порта CTI и имя устройства
  • Пользователь JTAPI
  • Временной диапазон вызовы имел место

Основные понятия CTI

Поставщик: поставщик сервисов CTI. Приложение устанавливает сеанс CTI путем открытия поставщика.
Пользователь: Приложения привязаны к пользователю.
Устройство: устройство, которое регистрируется к CUCM.
Линия: появление DN на поддерживаемом устройстве CTI.
Идентификатор вызова (callLegID): Привязанный к одной ветви вызовов в вызове.
Глобальный вызов (callID): Определяет все ветви вызовов для одиночного вызова.

Общие режимы вызова CTI

state = 1               IDLE
state = 2 OFFERING
state = 3 ACCEPTED
state = 8 CONNECTED

На что должны быть похожими журналы следа

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

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

Вот подробные данные используемых конфигураций:

Jtapi User:                    tacjtapiuser
CUCM IP Address: 192.168.100.10
CUE CTI Route Point: cue_vm_ctirp
CUE CTI Port: cue_ctiport1
CUE and Phone Partition: cue_pt
IP Phone MAC: SEP0023331C29EC
CTI Route Point DN: 8000
CTI Port DN: 8501
IP Phone DN: 3001

RP CTI и порт регистрация

(Выходные данные от CiscoJtapi1 / Журналы Cisco Jtapi2)

  1. Откройте соединение поставщика
     

    21: 12:05:23.686 CST %JTAPI-CTIIMPL-7-UNK.(P1-tacjtapiuser) ProviderID = 
    P1-tacjtapiuser
    22: 12:05:23.739 CST %JTAPI-CTIIMPL-7-UNK.(P1-tacjtapiuser) Trying to
    create normal socket connection to 192.168.100.10

    23: 12:05:23.747 CST %JTAPI-CTIIMPL-7-UNK.(P1-tacjtapiuser) connected
    26: 12:05:24.112 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.ProviderOpenRequest {
    provider = 192.168.100.10
    qbeClientVersion = Cisco JTAPI 7.0(1.1000)-1 Release
    login = com.cisco.cti.protocol.UnicodeString {
    unicodedisplayName = tacjtapiuser
    }
    applicationID = Cisco IP IVR
    desiredServerHeartbeatTime = 30
    pluginName = CiscoJTAPI
    }
    28: 12:05:24.131 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.ProviderOpenResponse {
    sequenceNumber = 0
    result = 0
    providerInfoString = 7.1.5.10000-12
    clientHeartbeat = 30
    serverHeartbeat = 30
    pluginVersion = 7.1.5.10000-2
    pluginLocation = http://192.168.100.10/plugins/
    providerId = 16777236
    }
    35: 12:05:24.858 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Event: com.cisco.cti.protocol.ProviderOpenCompletedEvent {
    eventSequence = 0
    reason = 0
    providerInfoString = 7.1.5.10000-12
    clientHeartbeat = 30
    serverHeartbeat = 30
    failureDescription = null
    providerId = 16777236
    }
  2. Запрос для управляемых устройств
     

    48: 12:05:24.864 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT] 
    sending: com.cisco.cti.protocol.ProviderGetDeviceInfoRequest {
    sequenceNumber = 2
    deviceGroup = 1
    }
    49: 12:05:24.865 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.ProviderGetDeviceInfoResponse {
    sequenceNumber = 2
    result = 0
    }
    50: 12:05:24.865 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetDeviceInfoFetchRequest {
    sequenceNumber = 3
    }
    51: 12:05:25.011 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.GetDeviceInfoFetchResponse {
    sequenceNumber = 3
    result = 0
    info = 2@[
    com.cisco.cti.protocol.DeviceInfo {
    name = cue_ctiport1
    type = 72
    allowsRegistration = true
    deviceID = 62
    devTypeName = CTI Port
    },
    com.cisco.cti.protocol.DeviceInfo {
    name = cue_vm_ctirp
    type = 73
    allowsRegistration = true
    deviceID = 61
    devTypeName = CTI Route Point
    }]
    52: 12:05:25.012 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetDeviceInfoCloseRequest {
    sequenceNumber = 4
    }
    53: 12:05:25.013 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.GetDeviceInfoCloseResponse {
    sequenceNumber = 4
    }
    54: 12:05:25.013 CST %JTAPI-MISC-7-UNK.(P1-192.168.100.10)

    creating controlled devices
  3. Получите информацию о линии порта CTI
     

    55: 12:05:25.024 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT] 
    sending: com.cisco.cti.protocol.DeviceGetLineInfoRequest {
    sequenceNumber = 5
    deviceName = cue_ctiport1
    }
    56: 12:05:25.026 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.DeviceGetLineInfoResponse {
    sequenceNumber = 5
    result = 0
    }
    57: 12:05:25.026 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetLineInfoFetchRequest {
    sequenceNumber = 6
    }
    58: 12:05:25.029 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.GetLineInfoFetchResponse {
    sequenceNumber = 6
    result = 0
    com.cisco.cti.protocol.LineInfo {
    name = 8501
    displayName =
    maxNumberOfCalls = 4
    lineInstance = 1
    unicodeDisplayName = com.cisco.cti.protocol.UnicodeString {
    }
    partition = cue_pt
    defaultIntercomTargetInfo = com.cisco.cti.protocol.LineIntercomSpeedDialInfo {
    }]
    59: 12:05:25.029 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetLineInfoCloseRequest {
    sequenceNumber = 7
    }
    60: 12:05:25.031 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.GetLineInfoCloseResponse {
    sequenceNumber = 7
    result = 0
    }
    61: 12:05:25.042 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser)
    DeviceMap: adding device "cue_ctiport1"
  4. Получите информацию о линии RP CTI
    62: 12:05:25.043 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT] 
    sending: com.cisco.cti.protocol.DeviceGetLineInfoRequest {
    sequenceNumber = 8
    deviceName = cue_vm_ctirp
    }
    63: 12:05:25.044 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.DeviceGetLineInfoResponse {
    sequenceNumber = 8
    result = 0
    }
    64: 12:05:25.045 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetLineInfoFetchRequest {
    sequenceNumber = 9
    }
    65: 12:05:25.047 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.GetLineInfoFetchResponse {
    sequenceNumber = 9
    result = 0
    info = 1@[
    com.cisco.cti.protocol.LineInfo {
    name = 8000
    displayName =
    permanentLineID = 52
    partition = cue_pt
    defaultIntercomTargetInfo = com.cisco.cti.protocol.LineIntercomSpeedDialInfo {
    unicodeLabel = com.cisco.cti.protocol.UnicodeString {
    }
    }
    66: 12:05:25.048 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.GetLineInfoCloseRequest {
    sequenceNumber = 10
    }
    67: 12:05:25.058 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response: com.cisco.cti.protocol.GetLineInfoCloseResponse {
    sequenceNumber = 10
    result = 0
    }
    68: 12:05:25.059 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser)
    DeviceMap: adding device "cue_vm_ctirp"
    69: 12:05:25.059 CST %JTAPI-CTI-7-UNK.(P1-192.168.100.10)
    refreshing device map: previous=0 current=2 created=2 removed=0
  5. CUE применяет полученную конфигурацию
    76: 12:05:25.064 CST %JTAPI-MISC-7-UNK.Provider 192.168.100.10 
    open, beginning device
    initialization

    77: 12:05:25.071 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_INIT]
    (P1-tacjtapiuser) Request: addObserver
    79: 12:05:25.073 CST %JTAPI-MISC-7-UNK.ObserverThread
    (com.cisco.wf.subsystems.jtapi.SubsystemJTAPI$ProviderObserver@3d823d82):created
    80:12:05:25.074 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) ProvOutOfServiceEv [#0]
    Cause:100 CallCtlCause:0 CiscoFeatureReason:12
    82: 12:05:25.085 CST %JTAPI-MISC-7-
    UNK.ObserverThread
    (com.cisco.wf.subsystems.jtapi.SubsystemJTAPI$ProviderObserver@3d823d82):
    queuing com.cisco.jtapi.JtapiProviderEventSet
    83: 12:05:25.084 CST %JTAPI-MISC-7-UNK.(P1-192.168.100.10)
    ProviderRetryThread starting up
    85: 12:05:25.084 CST %JTAPI-MISC-7-UNK.ObserverThread
    (com.cisco.wf.subsystems.jtapi.SubsystemJTAPI$ProviderObserver@3d823d82)
    starting up...
    90: 12:05:25.102 CST %JTAPI-JTAPIIMPL-7-UNK.Partition Support 8000 in
    partitioncue_pt
    91: 12:05:25.102 CST %JTAPI-JTAPIIMPL-7-UNK.(P1-tacjtapiuser) cue_vm_ctirp:
    Address: 8000 in partitioncue_pt created

    92: 12:05:25.102 CST %JTAPI-JTAPIIMPL-7-UNK.Partition Internal Address Added
    8000 in Partition cue_pt
    93: 12:05:25.102 CST %JTAPI-JTAPIIMPL-7-UNK.Partition Support 8501 in
    partitioncue_pt
    94: 12:05:25.103 CST %JTAPI-JTAPIIMPL-7-UNK.(P1-tacjtapiuser) cue_ctiport1:
    Address: 8501 in partitioncue_pt created

    95: 12:05:25.103 CST %JTAPI-JTAPIIMPL-7-UNK.Partition Internal Address Added
    8501 in Partition cue_pt
    96: 12:05:25.103 CST %JTAPI-MISC-7-UNK.Provider "(P1-tacjtapiuser)" changing
    state to IN_SERVICE

    97: 12:05:25.103 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[Thread-76]
    (P1-tacjtapiuser) Request: getObservers
    98: 12:05:25.103 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) ProvInServiceEv [#1]
    Cause:100 CallCtlCause:0 CiscoFeatureReason:12
    100: 12:05:25.103 CST %JTAPI-MISC-7-UNK.ObserverThread
    (com.cisco.wf.subsystems.jtapi.SubsystemJTAPI$ProviderObserver@3d823d82):
    queuing com.cisco.jtapi.JtapiProviderEventSet
    101: 12:05:25.103 CST %JTAPI-JTAPIIMPL-7-UNK.Provider 192.168.100.10
    initialized 2 devices
    104: 12:05:25.104 CST %JTAPI-JTAPIIMPL-7-UNK:
    [com.cisco.wf.subsystems.jtapi.SubsystemJTAPI$ProviderObserver@3d823d82]
    delivering to providerChangedEvent
    106: 12:05:25.523 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_INIT]
    (P1-tacjtapiuser) Request: getAddress( 8501 )Partition = cue_pt
    107: 12:05:25.526 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_INIT]
    [cue_ctiport1]Request: addObserver
    (com.cisco.wf.subsystems.jtapi.TAPIPortGroup$Port$AddressCallObserver@5d085d08)
  6. Получите контроль устройств CTI и линий
     
    109: 12:05:25.528 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT] 
    sending:
    com.cisco.cti.protocol.DeviceOpenRequest {
    deviceName = cue_ctiport1
    }
    110: 12:05:25.533 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
    received Response:
    com.cisco.cti.protocol.DeviceOpenResponse {
    result = 0
    }
    111: 12:05:25.533 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser) DeviceMap: opening
    device "cue_ctiport1"

    112: 12:05:25.533 CST %JTAPI-JTAPIIMPL-7-UNK.(P1-tacjtapiuser) Terminal
    "cue_ctiport1" out of service
    113: 12:05:25.534 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) [cue_ctiport1]
    CiscoTermOutOfServiceEv [#2] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
    119: 12:05:25.544 CST %JTAPI-JTAPIIMPL-7-UNK:Address [cue_ctiport1:8501:
    cue_pt.(0,0)] out of service
    120: 12:05:25.544 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) [8501:cue_pt]
    CiscoAddrOutOfServiceEv [#3] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
    121: 12:05:25.546 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.LineOpenRequest {
    deviceName = cue_ctiport1
    lineName = 8501
    }
    122: 12:05:25.582 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.LineOpenResponse {
    134: 12:05:25.670 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.LineCloseRequest {
    135: 12:05:25.673 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.LineCloseResponse {
    138: 12:05:25.674 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.DeviceCloseRequest {
    139: 12:05:25.681 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.DeviceCloseResponse {
    141: 12:05:25.683 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.DeviceRegisterDeviceRequest {
    deviceName = cue_ctiport1
    142: 12:05:25.687 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.DeviceRegisterDeviceResponse {
    result = 0
    name = cue_ctiport1
    allowsRegistration = true
    }
    143: 12:05:25.687 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser) DeviceMap: opening
    device "cue_ctiport1"

    150: 12:05:25.688 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
    sending: com.cisco.cti.protocol.LineOpenRequest {
    deviceName = cue_ctiport1
    lineName = 8501
    151: 12:05:25.690 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Response: com.cisco.cti.protocol.LineOpenResponse {
    152: 12:05:25.691 CST %JTAPI-JTAPIIMPL-7-UNK:cue_ctiport1: Lines opened
    153: 12:05:25.739 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Event: com.cisco.cti.protocol.DeviceRegisteredEvent {
    deviceInfo = com.cisco.cti.protocol.DeviceInfo {
    allowsRegistration = true
    controllable = true
    }
    156: 12:05:25.739 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) Received
    DeviceRegisteredEvent
    160: 12:05:25.740 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Event: com.cisco.cti.protocol.DeviceInServiceEvent {
    162: 12:05:25.741 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
    Event: com.cisco.cti.protocol.LineInServiceEvent {
    }

Базовый вызов, переданный голосовой почте

(Выходные данные от CiscoJtapi1 / Журналы Cisco Jtapi2)

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

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

12:46:00.396 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event: 
com.cisco.cti.protocol.NewCallEvent {
deviceName = cue_vm_ctirp
callLegID = 25626132
callID = 9040
callingParty = 3001
calledParty = 8000

callingPartyName = Ext 3001 - Phone
callingPartyDeviceName = SEP0023331C29EC
unModifiedCalledParty = 8000
unModifiedOriginalCalledParty = 8000
unModifiedLastRedirectingParty =
}
12:46:00.400 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626132
state = 2
reason = 1
}
12:46:00.402 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_vm_ctirp:8000:
cue_pt.(1,28)
|Call:[GCID=
(9040/1),CID=25626132]} NewCall [ state=OFFERING auxData=1 destCM=1 destType=
IN_CLUSTER unModifiedCg=3001
unModifiedCd=8000 unModifiedOriginalCd=8000 unModifiedLastRedirected= calling=3001
callingName=Ext 3001 -
Phone called=8000 calledName= origParty=8000 origName= lastRedirected=
lastRedirectedName= origin=INBOUNDINTERNAL reason=DIRECTCALL activeTone=0
deviceName=cue_vm_ctirp bRemoteInUse=false bPrivacy=false CallSelectStatus=0
CallingPartyPI=True CallingPartyDisplayNamePI=True CalledPartyPI=True
CalledPartyDisplayNamePI=True OriginalCalledPartyPI=True]
12:46:00.424 CST %JTAPI-JTAPIIMPL-7-UNK:{(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE}
Initializing to OFFERING for 8000:cue_pt Cause=CAUSE_NORMAL Reason= 1
12:46:00.424 CST %JTAPI-JTAPI-7-UNK:[[3001:cue_pt/(P1-tacjtapiuser) GCID=
(1,9040)->ACTIVE]->IDLE]creating external connection for 3001:cue_pt
12:46:00.424 CST %JTAPI-JTAPI-7-UNK:{ CcnCall=Call:[GCID=(9040/1),CID=25626132]
Connection=[3001:cue_pt/(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE]->IDLE: creating
new Connection for CCNCall }
12:46:00.425 CST %JTAPI-JTAPI-7-UNK:[9040/1]CallImpl.deliverEvents(): for all
1 observers
12:46:00.430 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_ROUTE_CALL_EV][[
8000:cue_pt/(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE]->OFFERED]Request: redirect
(8501, REDIRECT_NORMAL, DEFAULT_SEARCH_SPACE, CALLED_ADDRESS_UNCHANGED,
REDIRECT,8501,null,REDIRECT_WITHOUT_MODIFIED_CALLING_PARTY,1)
12:46:00.430 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
[SS_TEL_ROUTE_CALL_EV] sending: com.cisco.cti.protocol.CallRedirectRequest {
callLegID = 25626132
redirectAddress = 8501

unconditional = false
redirectReason = 0
preferredOriginalCalledParty = 8501
}

Новый вызов к порту CTI

12:46:00.460 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received 
Event: com.cisco.cti.protocol.NewCallEvent {
deviceName = cue_ctiport1
callLegID = 25626133
callID = 9040
callingParty = 3001

calledParty = 8501
originalCalledParty = 8000
reason = 6
lastRedirectingParty = 8000
callingPartyDeviceName = SEP0023331C29EC
}
12:46:00.463 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Event: com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626133
state = 2
}
12:46:00.464 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Response: com.cisco.cti.protocol.CallRedirectResponse {
result = 0
}
12:46:00.468 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Event: com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626132
state = 1
farEndpointSpecified = true
fwdDestinationAddress =
reason = 68501
callingParty = 3001
callingPartyName = Ext 3001 - Phone
calledParty = 8000 }
12:46:00.481 %JTAPI-JTAPIIMPL-7-UNK:{(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE}
Initializing to OFFERING for 8501:cue_pt Cause=CAUSE_REDIRECTED Reason= 6
12:46:00.481 %JTAPI-JTAPIIMPL-7-UNK:{(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE}
Received a redirected call -- lastRedAddress is 8000
12:46:00.487 %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_ctiport1:8501:cue_pt.
(1,24)|Call:[GCID=(9040/1),CID=25626133]} CallStateChanged [ state=OFFERING
cause=NOERROR
]
12:46:00.489 %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_vm_ctirp:8000:cue_pt.
(1,28)|Call:[GCID=(9040/1),CID=25626132]} CallStateChanged [ state=IDLE cause=
NOERROR destType=IN_CLUSTER destCM=1 fwdDestination=8501]

Порт CTI принимает перенаправленный вызов

12:46:00.490 %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_CALL_CONN_OFFERED:8501]
[[8501:cue_pt/(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE]->OFFERED]Request: accept()
12:46:00.491 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_CALL_
CONN_OFFERED:8501] sending: com.cisco.cti.protocol.CallAcceptRequest {
callLegID = 25626133
}
12:46:00.495 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response:
com.cisco.cti.protocol.CallAcceptResponse {
result = 0
}
12:46:00.498 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626133
state = 3

12:46:00.499 %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_ctiport1:8501:cue_pt.
(1,24)|Call:[GCID=(9040/1),CID=25626133]} CallStateChanged [ state=ACCEPTED
cause=NOERROR]
12:46:00.502 %JTAPI-JTAPIIMPL-7-UNK.(P1-tacjtapiuser) Terminal "cue_ctiport1"
in service
12:46:00.503 %JTAPI-JTAPIIMPL-7-UNK:{(P1-tacjtapiuser) GCID=(1,9040)->ACTIVE}
Handling
External STATE_RINGBACK for 3001:cue_pt
12:46:00.517 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
[ENG_TASK:0x98bca5a08_voicebrowser.aef] sending:
com.cisco.cti.protocol.CallAnswerRequest {
callLegID = 25626133
}
12:46:00.522 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response:
com.cisco.cti.protocol.CallAnswerResponse {
result = 0
}
12:46:00.530 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626133
state = 8

Согласование среды

12:46:00.531 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event: 
com.cisco.cti.protocol.DeviceCallOpenLogicalChannelEvent {
callLegID = 25626133
compressionType = 4

}
12:46:00.531 %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_ctiport1:8501:
cue_pt.(1,24)|Call:[GCID=(9040/1),CID=25626133]} CallStateChanged
[ state=CONNECTED cause=NOERROR]
12:46:00.537 %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[SS_TEL_OPEN_LOGICAL_CHANNEL:
8501][cue_ctiport1]
Request: setRTPParams(CiscoRTPParams192.168.105.224/16384)
12:46:00.537 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_OPEN_
LOGICAL_CHANNEL:8501] sending:
com.cisco.cti.protocol.DeviceSetRTPForCallRequest {
callLegID = 25626133
ipAddress = -529946432
rtpPortNumber = 16384

}
12:46:00.540 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response:
com.cisco.cti.protocol.DeviceSetRTPForCallResponse {
result = 0
}
12:46:00.591 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.StartReceptionEvent {
callLegID = 25626133
ipAddr = -529946432
rtpPortNumber = 16384
compressionType = 4
}
12:46:00.596 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.StartTransmissionEvent {
callLegID = 25626133
ipAddr = -1167415104
rtpPortNumber = 22668
compressionType = 4
}

Отключение вызова

12:46:09.438 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event: 
com.cisco.cti.protocol.StopReceptionEvent {
callLegID = 25626133
}
12:46:09.438 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.StopTransmissionEvent {
callLegID = 25626133
}
12:46:09.441 %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626133
state = 1
cause = 16

12:46:09.443 %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_ctiport1:8501:
cue_pt.(1,24)|Call:[GCID=(9040/1),CID=25626133]} CallStateChanged
[ state=IDLE cause=NORMALCALLCLEARING]

MWI, Вкл\выкл Сигнализирующий

CUE включает индикатор MWI для линии 3001

12:46:02.714 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[Thread-88][8501:cue_pt]
Request:
setMessageWaiting ( 3001,true )
12:46:02.714 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [Thread-88]
sending: com.cisco.cti.protocol.LineSetMessageWaitingRequest {
sequenceNumber = 57
lineName = 3001
lampMode = 2

}
12:46:02.718 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Response: com.cisco.cti.protocol.LineSetMessageWaitingResponse {
sequenceNumber = 57
result = 0
}

Набранный DTMF количество '3' для удаления сообщения из почтового ящика

12:55:52.145 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event: 
com.cisco.cti.protocol.DtmfEvent {
eventSequence = 70
callLegID = 25626160
digit = 3
}
12:55:52.145 CST %JTAPI-CTIIMPL-7-UNK.(P1-192.168.100.10) EventThread handling
event com.cisco.cti.protocol.DtmfEvent[70]
12:55:52.146 CST %JTAPI-CTI-7-UNK.(){Line:cue_ctiport1:8501:cue_pt.(1,64)|Call:
[GCID=(9047/1),CID=25626160]}
DTMF [digit=3]

CUE выключает индикатор MWI для линии 3001

12:55:52.209 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[Thread-86][8501:cue_pt]
Request: setMessageWaiting ( 3001,false )
12:55:52.209 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [Thread-86] sending:
com.cisco.cti.protocol.LineSetMessageWaitingRequest {
sequenceNumber = 62
lineName = 3001
lampMode = 1

}
12:55:52.212 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response:
com.cisco.cti.protocol.LineSetMessageWaitingResponse {
sequenceNumber = 62
result = 0
}

Журналы CCN в реальном времени

(Выходные данные от журналов CCN в реальном времени)

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

Настройка вызова

12:46:00.425 ACCN TELS 0  assigned STANDARD-worker-8
12:46:00.425 ACCN TELS 0 Route Connection=[8000:cue_pt/(P1-tacjtapiuser) GCID=
(1,9040)->ACTIVE]->OFFERED, reason=1...
12:46:00.426 ACCN TELS 0 Call.received() JTAPICallContact[id=7,type=Cisco JTAPI
Call,implId=9040/1,active=true,state=CALL_RECEIVED,inbound=true...
12:46:00.429 ACCN TELS 0 Route Connection: [8000:cue_pt/(P1-tacjtapiuser)
GCID=(1,9040)->ACTIVE]->OFFERED, CTI Port selected: TP[id=0,implId=8501,
state=IN_USE]
12:46:00.429 ACCN TELS 0 RouteCallObserver.callChangedEvent: redirecting to
8501
, css=default
12:46:00.480 ACCN TELS 0 Call.associated() JTAPICallContact[id=7,type=Cisco
JTAPI Call,implId=9040/1,active=true,state=CALL_RECEIVED,
12:46:00.480 ACCN TELS 0 Route Connection: [8000:cue_pt/(P1-tacjtapiuser)
GCID=(1,9040)->ACTIVE]->OFFERED has 1 current sessions active.
12:46:00.484 ACCN TELS 0 CallID: 7, MediaID: 9040/1 CallCtlConnOfferedEv
received for CTI Port: 8501, lastRedirectedAddress: 8000
12:46:00.490 ACCN TELS 0 assigned STANDARD-worker-9
12:46:00.490 ACCN TELS 0 Route TR[num=8000], event=(P1-tacjtapiuser) 9040/1
CallCtlConnDisconnectedEv 8000:cue_pt [#108] Cause:100 CallCtlCause:0
CiscoCause:0 CiscoFeatureReason:6, cause=CAUSE_NORMAL[100],
meta=META_CALL_REMOVING_PARTY[131]
12:46:00.499 ACCN TELS 0 CallID: 7, MediaID: 9040/1 Accepting call for CTI
Route Point: 8000 on CTI Port: 8501, ciscoCause=31
12:46:00.501 ACCN TELS 0 Call.accepted() JTAPICallContact[id=7,type=Cisco
JTAPI Call,implId=9040/1,active=true,state=CALL_RECEIVED...
12:46:00.501 ACCN TELS 0 CallID:7 MediaId:9040/1, TerminalConnection to
Terminal: cue_ctiport1 is RINGING, [8501:cue_pt/(P1-tacjtapiuser)
GCID=(1,9040)->ACTIVE]->ALERTING
12:46:00.504 ACCN TELS 0 CallID:7 MediaId:9040/1 com.cisco.jtapi.
CiscoTermInServiceEvImpl received
12:46:00.504 ACCN TELS 0 TR[num=8000] Get TriggerMap[] return:
{secondaryDialogGroup=0, primaryDialogGroup=0}
12:46:00.513 ACCN TELS 0 Call.attributed() JTAPICallContact[id=7,type=Cisco
JTAPI Call,implId=9040/1,active=true,state=CALL_RECEIVED,...
12:46:00.513 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008 associated
with Task ID: 41000000008
12:46:00.533 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008,
TerminalConnection to Terminal:cue_ctiport1 is ACTIVE
12:46:00.534 ACCN TELS 0 Call.answered() JTAPICallContact[id=7,type=
Cisco JTAPI Call,implId=9040/1,active=true,state=CALL_ANSWERED,...
12:46:00.536 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
com.cisco.jtapi.CiscoMediaOpenLogicalChannelEvImpl received
12:46:00.593 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
com.cisco.jtapi.CiscoRTPInputStartedEvImpl received
12:46:00.597 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
com.cisco.jtapi.CiscoRTPOutputStartedEvImpl received

Отключение вызова

12:46:09.442 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008 
com.cisco.jtapi.CiscoRTPInputStoppedEvImpl received
12:46:09.443 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
com.cisco.jtapi.CiscoRTPOutputStoppedEvImpl received
12:46:09.447 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
gets TermConnDroppedEv, meta code:132, cause code:100
12:46:09.447 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008,
TerminalConnection to Terminal: cue_ctiport1 is DROPPED, 9040/1
12:46:09.448 ACCN TELS 0 CallID:7 MediaId:9040/1 is removed from call session
mapping in Session[id=0x60db88402,parent=null,active=true,state=SESSION_IN_USE,
time=1354733160426], result:true
12:46:09.466 ACCN TELS 0 Call.abandoned() JTAPICallContact[id=7,type=Cisco
JTAPI Call,implId=9040/1,active=false,state=CALL_DISCONNECTED,...
12:46:09.466 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008, released TP
[type=Cisco CTI Port,id=0,implId=8501,active=false,state=IDLE] from 8000, and
releasing udpPort 16384
12:46:09.467 ACCN TELS 0 CallID:7 MediaId:9040/1 Task:41000000008
com.cisco.jtapi.TermObservationEndedEvImpl received

Устранение проблем примеров практического применения

Проблемы подключения

В этом сценарии порты CUE и спусковые механизмы не регистрируются в должном CUCM к отсутствия подключения между CUE и CUCM.

CUE# show log name CiscoJtapi1.log tail
!! or show log name CiscoJtapi2.log tail
456: 13:20:28.331 CDT %JTAPI-MISC-7-UNK.(P20-) started preloading classes
457: 13:20:28.331 CDT %JTAPI-MISC-7-UNK.(P20-) finished preloading classes
461: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) EventThread queue size
threshold is 25
462: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) Provider retry interval is set
to 30 seconds
463: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) Client desired server heartbeat
time is set to 30 seconds
464: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) CTI request timeout is is set to
30 seconds
465: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) Provider open request timeout
is set to 200 seconds
467: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) Provider Reconnect attempts is
set to 0
468: 13:20:28.331 CDT %JTAPI-CTI-7-UNK.(P20-) JAVA Socket Connect Timeout is
set to 15 seconds
469: 13:20:28.332 CDT %JTAPI-CTIIMPL-7-UNK.(P20-) Provider.info(CCMEncryption:
:encryptPassword was successful)
471: 13:20:28.334 CDT %JTAPI-JTAPIIMPL-7-UNK.ProviderImpl(): calling
jtapiProperties.getSecurityPropertyForInstance()
472: 13:20:28.334 CDT %JTAPI-JTAPIIMPL-7-UNK.(P20-tacjtapiuser ) TraceModule:
JTAPI version Cisco Jtapi version 7.0(1.1000)-1 Release
473: 13:20:28.334 CDT %JTAPI-JTAPIIMPL-7-UNK.(P20-tacjtapiuser ) Route Select
Timeout is 5000 msecs
474: 13:20:28.335 CDT %JTAPI-JTAPIIMPL-7-UNK.(P20-tacjtapiuser ) Jtapi post
condition timeout is set to 15 seconds
476: 13:20:28.335 CDT %JTAPI-CTIIMPL-7-UNK.(P20-tacjtapiuser ) Opening server
"192.168.100.10" login "tacjtapiuser "

477: 13:20:28.335 CDT %JTAPI-CTIIMPL-7-UNK.(P20-tacjtapiuser ) ProviderID =
P20-tacjtapiuser 478: 13:20:28.337 CDT %JTAPI-CTIIMPL-7-UNK.(P20-tacjtapiuser )
Trying to create normal socket connection to 192.168.100.10
479: 13:20:38.338 CDT %JTAPI-JTAPI-7-UNK:[DefaultJtapiPeer]PlatformExceptionImpl
caught:
Unable to create provider --

Примечание: Секунды метки времени проходят с 13:20:28 до 13:20:38; поэтому, мы можем сказать, что CUE не смог открыть TCP - сокет в течение 10 секунд перед подтверждением неспособности создать поставщика.

Проблемы аутентификации

В этом сценарии порты CUE и спусковые механизмы не в состоянии регистрироваться в CUCM, потому что не совпадают пароли, настроенные между CUE и CUCM.

Журнал CCN

CUE# show trace buffer tail
Press CTRL-C to exit...
140053.173 ACCN TELS 0 TAPIPortGroup Leaving getActiveCCM(), retvalnull
140123.184 ACCN TELS 0 TAPIPortGroup Enter getActiveCCM()
140123.184 ACCN TELS 0 TAPIPortGroup getActiveCCM() subsystemstate3
140123.184 ACCN TELS 0 TAPIPortGroup getActiveCCM() subsystemJTAPI is not
inservice or partial service

140123.184 ACCN TELS 0 TAPIPortGroup Leaving getActiveCCM(), retvalnull

atrace.log

14:12:18.681 ACCN TELS 0 JTAPI_PROVIDER_EVENT:JTAPI Provider state is changed: 
JTAPI provider name=192.168.100.10,Event=ProvShutdownEv received
14:12:18.682 ACCN TELS 0 SS_LOGIN:JTAPI Login String: Module=JTAPI Subsystem,
JTAPI login string=192.168.100.10;login=tacjtapiuser ;passwd=****;appinfo=
Cisco IP IVR
14:12:18.682 ACCN TELS 0 PROVIDER_CLEANUP:Cleaning up JTAPI provider:
Module=JTAPI Subsystem,JTAPI provider name=192.168.100.10
14:12:18.682 ACCN TELS 0 TAPIPortGroup 1 getNumPorts() for Cisco CTI Port = 2
14:12:18.682 ACCN TELS 0 TPG[id=1,state=PARTIAL_SERVICE] removeRoute() -
TR[num=9500]
14:12:18.682 ACCN TELS 0 TPG[id=1,state=PARTIAL_SERVICE] removeRoute() -
TR[num=9000]
14:12:18.682 ACCN TELS 0 MwiAddress.clear: [addrStr=, addr=null, inService=false,
isRegistered=false]
14:12:18.682 ACCN TELS 0 MwiAddress.unregister: [addrStr=, addr=null,
inService=false, isRegistered=false]
14:12:18.682 ACCN TELS 0 TAPIPortGroup 1 getNumPorts() for Cisco CTI Port = 0
14:12:18.682 ACCN TELS 0 Number of CTI ports = 0
14:12:18.682 ACCN TELS 0 calculateSubsystemState
14:12:18.682 ACCN TELS 0 TPG[id=1,state=PARTIAL_SERVICE] Triggers: ISV = 0,
OOS = 0, PARTIAL = 0
14:12:18.682 ACCN TELS 0 TAPIPortGroup 1 getNumPorts() for Cisco CTI Port = 0
14:12:18.682 ACCN TELS 0 calculateSubsystemState -> Groups: ISV = 0, OOS = 0,
PARTIAL/OTHERS = 1
14:12:18.682 ACCN TELS 0 calculateSubsystemState -> Triggers: ENABLED = 0,
DISABLED = 2, CONFIG ERR = 0
14:12:18.682 ACCN TELS 0 calculateSubsystemState -> subsystem partial in
service, unchanged cause:
A number of route points are OOS - TR[num=9000], TR[num=9500]; A number of
CTI ports are OOS - TPG[id=1,state=PARTIAL_SERVICE].Ports[9590]
14:12:18.689 ACCN TELS 0 SS_PARTIAL_SERVICE:JTAPI subsystem in partial service:
Failure reason=A number of route points are OOS - TR[num=9000], TR[num=9500];
A number of CTI ports are OOS - TPG[id=1,state=PARTIAL_SERVICE].Ports[9590]
14:12:18.689 ACCN TELS 0 GET_NEW_PROVIDER:Attempt to get JTAPI provider
14:12:18.693 ACCN TELS 0 Calling updateJTAPIPackage: 192.168.100.10
Module=JTAPI_PROVIDER_INIT,Exception=com.cisco.jtapi.PlatformExceptionImpl:
Unable to create provider
-- bad login or password.
14:12:18.828 ACCN TELS 0 EXCEPTION:com.cisco.jtapi.PlatformExceptionImpl:
Unable to create provider
-- bad login or password.

CiscoJtapi1.log / CiscoJtapi2.log

6318: 14:22:26.653 CDT %JTAPI-CTIIMPL-7-UNK.(P62-tacjtapiuser   ) Trying to 
create normal socket connection to 192.168.100.10

6319: 14:22:26.654 CDT %JTAPI-CTIIMPL-7-UNK.(P62-tacjtapiuser ) connected
6321: 14:22:26.654 CDT %JTAPI-PROTOCOL-7-UNK.(P62-192.168.100.10)
[SS_TEL_REINIT] sending: com.cisco.cti.protocol.ProviderOpenRequest {
provider = 192.168.100.10
qbeClientVersion = Cisco JTAPI 7.0(1.1000)-1 Release
login = com.cisco.cti.protocol.UnicodeString {
unicodedisplayName = tacjtapiuser
}
filter = com.cisco.cti.protocol.ProviderEventFilter {
deviceRegistered = true
deviceUnregistered = true
desiredServerHeartbeatTime = 30
}
6331: 14:22:26.781 CDT %JTAPI-PROTOCOL-7-UNK(P62-192.168.100.10)
received Event: com.cisco.cti.protocol.ProviderOpenCompletedEvent {
eventSequence = 251
reason = -1932787616
providerInfoString = 7.1.2.21900-5
failureDescription = Directory login failed - authentication failed.
providerId = 16777255
}
6333: 14:22:26.781 CDT %JTAPI-PROTOCOL-7-UNK.(P62-192.168.100.10)
received Event: com.cisco.cti.protocol.ProviderClosedEvent {
eventSequence = 252
reason = 4
}
6338: 14:22:26.781 CDT %JTAPI-PROTOCOL-7-UNK.(P62-192.168.100.10)
Received ProviderClosedEvent
6339: 14:22:26.781 CDT %JTAPI-PROTOCOL-7-UNK.(P62-192.168.100.10)
received Event: com.cisco.cti.protocol.ProviderOutOfServiceEvent {
eventSequence = 253
PROVIDER_OUT_OF_SERVICE_EVENT = 200
}
6343: 14:22:26.782 CDT %JTAPI-JTAPI-7-UNK:[DefaultJtapiPeer]
PlatformExceptionImpl caught: Unable to create provider -- bad login or password.
6344: 14:22:26.881 CDT %JTAPI-CTIIMPL-7-UNK.(P62-192.168.100.10) ReceiveThread:
caught java.net.SocketException: The socket was closed

Пользователь, не поддерживающий CTI

В этом сценарии порты CUE и спусковые механизмы не в состоянии регистрироваться в CUCM, потому что пользователь приложения JTAPI не был добавлен к Включенной группе разрешений стандартного CTI в стороне CUCM. Поэтому, даже когда учетные данные пользователя подтверждают подлинность соответственно, пользователь JTAPI, tacjtapiuser в этом случае, не может управлять никакими устройствами через CTI и JTAPI.

CiscoJtapi1.log / CiscoJtapi2.log

11590:14:41:08.768 CDT %JTAPI-PROTOCOL-7-UNK.(P115-192.168.100.10) 
[ProviderRetryThread] sending:
com.cisco.cti.protocol.ProviderOpenRequest {
provider = 192.168.100.10
qbeClientVersion = Cisco JTAPI 7.0(1.1000)-1 Release
login = com.cisco.cti.protocol.UnicodeString {
unicodedisplayName = tacjtapiuser
}
applicationID = Cisco IP IVR
desiredServerHeartbeatTime = 30
requestTimer = 0
cmAssignedApplicationID = 0
pluginName = CiscoJTAPI
}
11593:14:41:08.770 CDT %JTAPI-PROTOCOL-7-UNK.(P115-192.168.100.10)
received Response: com.cisco.cti.protocol.ProviderOpenResponse {
sequenceNumber = 117
result = 0
providerInfoString = 7.1.2.21900-5
clientHeartbeat = 30
serverHeartbeat = 30
requestTimer = 5
pluginVersion = 7.1.2.10000-5
pluginLocation = http://192.168.100.10/plugins/
providerId = 16777220
}
11600: 14:41:08.899 CDT %JTAPI-PROTOCOL-7-UNK.(P115-192.168.100.10)
received Event: com.cisco.cti.protocol.ProviderOpenCompletedEvent {
eventSequence = 461
reason = -1932787617
sequenceNumber = 117
failureDescription = Directory login failed - User not present in Standard
CTI Users group.

providerId = 16777220
}
11608:14:41:08.900 CDT %JTAPI-PROTOCOL-7-UNK.(P115-192.168.100.10)
received Event:
com.cisco.cti.protocol.ProviderOutOfServiceEvent {
eventSequence = 463
PROVIDER_OUT_OF_SERVICE_EVENT = 200

}

Диспетчер CTI CUCM Сервайс не работает

В этом сценарии не могут зарегистрироваться порты CUE и спусковые механизмы, потому что диспетчер CTI CUCM Сервайс не работает или в аварийном статусе. Это получает "соединение, которому отказывают" ошибка для попытки подключения CUE к порту TCP JTAPI 2748.

18956: 16:25:45.516 CDT %JTAPI-CTIIMPL-7-UNK.(P200-) Provider.
info(CCMEncryption::encryptPassword was successful)
18957: 16:25:45.516 CDT %JTAPI-CTIIMPL-7-UNK.(P200-) application did
not set appinfo, creating default
18958: 16:25:45.516 CDT %JTAPI-JTAPIIMPL-7-UNK.ProviderImpl(): calling
jtapiProperties.getSecurityPropertyForInstance()
18959: 16:25:45.516 CDT %JTAPI-JTAPIIMPL-7-UNK.(P200-tacjtapiuser )
TraceModule: JTAPI version Cisco Jtapi version 7.0(1.1000)-1 Release
18960: 16:25:45.516 CDT %JTAPI-JTAPIIMPL-7-UNK.(P200-tacjtapiuser )
Route Select Timeout is 5000 msecs
18961: 16:25:45.516 CDT %JTAPI-JTAPIIMPL-7-UNK.(P200-tacjtapiuser )
Jtapi post condition timeout is set
to 15 seconds
18962: 16:25:45.516 CDT %JTAPI-JTAPIIMPL-7-UNK.(P200-tacjtapiuser )
IgnoreFwdDestination
set to false
18963: 16:25:45.516 CDT %JTAPI-CTIIMPL-7-UNK.(P200-tacjtapiuser )
Opening server "192.168.100.10" login "tacjtapiuser "
18964: 16:25:45.516 CDT %JTAPI-CTIIMPL-7-UNK.(P200-tacjtapiuser )
ProviderID = P200-tacjtapiuser
18965: 16:25:45.517 CDT %JTAPI-CTIIMPL-7-UNK.(P200-tacjtapiuser )
Trying to create normal socket connection to 192.168.100.10
18966: 16:25:45.518 CDT %JTAPI-JTAPI-7-UNK:[DefaultJtapiPeer]
PlatformExceptionImpl caught:
Unable to create provider -- 192.168.100.10/192.168.100.10:2748 -
Connection refused

Несоответствие конфигурации

В этом сценарии CUE не в состоянии зарегистрировать спусковой механизм JTAPI в количестве 9999, потому что RP CTI, с которым это должно совпасть, не настроен, или это не было добавлено к? управляемые устройства? для пользователя на стороне CUCM. CUE понимает это после того, как он получает GetDeviceInfoFetchResponse от CUCM и замечает, что нет устройства в домене поставщика услуг, который обращается ко всем управляемым устройствам тем пользователем, который совпал бы с более аккуратным количеством, которое он настроил локально. CUE тогда не пытается передать DeviceOpenRequest за тем определенным спусковым механизмом, и вместо этого только сообщает об исключении в следах. CUE все еще пытается зарегистрировать все другие устройства, которые являются в домене поставщика, передаваемом CUCM.

13:27:58.864 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response: 
com.cisco.cti.protocol.GetDeviceInfoFetchResponse {
com.cisco.cti.protocol.DeviceInfo {
name = cue_vm_ctirp
}
13:27:58.960 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
sending: com.cisco.cti.protocol.DeviceGetLineInfoRequest {
deviceName = cue_vm_ctirp
}
13:27:58.962 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
sending: com.cisco.cti.protocol.GetLineInfoFetchRequest
13:27:58.964 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Response:
com.cisco.cti.protocol.GetLineInfoFetchResponse{
name = 8000
}
13:27:58.966 CST %JTAPI-CTI-7-UNK(P1-tacjtapiuser) DeviceMap: adding device
"cue_vm_ctirp"
13:27:59.427 CST %JTAPI-JTAPI-7-UNK: InvalidArgumentExceptionImpl caught:
Address 9999 is not in provider's domain.

Примечание: Даже когда спусковой механизм 9999 настроен локально в CUE, это не часть домена поставщика услуг, полученного от CUCM, и поэтому, не регистрируется.

CUE продолжает открывать линию 8000; который включен в поставщика? s домен

13:28:00.953 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT] 
sending: com.cisco.cti.protocol.DeviceOpenRequest {
deviceName = cue_vm_ctirp
13:28:00.979 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
sending: com.cisco.cti.protocol.LineOpenRequest {
deviceName = cue_vm_ctirp
lineName = 8000
13:28:00.983 CST %JTAPI-JTAPIIMPL-7-UNK:cue_vm_ctirp: Lines opened
13:28:00.997 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
sending: com.cisco.cti.protocol.DeviceRegisterDeviceRequest
deviceName = cue_vm_ctirp
13:28:01.000 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser) DeviceMap: opening device
"cue_vm_ctirp"

13:28:01.001 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) [SS_TEL_INIT]
sending: com.cisco.cti.protocol.LineOpenRequest {
lineName = 8000
13:28:01.012 CST %JTAPI-JTAPIIMPL-7-UNK:cue_vm_ctirp: Lines opened
13:28:01.164 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.DeviceRegisteredEvent {
13:28:01.165 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.DeviceInServiceEvent {
13:28:01.166 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received Event:
com.cisco.cti.protocol.LineInServiceEvent {
13:28:01.168 CST %JTAPI-JTAPIIMPL-7-UNK.(P1-tacjtapiuser) Terminal
"cue_vm_ctirp" in service

Проблема маршрутизации вызова CUCM

В этом сценарии пользователь с DN 3001 вызывает CUE для проверки его VM. Вызов представлен пилоту VM CUE (RP CTI) с DN 8000. CUE тогда запрашивает вызов быть перенаправленным к его порту CTI сред с DN 8501, но вызов не в состоянии быть перенаправленным, потому что CSS, настроенный для DN 3001, не имеет доступа к PT, где назначен DN порта CTI.

12:56:01.392 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received 
Event: com.cisco.cti.protocol.NewCallEvent {
deviceName = cue_vm_ctirp
callLegID = 25626135
callID = 9041
callingParty = 3001
calledParty = 8000

originalCalledParty state = 2
}
12:56:01.404 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10)
[SS_TEL_ROUTE_CALL_EV] sending: com.cisco.cti.protocol.CallRedirectRequest {
callLegID = 25626135
redirectAddress = 8501
}
12:56:01.397 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Event: com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626135
state = 2
}
12:56:01.450 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Response: com.cisco.cti.protocol.FailureResponse {
result = -1932787660
description = redirect failure
}
12:56:01.450 CST %JTAPI-JTAPI-7-UNK:[[8000:cue_pt/(P1-tacjtapiuser)
GCID=(1,9041)->ACTIVE]->OFFERED]InvalidPartyExceptionImpl caught:
Request failed because of an invalid destination.
12:56:05.456 CST %JTAPI-PROTOCOL-7-UNK.(P1-192.168.100.10) received
Event: com.cisco.cti.protocol.CallStateChangedEvent {
callLegID = 25626135
state = 1
cause = 17
}
12:56:05.456 CST %JTAPI-CTI-7-UNK.(P1-tacjtapiuser){Line:cue_vm_ctirp:
8000:cue_pt.(1,28)|Call:[GCID=(9041/1),CID=25626135]}CallStateChanged
[ state=IDLE cause=USERBUSY]
12:56:05.457 CST %JTAPI-CTI-7-UNK:{ALL EXTERNAL ADDRESSES|Call(P1-tacjtapiuser)
GCID=(1,9041)->ACTIVE} ExternalCallStateChanged
[ state=IDLE cause=17 processEvent= reason =1 ]
12:56:05.457 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) 9041/1 ConnDisconnectedEv
3001:cue_pt [#160]
Cause:17 CallCtlCause:0 CiscoCause:17 CiscoFeatureReason:12
12:56:05.457 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser)[(P1-192.168.100.10)
EventThread][SEP0023331C29EC] Request: getCallingTerminal()
12:56:05.457 CST %JTAPI-JTAPI-7-UNK.(P1-tacjtapiuser) 9041/1
CallCtlConnDisconnectedEv 3001:cue_pt [#161] Cause:17 CallCtlCause:0
CiscoCause:17 CiscoFeatureReason:12= 8000

Проблемы лицензии

В этом сценарии CUE неспособен зарегистрировать свои порты и спусковые механизмы, потому что не были активированы лицензии на порты VM. Никакие регистрационные попытки не замечены в перехватах из-за той же причины.

Сводка от декодируемого atrace.log:

2551 11:45:17.178 LLMA LAPI 0 Llama: getMaxVmPortCount():
2547 11:45:17.178 LLMA LVMP 0 LlamaVmPortQuery: get(): maxCount
2551 11:45:17.178 LLMA LSDB 0 Llama: getMaxVmPortCount(): LlamaSysdbUser():
getInt(): Getting int /sw/apps/limitsManager/vmPort/query/maxCount returns 0
2551 11:45:17.178 LLMA LAPI 0 Llama: getMaxVmPortCount(): count: 0
2551 11:45:17.178 WFSP JTRG 0 WFSysdbNdJtapiTrg::getMaxSessions for trigger
for app: voicemail 0
2551 11:45:17.178 WFSP JTRG 0 WFSysdbNdJtapiTrg::commit warning session
value exceeded license max

2551 11:45:17.181 WFSP JTRG 0 com.cisco.aesop.sysdb.xactSysdbException:
Session value exceeds license limit
2551 11:45:19.654 LLMA LVMM 0 LlamaVmMbxQuery: get(): licenseStatus
2575 11:45:19.654 LLMA LSDB 0 Llama: showVoicemail(): LlamaSysdbUser():
getInt(): Getting int /sw/apps/limitsManager/vmMbx/query/licenseStatus returns 2
2575 11:45:19.657 LLMA LLMT 0 voicemail disabled, voicemail mailbox
activation count has been set to zero

3456 11:45:23.114 LLMA LAPI 0 Llama: getMaxPortCount():
2555 11:45:23.114 LLMA LPRT 0 LlamaPortQuery: get(): maxCount
3456 11:45:23.115 LLMA LSDB 0 Llama: getMaxPortCount(): LlamaSysdbUser():
getInt(): Getting int/sw/apps/limitsManager/port/query/maxCount returns 0
3456 11:45:23.115 LLMA LAPI 0 Llama: getMaxPortCount(): count: 0
3456 11:45:28.727 ACCN TELS 0 CueCiscoCall:getMajorVer() jtapi version=
7.0(1.1000)-1 majorVer=7
3456 11:45:28.785 ACCN TELS 0 JTAPI Login Str:
192.168.100.10;login=tacjtapiuser ;passwd=****;appinfo=Cisco IP IVR
3456 11:45:28.785 ACCN TELS 0 Actual Login Str:
192.168.100.10;login=tacjtapiuser ;passwd=cisco;appinfo=Cisco IP IVR
3477 11:45:31.330 ACCN TELS 0 Got JTAPI provider: Cisco Jtapi version
7.0(1.1000)-1 Release
3621 11:45:31.338 ACCN TELS 0 JTAPI_PROVIDER_EVENT:JTAPI Provider
state is changed: JTAPI provider name=192.168.100.10,Event=
ProvOutOfServiceEv received

3621 11:45:31.352 ACCN TELS 0 JTAPI_PROVIDER_EVENT:JTAPI Provider state
is changed: JTAPI provider name=192.168.100.10,Event=ProvInServiceEv received
3621 11:45:31.353 ACCN ATJT 0 checkConnectivity:
urlString:http://192.168.100.10/CCMPluginsServer/CiscoJTAPIClient.exe
3477 11:45:34.130 ACCN TELS 0 SS_OUT_OF_SERVICE:JTAPI subsystem in
out of service:
Failure reason=A number of route points are OOS; A number of
CTI ports are OOS
- all ports in TPG
3751 11:45:48.558 ACCN TELS 0 TAPIPortGroup: getActiveCCM() subsystemJTAPI
is not in service or partial service

Лучшие методы

CUE только поддерживает кодек G711ulaw; поэтому в почти каждых развертываниях перекодировщик требуется для CUE связаться с другими устройствами или транками, которые используют другие кодеки (включает G711Alaw). То же самое касается DTMF, взаимодействующего с устройствами, которые только поддерживают внутриполосный DTMF, где также требуется ресурс Media Termination Point (MTP). Из-за этих ограничений Cisco рекомендует:

  • Создать отдельный Аппаратный пул для использования только CUE? s RP CTI и порты CTI. Если несколько CUE интегрированы с CUCM, затем создайте Аппаратный пул на CUE.
  • Создайте отдельную область только для RP и портов CUE и примените его к тому отдельному Аппаратному пулу.
  • Гарантируйте, что область настроена для разрешения только G711 со всеми другими областями.
  • Гарантируйте, что Список Media Resource Groups (MRGL) с доступными ресурсами перекодировки применен к Аппаратному пулу RP CTI CUE и портов CTI так, чтобы они имели доступ к ресурсу транскодера, при необходимости.

  • Если пользователь неспособен перейти через голосовые меню с Тонами DTMF, то возможно, что ресурс MTP должен быть добавлен к MRGL устройств CUE.

Создайте отдельный профиль VM для CUE в CUCM

Во избежание некоторых недавних проблем, наблюдаемых с диспетчером CTI CUCM, рекомендуется привязать все телефоны к пользователю JTAPI CUE на стороне CUCM вместо только RP CTI и портов.


Если требуется функциональность Survivable Remote Site Telephony (SRST):

  • Гарантируйте, что соответствующий спусковой механизм SIP настроен для каждого JTAPI, включают CUE.
  • Гарантируйте, что точки вызова добавлены к маршрутизатору для филиалов, чтобы позволить вызовам маршрутизироваться к модулю CUE через SIP в то время как в режиме SRST.
  • Настройте Маску Внешнего номера каждой из точек маршрута CTI, а также маску для поля CFU (Call Forward Unregistered) в CUCM, чтобы гарантировать, что CUCM направляет вызовы, предназначенные для модуля филиала компании через локальный шлюз открытой коммутируемой телефонной сети (PSTN), когда подключение между CUCM и CUE было потеряно или если вызвана автоматическая альтернативная маршрутизация (AAR). Дополнительные правила трансляции могли бы требоваться для маршрутизатора для филиалов быть в состоянии направить входящие вызовы от PSTN до модуля CUE также.
  • Если прямая Передача в подход конфигурации VM присутствует в стороне CUCM, и пользователь хочет поддержать эту функциональность, в то время как в SRST CME, то необходимо использовать старый фиктивный DN с подходом конфигурации Переадресации всех вызовов (CFA), который использовался для CME, прежде чем функциональная клавиша TransferToVM стала доступной. Отнеситесь для Передачи Абонента Непосредственно в Ящик экспресс-почты Unity для получения дополнительной информации. Вот пример того, как это может посмотреть. Следует иметь в виду, что это может только быть сделано, если SRST CME используется и не устаревший call-manager-fallback SRSTwith.
    • Предположите, что DN находятся в диапазоне 200-299.
      1. Вызов наталкивается на x201.
      2. Настройте ephone-dn с этой командой:
        ephone-dn 99
        number 2..
        call-forward all <VM Pilot>
      3. В точке вызова, указывающей на CUE:
        1. Используйте правило исходящего преобразования и профиль, чтобы разделить снабженную префиксом звездочку (" * ") и заменить Dialed Number Information Service перенаправления (RDNIS) назад к номеру состоящий из цифр оригинала 3, например, 201, или с полным количеством E.164 в случае, если phonenumber был настроен с полным DID в CUE.
        2. Гарантируйте Заголовок разноса INVITE, который передается соответствиям CUE phonenumber, настроенный для пользователя на стороне CUE.

Чек-лист для регистрационного устранения проблем порта

  1. Проверьте конфигурацию на стороне CUCM:
    1. Диспетчер CTI, CallManager, и Административный XML (AXL) веб-сервисы включили и запустились?
    2. Порты CTI и точка маршрута были настроены и назначили уникальное DN?
    3. CTI пользователя JTAPI включен, и он имеет доступ API AXL?
    4. Пользователь JTAPI имеет контроль над всеми точками маршрута CTI и портами?
    5. Иногда это - хорошая идея перезапустить сервис Диспетчера CTI на всех серверах после того, как будет добавлена конфигурация. Однако это могло быть сервисным влиянием и его желательным для планирования периода технического обслуживания, потому что это влияет на все другие устройства, которые используют CTI и JTAPI с CUCM, таким как Унифицированный Contact Center Express (UCCX), Помощник диспетчера IP (IPMA), Консоль оператора, AA третьей стороны или приложения ACD, и т.д.
  2. Проверьте конфигурацию на стороне CUE:
    1. Call-agent определен как CUCM?
    2. Лицензии порта были включены? Лицензии на пробное пользование приемлемы для начальной конфигурации.
    3. В состоянии вы для прозванивания CUCM?
    4. Учетные данные пользователя JTAPI были добавлены должным образом, и агенты вызовов были определены?
    5. Модуль был повторно загружен так, чтобы были применены изменения конфигурации?
    6. Если RP CTI и порт не импортированы из CUCM автоматически, то попытайтесь вручную добавить DN порта под jtapi подсистемы ccn, а также спусковые механизмы jtapi для каждого RP CTI и повторно загрузить модуль.

Если все эти элементы подтверждены, то следующий шаг должен получить следы JTAPI на CUE и возможно следы CTI CUCM для дальнейшей изоляции проблемы.

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


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

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


Document ID: 116060