Керівництво з розгортання міграції

Вступ

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

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

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

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

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

Контрольний хаб
Забезпечення каталогів і користувачів
Webex Callingплатформа
Підтримувані кінцеві точки виклику
Параметри підключення PSTN
Webex Callingплан набору номера і управління номерами
Функції безпеки та відповідності.

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

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

Інструменти міграції Webex: безкоштовні інструменти самообслуговування, вбудовані в Центр керування, щоб спростити перехід до Webex Calling
Сертифіковані постачальники міграції: перевірені постачальники програмного забезпечення та інструментів Cisco, які розробили рішення для міграції, щоб допомогти партнерам і клієнтам Webex у складних та великих міграціях. Ці рішення можуть допомогти спростити, керувати та прискорити перехід до Webex Calling
Webex Setup Assist: служ ба міграції під керівництвом 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-телефони Cisco, відео системи Cisco Desk and Room) та програмне забезпечення () кінцеві точки на основі IP. Cisco Jabber Ці компоненти можуть дещо відрізнятися в деяких середовищах, але це відправна точка для переходу, описаного в решті цього документа.

On-Premises Collaboration Architecture: Call Control and Remote Access — ***Архітектура локальної співпраці: керування викликами та віддалений доступ***

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

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

Таблиця 1. До: Компоненти локальної інфраструктури викликів
Продукт	Опис
Unified CM	Локальний контроль дзвінків, що забезпечує реєстрацію пристроїв та послуги маршрутизації викликів
Cisco Expressway-С/Е	Передгранна інфраструктура, що забезпечує мобіль Remote Access ні та (MRA) та функціональні можливості між бізнесом (B2B), що дозволяє віддаленим кінцевим точкам безпечно підключатися з-за меж організації . Expressway розгортається парами, щоб забезпечити об'їзд брандмау ера для зовнішніх кінцевих точок.
Сервер нарад Cisco (CMS), керування зустрічами Cisco (CMM) та пакет керування телеприсутністю Cisco (TMS)	Локальна інфраструктура голосових, відео та веб-конференцій, що забезпечує багатоточкові зустрічі, управління нарадами та можливості планування. [Необов'язково]
Cisco Unity Connection	Локальна платформа голосових повідомлень, що забезпечує голосову пошту та уніфіковані можливості обміну повідомленнями. [Необов'язково]
Робочий стіл Cisco, кімната Cisco, плата Cisco, IP-телефони Cisco та Cisco Jabber	Пристрої на основі IP, зареєстровані Unified CM та надають можливості голосових та відеодзвінків

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

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

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

Transition Decision: On-Premises Calling to Webex Calling — ***Рішення про перехід: локальний виклик Webex Calling***

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

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

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

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

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

After: Webex Calling Architecture — ***Після: Архі Webex Calling тектура***

Після: Таблиця компонентів інфраструктури викликів хма ри містить список нових елементів архітектури після переходу на Webex.

Таблиця 2. Після: Компоненти інфраструктури хмарних дзвінків
Продукт	Опис
Webex Calling	Служба дзвінків у хмарі, що надається з платформи Webex та забезпечує реєстрацію кінцевих точок та маршрутизацію дзвінків
Роз'єм каталогу Cisco	Програма Windows, що працює на доменній машині Windows, що забезпечує синхронізацію ідентифікацій між локальним корпоративним схови Active Directory щем та с ховищем ідентифікацій організації Webex. Для клієнтів, які переходять з локального на іденти Active Directory фікатор Entra ID, інтеграція ідентичності з Webex замість Cisco Directory Connector використовує додаток Майстер ідентифікатора Entra ID.
Локальний шлюз	Локальний шлюз діє як міст між локальною уніфікованою мережею зв'язку клієнта та Webex Calling хмарою. Він може бути розгорнутий локально або розміщений партнером, забезпечуючи доступ PSTN для кінцевих точок, зареєстрованих у хмарі, а також виклик інтеграції між зареєстрованими та Unified CM зареєстрованими в хмарі кінцевими точками. Cisco IOS-Маршрутизатор інтегрованих служб XE (серії ISR 1100 та 4000), серія Cisco Catalyst 8200/8300, програмне забезпечення Cisco Catalyst 8000V Edge та різні сертифіковані сторонні контролери кордонів сесій (SBC) можуть використовуватися як LGW для підходу поетапної міграції.
Шлюз виживання	Шлюз Survivalability (SGW) - це локальний мережевий шлюз на базі IOS-XE, який надає послуги резервних дзвінків до кінцевих точок на місці під час відключень мережі. Webex Calling
План дзвінків Cisco, хмарне підключення для Webex Calling	План дзвінків Cisco та Cloud Connect for - 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 разом із сторонніми інструментами для виконання змін режиму мікропрограми пристрою, конфігурації функцій та міграції користувачів
Використовуйте масові операції та забезпечення за допомогою API Webex для оптимізації масштабних міграцій та конфігурацій
Виконання надання ліцензій, реєстрації пристрою та оновлення конфігурації
Перевірте успішність міграції за допомогою тестування та опера ційної перевірки.

Оптимізувати

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

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

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

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

Iterations while executing PPDIO — ***Ітерації під час виконання PPDIO***

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

Unified CM assisted PPDIO process — ***Unified CMдопоміжний процес PPDIO***

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

Міграційний підхід

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

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

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

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

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

Phased Calling Transition: Hybrid and Cloud — ***Поетапний перехід викликів: гібридний і хмарний***

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

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

Recommended 3-Phase Transition — ***Рекомендований 3-фазний перехід***

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

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

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

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

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

Pre-Migration Activities — ***Передміграційна діяльність***

Підготуйте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клієнти та партнери мають доступ до можливостей підключення за межами поточного Інтернету (OTT) , які можуть оптимізувати підключення до вклю Webex Edge чення Connect. Для отримання додаткової інформації про подроб Webex Edge иці дизайну Connect див. статтю П ріоритетна архітектура Cisco для Webex Edge підключенняWebex Meetings, виклик для кількох орендарів та виділений екземпляр .

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

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

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

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

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

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

Таблиця 2. Webex Calling розрахунки пропускної здатності типу виклику
Типи дзвінків	Кодек - пропускна здатність	Розрахунок пропускної здатності
/Настільний телефон ->	ОПУС - 70 кбіт/с	Кількість одночасних дзвінків* 70 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> Настільний телефон	ОПУС — 70 кбіт/с	Кількість одночасних дзвінків* 70 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> PSTN через LGW	Г.711 — 80 кбіт/с	Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> PSTN через хмарний PSTN (напр. План дзвінків Cisco)	Г.711 — 80 кбіт/с	Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> Підприємство через LGW	Г.722 — 80 кбіт/с	Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> голосова пошта	ОПУС — 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 кбіт/с = 8 000 кбіт/с
Додаток Webex/Настільний телефон → PSTN через хмарне підключення для 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 між комутаторами, маршрутизато рами та брандмауерами.
Цілі затримки, тремтіння та втрати пакетів

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

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

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

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

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

Налаштування хмарного зв'язку UC

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

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

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

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

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

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

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

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

Платформа

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

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

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

Місцезнаходження/Сайти

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

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

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

Інвентаризація існуючих пристроїв/клієнтів

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

Настільні телефони

Для аудіо та відео настільних телефонів підтримуються лише настільні телефони серії 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, див. розділ Перетворення IP-телефонів Cisco 7800 та 8800 між прошивкою Enterprise та MPP.

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. Будь-яка з цих кінцевих точок, яка потребує здійснення аудіо та/або дзвінків PSTN, вимагає ліцензії на виклик:

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

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

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

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

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

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

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

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

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

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

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

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

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

Для отримання додаткової інформації про ці два варіанти див. Мі граційна подорож - один або два кроки? .

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

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

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

Щоб допомогти визначити придатність телефонів, Контрольний центр має вбудований інструмент під назвою Migration Your Phone to Webex Calling. Якщо ви використовуєте цей інструмент для перевірки відповідності пристрою, виберіть параметр «Міграція» Ство рити лише ліцензію на пристрій.

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

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

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

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

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

Використовуйте інструмент готовності IP-телефонів Cisco

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

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

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

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

Користувачі

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

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

Розгортання з

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

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

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

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

Пошук каталогу додатків Webex

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

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

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

Моніторинг BLF

Той самий пілот/група полювання

Поділитися рядками

Частина тієї ж групи прийому дзвінків

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

Домофон

Адміністратор/Виконавець

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

Таблиця 4. План переходу користувача за сайтом
Сайт користувача/місцезнаходження	Передперехідна інформація та навчальні заняття	Перехідний період	Підтримка після переходу
NYC (1 525 користувачів)	Тиждень 1 квітня	Квітень 15 — Квітень 27	Тиждень 29 квітня
SFO (1 600 користувачів)	Тиждень 6 травня	20 травня — 31 травня	Тиждень 3 червня
RTP (1 275 користувачів)	Тиждень 3 червня	17 червня — 28 червня	Тиждень 1 липня

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

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

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

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

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

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

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

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

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

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

експорт налаштувань - масовий експорт або AXL

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

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

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

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

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

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

Огляд хмарної аналітики UC в

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

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

(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-телефони, пристрої з ОС кімнати, ATA та сторонні особи)
DevicePoolNumbers.txt
Список всіх номерів у певному пулі пристроїв
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Детальна інформація про пристрої та користувачів, які слід мігрувати разом на основі спільних ліній, пілота пошуку, черги викликів, паркування викликів та конфігурації групи викликів
HuntGroupMigrationInsight.csv
Детальна інформація про призначені лінії полювання, групи ліній та асоційованих агентів
SharedlineGroupMigrationReport.csv
Огляд спільного використання телефон них номерів (номерів каталогів) між користувачами

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

Докладніші відомості про звіти Migration Insights див. у статті Інформація про мігра цію.

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

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

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

Інтеграція Cisco: Підключення Unity UCCX UCCE

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

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

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

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

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

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

Запис Dubber Go (пропозиція партнера) - інтеграція між і дуббером, де всі записані носії надійно зберігаються в хмарі.

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

Таблиця 7. включені параметри запису
Webex Дуббер Go

Доступно всім користувачам Доступно всім користувачам

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

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

100 ГБ пам'яті на організацію -

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

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

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

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

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

Інтеграція третіх сторін

підтримує різноманітні інтеграції третьої сторони^, включаючи, але не обмежуючись ними, SBC для локальних шлюзів, IP-телефонів, домофонів, динаміків/пейджерів, 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 App високого рівня, локальна інфраструктура не змінюється, і працює так само, як це робить Jabber. Єдина зміна полягає в тому, що вимагає підключення до.

Докладніші відомості про цей перехід див. у розділі «Клієнт» на сторінці «Перехід для співпраці» у розділі «Клієнт» на сторінці «Перехід до співпраці».

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

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

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

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

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

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

Дизайн

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

Місцезнаходження

PSTN

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

Місцевий план набору номера в

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

Запис

1. Вибір провайдера запису дзві нків

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

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

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

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

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

Масове призначення за допомогою шаблону CSV

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

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

Забезпечення користувача

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

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

Розробка груп користувачів

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

Підтримка декількох IdP

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

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

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

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

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

6. Спрощений досвід користувача

Дует MFA з SSO для

Особливості

Автосервіс

Дзвінок Парку

Прийом дзвінків

Черга дзвінків

Хант Груп

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

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

Записи

Охоплення одного номера

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

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

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

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

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

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

Місцезнаходження

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

PSTN

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

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

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

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

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

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

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

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

Місцевий план набору номера

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

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

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

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

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

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

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

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

Примусова мережа від до

Розширений набір номера з до (міжсайтовий).

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

На малюнку План на бору передових практик показано найкращі практики підходу до плану набору номера, як описано в розділі «Бажана архітектура для локального розгортання Cisco Collaboration 12.x Enterprise Local Deployments, 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-значний буде або збігатися з номером каталогу +E.164 у розділі DN, або одним із шаблонів маршруту PSTN у розділі USPSTNNational або SJCpStnLocal. Скорочені внутрішньосайтові та міжсайтові звички набору реалізовані перекладами в розділі ES N та 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 у розділі.

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

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

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

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

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

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

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

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

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

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

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

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

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

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

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

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

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

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

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

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

Сайт Розширення Код сайту Підприємницький асортимент Ода сайту Підприємство англ

NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX

SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 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

Для розгортання телефонії в США, які повинні забезпечувати розширені рішення для екстрених викликів, використовує Horizon Mobility RedSky, інтегровану для маршрутизації екстрених викликів. При використанні 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 та API ліцензій), які можна використовувати для автоматизації присвоєння ліцензій. API ліцензій дозволяє одночасне присвоєння ліцензій, номерів телефонів і розширень.
Таблиця 5. Параметри забезпечення користувача - резюме
Метод призначення плюси мінуси
Ручний наскрізний Простий для небагатьох користувачів.
Дозволяє точний і детальний контроль над присво єнням ліцензії.
Не масштабується, трудомісткий
Схильний до людських помилок під час ру чного введення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

П@@ лан дзвінків Cisco (план вихідних дзвінків): кількість користувачів, яким потрібен номер PSTN та/або доступ до вихід них дзвінків 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 до. Він повністю керований всередині і вимагає мінімального налаштування.

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

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

Забезпечення API: Публічні API (Люди, SCIM 2.0) можна використовувати для надання користувачам. Основною перевагою використання API є можливість інтеграції резервування користувачів з іншими корпоратив ними системами.
Таблиця 6. Параметри надання користувачем для
Метод забезпечення Опис плюси мінуси
Посібник Створють/керуйте користувачами окремо в Простий для небагатьох користувачів; не потрібна інфраструктура Не масштабується; трудомісткий для багатьох користувачів
Масова кількість (файл CSV) Імпортував/оновлюйте користувачів масово через 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. Параметри керування групами та членством у групах
Варіант Опис плюси мінуси

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

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

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

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

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

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

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

Cisco рекомендує використовувати централізований хмарний каталог, такий як Microsoft Entra ID (Azure AD), як єди не джерело істини для ідентифікацій користувачів. Синхронізація користувачів з ідентифікатором Entra для забезпечення послідовності, спрощення керування та підтримки можливостей єдиного входу (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 App і User.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дуо Cisco

Окта

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

Майкрософт Азур

Пінгфедерат

ОпенАМ

F5 BIG-IP.

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

Підтримка декількох IdP

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

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

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

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

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

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

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

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

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

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

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

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

6. Спрощений досвід користувача

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

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

Дует МФА з SSO для

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

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

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

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

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

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

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

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

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

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

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

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

Особливості

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

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

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

Webex Callingосновні особливості

Автосервіс

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

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

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

Ділові та позаробочі графіки

Графік відпусток

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

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

Набрати за назвою опція

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

Аналітика та звіти Control Hub.

Докладніші відомості див. у розділі Керування автоматичними обслуговуючи ми службами.

Дзвінок Парку

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

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

Call park direct - дозволяє будь-якому користувачеві припаркувати дзвінок на розширення іншого користувача або на розширення парку викликів, як це визначено Адміністратором

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

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

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

Докладніші відомості див. у розділі Керування парком викликів у Центрі керування.

Підбір дзвінків

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

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

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

:

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

Повідомлення про вхідний дзвінок

Прийом дзвінків на основі FACS (наберіть *98) або сповіщення

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

Настільні телефони:

Повідомлення про вхідний дзвінок

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

Коли тип сповіщення обраний у списку не є жод ен

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

Докладніші відомості див. у розділі Налаштування групи прийому дзвінків.

Черга дзвінків

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

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

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

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

Тримайте музику

Зворотний дзвінок

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

Вхід/вихід з черги агента

Управління статусом черги агента

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

Агент супервайзера зателефонує до монітора, тренера, баржі або бере участь за допомогою кодів доступу до функцій (FACS)

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

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

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

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

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

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

Хант Груп

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

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

Докладніші відомості див. у розділі Керування групами пошуку в Центрі керування.

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

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

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

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

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

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

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

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

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

Записи

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

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

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

Охоплення одного номера

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

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

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

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

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

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

Додати опцію голосової пошти до автоматичної служби супроводу або групи пошуку

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

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

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

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

Докладніші відомості див. у статті Початок роботи з консоллю супутника.

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

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

Таблиця 2. Приклад нумерації підприємства
Сайт	Діапазон розширення	Код сайту	Підприємницький асортимент
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

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

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

Сайт	Розширення	Код сайту	Підприємницький асортимент	Ода сайту	Підприємство англ
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

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

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

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

Впровадити

Мережева готовність

Початкова настройка

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

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

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

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

Закупівля, надання та перевірка ліцензій

Webex Callingнастройки сервісу

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

Закупіть ПСТН

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

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

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

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

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

Налаштування функцій

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

Мережева готовність

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Початкова настройка

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

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

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

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

Докладніші відомості про керування доменами див. у розділі Керування доменами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Приклад кроків реалізації:

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

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

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

Налаштуйте роз'єм каталогів за допомогою фільтра LDAP, наприклад: (MemberOF=CN = Група синхронізації WebEx, OU = Групи, DC = Ваш домен, DC = COM).

У корпорації Майкрософт введіть ідентифікатор:

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

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

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

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

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

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

Посилання:

Синхронізація користувачів ідентифікатора Entra з Контрольним центром

Налаштування програми майстра ідентифікатора Entra ID у Центрі керування

Роз'єм каталогу

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

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

На цьому етапі розроблена настройка SSO повинна бути реалізована та протестована.

Посилання:

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

налаштувати єдиний вхід для адміністрування webex

Налаштування єдиного входу за допомогою ідентифікатора Microsoft Entra

SSO з декількома ВПО

Керування SSO при інтеграції в Контрольному центрі

Закупівля, надання та перевірка ліцензій

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

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

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

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

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

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

Webex Callingнастройки сервісу

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

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

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

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

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

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

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

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

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

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

Закупіть ПСТН

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У тому ж полюванні пілот, черга викликів і т.д.

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

Використання підбору дзвінків

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

Домофон

Керівник/Адміністратор.

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

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

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

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

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

Перевірте, що всі користувачі перебувають

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

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

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

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

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

Інструменти використання - інструменти міграції користувачів та функцій та/або сторонні інструменти

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

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

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

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

Орієнтований на розташування: прив'язаний до фізичних просторів.

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

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

Докладніші відомості про робочі простори в розділі Робочі простори.

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

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

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

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

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

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

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

CUCM v15 - уніфікований менеджер комунікацій версії 15

CUCM v14 - уніфікований менеджер комунікацій версії 14.

Для отримання додаткової інформації про процес реєстрації для серії 9800 див. Процес реєстрації .

Окрім IP-телефонів Cisco, може знадобитися забезпечення інших пристроїв, таких як аналогові телефонні адаптери (ATA), бездротові (Wifi, DECT) телефони, відеопристрої, голосові шлюзи, а також пристрої ^та телефони третьої сторони. Багато з цих пристроїв не мають шляху оновлення мікропрограми , як IP-телефони, для переходу їх від корпоративної прошивки до хмарної прошивки. Тому ви забезпечите кожен із цих пристроїв у Контрольному центрі. Деякі з них неможливо перевести, і еквівалентну модель потрібно буде замінити її (напр. ATA 191/192) та інші потребують ручної переналаштування та/або зміни програмного забезпечення.

Голосові шлюзи. Щоб перенести локальний шлюз, див. розділ Міграція локального шлюзу.
Докладніші відомості щодо налаштування голосового шлюзу VG400, VG410 або VG420 у Центрі керування див. розділ Локальний шлюз

Аналоговий телефонний адаптер (ATA) - Для початку роботи з Cisco ATA 191 і 192 див. Cisco ATA.

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

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

Щоб створити та керувати цифровою мережею DECT у Control Hub, див. розділ Керування мереже ю DEC T

Для отримання додаткової інформації про Cisco IP DECT 6800 див. Посібник із розгортання

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

Налаштування функцій

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

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

Автосервіси - Щоб керувати автосервісами, див. розділ Автосервіси

Парк викликів - Щоб керувати парком викликів, див. Парк викликів

Прийом дзвінків. Щоб налаштувати групу прийому дзвінків, див. розділ Прийо м дзві нків

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

Групи полювання - Щоб керувати групами полювання, див. розділ Керування групою полювання

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

Групи сторінок. Щоб налаштувати групу підкачки, див. розділ Налаштування групи підказок

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

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

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

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

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

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

Забезпечення користувача та присвоєння номера

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

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

Потоки дзвінків PSTN та презентація ідентифікатора абонента

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

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

Потоки дзвінків в мережі

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

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

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

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

Черги дзвінків: досвід агента та керівника

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

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

Групи полювання: Розподіл дзвінків

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

Автосервіси: Оголошення та операції меню

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

Операція голосової пошти

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

Оптимізувати

Міграція PSTN до хмарного підключення для

Оптимізація локальної інфраструктури

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

Міграція PSTN до хмарного підключення для

Після перенесення всіх кінцевих точок та користувачів до хмарних викликів єдиною метою 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, крім виведення з експлуатації та локальних шлюзів.

Оптимізація локальної інфраструктури

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

Видаліть локальні DNS SRV записи керування викликами та повідомленнями з локальних серверів DNS, включаючи cisco_uds. _tcp. <domain>, вхід на чашку. _tcp. <domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб.

Видаліть DNS SRV записи, пов'язані з краями, з загальнодоступної системи DNS, включаючи collab_edge. _тлс. <domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб периферійних служб співпраці.

Оновіть всі відповідні області DHCP, щоб видалити адреси TFTP/завантажувального сервера опції 66 та параметра 150. Ці області більше не потрібні для виявлення та завантаження конфігурації керування викликом кінцевих точок.

Оновлення/видалення відповідних аналогів у локальному шлюзі/кубі, які маршрутизують дзвінки до та з. Unified CM Ці аналоги комутованого зв'язку більше не потрібні для локальної маршрутизації викликів.

Видалити або видалити всі віртуальні машини і/або сервери вузлів кластерів. За потреби змінюйте обчислювальні ресурси та обладнання . Ці ресурси більше не потрібні для керування викликами та крайових служб.

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

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

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

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

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

Заміна мережевого комутатора

Заміна бездротової точки доступу

Зміни сфери DHCP

Фізичні зміни всередині будівлі (якщо вони вирішуються на кубічні/офіс)

Фізичне розширення або скорочення офісного приміщення всередині будівлі.

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

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

аналітика якості медіа

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

усунення несправностей якості медіа

усунення несправностей також можна інтегрувати з іншими продуктами Cisco, такими як комутатори ThousandEyes та Meraki, щоб забезпечити ще багатший інтегрований досвід роботи в Control Hub. Докладніші відо мості про використання Webex Callingаналітики та усунення неполадок див. у розділі Виправ лення не Webex Calling поладок викликів у Центрі керування.

Вступ

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

Огляд

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

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

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

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

Підготуйте

План

Дизайн

Реалізуйте

Оптимізувати

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

Міграційний підхід

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

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

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

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

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

Контрольний хаб

Забезпечення каталогів і користувачів

Webex Callingплатформа

Підтримувані кінцеві точки виклику

Параметри підключення PSTN

Webex Callingплан набору номера і управління номерами

Функції безпеки та відповідності.

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

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

Інструменти міграції Webex: безкоштовні інструменти самообслуговування, вбудовані в Центр керування, щоб спростити перехід до Webex Calling

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

Webex Setup Assist: служ ба міграції під керівництвом 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-телефони Cisco, відео системи Cisco Desk and Room) та програмне забезпечення () кінцеві точки на основі IP. Cisco Jabber Ці компоненти можуть дещо відрізнятися в деяких середовищах, але це відправна точка для переходу, описаного в решті цього документа.

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

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

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

Таблиця 1. До: Компоненти локальної інфраструктури викликів
Продукт Опис

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

Cisco Expressway-С/Е Передгранна інфраструктура, що забезпечує мобіль Remote Access ні та (MRA) та функціональні можливості між бізнесом (B2B), що дозволяє віддаленим кінцевим точкам безпечно підключатися з-за меж організації . Expressway розгортається парами, щоб забезпечити об'їзд брандмау ера для зовнішніх кінцевих точок.

Сервер нарад Cisco (CMS), керування зустрічами Cisco (CMM) та пакет керування телеприсутністю Cisco (TMS) Локальна інфраструктура голосових, відео та веб-конференцій, що забезпечує багатоточкові зустрічі, управління нарадами та можливості планування. [Необов'язково]

Cisco Unity Connection Локальна платформа голосових повідомлень, що забезпечує голосову пошту та уніфіковані можливості обміну повідомленнями. [Необов'язково]

Робочий стіл Cisco, кімната Cisco, плата Cisco, IP-телефони Cisco та Cisco Jabber Пристрої на основі IP, зареєстровані Unified CM та надають можливості голосових та відеодзвінків

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

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

Моделі телефонів, які не підтримуються Webex Calling

Складні або численні інтеграції з іншими локальними системами або рішеннями, особливо там, де відтворення цих інтеграцій важко або немає еквівалентних альтернативних рішень Webex Calling

Складний план набору номера, високодетальні класи послуг або обидва

Обмежений, обмежений або ненадійний доступ до Інтернету

Сувора політика конфіденційності даних та права власності

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

Інтеграція третіх сторін без життєздатної альтернатив Webex Calling ної інтеграції

Інтеграція контакт-центру, де контакт-центр ще не переходить у хма ру.

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

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

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

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

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

Після: Архі Webex Calling тектура

Після: Таблиця компонентів інфраструктури викликів хма ри містить список нових елементів архітектури після переходу на Webex.

Таблиця 2. Після: Компоненти інфраструктури хмарних дзвінків
Продукт Опис

Webex Calling Служба дзвінків у хмарі, що надається з платформи Webex та забезпечує реєстрацію кінцевих точок та маршрутизацію дзвінків

Роз'єм каталогу Cisco Програма Windows, що працює на доменній машині Windows, що забезпечує синхронізацію ідентифікацій між локальним корпоративним схови Active Directory щем та с ховищем ідентифікацій організації Webex.
Для клієнтів, які переходять з локального на іденти Active Directory фікатор Entra ID, інтеграція ідентичності з Webex замість Cisco Directory Connector використовує додаток Майстер ідентифікатора Entra ID.

Локальний шлюз Локальний шлюз діє як міст між локальною уніфікованою мережею зв'язку клієнта та Webex Calling хмарою. Він може бути розгорнутий локально або розміщений партнером, забезпечуючи доступ PSTN для кінцевих точок, зареєстрованих у хмарі, а також виклик інтеграції між зареєстрованими та Unified CM зареєстрованими в хмарі кінцевими точками. Cisco IOS-Маршрутизатор інтегрованих служб XE (серії ISR 1100 та 4000), серія Cisco Catalyst 8200/8300, програмне забезпечення Cisco Catalyst 8000V Edge та різні сертифіковані сторонні контролери кордонів сесій (SBC) можуть використовуватися як LGW для підходу поетапної міграції.

Шлюз виживання Шлюз Survivalability (SGW) - це локальний мережевий шлюз на базі IOS-XE, який надає послуги резервних дзвінків до кінцевих точок на місці під час відключень мережі. Webex Calling

План дзвінків Cisco, хмарне підключення для Webex Calling План дзвінків Cisco та Cloud Connect for - Webex Calling це хмарні варіанти доступу PSTN для кінцевих точок. Webex Calling Доступ до PSTN полегшується хмарним постачальником PSTN і не вимагає локального обладнання.

Додаток Webex Клієнтський додаток працює на настільних ОС (Windows, Mac) або мобільних ОС (Android, iOS) і зареєстрований безпосередньо на Webex Calling платформі для функціоналу виклику.

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

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

Процес PPDIO

Загальний опис 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 разом із сторонніми інструментами для виконання змін режиму мікропрограми пристрою, конфігурації функцій та міграції користувачів

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

Виконання надання ліцензій, реєстрації пристрою та оновлення конфігурації

Перевірте успішність міграції за допомогою тестування та опера ційної перевірки.

Оптимізувати

Постійно відсте Webex Calling жуйте продуктивність та досвід користувача

Уточнити конфігурації та робочі процеси на основі оперативних даних та зворотного зв'язку

Використовуйте можливості автоматизації та інтеграції для підвищення ефективності та масштабованості

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

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

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

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

Ітерації під час виконання PPDIO

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

Unified CMдопоміжний процес PPDIO

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

Міграційний підхід

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

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

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

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

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

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

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

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

Рекомендований 3-фазний перехід

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

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

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

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

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

Передміграційна діяльність

Підготуйте

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

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

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

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

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

Налаштування хмарного зв'язку

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

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

Місцезнаходження/Сайти

Інвентаризація існуючих пристроїв/клієнтів

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

Користувачі

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

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

Інтеграція Cisco: Підключення Unity UCCX UCCE

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

Інтеграція третіх сторін

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

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

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

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

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

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

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

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

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

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

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

Політика відповідності та безпеки

Бюджетні обмеження та очікування витрат

Навчання користувачів та потреби в підтримці

Хронологія міграції та міркування безперервності бізнесу.

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

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

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

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

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

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

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

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

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

Забезпечення безпеки постачальників: оцінка сертифікатів безпеки та сертифікатів відповідності Cisco для забезпечення надійності.

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

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

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

Документація: надайте чіткі та доступні посібники користувача, поширені запитання та короткі довідкові матеріали, зокрема ресурси «Що нового» та «Різ не», а також покрокові інструкції до та після (у форматі відео або короткого посібника), щоб підтримати користувачів під час адаптації до оновленого досвіду після міграції.

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

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

Постійна освіта: Плануйте постійні оновлення тренінгів у міру випуску нових функцій або онов лень.

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

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

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

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

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

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

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

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

Підключення до мережі WAN та Інтернету: перевірка того, чи зв'язки WAN та підключення до Інтернету відповідають вимогам хмарних дзвінків, включаючи можливості резервування та відмови.

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

Інтеграція з існуючою системою

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

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

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

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

Сумісність кінцевих точок і забезпечення

Усі кінцеві точки, включаючи настільні телефони, софт-телефони та мобільні пристрої, повинні бути оцінені на сумісність:

Підтримка пристроїв: підтвердження підтримки існуючих IP-телефонів та пристроїв або визначення необхідних замін.

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

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

Конфігурації безпеки та стандарти шифрування

Безпека має першорядне значення в хмарних комунікаціях:

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

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

Відповідність: Заб езпечення відповідності рішення відповідним норматив ним і галузевим стандартам (наприклад, GDPR, HIPAA).

Моніторинг безпеки: Інтеграція з інструментами SIEM та налаштування оповіщення про потенційні інциденти безпеки.

Таблиця 1. Приклад оцінки
вимога Ключові міркування

Мережева готовність і пропускна здатність Пропускна здатність, QoS, WAN/Інтернет, брандмауер/NAT

Інтеграція з існуючими системами Довідник, CRM, АТС, Електронна пошта/Календар

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

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

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

Переносність номера та план набору номера Міграція/портування номера, переклад тарифного плану

Інтеграція третіх сторін Пейджінг, контакт-центр, факс, аналогові пристрої

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

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

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

Клієнти та партнери мають доступ до можливостей підключення за межами поточного Інтернету (OTT) , які можуть оптимізувати підключення до вклю Webex Edge чення Connect. Для отримання додаткової інформації про подроб Webex Edge иці дизайну Connect див. статтю П ріоритетна архітектура Cisco для Webex Edge підключенняWebex Meetings, виклик для кількох орендарів та виділений екземпляр .

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

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

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

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

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

Кількість очікуваних одночасних викликів * Пропускна здатність на дзвінок на основі кодека = Необхідна пропускна здатність мережі.
Таблиця 2. Webex Calling розрахунки пропускної здатності типу виклику
Типи дзвінків Кодек - пропускна здатність Розрахунок пропускної здатності
/Настільний телефон -> ОПУС - 70 кбіт/с Кількість одночасних дзвінків* 70 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> Настільний телефон ОПУС — 70 кбіт/с Кількість одночасних дзвінків* 70 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> PSTN через LGW Г.711 — 80 кбіт/с Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> PSTN через хмарний PSTN (напр. План дзвінків Cisco) Г.711 — 80 кбіт/с Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> Підприємство через LGW Г.722 — 80 кбіт/с Кількість одночасних викликів* 80 кбіт/с = Необхідна пропускна здатність мережі
/Настільний телефон -> голосова пошта ОПУС — 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 кбіт/с = 8 000 кбіт/с
Додаток Webex/Настільний телефон → PSTN через хмарне підключення для 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 між комутаторами, маршрутизато рами та брандмауерами.

Цілі затримки, тремтіння та втрати пакетів

Наступні пороги рекомендуються для оптимальної якості голосу, коли дзвінки переходять через Інтернет (Over-the-Top) (OTT):

Затримка - менше 100 мс в один бік

Диттер - менше 10 мс

Втрата пакетів - 0,5% або менше.

Брандмауер і NAT

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

DNS і НТП

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

Планування відмови

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

Живучість сайту

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

Налаштування хмарного зв'язку UC

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

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

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

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

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

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

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

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

Платформа

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

Користувачі та пристрої

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

Локальний шлюз

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

Місцезнаходження/Сайти

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

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

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

Інвентаризація існуючих пристроїв/клієнтів

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

Настільні телефони

Для аудіо та відео настільних телефонів підтримуються лише настільні телефони серії 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, див. розділ Перетворення IP-телефонів Cisco 7800 та 8800 між прошивкою Enterprise та MPP.

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. Будь-яка з цих кінцевих точок, яка потребує здійснення аудіо та/або дзвінків PSTN, вимагає ліцензії на виклик:

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

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

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

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

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

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

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

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

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

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

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

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

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

Для отримання додаткової інформації про ці два варіанти див. Мі граційна подорож - один або два кроки? .

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

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

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

Щоб допомогти визначити придатність телефонів, Контрольний центр має вбудований інструмент під назвою Migration Your Phone to Webex Calling. Якщо ви використовуєте цей інструмент для перевірки відповідності пристрою, виберіть параметр «Міграція» Ство рити лише ліцензію на пристрій.

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

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

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

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

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

Використовуйте інструмент готовності IP-телефонів Cisco

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

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

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

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

Користувачі

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

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

Розгортання з

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

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

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

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

Пошук каталогу додатків Webex

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

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

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

Моніторинг BLF

Той самий пілот/група полювання

Поділитися рядками

Частина тієї ж групи прийому дзвінків

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

Домофон

Адміністратор/Виконавець

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

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

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

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

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

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

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

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

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

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

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

експорт налаштувань - масовий експорт або AXL

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

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

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

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

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

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

Огляд хмарної аналітики UC в

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

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

(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-телефони, пристрої з ОС кімнати, ATA та сторонні особи)
DevicePoolNumbers.txt
Список всіх номерів у певному пулі пристроїв
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Детальна інформація про пристрої та користувачів, які слід мігрувати разом на основі спільних ліній, пілота пошуку, черги викликів, паркування викликів та конфігурації групи викликів
HuntGroupMigrationInsight.csv
Детальна інформація про призначені лінії полювання, групи ліній та асоційованих агентів
SharedlineGroupMigrationReport.csv
Огляд спільного використання телефон них номерів (номерів каталогів) між користувачами

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

Докладніші відомості про звіти Migration Insights див. у статті Інформація про мігра цію.

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

Інтеграція Cisco: Підключення Unity UCCX UCCE

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

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

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

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

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

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

Запис Dubber Go (пропозиція партнера) - інтеграція між і дуббером, де всі записані носії надійно зберігаються в хмарі.

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

Таблиця 7. включені параметри запису
Webex Дуббер Go

Доступно всім користувачам Доступно всім користувачам

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

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

100 ГБ пам'яті на організацію -

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

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

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

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

Інтеграція третіх сторін

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

Таблиця 4. План переходу користувача за сайтом
Сайт користувача/місцезнаходження	Передперехідна інформація та навчальні заняття	Перехідний період	Підтримка після переходу
NYC (1 525 користувачів)	Тиждень 1 квітня	Квітень 15 — Квітень 27	Тиждень 29 квітня
SFO (1 600 користувачів)	Тиждень 6 травня	20 травня — 31 травня	Тиждень 3 червня
RTP (1 275 користувачів)	Тиждень 3 червня	17 червня — 28 червня	Тиждень 1 липня

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

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

Таблиця 7. включені параметри запису
Webex	Дуббер Go
Доступно всім користувачам	Доступно всім користувачам
Необмежена кількість записів	Необмежена кількість записів
Термін зберігання 1 рік*	30-денний термін зберігання
100 ГБ пам'яті на організацію	-
Працівники комплаєнсу можуть отримувати доступ до записів дзвінків та керувати	-
API для управління записами	-
Адміністратори можуть налаштовувати і керувати доступом користувачів до записів дзвінків Користувачі можуть керувати власними записами за допомогою User Hub та/або програми 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 App високого рівня, локальна інфраструктура не змінюється, і працює так само, як це робить Jabber. Єдина зміна полягає в тому, що вимагає підключення до.

Докладніші відомості про цей перехід див. у розділі «Клієнт» на сторінці «Перехід для співпраці» у розділі «Клієнт» на сторінці «Перехід до співпраці».

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

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

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

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

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

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

Дизайн

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

Місцезнаходження

PSTN

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

Місцевий план набору номера в

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

Запис

1. Вибір провайдера запису дзві нків

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

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

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

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

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

Масове призначення за допомогою шаблону CSV

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

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

Забезпечення користувача

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

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

Розробка груп користувачів

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

Підтримка декількох IdP

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

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

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

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

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

6. Спрощений досвід користувача

Дует MFA з SSO для

Особливості

Автосервіс

Дзвінок Парку

Прийом дзвінків

Черга дзвінків

Хант Груп

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

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

Записи

Охоплення одного номера

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

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

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

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

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

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

Місцезнаходження

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

PSTN

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

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

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

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

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

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

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

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

Місцевий план набору номера

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

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

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

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

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

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

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

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

Примусова мережа від до

Розширений набір номера з до (міжсайтовий).

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

На малюнку План на бору передових практик показано найкращі практики підходу до плану набору номера, як описано в розділі «Бажана архітектура для локального розгортання Cisco Collaboration 12.x Enterprise Local Deployments, 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-значний буде або збігатися з номером каталогу +E.164 у розділі DN, або одним із шаблонів маршруту PSTN у розділі USPSTNNational або SJCpStnLocal. Скорочені внутрішньосайтові та міжсайтові звички набору реалізовані перекладами в розділі ES N та 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 у розділі.

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

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

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

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

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

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

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

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

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

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

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

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

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

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

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

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

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

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

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

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

Сайт Розширення Код сайту Підприємницький асортимент Ода сайту Підприємство англ

NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX

SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 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

Для розгортання телефонії в США, які повинні забезпечувати розширені рішення для екстрених викликів, використовує Horizon Mobility RedSky, інтегровану для маршрутизації екстрених викликів. При використанні 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 та API ліцензій), які можна використовувати для автоматизації присвоєння ліцензій. API ліцензій дозволяє одночасне присвоєння ліцензій, номерів телефонів і розширень.
Таблиця 5. Параметри забезпечення користувача - резюме
Метод призначення плюси мінуси
Ручний наскрізний Простий для небагатьох користувачів.
Дозволяє точний і детальний контроль над присво єнням ліцензії.
Не масштабується, трудомісткий
Схильний до людських помилок під час ру чного введення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

П@@ лан дзвінків Cisco (план вихідних дзвінків): кількість користувачів, яким потрібен номер PSTN та/або доступ до вихід них дзвінків 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 до. Він повністю керований всередині і вимагає мінімального налаштування.

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

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

Забезпечення API: Публічні API (Люди, SCIM 2.0) можна використовувати для надання користувачам. Основною перевагою використання API є можливість інтеграції резервування користувачів з іншими корпоратив ними системами.
Таблиця 6. Параметри надання користувачем для
Метод забезпечення Опис плюси мінуси
Посібник Створють/керуйте користувачами окремо в Простий для небагатьох користувачів; не потрібна інфраструктура Не масштабується; трудомісткий для багатьох користувачів
Масова кількість (файл CSV) Імпортував/оновлюйте користувачів масово через 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. Параметри керування групами та членством у групах
Варіант Опис плюси мінуси

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

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

Групи та SCIM 2.0 API (групи) Використовуйте Groups або SCIM 2.0 API для програмного керування групами та членством Автоматизація та інтеграція з іншими системами
Масштабовується для великих або складних середовищ
Потрібні зусилля з розвитку
Складність залежить від використання API

Хоча синхронізовані групи забезпечують послідовність і пропонують єдину точку адміністрування, можливий гібридний підхід, що поєднує синхронізовані групи та групи (керовані в центрі управління або через API). Так, наприклад, групи для присвоєння ліцензії можуть бути синхронізованими групами, а окремий набір груп може використовуватися для призначення користувацьких і викликових шаблонів.

Цей комплексний підхід до управління групами користувачів дозволяє організаціям ефективно керувати ліцензіями користувачів, налаштуваннями та політиками, забезпечуючи послідовний та масштабований досвід співпраці.

Рекомендований підхід при міграції з на

Основним джерелом даних для користувачів є база даних, яка містить інформацію про кінцевого користувача. Однак, як правило, не є авторитетним джерелом для управління ідентифікаційними даними користувачів, і, що ще важливі ше, буде закрито в кінці переходу, і тому виключається як довгострокове авторитетне джерело інформації про особу.

Cisco рекомендує використовувати централізований хмарний каталог, такий як Microsoft Entra ID (Azure AD), як єди не джерело істини для ідентифікацій користувачів. Синхронізація користувачів з ідентифікатором Entra для забезпечення послідовності, спрощення керування та підтримки можливостей єдиного входу (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 App і User.

Синхронізація каталогів: чи буде ця група синхронізована з корпоративного каталогу чи це локальна група Webex, створена в Центрі керування або через API.

Опис: як буде використовуватися ця група і які користувачі повинні бути членами цієї групи

Ці дані будуть використані пізніше на етапі впровадження для створення локальних груп або груп у каталозі підприємства та управління член ством користувачів у групах.

Єдиний вхід (SSO)

Cisco рекомендує використовувати SSO для автентифікації користувачів. Використання SSO має деякі переконливі переваги, включаючи:

Спрощена автентифікація користувачів: Користувачі можуть увійти один раз, використовуючи свої корпоративні облікові дані (наприклад, з Azure ID) для доступу до інших інтегрованих програм, що виключає необхідність використання декількох паролів та зменшує кількість запитів про вхід. Це підвищує безпеку, гарантуючи, що корпоративні паролі ніколи не зберігаються або передаються після аутентифікації.

Спрощене управління користувачами: Автоматизує створення, оновлення та деактивацію облікових записів користувачів на основі змін у корпоративному каталозі, зменшуючи адміністративні витрати та забезпечуючи доступ лише авторизованим користувачам.

Покращена безпека: SSO зменшує втому пароля та ризик порушень, пов'язаних з паролем, шляхом централізації автенти фікації через довірених постачальників ідентифікацій (ВПО).

Проста інтеграція багатофакторної аутентифікації (MFA): MFA можна легко підтримувати або за допомогою рішення для управління доступом до ідентифікацій, як- от Cisco Duo, або через підтримку M FA IdP.

Існує кілька варіантів впровадження SSO для послуг:

SSO на основі SAML 2.0: основний протокол, що підтримується для інтеграції SSO, що забезпечує безпечний обмін інформацією про автентифікацію між Id P та постачальником послуг.

OpenID connect (OIDC): Підтримується як альтернативний сучасний протокол аутентифікації для інтеграції SSO.

Ідентифікація Webex: також підтримується як параметр постачальника ідентифікацій.

SSO налаштовується та керується централізовано, вимагаючи обміну метаданими між вибраним IdP.

Після конфігурації SSO можна протестувати перед активацією, щоб забезпечити належне налаштування.

Cisco підтримує інтеграцію з кількома перевіреними та часто використовуваними ВПО та системами управління іденти фікаціями (IAM), включаючи, але не обмежуючись ними:

Дуо Cisco

Окта

Microsoft Active DirectoryСлужби федерації (ADFS)

Майкрософт Азур

Пінгфедерат

ОпенАМ

F5 BIG-IP.

Ці ВПО відповідають стандартам SAML 2.0 або OpenID Connect і пройшли перевірку на сумісність з рішеннями для співпраці Cisco.

Підтримка декількох IdP

дозволяє організаціям налаштовувати SSO з декількома ВПО для розміщення складних ІТ- середовищ, таких як злиття, поглинання або децентралізовані ІТ-відділи, де різні групи використовують різних ВПО. Підтримка декількох IdP може бути реалізована за допомогою функції Multi ple IdP або через інтеграцію корпоративної системи IAM, як-от Cisco Duo.

Підтримка декількох постачальників ідентифікацій (IdP) вирішує кілька ключових випадків використання, коли організації потребують гнучкої та безпечної аутентифікації в різних ІТ-середовищах:

1. Злиття та поглинання

Коли компанії об'єднуються або купують інші, вони часто мають окрему ІТ-інфраструктуру та окремі ВПО, які не можуть об'єднуватися. Підтримка декількох IdP дозволяє користувачам з обох організацій безпечно здійснювати автентифікацію та співпрацювати без необхідності негайно уніфікувати свої системи ідентифікації.

2. Кілька незалежних ІТ-відділів

Великі організації або державні установи можуть мати кілька незалежних ІТ-відділів, кожен з яких керує власним ВПО. функція декількох IdP дозволяє цим відділам підтримувати власні системи аутентифікації, дозволяючи користувачам безперешкодний доступ.

3. Різні групи користувачів або домени

Організації з різними групами користувачів (наприклад, співробітниками чи підрядниками) або декількома доменами електронної пошти можуть налаштовувати правила маршрутизації для направлення запитів на автентифікацію до відповідного Ідентифікатора на основі членства в домені або групі. Це підтримує диференційовану політику доступу та контроль безпеки.

4. Підтримка різних протоколів аутентифікації

підтримує ВПО SAML та OpenID Connect (OIDC), що дозволяє організаціям інтегрувати різні типи постачальників ідентифікацій відповідно до їх існуючої інфраструктури та вимог безпеки.

5. Покращена безпека та відповідність

Увімкнувши декілька ВПО, організації можуть впроваджувати більш сильні механізми аутентифікації, включаючи багатофакторну аутентифікацію (MFA) за допомогою інтеграцій, таких як Duo, і застосовувати послідовні політики безпеки для різних баз користувачів.

6. Спрощений досвід користувача

Користувачі можуть здійснювати аутентифікацію, використовуючи свої існуючі облікові дані від відповідних ВПО, забезпечу ючи уніфікований досвід входу, незважаючи на складність декількох систем ідентифікації.

Хоча підтримка декількох IdP забезпечує гнучкість, вона вимагає ретельної координації між командами безпеки та ідентифікації, щоб підтримувати послідовну політику безпеки та уникати потенційних вразливостей.

Дует МФА з SSO для

Шлюз Duo Access (DAG) може автентифікувати користувачів за допомогою існуючих локальних або хмарних каталогів, таких як Active Directory (AD) і OpenLDAP. Він також підтримує інтеграцію з іншими постачальниками ідентифікацій, такими як Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS та Shibboleth. Ця гнучкість дозволяє організаціям використовувати свою поточну інфраструктуру каталогів для Webex SSO з Duo MFA.

Duo діє як сильний рівень аутентифікації поверх автентифікації основного каталогу. Він функціонує як постачальник ідентифікації (IdP), використовуючи SAML 2.0 для забезпечення двофакторної аутентифікації (2FA) перед наданням доступу до. Duo оцінює контекст користувача, пристрою та мережі відповідно до налаштовуваних політик, щоб дозволити або заборонити доступ , підвищуючи безпеку, окрім лише імені користувача та пароля. Duo також забезпечує гнучкий контроль політики, наприклад, вимагаючи MFA при кожному вході в систему для деяких програм і рідше для інших.

Переваги Cisco Duo включають:

Покращена безпека: Дод ає MFA, стійкий до фішингу, для захисту доступу, зменшуючи ризик скомпрометованих паролів.

Гнучкі політики: Дозволяє детальний контроль над вимогами автентифікації для кожної програми або групи користувачів.

Інтеграція з існуючими каталогами: Підтримує локальні AD, OpenLDAP, хмарні каталоги та різні постачальники SSO, мінімізуючи зміни інфраструктури.

Зручність користувача: Підтримує єдиний вхід (SSO) для зменшення втоми пароля, дозволяючи користувачам входити один раз і безпечно отримувати доступ до декількох ресурсів.

Надійні кінцеві точки: Підтримує довіру до пристроїв для клієнтів у Windows та macOS, покращуючи стан безпеки.

Реєстрація самообслуговування: вбудов ана реєстрація та подвійна підказка покращують досвід користувача під час налаштування MFA.

Duo MFA з SSO для використання існуючих каталогів, таких як Active Directory і OpenLDAP, або постачальників хмарних ідентифікаційних даних, для автентифікації користувачів. Роль Duo полягає в тому, щоб забезпечити сильний, орієнтований на політику другий фактор аутентифікації, інтегрований через SAML 2.0, підвищуючи безпеку, зберігаючи зручність користувача за допомогою SSO. Переваги включають покращення стану безпеки, гнучке дотримання політики, безперебійну інтеграцію та кращий досвід користувача.

Cisco рекомендує впроваджувати SSO для користувачів. Для посиленої безпеки рекомендується інтеграція з Cisco Duo.

Стратегію корпоративного IAM та SSO слід розгорнути перед початком переходу від до.

Особливості

має повний набір основних функцій, які входять в комплект сервісу. Це включає багато функцій дзвінків корпоративного рівня, які доступні протягом багатьох років. Ви можете не бачити 100% парності між функціями та функціями, однак, як ви можете бачити на малюнку нижче, основні функції виклику доступні в.

Webex Callingфункції корпоративного рівня

Окрім багатьох функцій користувача, має основні функції системи, які входять до платформи. До них відносяться такі функції, як автосервіси, черги дзвінків, парк викликів тощо. Ви можете побачити всі доступні основні функції системи в розділі Сервіс → Виклик → Функції, як показано на малюнку Webex Callingосновні функції.

Webex Callingосновні особливості

Автосервіс

Автосервіс забезпечує цілодобову автоматизацію обробки вхідних дзвінків, що дозволяє ефективно обробляти дзвінки без необхідності відповідати людині на кожен дзвінок.

Автосервіс відповідає на вхідні дзвінки і надає абоненту меню параметрів того, куди він хоче направити свій дзвінок. Це може бути для людини, голосової пошти або служби дзвінків (напр. Черга дзвінків). Аб онент використовує клавіатуру свого телефону, щоб ввести номер з меню автоматичної служби підтримки.

Автосервіс підтримує наступні ключові функції:

Ділові та позаробочі графіки

Графік відпусток

Опція меню набору номера, щоб направити клієнтів туди, куди їм потрібно звернутися

Налаштуйте привітання

Набрати за назвою опція

Параметри переадресації викликів

Аналітика та звіти Control Hub.

Докладніші відомості див. у розділі Керування автоматичними обслуговуючи ми службами.

Дзвінок Парку

Парк викликів дає користувачам можливість легко призупинити дзвінок, щоб інший користувач міг легко отримати виклик, коли вони можуть його прийняти. Це також звільняє користувача, який відповів на оригінальний дзвінок, для здійснення або отримання інших дзвінків, поки дзвінок припаркований.

Є два типи парків викликів, доступних у:

Call park direct - дозволяє будь-якому користувачеві припаркувати дзвінок на розширення іншого користувача або на розширення парку викликів, як це визначено Адміністратором

Call park group - дозволяє певній групі користувачів автоматично паркувати дзвінки за доступ ними напрямками парку, визначеними для групи. Ці напрямки можуть бути розширеннями учасників групи або розширеннями парків дзвінків.

Залежно від конфігурації та типу парку користувачі можуть отримувати дзвінки, набравши *88+><extension of parked call>, натиснувши лінійну клавішу, пов'язану з розширенням парку викликів, або використовуючи програмну клавішу на своєму IP-телефоні.

Опція відкликання доступна для відкликання припаркованого дзвінка через визначений період користувачеві, який припаркував дзвінок, або альтернативному користувачеві.

Докладніші відомості див. у розділі Керування парком викликів у Центрі керування.

Підбір дзвінків

Прийом виклику дозволяє адміністратору визначити групу користувачів (учасників), які можуть відповісти на дзвінок на телефон іншого учасника. Це дає користувачеві можливість відповідати на дзвінки, коли його товариші по команді зайняті і не можуть відповісти на вхідний дзвінок.

Користувачі групи повинні знаходитися в одному місці.

Користувачі можуть використовувати або свій настільний телефон, щоб прийняти дзвінок.

:

Підтримує візуальні та аудіо сповіщення

Повідомлення про вхідний дзвінок

Прийом дзвінків на основі FACS (наберіть *98) або сповіщення

Сповіщення про отримання дзвінків для багаторядкових.

Настільні телефони:

Повідомлення про вхідний дзвінок

Звукові куранти та візуальне сповіщення через світлодіод трубки. 6821 підтримує лише звукові куран ти

Коли тип сповіщення обраний у списку не є жод ен

Сповіщення про отримання дзвінків лише для основних ліній.

Докладніші відомості див. у розділі Налаштування групи прийому дзвінків.

Черга дзвінків

включає черги голосових дзвінків як частину своїх основних функцій, і будь-який користувач з ліцензією Professional може бути частиною черги викликів, агентом або керівником. Ця функція дозволяє користува чам ефективно взаємодіяти з клієнтами. Черги викликів підтримують підмножину деяких основних можливостей колл- центру, таких як голосові черги, зворотні дзвінки, маршрутизація навичок або пріоритетів, управління чергою агентів, аналітика, звітність тощо.

Заклик Cisco для інтеграції Microsoft Teams дозволяє агентам отримувати доступ до викликів і функцій черги викликів безпосередньо зі свого клієнта Microsoft Teams.

Черги викликів підтримують наступні ключові функції:

Привітання та повідомлення (вітання, комфорт, шепіт тощо)

Тримайте музику

Зворотний дзвінок

Політика маршрутизації черги (нічне обслуговування, святкові дні, переадресація)

Вхід/вихід з черги агента

Управління статусом черги агента

або підтримка настільного телефону

Агент супервайзера зателефонує до монітора, тренера, баржі або бере участь за допомогою кодів доступу до функцій (FACS)

(доступ адміністратора) для:

управління чергою

Аналітика та звітність агентів та черг

Управління чергою, агентом та супервайзером.

Докладніші відомості див. у розділі Н алаштування черги викликів.

має функцію доповнення Customer Assist, яка забезпечує додаткові можливості черги дзвін ків та надає агентам та керівникам кращий досвід користувача в межах. Для порівняння функцій черги викликів та допомоги клієнтам див. розділ Порівня ння Webex Calling функцій черги викликів та допомоги клієнтам.

Хант Груп

Hunt Groups дозволяють маршрутизувати вхідні дзвінки певній групі користувачів через заздалегідь визначену схему маршрутизації викликів. Це гарантує, що на дзвінки відповідають правильна група користувачів або надсилаються на голосову пошту для подальшого спостереження.

Одна велика відмінність між Hunt Groups і Call Queues полягає в тому, що дзвінки не стоять у черзі в групах полювання, тому якщо жоден користувач у Hunt Group не доступний для відповіді на дзвінок, він буде відключений, відправлений на голосову пошту або переадресований на інший номер (користувач або служба).

Докладніші відомості див. у розділі Керування групами пошуку в Центрі керування.

Режими роботи

Функція режимів роботи дозволяє підприємствам ефективно маршрутизувати дзвінки в різні напрямки (користувачі, голосова пошта, служби викликів, наприклад черга дзвінків). Де і коли маршрутизується дзвінок, базується на графіку часу доби та дня тижня, і будь-який користувач може бути уповноважений керувати цими режимами (розкладами) для контролю змін маршрутизації дзвінків.

Наприклад, дзвінки до черги викликів можуть бути перенаправлені в іншу чергу викликів з агентами в іншому часовому поясі, щоб відповідати на дзвінки в неробочий час, у робочий час перенаправлятися до місцевих агентів, а під час свят - на голосову пошту для подальшого спостереження після повернення аген тів до офісу.

Авторизований користувач може перемикатися між цими різними сценаріями (режимами) переадресації дзвінків, якщо йому потрібно змінити маршрут вхідних дзвінків протягом певного періоду. Ці користувачі можуть керувати режимами через свої телефони 6800/7800/8800 MPP, телефони 9800 або в Центрі користувачів у розділі Керування режимами.

Для отримання додаткової інформації див. Мар шрутизація дзвінків на основі режимів роботи в Webex Calling.

Пейджінгова група

Групи сторінок дозволяють користувачам здійснювати односторонній дзвінок для надсилання аудіоповідомлення групі користувачів. Кожна група може містити до 75 цільових користувачів та/або робочих просторів, до яких можна дістатися шляхом набору попередньо визначеного номера або розширення.

Коли користувач викликає групу сторінок, здійснюється одночасний дзвінок до всіх призначених цілей у групі, після чого абонент може вимовляти свої повідомлення та зависати повідомлення, коли вони закінчаться.

Докладніші відомості див. у розділі Налаштування групи підкачки в Центрі керування.

Записи

підтримує запис дзвінків, зроблених або отриманих користувачем. Це може знадобитися для потреб якості, забезпечення, безпеки або навчання. За замовчуванням дзвінки записуються, але інші сторонні постачальники запису також можуть використовуватися, якщо потрібні інші функції запису або відповідність та нормативним вимогам.

При використанні в якості платформи запису всі записані дзвінки керуються всередині. Повні адміністратори з роллю комплаєнс-офіцера можуть грати та завантажувати записи. Без ролі відповідного співробітника Адміністратор може видаляти лише записи.

Докладніші відомості про цю функцію та список сторонніх записів див. розділ Керування записом дзві нків для Webex Calling.

Охоплення одного номера

Охоплення одного номера дозволяє дзвінкам на номер телефону користувача дзвонити на кілька пристроїв. Це можуть включати інші настільні телефони, а також мобільні телефони. Дзвінки також можуть здійснюватися з цих пристроїв, і користувачі можуть натискати та здійснювати дзвінки між ними.

Докладніші відомості про цю функцію та про те, як адміністратор налаштовує її, див. у розділі Н алаштування охоплення одного номера (офіс у будь-якому місці).

Для отримання додаткової інформації про те, як користувач може керувати цією функцією та налаштовувати для себе на Webex User Hub (порт алі), див. розділ Налаш тування охоплення одного номер а (офіс у будь-якому місці).

Група голосової пошти

Групи голосової пошти дозволяють використовувати спільну скриньку голосової пошти, яку можна призначити користувачеві або функції маршрутизації дзвінків. Деякі з причин, за якими може знадобитися група голосової пошти:

Голосова пошта загального призначення для відділу або робочої групи

Додати опцію голосової пошти до автоматичної служби супроводу або групи пошуку

Надсилання переповнених викликів із черги викликів

Користувачі, яким потрібна лише ящик голосової пошти.

Докладніші відомості див. у розділі Керування спільною голосовою поштою та вхідним факсом для. Webex Calling

Консоль супутника перелічено на сторінці Функції виклику у Webex, однак це додаткова функція, яка вимагає придбання ліцензії супровідної консолі для використання.

Докладніші відомості див. у статті Початок роботи з консоллю супутника.

Щоб отримати інформацію про всі функції, включаючи деякі додаткові функції, див. Функції, доступні за ти пом ліцензії для Webex Calling.

Таблиця 1. Інформація для збору для кожного місця
Інформація	Коментар
Діапазон (и) розширення	Кожне розташування може мати розширення, що починаються з різних цифр. Одна цифра повинна бути збережена для циф ри рульового набору між сайтами (наприклад, 8) та одну для цифри рульового керування PSTN (наприклад, 9). Жоден діапазон розширення не може починатися з жодної з цих двох цифр. Всі діапазони розширення всіх локацій повинні бути однакової довжини.
Діапазон (и) DID	-
Рульова цифра PSTN	-
Код сайту	Усі коди сайтів усіх місць повинні бути унікальними та мати однакову довжину.
Основний номер	При створенні локації потрібно забезпечити два DID. Один як основний номер (наприклад, призначений службі автосервісу) і один для порталу голосової пошти. Забезпечити один DID для номера голосової пошти.
Номер голосової пошти
Кількість ліцензій	Необхідні ліцензії за типом, включаючи Стандартний, Професійний, Робочий простір, Список маршрутів, план вихідних дзвінків.
Одночасні дзвінки в напружену годину	Сума одночасних дзвінків між пристроями та між пристроями та локальним шлюзом (PSTN та виклики на пристрої). Потрібна для визначення необхідної пропускної здатності доступу до Інтернету.
Країна	-
Часовий пояс	-
Мова	-
Контакт (Ім'я, Телефон, Електронна пошта)	-
Адреса (вулиця, місто, штат, поштовий індекс)	-
Фізичне розташування екстрених служб для кінцевих точок	Місцезнаходження пристрою, яке використовується для екстрених викликів, зазвичай включає наступне: адреса будівлі, адреса будівлі+номер поверху, адреса будівлі+номер номера номера номера номер а будівлі + номер поверху + номер офісу/кубічного номера.
Для кожного пристрою унікальне фізичне розташування мережі для екстрених служб	Фізичне розташування мережі для екстрених викликів зазвичай включає наступне: комутатора/комутатор для дротових пристроїв, базові ідентифікатори набору послуг бездротової точки доступу (BSSID) для бездротових підключених пристроїв та/або локальні IP-підмережі для кінцевих пристроїв.

Таблиця 2. Приклад нумерації підприємства
Сайт	Діапазон розширення	Код сайту	Підприємницький асортимент
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Таблиця 3. Діапазони розширення фіксованої довжини
Сайт	Діапазон розширення	Розширення	Код сайту	Підприємницький асортимент
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Таблиця 4. Перехід семизначного набору

Сайт	Розширення	Код сайту	Підприємницький асортимент	Ода сайту	Підприємство англ
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

Таблиця 5. Параметри забезпечення користувача - резюме
Метод призначення	плюси	мінуси
Ручний наскрізний	Простий для небагатьох користувачів. Дозволяє точний і детальний контроль над присво єнням ліцензії.	Не масштабується, трудомісткий Схильний до людських помилок під час ру чного введення.
Автоматичні шаблони ліцензій	Масштабований Зменшує помилки вручну Може застосовуватися до нових і існуючих користувачів.	Потрібні дійсні номери телефонів та місцезнаходження. Більш складна в налаштуванні Також потрібні групи користувачів на групу користувачів з еквівалентними вимогами до ліцензування.
Масове завантаження CSV	Ефективний для великих користувацьких наборів Дозволяє одночасне присвоєння ліцензій, номерів телефонів і розширень.	Потрібне ретельне форматування CSV Можливість помилок, якщо номери телефонів або розширень відсутні або невірні.
Призначення на основі API	Автоматизований, гнучкий. Дозволяє одночасне присвоєння ліцензій, номерів телефонів і розширень.	Потрібна розробка та знання API.

Таблиця 6. Параметри надання користувачем для
Метод забезпечення	Опис	плюси	мінуси
Посібник	Створють/керуйте користувачами окремо в	Простий для небагатьох користувачів; не потрібна інфраструктура	Не масштабується; трудомісткий для багатьох користувачів
Масова кількість (файл CSV)	Імпортував/оновлюйте користувачів масово через CSV в	Ефективний для груп; кодування не потрібно	Ручна підготовка CSV; менш динамічна
Люди та SCIM 2.0 API	Програмне управління користувачами за допомогою API Webex	Гнучкий; підтримує автоматизацію та інтеграцію	Потрібен розвиток та інфраструктура
Синхронізація каталогів	Автоматична синхронізація з AD, Entra ID, програм SCIM, Unified CM	Автоматизує життєвий цикл; підтримує фільтрацію та відображення	Складність налаштування: деякі варіанти мають обмежені можливості або вимагають інфраструктури

Таблиця 7. Параметри керування групами та членством у групах
Варіант	Опис	плюси	мінуси
групове забезпечення (групи)	Створюйте та керуйте групами безпосередньо в. Додавати/видаляйте учасників вручну або через CSV.	Повний контроль над членством у групі Негайне застосування ліцензій і шаблонів Легко створювати та редагувати групи	Потрібні ручні оновлення Ризик помилок при ручному завантаженні CSV Немає автоматичної синхронізації із зовнішніми каталогами
Синхронізовані групи з ідентифікатора Entra (Azure AD) або Active Directory	Автоматична синхронізація груп безпеки та членства із зовнішніх служб каталогів .	Автоматизована синхронізація зменшує ручну роботу Забезпечує відповідність корпоративному довіднику Підтримує великі організації	Не вдається редагувати членство в групі Затримка синхронізації до 12 годин Вкладені групи вимагають ручного вибору
Групи та SCIM 2.0 API (групи)	Використовуйте Groups або SCIM 2.0 API для програмного керування групами та членством	Автоматизація та інтеграція з іншими системами Масштабовується для великих або складних середовищ	Потрібні зусилля з розвитку Складність залежить від використання API

Впровадити

Мережева готовність

Початкова настройка

Перевірка домену

Заявка (конвертація) існуючих користувачів

Налаштування та перевірка синхронізації каталогів

Налаштування та тестування єдиного входу (SSO)

Закупівля, надання та перевірка ліцензій

Webex Callingнастройки сервісу

Пілотна міграція

Закупіть ПСТН

Налаштування розташування

Інтеграція з локальним управлінням викликами

Пакетна міграція користувачів

Робочі простори

Пристрої забезпечення

Налаштування функцій

Приймальне тестування

Мережева готовність

Першим кроком у переході до цього є забезпечення надійного та безпечного підключення до Інтернету між локальною мережею та хмарою.

Оскільки більшість організацій підключаються до Інтернету через один або кілька бр андма у ерів або пристроїв безпеки, важливо перевірити, чи підтриму ються необхідні потоки трафі ку.

Адміністратори мережі та безпеки повинні розуміти ці потоки з точки зору:

Напрямок (вхідний проти вихідного)

Протоколи (Приклад - SIP TLS, SRTP, HTTPS)

Діапазони IP-адрес, які використовуються службами

Номери пор тів, які необхідно відкрити або дозволити.

Це гарантує, що корпоративні брандмауери, пристрої NAT та інша мережева інфраструктура належним чином налаштовані для розміщення трафіку, зберігаючи корпоративну політику безпеки.

Для отримання інформації про необхідні потоки, включаючи IP-адресу, порти та протоколи, див. Довідкова інформація про порт для Webex Calling. Використовуйте цю інформацію, щоб налаштувати брандмауер, проксі-сервери та іншу мережеву інфраструктуру в існуючому розгортанні, щоб увімкнути мережеві потоки.

Децентралізований прорив Інтернету з кожної філії чи сайту є рекомендованим підходом для хмарних служб співпраці, таких як. Дозволяючи трафіку виходити локально, ця модель:

Зменшує затримку і тремтіння в обидва кінці, покращуючи загальну якість дзвінків

Ефективно масштабується в міру переходу більшої кількості користувачів і сайтів

Безперебійно працює з SD-WAN, який може динамічно маршрутизувати сеанси до найближчої точки входу в хмару для оптимальної продуктивності

Дозволяє відстежувати місцезнаходження користувача на основі їх загальнодоступної IP-адреси, що допомагає з аналізом шляхів медіа та усуненням несправностей.

Крім того, організації повинні забезпечити достатню пропускну здатність Інтернету на кожному сайті. Пропускна здатність повинна бути розміщена на основі очікуваної кількості одночасних викликів, вибраного кодека (наприклад, Opus або G.711), плюс накладних витрат на сигналізацію, повторну передачу та зростання. Це узгоджується з фазою підготовки життєвого циклу PPDIO та створює міцну основу для міграції.

Початкова настройка

Підрозділ початкового налаштування на етапі впровадження розгортання є основним для створення добре структурованого та керованого середовища хмарних викликів. Цей етап охоплює важливі завдання, такі як налаштування організації, закупівля та призначення ліцензій, а також перевірка та претензія на до мени вашої компанії, щоб забезпечити належне управління користувачами та безпеку. Крім того, він включає шаблони ліцензій для автоматизації присвоєння ліцензій користувача, налаштування єдиного входу (SSO) для спро щення автентифікації користувачів та підвищення безпеки, а також коригування налаштувань служби та клієнта відповідно до організаційних політик та потреб користувачів. Завершення цих початкових дій налаштування гарантує, що середовище належним чином налаштовано на масштабованість, безпеку та безперебійну роботу користувача, створю ючи основу для подальших етапів розгортання та експлуатації.

Перевірка домену

Щоб дозволити ідентифікувати користувачів, зареєстрованих у доменах електронної пошти вашої компанії, важливо перевірити свої домени. Без перевірки домену користувачі будуть призначені до споживчої організації, ускладнюючи управління користувачами для вашої компанії. Перевірка домену є обов'язковим кроком, який дозволяє вашій організації претендувати та ефективно керувати цими користувачами.

Переконайтеся, що всі домени, пов'язані з адресами електронної пошти ваших користувачів, перевірені. Перевір ка домену не є ексклюзивною; один і той же домен можна перевірити в декількох організаціях.

Докладніші відомості про керування доменами див. у розділі Керування доменами.

Заявка (конвертація) існуючих користувачів

Після успішної перевірки доменів ви можете продовжувати претендувати на користувачів, які зареєстр увалися за використання доменів електронної пошти вашої компанії у вашій організації. Цей процес об'єднує всіх користувачів під єдиною організаційною парасолькою, забезпечуючи централізоване управління та оптимізоване адміністрування. Заявляючи цих користувачів, ви гарантуєте, що ваша компанія має повний контроль над облі ковими записами користувачів, що дозволяє призначати відповідні ліцензії, налаштовувати послуги та ефективно надавати необхідну підтримку. Цей єдиний підхід до управління підвищує безпеку, спрощує надання користувачам та забезпечує постійний доступ до служб у всій організації. Претензії користувачів також перешкоджають управлінню ними у зовнішніх або споживчих організаціях, тим самим зберігаючи організаційну цілісність та контроль над ресурсами співпраці.

Докладніші відомості про заявки користувачів див. у статті Заявка користувачів на користувачів вашої організації (конвертувати).

Налаштування та перевірка синхронізації каталогів

Щоб увімкнути безперебійне керування користувачами та групами, ви можете синхронізувати користувачів та групи з корпоративного каталогу або ідентифікатор Microsoft Entra ID (раніше Azure AD) або Microsoft Active Directory (AD). Цей процес гарантує, що ідентифікації користувачів та членство в групах послідовно підтримуються у вашому середовищі.

Для організацій, які впроваджують поетапне розгортання, дуже важливо контролювати та обмежувати обсяг синхронізації під час початкового розгортання. Це мінімізує ризик непередбачуваних змін і дозволяє проводити цілеспрямоване тестування перед більш широким прийняттям.

Найефективнішим методом фільтрації синхронізованих користувачів є використання членства в групах каталогів:

1
Створіть виділену групу синхронізації: у вашому корпоратив ному каталозі (Microsoft Entra ID або AD) створіть групу безпеки спеціально для синхронізації (наприклад, групу синхронізації).

2
Наповнення групи цільовими користувачами. Додайте до цієї групи лише тих користувачів, яких потрібно синхронізувати (наприклад, тестову групу під час пілотного етапу). Це дозволяє жорстко контролювати, хто входить в процес синхронізації.

3
Налаштування угоди про синхронізацію за допомогою фільтрації на основі групи: під час налаштування угоди про синхронізацію в каталозі Connector або створення ідентифікатора Entra, налаштуйте область так, щоб вона включала лише користувачів, які є членами визначеної групи.

Для ідентифікатора Microsoft Entra ID можна використовувати групові призначення в налаштуваннях забезпечення

Для AD можна визначити фільтр LDAP для включення лише користувачів, що належать до вказаної групи.

4
Розширюйте групу за потреби: Коли ви переходите до більш широких етапів розгортання, просто додайте додаткових користувачів або групи до групи синхронізації. Область синхронізації автоматично розшириться, включивши цих користувачів, дозволяючи контрольоване та поступове розгортання.

Приклад кроків реалізації:

В активному каталозі:

Створіть групу безпеки з назвою група синхронізації.

Додайте бажаних пілотних користувачів до цієї групи.

Налаштуйте роз'єм каталогів за допомогою фільтра LDAP, наприклад: (MemberOF=CN = Група синхронізації WebEx, OU = Групи, DC = Ваш домен, DC = COM).

У корпорації Майкрософт введіть ідентифікатор:

Створіть групу з назвою група синхронізації

Призначте групу до налаштувань забезпечення ідентифікатора Entra ID

Тільки користувачі цієї групи будуть забезпечені.

Завжди перевіряйте синхронізацію на основі групи в невиробничому середовищі, перш ніж застосовувати до всієї організації

Регулярно перевіряйте членство в групі, щоб забезпечити синхронізацію лише авторизованих користувачів

Для постійного управління автоматизуйте оновлення членства в групі на основі бізнес- правил або систем управління персоналом, якщо це можливо.

Посилання:

Синхронізація користувачів ідентифікатора Entra з Контрольним центром

Налаштування програми майстра ідентифікатора Entra ID у Центрі керування

Роз'єм каталогу

Налаштування та тестування єдиного входу (SSO)

Єдиний вхід (SSO) підвищує безпеку та спрощує доступ користувачів, дозволяючи користувачам здійснювати аутентифікацію один раз за допомогою своїх корпоративних облікових даних та отримати безперебійний доступ до. підтримує інтеграцію SSO з сумісними ідентифікаторами SAML 2.0, включаючи ідентифікатор Microsoft Entra ID (раніше Azure AD), Active Directory (AD) федеративні рішення та різні сторонні Ідентифікатори.

На цьому етапі розроблена настройка SSO повинна бути реалізована та протестована.

Посилання:

Інтеграція єдиного входу в центр управління

налаштувати єдиний вхід для адміністрування webex

Налаштування єдиного входу за допомогою ідентифікатора Microsoft Entra

SSO з декількома ВПО

Керування SSO при інтеграції в Контрольному центрі

Закупівля, надання та перевірка ліцензій

В рамках початкового налаштування для, важливо закуповувати, надавати та перевіряти відповідні ліцензії для ефективного включення та управління послугами. Процес закупівлі передбачає вибір типів ліцензій на основі ролей користувачів та робочих навантажень, таких як ліцензії Professional, Standard та Workspace. Ліцензії генеруються та надаються через програмні платформи Cisco або через партнерів. Після закупівлі та надання необхідно перевірити належну кількість ліцензі й. Цей процес гарантує, що організація має правильні ліцензії активовані та готові до використання при розгортанні.

У рамках початкового налаштування ліцензування в, важливо налаштувати автоматичне ліцензування на основі організації, щоб спростити присвоєння ліцензій для нових користувачів. Ця настройка дозволяє автоматично надавати ліцензії, коли користувачі додаються до організації, усуваючи необхідність ручного присвоєння ліцен зій. Під час налаштування автоматичного ліцензування на рівні організації ви вибираєте служби, які потрібно призначити, і визначте сферу, наприклад, застосування ліцензій лише майбутнім користувачам або включення існуючих користувачів.

Однак, якщо ваш план розгортання передбачає використання автоматичного ліцензування на рівні групи , ви можете не призначати ліцензії на рівні організації, щоб уникнути конфліктів або повторних призначень ліцензій. За допомогою автоматичного ліцензування на рівні групи ліцензії призначаються на основі членства в групі. Користувачі з декількох груп отримують ліцензії від усіх відповідних груп.

Налаштування присвоєння ліцензій на основі групи необхідно виконати після завершення синхронізації каталогів, щоб існували синхронізовані групи та могли використовуватися для присвоєння ліцензії.

Зокрема, для автоматичного присвоєння ліцензії потрібні додаткові відомості про надання, такі як місцезнаходження користувача та присвоєння номера телефону. Робочий номер телефону користувача повинен бути у форматі+E.164, попередньо забезпечений та призначений для дійсного місця для автоматичної активації ліцензії. Якщо ці умови не виконуються, користувачеві не буде надано послуги автоматично і може знадобитися втручання вручну.

Підсумовуючи це, налаштуйте автоматичне ліцензування на основі організації для нових користувачів, якщо ви хочете отримати широке призначення ліцензій для всієї організації. Якщо ви віддаєте перевагу більш детальному контролю або маєте різні потреби в ліцензуванні для кожної групи, налаштуйте автоматичне ліцензування на рівні групи та уникайте при своєння ліцензій на рівні організації, щоб запобігти перекриттю та забезпечити належне управління ліцензіями.

Webex Callingнастройки сервісу

Важливо провести всебічний огляд та конфігурацію глобальних налаштувань служби всередині.

Почніть з доступу та перейдіть до розділу налаштувань. Уважно вивчіть кожну настроювану опцію, включаючи, але не обмежуючись ними, внутрішню конфігурацію набору номера, параметри екстреного виклику, політику маршрутизації викликів, управління голосовою поштою та налаштування за замовчуванням пристрою.

Налаштуйте ці глобальні налаштування відповідно до політики організації та рішень щодо дизайну.

Крім того, налаштування налаштувань та шаблонів користувачів та додатків.

Пілотна міграція

На етапі впровадження виконання пілотної міграції є критичною віхою у підтвердженні переходу від до. Цей пілотний проект передбачає надання репрезентативної підмножини користувачів в одному або декількох місцях на платформі, гарантуючи, що вибране населення відображає різноманітні випадки використання та організаційні ролі. Паралельно з міграцією користувачів основні служби співпраці, включаючи голосову пошту, автосервіси, черги викликів та групи пошуку, повинні бути переведені на їх еквіваленти, щоб підтримувати безперервність бізнесу та функціональність обслуговування.

Пілотна міграція повинна використовувати ту саму комбі націю інструментів, що надаються Cisco, та сторонніх утиліт міграції, які плануються для ширшого організаційного розгортання, гарантуючи, що процеси, робочі процеси автоматизації та точки інтеграції ретельно перевіряються за репрезентатив них умов.

Основними цілями цього пілотного розгортання є дві: по-перше, перевірка та вдоскон алення процесів наскрізного переходу, включаючи робочі процеси надання користувачем, процедури міграції даних та конфігурації кінцевих точок; по-друге, всебічна перевір ка функціональності перенесених служб у реальних операційних умовах.

Цей поетапний підхід дозволяє команді проекту виявляти та усунути будь-які технічні чи процедурні проблеми в контрольованому середовищі, збирати відгуки користувачів про досвід нової платформи, оцінити ефективність вибр аних інструментів міграції та встановити впевненість у методології міграції, перш ніж приступити до більш широкого організаційного розгортання.

Отримані на цьому пілотному етапі знання мають важливе значення для оптимізації подальших хвиль міграції та забезпечення плавного переходу, що зменшує ризики для всього підприємства.

Закупіть ПСТН

Щоб придбати послуги PSTN, спочатку виберіть параметр підключення PSTN у.

Якщо організація планує підтримувати гібридний подвійний контроль дзвінків (етап 1 на малюнку Поета пний перехід викликів: гібридний і хмар ний) тимчасово або необмежено, їй потрібно буде розгорнути один або кілька локальних шлюзів для локального PSTN, щоб дозволити виклик між кінцевими точками та кінцевими точками.

Якщо кінцевою метою є повний перехід (фаза 2) до хмари, включаючи PSTN, то для PSTN буде потрібно або план дзвінків Cisco, або опція Cloud Connect for.

Співпрацюйте з обраним постачальником, щоб замовити та перенести телефонні номери, перш ніж налаштувати їх. Замовлення номерів телефонів або ініціювання портових замовлень потрібно/можливе лише для локальних PSTN та Cloud Connect для. Для планів дзвінків Cisco замовлення та перенесення ініціюються з Центру керування, як тільки місцезнаходження створено, та в країнах, де доступний план викликів Cisco. Докладніші відомості про плани Cisco Calling див. у статті Початок роботи з планами Cisco.

В рамках реалізації PSTN переконайтеся, що ваш постачальник уві мкнув як вхідні, так і вихідні послуги PSTN для вашого місцезнаходження. Крім того, виконайте тестові виклики, щоб переконатися, що дзвінки маршрутизуються правильно через вибране PSTN-з'єднання.

Налаштування розташування

Перш ніж додавати користувачів і пристрої, необхідно надати місцезнаходження дзвінків. Для кожного місця необхідно ввести дійсну вуличну адресу. У США та Канаді ця адреса підтверджується та використовується платформою для надсилання інформації про місцезнаходження PIDF-LO для екстрених викликів.

Під час налаштування розташування, які використовують локальний PSTN, потрібно відповідно налаштувати локальні шлюзи. У ньому для кожного локального шлюзу необхідно створити магістраль і групу маршрутів, а потім група маршрутів призначається як вибір PSTN для місцезнаходження. Cisco настійно рекомендує завжди вибирати групу маршрутів як вибір PSTN, оскільки такий підхід дозволяє легко додавати додаткові магістралі в майбутньому, підтримуючи як масштабованість, так і надмірність. Cisco також рекомендує увімкнути підтримку подвійної ідентифікації та P-Charge-Info на кожному магістралі PSTN, оскільки це спрощує ідентифікацію платної сторони для вихідних прямих або перенаправлених дзвінків. Якщо ваш постачальник послуг PSTN використовує інший заголовок для виставлення рахунків, ви можете скопіювати інформацію із заголов ка P-Charge-Info на локальному шлюзі до необхідного заголовка виставлення рахунків.

Для місць, які використовують Cloud Connect для або план дзвінків Cisco як опцію PSTN, просто виберіть відповідний вибір PSTN для місцезнаходження під час налаштування. Якщо місцезнаходження використовує Cloud Connect для або локальний PSTN, вам потрібно буде додати номери телефонів, які були замовлені на попередньому кроці . Номери можна додати як неактивні, якщо ви не хочете, щоб вони відразу включалися до маршрутизації дзвінків; ви можете активувати ці номери пізніше, коли вони будуть призначені користувачам або функціям.

Важливо завжди встановлювати основний номер для кожної локації. Основний номер може бути призначений як користувачеві, так і функції, наприклад автоматичному обслуговуючому службі. Щоб увімкнути голосову пошту в цьому місці, обов'язково встановіть номер піло та голосової пошти, також відомий як номер голосового порталу.

Додаткові налаштування для місць виклику включають налаштування деталей екстрен ого виклику, таких як номер екстреного виклику, параметри сповіщень та розширені функції екстреного виклику. Ви також повинні переглянути та налаштувати параметри запису, мовні налаштування та конфігурації пристрою відповідно до кожного місця. Якщо ваша організація використовує скорочений міжсайтовий набір через мережу зі значущими номерами підприємства, не за будьте налаштувати унікальний код сайту для місцезнаходження у внутрішніх налаштуваннях набору номер а. Нарешті, якщо для зовнішнього набору потрібна цифра вихідного набору, обов'язково встановіть це в налаштуваннях зовнішнього набору номера. Коли налаштовано цифру вихідного набору, компанія Cisco рекомендує увімкнути приму сове виконання цифр вихідного набору, щоб забезпечити послідовність.

Інтеграція з локальним управлінням викликами

Для інтеграції з локальним управлінням викликами необхідно налаштувати магістралі, групи маршрутів, плани набору підприємств, а також параметри місцезнаходження та глобальні налаштування. Почніть з налаштування магістралей і локальних шлюзів, призначених для взаємозв'язку з локальною системою керування викликами; цей крок необхідний лише в тому випадку, якщо потрібні виділені магістралі. Якщо існуючих магістралей і груп маршрутів достатньо для розгортання, їх можна повторно використовувати для локального підключення без додаткової конфігурації.

Після встановлення магістралей та груп маршрутів перейдіть до створення планів набору підприємств та призначте відповідну групу маршрутів як пункт призначення для кожного плану набору номера. Якщо інтеграція включає кілька локальних систем керування дзвінками, підключених через різні магістралі, буде потрібно кілька планів набору номера. Важливо переконатися, що ці плани набору містять лише шаблони, необхідні для маршрутизації дзвінків до локальних пунктів призначення.

Якщо для розгортання потрібна підтримка невідомої маршрутизації розширень, цю функцію слід у вімкнути на рівні місцезнаходження. Крім того, коли активовано маршрутизацію невідомого розширення, ви повинні вказати максимальну довжину невідомого розширення в розділі Маршру тизація дзвінків між приміщеннями та приміщен нями налаштувань послуг виклику в. Це гарантує безперебійну маршрутизацію викликів і правильну обробку сценаріїв набору на основі розширення у вашому інтегрованому середовищі.

Міграція користувачів пакетно

Під час міграції користувачів до вас, можливо, не вдасться переміщати всіх користувачів одночасно. Це може бути пов'язано з кількома причинами, включаючи, але не обмежуючись, кількість сайтів або користувачів, скільки часу потрібно для переходу сайту та/або групи користувачів одночасно, обмежений ІТ або ресурс сайту для підтримки вікна змін, тривалість вікна зміни, складність зміни тощо.

Коли ви мігруєте користувачів поетапно, важливо визначити, які користувачі повинні мігрувати разом у одному пакеті. Основною метою є спільна міграція користувачів, які мають залежність один від одного для своїх служб та функцій виклику. Ви хочете переконатися, що всі ї хні функції виклику (Приклад - Черги викликів) повністю функціональні, як і до переходу.

Навіть якщо ви реалізуєте взаємодію викликів між локальними шлюзами та за допомогою них, ви не можете розділити спільні служби або функції по цьому з'єднанню. Тому вам потрібно визначити залежності між користувачами, дивлячись на такі функції, як:

Моніторинг інших користувачів за допомогою BLF

У тому ж полюванні пілот, черга викликів і т.д.

Спільні лінії

Використання підбору дзвінків

Використання одних і тих самих номерів кол-парків

Домофон

Керівник/Адміністратор.

Прикладом може бути користувач, який є частиною групи Hunt, до якої переходить. Цей користувач перейде до групи Hunt та з усіма іншими членами групи Hunt. Тому після переходу Hunt Group та її члени можуть успішно відповідати на дзвінки на новій платформі.

Це стає більш складним, коли користувачі підключаються до різних груп користувачів для різних служб та функцій виклику. Для цього буде потрібно перевести одночасно більше однієї групи користувачів і одну службу виклику.

Щоб визначити, які користувачі та функції слід згрупувати разом, скористайтеся виведеними даними інструмента Migration Insights або стороннім інструментом, який ви використовували на етапі підготовки. Цей результат повинен був бути використаний для розробки плану міграції та дасть вам уявлення про те, як ви будете групувати користувачів та функції, які потребують переходу разом.

Ключовими кроками при переході партії користувачів є:

Ідентифікація користувачів для спільної міграції

Перевірте, що всі користувачі перебувають

Перевірте, що всі TN для користувачів існують

Перевірте правильний формат номера телефону в каталозі

Переконайтеся, що шаблон ліцензування та налаштувань для груп користувачів правильно налаштовано

Перевірка або налаштування всіх служб виклику та функцій для групи користувачів (до або під час переходу, якщо це необхідно)

У корпоративному каталозі додайте користувачів до групи користувачів з включеним викли ком

Інструменти використання - інструменти міграції користувачів та функцій та/або сторонні інструменти

Вимкнути/Видалити номер каталогу користувача/пристрою та функції виклику ввімкнути/служби після переходу.

Після міграції групи користувачів перевірте підмножину користувачів, щоб перевірити, чи всі їхні функції виклику та служби працюють належним чином. Якщо функції виклику, такі як черга викликів, групи пошуку тощо, переходять із групою користувачів, перевірте належну функціональність цих служб виклику.

Робочі простори

У робочому просторі відноситься до спільного розташування (наприклад, конференц-залу, місця для спілкування або робо чого столу), якому можна призначити пристрої, розширення та користувачі. На відміну від традиційних телефонів Unifed CM, робочі простори:

Орієнтований на розташування: прив'язаний до фізичних просторів.

Гнучкий для пристрою: може мати один або кілька пристроїв (настільні телефони, дошки тощо).

Після того, як робочі простори будуть визначені як частина переходу до, їх можна додати в розділі Пристрої. Кожному робочому середовищу потрібно призначити пристрій, і якщо вони вже єUnified CM, їх потрібно скинути або відновити. такі функції, як голосова пошта, переадресація дзвінків та отримання дзвінків можна ввімкнути або вимкнути, а також застосовувати політику для відеодзвінків, паркування викликів та мобільності за потреби. Перевірте кож ну робочу область, здійснюючи внутрішні та зовнішні дзвінки, тестуючи функції відео, конференцій та мобіль ності. Нарешті, повідомте користувачів про будь-які застосовні процеси для пристроїв робочого простору та бронювання.

Докладніші відомості про робочі простори в розділі Робочі простори.

Пристрої забезпечення

Телефони, на які зараз зареєстровані, потрібно буде перенести в рамках хмарного переходу. Щоб зробити міграцію максимально простою з мінімальним шансом на збій, Cisco рекомендує одночасно мігрувати фізичні сайти або відділи. Однак вам може знадобитися мігрувати користувачів пакетно через залежності функцій. Докладніші відомості див. у розділі Міграція користувачів пакетами.

Будь-які підтримувані телефони, з яких вам потрібно перейти, потрібно буде налаштувати як користувача або робочу область, а фізичний телефон потрібно буде переналаштувати для реєстрації. Крім того, телефони серії 7800 і 8800 потребують оновлення прошивки з прошивки Enterprise до прошивки Multiplatform Phone (MPP). Цей процес включає завантаження перехідної прошивки перед завантаженням прошивки MPP, необхідної для реєстрації. Також потрібна відповідна міграційна ліцензія. Cisco вдосконалила цей процес за останні кілька років, щоб полегшити вам оновлення телефонів з прошивкою Enterprise до прошивки MPP. Для отримання додаткової інформації про кроки для завершення оновлення мікропрограми див. розділ Пере творення IP-телефонів Cisco серії 7800 та 8800 між корпоративними та MP P мікропрограмами.

На додаток до кроків, описаних у цій статті, є вбудований інструмент «Пере міщення телефону на»Webex Calling, за допомогою якого ви можете допомогти перене сти ваші телефони 7800 та 8800 з Enterprise на MPP мікропрограму. Цей інструмент також дозволяє додавати телефони та призначати їх відповідним користувачам або робочим просторам. Докладніші відомості про використання інструменту див. у розділі Перенесення телефону.

Для будь-яких телефонів серії 9800, зареєстрованих з вищевказаною вимогою міграції мікропрограми, не застосовується. Ці телефони працюють під управлінням PhoneOS, яка підтримується обома і. Для переходу цих телефонів вам потрібно буде додати їхWebex Calling, призначити їх користувачеві або робочому простору, а потім скинути за водські налаштування телефонів. Послідовність завантаження Phon eOS для реєстрації на малюнку нижче показує послідовність завантаження PhoneOS та спосіб реєстрації телефону після його додавання, навіть якщо телефон все ще забезпечений та/або використовуються параметри DHCP (Приклад - 150).

Послідовність завантаження PhoneOS для реєстрації

підтримує скидання до заводських налаштувань пристроїв PhoneOS, щоб дозволити впровадження Zero-Touch. адміністратори можуть віддалено скинути заводські налаштування телефонів 9800 та 8875 через сторінки адміністрування CUCM, що виключає необхідність фізичного доступу до телефонів для встановлення телефонів. Ця функція підтримується в пакетах пристроїв з 9 вересня 2025 року:

CUCM v15 - уніфікований менеджер комунікацій версії 15

CUCM v14 - уніфікований менеджер комунікацій версії 14.

Для отримання додаткової інформації про процес реєстрації для серії 9800 див. Процес реєстрації .

Окрім IP-телефонів Cisco, може знадобитися забезпечення інших пристроїв, таких як аналогові телефонні адаптери (ATA), бездротові (Wifi, DECT) телефони, відеопристрої, голосові шлюзи, а також пристрої ^та телефони третьої сторони. Багато з цих пристроїв не мають шляху оновлення мікропрограми , як IP-телефони, для переходу їх від корпоративної прошивки до хмарної прошивки. Тому ви забезпечите кожен із цих пристроїв у Контрольному центрі. Деякі з них неможливо перевести, і еквівалентну модель потрібно буде замінити її (напр. ATA 191/192) та інші потребують ручної переналаштування та/або зміни програмного забезпечення.

Голосові шлюзи. Щоб перенести локальний шлюз, див. розділ Міграція локального шлюзу.
Докладніші відомості щодо налаштування голосового шлюзу VG400, VG410 або VG420 у Центрі керування див. розділ Локальний шлюз

Аналоговий телефонний адаптер (ATA) - Для початку роботи з Cisco ATA 191 і 192 див. Cisco ATA.

Бездротовий телефон Wi-Fi - Щоб інтегрувати бездротовий телефон 840 і 860, див. Інтегра ція бездротового телефону Webex.

Без@@ дротові телефони DECT - Щоб розпочати роботу з новою серією Cisco IP DECT 6800, див. розділ Cisco IP DECT.

Щоб створити та керувати цифровою мережею DECT у Control Hub, див. розділ Керування мереже ю DEC T

Для отримання додаткової інформації про Cisco IP DECT 6800 див. Посібник із розгортання

Прист ^ро ї та телефони треть ої сторони - Працюйте ^з постачальниками тре тьої сторони щодо вимог до пристроїв/телефону та процесу їх міграції або заміни на підтримку.

Налаштування функцій

Будь-які функції виклику, які потрібні, повинні бути забезпечені до переходу або під час переходу. Як було сказано в розділі Переміщення користувачів пакетами, функції виклику потрібно налаштувати та перевести під час переходу користувачів, які їх використовують.

Докладніше про те, як налаштувати кожну з функцій, див. у відповідних статтях довідки щодо конфігурації.

Автосервіси - Щоб керувати автосервісами, див. розділ Автосервіси

Парк викликів - Щоб керувати парком викликів, див. Парк викликів

Прийом дзвінків. Щоб налаштувати групу прийому дзвінків, див. розділ Прийо м дзві нків

Черги викликів. Щоб налаштувати Чергу викликів, див. розділ Черга викликів

Групи полювання - Щоб керувати групами полювання, див. розділ Керування групою полювання

Режим роботи - Для маршрутизації викликів на основі режимів роботи див. Маршру тизація викликів на основі операційних режимів

Групи сторінок. Щоб налаштувати групу підкачки, див. розділ Налаштування групи підказок

Записи. Щоб керувати записом дзвінків, див. розділ Кер ування записами

Охоплення одного номера. Щоб налаштувати охоплення одного номера (офіс де завгодно), див. розділ Налаш тування єдиного номера

Група голосової пошти. Щоб керувати спільною голосовою поштою та вхідним факсом, див. розділ Керування голосовою поштою.

Приймальне тестування

Приймальне тестування гарантує, що перенесене середовище відповідає функціональним вимогам, працює належним чином, і забезпечує безперебій ну роботу користувачів у всіх робочих процесах зв'язку. Цей процес перевірки є багатогранним, охоплюючи все: від надання користувачем та призначення номерів до оперативної продуктивності розширених функцій викли ку.

У цьому розділі наведено приклади та висвітлюються ключові аспекти, які слід враховувати під час приймального тестування; однак він не призначений для того, щоб служити вичерпним або вичерпним контрольним списком.

Забезпечення користувача та присвоєння номера

Основний аспект приймального тестування передбачає перевірку того, чи всі користувачі забезпечені точно та повністю всередині. Це вимагає ретельного порівняння каталогу source () та новоствореної бази користувачів, щоб переконатися, що кожен обліковий запис користувача разом із пов'язаними атрибутами, такими як номери розширень та призначення прямого внутрішнього набору (DID), були правильно перенесені. Повнота забезпечення має вирішальне значення не лише для працездатності першого дня, але й для постійного адміністрування та підтримки.

Перевірка присвоєння номера включає підтвердження того, що кожному користувачеві присвоєно правильне розширення та зовнішній номер, і що ці номери правильно маршрутизуються як у внутрішніх (мережевих), так і зовнішніх (PSTN) потоках викликів. Важливо перевірити наявність будь-яких перекриттів, відсут ніх призначень або неправильних конфігурацій, які можуть призвести до помилок маршрутизації викликів або переривань служби.

Потоки дзвінків PSTN та презентація ідентифікатора абонента

Надійна процедура приймального тестування повинна охоплювати наскрізну перевірку потоків викликів PSTN. Це включає сценарії як вхідних, так і вихідних викликів. Для вхідних дзвінків PSTN команда тестування повинна підтвердити, що дзвінки доставляються до передбачуваних кінцевих точок, будь то окремі користувачі, черги викликів, групи пошуку або автосервіси. Вихід ні дзвінки PSTN повинні бути здійснені успішно, приділяючи особливу увагу правильній доставці та представлен ню інформації ідентифікатора абонента. Це передбачає забезпечення відоб раження правильного імені та номера абонента зовнішнім одержувачам відповідно до організаційної політики та нормативних вимог.

Тестування також має стосуватися сценаріїв відмови, таких як обробка недосяжних кінцевих точок або збоїв у мережі. Це допомагає підтвердити, що резервні механізми та альтернативна маршрутизація функціонують належним чином, підтримуючи безперервність та надійність обслуговування.

Потоки дзвінків в мережі

Внутрішні або он-мережеві потоки викликів складають основу корпоративної комунікації. Тестування прийняття в цій області перевіряє правильність маршрути зації дзвінків між користувачами в організації, а такі функції, як передача дзвінків, затримка, переадресація та конференція, працюють за призначенням. Повинні бути підтверджені цілісність план ів набору номера, підключення від розширення до розширення та підтримка політик організаційних викликів.

Обробка викликів користувача та перевірка функцій

Важливим аспектом приймального тестування є перевірка того, як користувачі обробляють дзвінки за допомогою та підтрим уваних настільних телефонів. Цей процес зосереджений на підтвердженні того, що щоденні робочі процеси дзвінків є інтуїтивно зрозумілими та надійними, а також що користувачі мають безперебійний доступ до основних функцій, необхідних для їхніх ролей. Тестування має оцінити легкість, з якою користувачі можуть розміщувати та приймати дзвінки, керувати функціями утримання та відновлення, а також виконувати як сліпі, так і консультативні перекази. Також важливо переконатися, що переадресація дзвінків, конференція та інші розширені можливості, такі як паркування та отримання дзвінків або активація «не турбувати», легко доступні та працюють безперебійно.

Досвід слід оцінювати на чіткість та оперативність, врахов уючи, як користувачі взаємодіють з історією дзвінків, голосовою поштою та інтегрованими каталогами. Додаткову увагу слід приділити можливості переміщення активних дзвінків між пристроями та ефективно використовувати елементи керування викликом у програмі або на фізичних телефонях. Кінце ва мета полягає в тому, щоб досвід кінцевого користувача був послідовним, ефективним і повністю підтримував потреби організації в комунікаціях після мі грації.

Черги дзвінків: досвід агента та керівника

Черги викликів часто використовуються для обробки сценаріїв вхідних дзвінків великого обсягу. Приймальне тестування тут зосереджується на декількох вимірах. По-перше, слід перевірити, що виклики розподіляються агентам відповідно до налаштованої логі ки черги, наприклад, round robin, найдовший неробочий час або одночасний дзвінок. Презентація дзвінків у черзі на робочому столі агента повинна бути перевірена на чіткість та простоту використання, гарантуючи, що агенти можуть ефективно приймати, утримувати та передавати дзвінки.

Для керівників досвід роботи на робочому столі слід оцінювати на такі функції, як моніторинг у режимі реального часу, розгортання дзвінків та аналітика або уявлення про ефективність черги. Це включає, але не обмежується, перевірку інформаційних панеле й та інструментів звітності, які надають дієві дані про розподіл дзвінків, активність агента та показники черги.

Групи полювання: Розподіл дзвінків

Групи полювання є ключовим механізмом розподілу викликів попередньо визначеним наборам користувачів. Приймальне тестування має підтвердити, що дзвінки маршрутизуються членам групи на основі налаштованого алгоритму полювання, і що сценарії переповнення, переадресації та відсутності відповіді обробляються відповідно до дизайну. Забезпечення того, що членство в групі та поведін ка маршрутизації дзвінків відповідають встановленим раніше, має важливе значення для послідовності роботи та задоволеності користувачів.

Автосервіси: Оголошення та операції меню

Автосервіси представляють передову лінію автоматизованої обробки дзвінків. Тестування повинно охоплювати відтворення оголошень, точність записаних привітань та правильність роботи дерев меню. Вибір меню повинен надійно направляти абонентів до відповідних відділів, приватних осіб або зовнішніх номерів. Тестування також повинно включати недійсні сценарії або сценарії тайм-ауту, щоб підтвердити, що абоненти отримують чіткі вказівки або перена правляються за призначенням.

Операція голосової пошти

Нарешті, функціональність голосової пошти має вирішальне значення для досвіду користувача. Приймальні тести повинні перевірити, чи коробки голосової пош ти правильно призначені та доступні як всередині організації, так і віддалено. Можливість запису, отримання та управління повідомленнями повинна бути підтверджена разом із доставкою сповіщень.

Оптимізувати

Міграція PSTN до хмарного підключення для

Оптимізація локальної інфраструктури

Використовуйте аналітику та усунення несправностей

Міграція PSTN до хмарного підключення для

Після перенесення всіх кінцевих точок та користувачів до хмарних викликів єдиною метою 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, крім виведення з експлуатації та локальних шлюзів.

Оптимізація локальної інфраструктури

Після переходу всіх користувачів і переходу всіх кінцевих точок на хмарну реєстрацію (або виведені з експлуатації), оновіть відповідну локальну інфраструктуру тепер, коли використовується хмарний виклик. Оновлення інфраструктури включають:

Видаліть локальні DNS SRV записи керування викликами та повідомленнями з локальних серверів DNS, включаючи cisco_uds. _tcp. <domain>, вхід на чашку. _tcp. <domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб.

Видаліть DNS SRV записи, пов'язані з краями, з загальнодоступної системи DNS, включаючи collab_edge. _тлс. <domain>. Ці записи SRV більше не потрібні для виявлення клієнтських служб периферійних служб співпраці.

Оновіть всі відповідні області DHCP, щоб видалити адреси TFTP/завантажувального сервера опції 66 та параметра 150. Ці області більше не потрібні для виявлення та завантаження конфігурації керування викликом кінцевих точок.

Оновлення/видалення відповідних аналогів у локальному шлюзі/кубі, які маршрутизують дзвінки до та з. Unified CM Ці аналоги комутованого зв'язку більше не потрібні для локальної маршрутизації викликів.

Видалити або видалити всі віртуальні машини і/або сервери вузлів кластерів. За потреби змінюйте обчислювальні ресурси та обладнання . Ці ресурси більше не потрібні для керування викликами та крайових служб.

Видалити або видалити всі віртуальні машини та/або сервери вузлів кластера. За потреби змінюйте обчислювальні ресурси та обладнання . Ці ресурси більше не потрібні для голосової пошти та уніфікованих служб обміну повідомленнями .

Очищення: після перенесення доступу PSTN до хмарного PSTN можна вивести з експлуатації магістралі PSTN, шлюзи PSTN та локальний шлюз.

Для будь-якого існуючого локального рішення E911 видаліть усі місця або номери, які перенесли , і після завершення повного переходу видаліть віртуальні машини або сервери додатків. За потреби змінюйте обчислювальні ресурси та обладнання . Ці ресурси більше не потрібні для екстрених викликів та служб визначення місцезнаходження.

DNs, що належать переміщеним користувачам, слід розміщувати в при хованому розділі, щоб уникнути збоїв маршрутизації викликів та забезпечити пріоритетний доступ всіх CSS-систем до хмарного шляху тих самих DNS.

Оновлюйте фізичне місце розташування та мережевий елемент у мобільності горизонту, коли відбуваються зміни. Поширеними заходами, які потребують оновлення, є:

Заміна мережевого комутатора

Заміна бездротової точки доступу

Зміни сфери DHCP

Фізичні зміни всередині будівлі (якщо вони вирішуються на кубічні/офіс)

Фізичне розширення або скорочення офісного приміщення всередині будівлі.

Використовуйте аналітику та усунення несправностей

надає комплексні можливості аналізу та усунення несправностей, які допоможуть візуалізувати та відстежувати розгортання. Вони охоплюють якість медіа, детальну історію дзвінків, чергу дзвінків, групу полювання та автоматичну аналітику супутників. Приклад аналітики якості медіа показаний на малюнку аналітика якості медіа.

аналітика якості медіа

У розділі усунення несправностей кожен дзвінок, здійснений за допомогою, можна переглянути з детальною інформацією про ключові якості носіїв та проблеми, пов'язані з сигналізацією, щоб допомогти точно визначити проблеми із медіа, а також невдалими дзвінками, як показано на малюнку усунення несправностей якості медіа.

усунення несправностей якості медіа

усунення несправностей також можна інтегрувати з іншими продуктами Cisco, такими як комутатори ThousandEyes та Meraki, щоб забезпечити ще багатший інтегрований досвід роботи в Control Hub. Докладніші відо мості про використання Webex Callingаналітики та усунення неполадок див. у розділі Виправ лення не Webex Calling поладок викликів у Центрі керування.

Вступ

Перш ніж почати

Огляд

Основні компоненти

Огляд процесу PPDIO

Загальний опис PPDIO

Використання PPDIO для проектів міграції з Unified CM до Webex Calling

Підготовка

Планування

Проєктування

Впровадження

Оптимізація

петлі зворотного зв'язку PPDIO

Підхід до міграції

Перш ніж почати

Цей посібник призначений для команд або окремих осіб, які мають досвід налаштування та адміністрування 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 для масштабування та підключення. Учасники корпоративної мережі та віддалені учасники поза межами корпоративної мережі можуть спілкуватися за допомогою апаратних кінцевих точок на базі 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

Після: У таблиці «Компоненти інфраструктури хмарних викликів » перелічено нові елементи архітектури після переходу на 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

Підготуйте: Оцініть поточне середовище, зберіть вимоги та узгодьте дії зацікавлених сторін для створення міцної основи.

План: Розробіть детальні плани проектів, включаючи терміни, ресурси та стратегії зменшення ризиків.

Дизайн: Розробити цільове рішення, адаптоване до бізнес-потреб та технічних потреб.

Впровадити: Виконайте розгортання або міграцію відповідно до проєкту, перевіривши функціональність та продуктивність.

Оптимізувати: Постійно вдосконалюйте рішення після впровадження, контролюючи продуктивність, удосконалюючи конфігурації та використовуючи інструменти автоматизації та інтеграції.

Використання 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 висновки на пізніших етапах часто вимагають повторного розгляду та потенційного перегляду рішень, прийнятих на попередніх етапах. Наприклад, проблеми, що виникли на етапі впровадження, такі як виявлення неоднозначностей у проектуванні або відсутні деталі, можуть свідчити про те, що певні аспекти не були повністю враховані на етапі проектування. У таких випадках стає необхідним повернутися до відповідного попереднього етапу, щоб вирішити ці проблеми, перш ніж продовжувати. Цей ітеративний механізм зворотного зв'язку, як показано на рисунку , уніфікований процес 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 фази.

Рекомендований 3-фазний перехід

Перед міграцією: Цей етап зосереджений на підготовці середовищ Webex та Unified CM до міграції. Йдеться не про виклик конкретного планування чи налаштування, а про виконання дій, які можна виконати зараз і до початку будь-якого проекту міграції Webex Calling. Мета полягає в тому, щоб створити основу для двох середовищ, щоб підготуватися до міграції.

Підготовка до міграції: На цьому етапі починаються зусилля з підготовки до міграції на Webex Calling. Тут необхідно переглянути та оновити бізнес-вимоги та технічні вимоги. Не просто піднімайте та змінюйте те, що зараз розгорнуто за допомогою Unified CM, а натомість переосмисліть бізнес- та технічні вимоги, які потрібні вашій компанії сьогодні та в майбутньому, використовуючи можливості Webex Calling. Крім того, це етап, на якому ви завершите проектування, планування конфігурації та міграцію. planning/schedule.

Міграція (розгортання та виведення з експлуатації): На цьому етапі відбувається фактична міграція користувачів, пристроїв, номерів телефонів та програмних клієнтів. Як обговорювалося вище, цей етап можна виконати для всіх одночасно (блискавично скорочення) або протягом кількох вікон змін (поетапне скорочення). Плани впровадження для кінцевих користувачів, навчання та комунікації є критично важливими, щоб ваші користувачі були обізнані зі змінами, знали, як використовувати нову платформу викликів, і коли зміни відбудуться. Останнім кроком є виведення з експлуатації всієї локальної інфраструктури уніфікованих комунікацій, яка більше не використовується.

Фаза підготовки до міграції включає дії (обов’язкові, рекомендовані та необов’язкові), над якими ви можете негайно розпочати роботу. Рекомендується виконати їх якомога раніше, а краще до початку вашого проєкту. Деякі дії можуть тривати довше, тому їх ранній початок допоможе оптимізувати ваш фактичний проект міграції.

На рисунку «Підготовчі дії до міграції нижче показано п’ять конкретних категорій дій, пов’язаних із міграцією 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 та надають можливості голосових та відеодзвінків

Таблиця 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 для здійснення дзвінків.

Підготовка

Бізнес- та технічні вимоги

Чому важливо збирати вимоги:

Вимоги бізнесу

Технічні вимоги

Готовність до мережі та вимоги

Налаштування хмарно-підключеного UC

Оцінка поточного середовища

Ліцензування

Locations/Sites

наявний інвентар devices/clients

Перевірте придатність пристрою

Користувачі

Підключення до PSTN

Особливості & використання функцій

Інтеграції Cisco: Unity Connection UCCX UCCE

Запис викликів

Інтеграції зі сторонніми розробниками

Бізнес- та технічні вимоги

Під час планування міграції з на , вкрай важливо ретельно зібрати як технічні, так і бізнес-вимоги на етапі планування. Цей крок гарантує, що міграція відповідає операційним цілям та технічним можливостям вашої організації, мінімізуючи ризики та збої.

Чому важливо збирати вимоги:

Узгоджує бізнес-цілі: Розуміння потреб бізнесу допомагає адаптувати міграцію до ключових робочих процесів, зручності використання та планів зростання.

Забезпечує технічну сумісність: Раннє визначення технічних вимог запобігає проблемам інтеграції з існуючою інфраструктурою, мережею та кінцевими точками.

Сприяє плануванню ресурсів: Чіткі вимоги допомагають точно оцінити терміни, витрати та необхідні ресурси.

Зменшує ризики: Раннє виявлення потенційних проблем дозволяє приймати проактивні рішення, зменшуючи час простою та переривання обслуговування.

Вимоги бізнесу

Типові бізнес-вимоги включають:

Кількість користувачів і місць розташування, яких потрібно перенести

Бажані функції та послуги (наприклад, маршрутизація викликів, голосова пошта, конференц-зв'язок, автосекретарі, черги викликів)

Політики відповідності та безпеки

Бюджетні обмеження та очікувані витрати

Потреби в навчанні та підтримці користувачів

Графік міграції та міркування щодо безперервності бізнесу.

Збір бажаних функцій та послуг є критично важливим кроком для забезпечення відповідності нової системи потребам бізнесу. Збираючи ці вимоги, важливо не лише враховувати поточні налаштування, але й спробувати зібрати фактичні вимоги від бізнес-суб'єктів, які збираються використовувати систему. В іншому випадку існує ризик того, що план базується на непоточних припущеннях. Обов’язково оцініть додаткові або розширені функції, доступні в , яких може бути немає в , такі як хмарні виклики, розширені черги викликів тощо. Це допомагає використовувати всі переваги хмарної платформи.

Під час оцінки поточної конфігурації в , важливо розуміти, що не всі існуючі налаштування можуть залишатися необхідними через зміну вимог протягом життєвого циклу системи. Основна увага має бути зосереджена на визначенні та збереженні лише тих конфігурацій, які відповідають поточним та майбутнім потребам розгортання.

Зосередьтеся більше на тому, що вам потрібно, ніж на тому, що у вас є.

Політики відповідності та безпеки є критично важливими міркуваннями під час міграції з 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, щоб допомогти визначити групи користувачів із цими залежностями.

Підключення до 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 щоб переглянути конфігурації в графічному інтерфейсі або в даних експорту конфігурації.

Інтеграції 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.

Інтеграції зі сторонніми розробниками

підтримує різноманітні інтеграції сторонніх розробників, включаючи, але не обмежуючись, SBC для локальних шлюзів, IP-телефонів, домофонів, Speaker/Pagers, ATA тощо. Окрім цих сторонніх^{пристроїв}, Webex Calling підтримує різні сторонні^{рішення} для підтримки клієнтів, аналітики, запису, виставлення рахунків тощо. Щоб отримати додаткові відомості про рішення сторонніх^{розробників}, див. Центр додатків Webex.

Таблиця 1. Приклад оцінювання
Вимоги	Ключові міркування
Готовність мережі та пропускна здатність	Пропускна здатність, якість обслуговування (QoS), WAN/Internet, Firewall/NAT
Інтеграція з існуючими системами	Довідник, CRM, АТС, Email/Calendar
Сумісність та забезпечення кінцевих точок	Підтримка пристроїв, налаштування, оновлення прошивки
Конфігурації безпеки та шифрування	Шифрування, автентифікація, відповідність вимогам, моніторинг безпеки
Навчання користувачів та управління змінами	Навчальні програми, документація, комунікація змін
Перенесення номерів та тарифний план	Номер migration/porting, переклад плану набору номера
Інтеграції зі сторонніми розробниками	Пейджинг, контакт-центр, факс, аналогові пристрої

Таблиця 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 кбіт/с = Необхідна пропускна здатність мережі

Таблиця 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 Мбіт/с

Таблиця 4. План переходу користувачів за сайтом
Сайт користувача / місцезнаходження	Інформація та навчальні сесії перед переходом	Перехідний період	Підтримка після переходу
Нью-Йорк (1525 користувачів)	Тиждень з 1 квітня	15 квітня – 27 квітня	Тиждень з 29 квітня
СФО (1600 користувачів)	Тиждень з 6 травня	20 травня – 31 травня	Тиждень з 3 червня
RTP (1275 користувачів)	Тиждень з 3 червня	17 червня – 28 червня	Тиждень з 1 липня

Таблиця 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

Таблиця 7. включені опції запису
Webex	Даббер Го
Доступно для всіх користувачів	Доступно для всіх користувачів
Необмежена кількість записів	Необмежена кількість записів
Термін зберігання 1 рік*	30-денний період зберігання
100 ГБ сховища на організацію	-
Співробітники з дотримання вимог можуть отримувати доступ до записів дзвінків та керувати ними	-
API для керування записами	-
Адміністратори можуть налаштовувати та керувати доступом користувачів до записів їхніх дзвінків Користувачі можуть керувати власними записами за допомогою Центру користувача and/or додаток 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	Налаштування угоди про синхронізацію за допомогою фільтрації на основі групи: під час налаштування угоди про синхронізацію в каталозі Connector або створення ідентифікатора Entra, налаштуйте область так, щоб вона включала лише користувачів, які є членами визначеної групи. Для ідентифікатора Microsoft Entra ID можна використовувати групові призначення в налаштуваннях забезпечення Для AD можна визначити фільтр LDAP для включення лише користувачів, що належать до вказаної групи.
4	Розширюйте групу за потреби: Коли ви переходите до більш широких етапів розгортання, просто додайте додаткових користувачів або групи до групи синхронізації. Область синхронізації автоматично розшириться, включивши цих користувачів, дозволяючи контрольоване та поступове розгортання. Приклад кроків реалізації: В активному каталозі: Створіть групу безпеки з назвою група синхронізації. Додайте бажаних пілотних користувачів до цієї групи. Налаштуйте роз'єм каталогів за допомогою фільтра LDAP, наприклад: (MemberOF=CN = Група синхронізації WebEx, OU = Групи, DC = Ваш домен, DC = COM). У корпорації Майкрософт введіть ідентифікатор: Створіть групу з назвою група синхронізації Призначте групу до налаштувань забезпечення ідентифікатора Entra ID Тільки користувачі цієї групи будуть забезпечені. Завжди перевіряйте синхронізацію на основі групи в невиробничому середовищі, перш ніж застосовувати до всієї організації Регулярно перевіряйте членство в групі, щоб забезпечити синхронізацію лише авторизованих користувачів Для постійного управління автоматизуйте оновлення членства в групі на основі бізнес- правил або систем управління персоналом, якщо це можливо. Посилання: Синхронізація користувачів ідентифікатора Entra з Контрольним центром Налаштування програми майстра ідентифікатора Entra ID у Центрі керування Роз'єм каталогу

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

Оцінка поточного середовища

Ліцензування

Місцезнаходження/Сайти

Інвентаризація існуючих пристроїв/клієнтів

Перевірте відповідність пристрою

Користувачі

Підключення PSTN

Особливості та використання функцій

Інтеграція Cisco: Підключення Unity UCCX UCCE

Запис дзвінків

Інтеграція третіх сторін

План

План проекту високого рівня

Міграційна подорож - один-два кроки?

Варіант 1: Однокрокова міграція користувача

Варіант 2: двоетапна міграція користувачів

Крок 1

Крок 2

Дизайн

Вибір регіону

Місцезнаходження

PSTN

План набору номера

Місцевий план набору номера

план набору номера

Запис

1. Вибір провайдера запису дзвінків

2. Вибір регіону

Екстрений виклик

Ліцензування

Ручне призначення через

Шаблони автоматичного присвоєння ліцензії

Масове призначення за допомогою шаблону CSV

Призначення на основі API

Вимоги до ліцензії

Забезпечення користувача

Групи користувачів

Рекомендований підхід при міграції з на

Розробка груп користувачів

Єдиний вхід (SSO)

Підтримка декількох IdP

1. Злиття та поглинання

2. Кілька незалежних ІТ-відділів

3. Різні групи користувачів або домени

4. Підтримка різних протоколів аутентифікації

5. Покращена безпека та відповідність

6. Спрощений досвід користувача

Дует МФА з SSO для

Особливості

Автосервіс

Дзвінок Парку

Підбір дзвінків

Черга дзвінків

Хант Груп

Режими роботи

Пейджінгова група

Записи