Unity Call Flow в CUCM с переадресацией на альтернативный номер контакта

[Bob_IA]

Я унаследовал кластер Unity Connection с двумя узлами и кластер CUCM с двумя узлами, между которыми установлены соединения SCCP. Я пытаюсь понять, как серверы Unity определяют, как передавать вызовы «Передача на альтернативный номер контакта» в кластер CUCM. Я вижу, что вызов поступает в PSTN SIP-транк на моем абоненте CUCM, а затем в Unity, но когда они нажимают номер для перевода на внешний номер 1-888, он хочет использовать CUCM Publisher, что в нашей текущей конфигурации телекоммуникационной связи означает, что у вызывающих абонентов возникают проблемы с распознаванием исходящего аудио/DTMF и они не могут выбрать опции в обработчике вызовов внешнего объекта. Если я смогу зарегистрировать его в абоненте CUCM, то поток вызовов должен быть «правильным» и позволять двустороннюю передачу данных. В конечном итоге мы установим SBC, чтобы устранить это ограничение, но на данный момент это версия, которая «работает». Я попробовал изменить приоритет портов Unity для CUCM и порядок серверов в группе портов, но безрезультатно. Если у кого-нибудь есть какие-то идеи, буду признателен. Пока что найти информацию оказалось довольно сложно, поэтому даже справочный документ был бы полезен. Спасибо, Боб

[Brad Magnani]

Привет,
@Bob_IA
Unity проверит телефонную систему, настроенную на объекте, выполняющем перенос, и использует связанную группу портов для осуществления исходящего вызова. Убедитесь, что список серверов в группе портов SCCP (например, sub1, sub2) точно соответствует порядку серверов в группе CM, назначенной портам вашей виртуальной машины (через назначенный пул устройств). Если вы вносите изменения в CUC или CUCM в этой области, неплохо было бы перезапустить группу портов, а если вы по-прежнему видите, что переносы идут на неправильный узел CUCM, вы можете перезапустить Conversation Manager. Обычно это не требуется, но мне было бы интересно узнать, как вы убедились, что переносы из CUC идут на издателя, несмотря на то, что издатель был удален из группы портов на CUC.

[Maren Mahoney]

Во-первых, в группе портов для ваших портов SCCP в разделе «Серверы» указаны только узлы обработки вызовов (а не издатель)? Если издатель указан и находится первым, то исходящие соединения будут использовать его. В группе портов должны быть указаны только узлы обработки вызовов. Кроме того, рекомендуется перечислить узлы обработки вызовов из группы CallManager, связанной с пулом устройств портов, указанных как 1-2-3 на серверах группы портов в CUC, и дождаться повторной регистрации портов. И я согласен с
@Brad Magnani,
что после внесения изменений в серверы группы портов необходимо перезапустить Conversation Manager. Если вы изменили приоритет, вы также сбросили оба порта SCCP в CUCM и сбросили группу портов в CUC? Если все в порядке, то нам нужно копнуть глубже. Марен

[Stefan Mihajlov]

@Bob_IA Unity Connection не «выбирает» издателя или подписчика так, как это делают транки CUCM — он использует свои группы портов SCCP. Каждая группа портов имеет список серверов CUCM, и Unity регистрирует каждый порт SCCP на
первом доступном сервере в списке
. Когда Unity необходимо перевести вызов, он захватывает зарегистрированный порт, поэтому, если эти порты заняты на Pub, все переводы будут проходить через него.
Чтобы исправить это поведение в краткосрочной перспективе, убедитесь, что в
Cisco Unity Connection Administration → Telephony Integrations → Port Group
абонент указан
первым
в списке серверов, а затем сбросьте настройки группы портов, чтобы все порты Unity регистрировались на этом абоненте. Таким образом, новые попытки перевода будут исходить оттуда, а не от Pub. Если вам нужна избыточность, оставьте оба узла в списке, но поместите тот, у которого работает SIP-путь, в верхнюю часть списка.
В долгосрочной перспективе ваш план правильный — как только SBC будет установлен, вам будет все равно, какой узел CUCM инициирует вызов. Однако на данный момент упорядочивание серверов CUCM в группе портов Unity — это единственный рычаг, который у вас есть.
С уважением,
Стефан Михайлов
Отметьте этот пост как полезный, если он вам помог, и примите как решение, если он решил ваш вопрос.

[Bob_IA]

Хорошо, я подтвержу порядок в списке с обеих сторон, так как не учел этого. Я не удалял Publisher из списка Unity, а просто поменял их приоритеты (сделав Publisher 1, а Subscriber 0). Скажу, что я внес изменения только со стороны Unity, а затем перезапустил только Conversation Manager. Я могу внести изменения и перезапустить обе сущности/службы утром, до того как мы начнем активно работать. Я просматривал трафик с помощью RTMT в Trace и мониторе calllogs Log Central; просто направил его на издателя или подписчика и запустил те же действия вызова и нажатия клавиш. Я очень благодарен за ваши комментарии!

[Bob_IA]

В нашей 2-узловой CUCM как издатель, так и подписчик указаны в группе портов Unity; издатель имеет приоритет 0, а подписчик — 1. Я поменял их приоритеты, но не заметил никаких изменений, поэтому вернул их в исходное состояние. Я снова поменяю их местами, перезапущу Conversation Manager и сброшу настройки группы портов. Я подозреваю, что издатель находится там для обеспечения отказоустойчивости. Эта настройка осталась от тех времен, когда нашей системой управляла сторонняя компания более 6 лет назад, так что это всего лишь мое предположение. Большое спасибо!

[Maren Mahoney]

Если и Pub, и Sub являются узлами обработки вызовов, то они могут (и должны) находиться в списке серверов. Тот, который указан первым в CM Group в DP, должен быть сервером 0, а другой — сервером 1. Если исходящие вызовы работают при обработке через Sub, но не через Pub, ответ может быть в CUCM, а не в CUC. CUC на самом деле не заботится об этом со своей стороны, и я предполагаю, что все ваши порты SCCP настроены одинаково. На вашем маршрутизаторе-шлюзе-кубе (какой у вас?) вы используете один набор dial-peers с серверной группой, в которой указаны оба узла CUCM, или у вас есть два отдельных набора dial-peers, в которых Pub и Sub указаны отдельно? Если они отделены, то настроены ли они одинаково для таких вещей, как DTMF-реле? А как насчет магистрали на стороне CUCM к шлюзу? У вас есть более одного шлюза и, следовательно, более одной магистрали, и если да, то они настроены одинаково? Имеют ли Pub и Sub доступ к одним и тем же медиаресурсам (через структуру MRG/MRGL), или ваши медиаресурсы широко открыты? Если они широко открыты, имеете ли вы одинаковые медиаресурсы, доступные на обоих? (Я размышляю, есть ли проблема с ретрансляцией DTMF, при которой Pub может пытаться использовать MTP, а Sub в этом не нуждается). В конце концов, если мы не сможем найти причину, нам понадобятся файлы трассировки для работающего и неработающего вызова, чтобы мы могли определить, в чем заключается проблема. Файлы трассировки укажут нам на проблему. Марен

[Bob_IA]

Спасибо всем, я смог сделать Subscriber первым выбором для Unity, и теперь вызов поступает на него в первую очередь. Похоже, у меня также есть проблема с DTMF, потому что теперь единственный внешний пункт назначения, который имеет систему распознавания голоса, работает, хотя раньше не работал, но нажатия цифр не доходят до него. Я предполагаю, что это проблема In/Out of Band, но в отношении вопроса, который у меня был, вы все были великолепны!