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

[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]