Мигриране на местния шлюз

Подобренията на тази нова инфраструктура включват:

Подобрена производителност при работа с обаждания, позволяваща до 250 едновременни сесии на местна регистрация на шлюз.
Поддържа използването на Webex Calling Media Optimization за разговори между настолни телефони, приложението Webex и локален шлюз.

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

Издаден е нов списък с прокси адреси. Прокси адрес е статичен DNS запис, който се получава от Control Hub по време на процеса на качване на локален шлюз и след това конфигуриран на конфигурацията на наемателя на локален шлюз за регистриране на шлюза.
Webex Calling облак операции е искане на клиентите да мигрират местните шлюзове, които използват по-стар прокси адрес. Подробностите са очертани в следващите раздели.

Първи стъпки с местната миграция на шлюз

Ако някой от местните ви шлюзове има изходящ прокси адрес, който не е част от новия прокси адресен диапазон webex Calling, посочен по-долу, ще трябва да мигрирате ръчно на удобство на вашата организация. Адресът, посочен в контролния център, ще бъде един от новите адреси по-долу; обаче вашият локален шлюз в момента може да бъде конфигуриран със стар адрес и ще изисква миграция.

Тази миграция не трябва да отнеме повече от 10-15 минути. Въпреки това, по време на миграцията, местният шлюз ще се регистрира повторно в облака, който ще окаже влияние върху услугата. Затова ви препоръчваме да извършвате тази дейност по време на прозорец за поддръжка.

САЩ

Канада

Европа

Япония

Австралия

Новите устройства Local Gateway, които се качват на борда от декември 2020 г., автоматично се настройват, за да използват тази инфраструктура, поради което не може да е необходимо действие. Препоръчваме ви да се обърнете към горния списък, за да проверите дали някой от местните ви шлюзове се нуждае от миграция и ако е така, извършете миграция, на насоки по-долу.

Мигриране на местния шлюз в контролния център

За да разберете дали някой от местните ви шлюзове може да се нуждае от миграция, вижте раздела Първи стъпки с вашия локален раздел за миграция на шлюз.

Конфигурационните екрани в Контролния център, стъпките cube config и изходящ прокси адрес ще варират в зависимост от местоположението и локалния шлюз на вашата организация. Подробностите, изброени в стъпките, показани по-долу, са само примери.

Преди да започнете

Актуализирайте списъка за контрол на достъпа на КУБ –Webex Calling има актуализиран диапазон от ip адреси на сесиен граничен контролер (SBC), които може да се наложи да се прилагат като надежден списък на всички Кубове във вашата организация, свързващи се с Webex Calling. Проверете най-новия IP диапазон от Справочния справочник на Webex Calling Port, за да потвърдите дали вече е приложен и, ако не, вижте стъпките за конфигуриране под стъпка 1 от Регистриране на локален шлюз към Webex Calling, за да извършите тази актуализация. Наличието на актуални "надеждни IP адреси" на вашия CUBE е задължително изискване, което, ако не бъде актуализирано, ще доведе до откази при обаждания.
Осигурете вашата външна защитна стена позволява тези IP адреси да бъдат достигнати от вашия КУБ –Ако външната ви защитна стена филтрира IP адресите, до които кубът може да достигне, трябва да актуализирате това също така, така че Локалният шлюз да може да се свърже с облака. Вижте справочния информационен справочник на порт за повече информация.
Осигурете, че котвата за доверие на CUBE е актуализирана, като следвате стъпка 5 от Perform Reference Platform Configuration.

От Контролния центърможете да получите новия си изходящ прокси адрес.

От изгледа на клиента в https://admin.webex.com, отидете на Услуги , иизберете Извикване > Маршрутизиране на обаждания.

Изберете вашата PSTN връзка, след което кликнете върху Редактиране под Локален шлюз.

Щракнете върху Управление за достъп до локалната конфигурация на шлюза.

Копирайте изходящите прокси адрес.

Ако имате много местни шлюзове във вашата организация, вероятно всеки път, когато изпълнявате горната задача за различен локален шлюз, ще получите различни изходящи прокси адреси от 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	Вземете новия адрес, който сте копирали от контролния център , и добавете реда нарегистратора отгоре назад. В примера по-долу нашата ОБП беше `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
!

Ако се върнете назад, вашата конфигурация в контролния център все още показва новия изходящ прокси адрес. Това се очаква поведение. Услугата ще продължи да работи със стария изходящ прокси адрес.
Гарантирайте, че сте следвали стъпка 2 правилно в Мигриране на вашия локален шлюз в Control Hub раздел и няма достъп за блокиране на защитната стена до новия изходящ прокси.
Ако не можете да разрешите този проблем, свържете се с поддръжката на обаждания на Cisco Webex.

Валидиране след миграцията

Важно е да се гарантира, че услугите работят като нормална следмиграция. Уверете се, че сте тествали услугата си, след като завършите миграцията. Можете да тествате услугата си, като провеждате обаждания до телефонни номера от вашите устройства Webex Calling, или тествате обаждания към всеки SBC, който се използва съвместно с Webex Calling.