Доступ к одному номеру на устройстве с двумя режимами работы

[nkiliddar]

У меня есть пользователи, которые включают функцию Single Number Reach на устройствах с двумя режимами, настроенных через портал самообслуживания, который создает идентификатор мобильности на устройстве с двумя режимами в cucm. Когда пользователь звонит со своего мобильного телефона, и этот номер также является идентификатором мобильности на устройстве с двумя режимами, пытается перезвонить на DID-номера предприятия, звонок не проходит, либо обрывается, либо не звонит на целевом устройстве. Ошибка, которую я вижу в трассировках sdl DbMobility IMS Match: нет соответствующей записи ims для удаленного назначения Поведение очень непоследовательное, независимо от того, включено ли устройство с двумя режимами работы (Webex TCT или BOT). Для тестирования я настроил профиль удаленного назначения для пользователя, и он работает стабильно без каких-либо проблем. Я проверил CSS перенаправления на устройстве с двумя режимами работы, и у него есть правильные E164, LD PT. Эта проблема была зарегистрирована после обновления cucm с 14SU4 до 15SU2. Не уверен, связано ли это с обновлением или просто никто не замечал эту проблему раньше. Каковы лучшие практики или рекомендации Cisco по SNR? Следует ли нам избегать использования двухрежимного SNR через портал самообслуживания, чтобы предотвратить сбой петли, поскольку он очень нестабилен, или есть обходной путь для решения этой проблемы? Спасибо, Нур

[nkiliddar]

TAC попросил меня установить
файл
ciscocm.V15SU2_CSCWM77174- multiline_v1.
cop
.sha512 cop для устранения проблемы MI на устройствах с двумя режимами работы.

[Roger Kallberg]

Если возможно, можете ли вы поделиться результатом настройки из веб-интерфейса администратора для конфигурации, созданной пользователем, выполнив это в веб-интерфейсе пользователя? Можете ли вы также посмотреть параметр службы Unified Mobility, чтобы проверить, как он настроен для сопоставления с номером назначения на удаленном пункте назначения или мобильным идентификатором? Это контролирует, как CM будет сопоставлять мобильный или любой другой тип номера, установленный в качестве назначения, с вариациями SNR для обратной привязки вызова к корпоративному номеру пользователя. Перенаправление CSS в отношении SNR используется только для отправки вызова
на
удаленный номер назначения, оно не является фактором при совершении вызовов
с
удаленного номера назначения. Для этого используется CSS устройства, установленный на RDP или TCT/BOT. ![Response Signature]

[nkiliddar]

CUCM создает удаленное назначение (идентификатор мобильности), связанное непосредственно с устройством TCT или BOT, когда пользователь включает SNR на устройстве с двумя режимами в пользовательском интерфейсе CCM, а не через профиль удаленного назначения. У меня параметр службы
«Соответствие идентификатора вызывающего абонента с удаленным пунктом назначения»
изначально установлен на «Частичное соответствие». Я попытался изменить его на «Полное соответствие», но результат остался прежним.
Количество цифр для «Частичного соответствия идентификатора вызывающего абонента
» установлено на 10 цифр.

[Roger Kallberg]

Я понял, что пользователи создали это из пользовательского веб-интерфейса, я просил вас зайти в административный веб-интерфейс, сделать скриншоты полученной конфигурации и поделиться ими. Я бы порекомендовал использовать полное совпадение номеров и убедиться, что номера в пунктах назначения имеют полный формат +E.164, а также нормализовать номер вызывающего абонента при входящем вызове из PSTN до полного формата +E.164. Таким образом, вы обеспечите совпадение номера при входящем вызове с номера назначения, установленного в Mobile Identity, чтобы вызов был удаленно привязан к корпоративному номеру пользователя. ![Response Signature]

[Stefan Mihajlov]

@nkiliddar Вы столкнулись с
неоднозначностью сопоставления
IMS/мобильности, когда один и тот же номер мобильного телефона настроен как
идентификатор
мобильности на устройстве с двумя режимами (TCT/BOT)
и также используется для
SNR
. После обновления до версии 15.x сопоставление номеров стало более строгим, поэтому вызов PSTN с сотового телефона не сопоставляется четко, и вы получаете
сообщение «DbMobility IMS Match: no matching ims record exists for remote destination» (Сопоставление IMS мобильности базы данных: для удаленного назначения не существует соответствующей записи IMS). Что работает надежно (и является практическим лучшим решением Cisco):
используйте только
SNR на основе RDP
. Создайте
профиль
удаленного назначения
для пользователя, добавьте
удаленное назначение
(мобильный E.164), включите там Mobile Connect и
удалите/избегайте Mobility Identity на TCT/BOT
, чтобы устранить петлю. Затем: Убедитесь, что
нормализация номера вызывающего абонента
на SIP-транке/шлюзе делает мобильный CLI
точно
совпадающим с RD (обычно
+E.164
через Calling Party Transformation/Translation Pattern).
Обеспечьте, чтобы
CSS перенаправления
на RD/RDP мог достигать DID предприятия; настройте таймеры (Answer Too Soon/Wait for DTMF) по мере необходимости. Если вам необходимо сохранить устройство с двумя режимами, не используйте тот же номер в качестве Mobility Identity — используйте
только RDP SNR
. Учитывая, что это началось после 14SU4→15SU2, если поведение сохраняется даже при чистом RDP SNR + правильной нормализации, откройте
TAC,
чтобы проверить наличие регрессии 15.x/исправления ES. –––
С уважением,
Стефан Михайлов Отметьте этот пост как полезный, если он вам помог, и примите как решение, если он решил ваш вопрос.

[nkiliddar]

Да, SNR на основе RDP работает надежно, и мы наблюдали стабильные результаты при настройке профилей удаленных пунктов назначения с использованием мобильного номера пользователя в формате E.164. Конечные пользователи привыкли включать SNR через портал самообслуживания, поскольку это видимая функция для устройств с двумя режимами работы.

[Roger Kallberg]

Если вы используете полное совпадение номера с номером назначения +E.164 и нормализуете номер вызывающего абонента при входе из PSTN, Mobile Connect с Mobile Identity работает надежно. ![Response Signature]

[Roger Kallberg]

CSS перенаправления не должен иметь доступ к номерам корпоративного каталога. Я бы даже сказал, что он
не должен
иметь видимости
каких-либо
разделов, содержащих
номера предприятия
. Ему нужно видеть только маршрутизацию для достижения удаленного пункта назначения/номера мобильного устройства. Самый простой вариант — всегда иметь эти номера в формате +E.164, тогда потребуется только один маршрутный шаблон, который соответствует
+!
и отправляет вызов на
стандартный локальный шлюз
. ![Response Signature]

[nkiliddar]

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

[Roger Kallberg]

Определенно дело для TAC. ![Response Signature]

[Maren Mahoney]

Спасибо, что поделились своим решением с теми, кто будет следовать за вами. -- Марен

[Roger Kallberg]

Интересно, это было связано с настройкой устройств TCT для многолинейной связи? ![Response Signature]

[nkiliddar]

Правильно

[Roger Kallberg]

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