Миграция локального шлюза
Платформа Webex Calling включает модернизированную облачную инфраструктуру, к которой подключаются локальные шлюзы, размещенные на базе локальных ресурсов. Эта модернизация улучшает работу службы и реализует несколько новых функций для локального шлюза.
Улучшения этой новой инфраструктуры.
-
Улучшена производительность при обработке вызовов, позволяющая одновременно обрабатывать до 250 параллельных сеансов на одну регистрацию локального шлюза.
-
Поддерживает использование оптимизации мультимедиа Webex Calling для вызовов между стационарными телефонами, приложением Webex и локальным шлюзом.
Спецификации.
-
Выпущен новый список адресов прокси. Адрес прокси – это статическая запись DNS, полученная из Control Hub во время процесса подключения локального шлюза и затем настроенная в конфигурации клиента локального шлюза для регистрации шлюза.
-
Облачные операции Webex Calling предоставляют запросы клиентам на перенос локальных шлюзов, в которых используется более старый адрес прокси. Подробности описаны в приведенных ниже разделах.
Если какой-либо из локальных шлюзов имеет адрес исходящего прокси, который не входит в новый диапазон адресов прокси Webex Calling, выполните миграцию вручную в соответствии с удобствами вашей организации. Адрес, указанный в Control Hub, является одним из новых адресов ниже. Однако в настоящее время локальный шлюз может быть настроен со старым адресом и требует миграции.
Эта миграция не должна занимать более 10-15 минут. Однако во время миграции локальный шлюз повторно регистрируется в облаке, что влияет на работу службы. Поэтому рекомендуется выполнять эти действия во время технического обслуживания.
US
Канада
Европа
Япония
Австралия
Сингапур
Новые устройства локальных шлюзов, подключенные с декабря 2020 г., будут автоматически настроены для использования этой инфраструктуры, поэтому дополнительные действия могут не потребоваться. Рекомендуется использовать приведенный выше список для проверки необходимости миграции каких-либо ваших локальных шлюзов. Для выполнения миграции воспользуйтесь приведенными ниже инструкциями.
Чтобы определить, необходима ли миграция какого-либо из локальных шлюзов, см. раздел Начало работы по миграции локального шлюза.
Экраны конфигурации в Control Hub, действия по настройке CUBE и адрес исходящего прокси будут отличаться в зависимости от местоположения организации и локального шлюза. Сведения, указанные в представленных ниже действиях, можно использовать только в качестве примеров.
Прежде чем начать
-
Обновите список контроля доступа в CUBE. Webex Calling имеет обновленный диапазон IP-адресов пограничного контроллера сеансов (SBC), который может быть применен в качестве списка доверия во всех CUBE в вашей организации, подключающихся к Webex Calling. Проверьте последний диапазон IP, указанный в руководстве "Информация о портах для Webex Calling, чтобы убедиться в том, что он уже применен. В противном случае для выполнения этого обновления см. шаг 1 действий по настройке в разделе Регистрация локального шлюза в Webex Calling. Наличие актуальных "доверенных IP-адресов" в CUBE является обязательным требованием. Если обновление не выполнено, будут возникать ошибки вызовов.
-
Убедитесь в том, что во внешнем брандмауэре разрешен доступ к этим IP-адресам из CUBE. Если внешний брандмауэр фильтрует IP-адреса, с которыми CUBE может установить соединение, их также необходимо обновить, чтобы локальный шлюз мог установить связь с облаком. См. справочную информацию о портах для получения дополнительных сведений.
-
Убедитесь в том, что точка доверия в CUBE обновлена в соответствии с шагом 5 раздела Настройка базовой конфигурации платформы.
С помощью Control Hub можно получить новый адрес исходящего прокси.
1 |
В окне просмотра информации о клиенте на веб-сайте https://admin.webex.com перейдите к меню Службы и выберите . |
2 |
Выберите свое соединение PSTN, затем в области Локальный шлюз щелкните Правка. |
3 |
Щелкните Управление, чтобы получить доступ к конфигурации локального шлюза. |
4 |
Скопируйте адрес исходящего прокси. Если в вашей организации много локальных шлюзов, возможно, что каждый раз при выполнении вышеуказанных задач для отдельного локального шлюза в Control Hub будут получены разные адреса исходящего прокси. Убедитесь, что из Control Hub скопирован конкретный адрес исходящего прокси для каждого настраиваемого локального шлюза. Выбор определенного адреса важен для обеспечения избыточности и балансировки нагрузки трафика. |
Обновление конфигурации локального шлюза влияет на работу службы и может повлиять на активные вызовы.
В приведенном ниже примере клиент 201 является клиентом, который подключается к Webex Calling. Укажите правильный клиент для своей конфигурации.
#show running-config | s voice class tenant 201 voice class tenant 201 registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls магистраль номера учетных данных_ГРУППА_24740_МАГИСТРАЛЬ имени пользователя LGU_ГРУППА_29959_Пароль LGU 6 K]W]ZP`PSZRKWE^WXXIPG\^_adМАГИСТРАЛЬ имени пользователя аутентификации BroadWorks в области STbLMHV_ГРУППА_29959_Пароль LGU 7 XXXXXXXX область аутентификации BroadWorks TRUNK_ГРУППА_29959_LGU password 6 xxxxxxxx realm lgw2.killarney.cisco.com sip-server dns:lgw2.killarney.cisco.com connection-reuse session transport tcp tls url sips error-passthru bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 201 исходящий прокси-сервер dns:lgwrestest.killarney.cisco.com
1 |
Удалите жирную строку, начинающуюся с Теперь регистрация локального шлюза перейдет в Webex Calling. |
2 |
Убедитесь, что локальный шлюз не зарегистрирован в Webex Calling. Для этого введите указанные ниже команды. |
3 |
В новый адрес, скопированный из Control Hub, добавьте строку регистратора, сохраненную ранее. В приведенном ниже примере наш OBP был Локальный шлюз будет зарегистрирован с новым значением OBP. |
4 |
Проверьте выполнение регистрации с помощью указанной ниже команды. Выходные данные должны выглядеть примерно так, как указано ниже. |
Дальнейшие действия
Чтобы обновить другие локальные шлюзы, выполните те же приведенные выше действия.
В случае неудачной миграции просто повторно зарегистрируйте предыдущий адрес исходящего прокси. Чтобы выполнить откат и восстановить службу, следуйте приведенным ниже инструкциям.
voice class tenant 201 no registrar outproxy dns:lgwrestest.killarney.cisco.com registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls !
-
При откате конфигурация в Control Hub по-прежнему будет содержать новый адрес исходящего прокси. Это ожидаемое поведение. Служба продолжит работать со старым адресом исходящего прокси.
-
Убедитесь, что шаг 2 раздела Миграция локального шлюза в Control Hub выполнен корректно и брандмауэр не блокирует доступ к новому исходящему прокси.
-
Если решить эту проблему не удается, обратитесь в службу поддержки Cisco Webex Calling.
Важно убедиться, что после миграции службы работают надлежащим образом. Обязательно протестируйте службу по завершении миграции. Протестировать службу можно путем совершения вызовов на номера телефонов с устройств Webex Calling. Также можно протестировать совершение вызовов на какой-либо SBC, используемый в сочетании с Webex Calling.