Улучшения этой новой инфраструктуры.

  • Улучшена производительность при обработке вызовов, позволяющая одновременно обрабатывать до 250 параллельных сеансов на одну регистрацию локального шлюза.

  • Поддержка использования оптимизации мультимедиа Webex Calling для вызовов между стационарными телефонами, приложением Webex и локальным шлюзом.

Спецификации.

  • Выпущен новый список адресов прокси. Адрес прокси – это статическая запись DNS, полученная из Control Hub во время процесса подключения локального шлюза и затем настроенная в конфигурации клиента локального шлюза для регистрации шлюза.

  • Облачные операции Webex Calling предоставляют запросы клиентам на перенос локальных шлюзов, в которых используется более старый адрес прокси. Подробности описаны в приведенных ниже разделах.

Если какой-либо из локальных шлюзов имеет адрес исходящего прокси, не входящий в новый диапазон адресов прокси Webex Calling, указанный ниже, миграцию необходимо будет выполнить вручную для удобства вашей организации. Указанный в Control Hub адрес будет одним из новых адресов, перечисленных ниже. Однако в настоящее время в локальном шлюзе может быть настроен старый адрес и необходимо будет выполнить миграцию.

Эта миграция не должна длиться более 10–15 минут. Однако во время миграции локальный шлюз будет перерегистрирован в облаке, что повлияет на работу службы. Поэтому рекомендуется выполнять эти действия во время технического обслуживания.

США

Канада

Европа

Япония

Австралия


Новые устройства локальных шлюзов, подключенные с декабря 2020 г., будут автоматически настроены для использования этой инфраструктуры, поэтому дополнительные действия могут не потребоваться. Рекомендуется использовать приведенный выше список для проверки необходимости миграции каких-либо ваших локальных шлюзов. Для выполнения миграции воспользуйтесь приведенными ниже инструкциями.

Если вы не получили электронное сообщение от Cisco с инструкциями по модернизации конфигурации локального шлюза, дальнейшие действия не требуются. Чтобы определить, требуется ли миграция какого-либо из локальных шлюзов, см. раздел Начало работы по миграции локального шлюза.


Экраны конфигурации в Control Hub, действия по настройке CUBE и адрес исходящего прокси будут отличаться в зависимости от местоположения организации и локального шлюза. Сведения, указанные в представленных ниже действиях, можно использовать только в качестве примеров.

Прежде чем начать

  1. Обновите список контроля доступа в CUBE. Webex Calling имеет обновленный диапазон IP-адресов пограничного контроллера сеансов (SBC), который может быть применен в качестве списка доверия во всех CUBE в вашей организации, подключающихся к Webex Calling. Проверьте последний диапазон IP, указанный в руководстве "Информация о портах для Webex Calling, чтобы убедиться в том, что он уже применен. В противном случае для выполнения этого обновления см. шаг 1 действий по настройке в разделе Регистрация локального шлюза в Webex Calling. Наличие актуальных "доверенных IP-адресов" в CUBE является обязательным требованием. Если обновление не выполнено, будут возникать ошибки вызовов.

  2. Убедитесь в том, что во внешнем брандмауэре разрешен доступ к этим IP-адресам из CUBE. Если внешний брандмауэр фильтрует IP-адреса, с которыми CUBE может установить соединение, их также необходимо обновить, чтобы локальный шлюз мог установить связь с облаком. См. справочную информацию о портах для получения дополнительных сведений.

С помощью 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
  credentials number TRUNK_GROUP_24740_LGU username TRUNK_GROUP_29959_LGU password 6 K]W]ZP`PSZRKWE^WXXIPG\^_adSTbLMHV realm BroadWorks
  authentication username TRUNK_GROUP_29959_LGU password 7 xxxxxxxx realm BroadWorks
  authentication username TRUNK_GROUP_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
  outbound-proxy dns:lgwrestest.killarney.cisco.com

1

Удалите выделенную полужирным шрифтом строку, которая начинается с registrar dns:xxxx и сохраните ее для использования в дальнейшем. Также сохраните существующий адрес исходящего прокси.

Теперь регистрация локального шлюза перейдет в Webex Calling.

2

Убедитесь, что локальный шлюз не зарегистрирован в Webex Calling. Для этого введите указанные ниже команды.

voice class tenant 201
  no registrar
!
show  sip-ua register status
3

В новый адрес, скопированный из Control Hub, добавьте строку регистратора, сохраненную ранее. В приведенном ниже примере для OBP было указано значение ch13.sipconnect-us.bcld.webex.com.

voice class tenant 201
outbound-proxy dns:hs3.sse.lgw.bcld.webex.com  
registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls
!

Локальный шлюз будет зарегистрирован с новым значением OBP.

4

Проверьте выполнение регистрации с помощью указанной ниже команды.

show sip-ua register status
show sip-ua register status

Выходные данные должны выглядеть примерно так, как указано ниже.

Tenant:  201
--------------------- Registrar-Index  1 ---------------------
Line                             peer      expires(sec) reg survival  P-Associ-URI
================================ ========= ============ === ========  ============
TRUNK_GROUP_29959_LGU                 -1         7            yes normal

Дальнейшие действия

Теперь необходимо обновить другие локальные шлюзы, выполнив те же приведенные выше действия.

В случае неудачной миграции просто повторно зарегистрируйте предыдущий адрес исходящего прокси. Чтобы выполнить откат и восстановить службу, следуйте приведенным ниже инструкциям.

voice class tenant 201
  no registrar
  outbound-proxy dns:lgwrestest.killarney.cisco.com
  registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls
!
  1. При откате конфигурация в Control Hub по-прежнему будет содержать новый адрес исходящего прокси. Это ожидаемое поведение. Служба продолжит работать со старым адресом исходящего прокси.

  2. Убедитесь, что шаг 2 раздела Миграция локального шлюза в Control Hub выполнен корректно и брандмауэр не блокирует доступ к новому исходящему прокси.

  3. Если решить эту проблему не удается, обратитесь в службу поддержки Cisco Webex Calling.

Важно убедиться, что после миграции службы работают надлежащим образом. Обязательно протестируйте службу по завершении миграции. Протестировать службу можно путем совершения вызовов на номера телефонов с устройств Webex Calling. Также можно протестировать совершение вызовов на какой-либо SBC, используемый в сочетании с Webex Calling.