Покращення цієї нової інфраструктури включають:

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

  • Підтримує використання webex Calling Media Optimization для дзвінків між настільними телефонами, додатком Webex і локальним шлюзом.

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

  • Вийшов новий список адрес проксі- серверів. Адреса проксі-сервера — це статичний запис DNS, який отримується з Control Hub під час процесу адаптації локального шлюзу, а потім настроюється в конфігурації клієнта локального шлюзу для реєстрації шлюзу.

  • Хмарні операції Webex Calling просять клієнтів перенести локальні шлюзи, які використовують стару адресу проксі. Деталі викладені в наступних розділах.

Початок роботи з перенесенням локального шлюзу

Якщо будь-який із ваших локальних шлюзів має вихідну проксі-адресу, яка не входить до нового діапазону адрес проксі-сервера Webex Calling , переліченого нижче, вам потрібно буде здійснити міграцію вручну відповідно до зручності вашої організації. Адреса, вказана в Control Hub , буде однією з нових адрес нижче, однак ваш локальний шлюз може бути налаштований зі старою адресою і вимагатиме міграції.

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

США

Канада

Європа

Японія

Австралія

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

Перенесення локального шлюзу в Центр керування

Щоб зрозуміти, чи може комусь із ваших локальних шлюзів знадобитися перенесення, зверніться до розділу Початок роботи з перенесенням локального шлюзу .

Екрани конфігурації в Центрікерування, етапи конфігурації CUBE та адреса вихідного проксі-сервера відрізнятимуться залежно від розташування організації та локального шлюзу. Докладні відомості, перелічені в наведених нижче кроках, є лише прикладами.

Перш ніж почати

  1. Оновіть список контролю доступу в cube —Webex Calling має оновлений діапазон IP-адрес контролера меж сеансу (SBC), який, можливо, доведеться застосувати як надійний список до всіх КУБів вашої організації, підключених до Webex Calling. Перевірте найновіший діапазон IP-адрес за допомогою довідкового посібника з порту виклику Webex, щоб підтвердити, чи він уже застосований, і, якщо ні, зверніться до кроків конфігурації, наведених на кроці 1 від Реєстрації локального шлюзу до Webex Calling, щоб виконати це оновлення. Наявність оновлених «довірених IP-адрес» на вашому КУБІ є обов'язковою вимогою, яка, якщо її не оновити, призведе до збоїв у виклику.

  2. Переконайтеся, що зовнішній брандмауер дозволяє отримувати ці IP-адреси з вашого куба — якщо зовнішній брандмауер фільтрує IP-адреси, до яких може отримати куб, ви також повинні оновити його, щоб локальний шлюз міг зв'язатися з хмарою. Для отримання додаткової інформації зверніться до Довідково-інформаційного довідника порту.

  3. Переконайтеся, що прив'язка довіри до CUBE оновлено, виконавши крок 5 від Функції "Виконати конфігурацію довідкової платформи".

За допомогою Центрукерування можна отримати нову вихідну проксі-адресу.

1.

У поданні клієнта перейдіть https://admin.webex.comдо розділу Службита виберіть пункт Виклик > Маршрутизація викликів.

2.

Виберіть підключення до ТМЗК, а потім натисніть кнопку Редагувати в розділі Локальний шлюз.
3.

Клацніть Керування , щоб отримати доступ до конфігурації локального шлюзу.
4.

Скопіюйте вихідну адресу проксі-сервера.


 

Якщо у вашій організації багато локальних шлюзів, імовірно, що кожного разу, коли ви виконуєте вищенаведене завдання для іншого локального шлюзу, ви отримуватимете різні адреси вихідних проксі-серверів із Центру керування. Переконайтеся, що ви скопіювали конкретну вихідну адресу проксі-сервера з Центру керування для кожного настроєного локального шлюзу. Вибір конкретної адреси важливий для надмірності та балансування трафіку.

Оновлення конфігурації локального шлюзу

Оновлення конфігурації локального шлюзу впливає на службу та може вплинути на активні виклики.

У наведеному нижче прикладі клієнт 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, ввівши наведені нижче команди.

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
!

  1. Якщо відкотити назад, конфігурація в Центрі керування все одно відображатиме нову вихідну адресу проксі-сервера. Це очікувана поведінка. Сервіс продовжить працювати зі старою вихідною проксі-адресою.

  2. Переконайтеся, що ви правильно виконали крок 2 у розділі Перенесення локального шлюзу в Центрі керування, і немає брандмауера, який блокує доступ до нового вихідного проксі-сервера.

  3. Якщо ви не можете вирішити цю проблему, зверніться до служби підтримкиCisco Webex.

Перевірка після міграції

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