Посібник з розгортання міграції

У цій статті

Надіслати відгук?

Структурований процес міграції з локальної системи Cisco Unified CM до хмарної Webex Calling з використанням методології PPDIO. Це включає критичні міркування щодо проектування такі як вибір регіону, плани набору, екстрені служби та запис дзвінків. Процес також детально описує ліцензування, налаштування користувачів, єдиний вхід (SSO) та готовність мережі для забезпечення безперебійної та ефективний перехід.

Вступ

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

Цей посібник призначений для команд або окремих осіб, які мають досвід налаштування та адміністрування Cisco Unified Communications Manager (Unified CM) та кінцевих точок Cisco, включаючи стаціонарні IP-телефони, відеопристрої та програмні клієнти Jabber. У цьому документі є посилання на документацію щодо продукту та підтримки, які допоможуть вам.

Цей документ зосереджений на переходах від Unified CM до Webex Calling лише для кількох клієнтських систем. Термін Webex Calling у цьому документі завжди стосується багатокористувацького Webex Calling.

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

Глибоке розуміння наступних компонентів Webex Calling є важливим для розробки ефективної стратегії переходу та готовності до роботи.

Control Hub
Налаштування каталогів та користувачів
Платформа Webex Calling
Підтримувані кінцеві точки виклику
Варіанти підключення до PSTN
Керування планом нумерації та номерами Webex Calling
Функції безпеки та відповідності.

Для отримання додаткової інформації див. Бажана архітектура Cisco для викликів Webex.

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

Інструменти міграції Webex: самообслуговування, безкоштовні інструменти, вбудовані в Control Hub, для спрощення переходу на Webex Calling
Сертифіковані постачальники послуг міграції: Постачальники програмного забезпечення та інструментів, перевірені Cisco, які розробили рішення для міграції, щоб допомогти партнерам і клієнтам Webex зі складними та великими міграціями. Ці рішення можуть допомогти спростити, керувати та пришвидшити перехід на Webex Calling.
Допомога з налаштуванням Webex: послуга міграції від Cisco, яка допомагає клієнтам і партнерам розгортати та налаштовувати Webex Calling, що необхідно для успішної міграції користувачів і служб Unified CM до Webex Calling.

Огляд

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

Мета цього документа — надати рекомендації щодо розгортання для клієнтів, які бажають перейти з локальної версії Unified CM на хмарну версію Webex Calling. Цей посібник з розгортання передбачає, що читач має базове розуміння переходу між Unified CM та Webex Calling, зокрема змін під час цього переходу та відмінностей під час переміщення робочого навантаження викликів з локальної системи до хмари. Перш ніж продовжити, переконайтеся, що ви переглянули та ознайомилися з інформацією, доступною на карті переходу. Цей документ з картою переходу містить інформацію про зміни та відмінності цього переходу.

Як показано на рисунку Архітектура локальної співпраці: керування викликами та віддалений доступ, типове локальне розгортання включає різні компоненти інфраструктури для співпраці в мережі, платформу керування викликами, граничну платформу, апаратні та програмні кінцеві точки, а в деяких випадках навіть платформи для конференцій та планування. В архітектурі Cisco це включатиме Unified CM для керування викликами, Expressway для віддаленого доступу та граничних послуг для бізнесу (B2B), Cisco Meeting Server. / Cisco Meeting Management для локальних конференцій, Unity Connection для голосового обміну повідомленнями та кінцеві точки на базі IP, орієнтовані на користувача, апаратні (IP-телефони Cisco, відеосистеми Cisco Desk and Room) та програмні (Cisco Jabber). Ці компоненти можуть дещо відрізнятися в деяких середовищах, але це відправна точка для переходу, описаного в решті цього документа.

Архітектура локальної співпраці: Керування дзвінками та віддалений доступ — ***Архітектура локальної співпраці: керування дзвінками та віддалений доступ***

Архітектура, показана на рисунку Архітектура локальної співпраці: керування викликами та віддалений доступ базується на переважній архітектурі (PA) для локальних розгортань Cisco Collaboration Enterprise. Щоб отримати додаткові відомості про локальну платформу Enterprise, див. Рекомендовані архітектури співпраці Cisco.

До: У таблиці «Компоненти локальної інфраструктури викликів » перелічені ключові елементи локальної архітектури до переходу на Webex Calling у хмарі.

Таблиця 1. До: Компоненти локальної інфраструктури викликів
Продукт	Опис
Unified CM	Локальне керування викликами, що забезпечує послуги реєстрації пристроїв та маршрутизації викликів
Cisco Expressway-C/E	Периферійна інфраструктура, що забезпечує мобільний та віддалений доступ (MRA) та функціональність «бізнес для бізнесу» (B2B), що дозволяє віддаленим кінцевим точкам безпечно підключатися ззовні організації. Expressway розгортається парами для забезпечення проходження брандмауера для зовнішніх кінцевих точок.
Сервер Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) та Cisco Telepresence Management Suite (TMS)	Локальна інфраструктура голосових, відео- та веб-конференцій, що забезпечує можливості багатоточкових зустрічей, управління зустрічами та планування. [Optional]
Cisco Unity Connection	Локальна платформа голосових повідомлень, що забезпечує можливості голосової пошти та уніфікованого обміну повідомленнями. [Optional]
Cisco Desk, Cisco Room, Cisco Board, IP-телефони Cisco та Cisco Jabber	IP-пристрої, зареєстровані в Unified CM та надають можливості голосових та відеодзвінків

Як показано на рисунку , рішення про перехід: локальні виклики до Webex Calling, клієнти, які мають локальне керування викликами за допомогою Unified CM, а також кінцеві точки на робочому місці та відео з IP-відео, можуть вибрати перехід архітектури до хмарної архітектури Webex Calling.

Рішення потрібно приймати, виходячи з функціональних вимог замовника. Клієнти, які мають такі вимоги, повинні ретельно обміркувати це рішення, перш ніж приймати його, і зрештою можуть вирішити залишити керування викликами локально:

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

Рішення про перехід: Локальні виклики до Webex Calling — ***Рішення про перехід: локальні дзвінки до Webex Calling***

Клієнтам, які бажають почати використовувати хмарні сервіси дзвінків, варто розглянути Webex Calling. Цей хмарний сервіс викликів дозволяє клієнту використовувати глобальну архітектуру Webex для масштабування та підключення. Учасники корпоративної мережі та віддалені учасники поза межами корпоративної мережі можуть спілкуватися за допомогою апаратних кінцевих точок на базі IP and/or настільні або мобільні клієнтські додатки.

Цей документ орієнтований на клієнтів із розгортаннями керування викликами Unified CM, які хочуть зрозуміти загальні кроки, міркування та вимоги для ввімкнення розгортання Webex Calling, як описано в наступному розділі.

Основні компоненти

Цільова архітектура для цієї міграції включає кілька нових компонентів. Це включає службу Webex Calling для хмарних дзвінків, додаток Webex, Cisco Directory Connector для інтеграції ідентифікації та локальний шлюз (LGW) для доступу до PSTN, а також інтеграцію локальних дзвінків у хмару. Додатковими варіантами доступу до PSTN є тарифні плани Cisco або підключена до хмарної PSTN (CCP), що забезпечується партнером Cloud Connect для Webex Calling.

Як показано на рисунку після: Архітектура викликів Webex, нові компоненти (Виклики Webex, З’єднувач каталогу, Локальний шлюз і Шлюз живучості) додаються до існуючого локального розгортання.

Після: У таблиці «Компоненти інфраструктури хмарних викликів » перелічено нові елементи архітектури після переходу на Webex.

Таблиця 2. Після: Компоненти інфраструктури хмарних викликів
Продукт	Опис
Webex Calling	Хмарний сервіс викликів, що надається з платформи Webex та забезпечує реєстрацію кінцевих точок і маршрутизацію викликів
З’єднувач каталогів Cisco	Програма Windows, що працює на комп’ютері домену Windows, що забезпечує синхронізацію ідентифікаційних даних між локальною службою Active Directory підприємства та сховищем ідентифікаційних даних організації Webex. Для клієнтів, які переходять з локальної служби Active Directory на Entra ID, інтеграція ідентифікаційних даних з Webex замість Cisco Directory Connector використовує програму Entra ID Wizard.
Локальний шлюз	Локальний шлюз діє як міст між локальною мережею уніфікованих комунікацій клієнта та хмарою Webex Calling. Його можна розгорнути локально або розмістити у партнера, забезпечуючи доступ до PSTN для кінцевих точок, зареєстрованих у хмарі, а також інтеграцію викликів між кінцевими точками, зареєстрованими в Unified CM, та кінцевими точками, зареєстрованими в хмарі. Інтегрований сервісний маршрутизатор Cisco IOS-XE (серії ISR 1100 та 4000), Cisco Catalyst 8200/8300 Серія, програмне забезпечення Cisco Catalyst 8000V Edge та різні сертифіковані сторонні контролери меж сеансів (SBC) можуть використовуватися як LGW для поетапної міграції.
Шлюз Survivability	Шлюз аварійної безпеки (SGW) – це локальний мережевий шлюз на базі IOS-XE, який надає резервні послуги виклику для локальних кінцевих точок Webex Calling під час збоїв у мережі.
Тарифний план Cisco Calling, Cloud Connect для Webex Calling	Cisco Calling Plan та Cloud Connect для Webex Calling – це хмарні варіанти доступу до PSTN для кінцевих точок Webex Calling. Доступ до PSTN забезпечується хмарним постачальником PSTN і не потребує локального обладнання.
Програма Webex	Клієнтський застосунок, що працює на ОС для настільних комп'ютерів (Windows, Mac) або мобільних ОС (Android, iOS) та зареєстрований безпосередньо на платформі Webex Calling для здійснення дзвінків.

Огляд процесу PPDIO

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

Загальний опис PPDIO

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

Використання PPDIO для проектів міграції з Unified CM до Webex Calling

Під час переходу з Unified CM на Webex Calling процес PPDIO забезпечує чітку дорожню карту для забезпечення плавного та ефективного переходу:

Підготовка

Оцінка існуючого середовища Unified CM та готовності до міграції
Збирати детальні дані про користувачів, пристрої, мережу та залежності
Збирати інформацію про місцезнаходження, включаючи адресу екстреного реагування, кількість користувачів, доступ до Інтернету, доступ до PSTN
Визначте ризики та визначте обсяг проекту для узгодження дій усіх зацікавлених сторін.

Планування

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

Проєктування

Зіставлення поточних конфігурацій, груп дзвінків та профілів користувачів Unified CM з еквівалентами Webex Calling
Розробка середовища Webex Calling, включаючи стратегію PSTN (проміжну та остаточну), розташування, ролі користувачів та точки інтеграції, такі як локальний шлюз (CUBE) та синхронізація каталогів
Плануйте сценарії співіснування, де Unified CM та Webex Calling працюють одночасно під час міграції.

Впровадження

Використовуйте інструменти міграції Control Hub разом із інструментами сторонніх розробників для зміни режиму прошивки пристрою, налаштування функцій та міграції користувачів.
Використовуйте масові операції та налаштування за допомогою Webex API для оптимізації масштабних міграцій та конфігурацій
Виконувати надання ліцензій, реєстрацію пристроїв та оновлення конфігурації
Підтвердьте успішність міграції за допомогою тестування та операційної перевірки.

Оптимізація

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

Цей удосконалений підхід PPDIO забезпечує контрольовану, прозору та ефективну міграцію з Unified CM до Webex Calling, використовуючи інструменти, API та партнерську екосистему Cisco для підтримки безперервності бізнесу та покращення можливостей співпраці.

петлі зворотного зв'язку PPDIO

Загальний огляд, зображений на рисунку Ітерації під час виконання PPDIO, ілюструє єдиний цикл зворотного зв'язку від фази оптимізації назад до фази підготовки. Це означає, що після початкового впровадження існує постійна можливість для постійного вдосконалення. Кожен цикл оптимізації може виявити нові вимоги або області для вдосконалення, які можуть бути враховані за допомогою наступних проектів або ініціатив. Ці окремі проекти, у свою чергу, дотримуються встановленого життєвого циклу PPPIO (Підготовка, Планування, Проектування, Впровадження, Оптимізація). Такий ітеративний підхід гарантує, що система залишається узгодженою з бізнес-цілями, що розвиваються, та технологічним прогресом, сприяючи культурі постійного вдосконалення та адаптивності.

Під час виконання процесу PPDIO висновки на пізніших етапах часто вимагають повторного розгляду та потенційного перегляду рішень, прийнятих на попередніх етапах. Наприклад, проблеми, що виникли на етапі впровадження, такі як виявлення неоднозначностей у проектуванні або відсутні деталі, можуть свідчити про те, що певні аспекти не були повністю враховані на етапі проектування. У таких випадках стає необхідним повернутися до відповідного попереднього етапу, щоб вирішити ці проблеми, перш ніж продовжувати. Цей ітеративний механізм зворотного зв'язку, як показано на рисунку , уніфікований процес PPDIO за допомогою CM гарантує, що рішення ретельно перевірено та вдосконалено, що зрештою сприяє більш надійному та ефективному розгортанню.

***Уніфікований процес PPDIO з підтримкою CM***

Під час переходу від Unified CM до Webex Calling кожен етап процесу PPDIO може отримати значну користь від інформації, зібраної з існуючого середовища Unified CM. Наприклад, з поточної конфігурації Unified CM можна отримати повні переліки користувачів, номерів телефонів, функцій викликів та компонентів плану набору. Ці дані доповнюють інформацію, надану безпосередньо зацікавленими сторонами, та допомагають оптимізувати діяльність з планування та проектування. Використання відповідних інструментів для автоматизації вилучення та аналізу даних не лише підвищує точність, але й пришвидшує загальний процес. Використовуючи аналітичні дані з існуючого розгортання, перехід на Webex Calling може бути виконаний ефективніше, ніж традиційне впровадження з нуля, дотримуючись при цьому структурованої методології PPDIO. Цей процес проілюстровано на рисунку Уніфікований процес PPDIO за допомогою CM.

Підхід до міграції

Плануючи перехід від локальної Unified CM до Webex Calling, вам потрібно визначити, як ви підійдете до цього процесу. Спочатку вам потрібно буде вирішити, чи буде міграція швидкою (все одразу) чи поетапною (міграція груп users/devices протягом тривалого періоду).

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

Другий підхід — це поетапна міграція. Більшість організацій використовуватимуть цей підхід, оскільки він забезпечує кращий контроль, управління та масштабування під час міграції. Також він краще підходить для більших розгортань уніфікованих комунікацій. and/or розгортання в кількох регіонах. Таким чином, цей документ зосереджений на поетапному підході з двома кроками переходу.

Як показано на рисунку нижче, поетапний перехід виклику: Гібридний та хмарний, перший перехідний етап (Фаза 1) призводить до співіснування розгортання з подвійними середовищами викликів. На цьому етапі деякі користувачі, пристрої та програмні клієнти переходять на Webex Calling, тоді як інші все ще використовують локальне керування викликами Unified CM. Останній перехідний етап (Фаза 2) призводить до створення чистого хмарного середовища для викликів, де всі користувачі, пристрої та програмні клієнти повністю переведені на платформу Webex Calling.

Скільки часу знадобиться організації для повного переходу на хмарні виклики, залежатиме від її поточного розгортання. У деяких випадках організація може здійснити початковий перехід і залишатися у фазі співіснування подвійного керування викликами (Фаза 1) протягом тривалого періоду (місяців або навіть років), тоді як в інших випадках організація може повністю перейти на Webex Calling (Фаза 2) за дуже короткий період (тижні або місяці). Цей документ має на меті охопити обидві фази (Фазу 1 – співіснування та Фазу 2 – повний перехід).

Поетапний перехід викликів: Гібридний та хмарний — ***Поетапний перехід викликів: гібридні та хмарні***

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

Друге міркування стосується того, як ви будете переносити користувачів, пристрої та програмні клієнти з локальної системи керування викликами до хмарної системи керування викликами. Рекомендований підхід – це трифазний перехід. На рисунку Рекомендований 3-фазний перехід нижче цей підхід розбивається на 3 фази.

Перед міграцією: Цей етап зосереджений на підготовці середовищ Webex та Unified CM до міграції. Йдеться не про виклик конкретного планування чи налаштування, а про виконання дій, які можна виконати зараз і до початку будь-якого проекту міграції Webex Calling. Мета полягає в тому, щоб створити основу для двох середовищ, щоб підготуватися до міграції.

Підготовка до міграції: На цьому етапі починаються зусилля з підготовки до міграції на Webex Calling. Тут необхідно переглянути та оновити бізнес-вимоги та технічні вимоги. Не просто піднімайте та змінюйте те, що зараз розгорнуто за допомогою Unified CM, а натомість переосмисліть бізнес- та технічні вимоги, які потрібні вашій компанії сьогодні та в майбутньому, використовуючи можливості Webex Calling. Крім того, це етап, на якому ви завершите проектування, планування конфігурації та міграцію. planning/schedule.

Міграція (розгортання та виведення з експлуатації): На цьому етапі відбувається фактична міграція користувачів, пристроїв, номерів телефонів та програмних клієнтів. Як обговорювалося вище, цей етап можна виконати для всіх одночасно (блискавично скорочення) або протягом кількох вікон змін (поетапне скорочення). Плани впровадження для кінцевих користувачів, навчання та комунікації є критично важливими, щоб ваші користувачі були обізнані зі змінами, знали, як використовувати нову платформу викликів, і коли зміни відбудуться. Останнім кроком є виведення з експлуатації всієї локальної інфраструктури уніфікованих комунікацій, яка більше не використовується.

Фаза підготовки до міграції включає дії (обов’язкові, рекомендовані та необов’язкові), над якими ви можете негайно розпочати роботу. Рекомендується виконати їх якомога раніше, а краще до початку вашого проєкту. Деякі дії можуть тривати довше, тому їх ранній початок допоможе оптимізувати ваш фактичний проект міграції.

На рисунку «Підготовчі дії до міграції нижче показано п’ять конкретних категорій дій, пов’язаних із міграцією Webex Calling.

Підготовка

Бізнес- та технічні вимоги

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

Чому важливо збирати вимоги:

Узгоджує бізнес-цілі: Розуміння потреб бізнесу допомагає адаптувати міграцію до ключових робочих процесів, зручності використання та планів зростання.
Забезпечує технічну сумісність: Раннє визначення технічних вимог запобігає проблемам інтеграції з існуючою інфраструктурою, мережею та кінцевими точками.
Сприяє плануванню ресурсів: Чіткі вимоги допомагають точно оцінити терміни, витрати та необхідні ресурси.
Зменшує ризики: Раннє виявлення потенційних проблем дозволяє приймати проактивні рішення, зменшуючи час простою та переривання обслуговування.

Вимоги бізнесу

Типові бізнес-вимоги включають:

