отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Проблема с CUCM AutoLogout (EM)

Коллеги, испытываю трудности в следующем сценарии:

1) Intra-cluster Multiple Login Behavior выставлен в  Auto logout
2) Логин на первом телефоне SEP04C5A4B1D2A0
3) Дисконнект первого телефона (выключение компьютера, отключение телефона от сети и тд)
4) Логин на втором телефоне SEPAC220B7E0C74
5) По JTAPI приходит только сообщение CiscoAddrOutOfService
 Array<terminals>  [2]
[0]: Str<terminal> = SEP04C5A4B1D2A0 ; Bool<inService> = false ; Bool<isSharedLine> = true
[1]: Str<terminal> = SEPAC220B7E0C74 ; Bool<inService> = true ; Bool<isSharedLine> = true

Должен был сработать auto logout и придти сообщение CiscoAddrRemovedFromTerminal, но этого не происходит, из-за чего по JTAPI получается, что это Shared Line из-за чего некорректно работают системы, общающиеся с CUCM по JTAPI.


6) Если включить в сеть обратно первый телефон SEP04C5A4B1D2A0, то по JTAPI тут же приходит сообщение CiscoAddrRemovedFromTerminal и DN перестает быть shared line.

По логике, Auto logout должен делать логаут первого телефона и освобождение DN, когда на другом телефоне происходит логин девайс профиля, вне зависимости от того включен ли первый телефон или нет. По факту логаут происходит (первый телефон убирается из Dependency records экстеншен мобилити девайс профиля), но DN девайс профиля по-прежнему остается закрепленным за первым телефоном, пока его не включат в сеть.

Почему может не отрабатывать Logout ?

5 ОТВЕТ.
Cisco Employee

Добрый день Сергей,

Добрый день Сергей,

Какая версия CUCM и какие именно системы работают некорректно, когда второй DN OutOfService?

New Member

Добрый день, Владимир.

Добрый день, Владимир.

 Проблема воспроизводится на CUCM 11.0.1.20000-2 и 10.5.2.12901-1. Некорректно работает служба CTI Manager, т.к. по JTAPI он отдает информацию, что DN все еще есть на обоих девайсах SEP04C5A4B1D2A0 и SEPAC220B7E0C74, хотя этот DN принадлежит девайс профилю экстеншн мобилити и девайс профиль был автоматически вылогинен с первого девайса SEP04C5A4B1D2A0, когда во время его оффлайна был произведен логин на второй девайс SEPAC220B7E0C74.

 Получается, девайс профиль был автоматически (из-за auto logout) вылогинен с первого телефона, но DN девайс профиля остается привязанным к телефону, пока телефон снова не зайдет в сеть. Именно такая информация приходит от CTI Manager по JTAPI.

 При этом сегодня обнаружилось, что DN такого вылогиненного в оффлайне телефона не спадает с него даже после 8 часов оффлайна (Intra-cluster Maximum Login Time)

Cisco Employee

Добрый вечер Сергей,

Добрый вечер Сергей,

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

Если проблема критичная - откройте кейс и инженер выяснит это у разработчиков.

В случае признания этого поведения дефектом он будет исправлен.

New Member

Добрый день, Владимир.

Добрый день, Владимир.

 

От этого страдают приложения, которые определяют Shared Line по сообщениям JTAPI. В частности система записи Verint.

 

Verint (а точнее Cisco JTAPI Client) не получает сообщения CiscoAddrRemovedFromTerminal, когда пользователь логинится в профиль на втором телефоне, автоматически вылогинивая первый телефон, который находится в оффлайне. То есть сценарий такой:

 

1) Агент логинится в профиль Extension mobility на первый телефон.

2) Агент выключает компьютер с CIPC (или просто телефон отключается от сети) без logout.

3) Агент логинится в свой профиль на втором телефоне.

4) Девайс профиль был автоматически (из-за auto logout) вылогинен с первого телефона, но DN девайс профиля остается привязанным к первому телефону, пока он снова не зайдет в сеть (об этом говорит CTI Manager через JTAPI-сообщения, см. ниже).

5) По JTAPI сообщения CiscoAddrRemovedFromTerminal первого телефона не приходит во время логина пользователя в профиль, то есть согласно сообщениям JTAPI к DN остаются привязаны два телефона, один в inService = false (первый), а второй inService = true (на котором залогинен в профиль агент) и что данный DN является isSharedLine = true.'

6) Из-за параметра isSharedLine = true система записи считает, что данный DN является общей линией, что ведет к своим проблемам.

7) Как только первый телефон вновь регистрируется на CUCM, по JTAPI от CTI Manager приходит сообщение CiscoAddrRemovedFromTerminal с параметром isSharedLine = false. Сам телефон после регистрации соответственно не имеет DN профиля Extension Mobility (что естественно правильно).

 

То есть проблема заключается в том, что если телефон с залогиненным профилем ушел в оффлайн, где в оффлайне был вылогинен из профиля, то сообщение по JTAPI от CTI Manager CiscoAddrRemovedFromTerminal, повествующее, что DN профиля мобильности удален с устройства приходит только когда этот телефон возвращается в сеть обратно, а не в тот момент, когда происходит фактический логаут (то есть когда на втором телефоне в профиль логинится агент).

 

Получается, девайс профиль был автоматически (из-за auto logout) вылогинен с первого телефона, но DN девайс профиля остается привязанным к телефону, пока телефон снова не зайдет в сеть. Именно такая информация приходит от CTI Manager по JTAPI.

Cisco Employee

Добрый день Сергей,

Добрый день Сергей,

Да, я понял, открывайте кейс и мы разберемся.

Также подскажите, был ли уже сделан анализ данной проблемы со стороны Verint?

69
Просмотры
0
Полезный материал
5
Ответы