Кількість користувачів і місць розташування, яких потрібно перенести
Бажані функції та послуги (наприклад, маршрутизація викликів, голосова пошта, конференц-зв'язок, автосекретарі, черги викликів)
Політики відповідності та безпеки
Бюджетні обмеження та очікувані витрати
Потреби в навчанні та підтримці користувачів
Графік міграції та міркування щодо безперервності бізнесу.

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

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

Зосередьтеся більше на тому, що вам потрібно, ніж на тому, що у вас є.

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

Відповідність нормативним вимогам: Організації повинні перевірити, чи відповідає це галузевим нормам, таким як GDPR, HIPAA або SOX, що враховують вимоги щодо конфіденційності, зберігання та обробки даних, а також вимоги конкретної країни щодо місця розташування даних, обходу платних доріг та локалізації медіа.
Безпека даних: Забезпечення шифрування голосових та сигнальних даних як під час передачі, так і в стані спокою для захисту від перехоплення або несанкціонованого доступу.
Контроль доступу: Визначення та забезпечення автентифікації користувачів, авторизації та доступу на основі ролей для запобігання несанкціонованому використанню комунікаційних ресурсів.
Аудит та моніторинг: Впровадження можливостей реєстрації та моніторингу для відстеження доступу та використання для проведення аудитів відповідності та розслідувань інцидентів безпеки.
Узгодження політики: Узгодження міграції з існуючими політиками корпоративної безпеки, включаючи безпеку кінцевих точок, сегментацію мережі та плани реагування на інциденти.
Гарантія безпеки постачальника: Оцінка сертифікатів безпеки та атестацій відповідності Cisco для забезпечення надійності.

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

Потреби в навчанні та підтримці користувачів є важливими компонентами під час міграції з на для забезпечення плавного переходу та впровадження користувачами. Ключові міркування включають:

Навчальні програми: Розробляти індивідуальні навчальні сесії для різних груп користувачів (кінцевих користувачів, адміністраторів, співробітників служби підтримки), щоб ознайомити їх з функціями, інтерфейсами користувача та новими робочими процесами.
Документація: Надайте чіткі та доступні посібники користувача, відповіді на поширені запитання та короткі довідкові матеріали, включаючи ресурси «Що нового та відмінного » та покрокові інструкції «До та після » (у форматі відео або короткого посібника), щоб допомогти користувачам адаптуватися до оновленого інтерфейсу після міграції.
Управління змінами: Проактивно повідомляйте про зміни, щоб керувати очікуваннями користувачів та зменшувати опір.
Структура підтримки: Створіть спеціальну команду підтримки або шлях ескалації для оперативного вирішення проблем користувачів під час та після міграції.
Безперервна освіта: Плануйте постійні оновлення навчальних матеріалів у міру випуску нових функцій або оновлень у .
Механізми зворотного зв'язку: Впроваджуйте канали для повідомлення користувачів про проблеми та надання зворотного зв'язку для покращення процесів навчання та підтримки.

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

Технічні вимоги

Для успішної міграції з на необхідно зібрати та задокументувати кілька ключових технічних вимог, включаючи деталі щодо:

Готовність мережі та пропускна здатність

Комплексна оцінка мережі є критично важливою для того, щоб ваша існуюча інфраструктура могла підтримувати нове середовище Webex Calling. Зокрема:
- Аналіз пропускної здатності: Оцінка поточного та прогнозованого використання пропускної здатності для обробки голосового, відео та інформаційного трафіку без перевантаження.
- Якість обслуговування (QoS): Впровадження політик QoS для визначення пріоритетів голосового трафіку та мінімізації затримки, джиттера та втрати пакетів.
- Підключення до WAN та Інтернету: Перевірка відповідності WAN-з’єднань та інтернет-з’єднань вимогам для хмарних викликів, включаючи можливості резервування та відновлення після відмови.
- Конфігурація брандмауера та NAT: Забезпечення того, щоб налаштування брандмауера та NAT дозволяли необхідну передачу сигналів та медіатрафіку для .
Інтеграція з існуючою системою

Безперебійна інтеграція з існуючими бізнес-системами є важливою для зручності користувача та безперервності робочого процесу:
- Служби каталогів: Оцінка інтеграції з корпоративним каталогом для автоматизованої підготовки та автентифікації користувачів.
- CRM та бізнес-додатки: Визначення точок інтеграції із системами управління взаємовідносинами з клієнтами та іншими критично важливими для бізнесу програмами.
- Взаємодія зі старими АТС: Планування стратегій співіснування або поетапної міграції, якщо будь-які застарілі телефонні системи залишаться під час переходу.
Сумісність та забезпечення кінцевих точок

Усі кінцеві пристрої, включаючи стаціонарні телефони, софтфони та мобільні пристрої, слід оцінити на сумісність:
- Підтримка пристроїв: Підтвердження підтримки існуючих IP-телефонів та пристроїв або визначення необхідних замін.
- Процеси забезпечення: Встановлення автоматизованих або оптимізованих методів забезпечення ресурсів для ефективного підключення кінцевих точок.
- Оновлення прошивки та програмного забезпечення: Планування необхідних оновлень для забезпечення сумісності та безпеки.
Конфігурації безпеки та стандарти шифрування

Безпека є надзвичайно важливою у хмарних комунікаціях:
- Шифрування: Забезпечення наскрізного шифрування сигнальних та медіапотокових даних відповідно до найкращих практик безпеки Cisco.
- Аутентифікація та контроль доступу: Впровадження безпечних механізмів автентифікації (таких як SSO, багатофакторна автентифікація) та детального контролю доступу користувачів.
- Відповідність: Забезпечення відповідності рішення відповідним нормативним та галузевим стандартам (наприклад, GDPR, HIPAA).
- Моніторинг безпеки: Інтеграція з інструментами SIEM та налаштування сповіщень про потенційні інциденти безпеки.

Таблиця 1. Приклад оцінювання
Вимоги	Ключові міркування
Готовність мережі та пропускна здатність	Пропускна здатність, якість обслуговування (QoS), WAN/Internet, Firewall/NAT
Інтеграція з існуючими системами	Довідник, CRM, АТС, Email/Calendar
Сумісність та забезпечення кінцевих точок	Підтримка пристроїв, налаштування, оновлення прошивки
Конфігурації безпеки та шифрування	Шифрування, автентифікація, відповідність вимогам, моніторинг безпеки
Навчання користувачів та управління змінами	Навчальні програми, документація, комунікація змін
Перенесення номерів та тарифний план	Номер migration/porting, переклад плану набору номера
Інтеграції зі сторонніми розробниками	Пейджинг, контакт-центр, факс, аналогові пристрої

Готовність до мережі та вимоги

Готовність до мережі є критично важливою для успішної міграції на будь-яке хмарне рішення для викликів, таке як . Погане планування мережі може призвести до погіршення якості зв'язку, обривів дзвінків та незадоволення користувачів. Клієнтам необхідно провести оцінку мережі перед переходом на . Рекомендується підтвердити доступність пропускної здатності мережі для очікуваного обсягу викликів, забезпечити виконання вимог щодо якості обслуговування (QoS) та зрозуміти різні порти, які необхідно відкрити в граничному брандмауері(ах).

Надійне мережеве з’єднання з достатньою якістю обслуговування (пропускна здатність, втрата пакетів, RTT) є базовою вимогою для забезпечення найкращого можливого користувацького досвіду від початку до кінця для всіх кінцевих точок, клієнтів та програм, що використовують .

Клієнти та партнери мають варіанти підключення доступу, що виходять за рамки OTT (Over-the-top Internet), що дозволяє оптимізувати з’єднання, включаючи Webex Edge Connect. Щоб отримати додаткові відомості про деталі проектування Webex Edge Connect, див . Рекомендована архітектура Cisco для Webex Edge Connect для зустрічей Webex, викликів багатокористувацьких систем та виділених екземплярів.

Клієнти можуть використовувати CScan для оцінки мережі, яка надає інформацію про якість мережі клієнта, кількість дзвінків, які можна встановити, затримку тощо. Щоб отримати додаткові відомості про інструмент CScan, див. Використання CScan для перевірки якості мережі Webex Calling.

Щоб переконатися, що мережа готова до міграції на , розгляньте наступний контрольний список:

Планування пропускної здатності

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

У таблиці розрахунків пропускної здатності для типів викликів Webex Calling наведено типи викликів, доступні для розгортання, а також кодек і максимальну пропускну здатність, необхідну для кожного типу виклику. Як показано в таблиці розрахунки пропускної здатності для типів викликів Webex Calling, необхідну пропускну здатність аудіодзвінків для кожного типу виклику можна розрахувати за такою загальною формулою:

Кількість очікуваних одночасних викликів * Пропускна здатність на виклик залежно від кодека = Необхідна пропускна здатність мережі.

Таблиця 2. Розрахунки пропускної здатності для типів викликів Webex Calling
Типи дзвінків	Кодек - пропускна здатність	Розрахунки пропускної здатності
/ Стаціонарний телефон ->	OPUS – 70 кбіт/с	Кількість одночасних дзвінків * 70 кбіт/с = Необхідна пропускна здатність мережі
/ Стаціонарний телефон -> Стаціонарний телефон	OPUS – 70 кбіт/с	Кількість одночасних дзвінків * 70 кбіт/с = Необхідна пропускна здатність мережі
/ Стаціонарний телефон -> PSTN через LGW	G.711 – 80 кбіт/с	Кількість одночасних дзвінків * 80 кбіт/с = Необхідна пропускна здатність мережі
/ Стаціонарний телефон -> PSTN через хмарну PSTN (наприклад, тарифний план Cisco)	G.711 – 80 кбіт/с	Кількість одночасних дзвінків * 80 кбіт/с = Необхідна пропускна здатність мережі
/ Стаціонарний телефон -> Підприємство через LGW	G.722 – 80 кбіт/с	Кількість одночасних дзвінків * 80 кбіт/с = Необхідна пропускна здатність мережі
/ Стаціонарний телефон -> голосова пошта	OPUS – 70 кбіт/с	Кількість одночасних дзвінків * 70 кбіт/с = Необхідна пропускна здатність мережі

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

Усі гілки викликів завжди прив'язані до SBC доступу. Щоб визначити необхідну пропускну здатність Інтернету для будь-якого заданого місця розташування, необхідно враховувати не лише міжлокаційні дзвінки, але й внутрішньолокаційні дзвінки, а також дзвінки до та від локального шлюзу в цьому місці розташування. Наприклад, для внутрішньооб'єктового дзвінка між двома телефонами MPP знадобиться до 2 x 70 кбіт/с повного дуплексного з'єднання на інтернет-каналі об'єкта.

У таблиці приклади розрахунку пропускної здатності Webex Calling наведено приклад повного розрахунку пропускної здатності, за умови, що всі пристрої знаходяться на одному сайті.

Таблиця 3. Приклади розрахунку пропускної здатності Webex Calling
Типи дзвінків	Кількість одночасних дзвінків	Загальна пропускна здатність
Додаток Webex / Стаціонарний телефон → Додаток Webex	15	2 * 15 * 70 кбіт/с = 2100 кбіт/с
Додаток Webex / Стаціонарний телефон → Стаціонарний телефон	15	2 * 15 * 70 кбіт/с = 2100 кбіт/с
Додаток Webex / Стаціонарний телефон → PSTN через LGW	50	2 * 50 * 80 кбіт/с = 8000 кбіт/с
Додаток Webex / Стаціонарний телефон → PSTN через Cloud Connect для Webex Calling	0	0 * 80 Кбіт/с
Додаток Webex / Стаціонарний телефон → Підприємство через LGW	15	2 * 15 * 80 кбіт/с = 2400 кбіт/с
Додаток Webex / Стаціонарний телефон → Webex Calling Голосова пошта	5	5 * 70 кбіт/с = 350 кбіт/с
Загальна кількість дзвінків / Пропускна здатність	100 дзвінків	14 950 кбіт/с / 14,95 Мбіт/с

Усі значення пропускної здатності у наведених вище таблицях стосуються пропускної здатності IP-адреси. Пропускна здатність каналу вища залежно від інкапсуляції WAN.
Пропускна здатність у наведених вище таблицях вказана для аудіодзвінків. Для пропускної здатності відеодзвінків, застосунок Webex та MPP 8845/65 Телефони підтримують відео H.264 з максимальною роздільною здатністю 720p та максимальною пропускною здатністю 1500 кбіт/с на дзвінок. Однак обсяг пропускної здатності, що споживається в будь-який момент під час дзвінка, коливатиметься залежно від змінної швидкості передачі даних, властивої відеозв'язку.

Якість обслуговування (QoS)

Впроваджуйте політики QoS у вашому локальному середовищі, щоб пріоритезувати трафік у режимі реального часу та забезпечити підтримку QoS на комутаторах, маршрутизаторах і брандмауерах.
Цілі затримки, джиттера та втрати пакетів

Для оптимальної якості голосового зв'язку під час дзвінків через OTT (Over-the-Top) та через Інтернет рекомендуються такі порогові значення:
- Затримка - менше 100 мс в один бік
- Джиттер - менше 10 мс
- Втрата пакетів – 0,5% або менше.
Брандмауер і NAT

Переконайтеся, що брандмауер налаштовано на дозвіл трафіку, як зазначено у статті, доступній за адресою Інформація про порти для викликів Webex. Крім того, дозвольте доступ до доменів та діапазонів IP-адрес, перелічених у тому ж посібнику, та уникайте SIP ALG, оскільки це перешкоджає SIP-сигналізації. Слід уникати медіатрафіку через проксі-сервери.
DNS та NTP

Забезпечте належну роздільну здатність DNS доменів та надійні NTP-сервери для синхронізації годинників пристроїв для перевірки та реєстрації сертифікатів TLS.
Планування резервного перемикання

Врахуйте існуючі з’єднання для передачі даних від постачальників (MPLS, SD-WAN тощо) та загалом сплануйте прямий доступ до Інтернету в кожному місці вашого розгортання. Плануйте резервні інтернет-з'єднання там, де потрібна висока доступність. Оскільки ви будете використовувати хмарні сервіси, надійне підключення до Інтернету з достатньою пропускною здатністю є базовою вимогою. Вам слід переглянути можливість цього переходу, якщо підключення до Інтернету у вашій організації загалом не є надійним, має низьку затримку та достатню пропускну здатність для вхідних та вихідних даних.
Житуальність сайту

Живучість сайту гарантує, що ваш бізнес завжди буде доступним, навіть якщо ваше мережеве з’єднання перерветься. Site Survivability використовує шлюз у вашій локальній мережі для забезпечення резервної служби викликів до локальних кінцевих точок у ситуаціях, коли мережеве з'єднання розривається. Розгляньте можливість забезпечення живучості об'єкта за допомогою локального шлюзу живучості (SGW), якщо бізнес-вимоги вимагають безперервного виклику у разі збою в мережі. Щоб отримати додаткові відомості про перевірку живучості сайту, див. Живучість сайту для Webex Calling.

Налаштування хмарно-підключеного UC

Cloud Connected UC (CCUC) – це хмарне рішення для управління та аналітики, розроблене для забезпечення централізованої видимості, адміністрування та аналітики для розгортань як локально (наприклад, Unified CM), так і в хмарі (). Він виступає посередником між традиційними локальними середовищами та хмарними сервісами Cisco, підтримуючи організації протягом усього процесу міграції з .

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

Cisco наполегливо рекомендує розгортати CCUC на ранніх етапах перехідного проекту, в ідеалі до або під час підготовчого етапу. Це дозволить отримати аналітичні дані та можливості, необхідні для ретельної оцінки, інвентаризації та планування подальших міграційних заходів, а також для початку вашого шляху до майбутніх гібридних можливостей.

Оцінка поточного середовища

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

У рамках цих зусиль важливо розглянути наступні аспекти.

Ліцензування

Розуміння поточної структури ліцензування існуючого розгортання є ключовим під час підготовки до переходу на . Виконайте оцінку ліцензій для наступних областей вашого існуючого локального рішення Cisco.

Платформа

Здатність повністю пояснити, що наразі ліцензовано на вашій основній платформі, буде критично важливою під час співпраці з вашою командою з обслуговування клієнтів або партнером для визначення найкращого шляху до гнучкого ліцензування. Щоб отримати додаткові відомості про гнучке ліцензування, див. Гнучкий план співпраці Cisco.
Користувачі та пристрої

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

Якщо для цього переходу для доступу до PSTN потрібен Cisco Unified Border Element (CUBE), також слід розглянути ліцензування CUBE. Аспекти ліцензування CUBE розглянуто далі в цьому документі.

Locations/Sites

Під час планування цього переходу слід враховувати кількість і типи сайтів (великий центральний, регіональний, філіали тощо) у вашому існуючому розгортанні. Повне розуміння існуючих сайтів розгортання допоможе у стратегічному плануванні успішного переходу, особливо коли йдеться про визначення того, які сайти мігрувати та в якому порядку. Детальне розуміння вимог до плану набору (нумерація, звички набору, класи обмежень тощо), підключення до мережі та пропускної здатності сайту (Інтернет, WAN, LAN), а також доступу до PSTN (локального чи централізованого, IP або TDM) для кожного сайту буде критично важливим під час прийняття рішень щодо міграції. Щоб отримати додаткові відомості про поширені моделі розгортання та ключові міркування, див. інформацію про моделі розгортання для співпраці, доступну в SRND для співпраці.

Ще одним важливим фактором розгортання під час переходу до є доступність розташування. має різні можливості, підписки та пристрої, доступні залежно від того, де знаходиться ваше розгортання. Щоб отримати докладнішу інформацію про географічну доступність, див. Де доступний Webex?.

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

наявний інвентар devices/clients

Перш ніж розпочати перехід, важливо провести інвентаризацію існуючого обладнання та програмного забезпечення кінцевих точок. Наявність повного списку пристроїв types/models, Версії обладнання, типи та кількості ОС програмних клієнтів забезпечать вам належне планування переходу пристроїв та пом’якшення впливу на ті пристрої, які неможливо перенести на хмарні виклики. Інвентаризацію слід використовувати для визначення пристроїв, які потрібно перевести, та пристроїв, які потрібно замінити до переходу.

Стаціонарні телефони

Для аудіо- та відеонастільних телефонів підтримуються лише настільні телефони серій 6800, 7800, 8800 та 9800. Це підмножина IP-телефонів Cisco, які підтримуються з . Існують деякі моделі та версії телефонів 6800, 7800 та 8800, які не можна використовувати з . Щоб отримати додаткові відомості про підтримувані моделі та версії обладнання, див. Підтримувані пристрої для Webex Calling.

IP-телефони Cisco серії 6800 не можна оновити з прошивки Enterprise до прошивки Multiplatform (MPP), яка потрібна для . Тому будь-які телефони 6800, зареєстровані для роботи з корпоративною прошивкою, необхідно замінити на модель 6800 MPP або на іншу підтримувану модель телефону.

IP-телефони Cisco серій 7800 та 8800 необхідно оновити до прошивки Multiplatform Phone (MPP) перед переходом та реєстрацією їх у . Щоб визначити, які моделі 7800 та 8800 і версії обладнання підтримують прошивку MPP, див. Перетворення прошивки Enterprise на прошивку MPP для IP-телефонів Cisco серії 7800 та 8800.

Продаж моделей 8845, 8865 та 8865NR закінчився, і їх не рекомендується переходити на .

Старіші версії телефонів серії 8800 (8811, 8841, 8851, 8851NR, 8861) не рекомендується використовувати з Webex Calling. Телефони з версіями апаратного забезпечення VID 14 або ранішими зареєструються, але можуть виникнути деякі проблеми з продуктивністю через апаратне забезпечення.

Настільні телефони серії 9800 працюють на базі PhoneOS, яка підтримує як реєстрацію, так і реєстрацію. Таким чином, на ці телефони можна перейти без оновлення прошивки.

Усі інші IP-телефони потрібно буде замінити на телефони серій 6800, 7800, 8800 або 9800, що підтримуються Webex Calling. Щоб отримати додаткові відомості про підтримувані IP-телефони та стаціонарні телефони з , див. статтю за адресою Підтримувані пристрої для Webex Calling.

Кінцеві точки відео

Персональні та кімнатні відеокінцеві точки, включаючи серії Cisco Board, Room та Desk, можуть реєструватися в .sip за допомогою власного протоколу SIP. Будь-яка з цих кінцевих точок, яка потребує передачі звуку and/or Для дзвінків PSTN потрібна ліцензія на дзвінки:

Для спільних пристроїв у конференц-залах, місцях для нарад тощо потрібна ліцензія Professional Workspace або Workspace.

Для персонального пристрою кінцевого користувача потрібна професійна або стандартна ліцензія.

Визначте, скільки кінцевих точок відео зареєстровано та використовуються для здійснення аудіодзвінків. Можливо, деякі кінцеві відеоточки можна використовувати лише для приєднання до зустрічей або здійснення відеодзвінків SIP. У будь-якому випадку, кінцеві точки все одно потрібно перенести, перш ніж сервери будуть виведені з експлуатації, проте це допоможе визначити, скільки з них потребуватимуть ліцензій для продовження телефонних дзвінків.

Коли відеопристрої переміщуються з реєстрації до , URI для цих кінцевих точок зміниться, оскільки тепер вони зареєстровані в хмарі.

Моделі телефонів 8845, 8865 та 8875 – це персональні відеотелефони, що підтримуються з .

М'які клієнти

Це єдиний програмний клієнт, що підтримується , на відміну від Unified CM, який підтримує як застосунок Webex, так і Jabber, і є новим програмним клієнтом за замовчуванням для кінцевих користувачів.

Залежно від режиму(ів) розгортання, що застосовується для Jabber (лише миттєві повідомлення, лише телефон, and/or повні режими UC), вам також може знадобитися врахувати перехід обміну повідомленнями and/or Робоче навантаження зустрічей з Jabber до . Можна розгорнути в режимі лише для телефону, якщо він використовуватиметься як клієнт лише для дзвінків, або як повний пакет Webex Suite, якщо використовуються інші робочі навантаження, наприклад, Webex Messaging and/or Webex Meetings переносяться в додаток із функцією викликів.

Це покращує взаємодію кінцевого користувача, надаючи такі функції штучного інтелекту, як audio/video розвідка, транскрипція дзвінків та інші. Додаткову інформацію див. на сторінці https://www.webex.com/all-new-webex.

Перш ніж переміщувати користувачів до вас, потрібно буде перевести їхні клієнти Jabber на . У вас є два варіанти для завершення цього переходу.

Перш ніж перевести їх на

Коли ви переходите їх на .

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

Для отримання додаткової інформації про ці два варіанти див. Шлях міграції – один чи два кроки?.

Повний список підтримуваних пристроїв для див. у розділі Підтримувані пристрої для Webex Calling.

Перевірте придатність пристрою

Як згадувалося раніше, підтримує підмножину IP-телефонів Cisco та вимагає іншого типу прошивки для телефонів серій 7800 та 8800. Телефони Unified CM використовують прошивку Enterprise, тоді як телефони Phone використовують прошивку Multiplatform Phone (MPP). Рекомендується перевірити, які зареєстровані телефони мають право на оновлення прошивки MPP, під час етапу підготовки. Це дає вам час замінити невідповідні телефони однією з підтримуваних моделей телефонів або визначити альтернативний план, наприклад, перевести користувача лише на додаток Webex.

Щоб допомогти визначити відповідність телефонів вимогам, Control Hub має вбудований інструмент під назвою «Перенесення телефону до Webex Calling». Під час використання цього інструменту для перевірки придатності пристрою виберіть опцію «Міграція» «Створити лише ліцензію на пристрій» .

Опція інструмента Control Hub для перевірки відповідності телефонів Unified CM вимогам Webex Calling

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

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

Вручну перевірте кожен телефон та перевірте модель і версію обладнання (PID VID)

7800/8800 етикетка телефону з інформацією про модель та версію обладнання

Використання засобу перевірки готовності IP-телефонів Cisco

Завантажте інструмент з https://github.com/joemar2/mpp_readiness_check.

Цей інструмент не є офіційним інструментом Cisco і не підтримується TAC. Він має найкращу підтримку, але користування безкоштовне.

Цей інструмент має бути запущений на локальному комп’ютері, який має доступ до серверів і IP-телефонів. Він має опцію ввімкнення веб-доступу на IP-телефонах, що рекомендується та необхідно для отримання найкращих результатів. Тому його слід використовувати в неробочий час, щоб уникнути перешкод для кінцевих користувачів. Результат роботи інструменту надає звіт, у якому перелічено, які з телефонів серій 7800 та 8800 мають право на оновлення прошивки MPP. Оскільки він отримує прямий доступ до телефону, він може перевірити Невідомі пристрої, про які повідомляв інструмент Control Hub.

Звіт про готовність інструменту Cisco IP-телефонів

Користувачі

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

Розгортання за допомогою виклику

Розгортання за допомогою

Налаштування служб для користувача

Зробити пошук користувачів у довіднику (дзвінок за кліком, контактна інформація користувача, пошук у телефонному довіднику).

Рекомендується підготувати всіх користувачів до або на початку вашого проєкту. Це включає користувачів, які досі використовують Unified CM для платформи викликів, незалежно від їхнього пристрою для викликів (IP-телефон, Jabber тощо). Коли користувачі переходять до (and/or ) ви оновите їхні ліцензії, щоб увімкнути необхідні їм послуги. Завдяки підготовці всіх корпоративних користувачів перед початком переходу, користувач, який перейшов на або , може шукати в каталозі корпоративного користувача, який все ще користується Jabber. and/or на . Це гарантує, що переведені користувачі можуть знайти контактну інформацію будь-якого іншого користувача та зателефонувати йому за допомогою пошуку в довіднику.

На рисунку пошук у каталозі показано приклад, коли користувач шукає іншого користувача. Результати пошуку показують контактну інформацію користувача та можуть бути як для користувача, який все ще користується Jabber, так і для користувача, який перейшов на… and/or .

Пошук у каталозі програм Webex

Далі визначте, яких із існуючих локальних користувачів, що здійснюють дзвінки, буде переведено на . Якщо всіх або велику кількість користувачів буде переведено, рекомендується переміщувати користувачів у групи, щоб команда проекту, ІТ-персонал та персонал служби підтримки могли впоратися з переходом та будь-якими проблемами, які можуть виникнути. Вам також слід виділити певний час для надання початкової інформації та проведення навчальних сесій, щоб підготувати користувачів до цього переходу. Групування користувачів для переходу між користувачами може здійснюватися на основі різних критеріїв, включаючи місцезнаходження або сайт, до якого призначені користувачі, відділи користувачів або навіть типи користувачів (працівники інтелектуальної роботи, керівники, мобільні працівники тощо).

Наприклад, якщо користувачі в розгортанні розділені на три основні сайти: Нью-Йорк (NYC), Сан-Франциско (SFC) та Research Triangle Park (RTP), план переходу користувачів може виглядати так, як наведено в таблиці План переходу користувачів за сайтами.
Таблиця 4. План переходу користувачів за сайтом
Сайт користувача / місцезнаходження Інформація та навчальні сесії перед переходом Перехідний період Підтримка після переходу
Нью-Йорк (1525 користувачів) Тиждень з 1 квітня 15 квітня – 27 квітня Тиждень з 29 квітня
СФО (1600 користувачів) Тиждень з 6 травня 20 травня – 31 травня Тиждень з 3 червня
RTP (1275 користувачів) Тиждень з 3 червня 17 червня – 28 червня Тиждень з 1 липня

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

Моніторинг BLF

Те саме полювання pilot/group

Спільні лінії

Частина тієї ж групи перехоплення дзвінків

Використання тих самих номерів паркування викликів

Домофон

Admin/Exec.

Ви можете переглянути конфігурацію (графічний інтерфейс або експорт) або скористатися інструментом Migration Insights, щоб допомогти визначити групи користувачів із цими залежностями.

Таблиця 4. План переходу користувачів за сайтом
Сайт користувача / місцезнаходження	Інформація та навчальні сесії перед переходом	Перехідний період	Підтримка після переходу
Нью-Йорк (1525 користувачів)	Тиждень з 1 квітня	15 квітня – 27 квітня	Тиждень з 29 квітня
СФО (1600 користувачів)	Тиждень з 6 травня	20 травня – 31 травня	Тиждень з 3 червня
RTP (1275 користувачів)	Тиждень з 3 червня	17 червня – 28 червня	Тиждень з 1 липня

Підключення до PSTN

можна отримати доступ до PSTN трьома способами: Тарифні плани Cisco, Cloud Connect for (раніше Cloud Connected PSTN) та локальна PSTN (локальний шлюз). Однак, одне розташування, як визначено в цьому документі, може бути призначене лише одному варіанту PSTN.

Локальна PSTN з локальним шлюзом (LGW) є важливим компонентом стратегії переходу. Він забезпечує зв'язок між локальним розгортанням and/or PSTN та платформа підтримують як Cisco, так і сертифіковані сторонні прикордонні контролери сеансів (SBC), які можна використовувати як локальний шлюз. Щоб переглянути найновіший список підтримуваних SBC, див. Список підтримуваних SBC.

підтримує до 250 одночасних викликів з одного локального шлюзу на основі реєстрації та понад 250 одночасних викликів з одного локального шлюзу на основі сертифікатів. Локальні шлюзи на основі сертифікатів можуть підтримувати до 6500 одночасних викликів, але це залежить від типу підключення, яке має використовувати локальний шлюз (Over-the-Top чи Interconnect peering), та моделі SBC, на якій розгорнуто локальний шлюз. Ці обмеження, по суті, є стандартним обмеженням кількості як для локальних шлюзів PSTN, так і для міжсайтових дзвінків між кінцевими точками. Для отримання додаткової інформації див. Початок роботи з локальним шлюзом.

Будь-які виклики, що перевищують цей ліміт, відхиляються з кодом 403 Forbidden. Команду show call active voice можна виконати на локальному шлюзі в будь-якому екземплярі, щоб визначити загальну кількість активних викликів.

Погані мережеві умови між локальним шлюзом та контролером SBC доступу можуть обмежувати продуктивність сигнального з'єднання, що призводить до ще нижчого ліміту одночасних викликів. Одностороння затримка між локальним шлюзом та центром обробки даних не повинна перевищувати 100 мс, а джиттер має бути менше 10 мс, а втрата пакетів менше 0,5. %.

Особливості & використання функцій

Під час оцінки поточного середовища важливо визначити та переглянути, які функції налаштовані. Крім того, важливо розуміти використання функцій, щоб ви могли (пере)визначити свої бізнес-вимоги та технічні вимоги до розгортання.

Щоб визначити, які функції налаштовано, проаналізуйте конфігурацію. Це все статичні дані, які встановлюються під час налаштування функції або параметра в системі. Для завершення цього аналізу можна використовувати такі опції:

Перегляд конфігурації в графічному інтерфейсі адміністратора

експорт конфігурації -- масовий експорт або AXL

інструмент аналізу міграції (рекомендовано)

Інструменти сторонніх партнерів Cisco (рекомендовано).

Для ефективного аналізу використання функцій важливо вивчити динамічні системні дані, такі як використання, реєстрації та активність викликів. Різні аналітичні інструменти та панелі інструментів надають уявлення про ці показники, що дозволяє отримати повне розуміння продуктивності та потужності системи, що сприяє прийняттю обґрунтованих рішень під час міграції та оптимізації. Для виконання цього типу аналізу можна використовувати такі опції:

Перегляд необроблених записів CDR

Огляд даних Unified CM RTMT

Інструмент аналізу міграції з використанням даних CDR

Огляд аналітики хмарно-підключених уніфікованих комунікацій у

Гучність дзвінків

Зареєстровані кінцеві точки

(CAC) місця розташування

Використання магістралі.

Інструменти сторонніх партнерів Cisco.

Cisco рекомендує почати з інструменту Webex Control Hub Migration Insights для цього аналізу. Ви імпортуєте експортований файл .TAR та файли Unified CM CDR (необов’язково, але обов’язково для аналізу використання функцій) в інструмент. Інструмент генеруватиме такі звіти у форматі CSV, які можна використовувати для початку аналізу:

Таблиця 5. Звіти, згенеровані з файлу Unified CM .tar
Назва звіту
Опис звіту
ImportedDataBulk.csv
Усі користувачі та пристрої з даних Unified CM
DeviceEligibility.csv
Визначає пристрої, які можуть бути перенесені на Webex Calling (IP-телефони, пристрої Room OS, ATA та пристрої третіх сторін)
DevicePoolNumbers.txt
Список усіх номерів у певному пулі пристроїв
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Відомості про пристрої та користувачів, яких слід перенести разом, на основі спільних ліній, пілотного пошуку, черги викликів, паркування викликів та конфігурації групи перехоплення викликів
HuntGroupMigrationInsight.csv
Детальна інформація про призначені лінії пошуку, групи ліній та пов'язаних агентів
SharedlineGroupMigrationReport.csv
Огляд того, як номери телефонів (номери довідника) спільно використовуються між користувачами

Таблиця 6. Звіти, створені з файлів Unified CM .tar та CDR.gzip
Назва звіту
Опис звіту
FeatureUsageBasedDeviceEligibilityReport.csv
Інформація про право на міграцію пристроїв на основі використання функцій
FeatureUsageWithLastUsageDateReport.csv
Кількість викликів пілотних операцій Hunt та черги викликів, а також дата останнього використання.
UserWorkspaceLastUsage.csv
Дата останнього використання для користувачів та робочих просторів як для програмних клієнтів, так і для апаратних телефонів
DIDUsageReport.csv
Використання DID як для призначених, так і для непризначених DID

Щоб отримати докладнішу інформацію про звіти Migration Insights, див. Migration Insights.

Якщо вам потрібна додаткова інформація про функції та використання після перегляду інформації у звітах Migration Insights, Cisco рекомендує розглянути один із інструментів міграції сторонніх партнерів Cisco. and/or щоб переглянути конфігурації в графічному інтерфейсі або в даних експорту конфігурації.

Таблиця 5. Звіти, згенеровані з файлу Unified CM .tar
Назва звіту Опис звіту
ImportedDataBulk.csv Усі користувачі та пристрої з даних Unified CM
DeviceEligibility.csv Визначає пристрої, які можуть бути перенесені на Webex Calling (IP-телефони, пристрої Room OS, ATA та пристрої третіх сторін)
DevicePoolNumbers.txt Список усіх номерів у певному пулі пристроїв
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Відомості про пристрої та користувачів, яких слід перенести разом, на основі спільних ліній, пілотного пошуку, черги викликів, паркування викликів та конфігурації групи перехоплення викликів
HuntGroupMigrationInsight.csv Детальна інформація про призначені лінії пошуку, групи ліній та пов'язаних агентів
SharedlineGroupMigrationReport.csv Огляд того, як номери телефонів (номери довідника) спільно використовуються між користувачами

Таблиця 6. Звіти, створені з файлів Unified CM .tar та CDR.gzip
Назва звіту Опис звіту
FeatureUsageBasedDeviceEligibilityReport.csv Інформація про право на міграцію пристроїв на основі використання функцій
FeatureUsageWithLastUsageDateReport.csv Кількість викликів пілотних операцій Hunt та черги викликів, а також дата останнього використання.
UserWorkspaceLastUsage.csv Дата останнього використання для користувачів та робочих просторів як для програмних клієнтів, так і для апаратних телефонів
DIDUsageReport.csv Використання DID як для призначених, так і для непризначених DID

Інтеграції Cisco: Unity Connection UCCX UCCE

Голосова пошта є невід'ємною частиною пропозиції та вбудована в рішення. Вона не може інтегруватися з рішенням голосової пошти на базі приміщення, таким як Unity Connection або Unity Connection Express. Крім того, немає вбудованого способу перенести існуючі повідомлення голосової пошти або привітання Unity до вбудованої служби голосової пошти, доступної з . Деякі інструменти міграції сторонніх партнерів Cisco мають можливості для перенесення деяких із цих даних. Щоб отримати додаткові відомості про голосову пошту для , див. Налаштування та керування параметрами голосової пошти для користувача Webex Calling.

також підтримує спільні голосові та факсимільні скриньки. Для отримання додаткової інформації див. Керування спільною голосовою поштою та скринькою вхідних факсів для Webex Calling.

має вбудовану функцію автосекретаря, яка входить до базової платформи. Ця функція дозволяє перенести обробники викликів та функції автоматичного оператора Unity Connection. Інструмент Центру керування «Міграція функцій з Unified CM» підтримує перенесення конфігурацій Unity Connection до автосекретарів. Щоб отримати додаткові відомості про використання цього інструменту, див. Міграція пристроїв та функцій з Unified CM до Webex Calling.

Запис викликів

включає два варіанти запису дзвінків без додаткової плати.

Запис дзвінків Webex

Запис Dubber Go (партнерська пропозиція) – інтеграція між Dubber та Dubber, де всі записані медіафайли безпечно зберігаються в хмарі.

включені опції запису у таблиці висвітлено деякі ключові функції двох опцій запису дзвінків, доступних без додаткової плати.

Таблиця 7. включені опції запису
Webex Даббер Го

Доступно для всіх користувачів Доступно для всіх користувачів

Необмежена кількість записів Необмежена кількість записів

Термін зберігання 1 рік* 30-денний період зберігання

100 ГБ сховища на організацію -

Співробітники з дотримання вимог можуть отримувати доступ до записів дзвінків та керувати ними -

API для керування записами -

Адміністратори можуть налаштовувати та керувати доступом користувачів до записів їхніх дзвінків
Користувачі можуть керувати власними записами за допомогою Центру користувача and/or додаток Webex.
Тільки користувачі можуть отримувати доступ до своїх записів та керувати ними
З їхнього дубляжного порталу.

Якщо вашій організації потрібні додаткові можливості запису, такі як запис дзвінків до відповідності вимогам, довші періоди зберігання, більше місця для зберігання, аналіз зі штучним інтелектом, and/or доступ адміністратора, платні пропозиції або додаткові послуги існують як від Cisco, так і від сторонніх постачальників послуг запису. Щоб отримати додаткові відомості про постачальників послуг запису, конфігурації та додаткові партнерські послуги, див. Керування записом викликів для Webex Calling.

Таблиця 7. включені опції запису
Webex	Даббер Го
Доступно для всіх користувачів	Доступно для всіх користувачів
Необмежена кількість записів	Необмежена кількість записів
Термін зберігання 1 рік*	30-денний період зберігання
100 ГБ сховища на організацію	-
Співробітники з дотримання вимог можуть отримувати доступ до записів дзвінків та керувати ними	-
API для керування записами	-
Адміністратори можуть налаштовувати та керувати доступом користувачів до записів їхніх дзвінків Користувачі можуть керувати власними записами за допомогою Центру користувача and/or додаток Webex.	Тільки користувачі можуть отримувати доступ до своїх записів та керувати ними З їхнього дубляжного порталу.

Інтеграції зі сторонніми розробниками

підтримує різноманітні інтеграції сторонніх розробників, включаючи, але не обмежуючись, SBC для локальних шлюзів, IP-телефонів, домофонів, Speaker/Pagers, ATA тощо. Окрім цих сторонніх^{пристроїв}, Webex Calling підтримує різні сторонні^{рішення} для підтримки клієнтів, аналітики, запису, виставлення рахунків тощо. Щоб отримати додаткові відомості про рішення сторонніх^{розробників}, див. Центр додатків Webex.

Планування

План проекту високого рівня

Міграційний шлях – один чи два кроки?

Варіант 1. Міграція користувачів в один крок

Варіант 2. Двоетапна міграція користувачів

Крок 1

Крок 2

План проекту високого рівня

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

Приклади елементів, які слід включити до плану проекту:

Визначення обсягу міграції (наприклад, які користувачі, пристрої та функції будуть перенесені)

Планування навчальних сесій для кінцевих користувачів та команд підтримки

Координація оцінок готовності мережі та

Планування перехідних заходів з урахуванням резервних варіантів. Також важливо інтегрувати перевірки відповідності та безпеки, а також фази підтримки та оптимізації після міграції.

Структуруючи план проекту з урахуванням цих міркувань, організації можуть краще керувати складністю, зменшувати ризики та досягати плавнішого переходу до .

Міграційний шлях – один чи два кроки?

вимагає від користувачів використання програмного клієнта для викликів. Тому, якщо якісь користувачі все ще використовують , у вас є два варіанти, коли ви можете перемістити їх до . Ви можете виконати одноетапну або двоетапну міграцію користувачів.

Варіант 1. Міграція користувачів в один крок

Під час одноетапної міграції користувачі переходять з на одночасно з переходом з Unified CM на . Цей варіант зазвичай призначений для клієнтів з невеликою кількістю користувачів для міграції та може керувати переміщенням як програмного клієнта користувача, так і служби викликів одночасно. Рисунок Служба викликів користувача, програмний клієнт & телефон мігрує одночасно нижче висвітлює цей тип міграції. За допомогою цієї опції користувач одночасно виконає наступні дії:

Послуги дзвінків переміщено з до

Номери телефонів та розширення переміщено з до

М'який клієнт перейшов з Jabber на - зареєструється в

Реєстрацію телефону перенесено з до .

Служба викликів користувача, програмний клієнт & телефон переміщується одночасно

Це все ще може бути поетапна міграція, коли групи користувачів переміщуються в різний час, але коли переміщується кожен користувач, усі ці дії відбуваються одночасно.

Варіант 2. Двоетапна міграція користувачів

Інший підхід — це двоетапна міграція. На кроці 1 користувачі переходять з на , але залишаються увімкненими для виклику служб. Потім, на кроці 2, користувачів переміщують з Unified CM до . Цей варіант рекомендується для великих клієнтів, які хочуть керувати змінами кінцевих користувачів і хочуть відокремити зміну програмного клієнта користувача від зміни виклику служби. Наступний малюнок Міграція програмного клієнта; потім міграція виклику служби, програмного клієнта & У розділі нижче з телефону на Webex Calling висвітлено цей тип міграції.

Крок 1

М'який клієнт перейшов з до - зареєструється в .

Крок 2

Послуги дзвінків переміщено з до.

Номери телефонів та розширення переміщено з до .

реєстрацію перенесено з до .

Реєстрацію телефону перенесено з до .

Міграція програмного клієнта; потім міграція служби викликів, програмного клієнта & телефон до Webex Calling

Це все ще може бути поетапна міграція, коли групи користувачів переміщуються в різний час на обох етапах.

Обраний вами варіант залежить від того, як ви хочете керувати переходом користувачів до та . Рекомендується робити це поетапно (Варіант 2). Це дозволяє мінімізувати зміни кінцевого користувача одночасно та розподілити зусилля між різними частинами проекту. Однак, якщо ви бажаєте, щоб користувачі постраждали лише один раз, тоді варіант 1 також підійде.

Дивлячись на рекомендований шлях (Варіант 1), карта переходу високого рівня з Jabber до Webex App на малюнку нижче показано перехід високого рівня для кроку 1.

Карта високорівневого переходу з Jabber до Webex App

На цьому кроці користувачі переходять з Jabber на для всіх своїх послуг дзвінків. Однак платформа для викликів все ще залишається Unified CM, і вони зареєструють свої послуги викликів у . Як видно на рисунку карти переходу високого рівня з Jabber до застосунку Webex, локальна інфраструктура не змінюється, і вона працює так само, як Jabber. Єдина зміна полягає в тому, що потрібне підключення до .

Щоб отримати додаткові відомості про цей перехід, див. Карта переходу з Jabber на Webex та посібник з розгортання у розділі «Клієнт» на сторінці Перехід до співпраці.

Карта переходу високого рівня з Unified CM до Webex Calling на рисунку показано перехід високого рівня від до . Це крок 2 рекомендованої подорожі.

Карта високого рівня переходу з уніфікованого CM до Webex Calling

Якщо ви вирішите використовувати одноетапний підхід, це також стосується цього.

На цьому кроці користувачі переходять у групи. На цьому етапі користувачі починають використовувати для своїх дзвінків послуги, реєстрацію дзвінків та реєстрацію IP-телефонів.

Оскільки користувачі переміщуються групами, корпоративні користувачі будуть розділені між двома платформами викликів під час переходу. Фаза 1 на малюнку Карта переходу високого рівня з Unified CM до Webex Calling зображує цей стан. На цьому етапі необхідне планування того, як керувати дзвінками між користувачами на двох платформах та як будуть маршрутизуватися дзвінки PSTN. Щоразу, коли група користувачів переходить на , на та локальному шлюзі (шлюзах) потрібно буде оновити плани набору номерів та маршрутизацію викликів.

Після того, як усі користувачі, програмні клієнти та пристрої будуть переведені на (Фаза 2), всю локальну інфраструктуру уніфікованих комунікацій можна буде видалити та вивести з експлуатації.

Проєктування

Вибір регіону

Розташування

PSTN

План набору номера

Локальний абонентський план у

план набору номера

Запис

1. Вибір постачальника послуг запису дзвінків

2. Вибір регіону

Екстрені виклики

Ліцензування

Ручне призначення через

Шаблони автоматичного призначення ліцензій

Масове призначення через шаблон CSV

Призначення на основі API

Вимоги до ліцензії

Підготовка користувачів

Групи користувачів

Рекомендований підхід під час міграції з до

Проектування груп користувачів

Єдиний вхід (SSO)

Підтримка кількох постачальників ідентифікаційних даних

1. Злиття та поглинання

2. Кілька незалежних ІТ-відділів

3. Різні групи користувачів або домени

4. Підтримка різних протоколів автентифікації

5. Покращена безпека та відповідність вимогам

6. Спрощений користувацький інтерфейс

Duo MFA з єдиним вхідним входом для

Функції

Автосекретар

Паркування викликів

Прийняти виклик

Черга викликів

Група пошуку

Режими роботи

Пейджингова група

Записи

Єдиний номер

Група голосової пошти

Вибір регіону

доступний у всьому світі та надається з резервних центрів обробки даних у кількох регіонах: США (Даллас, Чикаго), Канада (Ванкувер, Торонто), Європа (Франкфурт, Амстердам), Велика Британія (Лондон, Манчестер), Австралія (Мельбурн, Сідней), Японія (Токіо, Осака), Саудівська Аравія (Ер-Ріяд, Джидда) та Індія (Мумбаї, Ченнаї). Медіа-центри надають медіа-послуги для оптимізації часу доставки медіа-контенту. Наприклад, центр обробки даних у Сінгапурі використовується для оптимізації часу доставки медіафайлів туди й назад для клієнтів з азійських країн, де час доставки до Австралії чи Японії може бути неоптимальним. Центри обробки даних з'єднані між собою багатогігабітною та повністю резервованою магістраллю. На рисунку глобально розподілені центри обробки даних показано огляд усіх центрів обробки даних. Щоб переглянути найновіший список доступних центрів обробки даних, див. Розташування центрів обробки даних для Webex Calling.

Глобально розподілені центри обробки даних

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

Щоб дізнатися про доступність у різних країнах, див. Де доступний Webex?.

Розташування

Для підготовки до виділення місць розташування необхідно зібрати необхідну інформацію для всіх цільових місць міграції. Інформація, необхідна для кожного місця розташування, зведена в Інформація для збору для кожного місця розташування.
Таблиця 1. Інформація для збору для кожного місця розташування
Інформація Коментар
Діапазон(и) розширення Кожне місцезнаходження може мати розширення, що починаються з різних цифр. Одну цифру потрібно зарезервувати для керуючої цифри міжвузлового набору (наприклад , 8), а іншу — для керуючої цифри PSTN (наприклад , 9). Жоден діапазон розширення не може починатися з цих двох цифр.
Усі діапазони розширення всіх локацій повинні бути однакової довжини.
Діапазон(и) DID -
Керувальна цифра PSTN -
Код сайту Усі коди сайтів усіх локацій повинні бути унікальними та мати однакову довжину.
Головний номер Під час створення розташування потрібно налаштувати два DID. Один як основний номер (наприклад, для призначення службі автосекретаря), а один для порталу голосової пошти.
Надайте один DID для номера голосової пошти.
Номер голосової пошти
Кількість ліцензій Необхідні ліцензії за типом, включаючи Стандартну, Професійну, Робочу область, Список маршрутів, Тарифний план вихідних дзвінків.
Одночасні дзвінки в години пік Сума одночасних викликів між пристроями та між пристроями та локальним шлюзом (PSTN та виклики до пристроїв). Потрібно визначити необхідну пропускну здатність доступу до Інтернету.
Країна -
Часовий пояс -
Мова -
Контактна особа (ім'я, телефон, електронна пошта) -
Адреса (вулиця, місто, штат, поштовий індекс) -
Фізичне місце диспетчерської служби екстреної допомоги для кінцевих точок Місце диспетчерської дії пристрою, що використовується для екстрених викликів, зазвичай включає наступне: адреса будівлі, адреса будівлі + номер поверху, адреса будівлі + номер квартири або адреса будівлі + номер поверху + office/cubical число.
Унікальне фізичне мережеве розташування для екстрених служб на кожному пристрої Фізичне мережеве розташування для екстрених викликів зазвичай включає наступне: перемикач / комутатор для дротових пристроїв, ідентифікатори базового набору послуг (BSSID) бездротової точки доступу (AP) для бездротового підключення пристроїв, and/or локальні IP-підмережі для кінцевих пристроїв.

PSTN

Під час проектування розгортання клієнти мають три основні варіанти підключення до PSTN: Тарифні плани Cisco (хмарна послуга PSTN, що надається під управлінням Cisco), хмарні підключені постачальники PSTN (CCPP, де постачальники надають послуги PSTN через хмару) та локальна PSTN (де локальні шлюзи підключають мережу підприємства до PSTN). З впровадженням транкінгу PSTN для гібридних розгортань (докладнішу інформацію див. у розділі Транкінг PSTN для гібридних розгортань Webex Calling за адресою Транкінг PSTN), організації отримують додаткову гнучкість у своєму підході до міграції. Ця функція дозволяє клієнтам перевести свою PSTN на CCPP на початку переходу та розпочати перехід на хмарну PSTN для користувачів, водночас використовуючи CCPP для підтримки послуг PSTN для користувачів, які залишаються на Cisco під час поетапної міграції.

Такий гібридний підхід дозволяє організаціям спочатку переміщувати вибрані групи користувачів у хмару, не потребуючи негайного оновлення всього свого телефонного середовища. Однак це створює додаткові складності та ризики, особливо щодо адаптації існуючої логіки маршрутизації викликів для підтримки нової архітектури. Також потребує ретельного розгляду сумісність зі старими програмами, такими як факс-сервери, контакт-центри або системи пейджингу. Ключові технічні проблеми можуть включати забезпечення безперебійного наскрізного узгодження кодеків та сигналізації DTMF (двотональний багаточастотний сигнал) у змішаному середовищі, а також перевірку сумісності зі спеціалізованими функціями телефонії. Правильне планування та тестування є важливими для мінімізації перебоїв та підтримки надійних голосових послуг протягом усього процесу міграції. Крім того, важливими є комерційні міркування, оскільки гібридне транкінгове з’єднання вимагає ліцензії на використання, яка базується на кількості одночасних викликів між локальним середовищем та постачальником хмарної PSTN-мережі (CCPP).

Або ж організації можуть зберегти локальне підключення до PSTN протягом усього перехідного етапу. У цьому випадку міграцію на CCPP можна виконати двома способами: як єдине, скоординоване перемикання для всіх користувачів та локацій після завершення міграції або поступово, при цьому міграція PSTN відбуватиметься для кожного окремого локаційного розташування, коли користувачі переміщуватимуться до . Такий підхід може допомогти оптимізувати співіснування та підтримувати безперервність для застарілих інтеграцій, але він створює кілька операційних складнощів. Серед них є проблеми, пов'язані з перенесенням номерів, такі як необхідність точної координації замовлень на перенесення номерів, потенційні затримки та обмеження, що встановлюються постачальниками, такі як обмеження кількості одночасних запитів на перенесення або обмеження на перенесення підмножин великих блоків номерів. Організації повинні ретельно планувати свою стратегію переходу на PSTN, враховуючи ці логістичні міркування, щоб уникнути перебоїв у наданні послуг та забезпечити безперебійний процес міграції.

Міграція на CCCP на початку проти збереження локальної PSTN

На рисунку Міграція на CCCP на початку проти збереження локальної PSTN показано два варіанти міграції PSTN, описані вище. На ілюстрації ліворуч показано сценарій, у якому всі локальні користувачі та програми споживають послуги хмарно-підключеної PSTN через локальну магістраль та локальний шлюз, що з’єднує локальну мережу з , тоді як на ілюстрації праворуч показано сценарій, у якому існуюча локальна PSTN залишається на місці, а користувачі Webex Calling використовують локальну PSTN через підключення локального шлюзу між локальною мережею та . Під час переходу місця розташування можна переключитися на використання підключеної до хмари PSTN.

В обох сценаріях дзвінки між локальною системою та користувачем використовують підключення локального шлюзу. З'єднання між локальною мережею та мережею має бути спроектоване та розмірено відповідно, виходячи з очікуваної кількості одночасних викликів та необхідної резервованості.

План набору номера

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

Локальний абонентський план у

Під час переходу, щоб забезпечити співіснування пристроїв, зареєстрованих в Unified CM та в корпоративному абонентському плані, необхідно змінити, щоб відповідати принаймні таким вимогам:

+E.164 набір номера з до

Набір внутрішнього номера з до (всередині сайту, а також між сайтами, якщо діапазони внутрішніх номерів унікальні)

Скорочений міжсайтовий набір з до

Примусовий внутрішній набір номера з до

Зворотний виклик з каталогу пропущених викликів на адресати

Виклики PSTN з до PSTN, якщо під час переходу локальна PSTN використовується для

Виклики PSTN від до, якщо під час переходу використовується транкінг PSTN для гібридних розгортань, щоб забезпечити доступ до PSTN локальним користувачам через Cloud Connect для

Примусово підключено до мережі з до

Набір додаткового номера з до (міжсайтовий).

Якщо будь-який із перелічених вище способів набору не підтримувався до переходу, наприклад, якщо не існує скороченого способу міжсайтового набору, то їх не обов'язково впроваджувати під час переходу.

На рисунку Найкращі практики плану набору показано найкращий підхід до плану набору, як описано в Переважній архітектурі для локальних розгортань Cisco Collaboration 12.x Enterprise, CVD. Ключові характеристики цього підходу включають:

Один розділ для +E.164 номери телефонних книг

Основна маршрутизація на основі +E.164 схеми маршрутів

Нормалізація всіх звичок набору номерів +E.164 використання шаблонів перекладу

Використання успадкування простору пошуку викликів шаблонів перетворення (опція Використовувати простір пошуку викликів ініціатора встановлена для шаблонів перетворення).

Найкращі практики плану набору номера

Наприклад, набір PSTN (9+1+10D) з пристрою в SJC, наданого простором пошуку лінійних викликів , SJCInternational спочатку знайде збіг з 9.1[2-9]XX[2-9]XXXXXX шаблон перекладу, який нормалізує номер абонента, що викликається, до +E.164. Вторинний пошук потім використовує той самий виклик простору пошуку SJCInternational знову (виклик успадкування простору пошуку) та +E.164-digit рядок буде або знайдено збіг з +E.164 номер каталогу в розділі DN або за одним із шаблонів маршрутизації PSTN у розділі USPSTNNational або SJCPSTNNocal. Скорочені внутрішньосайтові та міжсайтові зв'язки з клієнтами реалізуються за допомогою перетворень у розділах ESN та SJCtoE164. Хоча розділ ESN є глобальним розділом (доступним для телефонів у всіх місцях розташування), розділ SJCTOE164 доступний лише для користувачів у місці розташування SJC. Це за умови перекриття діапазонів розширень.

Перший крок для активації викликів з до — переконатися, що +E.164 пункти призначення маршрутизуються відповідно. Цього можна досягти, додавши розділ до плану набору, +E.164 шаблони маршрутів для всіх пунктів призначення до цього розділу, і, нарешті, додавання розділу до всіх викликаючих просторів пошуку, що представляють класи обслуговування, які повинні мати можливість досягти . Створення виділеного розділу необхідне для того, щоб забезпечити створення диференційованого класу обслуговування для викликів, що надходять з . Щоб уникнути зациклення викликів, простір пошуку вхідних викликів на магістралі від локального шлюзу не повинен мати доступу до розділу.

+E.164 маршрутизація до Webex Calling

Як показано на рисунку +E.164 маршрутизація до Webex Calling, щоб увімкнути маршрутизацію з до для місця з +E.164 Діапазон DID +1 221 555 2XXX та код сайту 121, терміновий маршрут, що відповідає цьому +E.164 діапазон потрібно додати до розділу .

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

Щоб увімкнути скорочений набір між сайтами, до розділу додається необхідний шаблон маршруту 8121.2XXX. Для сайтів, які потрібно перевести на шаблон нормалізації набору 8121.2XXX, який нормалізує набір ESN до +E.164 можливо, вже існує в розділі ESN. У такому випадку 8121.2XXX здається надлишковим, але щойно всі DN відповідного розташування будуть перенесені на 8121.2XXX, шаблон нормалізації набору можна видалити, і тоді шаблон маршруту 8121.2XXX дозволить набір ESN навіть для користувачів лише з розширенням у цьому діапазоні.

Завдяки цим змінам плану набору дзвінки до місця розташування можна здійснювати не лише за допомогою скороченого міжсайтового набору, а й +E.164. Також можливий міжнародний та національний набір номерів PSTN, оскільки ці звички набору спочатку нормалізуються +E.164 через уже існуючі шаблони перетворення нормалізації набору, а потім маршрутизуватися до шляхом зіставлення +E.164 шаблон маршруту в розділі.

The +E.164 Зіставлення шаблонів маршрутів у діапазоні DID розташування може бути налаштоване, поки всі DID все ще розміщені на . Алгоритм зіставлення шаблонів найкращого збігу гарантує, що коли набирається номер, розміщений на +E.164 номер каталогу, наданий для, краще відповідає шаблону підстановки +E.164 шаблон маршруту, що вказує на , щоб виклики поширювалися на лінію на , а не надсилалися на .

план набору номера

Кожному користувачеві надається розширення and/or а +E.164 номер телефону. Довжина розширення є фіксованим глобальним параметром: Усі розширення в розгортанні мають однакову довжину. Додатковий набір номерів може використовуватися між користувачами як у межах одного розташування, так і між розташуваннями. Скорочений міжсайтовий набір внутрішнього номера (останній випадок) працює лише за умови, що набраний внутрішній номер унікальний.

Якщо скорочений міжсайтовий набір номерів є обов'язковим, але є дублювання між внутрішніми номерами, призначеними в різних місцях, тоді необхідно створити специфічний для підприємства план нумерації, додавши перед внутрішніми номерами код доступу (код сайту). Для отримання додаткової інформації див. Бажана архітектура для локальних розгортань Cisco Collaboration 15, огляд дизайну, доступна за адресою Бажані архітектури Cisco Collaboration.

Довжина додаткового номера, поведінка набору міжлокаційних додаткових номерів, довжина префікса для міжлокаційного набору та керуюча цифра в префіксі маршрутизації для міжлокаційного набору налаштовуються в налаштуваннях служби викликів у :

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

Керівна цифра в префіксі маршрутизації: Керівна цифра для скороченого набору номерів між підприємствами. Слід уникати перекриття першої цифри будь-якого місцезнаходження та цифр вихідного набору місцезнаходження. Потрібно лише якщо план нумерації підприємства потрібно встановити як альтернативний скорочений міжлокаційний набір номерів підприємства.

Довжина внутрішнього подовження: Стандартна довжина подовжувачів. Може бути будь-яким значенням від двох до десяти.
Якщо від локального елемента керування викликами до потрібен набір додаткового номера або набір номера з використанням корпоративних значущих номерів (код керування, код сайту, додатковий номер), і локальний елемент керування викликами надсилає додатковий номер як ідентифікатор абонента, обов’язково також установіть параметр Максимальна довжина невідомого додаткового номера у розділі Маршрутизація викликів між приміщеннями, щоб переконатися, що виклики, що надходять від локального елемента керування викликами до, можна правильно класифікувати як локальні виклики.

Дозволити набір додаткових номерів між розташуваннями: Переключити на enable/disable набір додаткового номера між локаціями. Цю опцію слід увімкнути, лише якщо всі розширення в організації є унікальними. Якщо цю опцію вимкнено, то між локаціями потрібно набирати важливі для підприємства номери (код керування, код сайту, додатковий номер) або номери телефонів.

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

У таблиці Приклад нумерації підприємств наведено приклад трьох локацій, де діапазони розширення двох локацій, NYC та RTP, ідентичні. Встановлення схеми нумерації підприємства з міжсайтовою керуючою цифрою 8, за якою йде тризначний код сайту та чотиризначне розширення, створює скорочену міжсайтову звичку набору номерів без перекриття.

Таблиця 2. Приклад нумерації підприємства
Вебсайт Діапазон розширення Код сайту Діапазон підприємств

Нью-Йорк 2XXX 202 8 202 2XXX

СФО 3XXX 203 8 203 3XXX

РТП 2XXX 204 8 204 2XXX

Для забезпечення плавного переходу набір номерів для користувачів до та після переходу в ідеалі має бути однаковим. Для підготовки до переходу для кожного місця розташування необхідно задокументувати діапазони DID та діапазони додаткових номерів (або скорочені звички набору номерів всередині місця розташування). На основі цієї інформації потрібно вибрати міжсайтову керівну цифру.

У таблиці Діапазони подовження з фіксованою довжиною наведено приклад трьох місць розташування та діапазонів подовження з фіксованою довжиною. Оскільки слід уникати дублювання звичок набору, важливо переконатися, що для будь-якого діапазону додаткового номера перша цифра діапазону не збігається з керуючою цифрою для скороченого міжвузлового набору. Якщо, наприклад, 8 вибрано як керівну цифру для міжсайтового набору, то жоден діапазон додаткових номерів на жодному сайті не може починатися з 8. Зазвичай, розширення в певному місці збігаються з останніми кількома цифрами DID, призначених цьому місцю. Щоб уникнути конфліктів, першу цифру розширення можна змінити. Якщо, наприклад, DID у +1 Якщо в певному місці використовується діапазон 408 555 8XXX, то замість використання 8XXX як діапазону розширення для розширень на цьому сайті можна використовувати 7XXX.

Таблиця 3. Діапазони подовження з фіксованою довжиною
Вебсайт Діапазон розширення Внутрішні номери Код сайту Діапазон підприємств

Нью-Йорк 2XXX 2XXX 202 8 202 2XXX

СФО 8XXX 7XXX 203 8 203 7XXX

РТП 1XX 11XX 204 8 204 11XX

Семизначні рядки набору, набрані на пристрої з використанням абонентського плану США, перетинаються із семизначним шаблоном для місцевого набору в попередньо завантаженому абонентському плані США. Щоб уникнути дублювання між будь-якими звичками набору номерів у мережі та поза мережею (PSTN), у цьому місці можна використовувати обов'язковий зовнішній код доступу. Якщо існуюча схема нумерації підприємства та відповідний скорочений міжвузловий набір перетинаються зі шаблонами в національному наборі, то під час переходу на схему нумерації, щоб уникнути перетинів, їх також можна змінити на довшу або коротшу форму. Найпростіший спосіб досягти цього – додати додаткову цифру до схеми нумерації. Нову довшу схему міжсайтового набору номера потрібно впровадити лише тим користувачам, які вже перейшли на . Користувачі, які все ще в мережі, можуть продовжувати набирати семизначний номер. У цьому випадку корпоративний абонентський план має забезпечити перетворення скороченого семизначного набору з Unified CM на +E.164 або до скороченого формату набору, розгорнутого на . Це потрібно зробити перед надсиланням виклику до локального шлюзу.

У таблиці «Перехід до семизначного набору номера » наведено приклад такої перенумерації. У цьому прикладі для скороченого міжсайтового набору використовується керуюча цифра 8, за якою слідують двозначний код вузла та чотиризначний додатковий номер. Щоб уникнути скороченого семизначного міжсайтового набору для локацій на , коди сайтів можна легко змінити на тризначні, додавши довільну цифру-доповнення (8 у прикладі) до двозначних кодів сайтів, що використовуються в , щоб міжсайтовий набір з телефонів використовував керуючу цифру 8, а потім цифру-доповнення 8, старий двозначний код сайту та чотиризначне розширення. Користувачам на не потрібно запам'ятовувати нові коди сайтів; їм лише потрібно пам'ятати, що для міжсайтового набору потрібно використовувати 88 як префікс замість 8 на .

Таблиця 4. Перехід на семизначний набір

Вебсайт Внутрішні номери Код сайту Діапазон підприємств Ода сайту Підприємницький анге

Нью-Йорк 2XXX 22 8 22 2XXX 822 8 822 2XXX

СФО 8XXX 23 8 23 7XXX 823 8 823 7XXX

РТП 1XXX 24 8 24 11XX 824 8 824 11XX

У сценарії з різними форматами номерів підприємства, і якщо номери підприємств відображаються як інформація про абонента для дзвінків від до (наприклад, дзвінки з пристроїв без DID), важливо також реалізувати зіставлення між різними форматами номерів для інформації про абонента, щоб забезпечити роботу зворотного виклику. Цього зіставлення можна досягти, використовуючи шаблон перетворення абонента на магістральній лінії між й локальним шлюзом.

Запис

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

1. Вибір постачальника послуг запису дзвінків

Вибір відповідного постачальника послуг запису дзвінків є основоположним для досягнення бізнес-цілей та забезпечення узгодженості функцій по всій організації:

Вибір глобального постачальника: Організації зазвичай призначають основного постачальника послуг запису дзвінків на глобальному рівні, забезпечуючи узгодженість набору функцій, відповідності вимогам та підтримки на всіх локаціях.

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

Вимоги бізнесу: Вибір постачальника має бути зумовлений оцінкою бізнес-факторів, таких як дотримання нормативних вимог (наприклад, MiFID II, HIPAA), забезпечення якості, вирішення спорів або потреби в навчанні.

Доступність функцій: Постачальників слід оцінювати на основі їхньої здатності надавати необхідні функції, такі як моніторинг у режимі реального часу, можливості пошуку та відтворення, шифрування, політики зберігання, інтеграція з аналітичними платформами та підтримка різних типів дзвінків (вхідних, вихідних, внутрішніх).

2. Вибір регіону

Визначення регіону, де зберігаються та обробляються записи дзвінків, має вирішальне значення для дотримання вимог та продуктивності:

Вибір глобального регіону: За замовчуванням організації можуть вибрати один регіон для зберігання записів дзвінків, щоб спростити управління та контроль.

Заміщення регіонів на основі місцезнаходження: Якщо цього вимагають закони про місцезнаходження даних або корпоративні політики, може знадобитися змінити налаштування глобального регіону для певних місць розташування, забезпечуючи зберігання та обробку записів дзвінків у необхідних географічних межах.

Вимоги до місця зберігання даних: Дизайн має враховувати міжнародні та місцеві правила захисту даних (такі як GDPR, CCPA або вимоги конкретної країни), які можуть диктувати, де і як зберігатимуться записи дзвінків.

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

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

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

Середня тривалість дзвінка: Розрахуйте типову тривалість записаних дзвінків, оскільки довші дзвінки споживатимуть більше місця для зберігання. Варіації тривалості дзвінків між різними відділами або групами користувачів також слід враховувати в оцінці

Період збереження: Визначте термін зберігання записів, який часто визначається політикою організації або зовнішніми нормативними актами (наприклад, галузевими стандартами відповідності). Довші періоди зберігання збільшать загальні вимоги до зберігання

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

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

Екстрені виклики

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

Існує два способи здійснення екстрених викликів у . Існує базова послуга маршрутизації екстрених викликів та розширена послуга маршрутизації екстрених викликів. Базова служба маршрутизації екстрених викликів використовуватиме номер, обраний адміністратором, для визначення місцезнаходження та маршруту виклику для зв’язку з екстреними службами. Для базових екстрених викликів шлях виклику зазвичай здійснюється через PSTN клієнта для цього місцезнаходження. Також передбачено розширену маршрутизацію екстрених викликів, розроблену для розгортань у США та Канаді, де діють вимоги до дотримання нормативних вимог, що вимагають використання загальнонаціонального постачальника послуг для доставки екстрених викликів до відповідного диспетчерського центру.

Усім клієнтам слід розгорнути, як мінімум, базову конфігурацію екстрених викликів. Для базових екстрених викликів потрібен принаймні один клієнт +E.164 кожному місцю, визначеному в . Для базових екстрених викликів кожне місце буде визначено адресою вулиці, за якою у разі надзвичайної ситуації направляються поліцейські, пожежні або швидкі служби. У більшості випадків основний номер для розташування є найкращим вибором для позначення фізичного місця надзвичайної ситуації. Зазвичай, призначення адреси +E.164 Номер узгоджується з постачальником PSTN. На зображеннях нижче показано призначення основного номера, який буде використовуватися як номер екстреного зворотного виклику для відділення Річардсон.

Конфігурація ECBN розташування

У більшості випадків адреси будівлі достатньо для адреси відправлення. Але якщо для певних користувачів або пристроїв потрібні додаткові відомості про місцезнаходження, адміністратор може скористатися тим самим процесом, що описаний вище, і призначити ці пристрої певній адресі або точнішому розташуванню в межах адреси (наприклад, поверху або кімнати). У розділі Керування користувачами вкладка Виклики дозволяє використовувати певний номер для користувача та його пристроїв для отримання конкретної адреси відправлення. На наступних зображеннях показано, як пристрою можна призначити певний номер. Адміністратор відповідає за те, щоб номеру, який використовується пристроєм, було призначено правильну адресу відправлення. Призначення адреси зазвичай здійснюється через постачальника PSTN цього місця розташування.

Конфігурація ECBN користувача

Для розгортання телефонії в США, яка повинна забезпечувати розширені рішення для екстрених викликів, використовується інтегрована система RedSky Horizon Mobility для маршрутизації екстрених викликів. Під час використання RedSky для маршрутизації викликів адміністратор повинен зареєструвати обліковий запис через Cisco та налаштувати відповідну інформацію в розділі Виклики -> Налаштування служби, щоб увімкнути цю функцію. Після ввімкнення служби RedSky на системному рівні адміністратор увімкне службу RedSky на кожному рівні розташування. Увімкнення розширених екстрених викликів у певному місці активує послугу для всіх пристроїв, призначених цьому місцю. Пристроями, що підтримують розширені екстрені виклики, є телефони Cisco MPP, телефони Cisco PhoneOS та телефони Cisco.

Існує два налаштування для ввімкнення розширених екстрених викликів у певному місці. Для перевірки правильності конфігурації RedSky для зіставлення пристроїв та інфраструктури слід використовувати параметр Дозволити RedSky отримувати інформацію про мережеве підключення та тестові виклики. Цей параметр також дозволяє здійснювати тестові дзвінки на номер 933 для перевірки місцезнаходження за допомогою системи IVR RedSky, яка зчитує місцезнаходження абонента. Хоча цей документ не охоплює налаштування RedSky для відстеження місцезнаходження, адміністратору ЗАВЖДИ слід перевіряти своє визначення місцезнаходження, перш ніж активувати екстрені виклики для маршрутизації до RedSky. Після завершення тестування та підтвердження його точності адміністратор перенаправлятиме дзвінки до RedSky, перемикаючи маршрутизацію екстрених дзвінків до RedSky. Цей перемикач перенаправлятиме всі екстрені виклики для цього місця до RedSky для доставки до центру прийому викликів для цього місця.

Параметри розширених екстрених викликів також застосовуються до клієнтів як локально, так і поза межами офісу. У локальному режимі їх можна відстежувати так само, як і стаціонарні телефони. Перебуваючи поза межами приміщення, користувач зможе динамічно встановлювати своє місцезнаходження безпосередньо в . Щоб отримати докладнішу інформацію про екстрені виклики, див. Розширені екстрені виклики для .

Ліцензування

Існує кілька варіантів призначення ліцензій користувачам.

Ручне призначення через

Адміністратори вручну призначають ліцензії окремим користувачам через інтерфейс.

Адміністратори можуть редагувати ліцензії на послуги для окремих користувачів і призначати ліцензії на виклики безпосередньо.

Шаблони автоматичного призначення ліцензій

Використовуйте шаблони призначення ліцензій, щоб автоматично призначати ліцензії користувачам на основі групових або організаційних налаштувань.

Автоматичне ліцензування можна виконати шляхом синхронізації каталогів або ручного оновлення користувачів, але користувачі повинні мати дійсний +E.164 відформатований номер телефону, і номери телефонів повинні існувати в певному місці до налаштування користувача. Якщо умови не виконано (наприклад, недійсний формат номера телефону), ліцензії не будуть призначені.

Масове призначення через шаблон CSV

Завантажте CSV-файл із даними користувача та призначенням ліцензій, щоб додати або змінити кількох користувачів одночасно.

Імпорт CSV-файлу підтримує додавання до 20 000 користувачів та призначення ліцензій, але для ліцензій потрібні певні поля, такі як номер телефону та додатковий номер.

Призначення на основі API

Використовуйте API для програмного призначення ліцензій та керування користувачами.

підтримує операції API для керування користувачами та ліцензіями (People, SCIM 2.0 та Licenses API), які можна використовувати для автоматизації призначення ліцензій. API ліцензій дозволяє одночасне призначення ліцензій, номерів телефонів та додаткових номерів.
Таблиця 5. Параметри налаштування користувачів – короткий виклад
Метод призначення Плюси Мінуси
Ручний через Простий для небагатьох користувачів.
Дозволяє точний та детальний контроль над призначенням ліцензій.
Не масштабується, трудомісткий
Схильний до людських помилок під час ручного введення.

Шаблони автоматичних ліцензій Масштабований
Зменшує кількість помилок ручного керування
Можна застосовувати до нових та існуючих користувачів.
Потрібні дійсні номери телефонів та місцезнаходження.
Складніший у налаштуванні
Також потрібні групи користувачів для кожної групи користувачів з еквівалентними ліцензійними вимогами.

Масове завантаження CSV-файлу Ефективний для великих груп користувачів
Дозволяє одночасне призначення ліцензій, номерів телефонів та додаткових номерів.
Потрібне ретельне форматування CSV
Можливі помилки, якщо номери телефонів або додаткові номери відсутні або неправильні.
Призначення на основі API Автоматизований, гнучкий.
Дозволяє одночасне призначення ліцензій, номерів телефонів та додаткових номерів.
Потрібна розробка та знання API.

У таблиці Варіанти надання користувачам – короткий огляд підсумовано варіанти надання користувачам, а також їхні переваги та недоліки. Цей огляд допомагає вибрати найкращий метод призначення ліцензій на основі розміру організації клієнта, можливостей автоматизації, а також процесів і вимог до забезпечення користувачів.

За можливості, Cisco рекомендує призначати ліцензії на дзвінки за допомогою шаблонів ліцензій. Це вимагає, щоб для кожної групи користувачів, якій потрібен унікальний набір ліцензій (наприклад, Стандартний або Професійний), існувала група з відповідним членством у групах. Як обговорювалося в розділах Групи користувачів, групи користувачів можна визначити вручну в корпоративному каталозі або синхронізувати з нього. Можливе поєднання обох підходів.

Користувачі, що належать до кількох груп, отримують ліцензії з усіх призначень, застосованих до всіх їхніх груп. Це дозволяє використовувати групи безпеки для окремих ліцензій у каталозі підприємства для керування призначенням ліцензій, де результуюче призначення ліцензій користувача контролюється об'єднанням членів груп.

Для отримання додаткової інформації див. Налаштування автоматичного призначення ліцензій у Control Hub та Налаштування шаблонів автоматичного призначення ліцензій для користувачів Webex Calling.

Вимоги до ліцензії

Цей розділ охоплює лише пов'язані ліцензії. Інші типи ліцензій (наприклад, реєстрація пристроїв Webex, обмін повідомленнями, зустрічі) не охоплюються. В рамках процесу проектування необхідно визначити вимоги до ліцензії. Необхідно розрахувати кількість ліцензій для таких типів ліцензій:

Стандартний: кількість окремих користувачів, яким потрібні стандартні функції телефонії.

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

Робочий простір для спільної зони: кількість місць спільного користування або місць загального користування, що потребують стандартних можливостей виклику.

Допомога клієнтам: кількість агентів та керівників, яким потрібні функції Customer Assist. Підтримка клієнтів включає професійну ліцензію.

Виклики зі списку маршрутів: кількість необхідних дзвінків через хмарну PSTN-мережу між локальними користувачами and/or локальні спеціалізовані сторонні програми.

Консоль оператора: кількість користувачів, яким потрібен доступ до клієнта консолі оператора.

Тарифний план Cisco (тарифний план вихідних дзвінків): кількість користувачів, яким потрібен номер PSTN and/or Доступ до вихідних викликів PSTN для служби Cisco PSTN.

Для професійних робочих просторів немає окремого типу ліцензії. Професійні робочі простори використовують професійну ліцензію.

Робочі простори лише з гарячим робочим місцем пропонують послугу хоста гарячого робочого місця та екстрені виклики від хоста гарячого робочого місця та не потребують жодної ліцензії. Для отримання додаткової інформації див. Додавання та керування пристроями лише для гарячих столів.

Щоб визначити необхідний тип ліцензії для кожного користувача та робочої області на основі необхідних функцій, див. Функції, доступні за типом ліцензії для Webex Calling.

Щоб розрізнити функціональність, що пропонується чергами викликів у поєднанні з професійною ліцензією, та функцію підтримки клієнтів, див. Порівняння функцій черги викликів Webex Calling та служби підтримки клієнтів.

Підготовка користувачів

Під час надання користувачів у Webex доступні кілька варіантів, кожен з яких підходить для різних потреб та середовищ організації:

Ручне налаштування: Адміністратори можуть додавати та керувати окремими користувачами безпосередньо в . Цей метод простий, але найкраще підходить для невеликих організацій або обмежених змін, внесених користувачами.

Масове налаштування через CSV: Для більших баз користувачів адміністратори можуть імпортувати та оновлювати дані користувачів масово, завантажуючи CSV-файли у формат . Це дозволяє ефективно керувати одночасно тисячами користувачів.

Параметри синхронізації каталогів:
З’єднувач каталогу: Це інструмент автоматичної синхронізації, який використовується в середовищах Microsoft Active Directory. Він синхронізує облікові записи користувачів, групи та атрибути за розкладом (щогодинно, щодня або щотижня). Він підтримує багатодоменні та багатолістові налаштування Active Directory, а також може синхронізувати зображення профілів та об'єкти кімнат.

Майстер Entra ID (Azure AD): Розроблений для організацій, що використовують Microsoft Entra ID (Azure AD), цей метод забезпечує автоматичну синхронізацію облікових записів користувачів та атрибутів майже в режимі реального часу безпосередньо з Entra ID до . Він повністю керований зсередини та вимагає мінімального налаштування.

Застосування SCIM 2.0: Для середовищ, відмінних від Microsoft, або інших постачальників ідентифікаційних даних, таких як Okta або Duo, програми синхронізації на основі SCIM дозволяють автоматично надавати та скасувати надання користувачам доступ до них за допомогою зіставлення атрибутів та синхронізації груп.

Синхронізація користувачів Unified CM: Ця опція дозволяє створювати облікові записи користувачів на основі існуючих кінцевих користувачів шляхом синхронізації з . Для цього потрібно, щоб Cloud Connected UC (CCUC) працював на локальних кластерах. Однак, зазвичай рекомендується синхронізувати користувачів із централізованого хмарного каталогу, такого як Entra ID, а не безпосередньо з .

Надання API: Для надання доступу користувачам можна використовувати публічні API (People, SCIM 2.0). Головною перевагою використання API є можливість інтеграції системи надання користувачів з іншими корпоративними системами.
Таблиця 6. Параметри налаштування користувачів для
Метод забезпечення Опис Плюси Мінуси
Вручну Create/manage користувачів окремо в Простий для невеликої кількості користувачів; не потрібна інфраструктура Не масштабується; займає багато часу для багатьох користувачів
Масово (CSV-файл) Import/update користувачів масово через CSV у Ефективно для груп; кодування не потрібне Ручна підготовка CSV; менш динамічний
Люди та SCIM 2.0 API Програмне керування користувачами через API Webex Гнучкий; підтримує автоматизацію та інтеграцію Потребує розвитку та інфраструктури
Синхронізація каталогів Автоматична синхронізація з AD, Entra ID, додатків SCIM, Unified CM Автоматизує життєвий цикл; підтримує фільтрацію та зіставлення Складність налаштування: деякі опції мають обмежені функції або вимагають інфраструктури
У цьому огляді та таблиці відображено основні варіанти надання доступу користувачам, їхні переваги та обмеження, щоб допомогти вам вибрати найкращий підхід для потреб вашої організації.

Групи користувачів

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

Керування групами користувачів пропонує кілька переваг, зокрема:

Спрощене адміністрування: Керуйте ліцензіями, налаштуваннями та політиками для кількох користувачів одночасно.

Узгодженість: Застосовуйте однакові налаштування та ліцензії для всіх користувачів в одній групі.

Масштабованість: Підтримує до 250 000 учасників на групу.

Інтеграція: Синхронізуйте групи з Microsoft Entra ID (Azure AD) або Active Directory для автоматизованого керування користувачами та групами.

Гнучкість: Створюйте локальні групи або синхронізуйте групи безпеки; керуйте членством у групах вручну або через CSV-файли.

Розподіл ресурсів: Контролюйте доступ до вбудованих програм і служб на основі членства в групах.

Основні варіанти використання груп користувачів під час налаштування:

Призначення ліцензій: Призначте ліцензії групам, щоб автоматично надавати учасникам групи такі послуги, як виклики, зустрічі, обмін повідомленнями або гібридні послуги.

Шаблони налаштувань: Застосовуйте колекції налаштувань послуг (наприклад, обмін повідомленнями, зустрічі, дзвінки) до груп для узгодженого користувацького досвіду.

Масове керування користувачами: Додавайте або видаляйте користувачів масово за допомогою CSV-файлів або синхронізації каталогів.

Автоматизація та інтеграція: Використовуйте API або синхронізацію каталогів для автоматизованого керування життєвим циклом користувачів і груп.

У наступній таблиці підсумовано різні опції керування групами користувачів та управління групами в .
Таблиця 7. Варіанти керування групами та членством у групах
Параметр Опис Плюси Мінуси

групове забезпечення (групи) Створюйте та керуйте групами безпосередньо в . Add/remove учасників вручну або через CSV. Повний контроль над членством у групі
Негайне застосування ліцензій та шаблонів
Легко створювати та редагувати групи Потрібні оновлення вручну
Ризик помилок під час ручного завантаження CSV-файлів
Немає автоматичної синхронізації із зовнішніми каталогами

Синхронізовані групи з Entra ID (Azure AD) або Active Directory Автоматично синхронізувати групи безпеки та членство із зовнішніх служб каталогів. Автоматизована синхронізація зменшує ручну роботу
Забезпечує узгодженість з корпоративним каталогом
Підтримує великі організації
Неможливо редагувати членство в групі
Затримка синхронізації до 12 годин
Вкладені групи потребують ручного вибору

Групи та SCIM 2.0 API (Групи) Використовуйте групи або SCIM 2.0 API для програмного керування групами та членством Автоматизація та інтеграція з іншими системами
Масштабований для великих або складних середовищ
Вимагає зусиль розвитку
Складність залежить від використання API

Хоча синхронізовані групи забезпечують узгодженість і пропонують єдину точку адміністрування, можливий гібридний підхід, що поєднує синхронізовані групи та групи (керовані в центрі керування або через API). Отже, наприклад, групи для призначення ліцензій можуть бути синхронізованими групами, а окремий набір груп може використовуватися для призначення шаблонів користувачів та викликів.

Такий комплексний підхід до управління групами користувачів дозволяє організаціям ефективно керувати ліцензіями, налаштуваннями та політиками користувачів, забезпечуючи узгоджений та масштабований досвід співпраці.

Рекомендований підхід під час міграції з до

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

Cisco рекомендує використовувати централізований хмарний каталог, такий як Microsoft Entra ID (Azure AD), як єдине джерело достовірної інформації про ідентифікацію користувачів. Синхронізація користувачів з Entra ID забезпечує узгодженість, спрощує керування та підтримує можливості єдиного входу (SSO).

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

Підсумовуючи, рекомендований метод підготовки полягає в синхронізації користувачів з Microsoft Entra ID (Azure AD) до Webex за допомогою майстра Azure AD або програм SCIM. Ручне та масове налаштування у форматі CSV доступні як додаткові методи, але вони менш масштабовані та більш схильні до помилок для великих організацій. Забезпечення того, що Entra ID є авторитетним джерелом, а всі користувачі присутні в Entra ID, є критично важливим для успішної міграції та узгодженого користувацького досвіду в різних середовищах.

Перехід з локальної служби каталогів, такої як Active Directory, до хмарної служби каталогів, такої як Entra ID (Azure ID), не залежить від переходу виклику. Cisco рекомендує завершити перехід на хмарну службу каталогів, перш ніж розпочинати перехід на виклики.

Проектування груп користувачів

Після перенесення корпоративного каталогу з локального сховища до хмари зберіть необхідні групи користувачів відповідно до вимог до ліцензування та шаблонів функцій. Для кожного групового документа:

Ім’я групи: унікальна назва групи.

Ліцензії: ліцензії, що будуть призначені цій групі (якщо такі є), та обсяг (чи слід призначати ліцензії існуючим користувачам чи лише новим користувачам)

Шаблони налаштувань: Шаблони викликів для застосунку Webex та користувачів.

Синхронізація каталогів: Чи буде ця група синхронізована з каталогу підприємства, чи це локальна група Webex, налаштована в Центрі керування або через API?

Опис: як буде використовуватися ця група та які користувачі повинні бути її членами

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

Єдиний вхід (SSO)

Cisco рекомендує використовувати SSO для автентифікації користувачів. Використання SSO має деякі переконливі переваги, зокрема:

Спрощена автентифікація користувача: Користувачі можуть увійти один раз, використовуючи свої корпоративні облікові дані (наприклад, з Azure ID) для доступу до інших інтегрованих програм, що усуває потребу в кількох паролях і зменшує кількість запитів на вхід. Це підвищує безпеку, гарантуючи, що корпоративні паролі ніколи не зберігатимуться та не передаватимуться після автентифікації.

Спрощене керування користувачами: Автоматизує створення, оновлення та деактивацію облікових записів користувачів на основі змін у корпоративному каталозі, зменшуючи адміністративні витрати та забезпечуючи доступ лише авторизованим користувачам.

Покращена безпека: SSO зменшує втому паролів та ризик порушення безпеки паролів, централізуючи автентифікацію через довірених постачальників ідентифікаційних даних (IdP).

Проста інтеграція багатофакторної автентифікації (MFA): Багатофакторну автентифікацію (MFA) можна легко підтримувати або за допомогою рішення для керування доступом до ідентифікаційних даних, такого як Cisco Duo, або через підтримку MFA постачальника ідентифікаційних даних.

Існує кілька варіантів впровадження SSO для сервісів:

Єдиний вхід (SSO) на основі SAML 2.0: Основний протокол, що підтримується для інтеграції SSO, що забезпечує безпечний обмін інформацією для автентифікації між постачальником ідентифікаційних даних та постачальником послуг.

Підключення OpenID (OIDC): Підтримується як альтернативний сучасний протокол автентифікації для інтеграції SSO.

Ідентифікація Webex: Також підтримується як опція постачальника ідентифікаційних даних.

SSO налаштовується та керується централізовано через , що вимагає обміну метаданими між та обраним постачальником ідентифікаційних даних.

Після налаштування, SSO можна протестувати перед активацією, щоб переконатися в правильності налаштування.

Cisco підтримує інтеграцію з багатьма перевіреними та поширеними постачальниками ідентифікаційних даних та системами керування ідентифікацією (IAM), включаючи, але не обмежуючись:

Cisco Duo

Okta

Служби федерації Microsoft Active Directory (ADFS)

Microsoft Azure

PingFederate

OpenAM

F5 BIG-IP.

Ці постачальники ідентифікаційних даних відповідають стандартам SAML 2.0 або OpenID Connect і пройшли перевірку на сумісність із рішеннями Cisco для співпраці.

Підтримка кількох постачальників ідентифікаційних даних

дозволяє організаціям налаштовувати SSO з кількома постачальниками ідентифікаційних даних (IdP) для роботи зі складними ІТ-середовищами, такими як злиття, поглинання або децентралізовані ІТ-відділи, де різні групи використовують різні IdP. Підтримку кількох IdP можна реалізувати за допомогою функції Multiple IdP в корпоративній системі IAM, такій як Cisco Duo, або шляхом інтеграції з нею.

Підтримка кількох постачальників ідентифікаційних даних (IdP) вирішує кілька ключових випадків використання, коли організаціям потрібна гнучка та безпечна автентифікація в різних ІТ-середовищах:

1. Злиття та поглинання

Коли компанії зливаються або купують інші, вони часто мають окремі ІТ-інфраструктури та окремі постачальники ідентифікаційних даних, які не можуть об'єднатися. Підтримка кількох постачальників ідентифікаційних даних дозволяє користувачам з обох організацій безпечно проходити автентифікацію та співпрацювати без необхідності негайно об'єднувати свої системи ідентифікації.

2. Кілька незалежних ІТ-відділів

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

3. Різні групи користувачів або домени

Організації з різними групами користувачів (наприклад, співробітники проти підрядників) або кількома доменами електронної пошти можуть налаштувати правила маршрутизації для спрямування запитів на автентифікацію до відповідного постачальника ідентифікаційних даних на основі членства в домені або групі. Це підтримує диференційовані політики доступу та засоби контролю безпеки.

4. Підтримка різних протоколів автентифікації

підтримує постачальників ідентифікаційних даних SAML та OpenID Connect (OIDC), що дозволяє організаціям інтегрувати різні типи постачальників ідентифікаційних даних відповідно до їхньої існуючої інфраструктури та вимог безпеки.

5. Покращена безпека та відповідність вимогам

Завдяки активації кількох постачальників ідентифікаційних даних організації можуть впроваджувати сильніші механізми автентифікації, включаючи багатофакторну автентифікацію (MFA) через інтеграції, такі як Duo, та забезпечувати узгоджені політики безпеки для різних користувачів.

6. Спрощений користувацький інтерфейс

Користувачі можуть автентифікуватися, використовуючи свої існуючі облікові дані від відповідних постачальників ідентифікаційних даних, забезпечуючи єдиний процес входу, незважаючи на складність існування кількох систем ідентифікації.

Хоча підтримка кількох постачальників ідентифікаційних даних забезпечує гнучкість, вона вимагає ретельної координації між командами безпеки та ідентифікації для підтримки узгоджених політик безпеки та уникнення потенційних вразливостей.

Duo MFA з єдиним вхідним входом для

Duo Access Gateway (DAG) може автентифікувати користувачів за допомогою існуючих локальних або хмарних каталогів, таких як Active Directory (AD) та OpenLDAP. Він також підтримує інтеграцію з іншими постачальниками ідентифікаційних даних, такими як Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS та Shibboleth. Ця гнучкість дозволяє організаціям використовувати свою поточну інфраструктуру каталогів для єдиного входу Webex з Duo MFA.

Duo діє як надійний рівень автентифікації поверх автентифікації основного каталогу. Він функціонує як постачальник ідентифікаційних даних (IdP), використовуючи SAML 2.0 для забезпечення двофакторної автентифікації (2FA) перед наданням доступу до . Duo оцінює контекст користувача, пристрою та мережі на основі налаштовуваних політик, щоб дозволити або заборонити доступ, що підвищує безпеку, виходячи за рамки просто імені користувача та пароля. Duo також надає гнучкі правила керування, такі як вимога багатофакторної автентифікації (MFA) під час кожного входу для деяких програм і рідше для інших.

Переваги Cisco Duo включають:

Посилена безпека: Додає стійку до фішингу багатофакторну автентифікацію для захисту доступу, зменшуючи ризик від скомпрометованих паролів.

Гнучка політика: Дозволяє детально контролювати вимоги до автентифікації для кожної програми або групи користувачів.

Інтеграція з існуючими каталогами: Підтримує локальні служби Active Directory, OpenLDAP, хмарні каталоги та різних постачальників SSO, мінімізуючи зміни в інфраструктурі.

Зручність для користувача: Підтримує єдиний вхід (SSO) для зменшення втоми від пароля, дозволяючи користувачам входити один раз та безпечно отримувати доступ до кількох ресурсів.

Довірені кінцеві точки: Підтримує довіру пристроїв для клієнтів у Windows та macOS, покращуючи рівень безпеки.

Реєстрація в самообслуговуванні: Вбудована реєстрація та запит Duo покращують взаємодію з користувачем під час налаштування MFA.

Duo MFA з SSO використовує існуючі каталоги, такі як Active Directory та OpenLDAP, або хмарні постачальники ідентифікації, для автентифікації користувачів. Роль Duo полягає в забезпеченні надійного, керованого політиками другого фактора автентифікації, інтегрованого через SAML 2.0, підвищуючи безпеку, зберігаючи при цьому зручність для користувачів завдяки єдиному входу (SSO). Переваги включають покращений рівень безпеки, гнучке застосування політик, безперебійну інтеграцію та кращий користувацький досвід.

Cisco рекомендує впроваджувати SSO для користувачів. Для покращеної інтеграції безпеки рекомендується використовувати Cisco Duo.

Стратегію Enterprise IAM та SSO слід розгорнути перед початком переходу з .

Функції

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

Функції корпоративного рівня Webex Calling

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

Основні функції Webex Calling

Автосекретар

Автосекретар дозволяє 24/7 автоматизація обробки вхідних дзвінків, що дозволяє ефективно обробляти дзвінки без необхідності відповіді на кожен дзвінок.

Автосекретар відповідає на вхідні дзвінки та надає абоненту меню з варіантами маршрутизації дзвінка. Це може бути виклик для особи, голосової пошти або служби викликів (наприклад, черги викликів). Абонент використовує клавіатуру свого телефону, щоб ввести номер з меню автосекретаря.

Автосекретар підтримує такі ключові функції:

Робочий графік та графік після робочого часу

Розклад свят

Опція меню набору номера, щоб спрямувати ваших клієнтів туди, куди їм потрібно дістатися

Налаштувати привітання

Опція набору номера за іменем

Параметри переадресації викликів

Аналітика та звіти Центру керування.

Для отримання додаткової інформації див. Керування автосекретарями.

Паркування викликів

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

Існує два типи парків викликів, доступних у :

Пряма парковка виклику – дозволяє будь-якому користувачеві паркувати виклик на додатковий номер іншого користувача або на додатковий номер для паркування виклику, визначений адміністратором

Група паркування викликів – дозволяє визначеній групі користувачів автоматично паркувати виклики за доступними адресатами паркування, визначеними для групи. Ці адресати можуть бути внутрішніми номерами учасників групи або внутрішніми номерами паркування викликів.

Залежно від конфігурації та типу паркування, користувачі можуть отримувати дзвінки, набираючи *88+><extension of parked call>, натискаючи клавішу лінії, пов’язану з внутрішнім номером паркування виклику, або використовуючи програмну клавішу на своєму IP-телефоні.

Доступна опція відкликання, яка дозволяє відкликати запаркований виклик після певного періоду часу користувачеві, який його запаркував, або іншому користувачеві.

Для отримання додаткової інформації див. Керування паркуванням викликів у Control Hub.

Підхоплення викликів

Перехоплення виклику дозволяє адміністратору визначити групу користувачів (учасників), які можуть відповідати на виклик на телефон іншого учасника. Це дає користувачеві можливість відповідати на дзвінки, коли його колеги зайняті та не можуть відповісти на вхідний дзвінок.

Користувачі в групі повинні знаходитися в одному місці.

Користувачі можуть використовувати або свій стаціонарний телефон, щоб відповісти на дзвінок.

:

Підтримує візуальні та звукові сповіщення

Сповіщення про вхідний виклик

на основі FAC (циферблат *98) або тост сповіщення про перехоплення дзвінка

Сповіщення про перехоплення виклику для багатоканального зв'язку.

Стаціонарні телефони:

Сповіщення про вхідний виклик

Звукові сигнали та візуальне сповіщення через світлодіодний індикатор на телефоні. 6821 підтримує лише звукові сигнали дзвінка

Якщо вибраний тип сповіщення не є жодного

Сповіщення про перехоплення викликів лише для основних ліній.

Для отримання додаткової інформації див. Налаштування групи перехоплення викликів.

Черга викликів

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

Заклик Cisco до інтеграції Microsoft Teams дозволяє агентам отримувати доступ до черги викликів та функцій безпосередньо з клієнта Microsoft Teams.

Черги викликів підтримують такі ключові функції:

Привітання та повідомлення (ласкаво просимо, заспокоєння, шепіт тощо)

Призупинити музику

Зворотній виклик

Політики маршрутизації черг (нічний сервіс, свята, переадресація)

Черга агента login/logout

Керування статусом черги агентів

або підтримка стаціонарного телефону

Моніторинг виклику агента супервайзера, коучинг, втручання або перехоплення керування за допомогою кодів доступу до функцій (FAC)

(доступ адміністратора) для:

управління чергою

Аналітика та звітність агентів і черг

Управління чергою, агентом та супервайзером.

Для отримання додаткової інформації див. Налаштування черги викликів.

має додаткову функцію Customer Assist, яка надає додаткові можливості черги викликів і покращує взаємодію з операторами та керівниками. Порівняння функцій черги викликів та допомоги клієнтам див. у статті Порівняння функцій черги викликів та допомоги клієнтам Webex Calling.

Група пошуку

Групи пошуку дозволяють маршрутизувати вхідні дзвінки певній групі користувачів за заздалегідь визначеним шаблоном маршрутизації дзвінків. Це гарантує, що на дзвінки відповість потрібна група користувачів або вони будуть перенаправлені на голосову пошту для подальшого зв'язку.

Одна велика відмінність між групами пошуку та чергами викликів полягає в тому, що в групах пошуку виклики не ставляться в чергу, тому, якщо в групі пошуку немає користувачів, які можуть відповісти на виклик, він буде роз’єднаний, переданий на голосову пошту або переадресований на інший номер (користувача чи службу).

Для отримання додаткової інформації див. Керування групами пошуку в Control Hub.

Режими роботи

Функція «Режими роботи» дозволяє компаніям ефективно направляти дзвінки різним адресатам (користувачам, голосовій пошті, службам викликів, таким як черга викликів). Куди і коли маршрутизується виклик, визначається на основі розкладу часу доби та дня тижня, і будь-який користувач може бути уповноважений керувати цими режимами (розкладами) для контролю змін у маршрутизації викликів.

Наприклад, дзвінки до черги викликів можуть бути перенаправлені до іншої черги викликів з агентами в іншому часовому поясі для відповіді на дзвінки після робочого часу, у робочий час – місцевим агентам, а у святкові дні – на голосову пошту для подальшого зв’язку після повернення агентів до офісу.

Авторизований користувач може перемикатися між цими різними сценаріями (режимами) переадресації викликів, якщо йому потрібно змінити, куди спрямовуються вхідні виклики протягом певного періоду. Ці користувачі можуть керувати режимами через свої 6800/7800/8800 Телефони MPP, телефони 9800 або в Центрі користувача за адресою Керування режимами.

Для отримання додаткової інформації див. Маршрутизація викликів на основі режимів роботи у Webex Calling.

Пейджингова група

Групи пейджингу дозволяють користувачам здійснювати односторонній дзвінок, щоб надсилати аудіоповідомлення групі користувачів. Кожна група може містити до 75 цільових користувачів and/or робочі місця, до яких можна дістатися, набравши заздалегідь визначений номер або додатковий номер.

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

Для отримання додаткової інформації див. Налаштування групи пейджингу в Control Hub.

Записи

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

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

Щоб отримати додаткові відомості про цю функцію та список записів третіх сторін, див. Керування записом викликів для Webex Calling.

Єдиний номер

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

Щоб отримати додаткові відомості про цю функцію та про те, як адміністратор її налаштовує в , див. Налаштування охоплення за одним номером (офіс будь-де).

Щоб отримати додаткові відомості про те, як користувач може керувати цією функцією та налаштовувати її для себе в Центрі користувачів Webex (порталі), див. Налаштування зв’язку за одним номером (офіс будь-де).

Група голосової пошти

Групи голосової пошти дозволяють використовувати спільну скриньку голосової пошти, яку можна призначити користувачеві або функції маршрутизації викликів. Деякі причини, через які може знадобитися група голосової пошти:

Загальна голосова пошта для відділу або робочої групи

Додайте опцію голосової пошти до автосекретаря або групи пошуку

Надсилання переповнених викликів із черги викликів

Користувачі, яким потрібна лише голосова пошта.

Для отримання додаткової інформації див. Керування спільною голосовою поштою та скринькою вхідних факсів для Webex Calling.

Консоль оператора вказана на сторінці «Функції викликів» у Webex, проте це додаткова функція, для використання якої потрібно придбати ліцензію на консоль оператора.

Для отримання додаткової інформації див. Початок роботи з консоллю оператора.

Щоб отримати інформацію про всі функції, зокрема деякі додаткові функції, див. Функції, доступні за типом ліцензії для Webex Calling.

Таблиця 1. Інформація для збору для кожного місця розташування
Інформація	Коментар
Діапазон(и) розширення	Кожне місцезнаходження може мати розширення, що починаються з різних цифр. Одну цифру потрібно зарезервувати для керуючої цифри міжвузлового набору (наприклад , 8), а іншу — для керуючої цифри PSTN (наприклад , 9). Жоден діапазон розширення не може починатися з цих двох цифр. Усі діапазони розширення всіх локацій повинні бути однакової довжини.
Діапазон(и) DID	-
Керувальна цифра PSTN	-
Код сайту	Усі коди сайтів усіх локацій повинні бути унікальними та мати однакову довжину.
Головний номер	Під час створення розташування потрібно налаштувати два DID. Один як основний номер (наприклад, для призначення службі автосекретаря), а один для порталу голосової пошти. Надайте один DID для номера голосової пошти.
Номер голосової пошти
Кількість ліцензій	Необхідні ліцензії за типом, включаючи Стандартну, Професійну, Робочу область, Список маршрутів, Тарифний план вихідних дзвінків.
Одночасні дзвінки в години пік	Сума одночасних викликів між пристроями та між пристроями та локальним шлюзом (PSTN та виклики до пристроїв). Потрібно визначити необхідну пропускну здатність доступу до Інтернету.
Країна	-
Часовий пояс	-
Мова	-
Контактна особа (ім'я, телефон, електронна пошта)	-
Адреса (вулиця, місто, штат, поштовий індекс)	-
Фізичне місце диспетчерської служби екстреної допомоги для кінцевих точок	Місце диспетчерської дії пристрою, що використовується для екстрених викликів, зазвичай включає наступне: адреса будівлі, адреса будівлі + номер поверху, адреса будівлі + номер квартири або адреса будівлі + номер поверху + office/cubical число.
Унікальне фізичне мережеве розташування для екстрених служб на кожному пристрої	Фізичне мережеве розташування для екстрених викликів зазвичай включає наступне: перемикач / комутатор для дротових пристроїв, ідентифікатори базового набору послуг (BSSID) бездротової точки доступу (AP) для бездротового підключення пристроїв, and/or локальні IP-підмережі для кінцевих пристроїв.

Таблиця 2. Приклад нумерації підприємства
Вебсайт	Діапазон розширення	Код сайту	Діапазон підприємств
Нью-Йорк	2XXX	202	8 202 2XXX
СФО	3XXX	203	8 203 3XXX
РТП	2XXX	204	8 204 2XXX

Таблиця 3. Діапазони подовження з фіксованою довжиною
Вебсайт	Діапазон розширення	Внутрішні номери	Код сайту	Діапазон підприємств
Нью-Йорк	2XXX	2XXX	202	8 202 2XXX
СФО	8XXX	7XXX	203	8 203 7XXX
РТП	1XX	11XX	204	8 204 11XX

Таблиця 4. Перехід на семизначний набір

Вебсайт	Внутрішні номери	Код сайту	Діапазон підприємств	Ода сайту	Підприємницький анге
Нью-Йорк	2XXX	22	8 22 2XXX	822	8 822 2XXX
СФО	8XXX	23	8 23 7XXX	823	8 823 7XXX
РТП	1XXX	24	8 24 11XX	824	8 824 11XX

Таблиця 5. Параметри налаштування користувачів – короткий виклад
Метод призначення	Плюси	Мінуси
Ручний через	Простий для небагатьох користувачів. Дозволяє точний та детальний контроль над призначенням ліцензій.	Не масштабується, трудомісткий Схильний до людських помилок під час ручного введення.
Шаблони автоматичних ліцензій	Масштабований Зменшує кількість помилок ручного керування Можна застосовувати до нових та існуючих користувачів.	Потрібні дійсні номери телефонів та місцезнаходження. Складніший у налаштуванні Також потрібні групи користувачів для кожної групи користувачів з еквівалентними ліцензійними вимогами.
Масове завантаження CSV-файлу	Ефективний для великих груп користувачів Дозволяє одночасне призначення ліцензій, номерів телефонів та додаткових номерів.	Потрібне ретельне форматування CSV Можливі помилки, якщо номери телефонів або додаткові номери відсутні або неправильні.
Призначення на основі API	Автоматизований, гнучкий. Дозволяє одночасне призначення ліцензій, номерів телефонів та додаткових номерів.	Потрібна розробка та знання API.

Таблиця 6. Параметри налаштування користувачів для
Метод забезпечення	Опис	Плюси	Мінуси
Вручну	Create/manage користувачів окремо в	Простий для невеликої кількості користувачів; не потрібна інфраструктура	Не масштабується; займає багато часу для багатьох користувачів
Масово (CSV-файл)	Import/update користувачів масово через CSV у	Ефективно для груп; кодування не потрібне	Ручна підготовка CSV; менш динамічний
Люди та SCIM 2.0 API	Програмне керування користувачами через API Webex	Гнучкий; підтримує автоматизацію та інтеграцію	Потребує розвитку та інфраструктури
Синхронізація каталогів	Автоматична синхронізація з AD, Entra ID, додатків SCIM, Unified CM	Автоматизує життєвий цикл; підтримує фільтрацію та зіставлення	Складність налаштування: деякі опції мають обмежені функції або вимагають інфраструктури

Таблиця 7. Варіанти керування групами та членством у групах
Параметр	Опис	Плюси	Мінуси
групове забезпечення (групи)	Створюйте та керуйте групами безпосередньо в . Add/remove учасників вручну або через CSV.	Повний контроль над членством у групі Негайне застосування ліцензій та шаблонів Легко створювати та редагувати групи	Потрібні оновлення вручну Ризик помилок під час ручного завантаження CSV-файлів Немає автоматичної синхронізації із зовнішніми каталогами
Синхронізовані групи з Entra ID (Azure AD) або Active Directory	Автоматично синхронізувати групи безпеки та членство із зовнішніх служб каталогів.	Автоматизована синхронізація зменшує ручну роботу Забезпечує узгодженість з корпоративним каталогом Підтримує великі організації	Неможливо редагувати членство в групі Затримка синхронізації до 12 годин Вкладені групи потребують ручного вибору
Групи та SCIM 2.0 API (Групи)	Використовуйте групи або SCIM 2.0 API для програмного керування групами та членством	Автоматизація та інтеграція з іншими системами Масштабований для великих або складних середовищ	Вимагає зусиль розвитку Складність залежить від використання API

Впровадження

Готовність до мережі

Початкове налаштування

Перевірка домену

Заявити права (конвертувати) існуючих користувачів

Налаштування та тестування синхронізації каталогів

Налаштування та тестування єдиного входу (SSO)

Придбання, надання та перевірка ліцензій

Налаштування служби Webex Calling

Пілотна міграція

Закупівля PSTN

Налаштувати розташування

Інтеграція з локальним керуванням викликами

Міграція користувачів пакетами

Робочі простори

Пристрої забезпечення

Настроювання функцій

Приймальне тестування

Готовність до мережі

Першим кроком у переході до [] є забезпечення надійного та безпечного підключення до Інтернету між локальною мережею та хмарою.

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

Мережеві та безпекові адміністратори повинні розуміти ці потоки з точки зору:

Напрямок (вхідний чи вихідний)

Протоколи (Приклад - SIP TLS, SRTP, HTTPS)

Діапазони IP-адрес, що використовуються службами

Номери портів, які необхідно відкрити або дозволити.

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

Щоб отримати інформацію про необхідні потоки, включаючи IP-адресу, порти та протоколи, див. Довідкова інформація про порти для викликів Webex. Використайте цю інформацію для налаштування брандмауера, проксі-серверів та іншої мережевої інфраструктури в існуючому розгортанні, щоб увімкнути мережеві потоки.

Децентралізований інтернет-прорив з кожного відділення або сайту є рекомендованим підходом для хмарних сервісів співпраці, таких як . Дозволяючи трафіку виходити локально, ця модель:

Зменшує затримку та джиттер у зворотному напрямку, покращуючи загальну якість зв'язку

Ефективно масштабується, оскільки все більше користувачів і сайтів переходять на

Безперебійно працює з SD-WAN, яка може динамічно направляти сеанси до найближчої точки входу в хмару для оптимальної продуктивності.

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

Крім того, організації повинні забезпечити достатню пропускну здатність Інтернету на кожному сайті. Розмір пропускної здатності слід визначати на основі очікуваної кількості одночасних викликів, вибраного кодека (наприклад, Opus або G.711), а також накладних витрат на сигналізацію, повторні передачі та зростання. Це узгоджується з фазою підготовки життєвого циклу PPDIO та створює міцну основу для міграції.

Початкове налаштування

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

Перевірка домену

Щоб мати змогу ідентифікувати користувачів, зареєстрованих за допомогою доменів електронної пошти вашої компанії на [адресі [адреси]], важливо перевірити ці домени. Без перевірки домену користувачів буде призначено до організації споживачів, що ускладнить керування користувачами для вашої компанії. Перевірка домену – це обов’язковий крок, який дозволяє вашій організації ефективно заявляти про права на цих користувачів та керувати ними.

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

Щоб отримати додаткові відомості про керування доменами, див. Керування вашими доменами.

Заявити права (конвертувати) існуючих користувачів

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

Щоб отримати додаткові відомості про заявку на користувачів, див. Заявка на користувачів вашої організації (перетворення).

Налаштування та тестування синхронізації каталогів

Щоб забезпечити безперебійне керування користувачами та групами, ви можете синхронізувати користувачів та групи з корпоративного каталогу Microsoft Entra ID (раніше Azure AD) або Microsoft Active Directory (AD) до . Цей процес гарантує, що ідентифікаційні дані користувачів та членство в групах послідовно підтримуються в усьому середовищі.

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

Найефективніший метод фільтрації синхронізованих користувачів – це використання членства в групах каталогів:

1
Створіть спеціальну групу синхронізації: У каталозі підприємства (Microsoft Entra ID або AD) створіть групу безпеки спеціально для синхронізації (наприклад, групу синхронізації).

2
Заповніть групу цільовими користувачами: Додайте до цієї групи лише тих користувачів, яких потрібно синхронізувати (наприклад, тестову групу під час пілотного етапу). Це дозволяє вам жорстко контролювати, хто бере участь у процесі синхронізації.

3
Налаштуйте угоду про синхронізацію з фільтрацією на основі груп: Під час налаштування угоди про синхронізацію в Directory Connector або Entra ID provisioning налаштуйте область дії, щоб вона включала лише користувачів, які є членами призначеної групи.

Для Microsoft Entra ID ви можете використовувати призначення на основі груп у налаштуваннях підготовки

Для AD можна визначити фільтр LDAP, щоб включити лише користувачів, які належать до вказаної групи.

4
Розширте групу за потреби: У міру переходу до ширших фаз розгортання просто додавайте додаткових користувачів або групи до групи синхронізації. Область синхронізації автоматично розшириться, включивши цих користувачів, що дозволить контрольоване та поступове розгортання.

Приклади кроків впровадження:

В активному каталозі:

Створіть групу безпеки з назвою «Група синхронізації».

Додайте потрібних пілотних користувачів до цієї групи.

Налаштуйте Directory Connector за допомогою LDAP-фільтра, такого як: (memberOf=CN=Webex Синхронізація Group,OU=Groups,DC=yourdomain,DC=com).

У Microsoft введіть ідентифікатор:

Створіть групу під назвою синхронізаційна група

Призначте групу в налаштуваннях підготовки Entra ID

Тільки користувачі з цієї групи отримають доступ до .

Завжди тестуйте синхронізацію на основі груп у невиробничому середовищі, перш ніж застосовувати її до всієї організації.

Регулярно перевіряйте членство в групах, щоб забезпечити синхронізацію лише авторизованих користувачів

Для постійного управління, автоматизуйте оновлення членства в групах на основі бізнес-правил або систем управління персоналом, якщо це можливо.

Список літератури:

Синхронізувати користувачів Entra ID з Control Hub

Налаштуйте застосунок Entra ID Wizard у Control Hub

З’єднувач каталогу

Налаштування та тестування єдиного входу (SSO)

Єдиний вхід (SSO) підвищує безпеку та спрощує доступ користувачів, дозволяючи їм одноразово пройти автентифікацію за допомогою своїх корпоративних облікових даних та отримати безперешкодний доступ до . підтримує інтеграцію SSO з постачальниками ідентифікаційних даних, сумісними з SAML 2.0, включаючи Microsoft Entra ID (раніше Azure AD), федеративні рішення Active Directory (AD) та різні сторонні постачальники ідентифікаційних даних.

На цьому етапі розроблену систему єдиного входу слід впровадити та протестувати.

Список літератури:

Інтеграція єдиного входу в центр керування

налаштування єдиного входу для адміністрування Webex

Налаштування єдиного входу за допомогою Microsoft Entra ID

SSO з кількома постачальниками ідентифікаційних даних

Керування єдиним вхідним входом під час інтеграції в Control Hub

Придбання, надання та перевірка ліцензій

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

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

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

Налаштування призначення ліцензій на основі груп має бути виконано після завершення синхронізації каталогів, щоб синхронізовані групи існували та могли бути використані для призначення ліцензій.

Зокрема, автоматичне призначення ліцензії вимагає додаткових деталей підготовки, таких як місцезнаходження користувача та призначення номера телефону. Робочий номер телефону користувача має бути в +E.164 формат, попередньо підготовлений та призначений дійсному розташуванню для автоматичної активації ліцензії. Якщо ці умови не виконано, користувачеві не будуть надані послуги автоматично, і може знадобитися ручне втручання.

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

Налаштування служби Webex Calling

Вкрай важливо провести комплексний огляд та налаштування глобальних параметрів служби всередині .

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

Налаштуйте ці глобальні параметри відповідно до політик та рішень щодо дизайну вашої організації.

Також налаштуйте параметри та шаблони користувачів і програм.

Пілотна міграція

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

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

Основні цілі цього пілотного розгортання дві: по-перше, перевірити та вдосконалити процеси переходу від початку до кінця, включаючи робочі процеси надання користувачів, процедури міграції даних та конфігурації кінцевих точок; та по-друге, всебічно перевірити функціональність перенесених сервісів у реальних умовах експлуатації.

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

Аналіз, отриманий під час цього пілотного етапу, є важливим для оптимізації наступних хвиль міграції та забезпечення плавного переходу з мінімальними ризиками для всього підприємства.

Закупівля PSTN

Щоб придбати послуги PSTN для , спочатку виберіть варіант підключення PSTN у .

Якщо організація планує підтримувати гібридне подвійне керування викликами ( фаза 1 на рисунку Поетапний перехід викликів): Гібридний та хмарний) тимчасово або на невизначений термін, їм потрібно буде розгорнути один або кілька локальних шлюзів для локальної PSTN, щоб дозволити дзвінки між кінцевими точками.

Якщо кінцевою метою є повний перехід ( фаза 2) до хмари, включаючи PSTN, то для PSTN знадобиться або тарифний план Cisco Calling Plan, або опція Cloud Connect.

Зверніться до обраного вами постачальника послуг, щоб замовити та перенести номери телефонів, перш ніж налаштовувати їх у форматі . Замовлення номерів телефонів або ініціювання замовлень на перенесення даних можливе лише required/possible для локальної PSTN та Cloud Connect для . Для тарифних планів Cisco Calling Plan замовлення та перенесення ініціюється з Control Hub одразу після створення розташування, а також у країнах, де доступний тарифний план Cisco Calling Plan. Щоб отримати додаткові відомості про плани Cisco Calling, див. Початок роботи з планами Cisco.

У рамках впровадження PSTN переконайтеся, що ваш постачальник послуг увімкнув як вхідні, так і вихідні послуги PSTN для вашого місцезнаходження. Крім того, виконайте тестові дзвінки, щоб перевірити, чи правильно маршрутизуються дзвінки через вибране вами з’єднання PSTN.

Налаштувати розташування

Перш ніж додавати користувачів і пристрої до , необхідно налаштувати місця для викликів. Для кожного місця розташування необхідно ввести дійсну адресу вулиці. У США та Канаді ця адреса перевіряється та використовується платформою для надсилання інформації про місцезнаходження PIDF-LO для екстрених викликів.

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

Для локацій, які використовують Cloud Connect або Cisco Calling Plan як варіант PSTN, просто виберіть відповідний варіант PSTN для локації під час налаштування. Якщо розташування використовує Cloud Connect для PSTN або локальну PSTN, вам потрібно буде додати номери телефонів, замовлені на попередньому кроці. Номери можна додати як неактивні, якщо ви не хочете одразу включати їх до маршрутизації викликів; ви можете активувати ці номери пізніше, коли їх буде призначено користувачам або функціям.

Важливо завжди встановлювати головний номер для кожного місця розташування. Основний номер можна призначити або користувачеві, або функції, наприклад, автосекретарю. Щоб увімкнути голосову пошту в цьому місці, обов’язково встановіть пілотний номер голосової пошти, також відомий як номер голосового порталу.

Додаткові налаштування для виклику місць розташування включають налаштування деталей екстрених викликів, таких як номер екстреного зворотного виклику, параметри сповіщень та розширені функції екстрених викликів. Також слід переглянути та налаштувати параметри запису, мовні налаштування та конфігурації пристроїв відповідно до потреб кожного місця розташування. Якщо ваша організація використовує скорочений міжсайтовий внутрішньомережевий набір номерів із корпоративними значущими номерами, не забудьте налаштувати унікальний код сайту для розташування у внутрішніх налаштуваннях набору. Зрештою, якщо для зовнішнього набору потрібна цифра вихідного набору, обов’язково встановіть її в налаштуваннях зовнішнього набору. Якщо налаштовано вихідний набір цифри, Cisco рекомендує ввімкнути примусове використання вихідного набору цифри для забезпечення узгодженості.

Інтеграція з локальним керуванням викликами

Для інтеграції з локальним керуванням викликами необхідно налаштувати транкінги, групи маршрутів, корпоративні абонентські плани, а також налаштування розташування та глобальні налаштування. Почніть з налаштування транкових ліній та локальних шлюзів, призначених для взаємоз’єднання з локальною системою керування викликами; цей крок потрібен лише за необхідності виділених транкових ліній. Якщо існуючих транків та груп маршрутів достатньо для вашого розгортання, їх можна повторно використовувати для локального з'єднання без додаткового налаштування.

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

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

Міграція користувачів пакетами

Під час перенесення користувачів з до ви можете не мати змоги перемістити всіх користувачів одночасно. Це може бути пов’язано з кількома причинами, зокрема, але не обмежуючись кількістю сайтів або користувачів, часом, необхідним для перенесення сайту and/or група користувачів одночасно, обмежені ІТ-ресурси або ресурси сайту для підтримки вікна змін, тривалість вікна змін, складність змін тощо.

Під час поетапної міграції користувачів критично важливо визначити, яких користувачів потрібно мігрувати разом в одному пакеті. Основна мета — разом перенести користувачів, які мають залежності один від одного щодо своїх послуг та функцій викликів. Ви хочете переконатися, що всі їхні функції викликів (наприклад, черги викликів) повністю функціональні, як і до переходу на .

Навіть якщо ви реалізуєте взаємодію викликів між локальними шлюзами та з ними, ви не зможете розділити спільні служби або функції через це з'єднання. Тому вам потрібно визначити залежності між користувачами, розглядаючи такі функції, як:

Моніторинг інших користувачів за допомогою BLF

У тому ж пілотному проекті пошуку, черзі викликів тощо

Спільні лінії

Використання функції перехоплення дзвінків

Використання тих самих номерів паркування викликів

Домофон

Executive/Admin.

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

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

Використайте результати інструменту Migration Insights або стороннього інструменту, який ви використовували на етапі підготовки, щоб визначити, яких користувачів та функції слід згрупувати разом. Цей результат слід було використати для розробки плану міграції, і він дасть вам уявлення про те, як групувати користувачів та функції, які потрібно перенести разом.

Ключові кроки під час переходу групи користувачів:

Визначення користувачів для спільної міграції

Перевірте, чи всі користувачі ввійшли

Перевірте, чи існують усі TN для користувачів.

Перевірте правильність формату номера телефону в довіднику

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

Перевірка або налаштування всіх послуг та функцій викликів для групи користувачів (до або під час переходу, залежно від обставин)

У корпоративному довіднику додайте користувачів до групи користувачів з увімкненою функцією виклику

Інструменти Leverage Tools – інструменти для міграції користувачів та функцій and/or інструменти сторонніх розробників

Disable/Delete user/device номер телефону та виклик features/services після переходу.

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

Робочі простори

У , робоча область стосується спільного розташування (наприклад, конференц-зали, місця для нарад або робочого столу), якому можна призначити пристрої, розширення та користувачів. На відміну від традиційних телефонів Unifed CM, робочі простори:

Орієнтований на місцезнаходження: прив'язаний до фізичних просторів.

Гнучкий для пристрою: може мати один або декілька пристроїв (стаціонарні телефони, дошки тощо).

Після того, як робочі простори будуть визначені як частина переходу до , їх можна буде додати в розділі «Пристрої». Кожному робочому простору потрібно призначити пристрій, і якщо вони вже перебувають в Unified CM, їх потрібно скинути або повторно налаштувати. Такі функції, як голосова пошта, переадресація викликів та перехоплення викликів, можна ввімкнути або вимкнути, а також можна застосовувати політики для відеодзвінків, паркування викликів та мобільності за потреби. Перевірте кожне робоче місце, здійснюючи внутрішні та зовнішні дзвінки, тестуючи відео- та конференц-зв'язок, а також функції мобільності. Насамкінець, повідомте користувачів про будь-які застосовні процеси для пристроїв робочого простору та бронювань.

Щоб отримати додаткові відомості про робочі простори в , див. Робочі простори.

Пристрої забезпечення

Телефони, які зараз зареєстровані в , потрібно буде перенести в рамках переходу до хмари. Щоб максимально спростити міграцію та мінімізувати ризик невдачі, Cisco рекомендує одночасно переносити фізичні сайти або відділи. Однак, можливо, вам доведеться переносити користувачів пакетами через залежності функцій. Див. розділ Пакетне перенесення користувачів для отримання додаткової інформації.

Будь-які підтримувані телефони, з яких потрібно перейти, потрібно буде налаштувати як користувач або робочу область, а фізичний телефон потрібно буде переналаштувати для реєстрації в . Крім того, для телефонів серій 7800 та 8800 потрібно оновити прошивку з Enterprise до Multiplatform Phone (MPP). Цей процес включає завантаження перехідної прошивки перед завантаженням прошивки MPP, необхідної для реєстрації. Також потрібна відповідна міграційна ліцензія. Протягом останніх кількох років Cisco вдосконалила цей процес, щоб спростити оновлення прошивки ваших телефонів Enterprise до прошивки MPP. Щоб отримати додаткові відомості про кроки для завершення оновлення прошивки, див. Перетворення прошивки Enterprise на MPP для IP-телефонів Cisco серій 7800 та 8800.

Окрім кроків, описаних у цій статті, є вбудований інструмент «Перенесення телефону до Webex Calling» , який можна використовувати для перенесення прошивки телефонів 7800 та 8800 з Enterprise на MPP. Цей інструмент також дозволяє додавати телефони та призначати їх відповідним користувачам або робочим просторам. Щоб отримати додаткові відомості про використання інструменту, див. Перенесення телефону.

Для будь-яких телефонів серії 9800, зареєстрованих із вищезазначеною прошивкою, вимога щодо міграції не застосовується. Ці телефони працюють під керуванням PhoneOS, яка підтримується як , так і . Щоб перенести ці телефони, вам потрібно буде додати їх до Webex Calling, призначити їх користувачеві або робочому простору, а потім скинути налаштування телефонів до заводських. Послідовність завантаження PhoneOS для реєстрації на малюнку нижче показано послідовність завантаження PhoneOS та те, як телефон зареєструється після додавання до , навіть якщо телефон все ще налаштовано на and/or Використовуються параметри DHCP (приклад - 150).

Послідовність завантаження PhoneOS для реєстрації

підтримує скидання пристроїв PhoneOS до заводських налаштувань, що дозволяє безконтактне підключення до . Адміністратори можуть віддалено скидати телефони 9800 та 8875 до заводських налаштувань через сторінки адміністрування CUCM, що усуває необхідність фізичного доступу до телефонів для їх підключення до . Ця функція підтримується пакетами пристроїв з 9 вересня 2025 року:

CUCM версії 15 - Unified Communications Manager версії 15

CUCM версії 14 - Unified Communications Manager версії 14.

Щоб отримати докладнішу інформацію про процес реєстрації серії 9800, див. Процес реєстрації.

Окрім IP-телефонів Cisco, може знадобитися налаштування інших пристроїв, таких як аналогові телефонні адаптери (ATA), бездротові телефони (Wi-Fi, DECT), відеопристрої, голосові шлюзи та пристрої й телефони сторонніх^{виробників}. Багато з цих пристроїв не мають шляху оновлення прошивки, як IP-телефони, щоб перейти з корпоративної прошивки на хмарну. Таким чином, ви налаштуєте кожен із цих пристроїв у Центрі керування. Деякі з них неможливо перейти на них, і їх потрібно буде замінити еквівалентною моделлю (наприклад, ATA 191/192) а інші потребуватимуть ручного переналаштування and/or зміни програмного забезпечення.

Голосові шлюзи – Щоб перенести свій локальний шлюз, див. Перенесення локального шлюзу.
Щоб отримати додаткові відомості про налаштування голосового шлюзу VG400, VG410 або VG420 у Control Hub, див. Локальний шлюз

Аналоговий телефонний адаптер (ATA) – Щоб розпочати роботу з Cisco ATA 191 та 192, див. Cisco ATA.

Бездротовий телефон Wi-Fi - Щоб інтегрувати бездротові телефони 840 та 860, див. Інтеграція бездротового телефону Webex.

Бездротові телефони DECT – Щоб розпочати роботу з новою серією Cisco IP DECT 6800, див. Cisco IP DECT.

Щоб побудувати та керувати цифровою мережею DECT у Control Hub, див. Керування мережею DECT

Щоб отримати додаткові відомості про Cisco IP DECT 6800, див. Посібник з розгортання

сторонні пристрої та телефони - Працюйте зі сторонніми^{постачальниками [] сторонніх} постачальників на device/phone вимоги та процес їх перенесення або заміни для підтримки.

Настроювання функцій

Будь-які необхідні функції викликів потрібно налаштувати до або під час переходу. Як обговорювалося в розділі «Перенесення користувачів пакетами», функції викликів необхідно налаштувати та перенести під час перенесення користувачів, які їх використовують.

Докладніше про налаштування кожної з функцій див. у відповідних статтях довідки з налаштування.

Автосекретарі – Щоб керувати автосекретарями, див. Автосекретарі

Паркування викликів – Інструкції щодо керування паркуванням викликів див. у розділі Паркування викликів

Перехоплення виклику – Щоб налаштувати групу перехоплення виклику, див. Перехоплення виклику

Черги викликів – Щоб налаштувати чергу викликів, див. Черга викликів

Групи пошуку – Щоб керувати групами пошуку, див. Керування групою пошуку

Режими роботи – Щоб дізнатися про маршрутизацію викликів на основі режимів роботи, див. Маршрутизація викликів на основі режимів роботи

Групи пейджингу – Щоб налаштувати групу пейджингу, див . Налаштування групи пейджингу

Записи – Щоб керувати записом дзвінків для , див. Керування записами

Охоплення одним номером – Щоб налаштувати охоплення одним номером (офіс будь-де), див. Налаштування одного номера

Група голосової пошти – Щоб керувати спільною голосовою поштою та скринькою вхідних факсів для , див. Керування голосовою поштою.

Приймальне тестування

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

У цьому розділі наведено приклади та висвітлено ключові аспекти, які слід враховувати під час приймальних випробувань; однак він не призначений для використання як вичерпний або всебічний контрольний список.

Налаштування користувачів та призначення номерів

Фундаментальний аспект приймального тестування включає перевірку того, що всі користувачі точно та повністю надані в межах . Це вимагає ретельного порівняння між каталогом source() та щойно створеною базою користувачів, щоб переконатися, що кожен обліковий запис користувача разом із пов’язаними атрибутами, такими як номери додаткових номерів та призначення прямого вхідного набору (DID), було правильно перенесено. Повнота забезпечення є критично важливою не лише для працездатності з першого дня, але й для подальшого адміністрування та підтримки.

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

Потоки викликів PSTN та відображення ідентифікації абонента

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

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

Потоки викликів у мережі

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

Обробка викликів користувачів та перевірка функцій

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

Слід оцінити зрозумілість та швидкість реагування, враховуючи те, як користувачі взаємодіють з історією викликів, голосовою поштою та інтегрованими каталогами. Додаткову увагу слід приділити можливості переміщення активних дзвінків між пристроями та ефективному використанню елементів керування під час дзвінків у програмі або на фізичних телефонах. Кінцева мета полягає в тому, щоб забезпечити послідовний, ефективний досвід кінцевого користувача та повну підтримку комунікаційних потреб організації після міграції.

Черги викликів: Досвід роботи агентом та керівником

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

Керівникам слід оцінити можливості роботи з робочим столом на предмет таких функцій, як моніторинг у режимі реального часу, переривання викликів та аналітика або дані про продуктивність черги. Це включає, але не обмежується, перевіркою інформаційних панелей та інструментів звітності, які надають корисні дані про розподіл викликів, активність агентів та показники черги.

Мисливські групи: Розподіл дзвінків

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

Автосекретарі: Оголошення та операції з меню

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

Робота голосової пошти

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

Оптимізація

Міграція PSTN до Cloud Connect для

Оптимізуйте локальну інфраструктуру

Використовуйте аналітику та вирішуйте проблеми

Міграція PSTN до Cloud Connect для

Після перенесення всіх кінцевих точок та користувачів у хмарний сервіс викликів єдиною метою Unified CM є виконання функції транзитного каналу між шлюзами PSTN та через локальний шлюз. Видалення шлюзів PSTN, та локального шлюзу з картини за допомогою Cloud Connect як доступу PSTN для всіх користувачів Webex Calling має кілька переваг, включаючи зниження витрат та підвищення надійності. Щоб перевести локальний доступ до PSTN до Cloud Connect для , виконайте такі дії:

Cloud Connect для вибору партнера.

Перегляньте список партнерів Cloud Connect та виберіть одного з доступних партнерів для вашої організації.

Cloud Connect для перевірки.

Перш ніж перемикати доступ до PSTN для локацій на Cloud Connect, слід перевірити та підтвердити підключення до PSTN через вибраного партнера Cloud Connect. Для цього потрібно налаштувати тестове місце розташування та підготувати кількох тестових користувачів у цьому місці. Потім доступ до PSTN для цього тестового розташування налаштовується на партнера Cloud Connect перед перевіркою підключення PSTN за допомогою тестових телефонів. Після успішної перевірки тестове розташування можна деініціалізувати.

Перенесення номера.

Щоб підготуватися до переходу на Cloud Connect, необхідно розмістити замовлення на портування для всіх номерів, які наразі призначені для транкінгової лінії PSTN, що завершується на. Усі номери необхідно перенести до партнера Cloud Connect. Для підтримки міжлокаційної доступності всі номери всіх локацій необхідно переносити одночасно.

Перейдіть до партнера Cloud Connect.

На дату переходу доступ до PSTN для всіх локацій має бути налаштований на постачальника хмарно-підключеної PSTN, а також має бути перевірено вхідне та вихідне з’єднання.

Як обговорювалося в розділі про PSTN розділу про проектування, клієнти також можуть перенести свій доступ до PSTN до Cloud Connect на початку переходу, використовуючи транкінг PSTN для гібридного розгортання. Для отримання додаткової інформації див. Транкінг PSTN для гібридних розгортань Webex Calling. У такому випадку під час переходу доступ до PSTN здійснюється через локальний шлюз, і після переміщення всіх користувачів до PSTN не буде жодного додаткового кроку міграції, пов'язаного з ним, окрім виведення з експлуатації та локальних шлюзів.

Оптимізуйте локальну інфраструктуру

Після того, як усіх користувачів переведено до хмарної реєстрації, а всі кінцеві точки переведено до хмарної (або виведено з експлуатації), оновіть відповідну локальну інфраструктуру тепер, коли використовуються хмарні виклики. Оновлення інфраструктури включають:

Видалити локальні записи SRV для керування викликами та обміну повідомленнями DNS із локальних DNS-серверів, зокрема cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб.

Видалити записи SRV DNS, пов'язані з периферійним сервером, із публічної системи DNS, включаючи collab_edge._tls.<domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб граничних служб для співпраці.

Оновіть усі відповідні області DHCP, щоб видалити параметр 66 та параметр 150. TFTP/boot адреси серверів. Ці області більше не потрібні для виявлення та завантаження конфігурації керування викликами кінцевої точки.

Update/remove відповідні вузли виходу в локальному режимі Gateway/CUBE що спрямовують виклики до та з Unified CM. Ці точки виходу більше не потрібні для локальної маршрутизації викликів.

Видалити або видалити всі віртуальні машини вузлів кластера and/or сервери. Перепрофілювати обчислювальні ресурси та обладнання за потреби. Ці ресурси більше не потрібні для керування викликами та периферійних послуг.

Видалити або видалити всі віртуальні машини вузлів кластера and/or сервери. Перепрофілювати обчислювальні ресурси та обладнання за потреби. Ці ресурси більше не потрібні для голосової пошти та служб єдиного обміну повідомленнями.

Прибирання: Після міграції доступу з PSTN до Cloud Connected PSTN, транкінгові лінії PSTN, шлюзи PSTN та локальний шлюз можна вивести з експлуатації.

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

Роздільні імена (DN), що належать перенесеним користувачам, слід розміщувати в прихованому розділі, щоб уникнути збоїв маршрутизації викликів і забезпечити пріоритетний доступ усіх CSS до хмарного шляху тих самих роздільних імен (DN).

Оновлюйте фізичне місце диспетчеризації та мережевий елемент у Horizon Mobility щоразу, коли відбуваються зміни. Поширені дії, які потребують оновлення:

Заміна мережевого комутатора

Заміна бездротової точки доступу

Зміни області дії DHCP

Фізичні зміни всередині будівлі (якщо вирішено cubical/office)

Розширення або звуження фізичного офісного простору всередині будівлі.

Використовуйте аналітику та вирішуйте проблеми

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

аналітика якості медіа

У розділі усунення несправностей кожен виклик, здійснений за допомогою, можна переглянути з детальною інформацією про ключові проблеми з якістю медіа та сигналізацією, що допоможе точно визначити проблеми з медіа, а також невдалі виклики, як показано на рисунку .

усунення несправностей якості медіа

засіб усунення несправностей також можна інтегрувати з іншими продуктами Cisco, такими як комутатори ThousandEyes та Meraki, щоб забезпечити ще більш насичений інтегрований досвід у Control Hub. Щоб отримати додаткові відомості про використання аналітики та усунення несправностей Webex Calling, див. статтю Усунення несправностей викликів Webex Calling у Control Hub.

1	Створіть спеціальну групу синхронізації: У каталозі підприємства (Microsoft Entra ID або AD) створіть групу безпеки спеціально для синхронізації (наприклад, групу синхронізації).
2	Заповніть групу цільовими користувачами: Додайте до цієї групи лише тих користувачів, яких потрібно синхронізувати (наприклад, тестову групу під час пілотного етапу). Це дозволяє вам жорстко контролювати, хто бере участь у процесі синхронізації.
3	Налаштуйте угоду про синхронізацію з фільтрацією на основі груп: Під час налаштування угоди про синхронізацію в Directory Connector або Entra ID provisioning налаштуйте область дії, щоб вона включала лише користувачів, які є членами призначеної групи. Для Microsoft Entra ID ви можете використовувати призначення на основі груп у налаштуваннях підготовки Для AD можна визначити фільтр LDAP, щоб включити лише користувачів, які належать до вказаної групи.
4	Розширте групу за потреби: У міру переходу до ширших фаз розгортання просто додавайте додаткових користувачів або групи до групи синхронізації. Область синхронізації автоматично розшириться, включивши цих користувачів, що дозволить контрольоване та поступове розгортання. Приклади кроків впровадження: В активному каталозі: Створіть групу безпеки з назвою «Група синхронізації». Додайте потрібних пілотних користувачів до цієї групи. Налаштуйте Directory Connector за допомогою LDAP-фільтра, такого як: (memberOf=CN=Webex Синхронізація Group,OU=Groups,DC=yourdomain,DC=com). У Microsoft введіть ідентифікатор: Створіть групу під назвою синхронізаційна група Призначте групу в налаштуваннях підготовки Entra ID Тільки користувачі з цієї групи отримають доступ до . Завжди тестуйте синхронізацію на основі груп у невиробничому середовищі, перш ніж застосовувати її до всієї організації. Регулярно перевіряйте членство в групах, щоб забезпечити синхронізацію лише авторизованих користувачів Для постійного управління, автоматизуйте оновлення членства в групах на основі бізнес-правил або систем управління персоналом, якщо це можливо. Список літератури: Синхронізувати користувачів Entra ID з Control Hub Налаштуйте застосунок Entra ID Wizard у Control Hub З’єднувач каталогу

Cisco AI Assistant

Дякуємо за відгук.

Посібник з розгортання міграції

Вступ

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

Огляд

Основні компоненти

Огляд процесу PPDIO

Загальний опис PPDIO

Використання PPDIO для проектів міграції з Unified CM до Webex Calling

Підготовка

Планування

Проєктування

Впровадження

Оптимізація

петлі зворотного зв'язку PPDIO

Підхід до міграції

Підготовка

Бізнес- та технічні вимоги

Чому важливо збирати вимоги:

Вимоги бізнесу

Технічні вимоги

Готовність до мережі та вимоги

Налаштування хмарно-підключеного UC

Оцінка поточного середовища

Ліцензування

Locations/Sites

наявний інвентар devices/clients

Перевірте придатність пристрою

Користувачі

Підключення до PSTN

Особливості & використання функцій

Інтеграції Cisco: Unity Connection UCCX UCCE

Запис викликів

Інтеграції зі сторонніми розробниками

Планування

План проекту високого рівня

Міграційний шлях – один чи два кроки?

Варіант 1. Міграція користувачів в один крок

Варіант 2. Двоетапна міграція користувачів

Крок 1

Крок 2

Проєктування

Вибір регіону

Розташування

PSTN

План набору номера

Локальний абонентський план у

план набору номера

Запис

1. Вибір постачальника послуг запису дзвінків

2. Вибір регіону

Екстрені виклики

Ліцензування

Ручне призначення через

Шаблони автоматичного призначення ліцензій

Масове призначення через шаблон CSV

Призначення на основі API

Вимоги до ліцензії

Підготовка користувачів

Групи користувачів

Рекомендований підхід під час міграції з до

Проектування груп користувачів

Єдиний вхід (SSO)

Підтримка кількох постачальників ідентифікаційних даних

1. Злиття та поглинання

2. Кілька незалежних ІТ-відділів

3. Різні групи користувачів або домени

4. Підтримка різних протоколів автентифікації

5. Покращена безпека та відповідність вимогам

6. Спрощений користувацький інтерфейс

Duo MFA з єдиним вхідним входом для

Функції

Автосекретар

Паркування викликів

Підхоплення викликів

Черга викликів

Група пошуку

Режими роботи

Пейджингова група