Ръководство за внедряване

Въведение

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

Това ръководство е предназначено за екипи или лица с опит в конфигурирането и администрирането на 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 компоненти е от съществено значение, за да се осигури ефективна стратегия за преход и оперативна готовност.

Контролен център
Осигуряване на директории и потребители
Webex Callingплатформа
Поддържани крайни точки за извикване
Опции за свързване на PSTN
Webex Callingплан за набиране и управление на номера
Характеристики за сигурност и съответствие.

За повече информация вижте Пред почитаната архитектура на Cisco заWebex Calling.

Това ръководство ще подчертае инструментите и процесите, които да се използват през целия жизнен цикъл на прехода. Преходът от локални обаждания към нова платформа за обаждания в облак Webex Calling обаче може да бъде значително усилие при потенциални бизнес, технически и сложни предизвикателства. Unified CM За да помогне за преодоляването на тези предизвикателства Cisco разполага с няколко различни опции, които да ви помогнат в пътуването ви. Важно е да прегледате информацията в Enterprise cloud call - Calling migration и да разберете всяка опция и как всяка от тях може евентуално да ви помогне със собствената си миграция.

Инструменти за миграция на Webex: самообслужване, безплатни инструменти, вградени в Control Hub за рационализиране на прехода към 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 за пътека за отдалечен достъп и крайни услуги от бизнеса към бизнеса (B2B), Cisco Meeting Server/ Cisco Meeting Management за локални конферентни връзки, Unity Connection за гласови съобщения и хардуер, насочен към потребителя (Cisco IP телефони, Cisco Desk и Room видео системи) и софтуер (IP базирани крайни точки). Cisco Jabber Тези компоненти могат да варират леко в някои среди, но това е отправната точка за прехода, описан в останалата част от този документ.

On-Premises Collaboration Architecture: Call Control and Remote Access — ***Локална архитектура за сътрудничество: управление на повиквания и отдалечен достъп***

Архитектурата, показана на фигура Архитектура за локално сътрудничество: управление на повиквания и отдалечен достъп се основава на предпочитаната архитектура (PA) за локални внедрявания на Cisco Collaboration Enterprise. За повече информация относно Enterprise On-premisses вижте предпочитаните архитектури на Cisco за сътрудни чество.

Преди: Таблицата за локални компоненти на инфраструктурата за извикване изброява ключ овите елементи на локалната архитектура преди преминаването към обла Webex Calling ка.

Таблица 1. Преди: Локално извикване на компоненти на инфраструктурата
Продукт	Описание
Unified CM	Локален контрол на повикванията, предоставящ услуги за регистрация на устройства и маршрутизиране на повиквания
Cisco Expressway-С/Е	Edge инфраструктура, предоставяща мобилна и Remote Access (MRA) и функционалност от бизнеса към бизнеса (B2B), позволяваща на отдалечените крайни точки да се свързват сигурно извън организацията. Експресната пътека се разгръща по двойки, за да осигури преминаване на защитната ст ена за външни крайни точки.
Сървър за срещи на Cisco (CMS), Cisco за управление на срещи (CMM) и Cisco TelePresence Management Suite (TMS)	Локална инфраструктура за гласови, видео и уеб конференции, осигуряваща многоточкови срещи, управление на срещи и възможности за планиране. [По желание]
Cisco Unity Connection	Локална платформа за гласови съобщения, предоставяща възможности за гласова поща и унифицирани съобщения . [По желание]
Бюро на Cisco, стая на Cisco, борд на Cisco, IP телефони на Cisco и Cisco Jabber	IP базирани устройства, регистрирани Unified CM и предоставящи възможности за гласови и видео разговори

Както е илюстрирано на фигура Решение за преход: локално обаждане към Webex Calling, клиентите, които имат локален контрол на разговорите Unified CM и настолни и видео IP крайни точки, имат избор да прехвърлят архитектурата към облачна архитектура. Webex Calling

Решението трябва да бъде взето въз основа на изискванията за функционалност на клиента. Клиентите, които имат следните изисквания, трябва внимателно да обмислят, преди да вземат това решение и в крайна сметка могат да решат да запазят контрола на повикванията на място:

Модели на телефони, които не се поддържат от Webex Calling
Сложни или многобройни интеграции с други локални системи или решения, особено когато възпроизвеждането на тези интеграции Webex Calling е трудно или няма налични еквивалентни алтернативни решения
Сложен план за набиране, много подробни класове услуги или и двете
Ограничителен, ограничен или ненадежден достъп до интернет
Строги политики за поверителност и собственост на данните
Изискване за съответствие за запис и съхранение на носители на локални или вътрешни
Интеграции на трети страни без жизнеспособна алтернатив Webex Calling на интеграция
Интеграции на контактни центрове, при които контактният център inter все още не се премества в облака.

Transition Decision: On-Premises Calling to Webex Calling — ***Решение за преход: локално обаждане до Webex Calling***

Клиентите, които искат да започнат да използват услугите за обаждания в облак, трябва да помислятWebex Calling. Тази услуга за обаждания в облак позволява на клиента да използва глобалната архитектура на Webex за мащаб и свързаност. Участниците в корпоративната мрежа и отдал ечените участници извън корпоративната мрежа могат да комуникират чрез IP базирани хардуерни крайни точки и/или настолни или мобилни меки клиентски приложения.

Този документ се фокусира върху клиенти с внедряване за контрол на Unified CM повикванията, които искат да разберат общите стъпки, съображения и изисквания за разрешаване на в Webex Calling недряването, както е изобразено в следващия раздел.

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

Целевата архитектура за тази миграция включва няколко нови компонента. Това включва Webex Calling услугата за обаждания, базирани на облак, Webex App, Cisco Directory Connector за интеграция на самоличност и Local Gateway (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 Wizard.
Локален шлюз	Локалният шлюз действа като мост между локалната унифицирана комуникационна мрежа на клиента и Webex Calling облака. Тя може да бъде внедрена локално или хоствана от партньор, като предоставя PSTN достъп за регистрирани в облака крайни точки, както и извиква интеграция между Unified CM регистрирани и регистрирани в облак крайни точки. Cisco IOS-XE интегрирани услуги маршрутизатор (серии ISR 1100 и 4000), Cisco Catalyst серия 8200/8300, софтуер Cisco Catalyst 8000V Edge и различни сертифицирани контролери на сесии на трети страни (SBC) могат да се използват като LGW за подход за поетапна миграция.
Шлюз за оцеляване	Survivability Gateway (SGW) е локален мрежов шлюз, базиран на IOS-XE, който предоставя услуги за резервни обаждания до крайни точки на място по време на прекъсвания в мрежата. Webex Calling
План за обаждания на Cisco, Cloud Connect за Webex Calling	Cisco Calling Plan и Cloud Connect for Webex Calling са базирани на облак опции за достъп до PSTN за крайни точки. Webex Calling Достъпът до PSTN се улеснява от доставчик на PSTN в облак и не изисква локално оборудване.
Приложение Webex	Клиентско приложение, работещо на настолна операционна система (Windows, Mac) или мобилна операционна система (Android, iOS) и регистрирано директно в Webex Calling платформата за функционалност за повикване.

Преглед на процеса на PPDIO

Процесът PPDIO означава Под готовка, планиране, проектиране, изпълнение и оптимизиране. Това е структурирана методология на Cisco, която ръководи проектите от първоначалната оценка през непрекъснато усъвършенстване, осигурявайки ефективно и успешно внедряване или миграция.

Общо описание на PPDIO

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

Използване на PPDIO за Webex Calling мигра Unified CM ционни проекти

При преминаване от Unified CM към Webex Calling процесът PPDIO предоставя ясна пътна карта за осигуряване на плавен и ефектив ен преход:

Подгответе

Оценка на съществуващата Unified CM среда и готовност за миграция
Събирайте подробни данни за потребители, устройства, мрежа и зависимости
Събирайте подробности за местоположението, включително адрес за аварийна реакция, брой потребители, достъп до интернет, достъп до PSTN
Идентифициране на рисковете и определяне на обхвата на проекта, за да се съобразят всички

План

Създайте изчерпателен план за мигриране с пакетни графици, присвояване на ресурси и сро кове
Определяне на задачи като надстройки на фърмуера на устройството, предоставяне на лицензи и включване на потребителите
Координирайте прозорците за миграция с Cisco и партньорите, за да свед ете до миниму

Дизайн

Начертавайте тек Unified CM ущите конфигурации, плановете за набиране и потребителските профили с Webex Calling еквиваленти
Проектирайте Webex Calling средата, включително PSTN стратегия (междинна и окончателна), местоположения, потребителски роли и точки за интеграция като Local Gateway (CUBE) и синхронизация на директории
Планирайте сценарии за съвместно съществуване, където Unified CM и Webex Calling работят едновременно по време на миграцията.

Прилагане

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

Оптимизиране

Постоянно следете Webex Calling производителността и потребителското изживяване
Прецизирайте конфигурациите и работните потоци въз основа на оперативни данни и обратна връзка
Използвайте възможностите за автоматизация и интеграция, за да подобрите ефективността и ма щабируемостта
Наследени Unified CM компоненти от извеждане от експлоатация, ако е целесъобразно, и осигуряват текуща подкрепа за операциите втори

Този подобрен PPDIO подход осигурява контролирана, прозрачна и ефективна миграция от Unified CM към, като използва инструментите на CiscoWebex Calling, API и партньорската екосистема за поддържане на непрекъснатостта на бизнеса и подобряване на възможностите за сътрудничество.

PPDIO контури за обратна връзка

Прегледът на високо ниво, изобразен в Итера циите на фигурите при изпълнение на PPDIO, илю стрира единичен цикъл за обратна връзка от фазата на оптимизи ране обратно до фазата на подготовка . Това означава, че след първоначалното изпълнение съществува постоянна възможност за непрекъснато усъвършенстване. Всеки цикъл на оптимизация може да идентифицира нови изисквания или области за подобряване, които могат да бъдат адресирани чрез последващи проекти или инициативи. Тези индивидуални проекти от своя страна следват установения PPDIO (Подготовка, планиране, проектиране, изпълнение, оптимизиране) жизнен цикъл. Този итеративен подход гарантира, че системата остава в съответствие с развиващите се бизнес цели и технологичния напредък, насърчавайки културата на непрекъснато усъвършенстване и адаптивност.

Iterations while executing PPDIO — ***Итерации при изпълнение на PPDIO***

По време на изпълнението на процеса на PPDIO е обичайно констатациите в по-късните фази да изискват преразглеждане и потенциално преразгле ждане на решенията, взети на по-ранни етапи. Например проблеми, възникнали по време на етапа на изпълнение, като например идентифицирането на неяснотите в проекта или липсващите детайли, могат да разкрият, че някои аспекти не са били напълно разгледани по време на етапа на проектиране. В такива случаи става необходимо да се върнете обратно към съответната по-ранна фаза, за да разрешите тези проблеми, преди да продължите. Този итеративен механизъм за обратна връзка, както е илюстрирано на PPDIO процес, Unified CM подпома ган от фигура, гарантира, че решението е задълбочено валидирано и усъвършенствано, като в крайна сметка допринася за по-стабилно и ефективно внедряване.

Unified CM assisted PPDIO process — ***Unified CMасистиран PPDIO процес***

Когато се предприема преход от Unified CM къмWebex Calling, всяка фаза от процеса на PPDIO може да се възползва значително от информацията, събрана от съществува щата Unified CM среда. Например, изчерпателни описи на потребители, телефонни номера, функции за повикване и компоненти на план за набиране могат да бъдат извлечени от текущата Unified CM конфигурация. Тези данни допълват информацията, предоставена директно от заинтересованите страни, и спомагат за рационализиране на дейностите по планиране и проектиране. Използването на подходящи инструменти за автоматизиране на извличането и анализа на данни не само повишава точността, но и ускорява цялостния процес. Чрез използване на прозрения от съществуващото внедряване, преходът към Webex Calling може да бъде извършен по-ефективно от традиционното изпълнение на зелено поле, като същевременно се придържа към структурираната PPDIO методология. Този процес е илюстриран в PPDIO процес, Unified CM асистиран от фигура.

Миграционен подход

Докато планирате прехода си от локално Unified CM къмWebex Calling, трябва да определите как ще подходите към това пътуване. Първо ще трябва да решите дали мигра цията ще бъде флаш -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 фази.

Recommended 3-Phase Transition — ***Препоръчителен трифазен преход***

Предмиграция: Тази фаза се фокусира върху подготовката както на Webex, така и на околната Unified CM среда за миграцията. Тук не става въпрос за извикване на конкретно планиране или конфигурации и се фокусира върху завършване на дейности, които могат да бъдат извършени сега и преди да започне Webex Calling всеки проект за миграция. Целта е да се изгради основата на двете среди, за да се подготви за миграцията.

Подгот@@ овка за миграция: Тази фаза е мястото, където започват усилията за подготовка за миграцията към Webex Calling. Тук бизнес и техническите изисквания трябва да бъдат прегледани и актуализирани. Не правете просто повдигане и измест ване на това, с което се използва понастоящем, Unified CM а вместо това предефинирайте бизнес и техническите изисквания, от които се нуждае вашата компания днес и в бъдеще, като се възползвате от силата на това. Webex Calling В допълнение, това е фазата, в която ще завършите вашия дизайн, планиране на конфигурация и планиране/график за миграция.

Миграция (внедряване и извеждане от експлоатация): Тази фаза е мястото, където се случва действителната миграция на потребители, устройства, телефонни номера и меки клиенти. Както бе обсъдено по-горе, тази фаза може да бъде завър шена за всички наведнъж (ф лаш -изряз ване) или през множество прозорци за промяна (поетапно изрязване). Плановете за приемане на крайни потребители, обучението и комуникациите са от решаващо значение, така че вашите потребители са наясно с промените, как да използват новата платформа за обаждания и да знаят кога ще се случи про мяната. Последната стъпка е да се изключи цялата локална 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) е основно изискване за осигуряване на възможно най-доброто потребителско изживяване от край до край за всички гласови и видео крайни точки, клиенти и приложения, които използват.

Клиентите и партньорите имат опции за достъп до свързаност извън Over-the-Top (OTT) интернет, които могат да оптимизират връзката за включ Webex Edge ване на Connect. За повече информация относно подробностите за дизайна на Webex Edge Connect вижте Пред почитана архитектура на Cisco за Webex Edge свързванеWebex Meetings, извикване на множество наематели и специален екземпляр .

Клиентите могат да използват cScan за оценка на мрежата, която дава информация за качеството на мрежата на клиента, колко разговори могат да бъдат установени, латентността и т.н. За повече информация относно инструмента cScan вижте Използване на cS can за тестване на качеството на Webex Calling мрежата.

За да сте сигурни, че мрежата е готова за миграция, помислете за следния контролен списък:

планиране на честотната лента

Изчислете едновременните повиквания на сайт, за да сте сигурни, че имате достатъчно честотна лента на горе и надолу по веригата и да включите пространство за друг критичен за бизнеса трафи к и бъдещ растеж.

Таблицата Webex Calling за изчисления на честотната лента на ти па повикване показва типовете повиквания, налични с внедряване, заедно с кодека и максималната честотна лента, необходима за всеки тип повикване. Както е показано в таблицата Webex Calling за изчисления на честотната лента на ти па повикване, необходимата честотна лента за аудио повикване за всеки тип повикване може да бъде изчислена по следната обща формула:

Брой очаквани едновременни повиквания * Честотна лента на повикване въ з основа на кодек = Необходима мрежова пропускателна способност.

Таблица 2. Webex Calling изчисления на честотната лента тип повикване
Видове обаждания	Кодек - честотна лента	Изчисления на честотната
/Телефон за бюро ->	ОПУС - 70 kbps	Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> Телефон за бюро	ОПУС — 70 кб/с	Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност
/Настолен телефон -> PSTN чрез LGW	Г.711 - 80 кб/с	Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Настолен телефон -> PSTN чрез облачен PSTN (напр. План за обаждания на Cisco)	Г.711 - 80 кб/с	Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> Предприятие чрез LGW	Г.722 - 80 кб/с	Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> гласова поща	ОПУС — 70 кб/с	Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност

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

Всички крака за повикване винаги са закотвени върху SBC за достъп. За да се определи необходимата интернет честотна лента за дадено местоположение, трябва да се вземат предвид не само разговорите между местоположенията, но и обажданията в рамките на локацията и обажданията до и от локален шлюз на това място. Например, обаждане в рамките на сайта между два MPP телефона ще се нуждае от до 2 x 70 kbps пълен дуплекс за достъп до интернет на местоположението.

Табли Webex Callingцата с примери за изчисл яване на честотната лента показва пример за пълно упражнение за изчисляване на честотната лента, като се приеме, че всички устройства са на един и съ щ сайт.

Таблица 3. Webex Calling примери за изчисляване на честотната
Видове обаждания	Брой едновременни обаждания	Обща честотна лента
Приложение Webex/Настолен телефон → Приложение Webex	15	2* 15* 70 кб/с = 2,100 кб/с
Приложение Webex/Телефон за бюро → Телефон за настолен	15	2* 15* 70 кб/с = 2,100 кб/с
Приложение Webex/Настолен телефон → PSTN чрез LGW	50	2 * 50 * 80 кб/с = 8 000 кб/с
Приложение 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 App и телефоните MPP 8845/65 поддържат H.264 видео с максимална разделителна способност 720p при максимална честотна лента от 1500 kbps на разговор. Въпреки това, количеството честотна лента, консумирана във всеки момент по време на разговора, ще варира въз основа на променливата скорост на предаване, присъща на видео комуникациите.

Качество на услугата (QoS)

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

Следните прагове се препоръчват за оптимално качество на гласа, когато обажданията преминават през отгоре (OTT) и в интернет:
- Латентност - по-малко от 100 ms еднопосочна
- Треперене - по-малко от 10 ms
- Загуба на пакети - 0.5% или по-малко.
Защитна стена и NAT

Уверете се, че защитната стена е конфигурирана да позволява трафик, както е изброено в статията, налична в референтната информация за порт Webex Calling. Освен това позволете достъп до домейни и 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.
Потребители и устройства

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

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

Местоположения/сайтове

Броят и типовете обекти (големи централни, регионални, клонови и т.н.) в рамките на съществуващото ви разполагане трябва да се вземат предвид при планирането на този преход. Пълното разбиране на съществуващите места за разполагане ще помогне за стратегическото планиране на успешен преход, особено когато става въпрос за определяне на кои обекти да мигрират и в какъв ред. Разбирането на подробните изисквания за план за набиране (номериране, навици за набиране, класове ограничения и т.н.), свързаността на мрежата на сайта и честотната лента (Интернет, WAN, LAN) и достъп до PSTN (локален или централизиран, IP или TDM) за всеки сайт ще бъде от решаващо значение при вземането на решения за миграция. За повече информация относно общите модели на внедряване и ключови съображения вижте информацията за моделите за внедряване на сътрудничество, налична в SRND за сътрудни чество.

Друго важно съображение за внедряване при преминаване към е наличността на местоположението. има различни възможности, абонаменти и устройства, които са налични в зависимост от това къде се намира вашето внедряване. За повече информация относно географската наличност вижте Къде е наличен Webex? .

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

Инвентаризация на съществуващи устройства/клиенти

Преди да започнете прехода е важно да инвентаризирате съществуващите хардуерни и софтуерни крайни точки. Наличието на пълен списък с типовете устройства/модели, хардуерните версии, типовете и количествата на меките клиентски операционни системи ще гарантира, че можете адекватно да планирате прехода на устройствата и да смекчите въздействието на тези устройства, които не могат да бъдат мигрирани към обаждания в облак. Инвентаризацията трябва да се използва за определяне на устройствата за преход и устройствата, които трябва да се заменят преди прехода.

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

За аудио и видео настолни телефони се поддържат само настолните телефони от сериите 6800, 7800, 8800 и 9800. Това е подмножество от IP телефоните на Cisco, които се поддържат. Има някои модели и версии на телефоните 6800, 7800 и 8800, с които не могат да се използват. За повече информация за това кои модели и хардуерни версии се поддържат вижте Поддържани устройства за Webex Calling.

IP телефоните от серията Cisco 6800 не могат да бъдат надстроени от корпоративен фърмуер до мултиплатформен (MPP) фърмуер, който е необходим. Следователно всички 6800 телефона, регистрирани за работещ корпоративен фърмуер, трябва да бъдат заменени с модел 6800 MPP или с друг поддържан модел телефон.

IP телефоните от серията Cisco 7800 и 8800 трябва да бъдат надстроени до фърмуера на мултиплатформен телефон (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 обаждания, изискват лиценз за повикване:

Споделените устройства в конферентни зали, пространства за сгъване и т.н. изискват лиценз за професионално работно пространство или работно пространство.

Личното устройство на крайния потребител изисква професионален или стандартен лиценз.

Определете колко видео крайни точки са регистрирани и се използват за осъществяване на аудио разговори. Възможно е някои от крайните точки на видеоклипа да се използват само за присъединяване към срещи или извършване на 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телефоните работят с корпоративния фърмуер, докато телефоните работят с фърмуера с мултиплатформен телефон (MPP). Препоръчва се да проверите кои регистрирани телефони отговарят на условията за надграждане до MPP фърмуера по време на фазата на подготовка. Това ви дава време да замените неотговарящи на условията телефони с един от поддържаните модели телефони или да идентифицирате алтернативен план, като например преместване на потребител само в приложението Webex.

За да помогне при определянето на допустимостта на телефоните, Control Hub има вграден инструмент, наречен 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 телефона

Потребители

Една от най-важните стъпки за подготовка, за да сте сигурни, че имате успешна миграция, е правилното предостав яне на потребителя. Трябва да планирате правилно за всички потребители, дори ако правите поетапна миграция. Потребителите трябва да бъдат осигурени за някое от следните неща:

Разгръщане на с повикване

Разгръщане на с

Конфигуриране на услуги за потребител

За да може потребителите да могат да се търсят в директорията (кликване, за повикване, информация за контакт с потребителя, търсене на телефонна директория).

Препоръчително е да предоставите всички потребители преди или в началото на вашия проект. Това включва потребители, които все още използват платформата Unified CM за повикване, е независима от устройството им за повикване (IP телефон, Jabber,). Когато потребителите бъдат мигрирани към (и/или), вие ще актуализирате техните лицензи, за да активирате услугите, от които се нуждаят. Чрез предоставяне на всички корпоративни повикващи потребители преди започване на прехода ви позволява на потребител, който е преминал към или да търси в директорията потребител, който повиква корпоративен потребител, който все още е на Jabber и/или включен. Това гарантира, че преходните потребители могат да намерят информация за контакт на всеки друг потребител и да се обаждат с тях, като използват търсенето на директории.

Търсенето на директория с фигури показва пример за потребител, който търси друг потребител. Резултатите от търсенето показват информацията за контакт на потребителя и могат да бъдат за потребител, който все още е в Jabber или за потребител, който е преминал към и/или.

Търсене в директорията на Webex App

След това определете към кои от съществуващите локални повикващи потребители ще бъдат прехвърлени. Ако всички или голям брой потребители ще бъдат прехвърлени, тогава се препоръчва да преместите потребителите в групи, за да се гарантира, че екипът на проекта, ИТ персоналът и помощният персонал са в състояние да се справ ят с прехода и всички проблеми, които могат да възникнат. Също така трябва да отделите известно време, за да предоставите първоначална информация и обучителни сесии, за да подготвите потребителите за този преход. Групирането на потребителски преход може да се извърши въз основа на различни критерии, включително местоположението или сайта, към който са назначени потребителите, отделите на потребителите или дори типове потребители (работници по знания, ръководители, мобилни работници и т.н.).

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

Друг важен фактор е прехвърлянето на потребителите заедно, които имат зависимости помежду си. Това може да включва, но не се ограничава до следното:

BLF мониторинг

Същият лов пилот/група

Споделяне на редове

Част от една и съща група за вземане на обаждания

Използване на едни и същи номера за паркиране на повиквания

Домофон

Административ/Изпълнителен директор.

Можете да прегледате конфигурацията (GUI или експортиране) или да използвате инструмента Migration Insights, за да помогнете за идентифицирането на групите потребители с тези зависимости.

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

PSTN свързаност

може да има достъп до PSTN по три начина: планове за обаждания на Cisco, Cloud connect for (по-рано Cloud Connected PSTN) и локален PSTN (Локален шлюз). Въпреки това, едно местоположение, както е дефинирано в рамките на, може да бъде присвоено само на една опция PSTN.

Локалният PSTN с локален шлюз (LGW) е съществен компонент на стратегията за преход. Той осигурява свързаност между локалното внедряване и/или PSTN и платформа. поддържа както Cisco, така и сертифицирани контролери за гранични сесии на трети страни (SBC), които могат да се използват като локален шлюз. За последния списък на поддържаните SBC вижте Списък на поддържаните S BC.

поддържа до 250 едновременни обаждания от един локален шлюз, базиран на регистрация, и повече от 250 едновременни обаждания от един локален шлюз, който е базиран на сертификат. Локалните шлюзове, базирани на сертификати, могат да поддържат до 6500 едновременни обаждания, но това се основава на типа свързаност, към която трябва локалният шлюз (Over-the-Top vs Interconnect peering) и модела SBC, на който е внедрен локалният шлюз. Тези ограничения по същество са ограничението по подразбиране както за PSTN повиквания, базирани на локален шлюз, така и за повиквания между сайтове между и крайните точки. За повече информация вижте Първи стъпки с локален шлюз.

Всички обаждания, надвишаващи този лимит, се отхвърлят с 403 Забранено. Гласовата команда show call active може да се изпълни на локалния шлюз във всеки случай, за да се определи общият брой активни повиквания.

Лошите мрежови условия между локален шлюз и SBC за достъп могат да ограничат производителността на сигналната връзка, което води до още по-ниско ограничение за ед новременни повиквания. Еднопосочната латентност между локалния шлюз и центъра за данни не трябва да надвишава 100 ms и трептенето трябва да бъде по-малко от 10 ms, докато загубата на пакети е по-малка от 0,5%.

Характеристики и използване на функциите

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

За да определите кои функции са конфигурирани, анализирайте конфигурацията. Това са всички статични данни, които се задават, когато функция или настройка е конфигури рана в системата. Следните опции могат да се използват за завършване на този анализ:

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

конфигурационен експорт - насипен експорт или AXL

инструмент за информация за миграция (Препоръчва се)

Инструменти за партньори на Cisco от трети страни (Препоръчва се).

За да анализирате ефективно използването на функциите, е от съществено значение да се проучат динамичните системни данни като използване, регистрации и активност на повиквания. Различни аналитични инструменти и табла за управление предоставят информация за тези показатели, позволявайки цялостно разбиране на производ ителността и капацитета на системата, което поддържа информираното вземане на решения по време на усилията за миграция и оптимизация. Следните опции могат да се използват за завършване на този тип анализ:

Преглед на необработени CDR записи

Преглед на данните Unified CM от RTMT

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

Таблица 6. Отчети, генерирани от Unified CM .tar и CD. gzip файлове
Име на доклада
Описание на доклада
FeatureUsageBasedDeviceEligibilityReport.csv
Информация за допустимостта за мигриране на устройства въз основа на използването на функцията
FeatureUsageWithLastUsageDateReport.csv
Брой на използвания за броя пъти, в които пилотът (ите) за лов и опашката (ите) за повикване са били извикани заедно с последната дата на използване
UserWorkspaceLastUsage.csv
Последна дата на използване за потребители и работни пространства както за меки клиенти, така и за твърди телефони
DIDUsageReport.csv
Използване на DID както за присвоени, така и за незададени DID

За повече подробности относно отчетите за миграционните данни вижте Информа ция за ми грацията.

Ако имате нужда от повече информация за функциите и използването след преглед на информацията в отчетите Migration Insights, Cisco препоръчва да обмислите един от инструментите за мигриране на партньори от трети страни на Cisco и/или да прегледате конфигурациите в графичния интерфейс или в конфигурационните данни за експортиране.

Таблица 5. Отчети, генерирани от Unified CM файл.tar
Име на доклада Описание на доклада
ImportedDataBulk.csv Всички потребители и устройства от Unified CM данни
DeviceEligibility.csv Идентифицира устройства, отговарящи на Webex Calling условията за мигриране (IP телефони, устройства с операционна система Room, ATA и трети страни)
DevicePoolNumbers.txt Списък на всички номера в даден пул от устройства
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробности за устройствата и потребителите, които трябва да бъдат мигрирани заедно въз основа на споделени линии, пилот за лов, опашка за обаждания, паркиране на повиквания и конфигурация на групата за вземане на обаждания
HuntGroupMigrationInsight.csv Подробна информация за зададените ловни линии, групи линии и свързаните с тях агенти
SharedlineGroupMigrationReport.csv Преглед на това как телефонните номера (номера на директории) се споделят между потребителите

Таблица 6. Отчети, генерирани от Unified CM .tar и CD. gzip файлове
Име на доклада Описание на доклада
FeatureUsageBasedDeviceEligibilityReport.csv Информация за допустимостта за мигриране на устройства въз основа на използването на функцията
FeatureUsageWithLastUsageDateReport.csv Брой на използвания за броя пъти, в които пилотът (ите) за лов и опашката (ите) за повикване са били извикани заедно с последната дата на използване
UserWorkspaceLastUsage.csv Последна дата на използване за потребители и работни пространства както за меки клиенти, така и за твърди телефони
DIDUsageReport.csv Използване на DID както за присвоени, така и за незададени DID

Интеграции на Cisco: Unity Connection UCCX UCCE

Гласовата поща е неразделна част от офертата и естествено е вградена в решението. не може да се интегрира с решение за гласова поща, базирано на помещения, като Unity Connection или Unity Connection Express. Освен това няма естествен начин за мигриране на съществуващи съобщения за гласова поща за връзка с Unity или поздрави към родната услуга за гласова поща, налична с нея. Някои от инструментите за мигриране на партньори от трети страни на Cisco имат възможности за мигриране на някои от тези данни. За повече информация относно гласовата поща вижте Конфигуриране и управление на настройките на гласовата поща за потребител Webex Calling .

също така поддържа споделена гласова поща и факс пощенски кутии. За повече информация вижте Управление на споделена гласова поща и входящ факс кутия за. Webex Calling

има вградена функция за автоматично обслужване, която е включена като част от основната платформа. Тази функция позволява прехода на обработващите повиквания на вашата Unity Connection и функционалността за автоматично обслужване. Инструментът Control Hub, Migration Features fromUnified CM, поддържа мигри ране на конфигурациите на Unity Connection към автоматични помощници. За повече информация относно използването на този инструмент вижте Ми грация на устройства и функции от Unified CM къмWebex Calling.

Запис на обаждания

включва две опции за запис на разговори без допълнителни разходи.

Запис на обаждания на Webex

Dubber Go Recording (партньорска оферта) - интеграция между и дубър, където всички записани носители се съхраняват сигурно в облака.

Включената таблица с опции за запи с подчертава някои ключови характеристики на двете опции за запис на повиквания, които са налични без допълнителни разходи.

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

Достъпно за всички потребители Достъпно за всички потребители

Неограничени записи Неограничени записи

1 година период на задържане* 30-дневен период на съхранение

100 GB място за съхранение на организация -

Служителите по съответствие могат да имат достъп и да управляват записите на разговори -

API за управление на записи -

Админите могат да конфигурират и управляват достъпа на потребителите до техните записи на разговори
Потребителите могат да управляват собствените си записи с помощта на User Hub и/или приложението Webex.
Само потребителите могат да имат достъп и да управляват своите записи
От техния дублиращ портал.

Ако организацията ви изисква допълнителни възможности за запис, като например запис на повиквания за съответствие, по-дълги периоди на съхранение, повече съхранение, анализ на AI и/или достъп до администратора, съществуват платени оферти или добавки както от Cisco, така и от доставчици на записи от трети страни. За повече информация относно доставчиците на записи, конфигурациите и допълнителните партньорски услуги вижте Управление на записа на повиквания за Webex Calling.

Таблица 7. включени опции за запис
Webex	Дубър Го
Достъпно за всички потребители	Достъпно за всички потребители
Неограничени записи	Неограничени записи
1 година период на задържане*	30-дневен период на съхранение
100 GB място за съхранение на организация	-
Служителите по съответствие могат да имат достъп и да управляват записите на разговори	-
API за управление на записи	-
Админите могат да конфигурират и управляват достъпа на потребителите до техните записи на разговори Потребителите могат да управляват собствените си записи с помощта на User Hub и/или приложението Webex.	Само потребителите могат да имат достъп и да управляват своите записи От техния дублиращ портал.

Интеграции на трети страни

^{поддържа различни интеграции от трети страни, включително, но не само, SBC
за локални шлюзове, IP телефони, домофонни телефони, високоговорители/пейджъри, ATA и др.} В допълнение към тези устройства за ^трети страни, Webex Calling поддържа различни решения на трети ^страни за поддръжка на клиенти, анализи, запис, фактуриране и др. За повече информация относно реш енията ^на трети страни вижте Webex App Hub.

План

План на проекта на високо ниво

Миграционно пътуване - една или две стъпки?

Вариант 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. Единствената промяна е изискването за връзка към.

За повече информация относно този преход вижте Карта за преход и Ръководство за в недряване на Jabber към Webex в раздела Клиент на страницата Преход за сътрудничество.

Unified CMкъм картата на прехода на Webex Calling високо ниво фигурата е преходът на високо ниво от към. Това е стъпка 2 от препоръчаното пътуване.

Unified CMкъм карта на пре Webex Calling хода на високо равнище

Ако решите да използвате подхода с една стъпка, това също важи.

В тази стъпка потребителите се прехвърлят към групи. В този момент потребителите започват да използват за своите повиквания услуги, регистрация на обаждания и регистрация на IP телефон.

Тъй като потребителите се движат в групи, потребителите на Enterprise ще бъдат разделени между двете платформи за повикване по време на прехода. Фигурата Unified CMна картата на прехода от фаза 1 до 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 и обаждания към устройства). Необходимо е да се определи необходимата честотна лента за достъп до интернет.
Държава -
Часова зона -
Език -
Контакт (име, телефон, имейл) -
Адрес (адрес на улица, град, щат, пощенски код) -
Физическо изпращаемо местоположение на службите за спешни случаи за крайни точки Местоположението за изпращане на устройството, използвано за спешни повиквания, обикновено включва следното: адрес на сградата, адрес на сградата + номер на етажа, адрес на сградата + номер на апартамента или адрес на сградата + номер на етаж+офис/кубичен номер.
Уникално физическо местоположение на мрежата за аварийни служби за всяко устройство Местоположението на физическата мрежа за спешни повиквания обикновено включва следното: превключвател за кабелни устройства, Идентификатори за базови набор от услуги за безжична точка за достъп (AP) за безжично свързани устройства и/или локални IP подмрежи за устройства с крайни точки.

PSTN

При проектирането на внедряване клиентите имат три основни опции за свързване на PSTN: Cisco C alling Plans (PSTN услуга, предоставяна в облак, управлявана от Cisco), свързани с облак PSTN доставчици (CCPP, където доставчиците предоставят PSTN услуга през облака) и локални PSTN (където локал ните шлюзове свързват корпоративната мрежа с PSTN). С въвеждането на PSTN trunking за хибридни внедрявания (За повече информация вижте PSTN trunking за хибридни внедрявания при PSTN trunking), организациите получават допълнителна гъ 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 чрез връзката Local Gateway Webex Calling между локал ните и. По време на прехода местоположенията могат да бъдат превключени с помощта на Cloud Connected PSTN.

И в двата случая обажданията между локални и потребителски използват връзката Local Gateway. Връзката между локалните и трябва да бъде проектирана и оразмерена съответно въз основа на очаквания брой едновременни повиквания и необходимото съкращаване.

План за набиране

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

Локален план за набиране в

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

+E.164 набиране от до

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

Съкратено набиране между обектите от до

Принудително набиране в мрежата от до

Обратно обаждане от директорията за пропуснати повиквания към дестинации

PSTN извиква от към PSTN, ако по време на прехода се използва локален PSTN за

PSTN обаждания от до ако по време на прехода PSTN транкингът за хибридни внедрявания се използва за осигуряване на PSTN достъп на локални потребители чрез Cloud Connect за

Принудително включване в мрежата от до

Разширено набиране от до (междуобект).

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

Фигура Планът за на биране на най-добрите практики показва подхода на план за набиране с най-добри практики, както е описано в Пред почитана архитектура за Cisco Collaboration 12.x Enterprise On-Locals 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 дяла или от един от моделите на маршрута на PST N в USPSTNNational или SJCPSTNLocal дяла. Съкратените навици за набиране в рамките на сайта и между сайтовете се прилагат от преводите в дяла ES N и SJCTOe164. Докато ESN дял ът е глобален дял (достъпен за телефони на всички места), дялът SJCTOE164 е достъпен само за потребители в местоположението SJC. Това предполага припокриващи се диапазони на разширения.

Първата стъпка за активиране на обаждането от до е да се уверите, че дестинациите +E.164 се насочват съответно. Това може да се постигне чрез добавяне на дял към плана за набиране, добавяне на +E.164 модели на маршрут за всички дестинации към този дял и накрая добавяне на дяла към всички извикващи пространства за търсене, представляващи класове услуги, които трябва да могат да бъдат достигнати. Създаването на специален дял е необходимо, за да се даде възможност за създаване на диференциран клас услуги за обаждания, произхождащи от. За да избегнете цикли на повиквания, пространството за търсене на входящи повиквания в багажника от Local Gateway не трябва да има достъп до дяла.

+E.164 маршрутизиране към Webex Calling

Както е показано на фигура +E.164 маршрутизиране къмWebex Calling, за да се активира маршрутизиране от към за местоположение с диапазон +E.164 DID +1 221 555 2XXX и код на сайта 121, към дяла трябва да се добави спешен модел на маршрут, съответстващ на този диапазон +E.164.

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

За да активирате съкратено набиране между сайтовете към сайта, към дяла се добавя необходимия модел на маршру т 8121.2XXX. За да бъдат прехвърлени сайтовете към модел за нормализиране на набирането 8121.2XXX, който нормализира набирането на ESN до+E. 164, може вече да съществува в ESN дяла. В този случай 8121.2XXX изглежда излишен, но веднага щом всички DNS на съответното местоположение бъдат мигрирани към модела за нормализиране на набирането 8121.2XXX, моделът на превод може да бъде премахнат и след това моделът на маршрута 8121.2XXX позволява ESN набирането дори за потребители само за разширения в този диапазон.

С тези промени в плана за набиране повиквания към местоположението могат да се извършват не само чрез набиране на съкратен междуобект и +E.164. Също така, международното и националното набиране на PSTN са възможни, тъй като тези навици за набиране първо се нормализират до +E.164 чрез вече съществуващите модели на превод за нормализиране на набирането и след това се насочват чрез съответстване на модела на маршрута +E.164 в дяла.

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

план за набиране

Всеки потребител има разширение и/или телефонен номер +E.164. Дължината на разширението е фиксирана глобална настройка: всички разширения в разгръщане имат еднаква дължина. Разширеното набиране може да се използва между потребители както в рамките на местоположение, така и между местоположенията. Съкратеното набиране на разши рения между обектите (последният случай) работи само ако набраното разширение е уникално.

Ако съкратеното набиране между сайтовете между местоположенията е изискване, но има припокривания между разширенията, зададени на различни места, тогава трябва да се създаде специфичен за предприятието план за номериране чрез предварително фиксиране на разширенията с код за достъп и код на сайта. За повече информация вижте Пред почитана архитектура за сътрудничество на Cisco 15 Локални внедрявания, преглед на дизайна, наличен в предпочитаните архитектури на Cisco за сътрудни чество.

Дължината на разширението, поведението на набиране на разширения между местоположенията, дължината на префикса за набиране между местоположенията и кормилната цифра в префикса за набиране между местоположенията са конфигурирани в настройките на услугата за повикване в:

Д@@ ължина на префикса за маршрутизиране на местоположението: Дължина на префикса, включително цифрата Изиск ва се само ако план за номериране на предприятието трябва да бъде създаден като алтернативен съкратен навик за набиране между предприятията между местоположенията.

Кормилна цифра в префикса за маршрутизиране: Управ ляваща цифра за съкратен навик за набиране между предприятията между местоположенията. Трябва да се избягват припокривания с първата цифра на всяко местоположение и местоположение изходящи цифри за набиране. Изиск ва се само ако план за номериране на предприятието трябва да бъде създаден като алтернативен съкратен навик за набиране между предприятията между местоположенията.

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

Разрешаване на набиране на разширения между местоположения: Пре включете, за да активирате/деактивирате набирането на разширения между местоположенията. Тази опция трябва да бъде активирана само ако всички разширения в организацията са уникални. Ако опцията е деактивирана, тогава трябва да се набират значителни корпоративни номера (кормилен код, код на сайта, разширение) или телефонни номера между местоположенията.

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

Примерът за номериране на таблицата Enterprise показва пример за три места, където диапазоните на разширения на две места, NYC и RTP, са идентични. Създаването на схема за номериране на предприятието с кормилна цифра 8 между обектите, последвана от трицифрен код на сайта и четирицифреното разширение създава неприпокриващ се съкратен навик за набиране между обектите.

Таблица 2. Пример за номериране на предприятия
Сайт Обхват на разширяване Код на сайта Обхват на предприятието

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

За да се даде възможност за плавен преход, наборът от навици за набиране за потребителите преди и след премина ването към идеалния трябва да бъде същият. За да се подготви за прехода за всяко място, трябва да бъдат документирани DID диапазоните и обхватите на разширения (или съкратените навици за набиране в рамките на обекта). Въз основа на тази информация трябва да се избере кормилната цифра между обектите.

Таблицата Диа пазони на разширение с фиксирана дължина показва пример за три местоположения и диапазони на удължаване с фиксирана дължина. Тъй като трябва да се избягват припокриващите навици за набиране, важно е да се уверите, че за всеки разширен диапазон първата цифра от диапазона не съответства на кормилната цифра за съкратено набиране между места. Ако например 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, старият двуцифрен код на сайта и четирицифрено разширение. Потребителите не трябва да запомнят нови кодове на сайта; те трябва само да запомнят да използват 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 и Licenses API), които могат да бъдат използвани за автоматизация на възлагането на лицензи. API за лицензи позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Таблица 5. Опции за предоставяне на потребителя - резюме
Метод на възлагане Плюсове Минуси
Ръчно през Просто за малко потребители.
Позволява прецизен и подробен контрол върху възлагането на лицензи.
Не е мащабируем, отнема много време
Склонен към човешка грешка по време на ръчно въ веждане.

Автоматични шаблони за лиценз Мащабируем
Намалява ръчните грешки
Може да се прилага към нови и съществуващи потребители.
Изисква валидни телефонни номера и местоположения.
По-сложно за настройка
Също така изисква групи потребители на група потребители с еквивалентни лицензионни изисквания.

Групово качване на CSV Ефективен за големи потребителски комплекти
Позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Изисква внимателно CSV форматиране
Възможност за грешки, ако липсват телефон ни номера или разширения или са неправилни.
Назначаване, базирано на API Автоматизиран, гъвкав.
Позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Изисква разработка и API познания.

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

Когато е възможно, Cisco препоръчва да се възлагат лицензи за повикване с помощта на лицензни шаблони Това изисква за всяка група потребители, която изисква уникален набор от лицензи (Пример - Standard vs. Професионален) съществува група със съответното членство в групата. Както е обсъдено в разделите Потребителски групи, потребителските групи могат да бъдат дефинирани ръчно в или синхронизирани от корпоративна директория. Въз можна е комбинация от двата подхода.

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

За повече информация вижте Настройване на автоматично присвояване на лицензи в Control Hub и Настройване на шаблони за автоматично присвояване на лицензи за Webex Calling потребители.

Изисквания за лиценз

Този раздел обхваща само свързаните лицензи. Други видове лицензи (пример - регистрация на устройство Webex, съобщения, срещи) не са обхванати. Като част от процеса на проектиране трябва да бъдат определени изискванията за лиценз. Трябва да се изчисли броят на лицензите за следните типове лицензи:

Стандарт: брой индивидуални потребители, изискващи стандартни телефонни функции.

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

Работно пространство за обща зона: брой местоположения за споделено използване или общи зони, изискващи стандартни възможности за повикване.

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

Оба@@ ждания в списъка с маршру ти: брой необходими PSTN повиквания, свързани с облака, между локални потребители и/или локални специализирани приложения на трети страни.

Придружаваща конзола: брой потребители, които се нуждаят от достъп до клиента на обслужващата конзола.

План за разговори на Cisco (план за изходящи повиквания): брой потребители, които изискват PSTN номер и/или достъп до изходящи PSTN повиквания за услугата Cisco PSTN.

Няма специален тип лиценз за професионални работни пространства. Професионалните работни пространства консумират професионален лиценз.

Работните пространства само за Hot-desk предлагат хост услугата за горещо бюро и спешни повиквания от хоста на хот-дескинга и не изискват никакъв лиценз. За повече информация вижте Добавяне и управление на устройства само за горещи бюро.

За да определите необходимия тип лиценз за всеки потребител и работно пространство въз основа на необходимите функции, вижте Функции, налични по тип лиценз за 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синхронизиране на потреб ителя: Тази опция позволява създаване на потребителски акаунти въз основа на съществуващи крайни потребители чрез синхронизиране от до. Това изисква CCUC (CCUC), свързан с облак, да работи в локалните клъстери. Обикновено обаче се препоръчва да синхронизирате потребителите от централизирана облачна директория като Entra ID, а не директно от.

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

Потребителски групи

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

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

Опростено админи стриране: Управление на лицензи, настрой ки и правила за няколко потребители едновременно.

Съгла суваност: Прилагайте еднакви настройки и лицензи за потребители от една и съща група.

Мащабируемост: Поддържа до 250 000 членове на група.

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

Гъвкавост: Създаване на локални групи или синхронизиране на групи за защита; управ лявайте членството в групата ръчно или чрез CSV файлове.

Разпределение на ресурси: Контролирайте достъпа до вградени приложения и услуги въз основа на членството в групата.

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

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

Шаблони за настройки: Прилагайте колекции от настройки на услугите (например съобщения, среща, обаждания) към групи за постоянно потребителско изживяване.

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

Автоматизация и интеграция: Използвайте API или синхронизиране на директории за автоматизирано управление на жизнения цикъл на потребителите и групите.

Следващата таблица обобщава различните опции за управление на потребителски групи и управление на групи в.
Таблица 7. Опции за управление на групи и членства в групи
Вариант Описание Плюсове Минуси

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

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

Групи и SCIM 2.0 API (групи) Използвайте Groups или 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 Wizard или SCIM приложения. Ръчното и CSV групово предоставяне са достъпни като допълнителни методи, но са по-малко мащабируеми и по-склонни към грешки за големите организации. Гарантирането, че Entra ID е авторитетният източник и че всички потребители съществуват в Entra ID, е от решаващо значение за успешното мигриране и последователното потребителско из живяване между и средите.

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

Проектиране на потребителски групи

След преминаване на корпоративната директория от локална към облака събирайте необходимите потребителски групи, управлявани от изискванията за лицензиране и шаблон на функции. За всеки групов документ:

Име на групата: уникално име на групата.

Лицензи: лицензи, които трябва да бъдат присвоени към тази група (ако има такива) и обхват (ако лицензите се присвояват на съществуващи потребители или само на нови потребители)

Шаблони за настройки: Webex App и шаблони за обаждания на потребителя.

Синхронизиране на директории: Ще се синхронизира ли тази група от корпоративната директория или това е локална Webex група, предоставена в Control Hub или чрез API.

Описание: как ще се използва тази група и кои потребители трябва да бъдат членове на тази група

Тези подробности ще бъдат използвани по-късно по време на фазата на внедряване за създаване на локални групи или групи в корпоративната директория и управление на груповото членство на потребителите.

Еднократно влизане (SSO)

Cisco препоръчва използването на SSO за удостоверяване на потребителя. Използването на SSO има някои убедителни предимства, включително:

О@@ простено удостоверяване на потребителя: Потребителите могат да влязат веднъж, като използват корпора тивните си идентификационни данни (например от Azure ID) за достъп и други интегрирани приложения, елиминирайки необходимостта от множество пароли и намалявайки подканите за влизане. Това подобрява сигурността, като гарантира, че корпоративните пароли никога не се съхраняват или предават на тях след удостоверяване.

Опростено управление на потребителите: Автоматизира създаването, актуализациите и деактивирането на потребителски акаунти въз основа на промените в корпоративната директория, намалявайки административните разходи и гарантирайки достъп само на оторизирани потребители.

Подобрена сигурност: SSO намалява умората от паролата и риска от нарушения, свързани с паролата, чрез централизиране на удостоверяването чрез надеждни доставчици на идентичност (IDP).

Лесна интеграция на многофакторно удостоверяване (MFA): MFA може лесно да се поддържа или чрез решение за управление на достъпа до идентичността като Cisco Duo, или чрез M FA поддръжка на IDP.

Има няколко опции за внедряване на SSO за услуги:

SAML 2.0 базиран SSO: Основният протокол, поддържан за интеграция на SSO, позволяващ сигурен обмен на информация за удостоверяване между IDP и доставчика на услуги.

OpenID connect (OIDC): Поддържа се като алтернативен модерен протокол за удостоверяване за интеграция на SSO.

Иденти@@ чност на Webex: Поддържа се и като опция за доставчик на самоличност.

SSO се конфигурира и управлява централно чрез, което изисква обмен на метаданни между и избрания IDP.

След конфигурирането SSO може да бъде тестван преди активирането, за да се гарантира правилната настройка.

Cisco поддържа интеграция с множество тествани и често използвани вътрешни лица и системи за управление на самоличността (IAM), включително, но не само:

Циско Дуо

Окта

Microsoft Active DirectoryФедерационни услуги (ADFS)

Microsoft Azure

ПингФедерация

Отворена АМ

F5 BIG-IP.

Тези IDP отговарят на стандартите SAML 2.0 или OpenID Connect и са валидирани за съвместимост с решенията за сътрудничество на Cisco.

Поддръжка на множество IDP

позволява на организациите да конфигурират SSO с множество разселени лица, за да приемат сложни ИТ среди като сливания, придобивания или децентрализирани ИТ отдели, където различните групи използват различни разселени лица. Поддръжката на множество IDP може да бъде реализирана с помощта на функцията Multiple iD P в или чрез интегриране на корпоративна IAM система като Cisco Duo.

поддръжката на множество доставчици на идентичност (IDP) адресира няколко ключови случая на използване, при които организациите изискват гъвкаво и сигурно удостоверяване в различни ИТ среди:

1. Сливания и придобивания

Когато компаниите се сливат или придобиват други, те често имат отделни ИТ инфраструктури и отделни разселени лица, които не могат да се обединят. Поддръжката на множество IDP позволява на потребителите от двете организации да удостоверяват и да си сътрудничат сигурно, без да е необходимо незабавно да унифицират системите си за самоличност.

2. Множество независими ИТ отдели

Големите организации или държавни институции могат да имат множество независими ИТ отдели, всеки от които управлява собствен ИД. функцията за множество IDP позволява на тези отдели да поддържат свои собствени системи за удостоверяване, като същевременно позволява на потребителите да имат безпроблемен достъп.

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

Организации с различни потребителски групи (напр. служители срещу изпълнители) или множество имейл домейни могат да конфигурират правилата за маршрутизиране, за да насочат заявките за удостоверяване към съответния IDP въ з основа на членството в домейна или група. Това поддържа диференцирани политики за достъп и контрол на сигурността.

4. Поддръжка на различни протоколи за удостоверяване

поддържа SAML и OpenID Connect (OIDC) IDP, което позволява на организациите да интегрират различни видове доставчици на идентичност според съществуващата им инфраструктура и изисквания за сигурност.

5. Подобрена сигурност и съответствие

Чрез активиране на множество разселени лица организациите могат да внедрят по-силни механизми за удостоверяване, включително многофакторно удостоверяване (MFA) чрез интеграции като Duo, и да налагат последователни политики за сигурност в различни потребителски бази.

6. Опростено потребителско изживяване

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

Въпреки че поддръжката на множество IDP осигурява гъвкавост, тя изисква внимателна координация между екипите за сигурност и идентичност, за да се поддържат последователни политики за сигурност и да се избегнат потенциални уязвимости.

Дуо MFA с SSO за

Duo Access Gateway (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основни характеристики

Автоматичен асистент

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

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

Автоматичният служител поддържа следните основни функции:

Работни и следчасови графици

График на празниците

Опция за набиране на менюто, за да насочите клиентите си там, където трябва да отидат

Персонализирайте поздравите

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

Опции за пренасочване на оба

Анализи и отчети на контролния център.

За повече информация вижте Управление на автоматичните служители.

Обадете се в парк

Call park дава възможност на потребителите лесно да задържат повикване, за да може друг потребител лесно да го изтегли, когато са на разположение, за да го приеме. Той също така освобождава потребителя, който е отговорил на първоначалното обаждане, да осъществява или получава други обаждания, докато повикването е паркирано.

Има два вида кол паркове, налични в:

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

Група за паркиране на пови квания - позволява на определена група потребители автоматично да паркират повиквания с прямо наличните паркови дестинации, определени за групата. Тези дестинации могат да бъдат разширения на член овете на групата или разширения за парка за повиквания.

Въз основа на конфигурацията и типа паркиране потребителите могат да извличат обаждания, като набе рат *88+><extension of parked call>, натискат линейния клавиш, свързан с разширението за паркиране на повиквания, или използват софтуерен клавиш на своя IP телефон.

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

За повече информация вижте Управление на парка за повиквания в контролния център.

Вземане на обаждания

Възприемането на повикване позволява на администратора да определи група потребители (членове), които могат да отговарят на обаждане до телефона на друг член. Това дава възможност на потребителя да отговаря на обаждания, когато съотборниците им са заети и не могат да отговорят на входящо повикване.

Потребителите в дадена група трябва да са на едно и също място.

Потребителите могат да използват телефона или настолния си телефон, за да получат обаждане.

:

Поддържа визуални и аудио известия

Известие за входящо обаждане

Въз основа на лице (наберете *98) или вземане на повикване с тост за уведомяване

Известия за получаване на обаждания за многолинейни.

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

Известие за входящо обаждане

Аудио камбанки и визуално известяване чрез светодиода на слушалката. 6821 поддържа само аудио камбанки

Когато типът на уведомлението е избран в не е ника къв

Известия за получаване на обаждания само за първични линии.

За повече информация вижте Конфигу риране на групата за събиране на повиквания.

Опашка за обаждания

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

Призивът на Cisco за интеграция на Microsoft Teams позволява на агентите да имат достъп до повиквания и функции на опашката за обаждания директно от техния клиент на Microsoft Teams.

Опашките за повиквания поддържат следните основни функции:

Поздрави и съобщения (добре дошли, комфорт, шепот и т.н.)

Задръжте музика

Обратно обаждане

Политики за маршрутизиране на опашки (нощно обслужване, празници, препращане)

Влизане/излизане на опашката на агенти

Управление на състоянието на опашката на агенти

или Поддръжка на настолен телефон

Агентът на надзорния орган се обажда на монитора, треньора, шлепа или поема управлението чрез кодове за достъп до функции (FACs)

(администраторски достъп) за:

управление на опашките

Анализ и отчитане на агенти и опашки

Управление на опашка, агент и надзорник.

За повече информация вижте Конфигу риране на опашката за повиквания.

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

Хънт Груп

Hunt Groups позволяват маршрутизиране на входящи повиквания към определена група потребители чрез предварително определен модел за маршрутизиране на повиквания. Това гарантира, че обажданията се отговарят от правилната група потребители или се изпращат на гласова поща за проследяване.

Една голяма разлика между групите за лов и опашките за повиквания е, че обажданията не се поставят на опашка в групи за лов, така че ако няма потребители в групата за лов, които да отговорят на повикването, те ще бъдат прекъснати, изпратени на гласова поща или пренасочени към друг номер (потребител или услуга).

За повече информация вижте Управление на групи за лов в контролния център.

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

Функцията за режими на работа позволява на бизнеса ефективно да насочва повиквания към различни дестинации (потребители, гласова поща, услуги за обаждания като опашка за обаждания). Къде и кога се насочва повикването се основава на график от денонощието и деня от седмицата и всеки потребител може да бъде упълномощен да управлява тези режими ( графици), за да контролира промените в маршрутизирането на повиквания.

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

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

За повече информация вижте Маршрутизиране на повиквания въз основа на режими на работа в Webex Calling.

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

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

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

За повече информация вижте Конфигу риране на група за пейджинг в Контролен център.

Записи

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

Когато се използва като платформа за запис, всички записани повиквания се управляват вътре. Пълните администратори с ролята на служител по съответствието могат да играят и изтеглят записите. Без ролята на служител по съответствието администраторът може да изтрие само записите.

За повече информация относно тази функция и списък със записи на трети страни вижте Управление на запи са на пови квания за Webex Calling.

Обхват с единичен номер

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

За повече информация относно тази функция и как администраторът я конфигурира, вижте Конфигу риране на обхват с един номер (офис навсякъде).

За повече информация как потребителят може да управлява и конфигурира тази функция за себе си в Webex User Hub (портал) вижте Конфигу риране на обхват с един номер (офис навсякъде).

Група гласова поща

Групите за гласова поща позволяват споделено поле за гласова поща, което може да бъде присвоено на потребител или функция за маршрутизиране на повиквания. Някои от причините, поради които може да се изисква група гласова поща, са:

Гласова поща с общо предназначение за отдел или работна група

Добавяне на опция за гласова поща към група за автоматично обслужване или лов

Изпращане на преливащи повиквания от опашка за обаждания

Потребители, които се нуждаят само от кутия за гласова поща.

За повече информация вижте Управление на споделена гласова поща и входящ факс кутия за. Webex Calling

Attendant Console е посочена на страницата Функции за повикване в Webex, но това е добавка, която изисква закупуване на лиценза за придружаващата конзола, за да се използва.

За повече информация вижте Първи стъпки с конзолата за обслужване.

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

Таблица 1. Информация за заснемане за всяко място
Информация	Коментар
Обхват (и) на разширение	Всяко местоположение може да има разширения, започващи с различни цифри. Една цифра трябва да бъде спестена за кормил ната цифра за набиране между обектите (например 8) и една за кор милната цифра PSTN (например 9). Никой диапазон на разширения не може да започне с нито една от тези две цифри. Всички диапазони на разширения на всички места трябва да са с еднаква дължина.
Диапазон (и) на DID	-
PSTN кормилна цифра	-
Код на сайта	Всички кодове на сайтове на всички места трябва да са уникални и да имат еднаква дължина.
Основен номер	При създаването на местоположение трябва да бъдат осигурени два DID. Един като основен номер (например за присвояване на услуга за автоматично обслужване) и един за портала за глас ова поща. Предоставяне на един DID за номера на гласовата поща.
Номер на гласовата поща
Брой лицензи	Необходими лицензи по тип, включително Стандартни, Професионални, Работни пространства, Списък с маршрути, План за изходящи повиквания.
Едновременни обаждания в натоварения час	Сбор от едновременни повиквания между устройства и между устройства и локалния шлюз (PSTN и обаждания към устройства). Необходимо е да се определи необходимата честотна лента за достъп до интернет.
Държава	-
Часова зона	-
Език	-
Контакт (име, телефон, имейл)	-
Адрес (адрес на улица, град, щат, пощенски код)	-
Физическо изпращаемо местоположение на службите за спешни случаи за крайни точки	Местоположението за изпращане на устройството, използвано за спешни повиквания, обикновено включва следното: адрес на сградата, адрес на сградата + номер на етажа, адрес на сградата + номер на апартамента или адрес на сградата + номер на етаж+офис/кубичен номер.
Уникално физическо местоположение на мрежата за аварийни служби за всяко устройство	Местоположението на физическата мрежа за спешни повиквания обикновено включва следното: превключвател за кабелни устройства, Идентификатори за базови набор от услуги за безжична точка за достъп (AP) за безжично свързани устройства и/или локални 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	Програмно управление на потребителите чрез Webex API	Гъвкав; поддържа автоматизация и интеграция	Изисква развитие и инфраструктура
Синхронизация на директория	Автоматично синхронизиране от AD, Entra ID, SCIM приложения, Unified CM	Автоматизира жизнения цикъл; поддържа филтриране и картографиране	Сложност на настройката: някои от опциите имат ограничени функции или изискват инфраструктура

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

Прилагане

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

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

Проверка на домейна

Поискайте (преобразувайте) съществуващи потребители

Конфигуриране и тестване на синхронизацията

Настройване и тестване на еднократно влизане (SSO)

Набавяне, предоставяне и проверка на лицензи

Webex Callingнастройки на услугата

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

Закупуване на PSTN

Конфигурирайте местоположенията

Интеграция с локален контрол на повикванията

Мигриране на потребители на партиди

Работни пространства

Устройства за осигуряване

Конфигуриране на функции

Тестване за приемане

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

Първата стъпка в преминаването към е да се осигури надеждна и сигурна интернет връзка между локалната мрежа и облака.

Тъй като повечето организации се свързват с интернет чрез една или повече защитни стени или устройства за сигурност, от съществено значение е да се потвърди дали необходимите потоци от трафик се поддържат.

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

Посока (входяща срещу изходяща)

Протоколи (Пример - 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
Конфигу@@ риране на споразумението за синхронизиране с групово филтриране: Когато настройвате споразумението за синхронизация в предоставянето на Directory Connector или Entra ID, конфигурирайте обхвата да включва само потребители, които са членове на определената група.

За Microsoft Entra ID можете да използвате групови задачи в настройките за предоставяне

За AD можете да дефинирате LDAP филтър, който да включва само потребители, принадлежащи към зададената група .

4
Разширете групата според нуждите: Докато напредвате към по-широки фази на внедряване, просто добавете допълнителни потребители или групи към групата за синхронизация. Обхватът на синхронизи ране автоматично ще се разшири, за да включва тези потребители, което позволява контролирано и постепенно в недряване.

Примерни стъпки за изпълнение:

В активната директория:

Създайте група за защита, наречена група за синхронизиране.

Добавете желаните пилотни потребители към тази група.

Настройте конектор за директории с LDAP филтър като: (MemberOf = CN = Webex Sync Group, OU = Groups, DC = вашият домейн, DC = COM).

В Microsoft въведете идентификатор:

Създайте група, наречена група за синхронизиране

Присвояване на групата към настройките за предоставяне на идентификатора в Entra

Само потребителите в тази група ще бъдат предоставени.

Винаги тествайте груповата синхронизация в непроизводствена среда, преди да кандидатствате за цялата организация

Редовно преглеждайте членството в групата, за да сте сигурни, че само оторизираните потребители са

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

Референции:

Синхронизиране на потребителите на Entra ID в контролния център

Настройване на приложението Entra ID Wizard в контролния център

Конектор за директории

Настройване и тестване на еднократно влизане (SSO)

Еднократното влизане (SSO) подобрява сигурността и опростява достъпа на потребителите, като позволява на потребителите да се удостоверяват веднъж с корпоративните си идентификационни данни и да получат безпроблемен достъп до тях. поддържа интеграцията на SSO с SAML 2.0 съвместими с IDP, включително Microsoft Entra ID (по-рано Azure AD), Active Directory (AD) федерални решения и различни местни лица на трети страни.

В този момент проектираната настройка на SSO трябва да бъде внедрена и тествана.

Референции:

Интеграция с единично влизане в контролния център

конфигуриране на еднократно влизане за администриране на webex

Конфигуриране на еднократно влизане с Microsoft Entra ID

SSO с множество разселени лица

Управление на SSO при интеграция в Control Hub

Набавяне, предоставяне и проверка на лицензи

Като част от първоначалната настройка за, от съществено значение е да се набавят, предоставят и проверят съответните лицензи, за да се активират и управляват услугите ефективно. Процесът на възлагане на поръчки включва избор на типове лицензи въз основа на потребителски роли и работни натоварвания, като лицензи Professional, Standard и Workspace . Лицензите се генерират и предоставят чрез софтуерните платформи на Cisco или чрез партньори. След поръчка и осигуряване трябва да се провери правилният брой лицензи . Този процес гарантира, че организацията разполага с правилните лицензи, активирани и готови за използване при внедряване.

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

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

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

По-конкретно, автоматичното възлагане на лицензи изисква допълнителни подробности за предоставяне, като местоположение на потребителя и задаване на телефонен номер. Работният телефонен номер на потребителя трябва да е във формат +E.164, предварително предоставен и присвоен на валидно място, за да може лицензът да бъде активиран автоматично. Ако тези условия не са изпълнени, на потребителя няма да се предоставят услуги автоматично и може да се наложи ръчна намеса.

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

Webex Callingнастройки на услугата

От съществено значение е да се извърши цялостен преглед и конфигуриране на глобалните настройки на услугата вътре.

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

Регулирайте тези глобални настройки, за да отразяват политиките и дизайнерските решения на вашата организация.

Също така настройките за настройка и шаблони за потребители и приложения.

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

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

Пилотната миграция следва да използва същата комбинация от инструменти, предоставени от Cisco, и помощни програми за миграция на трети страни, които са планирани за по-широкото организационно внедряване, като гарантира, че процесите, работните процеси за автоматизация и точките за интеграция са задълбочено валидирани при представителни условия.

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

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

Прозренията, получени по време на тази пилотна фаза, са от решаващо значение за оптимизирането на последващите миграционни вълни и осигуряването на плавен преход, намал ен от риска за цялото предприятие.

Закупуване на PSTN

За да набавите PSTN услуги за, първо изберете опция за PSTN свързаност в.

Ако дадена организация планира да поддържа хибриден контрол на двойните повиквания (фаза 1 на фигура Phased Calling Transition: Hybrid and Cloud) временно или за неопределено време, тя ще трябва да внедри един или повече локални шлюзове за локални PSTN, за да позволят обаждания между и крайните точки.

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

Работете с избрания от вас доставчик, за да поръчате и портирате телефонни номера, преди да ги конфигурирате. Поръчването на телефонни номера или инициирането на поръчки за портове е изискване/възможно само за локални PSTN и Cloud Connect. За плановете за обаждания на Cisco поръчването и портирането се инициират от контролния център веднага след създаването на местоположението и в страни, където е наличен план за обаждания на Cisco. За повече информация относно плановете за обаждания на Cisco виж те Първи стъпки с план овете на Cisco.

Като част от внедряването на PSTN, уверете се, че вашият доставчик е активирал както входящи, така и изходящи PSTN услуги за вашето местоположение. Освен това изпълнявайте тестови повиквания, за да проверите дали повикванията се насочват правилно през избраната от вас PSTN връзка.

Конфигурирайте местоположенията

Преди да добавите потребители и устройства към тях, трябва да предоставите местоположения за повикване. За всяко място трябва да се въведе валиден адрес на улица. В САЩ и Канада този адрес е валидиран и използван от платформата за изпращане на информация за местоположението на PIDF-LO за спешни повиквания.

Когато конфигурирате местоположения, които използват локален PSTN, трябва да настроите съответно локалните шлюзове. В програмата трябва да се създадат багажник и група маршрути за всеки локален шлюз и след това групата маршрути се присвоява като избор на PSTN за местоположението. Cisco силно препоръчва винаги да избирате група маршрути като избор на PSTN, тъй като този подход ви позволява лесно да добавяте допълнителни стволове в бъдеще, като поддържате както мащабируемост, така и излишък. Cisco препоръчва също така да се активира поддръжка с двойна идентичност и P-Charge-Info на всеки PSTN багажник, тъй като това опростява идентифицирането на платежната страна за изходящи директни или пренасочени повиквания. Ако вашият доставчик на PSTN използва различно заглавие за фактуриране, можете да копирате информацията от заглав ката P-Charge-Info на локалния шлюз в необходимия заглавък за фактуриране.

За местоположения, които използват Cloud Connect for или Cisco Calling Plan като опция за PSTN, просто изберете съответния избор на PSTN за местоположението по време на настройката. Ако местоположението използва или Cloud Connect for или локален PSTN, ще трябва да добавите телефонните номера, които са били поръчани в предишната стъпка. Номерата могат да бъдат добавени като неактивни, ако не искате да бъдат включени веднага в маршрутизирането на повиквания; можете да активирате тези номера по-късно, когато бъдат присвоени на потребители или функции.

Важно е винаги да задавате основния номер за всяко място. Основният номер може да бъде присвоен или на потребител, или на функция, като например автоматично обслужване. За да активирате гласовата поща на местоположението, не забравяйте да зададете пилотния номер на гласовата поща, известен още като номер на гласовия портал.

Допълнителните настройки за местоположенията за обаждания включват конфигуриране на подробности за спешни повиквания, като номера за аварийно обаждане, опции за уведомяване и подобрени функции за спешни повиквания. Също така трябва да прегледате и коригирате настройките за запис, езиковите предпочитания и конфигурациите на устройството според изискванията за всяко местоположение. Ако организацията ви използва съкратено набиране в мрежата между сайтове със значителни корпоративни числа, не забравяйте да конфигурирате уникален код на сайта за местоположението в настройките за вътрешно набиране. И накрая, ако външното набиране изисква из ходяща цифра за набиране, не забравяйте да го зададете в настройките за външно набиране. Когато е конфигурирана изходяща цифра за набиране, Cisco препоръчва да се активира прилагането на изходящата цифра за набиране, за да се гарантира последователност.

Интеграция с локален контрол на повикванията

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

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

Ако разгръщането ви изисква поддръжка за неизвестно маршрутизиране на разширения, тази функция трябва да бъде активирана на ниво местоположение. Освен това, когато е активирано маршрутизиране на неизвестно разширение, трябва да посочите максималната неизвестна дължина на разширението в секцията Маршру тизиране на повиквания между и помещ ения в настройките на услугите за повикване в. Това осигурява безпроблемно маршрутизиране на повиквания и правилно управление на сценарии за набиране, базирани на разширения, във вашата интегрирана среда.

Мигриране на потребители на партиди

Когато мигрирате потребители от към, може да не успеете да преместите всички потребители едновременно. Това може да се дължи на множество причини, включително, но не само, броя на сайтовете или потребителите, колко време отнема преходът на даден сайт и/или група потребители едновременно, ограничен ИТ или ресурс на сайта за поддръжка на прозореца за промяна, продължителност на прозореца за промяна, сложност на промяната и т.н.

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

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

Наблюдение на други потребители, използващи BLF

В същия лов пилот, опашка за обаждания и т.н.

Споделени линии

Използване на вземане на обаждания

Използване на едни и същи номера за паркиране на повиквания

Домофон

Изпълнител/администратор.

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

Това става по-предизвикателно, когато потребителите са свързани с различни групи потребители за различни услуги и функции за обаждания. Това ще изисква преминаване на повече от една група потребители и една услуга за обаждане едновременно.

Използвайте изхода от инструмента Migration Insights или инструмента на трета страна, който сте използвали във фазата на подготовка, за да определите кои потребители и функции трябва да бъдат групирани заедно. Този изход трябваше да бъде използван за разработването на вашия план за миграция и ще ви даде представа за това как ще групирате потребители и функции, които трябва да се прехвърлят заедно.

Ключовите стъпки при прехвърляне на партида потребители са:

Идентифициране на потребители за мигриране заедно

Проверете дали всички потребители са в

Проверете всички TN за съществуващите потребители

Проверете правилния формат на телефонния номер в директорията

Уверете се, че шаблонът за лицензиране и настройки за потребител ските групи са настроени правилно

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

В корпоративната директория добавете потребители към група потребители с активирани повик вания

Leverage Tools - инструменти за мигриране на потребители и функции и/или инструменти на трети страни

Деактивиране/изтриване на номера на директория на потребителя/устройството и функции/услуги за повикване след прехода.

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

Работни пространства

В работното пространство се отнася до споделено местоположение (като конферентна зала, място за сгъване или горещо бюро), на което могат да бъдат зададени устройства, разширения и потребители. За разлика от традиционните телефони Unifed CM, работните пространства са:

Ориентиран към местоположението: обвързан с физически пространства.

Гъвкаво устройство: може да има едно или повече устройства (настолни телефони, табла и др.).

След като работните пространства бъдат идентифицирани като част от прехода към, те могат да бъдат добавени в раздела Устройства. Всяко работно пространство се нуждае от задаване на устройство и ако вече е включеноUnified CM, то трябва да бъде нулирано или преосигурено. функции като гласова поща, пренасочване на повиквания и получаване на повиквания могат да бъдат активирани или деактивирани, а политиките могат да се прилагат за видео разговори, паркиране на повиквания и мобилност, ако е необходимо. Тествайте всяко работно пространство, като извършвате вътрешни и външни повиквания, тествайте видео, конферентни връзки и функции за мобилност . И накрая, уведомете потребителите за всички приложими процеси за устройства и резервации на работното пространство.

За повече информация относно работните пространства вижте Работни пространства.

Устройства за осигуряване

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

Всички поддържани телефони, от които трябва да преминете, ще трябва да бъдат конфигурирани като потребител или работно пространство и физическият телефон ще трябва да бъде преконфигуриран, за да се регистрира. В допълнение, телефоните от серията 7800 и 8800 се нуждаят от надстроен фърмуер от корпоративен фърмуер до фърмуер за мултиплатформен телефон (MPP). Този процес включва зареждане на преходен фърмуер преди зареждане на MPP фърмуера, необходим за регистрация. Той също така изисква подходящ лиценз за миграция. Cisco подобри този процес през последните няколко години, за да ви улесни да надстроите вашите телефони с фърмуер на Enterprise до MPP фърмуер. За повече информация относно стъпките за завършване на надстройката на фърмуера вижте Конвер тиране на IP телефони от серията Cisco 7800 и 8800 между Enterprise и MP P фърмуера.

В допълнение към стъпките, описани в тази статия, има вграден инструмент, Мигрирайте телефона си къмWebex Calling, който можете да използвате, за да помогнете за мигрирането на вашите 7800 и 8800 телефони от Enterprise към MPP фърмуера. Този инструмент също ви позволява да добавяте телефоните към и да ги присвоявате на подходящите потребители или работни пространства. За повече информация относно използването на инструмента вижте Миг риране на телефона.

За всички телефони от серия 9800, регистрирани с горното изискване за миграция на фърмуера, не се прилага. Тези телефони работят с PhoneOS, който се поддържа от двете и. За да прехвърлите тези телефони към вас, ще трябва да ги добавите къмWebex Calling, да ги присвоите на потребител или работно пространство и след това да нулирате фабричните настройки на телефоните. Последователността за зареждане на PhoneOS за регистрация по-долу показва последователността на зареждане на 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 телефоните, за да ги прехвърлят от корпоративен фърмуер към облачен фърмуер. Следователно ще предоставите всяко от тези устройства в Control Hub. Някои от тях не могат да бъдат прехвърлени и еквивалентният модел ще трябва да го замени (напр. ATA 191/192) и други ще изискват ръчно пре конфигуриране и/или промени в софтуера.

Гласови шлюзове - За да мигрирате локалния шлюз, вижте Мигриране на локален шлюз.
За повече информация за конфигуриране на гласовия шлюз VG400, VG410 или VG420 в контролния център вижте Локален шлюз

Аналогов телефонен адаптер (ATA) - За да започнете с вашите Cisco ATA 191 и 192, вижте Cisco ATA.

Wifi безжичен телефон - За да интегрирате безжичен телефон 840 и 860, вижте Интегриране на безжичен телефон Webex.

Без@@ жични телефони DECT - За да започнете с новата си серия Cisco IP DECT 6800, вижте Cisco IP DECT.

За да изградите и управлявате цифрова DECT мрежа в Control Hub вижте Управление на DE CT мрежа

За повече информация относно Cisco IP DECT 6800 вижте Ръководство за внедряване

Устрой ^ства и телефони на трети страни - Работете с доставчици на ^трети страни по изискванията за устройство/телефон и процеса на мигрирането или замяната им за поддръжка.

Конфигуриране на функции

Всички функции за извикване, които са необходими, трябва да бъдат предоставени преди или по време на прехода. Както беше обсъдено по време на секцията „Мигриране на потребители в партиди“, функциите за повикване трябва да бъдат конфигурирани и прехвърлени, когато потребителите, които ги използват, бъдат прехвърлени.

За подробности как да конфигурирате всяка от функциите вижте съответните помощни статии за конфигуриране.

Автоматични служители - За да управлявате автостюардесите, вижте Автоматични служители

Парк за обаждания - За да управлявате парка за обаждания, виж те Call park

Вземане на повикване - За да конфигурирате групата за получаване на повикване, виж те Пол учаване

Опашки за повиквания - За да конфигурирате опашката за повиквания, виж те О пашка

Групи за лов - За да управлявате ловни групи, вижте Управление на група за лов

Режими на работа - За маршрутизиране на повиквания въз основа на режими на работа вижте Маршрутизиране на повиквания въз основа на оперативни режими

Групи за пейджинг - За да конфигурирате група за пейджинг, вижте Конфигу риране на пейджинг група

Записи - За да управлявате записа на повиквания, вижте Управление на записи

Достъп до единичен номер - За да конфигурирате обхват на единичен номер (офис навсякъде), вижте Кон фигуриране на единичен

Група гласова поща - За да управлявате споделена гласова поща и входяща факсова кутия вижте Управление на гласовата поща.

Тестване за приемане

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

Този раздел предоставя примери и подчертава ключови аспекти, които трябва да се вземат предвид по време на тестването за приемане; той обаче не е предназначен да служи като изчерпателен или изчерпателен контролен списък.

Предоставяне на потребителя и присвояване на номера

Основен аспект на тестването за приемане включва проверка дали всички потребители са предоставени точно и изцяло вътре. Това изисква задълбочено сравнение между директорията source () и новосъздадената потребителска база, за да се гарантира, че всеки потребителски акаунт, заедно със свързаните атрибути като номера на разширения и задачите за директно набиране (DID) е мигриран правилно. Пълнотата на осигуряването е от решаващо значение не само за оперативността на първия ден, но и за текущата администрация и поддръжка.

Валидирането на присвояване на номера включва потвърждаване, че на всеки потребител е присвоено правилното разширение и външен номер и че тези номера се насочват правилно както във вътрешните (вътрешни), така и във външни (PSTN) потоци от повиквания. От съществено значение е да проверите за припокривания, липсващи задачи или неправилни конфигурации, които биха могли да доведат до грешки при маршрутизиране на повиквания или прекъсвания на услугата.

PSTN Потоци от повиквания и представяне на идентификатора на обаждащия се

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

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

Потоци от повиквания в мрежата

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

Управление на потребителски повиквания и проверка на функциите

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

Опитът трябва да бъде оценен за яснота и отзивчивост, като се има предвид как потребителите взаимодействат с историята на обажданията, гласовата поща и интегрираните директории. Трябва да се обърне допълнително внимание на възможността за преместване на активни повиквания между устройства и ефективно използване на контролите по време на повикване в рамките на приложението или на физически телефони. Крайната цел е да се гарантира, че изживяването на крайния потребител е последователно, ефективно и напълно подкрепя комуникационните нужди на организацията след миграцията.

Опашки за обаждания: Опит на агент и ръководител

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

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

Групи за лов: Разпространение на обаждания

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

Автоматични служители: Съобщения и операции в менюто

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

Операция с гласова поща

И накрая, функционалността на гласовата поща е от решаващо значение за потребителското изживяване. Тестовете за приемане трябва да проверят дали кутиите за гласова поща са правилно зададени и достъпни, както от организацията, така и от разстояние. Възможността за записване, извличане и управление на съобщения трябва да бъде потвърдена, заедно с доставката на уведомления.

Оптимизиране

Миграция на PSTN към Cloud Connect за

Оптимизиране на локалната инфраструктура

Използвайте анализ и отстраняване на неизправности

Миграция на PSTN към Cloud Connect за

След като всички крайни точки и потребители бъдат мигрирани към облачно извикване, единствената цел Unified CM е да действа като транзит между PSTN шлюзовете и чрез Local Gateway. Премахването на 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 trunking за хибридни внедрявания. За повече информация вижте PSTN транкинг за хибридни внедрявания. Webex Calling В този случай по време на прехода достъпът до PSTN е чрез Local Gateway и след преместване на всички потребители към него няма допълнителна миграционна стъпка, свързана с PSTN, освен извеждането от експлоатация и Локалните шлюзове.

Оптимизиране на локалната инфраструктура

След като всички потребители са преминали към и всички крайни точки са преминали към регистрация в облак (или са били извед ени от експлоатация), актуализирайте подходящата локална инфраструктура сега, когато се използва обаждането в облак. Актуализациите на инфраструктурата включват:

Премахнете локалните DNS SRV записи за контрол на повиквания и съобщения от локалния DNS сървър (и), включително cisco_uds. _ткп. <domain>, чаш ка_вход. _ткп. <domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги.

Премахнете DNS SRV записи, свързани с ръба, от публичната DNS система, включително collab_edge. _тл. <domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги на крайни услуги за сътрудничество.

Актуализирайте всички съответни DHCP обхвати, за да премахнете опция 66 и опция 150 TFTP/адреси на сървъра за зареждане. Тези обхвати вече не са необходими за откриване и изтегляне на конфигурация за контрол на повикването в крайна точка.

Актуализиране/премахване на съответните набиращи партньори в Local Gateway/Cube, които насочват повиквания към и от. Unified CM Тези колеги за набиране вече не са необходими за локално маршру тизиране на повиквания.

Изтриване или премахване на всички виртуални машини и/или сървъри и клъстерни възли. Пренасочете изчислителните ресурси и хардуера според нуждите . Тези ресурси вече не са необходими за контрол на разговорите и крайните услуги.

Изтриване или премахване на всички виртуални машини и/или сървъри на клъстерни възли. Пренасочете изчислителните ресурси и хардуера според нуждите . Тези ресурси вече не са необходими за гласова поща и унифицирани услуги за съобщения.

Почистване: След мигриране на PSTN достъп до PSTN свързан с облак PSTN, PSTN стволовете, PSTN шлюзовете и локалния шлюз могат да бъдат изведени от експлоатация.

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

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

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

Подмяна на мрежовия превключвател

Подмяна на безжична точка за достъп

Промени в обхвата на DHCP

Физически промени в сградата (ако решите за кабина/офис)

Физическо разширяване или свиване на офис пространството вътре в сграда.

Използвайте анализ и отстраняване на неизправности

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

анализ на качеството на медиите

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

отстраняване на проблеми с качеството на медиите

Отстраняването на неизправности може да се интегрира и с други продукти на Cisco като превключватели ThousandEyes и Meraki, за да осигури още по-богато интегрирано изживяване в Control Hub. За повече информация относно използването на Webex Callingанализи и отстраняване на неиз правности вижте Отстраняване на неизправности Webex Calling при повиквания в Control Hub.

Въведение

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

Общ преглед

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

Преглед на процеса на PPDIO

Общо описание на PPDIO

Използване на PPDIO за Webex Calling мигра Unified CM ционни проекти

Подгответе

План

Дизайн

Прилагане

Оптимизиране

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 компоненти е от съществено значение, за да се осигури ефективна стратегия за преход и оперативна готовност.

Контролен център

Осигуряване на директории и потребители

Webex Callingплатформа

Поддържани крайни точки за извикване

Опции за свързване на PSTN

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

Характеристики за сигурност и съответствие.

За повече информация вижте Пред почитаната архитектура на Cisco заWebex Calling.

Това ръководство ще подчертае инструментите и процесите, които да се използват през целия жизнен цикъл на прехода. Преходът от локални обаждания към нова платформа за обаждания в облак Webex Calling обаче може да бъде значително усилие при потенциални бизнес, технически и сложни предизвикателства. Unified CM За да помогне за преодоляването на тези предизвикателства Cisco разполага с няколко различни опции, които да ви помогнат в пътуването ви. Важно е да прегледате информацията в Enterprise cloud call - Calling migration и да разберете всяка опция и как всяка от тях може евентуално да ви помогне със собствената си миграция.

Инструменти за миграция на Webex: самообслужване, безплатни инструменти, вградени в Control Hub за рационализиране на прехода към 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 за пътека за отдалечен достъп и крайни услуги от бизнеса към бизнеса (B2B), Cisco Meeting Server/ Cisco Meeting Management за локални конферентни връзки, Unity Connection за гласови съобщения и хардуер, насочен към потребителя (Cisco IP телефони, Cisco Desk и Room видео системи) и софтуер (IP базирани крайни точки). Cisco Jabber Тези компоненти могат да варират леко в някои среди, но това е отправната точка за прехода, описан в останалата част от този документ.

Локална архитектура за сътрудничество: управление на повиквания и отдалечен достъп

Архитектурата, показана на фигура Архитектура за локално сътрудничество: управление на повиквания и отдалечен достъп се основава на предпочитаната архитектура (PA) за локални внедрявания на Cisco Collaboration Enterprise. За повече информация относно Enterprise On-premisses вижте предпочитаните архитектури на Cisco за сътрудни чество.

Преди: Таблицата за локални компоненти на инфраструктурата за извикване изброява ключ овите елементи на локалната архитектура преди преминаването към обла Webex Calling ка.

Таблица 1. Преди: Локално извикване на компоненти на инфраструктурата
Продукт Описание

Unified CM Локален контрол на повикванията, предоставящ услуги за регистрация на устройства и маршрутизиране на повиквания

Cisco Expressway-С/Е Edge инфраструктура, предоставяща мобилна и Remote Access (MRA) и функционалност от бизнеса към бизнеса (B2B), позволяваща на отдалечените крайни точки да се свързват сигурно извън организацията. Експресната пътека се разгръща по двойки, за да осигури преминаване на защитната ст ена за външни крайни точки.

Сървър за срещи на Cisco (CMS), Cisco за управление на срещи (CMM) и Cisco TelePresence Management Suite (TMS) Локална инфраструктура за гласови, видео и уеб конференции, осигуряваща многоточкови срещи, управление на срещи и възможности за планиране. [По желание]

Cisco Unity Connection Локална платформа за гласови съобщения, предоставяща възможности за гласова поща и унифицирани съобщения . [По желание]

Бюро на Cisco, стая на Cisco, борд на Cisco, IP телефони на Cisco и Cisco Jabber IP базирани устройства, регистрирани Unified CM и предоставящи възможности за гласови и видео разговори

Както е илюстрирано на фигура Решение за преход: локално обаждане към Webex Calling, клиентите, които имат локален контрол на разговорите Unified CM и настолни и видео IP крайни точки, имат избор да прехвърлят архитектурата към облачна архитектура. Webex Calling

Решението трябва да бъде взето въз основа на изискванията за функционалност на клиента. Клиентите, които имат следните изисквания, трябва внимателно да обмислят, преди да вземат това решение и в крайна сметка могат да решат да запазят контрола на повикванията на място:

Модели на телефони, които не се поддържат от Webex Calling

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

Сложен план за набиране, много подробни класове услуги или и двете

Ограничителен, ограничен или ненадежден достъп до интернет

Строги политики за поверителност и собственост на данните

Изискване за съответствие за запис и съхранение на носители на локални или вътрешни

Интеграции на трети страни без жизнеспособна алтернатив Webex Calling на интеграция

Интеграции на контактни центрове, при които контактният център inter все още не се премества в облака.

Решение за преход: локално обаждане до Webex Calling
Клиентите, които искат да започнат да използват услугите за обаждания в облак, трябва да помислятWebex Calling. Тази услуга за обаждания в облак позволява на клиента да използва глобалната архитектура на Webex за мащаб и свързаност. Участниците в корпоративната мрежа и отдал ечените участници извън корпоративната мрежа могат да комуникират чрез IP базирани хардуерни крайни точки и/или настолни или мобилни меки клиентски приложения.

Този документ се фокусира върху клиенти с внедряване за контрол на Unified CM повикванията, които искат да разберат общите стъпки, съображения и изисквания за разрешаване на в Webex Calling недряването, както е изобразено в следващия раздел.

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

Целевата архитектура за тази миграция включва няколко нови компонента. Това включва Webex Calling услугата за обаждания, базирани на облак, Webex App, Cisco Directory Connector за интеграция на самоличност и Local Gateway (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 Wizard.

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

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

План за обаждания на Cisco, Cloud Connect за Webex Calling Cisco Calling Plan и Cloud Connect for Webex Calling са базирани на облак опции за достъп до PSTN за крайни точки. Webex Calling Достъпът до PSTN се улеснява от доставчик на PSTN в облак и не изисква локално оборудване.

Приложение Webex Клиентско приложение, работещо на настолна операционна система (Windows, Mac) или мобилна операционна система (Android, iOS) и регистрирано директно в Webex Calling платформата за функционалност за повикване.

Преглед на процеса на PPDIO

Процесът PPDIO означава Под готовка, планиране, проектиране, изпълнение и оптимизиране. Това е структурирана методология на Cisco, която ръководи проектите от първоначалната оценка през непрекъснато усъвършенстване, осигурявайки ефективно и успешно внедряване или миграция.

PPDIO процес

Общо описание на PPDIO

Подгответе се: Оценете текущата среда, съберете изисквания и съгласувате заинтересованите страни, за да създадете солидна основа.

План: Раз работване на подробни планове за проекти, включително срокове, ресурси и стратегии за намаляване на риска.

Дизайн: Ар хитектирайте целевото решение, съобразено с бизнес и техническите нужди.

Внедряване: Изпълнете внедряването или мигрирането според дизайна, потвърждавайки функционалността и производителността.

Оптимизиране: Непрекъснато подобрявайте решението след внедр яването чрез наблюдение на производителността, усъвършенстване на конфигурациите и използване на инструменти за автоматизация и интеграция.

Използване на PPDIO за Webex Calling мигра Unified CM ционни проекти

При преминаване от Unified CM към Webex Calling процесът PPDIO предоставя ясна пътна карта за осигуряване на плавен и ефектив ен преход:

Подгответе

Оценка на съществуващата Unified CM среда и готовност за миграция

Събирайте подробни данни за потребители, устройства, мрежа и зависимости

Събирайте подробности за местоположението, включително адрес за аварийна реакция, брой потребители, достъп до интернет, достъп до PSTN

Идентифициране на рисковете и определяне на обхвата на проекта, за да се съобразят всички

План

Създайте изчерпателен план за мигриране с пакетни графици, присвояване на ресурси и сро кове

Определяне на задачи като надстройки на фърмуера на устройството, предоставяне на лицензи и включване на потребителите

Координирайте прозорците за миграция с Cisco и партньорите, за да свед ете до миниму

Дизайн

Начертавайте тек Unified CM ущите конфигурации, плановете за набиране и потребителските профили с Webex Calling еквиваленти

Проектирайте Webex Calling средата, включително PSTN стратегия (междинна и окончателна), местоположения, потребителски роли и точки за интеграция като Local Gateway (CUBE) и синхронизация на директории

Планирайте сценарии за съвместно съществуване, където Unified CM и Webex Calling работят едновременно по време на миграцията.

Прилагане

Използвайте инструментите за мигриране на Control Hub заедно с инструменти на трети страни, за да извършвате промени в режима на фърмуера на устройството, конфигу рация на функции и миграции на потребители

Използвайте групови операции и осигуряване с помощта на Webex API, за да рационализирате мащабните миграции и конфигурации

Изпълнете предоставяне на лицензи, регистрация на устройства и актуализации на конфигурацията

Потвърдете успеха на миграцията чрез тестване и оперативна проверка.

Оптимизиране

Постоянно следете Webex Calling производителността и потребителското изживяване

Прецизирайте конфигурациите и работните потоци въз основа на оперативни данни и обратна връзка

Използвайте възможностите за автоматизация и интеграция, за да подобрите ефективността и ма щабируемостта

Наследени Unified CM компоненти от извеждане от експлоатация, ако е целесъобразно, и осигуряват текуща подкрепа за операциите втори

Този подобрен PPDIO подход осигурява контролирана, прозрачна и ефективна миграция от Unified CM към, като използва инструментите на CiscoWebex Calling, API и партньорската екосистема за поддържане на непрекъснатостта на бизнеса и подобряване на възможностите за сътрудничество.

PPDIO контури за обратна връзка

Прегледът на високо ниво, изобразен в Итера циите на фигурите при изпълнение на PPDIO, илю стрира единичен цикъл за обратна връзка от фазата на оптимизи ране обратно до фазата на подготовка . Това означава, че след първоначалното изпълнение съществува постоянна възможност за непрекъснато усъвършенстване. Всеки цикъл на оптимизация може да идентифицира нови изисквания или области за подобряване, които могат да бъдат адресирани чрез последващи проекти или инициативи. Тези индивидуални проекти от своя страна следват установения PPDIO (Подготовка, планиране, проектиране, изпълнение, оптимизиране) жизнен цикъл. Този итеративен подход гарантира, че системата остава в съответствие с развиващите се бизнес цели и технологичния напредък, насърчавайки културата на непрекъснато усъвършенстване и адаптивност.

Итерации при изпълнение на PPDIO

По време на изпълнението на процеса на PPDIO е обичайно констатациите в по-късните фази да изискват преразглеждане и потенциално преразгле ждане на решенията, взети на по-ранни етапи. Например проблеми, възникнали по време на етапа на изпълнение, като например идентифицирането на неяснотите в проекта или липсващите детайли, могат да разкрият, че някои аспекти не са били напълно разгледани по време на етапа на проектиране. В такива случаи става необходимо да се върнете обратно към съответната по-ранна фаза, за да разрешите тези проблеми, преди да продължите. Този итеративен механизъм за обратна връзка, както е илюстрирано на PPDIO процес, Unified CM подпома ган от фигура, гарантира, че решението е задълбочено валидирано и усъвършенствано, като в крайна сметка допринася за по-стабилно и ефективно внедряване.

Unified CMасистиран PPDIO процес

Когато се предприема преход от Unified CM къмWebex Calling, всяка фаза от процеса на PPDIO може да се възползва значително от информацията, събрана от съществува щата Unified CM среда. Например, изчерпателни описи на потребители, телефонни номера, функции за повикване и компоненти на план за набиране могат да бъдат извлечени от текущата Unified CM конфигурация. Тези данни допълват информацията, предоставена директно от заинтересованите страни, и спомагат за рационализиране на дейностите по планиране и проектиране. Използването на подходящи инструменти за автоматизиране на извличането и анализа на данни не само повишава точността, но и ускорява цялостния процес. Чрез използване на прозрения от съществуващото внедряване, преходът към Webex Calling може да бъде извършен по-ефективно от традиционното изпълнение на зелено поле, като същевременно се придържа към структурираната PPDIO методология. Този процес е илюстриран в PPDIO процес, Unified CM асистиран от фигура.

Миграционен подход

Докато планирате прехода си от локално Unified CM къмWebex Calling, трябва да определите как ще подходите към това пътуване. Първо ще трябва да решите дали мигра цията ще бъде флаш -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 фази.

Препоръчителен трифазен преход

Предмиграция: Тази фаза се фокусира върху подготовката както на Webex, така и на околната Unified CM среда за миграцията. Тук не става въпрос за извикване на конкретно планиране или конфигурации и се фокусира върху завършване на дейности, които могат да бъдат извършени сега и преди да започне Webex Calling всеки проект за миграция. Целта е да се изгради основата на двете среди, за да се подготви за миграцията.

Подгот@@ овка за миграция: Тази фаза е мястото, където започват усилията за подготовка за миграцията към Webex Calling. Тук бизнес и техническите изисквания трябва да бъдат прегледани и актуализирани. Не правете просто повдигане и измест ване на това, с което се използва понастоящем, Unified CM а вместо това предефинирайте бизнес и техническите изисквания, от които се нуждае вашата компания днес и в бъдеще, като се възползвате от силата на това. Webex Calling В допълнение, това е фазата, в която ще завършите вашия дизайн, планиране на конфигурация и планиране/график за миграция.

Миграция (внедряване и извеждане от експлоатация): Тази фаза е мястото, където се случва действителната миграция на потребители, устройства, телефонни номера и меки клиенти. Както бе обсъдено по-горе, тази фаза може да бъде завър шена за всички наведнъж (ф лаш -изряз ване) или през множество прозорци за промяна (поетапно изрязване). Плановете за приемане на крайни потребители, обучението и комуникациите са от решаващо значение, така че вашите потребители са наясно с промените, как да използват новата платформа за обаждания и да знаят кога ще се случи про мяната. Последната стъпка е да се изключи цялата локална UC инфраструктура , която вече не се използва.

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

Фигурата Дейности преди миграцията по-долу подчертава пет специфични категории дейности, които са свързани с Webex Calling миграция.

Дейности преди миграцията

Подгответе

Бизнес и технически изисквания

Защо изискванията за събиране са важни:

Изисквания за бизнеса

Технически изисквания

Мрежова готовност и изисквания

Настройване на UC, свързан с облака

Оценка на текущата среда

Лицензиране

Местоположения/сайтове

Инвентаризация на съществуващи устройства/клиенти

Проверете допустимостта на устройството

Потребители

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/интернет, защитна стена/NAT

Интеграция със съществуващи системи Директория, CRM, централа, имейл/календар

Съвместимост и осигуряване на крайни точки Поддръжка на устройства, осигуряване, актуализации на фърмуера

Конфигурации за сигурност и криптиране Криптиране, удостоверяване, съответствие, мониторинг на сигурността

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

Преносимост на номера и план за набиране Миграция/портиране на числа, превод на план за набиране

Интеграции на трети страни Пейджинг, контакт център, факс, аналогови устройства

Мрежова готовност и изисквания

Готовността на мрежата е от решаващо значение за успешното мигриране към всяко решение за обаждания, базирано на облак, като например. Лошото планиране на мрежата може да доведе до влошено качество на разговорите, откачени обаждания и недоволни потребители. Клиентите трябва да извършат оценка на мрежата, преди да мигрират към. Препоръчва се да потвърдите наличността на мрежовата честотна лента за очаквания обем на повиквания, да се гарантира, че изискванията за качество на услугата (QoS) са изпълнени и разбиране на различните портове, които трябва да бъдат отворени в крайната защитна стена (ите).

Надеждната мрежова свързаност с достатъчно качество на услугата (честотна лента, загуба на пакети, RTT) е основно изискване за осигуряване на възможно най-доброто потребителско изживяване от край до край за всички гласови и видео крайни точки, клиенти и приложения, които използват.

Клиентите и партньорите имат опции за достъп до свързаност извън Over-the-Top (OTT) интернет, които могат да оптимизират връзката за включ Webex Edge ване на Connect. За повече информация относно подробностите за дизайна на Webex Edge Connect вижте Пред почитана архитектура на Cisco за Webex Edge свързванеWebex Meetings, извикване на множество наематели и специален екземпляр .

Клиентите могат да използват cScan за оценка на мрежата, която дава информация за качеството на мрежата на клиента, колко разговори могат да бъдат установени, латентността и т.н. За повече информация относно инструмента cScan вижте Използване на cS can за тестване на качеството на Webex Calling мрежата.

За да сте сигурни, че мрежата е готова за миграция, помислете за следния контролен списък:

планиране на честотната лента

Изчислете едновременните повиквания на сайт, за да сте сигурни, че имате достатъчно честотна лента на горе и надолу по веригата и да включите пространство за друг критичен за бизнеса трафи к и бъдещ растеж.

Таблицата Webex Calling за изчисления на честотната лента на ти па повикване показва типовете повиквания, налични с внедряване, заедно с кодека и максималната честотна лента, необходима за всеки тип повикване. Както е показано в таблицата Webex Calling за изчисления на честотната лента на ти па повикване, необходимата честотна лента за аудио повикване за всеки тип повикване може да бъде изчислена по следната обща формула:

Брой очаквани едновременни повиквания * Честотна лента на повикване въ з основа на кодек = Необходима мрежова пропускателна способност.
Таблица 2. Webex Calling изчисления на честотната лента тип повикване
Видове обаждания Кодек - честотна лента Изчисления на честотната
/Телефон за бюро -> ОПУС - 70 kbps Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> Телефон за бюро ОПУС — 70 кб/с Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност
/Настолен телефон -> PSTN чрез LGW Г.711 - 80 кб/с Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Настолен телефон -> PSTN чрез облачен PSTN (напр. План за обаждания на Cisco) Г.711 - 80 кб/с Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> Предприятие чрез LGW Г.722 - 80 кб/с Брой едновременни повиквания* 80 kbps = Необходима мрежова пропускателна способност
/Телефон за бюро -> гласова поща ОПУС — 70 кб/с Брой едновременни повиквания* 70 kbps = Необходима мрежова пропускателна способност

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

Всички крака за повикване винаги са закотвени върху SBC за достъп. За да се определи необходимата интернет честотна лента за дадено местоположение, трябва да се вземат предвид не само разговорите между местоположенията, но и обажданията в рамките на локацията и обажданията до и от локален шлюз на това място. Например, обаждане в рамките на сайта между два MPP телефона ще се нуждае от до 2 x 70 kbps пълен дуплекс за достъп до интернет на местоположението.

Табли Webex Callingцата с примери за изчисл яване на честотната лента показва пример за пълно упражнение за изчисляване на честотната лента, като се приеме, че всички устройства са на един и съ щ сайт.
Таблица 3. Webex Calling примери за изчисляване на честотната
Видове обаждания Брой едновременни обаждания Обща честотна лента
Приложение Webex/Настолен телефон → Приложение Webex 15 2* 15* 70 кб/с = 2,100 кб/с
Приложение Webex/Телефон за бюро → Телефон за настолен 15 2* 15* 70 кб/с = 2,100 кб/с
Приложение Webex/Настолен телефон → PSTN чрез LGW 50 2 * 50 * 80 кб/с = 8 000 кб/с
Приложение 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 App и телефоните MPP 8845/65 поддържат H.264 видео с максимална разделителна способност 720p при максимална честотна лента от 1500 kbps на разговор. Въпреки това, количеството честотна лента, консумирана във всеки момент по време на разговора, ще варира въз основа на променливата скорост на предаване, присъща на видео комуникациите.

Качество на услугата (QoS)

Внедрете QoS политики във вашата локална среда, за да дадете приоритет на трафика в реално време и да гарантирате, че QoS се поддържа между комутатори, рутери и защитни стени.

Цели за латентност, треперене и загуба на пакети

Следните прагове се препоръчват за оптимално качество на гласа, когато обажданията преминават през отгоре (OTT) и в интернет:

Латентност - по-малко от 100 ms еднопосочна

Треперене - по-малко от 10 ms

Загуба на пакети - 0.5% или по-малко.

Защитна стена и NAT

Уверете се, че защитната стена е конфигурирана да позволява трафик, както е изброено в статията, налична в референтната информация за порт Webex Calling. Освен това позволете достъп до домейни и 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.

Потребители и устройства

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

Локален шлюз

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

Местоположения/сайтове

Броят и типовете обекти (големи централни, регионални, клонови и т.н.) в рамките на съществуващото ви разполагане трябва да се вземат предвид при планирането на този преход. Пълното разбиране на съществуващите места за разполагане ще помогне за стратегическото планиране на успешен преход, особено когато става въпрос за определяне на кои обекти да мигрират и в какъв ред. Разбирането на подробните изисквания за план за набиране (номериране, навици за набиране, класове ограничения и т.н.), свързаността на мрежата на сайта и честотната лента (Интернет, WAN, LAN) и достъп до PSTN (локален или централизиран, IP или TDM) за всеки сайт ще бъде от решаващо значение при вземането на решения за миграция. За повече информация относно общите модели на внедряване и ключови съображения вижте информацията за моделите за внедряване на сътрудничество, налична в SRND за сътрудни чество.

Друго важно съображение за внедряване при преминаване към е наличността на местоположението. има различни възможности, абонаменти и устройства, които са налични в зависимост от това къде се намира вашето внедряване. За повече информация относно географската наличност вижте Къде е наличен Webex? .

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

Инвентаризация на съществуващи устройства/клиенти

Преди да започнете прехода е важно да инвентаризирате съществуващите хардуерни и софтуерни крайни точки. Наличието на пълен списък с типовете устройства/модели, хардуерните версии, типовете и количествата на меките клиентски операционни системи ще гарантира, че можете адекватно да планирате прехода на устройствата и да смекчите въздействието на тези устройства, които не могат да бъдат мигрирани към обаждания в облак. Инвентаризацията трябва да се използва за определяне на устройствата за преход и устройствата, които трябва да се заменят преди прехода.

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

За аудио и видео настолни телефони се поддържат само настолните телефони от сериите 6800, 7800, 8800 и 9800. Това е подмножество от IP телефоните на Cisco, които се поддържат. Има някои модели и версии на телефоните 6800, 7800 и 8800, с които не могат да се използват. За повече информация за това кои модели и хардуерни версии се поддържат вижте Поддържани устройства за Webex Calling.

IP телефоните от серията Cisco 6800 не могат да бъдат надстроени от корпоративен фърмуер до мултиплатформен (MPP) фърмуер, който е необходим. Следователно всички 6800 телефона, регистрирани за работещ корпоративен фърмуер, трябва да бъдат заменени с модел 6800 MPP или с друг поддържан модел телефон.

IP телефоните от серията Cisco 7800 и 8800 трябва да бъдат надстроени до фърмуера на мултиплатформен телефон (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 обаждания, изискват лиценз за повикване:

Споделените устройства в конферентни зали, пространства за сгъване и т.н. изискват лиценз за професионално работно пространство или работно пространство.

Личното устройство на крайния потребител изисква професионален или стандартен лиценз.

Определете колко видео крайни точки са регистрирани и се използват за осъществяване на аудио разговори. Възможно е някои от крайните точки на видеоклипа да се използват само за присъединяване към срещи или извършване на 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телефоните работят с корпоративния фърмуер, докато телефоните работят с фърмуера с мултиплатформен телефон (MPP). Препоръчва се да проверите кои регистрирани телефони отговарят на условията за надграждане до MPP фърмуера по време на фазата на подготовка. Това ви дава време да замените неотговарящи на условията телефони с един от поддържаните модели телефони или да идентифицирате алтернативен план, като например преместване на потребител само в приложението Webex.

За да помогне при определянето на допустимостта на телефоните, Control Hub има вграден инструмент, наречен 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 телефона

Потребители

Една от най-важните стъпки за подготовка, за да сте сигурни, че имате успешна миграция, е правилното предостав яне на потребителя. Трябва да планирате правилно за всички потребители, дори ако правите поетапна миграция. Потребителите трябва да бъдат осигурени за някое от следните неща:

Разгръщане на с повикване

Разгръщане на с

Конфигуриране на услуги за потребител

За да може потребителите да могат да се търсят в директорията (кликване, за повикване, информация за контакт с потребителя, търсене на телефонна директория).

Препоръчително е да предоставите всички потребители преди или в началото на вашия проект. Това включва потребители, които все още използват платформата Unified CM за повикване, е независима от устройството им за повикване (IP телефон, Jabber,). Когато потребителите бъдат мигрирани към (и/или), вие ще актуализирате техните лицензи, за да активирате услугите, от които се нуждаят. Чрез предоставяне на всички корпоративни повикващи потребители преди започване на прехода ви позволява на потребител, който е преминал към или да търси в директорията потребител, който повиква корпоративен потребител, който все още е на Jabber и/или включен. Това гарантира, че преходните потребители могат да намерят информация за контакт на всеки друг потребител и да се обаждат с тях, като използват търсенето на директории.

Търсенето на директория с фигури показва пример за потребител, който търси друг потребител. Резултатите от търсенето показват информацията за контакт на потребителя и могат да бъдат за потребител, който все още е в Jabber или за потребител, който е преминал към и/или.

Търсене в директорията на Webex App

След това определете към кои от съществуващите локални повикващи потребители ще бъдат прехвърлени. Ако всички или голям брой потребители ще бъдат прехвърлени, тогава се препоръчва да преместите потребителите в групи, за да се гарантира, че екипът на проекта, ИТ персоналът и помощният персонал са в състояние да се справ ят с прехода и всички проблеми, които могат да възникнат. Също така трябва да отделите известно време, за да предоставите първоначална информация и обучителни сесии, за да подготвите потребителите за този преход. Групирането на потребителски преход може да се извърши въз основа на различни критерии, включително местоположението или сайта, към който са назначени потребителите, отделите на потребителите или дори типове потребители (работници по знания, ръководители, мобилни работници и т.н.).

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

Друг важен фактор е прехвърлянето на потребителите заедно, които имат зависимости помежду си. Това може да включва, но не се ограничава до следното:

BLF мониторинг

Същият лов пилот/група

Споделяне на редове

Част от една и съща група за вземане на обаждания

Използване на едни и същи номера за паркиране на повиквания

Домофон

Административ/Изпълнителен директор.

Можете да прегледате конфигурацията (GUI или експортиране) или да използвате инструмента Migration Insights, за да помогнете за идентифицирането на групите потребители с тези зависимости.

PSTN свързаност

може да има достъп до PSTN по три начина: планове за обаждания на Cisco, Cloud connect for (по-рано Cloud Connected PSTN) и локален PSTN (Локален шлюз). Въпреки това, едно местоположение, както е дефинирано в рамките на, може да бъде присвоено само на една опция PSTN.

Локалният PSTN с локален шлюз (LGW) е съществен компонент на стратегията за преход. Той осигурява свързаност между локалното внедряване и/или PSTN и платформа. поддържа както Cisco, така и сертифицирани контролери за гранични сесии на трети страни (SBC), които могат да се използват като локален шлюз. За последния списък на поддържаните SBC вижте Списък на поддържаните S BC.

поддържа до 250 едновременни обаждания от един локален шлюз, базиран на регистрация, и повече от 250 едновременни обаждания от един локален шлюз, който е базиран на сертификат. Локалните шлюзове, базирани на сертификати, могат да поддържат до 6500 едновременни обаждания, но това се основава на типа свързаност, към която трябва локалният шлюз (Over-the-Top vs Interconnect peering) и модела SBC, на който е внедрен локалният шлюз. Тези ограничения по същество са ограничението по подразбиране както за PSTN повиквания, базирани на локален шлюз, така и за повиквания между сайтове между и крайните точки. За повече информация вижте Първи стъпки с локален шлюз.

Всички обаждания, надвишаващи този лимит, се отхвърлят с 403 Забранено. Гласовата команда show call active може да се изпълни на локалния шлюз във всеки случай, за да се определи общият брой активни повиквания.

Лошите мрежови условия между локален шлюз и SBC за достъп могат да ограничат производителността на сигналната връзка, което води до още по-ниско ограничение за ед новременни повиквания. Еднопосочната латентност между локалния шлюз и центъра за данни не трябва да надвишава 100 ms и трептенето трябва да бъде по-малко от 10 ms, докато загубата на пакети е по-малка от 0,5%.

Характеристики и използване на функциите

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

За да определите кои функции са конфигурирани, анализирайте конфигурацията. Това са всички статични данни, които се задават, когато функция или настройка е конфигури рана в системата. Следните опции могат да се използват за завършване на този анализ:

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

конфигурационен експорт - насипен експорт или AXL

инструмент за информация за миграция (Препоръчва се)

Инструменти за партньори на Cisco от трети страни (Препоръчва се).

За да анализирате ефективно използването на функциите, е от съществено значение да се проучат динамичните системни данни като използване, регистрации и активност на повиквания. Различни аналитични инструменти и табла за управление предоставят информация за тези показатели, позволявайки цялостно разбиране на производ ителността и капацитета на системата, което поддържа информираното вземане на решения по време на усилията за миграция и оптимизация. Следните опции могат да се използват за завършване на този тип анализ:

Преглед на необработени CDR записи

Преглед на данните Unified CM от RTMT

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

Таблица 6. Отчети, генерирани от Unified CM .tar и CD. gzip файлове
Име на доклада
Описание на доклада
FeatureUsageBasedDeviceEligibilityReport.csv
Информация за допустимостта за мигриране на устройства въз основа на използването на функцията
FeatureUsageWithLastUsageDateReport.csv
Брой на използвания за броя пъти, в които пилотът (ите) за лов и опашката (ите) за повикване са били извикани заедно с последната дата на използване
UserWorkspaceLastUsage.csv
Последна дата на използване за потребители и работни пространства както за меки клиенти, така и за твърди телефони
DIDUsageReport.csv
Използване на DID както за присвоени, така и за незададени DID

За повече подробности относно отчетите за миграционните данни вижте Информа ция за ми грацията.

Ако имате нужда от повече информация за функциите и използването след преглед на информацията в отчетите Migration Insights, Cisco препоръчва да обмислите един от инструментите за мигриране на партньори от трети страни на Cisco и/или да прегледате конфигурациите в графичния интерфейс или в конфигурационните данни за експортиране.

Интеграции на Cisco: Unity Connection UCCX UCCE

Гласовата поща е неразделна част от офертата и естествено е вградена в решението. не може да се интегрира с решение за гласова поща, базирано на помещения, като Unity Connection или Unity Connection Express. Освен това няма естествен начин за мигриране на съществуващи съобщения за гласова поща за връзка с Unity или поздрави към родната услуга за гласова поща, налична с нея. Някои от инструментите за мигриране на партньори от трети страни на Cisco имат възможности за мигриране на някои от тези данни. За повече информация относно гласовата поща вижте Конфигуриране и управление на настройките на гласовата поща за потребител Webex Calling .

също така поддържа споделена гласова поща и факс пощенски кутии. За повече информация вижте Управление на споделена гласова поща и входящ факс кутия за. Webex Calling

има вградена функция за автоматично обслужване, която е включена като част от основната платформа. Тази функция позволява прехода на обработващите повиквания на вашата Unity Connection и функционалността за автоматично обслужване. Инструментът Control Hub, Migration Features fromUnified CM, поддържа мигри ране на конфигурациите на Unity Connection към автоматични помощници. За повече информация относно използването на този инструмент вижте Ми грация на устройства и функции от Unified CM къмWebex Calling.

Запис на обаждания

включва две опции за запис на разговори без допълнителни разходи.

Запис на обаждания на Webex

Dubber Go Recording (партньорска оферта) - интеграция между и дубър, където всички записани носители се съхраняват сигурно в облака.

Включената таблица с опции за запи с подчертава някои ключови характеристики на двете опции за запис на повиквания, които са налични без допълнителни разходи.

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

Достъпно за всички потребители Достъпно за всички потребители

Неограничени записи Неограничени записи

1 година период на задържане* 30-дневен период на съхранение

100 GB място за съхранение на организация -

Служителите по съответствие могат да имат достъп и да управляват записите на разговори -

API за управление на записи -

Админите могат да конфигурират и управляват достъпа на потребителите до техните записи на разговори
Потребителите могат да управляват собствените си записи с помощта на User Hub и/или приложението Webex.
Само потребителите могат да имат достъп и да управляват своите записи
От техния дублиращ портал.

Ако организацията ви изисква допълнителни възможности за запис, като например запис на повиквания за съответствие, по-дълги периоди на съхранение, повече съхранение, анализ на AI и/или достъп до администратора, съществуват платени оферти или добавки както от Cisco, така и от доставчици на записи от трети страни. За повече информация относно доставчиците на записи, конфигурациите и допълнителните партньорски услуги вижте Управление на записа на повиквания за Webex Calling.

Интеграции на трети страни

^{поддържа различни интеграции от трети страни, включително, но не само, SBC
за локални шлюзове, IP телефони, домофонни телефони, високоговорители/пейджъри, ATA и др.} В допълнение към тези устройства за ^трети страни, Webex Calling поддържа различни решения на трети ^страни за поддръжка на клиенти, анализи, запис, фактуриране и др. За повече информация относно реш енията ^на трети страни вижте Webex App Hub.

Таблица 4. План за преход на потребителя по сайт
Потребителски сайт/ местоположение	Информационни и обучителни сесии преди прехода	Преходен период	Поддръжка след прехода
Ню Йорк (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 телефони, устройства с операционна система Room, ATA и трети страни)
DevicePoolNumbers.txt Списък на всички номера в даден пул от устройства
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробности за устройствата и потребителите, които трябва да бъдат мигрирани заедно въз основа на споделени линии, пилот за лов, опашка за обаждания, паркиране на повиквания и конфигурация на групата за вземане на обаждания
HuntGroupMigrationInsight.csv Подробна информация за зададените ловни линии, групи линии и свързаните с тях агенти
SharedlineGroupMigrationReport.csv Преглед на това как телефонните номера (номера на директории) се споделят между потребителите

Таблица 6. Отчети, генерирани от Unified CM .tar и CD. gzip файлове
Име на доклада Описание на доклада
FeatureUsageBasedDeviceEligibilityReport.csv Информация за допустимостта за мигриране на устройства въз основа на използването на функцията
FeatureUsageWithLastUsageDateReport.csv Брой на използвания за броя пъти, в които пилотът (ите) за лов и опашката (ите) за повикване са били извикани заедно с последната дата на използване
UserWorkspaceLastUsage.csv Последна дата на използване за потребители и работни пространства както за меки клиенти, така и за твърди телефони
DIDUsageReport.csv Използване на DID както за присвоени, така и за незададени DID

Таблица 7. включени опции за запис
Webex	Дубър Го
Достъпно за всички потребители	Достъпно за всички потребители
Неограничени записи	Неограничени записи
1 година период на задържане*	30-дневен период на съхранение
100 GB място за съхранение на организация	-
Служителите по съответствие могат да имат достъп и да управляват записите на разговори	-
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. Единствената промяна е изискването за връзка към.

За повече информация относно този преход вижте Карта за преход и Ръководство за в недряване на Jabber към Webex в раздела Клиент на страницата Преход за сътрудничество.

Unified CMкъм картата на прехода на Webex Calling високо ниво фигурата е преходът на високо ниво от към. Това е стъпка 2 от препоръчаното пътуване.

Unified CMкъм карта на пре Webex Calling хода на високо равнище

Ако решите да използвате подхода с една стъпка, това също важи.

В тази стъпка потребителите се прехвърлят към групи. В този момент потребителите започват да използват за своите повиквания услуги, регистрация на обаждания и регистрация на IP телефон.

Тъй като потребителите се движат в групи, потребителите на Enterprise ще бъдат разделени между двете платформи за повикване по време на прехода. Фигурата Unified CMна картата на прехода от фаза 1 до 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 и обаждания към устройства). Необходимо е да се определи необходимата честотна лента за достъп до интернет.
Държава -
Часова зона -
Език -
Контакт (име, телефон, имейл) -
Адрес (адрес на улица, град, щат, пощенски код) -
Физическо изпращаемо местоположение на службите за спешни случаи за крайни точки Местоположението за изпращане на устройството, използвано за спешни повиквания, обикновено включва следното: адрес на сградата, адрес на сградата + номер на етажа, адрес на сградата + номер на апартамента или адрес на сградата + номер на етаж+офис/кубичен номер.
Уникално физическо местоположение на мрежата за аварийни служби за всяко устройство Местоположението на физическата мрежа за спешни повиквания обикновено включва следното: превключвател за кабелни устройства, Идентификатори за базови набор от услуги за безжична точка за достъп (AP) за безжично свързани устройства и/или локални IP подмрежи за устройства с крайни точки.

PSTN

При проектирането на внедряване клиентите имат три основни опции за свързване на PSTN: Cisco C alling Plans (PSTN услуга, предоставяна в облак, управлявана от Cisco), свързани с облак PSTN доставчици (CCPP, където доставчиците предоставят PSTN услуга през облака) и локални PSTN (където локал ните шлюзове свързват корпоративната мрежа с PSTN). С въвеждането на PSTN trunking за хибридни внедрявания (За повече информация вижте PSTN trunking за хибридни внедрявания при PSTN trunking), организациите получават допълнителна гъ 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 чрез връзката Local Gateway Webex Calling между локал ните и. По време на прехода местоположенията могат да бъдат превключени с помощта на Cloud Connected PSTN.

И в двата случая обажданията между локални и потребителски използват връзката Local Gateway. Връзката между локалните и трябва да бъде проектирана и оразмерена съответно въз основа на очаквания брой едновременни повиквания и необходимото съкращаване.

План за набиране

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

Локален план за набиране в

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

+E.164 набиране от до

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

Съкратено набиране между обектите от до

Принудително набиране в мрежата от до

Обратно обаждане от директорията за пропуснати повиквания към дестинации

PSTN извиква от към PSTN, ако по време на прехода се използва локален PSTN за

PSTN обаждания от до ако по време на прехода PSTN транкингът за хибридни внедрявания се използва за осигуряване на PSTN достъп на локални потребители чрез Cloud Connect за

Принудително включване в мрежата от до

Разширено набиране от до (междуобект).

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

Фигура Планът за на биране на най-добрите практики показва подхода на план за набиране с най-добри практики, както е описано в Пред почитана архитектура за Cisco Collaboration 12.x Enterprise On-Locals 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 дяла или от един от моделите на маршрута на PST N в USPSTNNational или SJCPSTNLocal дяла. Съкратените навици за набиране в рамките на сайта и между сайтовете се прилагат от преводите в дяла ES N и SJCTOe164. Докато ESN дял ът е глобален дял (достъпен за телефони на всички места), дялът SJCTOE164 е достъпен само за потребители в местоположението SJC. Това предполага припокриващи се диапазони на разширения.

Първата стъпка за активиране на обаждането от до е да се уверите, че дестинациите +E.164 се насочват съответно. Това може да се постигне чрез добавяне на дял към плана за набиране, добавяне на +E.164 модели на маршрут за всички дестинации към този дял и накрая добавяне на дяла към всички извикващи пространства за търсене, представляващи класове услуги, които трябва да могат да бъдат достигнати. Създаването на специален дял е необходимо, за да се даде възможност за създаване на диференциран клас услуги за обаждания, произхождащи от. За да избегнете цикли на повиквания, пространството за търсене на входящи повиквания в багажника от Local Gateway не трябва да има достъп до дяла.

+E.164 маршрутизиране към Webex Calling

Както е показано на фигура +E.164 маршрутизиране къмWebex Calling, за да се активира маршрутизиране от към за местоположение с диапазон +E.164 DID +1 221 555 2XXX и код на сайта 121, към дяла трябва да се добави спешен модел на маршрут, съответстващ на този диапазон +E.164.

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

За да активирате съкратено набиране между сайтовете към сайта, към дяла се добавя необходимия модел на маршру т 8121.2XXX. За да бъдат прехвърлени сайтовете към модел за нормализиране на набирането 8121.2XXX, който нормализира набирането на ESN до+E. 164, може вече да съществува в ESN дяла. В този случай 8121.2XXX изглежда излишен, но веднага щом всички DNS на съответното местоположение бъдат мигрирани към модела за нормализиране на набирането 8121.2XXX, моделът на превод може да бъде премахнат и след това моделът на маршрута 8121.2XXX позволява ESN набирането дори за потребители само за разширения в този диапазон.

С тези промени в плана за набиране повиквания към местоположението могат да се извършват не само чрез набиране на съкратен междуобект и +E.164. Също така, международното и националното набиране на PSTN са възможни, тъй като тези навици за набиране първо се нормализират до +E.164 чрез вече съществуващите модели на превод за нормализиране на набирането и след това се насочват чрез съответстване на модела на маршрута +E.164 в дяла.

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

план за набиране

Всеки потребител има разширение и/или телефонен номер +E.164. Дължината на разширението е фиксирана глобална настройка: всички разширения в разгръщане имат еднаква дължина. Разширеното набиране може да се използва между потребители както в рамките на местоположение, така и между местоположенията. Съкратеното набиране на разши рения между обектите (последният случай) работи само ако набраното разширение е уникално.

Ако съкратеното набиране между сайтовете между местоположенията е изискване, но има припокривания между разширенията, зададени на различни места, тогава трябва да се създаде специфичен за предприятието план за номериране чрез предварително фиксиране на разширенията с код за достъп и код на сайта. За повече информация вижте Пред почитана архитектура за сътрудничество на Cisco 15 Локални внедрявания, преглед на дизайна, наличен в предпочитаните архитектури на Cisco за сътрудни чество.

Дължината на разширението, поведението на набиране на разширения между местоположенията, дължината на префикса за набиране между местоположенията и кормилната цифра в префикса за набиране между местоположенията са конфигурирани в настройките на услугата за повикване в:

Д@@ ължина на префикса за маршрутизиране на местоположението: Дължина на префикса, включително цифрата Изиск ва се само ако план за номериране на предприятието трябва да бъде създаден като алтернативен съкратен навик за набиране между предприятията между местоположенията.

Кормилна цифра в префикса за маршрутизиране: Управ ляваща цифра за съкратен навик за набиране между предприятията между местоположенията. Трябва да се избягват припокривания с първата цифра на всяко местоположение и местоположение изходящи цифри за набиране. Изиск ва се само ако план за номериране на предприятието трябва да бъде създаден като алтернативен съкратен навик за набиране между предприятията между местоположенията.

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

Разрешаване на набиране на разширения между местоположения: Пре включете, за да активирате/деактивирате набирането на разширения между местоположенията. Тази опция трябва да бъде активирана само ако всички разширения в организацията са уникални. Ако опцията е деактивирана, тогава трябва да се набират значителни корпоративни номера (кормилен код, код на сайта, разширение) или телефонни номера между местоположенията.

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

Примерът за номериране на таблицата Enterprise показва пример за три места, където диапазоните на разширения на две места, NYC и RTP, са идентични. Създаването на схема за номериране на предприятието с кормилна цифра 8 между обектите, последвана от трицифрен код на сайта и четирицифреното разширение създава неприпокриващ се съкратен навик за набиране между обектите.

Таблица 2. Пример за номериране на предприятия
Сайт Обхват на разширяване Код на сайта Обхват на предприятието

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

За да се даде възможност за плавен преход, наборът от навици за набиране за потребителите преди и след премина ването към идеалния трябва да бъде същият. За да се подготви за прехода за всяко място, трябва да бъдат документирани DID диапазоните и обхватите на разширения (или съкратените навици за набиране в рамките на обекта). Въз основа на тази информация трябва да се избере кормилната цифра между обектите.

Таблицата Диа пазони на разширение с фиксирана дължина показва пример за три местоположения и диапазони на удължаване с фиксирана дължина. Тъй като трябва да се избягват припокриващите навици за набиране, важно е да се уверите, че за всеки разширен диапазон първата цифра от диапазона не съответства на кормилната цифра за съкратено набиране между места. Ако например 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, старият двуцифрен код на сайта и четирицифрено разширение. Потребителите не трябва да запомнят нови кодове на сайта; те трябва само да запомнят да използват 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 и Licenses API), които могат да бъдат използвани за автоматизация на възлагането на лицензи. API за лицензи позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Таблица 5. Опции за предоставяне на потребителя - резюме
Метод на възлагане Плюсове Минуси
Ръчно през Просто за малко потребители.
Позволява прецизен и подробен контрол върху възлагането на лицензи.
Не е мащабируем, отнема много време
Склонен към човешка грешка по време на ръчно въ веждане.

Автоматични шаблони за лиценз Мащабируем
Намалява ръчните грешки
Може да се прилага към нови и съществуващи потребители.
Изисква валидни телефонни номера и местоположения.
По-сложно за настройка
Също така изисква групи потребители на група потребители с еквивалентни лицензионни изисквания.

Групово качване на CSV Ефективен за големи потребителски комплекти
Позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Изисква внимателно CSV форматиране
Възможност за грешки, ако липсват телефон ни номера или разширения или са неправилни.
Назначаване, базирано на API Автоматизиран, гъвкав.
Позволява едновременно възлагане на лицензи, телефонни номера и разширения.
Изисква разработка и API познания.

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

Когато е възможно, Cisco препоръчва да се възлагат лицензи за повикване с помощта на лицензни шаблони Това изисква за всяка група потребители, която изисква уникален набор от лицензи (Пример - Standard vs. Професионален) съществува група със съответното членство в групата. Както е обсъдено в разделите Потребителски групи, потребителските групи могат да бъдат дефинирани ръчно в или синхронизирани от корпоративна директория. Въз можна е комбинация от двата подхода.

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

За повече информация вижте Настройване на автоматично присвояване на лицензи в Control Hub и Настройване на шаблони за автоматично присвояване на лицензи за Webex Calling потребители.

Изисквания за лиценз

Този раздел обхваща само свързаните лицензи. Други видове лицензи (пример - регистрация на устройство Webex, съобщения, срещи) не са обхванати. Като част от процеса на проектиране трябва да бъдат определени изискванията за лиценз. Трябва да се изчисли броят на лицензите за следните типове лицензи:

Стандарт: брой индивидуални потребители, изискващи стандартни телефонни функции.

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

Работно пространство за обща зона: брой местоположения за споделено използване или общи зони, изискващи стандартни възможности за повикване.

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

Оба@@ ждания в списъка с маршру ти: брой необходими PSTN повиквания, свързани с облака, между локални потребители и/или локални специализирани приложения на трети страни.

Придружаваща конзола: брой потребители, които се нуждаят от достъп до клиента на обслужващата конзола.

План за разговори на Cisco (план за изходящи повиквания): брой потребители, които изискват PSTN номер и/или достъп до изходящи PSTN повиквания за услугата Cisco PSTN.

Няма специален тип лиценз за професионални работни пространства. Професионалните работни пространства консумират професионален лиценз.

Работните пространства само за Hot-desk предлагат хост услугата за горещо бюро и спешни повиквания от хоста на хот-дескинга и не изискват никакъв лиценз. За повече информация вижте Добавяне и управление на устройства само за горещи бюро.

За да определите необходимия тип лиценз за всеки потребител и работно пространство въз основа на необходимите функции, вижте Функции, налични по тип лиценз за 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синхронизиране на потреб ителя: Тази опция позволява създаване на потребителски акаунти въз основа на съществуващи крайни потребители чрез синхронизиране от до. Това изисква CCUC (CCUC), свързан с облак, да работи в локалните клъстери. Обикновено обаче се препоръчва да синхронизирате потребителите от централизирана облачна директория като Entra ID, а не директно от.

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

Потребителски групи

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

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

Опростено админи стриране: Управление на лицензи, настрой ки и правила за няколко потребители едновременно.

Съгла суваност: Прилагайте еднакви настройки и лицензи за потребители от една и съща група.

Мащабируемост: Поддържа до 250 000 членове на група.

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

Гъвкавост: Създаване на локални групи или синхронизиране на групи за защита; управ лявайте членството в групата ръчно или чрез CSV файлове.

Разпределение на ресурси: Контролирайте достъпа до вградени приложения и услуги въз основа на членството в групата.

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

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

Шаблони за настройки: Прилагайте колекции от настройки на услугите (например съобщения, среща, обаждания) към групи за постоянно потребителско изживяване.

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

Автоматизация и интеграция: Използвайте API или синхронизиране на директории за автоматизирано управление на жизнения цикъл на потребителите и групите.

Следващата таблица обобщава различните опции за управление на потребителски групи и управление на групи в.
Таблица 7. Опции за управление на групи и членства в групи
Вариант Описание Плюсове Минуси

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

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

Групи и SCIM 2.0 API (групи) Използвайте Groups или 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 Wizard или SCIM приложения. Ръчното и CSV групово предоставяне са достъпни като допълнителни методи, но са по-малко мащабируеми и по-склонни към грешки за големите организации. Гарантирането, че Entra ID е авторитетният източник и че всички потребители съществуват в Entra ID, е от решаващо значение за успешното мигриране и последователното потребителско из живяване между и средите.

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

Проектиране на потребителски групи

След преминаване на корпоративната директория от локална към облака събирайте необходимите потребителски групи, управлявани от изискванията за лицензиране и шаблон на функции. За всеки групов документ:

Име на групата: уникално име на групата.

Лицензи: лицензи, които трябва да бъдат присвоени към тази група (ако има такива) и обхват (ако лицензите се присвояват на съществуващи потребители или само на нови потребители)

Шаблони за настройки: Webex App и шаблони за обаждания на потребителя.

Синхронизиране на директории: Ще се синхронизира ли тази група от корпоративната директория или това е локална Webex група, предоставена в Control Hub или чрез API.

Описание: как ще се използва тази група и кои потребители трябва да бъдат членове на тази група

Тези подробности ще бъдат използвани по-късно по време на фазата на внедряване за създаване на локални групи или групи в корпоративната директория и управление на груповото членство на потребителите.

Еднократно влизане (SSO)

Cisco препоръчва използването на SSO за удостоверяване на потребителя. Използването на SSO има някои убедителни предимства, включително:

О@@ простено удостоверяване на потребителя: Потребителите могат да влязат веднъж, като използват корпора тивните си идентификационни данни (например от Azure ID) за достъп и други интегрирани приложения, елиминирайки необходимостта от множество пароли и намалявайки подканите за влизане. Това подобрява сигурността, като гарантира, че корпоративните пароли никога не се съхраняват или предават на тях след удостоверяване.

Опростено управление на потребителите: Автоматизира създаването, актуализациите и деактивирането на потребителски акаунти въз основа на промените в корпоративната директория, намалявайки административните разходи и гарантирайки достъп само на оторизирани потребители.

Подобрена сигурност: SSO намалява умората от паролата и риска от нарушения, свързани с паролата, чрез централизиране на удостоверяването чрез надеждни доставчици на идентичност (IDP).

Лесна интеграция на многофакторно удостоверяване (MFA): MFA може лесно да се поддържа или чрез решение за управление на достъпа до идентичността като Cisco Duo, или чрез M FA поддръжка на IDP.

Има няколко опции за внедряване на SSO за услуги:

SAML 2.0 базиран SSO: Основният протокол, поддържан за интеграция на SSO, позволяващ сигурен обмен на информация за удостоверяване между IDP и доставчика на услуги.

OpenID connect (OIDC): Поддържа се като алтернативен модерен протокол за удостоверяване за интеграция на SSO.

Иденти@@ чност на Webex: Поддържа се и като опция за доставчик на самоличност.

SSO се конфигурира и управлява централно чрез, което изисква обмен на метаданни между и избрания IDP.

След конфигурирането SSO може да бъде тестван преди активирането, за да се гарантира правилната настройка.

Cisco поддържа интеграция с множество тествани и често използвани вътрешни лица и системи за управление на самоличността (IAM), включително, но не само:

Циско Дуо

Окта

Microsoft Active DirectoryФедерационни услуги (ADFS)

Microsoft Azure

ПингФедерация

Отворена АМ

F5 BIG-IP.

Тези IDP отговарят на стандартите SAML 2.0 или OpenID Connect и са валидирани за съвместимост с решенията за сътрудничество на Cisco.

Поддръжка на множество IDP

позволява на организациите да конфигурират SSO с множество разселени лица, за да приемат сложни ИТ среди като сливания, придобивания или децентрализирани ИТ отдели, където различните групи използват различни разселени лица. Поддръжката на множество IDP може да бъде реализирана с помощта на функцията Multiple iD P в или чрез интегриране на корпоративна IAM система като Cisco Duo.

поддръжката на множество доставчици на идентичност (IDP) адресира няколко ключови случая на използване, при които организациите изискват гъвкаво и сигурно удостоверяване в различни ИТ среди:

1. Сливания и придобивания

Когато компаниите се сливат или придобиват други, те често имат отделни ИТ инфраструктури и отделни разселени лица, които не могат да се обединят. Поддръжката на множество IDP позволява на потребителите от двете организации да удостоверяват и да си сътрудничат сигурно, без да е необходимо незабавно да унифицират системите си за самоличност.

2. Множество независими ИТ отдели

Големите организации или държавни институции могат да имат множество независими ИТ отдели, всеки от които управлява собствен ИД. функцията за множество IDP позволява на тези отдели да поддържат свои собствени системи за удостоверяване, като същевременно позволява на потребителите да имат безпроблемен достъп.

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

Организации с различни потребителски групи (напр. служители срещу изпълнители) или множество имейл домейни могат да конфигурират правилата за маршрутизиране, за да насочат заявките за удостоверяване към съответния IDP въ з основа на членството в домейна или група. Това поддържа диференцирани политики за достъп и контрол на сигурността.

4. Поддръжка на различни протоколи за удостоверяване

поддържа SAML и OpenID Connect (OIDC) IDP, което позволява на организациите да интегрират различни видове доставчици на идентичност според съществуващата им инфраструктура и изисквания за сигурност.

5. Подобрена сигурност и съответствие

Чрез активиране на множество разселени лица организациите могат да внедрят по-силни механизми за удостоверяване, включително многофакторно удостоверяване (MFA) чрез интеграции като Duo, и да налагат последователни политики за сигурност в различни потребителски бази.

6. Опростено потребителско изживяване

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

Въпреки че поддръжката на множество IDP осигурява гъвкавост, тя изисква внимателна координация между екипите за сигурност и идентичност, за да се поддържат последователни политики за сигурност и да се избегнат потенциални уязвимости.

Дуо MFA с SSO за

Duo Access Gateway (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основни характеристики

Автоматичен асистент

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

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

Автоматичният служител поддържа следните основни функции:

Работни и следчасови графици

График на празниците

Опция за набиране на менюто, за да насочите клиентите си там, където трябва да отидат

Персонализирайте поздравите

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

Опции за пренасочване на оба

Анализи и отчети на контролния център.

За повече информация вижте Управление на автоматичните служители.

Обадете се в парк

Call park дава възможност на потребителите лесно да задържат повикване, за да може друг потребител лесно да го изтегли, когато са на разположение, за да го приеме. Той също така освобождава потребителя, който е отговорил на първоначалното обаждане, да осъществява или получава други обаждания, докато повикването е паркирано.

Има два вида кол паркове, налични в:

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

Група за паркиране на пови квания - позволява на определена група потребители автоматично да паркират повиквания с прямо наличните паркови дестинации, определени за групата. Тези дестинации могат да бъдат разширения на член овете на групата или разширения за парка за повиквания.

Въз основа на конфигурацията и типа паркиране потребителите могат да извличат обаждания, като набе рат *88+><extension of parked call>, натискат линейния клавиш, свързан с разширението за паркиране на повиквания, или използват софтуерен клавиш на своя IP телефон.

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

За повече информация вижте Управление на парка за повиквания в контролния център.

Вземане на обаждания

Възприемането на повикване позволява на администратора да определи група потребители (членове), които могат да отговарят на обаждане до телефона на друг член. Това дава възможност на потребителя да отговаря на обаждания, когато съотборниците им са заети и не могат да отговорят на входящо повикване.

Потребителите в дадена група трябва да са на едно и също място.

Потребителите могат да използват телефона или настолния си телефон, за да получат обаждане.

:

Поддържа визуални и аудио известия

Известие за входящо обаждане

Въз основа на лице (наберете *98) или вземане на повикване с тост за уведомяване

Известия за получаване на обаждания за многолинейни.

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

Известие за входящо обаждане

Аудио камбанки и визуално известяване чрез светодиода на слушалката. 6821 поддържа само аудио камбанки

Когато типът на уведомлението е избран в не е ника къв

Известия за получаване на обаждания само за първични линии.

За повече информация вижте Конфигу риране на групата за събиране на повиквания.

Опашка за обаждания

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

Призивът на Cisco за интеграция на Microsoft Teams позволява на агентите да имат достъп до повиквания и функции на опашката за обаждания директно от техния клиент на Microsoft Teams.

Опашките за повиквания поддържат следните основни функции:

Поздрави и съобщения (добре дошли, комфорт, шепот и т.н.)

Задръжте музика

Обратно обаждане

Политики за маршрутизиране на опашки (нощно обслужване, празници, препращане)

Влизане/излизане на опашката на агенти

Управление на състоянието на опашката на агенти

или Поддръжка на настолен телефон

Агентът на надзорния орган се обажда на монитора, треньора, шлепа или поема управлението чрез кодове за достъп до функции (FACs)

(администраторски достъп) за:

управление на опашките

Анализ и отчитане на агенти и опашки

Управление на опашка, агент и надзорник.

За повече информация вижте Конфигу риране на опашката за повиквания.

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

Хънт Груп

Hunt Groups позволяват маршрутизиране на входящи повиквания към определена група потребители чрез предварително определен модел за маршрутизиране на повиквания. Това гарантира, че обажданията се отговарят от правилната група потребители или се изпращат на гласова поща за проследяване.

Една голяма разлика между групите за лов и опашките за повиквания е, че обажданията не се поставят на опашка в групи за лов, така че ако няма потребители в групата за лов, които да отговорят на повикването, те ще бъдат прекъснати, изпратени на гласова поща или пренасочени към друг номер (потребител или услуга).

За повече информация вижте Управление на групи за лов в контролния център.

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

Функцията за режими на работа позволява на бизнеса ефективно да насочва повиквания към различни дестинации (потребители, гласова поща, услуги за обаждания като опашка за обаждания). Къде и кога се насочва повикването се основава на график от денонощието и деня от седмицата и всеки потребител може да бъде упълномощен да управлява тези режими ( графици), за да контролира промените в маршрутизирането на повиквания.

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

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

За повече информация вижте Маршрутизиране на повиквания въз основа на режими на работа в Webex Calling.

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

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

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

За повече информация вижте Конфигу риране на група за пейджинг в Контролен център.

Записи

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

Когато се използва като платформа за запис, всички записани повиквания се управляват вътре. Пълните администратори с ролята на служител по съответствието могат да играят и изтеглят записите. Без ролята на служител по съответствието администраторът може да изтрие само записите.

За повече информация относно тази функция и списък със записи на трети страни вижте Управление на запи са на пови квания за Webex Calling.

Обхват с единичен номер

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

За повече информация относно тази функция и как администраторът я конфигурира, вижте Конфигу риране на обхват с един номер (офис навсякъде).

За повече информация как потребителят може да управлява и конфигурира тази функция за себе си в Webex User Hub (портал) вижте Конфигу риране на обхват с един номер (офис навсякъде).

Група гласова поща

Групите за гласова поща позволяват споделено поле за гласова поща, което може да бъде присвоено на потребител или функция за маршрутизиране на повиквания. Някои от причините, поради които може да се изисква група гласова поща, са:

Гласова поща с общо предназначение за отдел или работна група

Добавяне на опция за гласова поща към група за автоматично обслужване или лов

Изпращане на преливащи повиквания от опашка за обаждания

Потребители, които се нуждаят само от кутия за гласова поща.

За повече информация вижте Управление на споделена гласова поща и входящ факс кутия за. Webex Calling

Attendant Console е посочена на страницата Функции за повикване в Webex, но това е добавка, която изисква закупуване на лиценза за придружаващата конзола, за да се използва.

За повече информация вижте Първи стъпки с конзолата за обслужване.

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

Таблица 1. Информация за заснемане за всяко място
Информация	Коментар
Обхват (и) на разширение	Всяко местоположение може да има разширения, започващи с различни цифри. Една цифра трябва да бъде спестена за кормил ната цифра за набиране между обектите (например 8) и една за кор милната цифра PSTN (например 9). Никой диапазон на разширения не може да започне с нито една от тези две цифри. Всички диапазони на разширения на всички места трябва да са с еднаква дължина.
Диапазон (и) на DID	-
PSTN кормилна цифра	-
Код на сайта	Всички кодове на сайтове на всички места трябва да са уникални и да имат еднаква дължина.
Основен номер	При създаването на местоположение трябва да бъдат осигурени два DID. Един като основен номер (например за присвояване на услуга за автоматично обслужване) и един за портала за глас ова поща. Предоставяне на един DID за номера на гласовата поща.
Номер на гласовата поща
Брой лицензи	Необходими лицензи по тип, включително Стандартни, Професионални, Работни пространства, Списък с маршрути, План за изходящи повиквания.
Едновременни обаждания в натоварения час	Сбор от едновременни повиквания между устройства и между устройства и локалния шлюз (PSTN и обаждания към устройства). Необходимо е да се определи необходимата честотна лента за достъп до интернет.
Държава	-
Часова зона	-
Език	-
Контакт (име, телефон, имейл)	-
Адрес (адрес на улица, град, щат, пощенски код)	-
Физическо изпращаемо местоположение на службите за спешни случаи за крайни точки	Местоположението за изпращане на устройството, използвано за спешни повиквания, обикновено включва следното: адрес на сградата, адрес на сградата + номер на етажа, адрес на сградата + номер на апартамента или адрес на сградата + номер на етаж+офис/кубичен номер.
Уникално физическо местоположение на мрежата за аварийни служби за всяко устройство	Местоположението на физическата мрежа за спешни повиквания обикновено включва следното: превключвател за кабелни устройства, Идентификатори за базови набор от услуги за безжична точка за достъп (AP) за безжично свързани устройства и/или локални 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	Програмно управление на потребителите чрез Webex API	Гъвкав; поддържа автоматизация и интеграция	Изисква развитие и инфраструктура
Синхронизация на директория	Автоматично синхронизиране от AD, Entra ID, SCIM приложения, Unified CM	Автоматизира жизнения цикъл; поддържа филтриране и картографиране	Сложност на настройката: някои от опциите имат ограничени функции или изискват инфраструктура

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

Прилагане

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

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

Проверка на домейна

Поискайте (преобразувайте) съществуващи потребители

Конфигуриране и тестване на синхронизацията

Настройване и тестване на еднократно влизане (SSO)

Набавяне, предоставяне и проверка на лицензи

Webex Callingнастройки на услугата

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

Закупуване на PSTN

Конфигурирайте местоположенията

Интеграция с локален контрол на повикванията

Мигриране на потребители на партиди

Работни пространства

Устройства за осигуряване

Конфигуриране на функции

Тестване за приемане

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

Първата стъпка в преминаването към е да се осигури надеждна и сигурна интернет връзка между локалната мрежа и облака.

Тъй като повечето организации се свързват с интернет чрез една или повече защитни стени или устройства за сигурност, от съществено значение е да се потвърди дали необходимите потоци от трафик се поддържат.

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

Посока (входяща срещу изходяща)

Протоколи (Пример - 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
Конфигу@@ риране на споразумението за синхронизиране с групово филтриране: Когато настройвате споразумението за синхронизация в предоставянето на Directory Connector или Entra ID, конфигурирайте обхвата да включва само потребители, които са членове на определената група.

За Microsoft Entra ID можете да използвате групови задачи в настройките за предоставяне

За AD можете да дефинирате LDAP филтър, който да включва само потребители, принадлежащи към зададената група .

4
Разширете групата според нуждите: Докато напредвате към по-широки фази на внедряване, просто добавете допълнителни потребители или групи към групата за синхронизация. Обхватът на синхронизи ране автоматично ще се разшири, за да включва тези потребители, което позволява контролирано и постепенно в недряване.

Примерни стъпки за изпълнение:

В активната директория:

Създайте група за защита, наречена група за синхронизиране.

Добавете желаните пилотни потребители към тази група.

Настройте конектор за директории с LDAP филтър като: (MemberOf = CN = Webex Sync Group, OU = Groups, DC = вашият домейн, DC = COM).

В Microsoft въведете идентификатор:

Създайте група, наречена група за синхронизиране

Присвояване на групата към настройките за предоставяне на идентификатора в Entra

Само потребителите в тази група ще бъдат предоставени.

Винаги тествайте груповата синхронизация в непроизводствена среда, преди да кандидатствате за цялата организация

Редовно преглеждайте членството в групата, за да сте сигурни, че само оторизираните потребители са

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

Референции:

Синхронизиране на потребителите на Entra ID в контролния център

Настройване на приложението Entra ID Wizard в контролния център

Конектор за директории

Настройване и тестване на еднократно влизане (SSO)

Еднократното влизане (SSO) подобрява сигурността и опростява достъпа на потребителите, като позволява на потребителите да се удостоверяват веднъж с корпоративните си идентификационни данни и да получат безпроблемен достъп до тях. поддържа интеграцията на SSO с SAML 2.0 съвместими с IDP, включително Microsoft Entra ID (по-рано Azure AD), Active Directory (AD) федерални решения и различни местни лица на трети страни.

В този момент проектираната настройка на SSO трябва да бъде внедрена и тествана.

Референции:

Интеграция с единично влизане в контролния център

конфигуриране на еднократно влизане за администриране на webex

Конфигуриране на еднократно влизане с Microsoft Entra ID

SSO с множество разселени лица

Управление на SSO при интеграция в Control Hub

Набавяне, предоставяне и проверка на лицензи

Като част от първоначалната настройка за, от съществено значение е да се набавят, предоставят и проверят съответните лицензи, за да се активират и управляват услугите ефективно. Процесът на възлагане на поръчки включва избор на типове лицензи въз основа на потребителски роли и работни натоварвания, като лицензи Professional, Standard и Workspace . Лицензите се генерират и предоставят чрез софтуерните платформи на Cisco или чрез партньори. След поръчка и осигуряване трябва да се провери правилният брой лицензи . Този процес гарантира, че организацията разполага с правилните лицензи, активирани и готови за използване при внедряване.

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

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

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

По-конкретно, автоматичното възлагане на лицензи изисква допълнителни подробности за предоставяне, като местоположение на потребителя и задаване на телефонен номер. Работният телефонен номер на потребителя трябва да е във формат +E.164, предварително предоставен и присвоен на валидно място, за да може лицензът да бъде активиран автоматично. Ако тези условия не са изпълнени, на потребителя няма да се предоставят услуги автоматично и може да се наложи ръчна намеса.

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

Webex Callingнастройки на услугата

От съществено значение е да се извърши цялостен преглед и конфигуриране на глобалните настройки на услугата вътре.

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

Регулирайте тези глобални настройки, за да отразяват политиките и дизайнерските решения на вашата организация.

Също така настройките за настройка и шаблони за потребители и приложения.

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

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

Пилотната миграция следва да използва същата комбинация от инструменти, предоставени от Cisco, и помощни програми за миграция на трети страни, които са планирани за по-широкото организационно внедряване, като гарантира, че процесите, работните процеси за автоматизация и точките за интеграция са задълбочено валидирани при представителни условия.

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

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

Прозренията, получени по време на тази пилотна фаза, са от решаващо значение за оптимизирането на последващите миграционни вълни и осигуряването на плавен преход, намал ен от риска за цялото предприятие.

Закупуване на PSTN

За да набавите PSTN услуги за, първо изберете опция за PSTN свързаност в.

Ако дадена организация планира да поддържа хибриден контрол на двойните повиквания (фаза 1 на фигура Phased Calling Transition: Hybrid and Cloud) временно или за неопределено време, тя ще трябва да внедри един или повече локални шлюзове за локални PSTN, за да позволят обаждания между и крайните точки.

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

Работете с избрания от вас доставчик, за да поръчате и портирате телефонни номера, преди да ги конфигурирате. Поръчването на телефонни номера или инициирането на поръчки за портове е изискване/възможно само за локални PSTN и Cloud Connect. За плановете за обаждания на Cisco поръчването и портирането се инициират от контролния център веднага след създаването на местоположението и в страни, където е наличен план за обаждания на Cisco. За повече информация относно плановете за обаждания на Cisco виж те Първи стъпки с план овете на Cisco.

Като част от внедряването на PSTN, уверете се, че вашият доставчик е активирал както входящи, така и изходящи PSTN услуги за вашето местоположение. Освен това изпълнявайте тестови повиквания, за да проверите дали повикванията се насочват правилно през избраната от вас PSTN връзка.

Конфигурирайте местоположенията

Преди да добавите потребители и устройства към тях, трябва да предоставите местоположения за повикване. За всяко място трябва да се въведе валиден адрес на улица. В САЩ и Канада този адрес е валидиран и използван от платформата за изпращане на информация за местоположението на PIDF-LO за спешни повиквания.

Когато конфигурирате местоположения, които използват локален PSTN, трябва да настроите съответно локалните шлюзове. В програмата трябва да се създадат багажник и група маршрути за всеки локален шлюз и след това групата маршрути се присвоява като избор на PSTN за местоположението. Cisco силно препоръчва винаги да избирате група маршрути като избор на PSTN, тъй като този подход ви позволява лесно да добавяте допълнителни стволове в бъдеще, като поддържате както мащабируемост, така и излишък. Cisco препоръчва също така да се активира поддръжка с двойна идентичност и P-Charge-Info на всеки PSTN багажник, тъй като това опростява идентифицирането на платежната страна за изходящи директни или пренасочени повиквания. Ако вашият доставчик на PSTN използва различно заглавие за фактуриране, можете да копирате информацията от заглав ката P-Charge-Info на локалния шлюз в необходимия заглавък за фактуриране.

За местоположения, които използват Cloud Connect for или Cisco Calling Plan като опция за PSTN, просто изберете съответния избор на PSTN за местоположението по време на настройката. Ако местоположението използва или Cloud Connect for или локален PSTN, ще трябва да добавите телефонните номера, които са били поръчани в предишната стъпка. Номерата могат да бъдат добавени като неактивни, ако не искате да бъдат включени веднага в маршрутизирането на повиквания; можете да активирате тези номера по-късно, когато бъдат присвоени на потребители или функции.

Важно е винаги да задавате основния номер за всяко място. Основният номер може да бъде присвоен или на потребител, или на функция, като например автоматично обслужване. За да активирате гласовата поща на местоположението, не забравяйте да зададете пилотния номер на гласовата поща, известен още като номер на гласовия портал.

Допълнителните настройки за местоположенията за обаждания включват конфигуриране на подробности за спешни повиквания, като номера за аварийно обаждане, опции за уведомяване и подобрени функции за спешни повиквания. Също така трябва да прегледате и коригирате настройките за запис, езиковите предпочитания и конфигурациите на устройството според изискванията за всяко местоположение. Ако организацията ви използва съкратено набиране в мрежата между сайтове със значителни корпоративни числа, не забравяйте да конфигурирате уникален код на сайта за местоположението в настройките за вътрешно набиране. И накрая, ако външното набиране изисква из ходяща цифра за набиране, не забравяйте да го зададете в настройките за външно набиране. Когато е конфигурирана изходяща цифра за набиране, Cisco препоръчва да се активира прилагането на изходящата цифра за набиране, за да се гарантира последователност.

Интеграция с локален контрол на повикванията

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

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

Ако разгръщането ви изисква поддръжка за неизвестно маршрутизиране на разширения, тази функция трябва да бъде активирана на ниво местоположение. Освен това, когато е активирано маршрутизиране на неизвестно разширение, трябва да посочите максималната неизвестна дължина на разширението в секцията Маршру тизиране на повиквания между и помещ ения в настройките на услугите за повикване в. Това осигурява безпроблемно маршрутизиране на повиквания и правилно управление на сценарии за набиране, базирани на разширения, във вашата интегрирана среда.

Мигриране на потребители на партиди

Когато мигрирате потребители от към, може да не успеете да преместите всички потребители едновременно. Това може да се дължи на множество причини, включително, но не само, броя на сайтовете или потребителите, колко време отнема преходът на даден сайт и/или група потребители едновременно, ограничен ИТ или ресурс на сайта за поддръжка на прозореца за промяна, продължителност на прозореца за промяна, сложност на промяната и т.н.

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

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

Наблюдение на други потребители, използващи BLF

В същия лов пилот, опашка за обаждания и т.н.

Споделени линии

Използване на вземане на обаждания

Използване на едни и същи номера за паркиране на повиквания

Домофон

Изпълнител/администратор.

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

Това става по-предизвикателно, когато потребителите са свързани с различни групи потребители за различни услуги и функции за обаждания. Това ще изисква преминаване на повече от една група потребители и една услуга за обаждане едновременно.

Използвайте изхода от инструмента Migration Insights или инструмента на трета страна, който сте използвали във фазата на подготовка, за да определите кои потребители и функции трябва да бъдат групирани заедно. Този изход трябваше да бъде използван за разработването на вашия план за миграция и ще ви даде представа за това как ще групирате потребители и функции, които трябва да се прехвърлят заедно.

Ключовите стъпки при прехвърляне на партида потребители са:

Идентифициране на потребители за мигриране заедно

Проверете дали всички потребители са в

Проверете всички TN за съществуващите потребители

Проверете правилния формат на телефонния номер в директорията

Уверете се, че шаблонът за лицензиране и настройки за потребител ските групи са настроени правилно

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

В корпоративната директория добавете потребители към група потребители с активирани повик вания

Leverage Tools - инструменти за мигриране на потребители и функции и/или инструменти на трети страни

Деактивиране/изтриване на номера на директория на потребителя/устройството и функции/услуги за повикване след прехода.

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

Работни пространства

В работното пространство се отнася до споделено местоположение (като конферентна зала, място за сгъване или горещо бюро), на което могат да бъдат зададени устройства, разширения и потребители. За разлика от традиционните телефони Unifed CM, работните пространства са:

Ориентиран към местоположението: обвързан с физически пространства.

Гъвкаво устройство: може да има едно или повече устройства (настолни телефони, табла и др.).

След като работните пространства бъдат идентифицирани като част от прехода към, те могат да бъдат добавени в раздела Устройства. Всяко работно пространство се нуждае от задаване на устройство и ако вече е включеноUnified CM, то трябва да бъде нулирано или преосигурено. функции като гласова поща, пренасочване на повиквания и получаване на повиквания могат да бъдат активирани или деактивирани, а политиките могат да се прилагат за видео разговори, паркиране на повиквания и мобилност, ако е необходимо. Тествайте всяко работно пространство, като извършвате вътрешни и външни повиквания, тествайте видео, конферентни връзки и функции за мобилност . И накрая, уведомете потребителите за всички приложими процеси за устройства и резервации на работното пространство.

За повече информация относно работните пространства вижте Работни пространства.

Устройства за осигуряване

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

Всички поддържани телефони, от които трябва да преминете, ще трябва да бъдат конфигурирани като потребител или работно пространство и физическият телефон ще трябва да бъде преконфигуриран, за да се регистрира. В допълнение, телефоните от серията 7800 и 8800 се нуждаят от надстроен фърмуер от корпоративен фърмуер до фърмуер за мултиплатформен телефон (MPP). Този процес включва зареждане на преходен фърмуер преди зареждане на MPP фърмуера, необходим за регистрация. Той също така изисква подходящ лиценз за миграция. Cisco подобри този процес през последните няколко години, за да ви улесни да надстроите вашите телефони с фърмуер на Enterprise до MPP фърмуер. За повече информация относно стъпките за завършване на надстройката на фърмуера вижте Конвер тиране на IP телефони от серията Cisco 7800 и 8800 между Enterprise и MP P фърмуера.

В допълнение към стъпките, описани в тази статия, има вграден инструмент, Мигрирайте телефона си къмWebex Calling, който можете да използвате, за да помогнете за мигрирането на вашите 7800 и 8800 телефони от Enterprise към MPP фърмуера. Този инструмент също ви позволява да добавяте телефоните към и да ги присвоявате на подходящите потребители или работни пространства. За повече информация относно използването на инструмента вижте Миг риране на телефона.

За всички телефони от серия 9800, регистрирани с горното изискване за миграция на фърмуера, не се прилага. Тези телефони работят с PhoneOS, който се поддържа от двете и. За да прехвърлите тези телефони към вас, ще трябва да ги добавите къмWebex Calling, да ги присвоите на потребител или работно пространство и след това да нулирате фабричните настройки на телефоните. Последователността за зареждане на PhoneOS за регистрация по-долу показва последователността на зареждане на 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 телефоните, за да ги прехвърлят от корпоративен фърмуер към облачен фърмуер. Следователно ще предоставите всяко от тези устройства в Control Hub. Някои от тях не могат да бъдат прехвърлени и еквивалентният модел ще трябва да го замени (напр. ATA 191/192) и други ще изискват ръчно пре конфигуриране и/или промени в софтуера.

Гласови шлюзове - За да мигрирате локалния шлюз, вижте Мигриране на локален шлюз.
За повече информация за конфигуриране на гласовия шлюз VG400, VG410 или VG420 в контролния център вижте Локален шлюз

Аналогов телефонен адаптер (ATA) - За да започнете с вашите Cisco ATA 191 и 192, вижте Cisco ATA.

Wifi безжичен телефон - За да интегрирате безжичен телефон 840 и 860, вижте Интегриране на безжичен телефон Webex.

Без@@ жични телефони DECT - За да започнете с новата си серия Cisco IP DECT 6800, вижте Cisco IP DECT.

За да изградите и управлявате цифрова DECT мрежа в Control Hub вижте Управление на DE CT мрежа

За повече информация относно Cisco IP DECT 6800 вижте Ръководство за внедряване

Устрой ^ства и телефони на трети страни - Работете с доставчици на ^трети страни по изискванията за устройство/телефон и процеса на мигрирането или замяната им за поддръжка.

Конфигуриране на функции

Всички функции за извикване, които са необходими, трябва да бъдат предоставени преди или по време на прехода. Както беше обсъдено по време на секцията „Мигриране на потребители в партиди“, функциите за повикване трябва да бъдат конфигурирани и прехвърлени, когато потребителите, които ги използват, бъдат прехвърлени.

За подробности как да конфигурирате всяка от функциите вижте съответните помощни статии за конфигуриране.

Автоматични служители - За да управлявате автостюардесите, вижте Автоматични служители

Парк за обаждания - За да управлявате парка за обаждания, виж те Call park

Вземане на повикване - За да конфигурирате групата за получаване на повикване, виж те Пол учаване

Опашки за повиквания - За да конфигурирате опашката за повиквания, виж те О пашка

Групи за лов - За да управлявате ловни групи, вижте Управление на група за лов

Режими на работа - За маршрутизиране на повиквания въз основа на режими на работа вижте Маршрутизиране на повиквания въз основа на оперативни режими

Групи за пейджинг - За да конфигурирате група за пейджинг, вижте Конфигу риране на пейджинг група

Записи - За да управлявате записа на повиквания, вижте Управление на записи

Достъп до единичен номер - За да конфигурирате обхват на единичен номер (офис навсякъде), вижте Кон фигуриране на единичен

Група гласова поща - За да управлявате споделена гласова поща и входяща факсова кутия вижте Управление на гласовата поща.

Тестване за приемане

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

Този раздел предоставя примери и подчертава ключови аспекти, които трябва да се вземат предвид по време на тестването за приемане; той обаче не е предназначен да служи като изчерпателен или изчерпателен контролен списък.

Предоставяне на потребителя и присвояване на номера

Основен аспект на тестването за приемане включва проверка дали всички потребители са предоставени точно и изцяло вътре. Това изисква задълбочено сравнение между директорията source () и новосъздадената потребителска база, за да се гарантира, че всеки потребителски акаунт, заедно със свързаните атрибути като номера на разширения и задачите за директно набиране (DID) е мигриран правилно. Пълнотата на осигуряването е от решаващо значение не само за оперативността на първия ден, но и за текущата администрация и поддръжка.

Валидирането на присвояване на номера включва потвърждаване, че на всеки потребител е присвоено правилното разширение и външен номер и че тези номера се насочват правилно както във вътрешните (вътрешни), така и във външни (PSTN) потоци от повиквания. От съществено значение е да проверите за припокривания, липсващи задачи или неправилни конфигурации, които биха могли да доведат до грешки при маршрутизиране на повиквания или прекъсвания на услугата.

PSTN Потоци от повиквания и представяне на идентификатора на обаждащия се

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

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

Потоци от повиквания в мрежата

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

Управление на потребителски повиквания и проверка на функциите

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

Опитът трябва да бъде оценен за яснота и отзивчивост, като се има предвид как потребителите взаимодействат с историята на обажданията, гласовата поща и интегрираните директории. Трябва да се обърне допълнително внимание на възможността за преместване на активни повиквания между устройства и ефективно използване на контролите по време на повикване в рамките на приложението или на физически телефони. Крайната цел е да се гарантира, че изживяването на крайния потребител е последователно, ефективно и напълно подкрепя комуникационните нужди на организацията след миграцията.

Опашки за обаждания: Опит на агент и ръководител

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

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

Групи за лов: Разпространение на обаждания

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

Автоматични служители: Съобщения и операции в менюто

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

Операция с гласова поща

И накрая, функционалността на гласовата поща е от решаващо значение за потребителското изживяване. Тестовете за приемане трябва да проверят дали кутиите за гласова поща са правилно зададени и достъпни, както от организацията, така и от разстояние. Възможността за записване, извличане и управление на съобщения трябва да бъде потвърдена, заедно с доставката на уведомления.

Оптимизиране

Миграция на PSTN към Cloud Connect за

Оптимизиране на локалната инфраструктура

Използвайте анализ и отстраняване на неизправности

Миграция на PSTN към Cloud Connect за

След като всички крайни точки и потребители бъдат мигрирани към облачно извикване, единствената цел Unified CM е да действа като транзит между PSTN шлюзовете и чрез Local Gateway. Премахването на 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 trunking за хибридни внедрявания. За повече информация вижте PSTN транкинг за хибридни внедрявания. Webex Calling В този случай по време на прехода достъпът до PSTN е чрез Local Gateway и след преместване на всички потребители към него няма допълнителна миграционна стъпка, свързана с PSTN, освен извеждането от експлоатация и Локалните шлюзове.

Оптимизиране на локалната инфраструктура

След като всички потребители са преминали към и всички крайни точки са преминали към регистрация в облак (или са били извед ени от експлоатация), актуализирайте подходящата локална инфраструктура сега, когато се използва обаждането в облак. Актуализациите на инфраструктурата включват:

Премахнете локалните DNS SRV записи за контрол на повиквания и съобщения от локалния DNS сървър (и), включително cisco_uds. _ткп. <domain>, чаш ка_вход. _ткп. <domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги.

Премахнете DNS SRV записи, свързани с ръба, от публичната DNS система, включително collab_edge. _тл. <domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги на крайни услуги за сътрудничество.

Актуализирайте всички съответни DHCP обхвати, за да премахнете опция 66 и опция 150 TFTP/адреси на сървъра за зареждане. Тези обхвати вече не са необходими за откриване и изтегляне на конфигурация за контрол на повикването в крайна точка.

Актуализиране/премахване на съответните набиращи партньори в Local Gateway/Cube, които насочват повиквания към и от. Unified CM Тези колеги за набиране вече не са необходими за локално маршру тизиране на повиквания.

Изтриване или премахване на всички виртуални машини и/или сървъри и клъстерни възли. Пренасочете изчислителните ресурси и хардуера според нуждите . Тези ресурси вече не са необходими за контрол на разговорите и крайните услуги.

Изтриване или премахване на всички виртуални машини и/или сървъри на клъстерни възли. Пренасочете изчислителните ресурси и хардуера според нуждите . Тези ресурси вече не са необходими за гласова поща и унифицирани услуги за съобщения.

Почистване: След мигриране на PSTN достъп до PSTN свързан с облак PSTN, PSTN стволовете, PSTN шлюзовете и локалния шлюз могат да бъдат изведени от експлоатация.

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

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

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

Подмяна на мрежовия превключвател

Подмяна на безжична точка за достъп

Промени в обхвата на DHCP

Физически промени в сградата (ако решите за кабина/офис)

Физическо разширяване или свиване на офис пространството вътре в сграда.

Използвайте анализ и отстраняване на неизправности

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

анализ на качеството на медиите

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

отстраняване на проблеми с качеството на медиите

Отстраняването на неизправности може да се интегрира и с други продукти на Cisco като превключватели ThousandEyes и Meraki, за да осигури още по-богато интегрирано изживяване в Control Hub. За повече информация относно използването на Webex Callingанализи и отстраняване на неиз правности вижте Отстраняване на неизправности Webex Calling при повиквания в Control Hub.

Въведение

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

Общ преглед

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

Преглед на процеса на PPPIO

Общо описание на PPDIO

Използване на PPPIO за проекти за миграция от 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

Поддържани крайни точки за извикване

Опции за свързване на PSTN

Управление на план за набиране и номера на Webex Calling

Функции за сигурност и съответствие.

За повече информация вижте Предпочитана архитектура на Cisco за Webex Calling.

Това ръководство ще подчертае инструментите и процесите, които да се използват през целия жизнен цикъл на прехода. Преходът от локални разговори, 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 (business-to-business) edge услуги, Cisco Meeting Server. / Cisco Meeting Management за локална конференция, Unity Connection за гласови съобщения и хардуерни (Cisco IP телефони, Cisco Desk and Room video systems) и софтуерни (Cisco Jabber) IP-базирани крайни точки, насочени към потребителя. Тези компоненти може леко да се различават в някои среди, но това е отправната точка за прехода, описан в останалата част от този документ.

Архитектура за сътрудничество на място: управление на повиквания и отдалечен достъп

Архитектурата, показана на Фигура Архитектура за локално сътрудничество: Контролът на повикванията и отдалеченият достъп се базира на предпочитаната архитектура (PA) за локални внедрявания на Cisco Collaboration Enterprise. За повече информация относно локалната корпоративна среда вижте предпочитаните архитектури за сътрудничество на Cisco.

Преди: Таблицата „Компоненти на локалната инфраструктура за повиквания “ изброява ключовите елементи на локалната архитектура преди преминаването към Webex Calling в облака.

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

Unified CM Локален контрол на повикванията, предоставящ услуги за регистрация на устройства и маршрутизиране на повиквания

Сиско Expressway-C/E Крайна инфраструктура, осигуряваща мобилен и отдалечен достъп (MRA) и функционалност „бизнес към бизнес“ (B2B), позволяваща на отдалечени крайни точки да се свързват сигурно отвън организацията. Expressway се разполага по двойки, за да осигури преминаване през защитната стена за външни крайни точки.

Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) и Cisco Telepresence Management Suite (TMS) Локална инфраструктура за гласови, видео и уеб конференции, осигуряваща многоточкови срещи, управление на срещи и възможности за планиране. [Optional]

Връзка към единица на Cisco Локална платформа за гласови съобщения, предоставяща възможности за гласова поща и унифицирани съобщения. [Optional]

Cisco Desk, Cisco Room, Cisco Board, Cisco IP телефони и 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 за интеграция на самоличност и Local Gateway (LGW) за PSTN достъп, както и интеграция на локални към облачни обаждания. Допълнителни опции за достъп до PSTN са плановете на Cisco за обаждания или свързаната с облака PSTN (CCP), осъществявана от партньор на Cloud Connect за Webex Calling.

Както е показано на Фигура След: Архитектура на Webex Calling, новите компоненти (Webex Calling, Directory connector, Local gateway и Survivability gateway) се добавят към съществуващото локално внедряване.

След: Архитектура за извиквания на Webex

След: Таблицата „Компоненти на инфраструктурата за облачни разговори “ изброява новите елементи на архитектурата след прехода към Webex.

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

Webex Calling Облачна услуга за обаждания, предоставяна от платформата Webex и осигуряваща регистрация на крайни точки и маршрутизиране на обаждания

Cisco Directory Connector Приложение за 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 Software и различни сертифицирани Session Border Controllers (SBC) на трети страни могат да се използват като LGW за поетапен подход на миграция.

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

План за обаждания на Cisco, Cloud Connect за Webex Calling Cisco Calling Plan и Cloud Connect за Webex Calling са облачни опции за PSTN достъп за крайни точки на Webex Calling. Достъпът до PSTN се осъществява от доставчик на облачна PSTN услуга и не изисква локално оборудване.

Приложение Webex Клиентско приложение, работещо на настолна операционна система (Windows, Mac) или мобилна операционна система (Android, iOS) и регистрирано директно към платформата Webex Calling за функционалност за обаждания.

Преглед на процеса на PPPIO

Процесът PPDIO означава Подготовка, Планиране, Проектиране, Внедряване и Оптимизиране. Това е структурирана методология на Cisco, която ръководи проектите от първоначалната оценка до непрекъснатото им усъвършенстване, осигурявайки ефикасни и успешни внедрявания или миграции.

PPDIO процес

Общо описание на PPDIO

Подгответе: Оценете текущата среда, съберете изискванията и съгласувайте заинтересованите страни, за да изградите солидна основа.

План: Разработете подробни планове за проекти, включително срокове, ресурси и стратегии за смекчаване на риска.

Дизайн: Проектирайте целевото решение, съобразено с бизнес и техническите нужди.

Прилагане: Изпълнете внедряването или миграцията съгласно проекта, като валидирате функционалността и производителността.

Оптимизиране: Непрекъснато подобрявайте решението след внедряването му, като наблюдавате производителността, усъвършенствате конфигурациите и използвате инструменти за автоматизация и интеграция.

Използване на PPPIO за проекти за миграция от Unified CM към Webex Calling

При преминаване от Unified CM към Webex Calling, процесът PPPIO предоставя ясна пътна карта, за да се осигури плавен и ефикасен преход:

Подготовка

Оценка на съществуващата унифицирана среда за управление на комуникациите (Unified CM) и готовността за миграция

Събирайте подробни данни за потребители, устройства, мрежа и зависимости

Събиране на данни за местоположението, включително адрес за спешни случаи, брой потребители, достъп до интернет, достъп до PSTN

Идентифицирайте рисковете и дефинирайте обхвата на проекта, за да съгласувате действията на всички заинтересовани страни.

Планиране

Създайте подробен план за миграция с графици за партиди, разпределение на ресурси и срокове

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

Координирайте прозорците за миграция с Cisco и партньорите, за да сведете до минимум прекъсванията.

Проектиране

Съпоставяне на текущите конфигурации, планове за набиране и потребителски профили на Unified CM с еквиваленти на Webex Calling

Проектиране на средата за обаждания на Webex, включително стратегия за PSTN (междинна и окончателна), местоположения, потребителски роли и точки на интеграция, като например локален шлюз (CUBE) и синхронизация на директории

Планирайте сценарии за съвместно съществуване, при които Unified CM и Webex Calling работят едновременно по време на миграция.

Внедряване

Използвайте инструментите за миграция на Control Hub, заедно с инструменти на трети страни, за да извършвате промени в режима на фърмуера на устройството, конфигуриране на функции и миграции на потребители.

Използвайте групови операции и осигуряване, използвайки Webex API, за да рационализирате мащабни миграции и конфигурации

Извършване на осигуряване на лицензи, регистрация на устройства и актуализации на конфигурацията

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

Оптимизиране

Непрекъснато наблюдавайте производителността и потребителското изживяване на Webex Calling

Усъвършенствайте конфигурациите и работните процеси въз основа на оперативни данни и обратна връзка

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

Деактивирайте наследените компоненти на Unified CM, когато е необходимо, и осигурете текуща поддръжка за операциите през втория ден.

Този подобрен PPPDIO подход осигурява контролирана, прозрачна и ефикасна миграция от Unified CM към Webex Calling, използвайки инструментите, API и партньорската екосистема на Cisco, за да се поддържа непрекъснатостта на бизнеса и да се подобрят възможностите за сътрудничество.

PPDIO обратни връзки

Общият преглед, изобразен на Фигура Итерации по време на изпълнение на PPPDIO, илюстрира един цикъл на обратна връзка от фазата оптимизиране обратно към фазата подготовка. Това означава, че след първоначалното внедряване има възможност за непрекъснато подобрение. Всеки цикъл на оптимизация може да идентифицира нови изисквания или области за подобрение, които могат да бъдат разгледани чрез последващи проекти или инициативи. Тези отделни проекти, от своя страна, следват установения жизнен цикъл на PPPIO (Подготовка, Планиране, Проектиране, Внедряване, Оптимизиране). Този итеративен подход гарантира, че системата остава съобразена с развиващите се бизнес цели и технологичния напредък, насърчавайки култура на непрекъснато усъвършенстване и адаптивност.

Итерации при изпълнение на PPPIO

По време на изпълнението на процеса PPPDIO е обичайно констатациите в по-късните фази да налагат преразглеждане и евентуално преразглеждане на решения, взети на по-ранни етапи. Например, проблеми, възникнали по време на фазата на внедряване, като например идентифициране на неясноти в дизайна или липсващи детайли, могат да разкрият, че определени аспекти не са били напълно разгледани по време на фазата на проектиране. В такива случаи е необходимо да се върнете към съответния по-ранен етап, за да разрешите тези проблеми, преди да продължите. Този итеративен механизъм за обратна връзка, както е илюстрирано на Фигура , Унифициран процес на PPPIO, подпомаган от CM, гарантира, че решението е щателно валидирано и усъвършенствано, което в крайна сметка допринася за по-стабилно и ефективно внедряване.

Унифициран процес на PPPIO, подпомаган от CM

При преход от Unified CM към Webex Calling, всяка фаза от процеса PPPDIO може да се възползва значително от информацията, събрана от съществуващата среда на Unified CM. Например, от текущата конфигурация на Unified CM могат да бъдат извлечени подробни инвентаризации на потребители, телефонни номера, функции за обаждания и компоненти на план за набиране. Тези данни допълват информацията, предоставена директно от заинтересованите страни, и спомагат за рационализиране на дейностите по планиране и проектиране. Използването на подходящи инструменти за автоматизиране на извличането и анализа на данни не само повишава точността, но и ускорява цялостния процес. Чрез използване на анализи от съществуващото внедряване, преходът към Webex Calling може да се осъществи по-ефективно от традиционното внедряване на зелено, като същевременно се спазва структурираната PPPDIO методология. Този процес е илюстриран на Фигура Унифициран процес на PPPIO, подпомаган от CM.

Миграционен подход

Докато планирате прехода си от локалната система Unified CM към Webex Calling, трябва да определите как ще подходите към това пътуване. Първо ще трябва да решите дали миграцията ще бъде бързократна (всичко наведнъж) или поетапна (мигриране на групи от users/devices за продължителен период).

Извършването на светкавична миграция премества всички ваши потребители и устройства най-бързо. С този метод ще преместите всички потребители и устройства от локалния Unified CM към Webex Calling едновременно. По същество това е един-единствен прозорец за миграция за всички потребители и устройства. След като тази миграция приключи, всички ваши потребители и устройства ще бъдат на платформата Webex Calling и цялата ви инфраструктура на Unified CM може да бъде изведена от експлоатация. Въпреки това, много организации не могат да използват този подход поради мащаба и размера на внедряването на техните обаждания.

Вторият подход е поетапна миграция. Повечето организации ще използват този подход, тъй като той осигурява по-добър контрол, управление и мащабиране при миграцията. Също така е по-подходящ за по-големи UC внедрявания. and/or внедрявания в множество региони. Следователно, този документ се фокусира върху поетапния подход с две стъпки в прехода.

Както е показано на фигура по-долу: Фазов преход на повикване Хибрид и облак, първата преходна фаза (Фаза 1) води до съвместно внедряване с двойни среди за извиквания. В тази фаза някои потребители, устройства и софтуерни клиенти преминават към Webex Calling, докато други все още са на локалния Unified CM контрол на повикванията. Последната преходна фаза (Фаза 2) води до чисто облачна среда за обаждания, където всички потребители, устройства и софтуерни клиенти са напълно прехвърлени към платформата Webex Calling.

Колко време отнема на една организация да премине напълно към облачни обаждания, ще варира в зависимост от текущото ѝ внедряване. В някои случаи организацията може да направи първоначалния преход и да остане във фазата на съвместно съществуване на двоен контрол на повикванията (Фаза 1) за продължителен период (месеци или дори години), докато в други случаи организацията може напълно да премине към Webex Calling (Фаза 2) за много кратък период (седмици или месеци). Този документ е предназначен да обхване и двете фази (Фаза 1 - съвместно съществуване и Фаза 2 - пълен преход).

Поетапен преход на повикванията: хибридни и облачни

Възможно е някои организации да поддържат едновременно внедряване на двоен контрол на повикванията за неопределено време, без планове за пълен преход към облачни повиквания.

Второто съображение е как ще прехвърлите потребители, устройства и софтуерни клиенти от локалния контрол на повикванията към облачния контрол на повикванията. Препоръчителният подход е 3-фазен преход. Фигурата Препоръчителен 3-фазов преход по-долу разделя този подход на 3 фази.

Препоръчителен 3-фазен преход

Преди миграция: Тази фаза се фокусира върху подготовката на средите Webex и Unified CM за миграцията. Не става въпрос за извикване на специфично планиране или конфигурации, а за фокусиране върху завършване на дейности, които могат да бъдат извършени сега и преди началото на какъвто и да е проект за миграция на Webex Calling. Целта е да се изгради основата за двете среди, за да се подготвят за миграцията.

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

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

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

Фигура Дейности преди миграция по-долу показва пет специфични категории дейности, свързани с миграция на Webex Calling.

Дейности преди миграцията

Таблица 2. След: Компоненти на инфраструктурата за облачни разговори
Продукт	Описание
Webex Calling	Облачна услуга за обаждания, предоставяна от платформата Webex и осигуряваща регистрация на крайни точки и маршрутизиране на обаждания
Cisco Directory Connector	Приложение за 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 Software и различни сертифицирани Session Border Controllers (SBC) на трети страни могат да се използват като LGW за поетапен подход на миграция.
Шлюз за запазване на комуникацията	Survivability Gateway (SGW) е локален мрежов шлюз, базиран на IOS-XE, който предоставя резервни услуги за повиквания към локални крайни точки на Webex Calling по време на прекъсвания на мрежата.
План за обаждания на Cisco, 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 и бизнес приложения: Идентифициране на точки на интеграция със системи за управление на взаимоотношенията с клиенти и други критични за бизнеса приложения.

Взаимодействие със стари PBX системи: Планиране на стратегии за съвместно съществуване или поетапна миграция, ако по време на прехода ще останат някакви стари телефонни системи.

Съвместимост и осигуряване на крайни точки

Всички крайни устройства, включително настолни телефони, софтфони и мобилни устройства, трябва да бъдат оценени за съвместимост:

Поддръжка на устройства: Потвърждаване, че съществуващите IP телефони и устройства се поддържат или идентифициране на необходимите замени.

Процеси на осигуряване: Установяване на автоматизирани или рационализирани методи за осигуряване за ефективно внедряване на крайни точки.

Актуализации на фърмуера и софтуера: Планиране на необходимите актуализации за осигуряване на оперативна съвместимост и сигурност.

Конфигурации за сигурност и стандарти за криптиране

Сигурността е от първостепенно значение в облачните комуникации:

Криптиране: Прилагане на цялостно криптиране за сигнализация и медийни потоци, в съответствие с най-добрите практики за сигурност на Cisco.

Удостоверяване и контрол на достъпа: Внедряване на защитени механизми за удостоверяване (като SSO, многофакторно удостоверяване) и подробен контрол на потребителския достъп.

Съответствие: Осигуряване на съответствие между решението и съответните регулаторни и индустриални стандарти (например, GDPR, HIPAA).

Мониторинг на сигурността: Интегриране със SIEM инструменти и настройване на предупреждения за потенциални инциденти със сигурността.

Таблица 1. Примерна оценка
Изискване Ключови съображения

Готовност на мрежата и честотна лента Честотна лента, QoS, WAN/Internet, Firewall/NAT

Интеграция със съществуващи системи Директория, CRM, PBX, Email/Calendar

Съвместимост и осигуряване на крайни точки Поддръжка на устройства, осигуряване, актуализации на фърмуера

Конфигурации за сигурност и криптиране Криптиране, удостоверяване, съответствие, наблюдение на сигурността

Обучение на потребителите и управление на промените Програми за обучение, документация, комуникация на промените

Преносимост на номера и план за набиране Номер migration/porting, превод на план за набиране

Интеграции с трети страни Пейджинг, контакт център, факс, аналогови устройства

Готовност и изисквания за мрежата

Готовността за мрежа е от решаващо значение за успешната миграция към всяко облачно решение за обаждания, като например . Лошото мрежово планиране може да доведе до влошено качество на разговорите, прекъсване на повикванията и недоволство на потребителите. Клиентите трябва да извършат оценка на мрежата, преди да мигрират към . Препоръчително е да се потвърди наличността на мрежова честотна лента за очаквания обем на повикванията, да се гарантира, че са изпълнени изискванията за качество на услугата (QoS) и да се разберат различните портове, които трябва да бъдат отворени в граничната(ите) защитна(и) стена(и).

Надеждната мрежова свързаност с достатъчно качество на услугата (честотна лента, загуба на пакети, RTT) е основно изискване за осигуряване на възможно най-доброто потребителско изживяване от край до край за всички крайни точки, клиенти и приложения, използващи .

Клиентите и партньорите имат опции за свързване на достъп отвъд Over-the-top (OTT) интернет, които могат да оптимизират връзката, включително Webex Edge Connect. За повече информация относно детайлите на дизайна на Webex Edge Connect вижте Предпочитана архитектура на Cisco за Webex Edge Connect за Webex Meetings, извиквания на многонаематели и специализирани инстанции.

Клиентите могат да използват CScan за оценка на мрежата, която дава информация за качеството на мрежата на клиента, колко повиквания могат да бъдат осъществени, латентността и т.н. За повече информация относно инструмента CScan вижте Използване на CScan за тестване на качеството на мрежата Webex Calling.

За да сте сигурни, че мрежата е готова за миграция към , разгледайте следния контролен списък:

Планиране на честотната лента

Изчислете едновременните повиквания за всеки сайт, за да сте сигурни, че имате достатъчно честотна лента за обратна връзка (upstream) и обратна връзка (downstream) и включете резервен капацитет за друг критичен за бизнеса трафик и бъдещ растеж.

Таблицата Изчисления на честотната лента за типове повиквания на Webex Calling показва типовете повиквания, налични с внедряване, заедно с кодека и максималната честотна лента, необходима за всеки тип повикване. Както е показано в таблицата изчисления на честотната лента за типове повиквания на Webex Calling, необходимата честотна лента за аудио повиквания за всеки тип повикване може да се изчисли по следната обща формула:

Брой очаквани едновременни повиквания * Пропускателна способност на повикване въз основа на кодек = Необходима мрежова пропускателна способност.
Таблица 2. Изчисления на честотната лента за типовете повиквания на Webex Calling
Видове обаждания Кодек - честотна лента Изчисления на честотната лента
/ Стационарен телефон -> OPUS - 70 kbps Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> Стационарен телефон OPUS – 70 kbps Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> PSTN чрез LGW G.711 – 80 kbps Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> PSTN чрез Cloud PSTN (напр. план за обаждания на Cisco) G.711 – 80 kbps Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> Предприятие чрез LGW G.722 – 80 kbps Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> гласова поща OPUS – 70 kbps Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност

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

Всички канали за повикване винаги са закотвени към SBC за достъп. За да се определи необходимата интернет честотна лента за дадено местоположение, трябва да се вземат предвид не само междулокационните повиквания, но и вътрешнолокационните повиквания, както и повикванията към и от локален шлюз на това местоположение. Например, вътрешнофирмен разговор между два MPP телефона ще изисква до 2 x 70 kbps пълен дуплекс за интернет достъпа на местоположението.

Таблицата с примери за изчисляване на честотна лента за Webex Calling показва пример за пълно упражнение за изчисляване на честотна лента, като се приема, че всички устройства са в едно и също място.
Таблица 3. Примери за изчисляване на честотна лента за Webex Calling
Видове обаждания Брой едновременни разговори Обща честотна лента
Приложението Webex / Настолен телефон → Приложение Webex 15 2 * 15 * 70 kbps = 2100 kbps
Приложението Webex / Стационарен телефон → Стационарен телефон 15 2 * 15 * 70 kbps = 2100 kbps
Приложението Webex / Стационарен телефон → PSTN чрез LGW 50 2 * 50 * 80 kbps = 8 000 kbps
Приложението Webex / Настолен телефон → PSTN чрез Cloud Connect за Webex Calling 0 0 * 80 Kbps
Приложението Webex / Стационарен телефон → Корпоративен телефон чрез LGW 15 2 * 15 * 80 kbps = 2400 kbps
Приложението Webex / Стационарен телефон → Webex Calling Гласова поща 5 5 * 70 kbps = 350 kbps
Общо обаждания / Пропускателна способност 100 обаждания 14 950 kbps / 14,95 Мбит/с

Всички стойности на честотната лента в горните таблици се отнасят за IP честотна лента. Пропускателната способност на връзката е по-висока в зависимост от WAN капсулациите.

Пропускателната способност в горните таблици е за аудио разговори. За честотна лента за видео разговори, приложението Webex и MPP 8845/65 Телефоните поддържат H.264 видео с максимална резолюция 720p при максимална честотна лента от 1500 kbps на разговор. Въпреки това, количеството консумирана честотна лента във всеки един момент по време на разговора ще се колебае въз основа на променливата битрейт, присъща на видео комуникациите.

Качество на услугата (QoS)

Внедрете QoS политики във вашата локална среда, за да приоритизирате трафика в реално време и да гарантирате, че QoS се поддържа в комутатори, рутери и защитни стени.

Цели за латентност, трептене и загуба на пакети

Следните прагове се препоръчват за оптимално качество на гласа, когато разговорите се осъществяват през Over-the-Top (OTT) мрежа и през интернет:

Латентност - по-малко от 100ms в едната посока

Трептене - по-малко от 10ms

Загуба на пакети - 0,5% или по-малко.

Защитна стена и NAT

Уверете се, че защитната стена е конфигурирана да разрешава трафик, както е посочено в статията, достъпна на Информация за портове за Webex Calling. Освен това, разрешете достъп до домейни и 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.

Потребители и устройства

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

Локален шлюз

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

Locations/Sites

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

Друго важно съображение за внедряване при прехода към е наличността на местоположение. има различни възможности, абонаменти и устройства, които са налични в зависимост от това къде се намира вашето внедряване. За повече информация относно географската наличност вижте Къде е наличен Webex?.

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

Съществуваща инвентаризация devices/clients

Преди да започнете прехода, е важно да направите инвентаризация на съществуващите хардуерни и софтуерни крайни точки. Наличие на пълен списък с устройства types/models, Версиите на хардуера, типовете операционни системи на софтуерните клиенти и количествата ще гарантират, че можете адекватно да планирате прехода на устройствата и да смекчите въздействието върху онези устройства, които не могат да бъдат мигрирани към облачни разговори. Инвентаризацията трябва да се използва за определяне на устройствата за преход и устройствата за подмяна преди прехода.

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

За аудио и видео настолни телефони се поддържат само настолните телефони от сериите 6800, 7800, 8800 и 9800. Това е подмножество от IP телефоните на Cisco, които се поддържат с . Има някои модели и версии на телефоните 6800, 7800 и 8800, които не могат да се използват с . За повече информация относно поддържаните модели и версии на хардуера вижте Поддържани устройства за Webex Calling.

IP телефоните от серията Cisco 6800 не могат да бъдат надстроени от фърмуер за предприятия до фърмуер за мултиплатформени (MPP) версии, който е необходим за . Следователно, всички телефони 6800, регистрирани за работа с корпоративен фърмуер, трябва да бъдат заменени с модел 6800 MPP или с друг поддържан модел телефон.

IP телефоните Cisco от серията 7800 и 8800 трябва да бъдат надстроени до фърмуера за многоплатформени телефони (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 към . Всяка от тези крайни точки, която трябва да генерира аудио and/or PSTN разговорите изискват лиценз за обаждания:

Споделените устройства в конферентни зали, пространства за срещи и др. изискват лиценз за Professional Workspace или Workspace.

Личното устройство на крайния потребител изисква професионален или стандартен лиценз.

Определете колко видео крайни точки са регистрирани и се използват за осъществяване на аудио повиквания. Възможно е някои от крайните точки за видео да се използват само за присъединяване към срещи или за осъществяване на SIP видео разговори. И в двата случая крайните точки все още трябва да мигрират, преди сървърите да бъдат изведени от експлоатация, но това ще помогне да се определи колко от тях ще се нуждаят от лицензи, за да продължат да осъществяват телефонни разговори.

Когато видеоустройствата бъдат преместени от регистрация към , URI адресът за тези крайни точки ще се промени, тъй като те вече са регистрирани в облака.

Моделите телефони 8845, 8865 и 8875 са лични видеотелефони, които се поддържат с .

Софт клиенти

Това е единственият софтуерен клиент, поддържан от , за разлика от Unified CM, който поддържа както приложението Webex, така и Jabber, и е новият софтуерен клиент по подразбиране за крайните потребители.

В зависимост от режима(ите) на внедряване, внедрени за Jabber (само за IM, само за телефон, 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. Унифицираните CM телефони използват фърмуера Enterprise, докато телефоните работят с фърмуера Multiplatform Phone (MPP). Препоръчително е да проверите кои регистрирани телефони отговарят на условията за надграждане до фърмуера на MPP по време на фазата на подготовка. Това ви дава време да замените неподходящите телефони с един от поддържаните модели телефони или да определите алтернативен план, като например преместване на потребител само към приложението Webex.

За да ви помогне да определите дали телефоните отговарят на условията, Control Hub има вграден инструмент, наречен Мигриране на телефона ви към 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 и др.). Тъй като потребителите мигрират към (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.

Можете да прегледате конфигурацията (GUI или експорт) или да използвате инструмента 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 ms, а трептенето трябва да е по-малко от 10 ms, докато загубата на пакети е по-малка от 0,5 %.

Характеристики & използване на функции

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

За да определите кои функции са конфигурирани, анализирайте конфигурацията. Това са всички статични данни, които се задават, когато функция или настройка е конфигурирана в системата. Следните опции могат да се използват за завършване на този анализ:

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

експорт на конфигурация -- групов експорт или AXL

инструмент за анализ на миграцията (препоръчително)

Инструменти на партньори на трети страни на Cisco (препоръчително).

За да се анализира ефективно използването на функциите, е важно да се изследват динамични системни данни, като например използване, регистрации и активност на повикванията. Различни аналитични инструменти и табла за управление предоставят информация за тези показатели, позволявайки цялостно разбиране на производителността и капацитета на системата, което подпомага вземането на информирани решения по време на миграция и оптимизация. Следните опции могат да се използват за завършване на този тип анализ:

Преглед на суровите CDR записи

Преглед на данните от Unified CM RTMT

Инструмент за анализ на миграцията, използващ CDR данни

Преглед на анализите на свързаните с облака UC в

Силата на звука на разговорите

Регистрирани крайни точки

(CAC) местоположения

Използване на багажника.

Инструменти на партньори на трети страни на Cisco.

Cisco препоръчва да започнете с инструмента Webex Control Hub Migration Insights за този анализ. Ще импортирате експортирания .TAR файл и Unified CM CDR файловете (по избор, но задължителни за анализ на използването на функции) в инструмента. Инструментът ще генерира следните CSV-базирани отчети, които могат да се използват за стартиране на анализа:

Таблица 5. Отчети, генерирани от .tar файл на Unified CM
Име на отчета
Описание на отчета
ImportedDataBulk.csv
Всички потребители и устройства от данни на Unified CM
DeviceEligibility.csv
Идентифицира устройства, отговарящи на условията за мигриране към Webex Calling (IP телефони, устройства с Room OS, ATA и устройства на трети страни)
DevicePoolNumbers.txt
Списък с всички номера в определен пул от устройства
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Подробности за устройствата и потребителите, които трябва да бъдат мигрирани заедно въз основа на споделени линии, пилот за търсене, опашка за повиквания, паркиране на повиквания и конфигурация на група за приемане на повиквания
HuntGroupMigrationInsight.csv
Подробна информация за назначените линии за търсене, групи линии и свързани агенти
SharedlineGroupMigrationReport.csv
Общ преглед на това как телефонните номера (номера от указателя) се споделят между потребителите

Таблица 6. Отчети, генерирани от .tar и CDR.gzip файлове на Unified CM
Име на отчета
Описание на отчета
FeatureUsageBasedDeviceEligibilityReport.csv
Информация относно допустимостта за мигриране на устройства въз основа на използването на функции
FeatureUsageWithLastUsageDateReport.csv
Брой на използваните данни за броя пъти, в които са били извикани пилот(и) за търсене и опашка(и) за повиквания, заедно с датата на последно използване.
UserWorkspaceLastUsage.csv
Дата на последно използване за потребители и работни пространства както за софтуерни клиенти, така и за твърди телефони
DIDUsageReport.csv
Използване на DID както за назначени, така и за неприсвоени DID

За повече подробности относно отчетите „Информация за миграцията“ вижте „Информация за миграцията“.

Ако се нуждаете от повече информация за функциите и употребата, след като прегледате информацията в отчетите „Migration Insights“, Cisco препоръчва да обмислите един от инструментите за миграция на трети страни-партньори на Cisco. and/or за да прегледате конфигурациите в графичния потребителски интерфейс или в данните за експортиране на конфигурацията.

Cisco интеграции: Unity Connection UCCX UCCE

Гласовата поща е неразделна част от офертата и е вградена в решението. Не може да се интегрира с решение за гласова поща, базирано на място, като Unity Connection или Unity Connection Express. Освен това, няма вграден начин за мигриране на съществуващи гласови съобщения или поздрави от Unity връзка към вградената услуга за гласова поща, налична с . Някои от инструментите за миграция на трети страни-партньори на Cisco имат възможности за мигриране на част от тези данни. За повече информация относно гласовата поща за , вижте Конфигуриране и управление на настройките за гласова поща за потребител на Webex Calling.

също така поддържа споделени пощенски кутии за гласова поща и факс. За повече информация вижте Управление на споделена гласова поща и кутия за входящи факсове за Webex Calling.

има вградена функция за автоматичен оператор, която е включена като част от основната платформа. Тази функция позволява прехода на обработчиците на повиквания и функционалността за автоматичен оператор на вашата Unity Connection. Инструментът Control Hub, „Миграция на функции от Unified CM“, поддържа мигриране на конфигурациите на Unity Connection към автоматични оператори. За повече информация относно използването на този инструмент вижте Миграция на устройства и функции от Unified CM към Webex Calling.

Записване на повикване

включва две опции за запис на разговори без допълнително заплащане.

Запис на разговори в Webex

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

включени опции за запис таблицата подчертава някои ключови характеристики на двете опции за запис на разговори, които са налични без допълнително заплащане.

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

Достъпно за всички потребители Достъпно за всички потребители

Неограничени записи Неограничени записи

1-годишен период на съхранение* 30-дневен период на съхранение

100 GB място за съхранение на организация -

Служителите по съответствието могат да имат достъп и да управляват записи на разговори -

API за управление на записи -

Администраторите могат да конфигурират и управляват достъпа на потребителите до записите на техните разговори
Потребителите могат да управляват собствените си записи, използвайки User Hub and/or приложението Webex.
Само потребителите могат да имат достъп до своите записи и да ги управляват
От техния дублиращ портал.

Ако вашата организация изисква допълнителни възможности за запис, като например запис на обаждания за съответствие, по-дълги периоди на съхранение, повече място за съхранение, анализ с изкуствен интелект, and/or администраторски достъп, платени оферти или добавки съществуват както от Cisco, така и от доставчици на записи от трети страни. За повече информация относно доставчиците на запис, конфигурациите и допълнителните партньорски услуги вижте Управление на записа на разговори за Webex Calling.

Интеграции с трети страни

поддържа различни интеграции с трети страни, включително, но не само, SBC за локални шлюзове, IP телефони, интерком телефони, Speaker/Pagers, ATA и др. В допълнение към тези устройства на^трети страни , Webex Calling поддържа различни решения на^трети страни за поддръжка на клиенти, анализи, записване, фактуриране и др. За повече информация относно решения на трети^страни вижте Webex App Hub.

Таблица 1. Примерна оценка
Изискване	Ключови съображения
Готовност на мрежата и честотна лента	Честотна лента, QoS, WAN/Internet, Firewall/NAT
Интеграция със съществуващи системи	Директория, CRM, PBX, Email/Calendar
Съвместимост и осигуряване на крайни точки	Поддръжка на устройства, осигуряване, актуализации на фърмуера
Конфигурации за сигурност и криптиране	Криптиране, удостоверяване, съответствие, наблюдение на сигурността
Обучение на потребителите и управление на промените	Програми за обучение, документация, комуникация на промените
Преносимост на номера и план за набиране	Номер migration/porting, превод на план за набиране
Интеграции с трети страни	Пейджинг, контакт център, факс, аналогови устройства

Таблица 2. Изчисления на честотната лента за типовете повиквания на Webex Calling
Видове обаждания	Кодек - честотна лента	Изчисления на честотната лента
/ Стационарен телефон ->	OPUS - 70 kbps	Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> Стационарен телефон	OPUS – 70 kbps	Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> PSTN чрез LGW	G.711 – 80 kbps	Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> PSTN чрез Cloud PSTN (напр. план за обаждания на Cisco)	G.711 – 80 kbps	Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> Предприятие чрез LGW	G.722 – 80 kbps	Брой едновременни разговори * 80 kbps = Необходима мрежова пропускателна способност
/ Стационарен телефон -> гласова поща	OPUS – 70 kbps	Брой едновременни разговори * 70 kbps = Необходима мрежова пропускателна способност

Таблица 3. Примери за изчисляване на честотна лента за Webex Calling
Видове обаждания	Брой едновременни разговори	Обща честотна лента
Приложението Webex / Настолен телефон → Приложение Webex	15	2 * 15 * 70 kbps = 2100 kbps
Приложението Webex / Стационарен телефон → Стационарен телефон	15	2 * 15 * 70 kbps = 2100 kbps
Приложението Webex / Стационарен телефон → PSTN чрез LGW	50	2 * 50 * 80 kbps = 8 000 kbps
Приложението Webex / Настолен телефон → PSTN чрез Cloud Connect за Webex Calling	0	0 * 80 Kbps
Приложението Webex / Стационарен телефон → Корпоративен телефон чрез LGW	15	2 * 15 * 80 kbps = 2400 kbps
Приложението Webex / Стационарен телефон → Webex Calling Гласова поща	5	5 * 70 kbps = 350 kbps
Общо обаждания / Пропускателна способност	100 обаждания	14 950 kbps / 14,95 Мбит/с

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

Таблица 5. Отчети, генерирани от .tar файл на Unified CM
Име на отчета Описание на отчета
ImportedDataBulk.csv Всички потребители и устройства от данни на Unified CM
DeviceEligibility.csv Идентифицира устройства, отговарящи на условията за мигриране към Webex Calling (IP телефони, устройства с Room OS, ATA и устройства на трети страни)
DevicePoolNumbers.txt Списък с всички номера в определен пул от устройства
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробности за устройствата и потребителите, които трябва да бъдат мигрирани заедно въз основа на споделени линии, пилот за търсене, опашка за повиквания, паркиране на повиквания и конфигурация на група за приемане на повиквания
HuntGroupMigrationInsight.csv Подробна информация за назначените линии за търсене, групи линии и свързани агенти
SharedlineGroupMigrationReport.csv Общ преглед на това как телефонните номера (номера от указателя) се споделят между потребителите

Таблица 6. Отчети, генерирани от .tar и CDR.gzip файлове на Unified CM
Име на отчета Описание на отчета
FeatureUsageBasedDeviceEligibilityReport.csv Информация относно допустимостта за мигриране на устройства въз основа на използването на функции
FeatureUsageWithLastUsageDateReport.csv Брой на използваните данни за броя пъти, в които са били извикани пилот(и) за търсене и опашка(и) за повиквания, заедно с датата на последно използване.
UserWorkspaceLastUsage.csv Дата на последно използване за потребители и работни пространства както за софтуерни клиенти, така и за твърди телефони
DIDUsageReport.csv Използване на DID както за назначени, така и за неприсвоени DID

Таблица 7. включени опции за запис
Webex	Дъбър Гоу
Достъпно за всички потребители	Достъпно за всички потребители
Неограничени записи	Неограничени записи
1-годишен период на съхранение*	30-дневен период на съхранение
100 GB място за съхранение на организация	-
Служителите по съответствието могат да имат достъп и да управляват записи на разговори	-
API за управление на записи	-
Администраторите могат да конфигурират и управляват достъпа на потребителите до записите на техните разговори Потребителите могат да управляват собствените си записи, използвайки User Hub 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 App, локалната инфраструктура не се променя и работи по същия начин, както Jabber. Единствената промяна е, че изисква връзка към .

За повече информация относно този преход вижте Карта за преход от Jabber към Webex и ръководство за внедряване в раздела „Клиент“ на страницата Преход за сътрудничество.

Карта на прехода на високо ниво от Unified CM към Webex Calling фигурата показва прехода на високо ниво от към . Това е стъпка 2 от препоръчаното пътуване.

Унифицирана карта за преход на високо ниво от 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. Опростено потребителско изживяване

Duo MFA с SSO за

Функции

Автоматичен оператор

Прехвърляне на повикване

Поемане на повиквания

Опашка на повикванията

Група за търсене

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

Група за пейджинг

Записи

Свързване с един номер

Група за гласова поща

Избор на регион

е достъпен в световен мащаб и се доставя от резервирани центрове за данни в множество региони: САЩ (Далас, Чикаго), Канада (Ванкувър, Торонто), Европа (Франкфурт, Амстердам), Великобритания (Лондон, Манчестър), Австралия (Мелбърн, Сидни), Япония (Токио, Осака), Саудитска Арабия (Рияд, Джеда) и Индия (Мумбай, Ченай). Медийните PoP предоставят медийни услуги за оптимизиране на времето за комуникация с медиите. Например, центърът за данни в Сингапур се използва за оптимизиране на времето за доставка на медийни файлове за клиенти в азиатски страни, където времето за доставка до Австралия или Япония може да е неоптимално. Центровете за данни са свързани помежду си чрез многогигабитова и напълно резервирана гръбначна мрежа. Фигурата глобално разпределени центрове за данни показва общ преглед на всички центрове за данни. За най-актуалния списък с наличните центрове за данни вижте Местоположения на центрове за данни за Webex Calling.

Глобално разпределени центрове за данни

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

За наличност в различните държави вижте Къде е наличен Webex?.

Местоположения

За да се подготви предоставянето на местоположения, е необходимо да се събере необходимата информация за всички целеви местоположения на миграцията. Необходимата информация за всяко местоположение е обобщена в Информация за събиране за всяко местоположение.
Таблица 1. Информация за събиране за всяко местоположение
Информация Коментар
Диапазон(и) на разширение Всяко местоположение може да има разширения, започващи с различни цифри. Една цифра трябва да бъде запазена за управляващата цифра за набиране между обектите (например 8) и една за управляващата цифра за PSTN (например 9). Никой диапазон на разширение не може да започва с нито една от тези две цифри.
Всички диапазони на разширение на всички местоположения трябва да са с еднаква дължина.
Диапазон(и) на DID -
PSTN управляваща цифра -
Код на сайта Всички кодове на сайтове на всички местоположения трябва да са уникални и да имат еднаква дължина.
Главен номер При създаване на местоположение е необходимо да се осигурят два DID-а. Един като основен номер (например, за да бъде присвоен на услуга за автоматичен оператор) и един за портала за гласова поща.
Осигурете един DID за номера на гласова поща.
Номер на гласова поща
Брой лицензи Необходими лицензи по тип, включително Стандартен, Професионален, Работно пространство, Списък с маршрути, План за изходящи повиквания.
Едновременни разговори в натоварения час Сума от едновременните повиквания между устройства и между устройства и локалния шлюз (PSTN и повиквания към устройства). Необходимо е да се определи необходимата честотна лента за достъп до интернет.
Страна -
Часова зона -
Език -
Контакт (Име, Телефон, Имейл) -
Адрес (улица, град, щат, пощенски код) -
Физическо местоположение за изпращане на крайни точки на службите за спешна помощ Мястото за изпращане на устройството, използвано за спешни повиквания, обикновено включва следното: адрес на сграда, адрес на сграда + номер на етаж, адрес на сградата + номер на апартамент или адрес на сграда + номер на етаж + office/cubical номер.
Уникално физическо мрежово местоположение за всяко устройство за аварийни служби Физическото мрежово местоположение за спешни повиквания обикновено включва следното: превключвател / switchport за кабелни устройства, безжични идентификатори на базов набор от услуги (BSSID) за безжично свързани устройства, and/or локални IP подмрежи за крайни устройства.

PSTN

При проектирането на внедряване, клиентите имат три основни опции за PSTN свързване: Cisco Calling Plans (PSTN услуга, предоставяна в облака, управлявана от Cisco), Cloud-Connected PSTN Providers (CCPP, където доставчиците предоставят PSTN услуга през облака) и локална PSTN мрежа (където локални шлюзове свързват корпоративната мрежа с PSTN). С въвеждането на PSTN trunking за хибридни внедрявания (За повече информация вижте PSTN trunking за хибридни внедрявания на Webex Calling на PSTN trunking), организациите получават допълнителна гъвкавост в подхода си за миграция. Тази функция позволява на клиентите да преместят своята PSTN мрежа към CCPP в началото на прехода и да започнат прехода към облачна PSTN мрежа за потребителите, като същевременно използват CCPP, за да поддържат PSTN услугата за потребителите, които остават на Cisco по време на поетапна миграция.

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

Като алтернатива, организациите могат да изберат да запазят локалната си PSTN свързаност през целия преходен период. В този сценарий миграцията към CCPP може да се извърши по два начина: като единно, координирано преминаване за всички потребители и местоположения след завършване на миграцията или поетапно, като миграцията към PSTN се извършва за всяка отделна локация, когато потребителите се преместят към . Този подход може да помогне за рационализиране на съвместното съществуване и поддържане на непрекъснатост при наследени интеграции, но въвежда няколко оперативни усложнения. Сред тях са предизвикателствата, свързани с пренасянето на номера, като например необходимостта от прецизна координация на поръчките за пренасяне на номера, потенциални забавяния и ограничения, наложени от доставчиците, като например ограничение на броя на едновременните заявки за пренасяне или ограничения за пренасяне на подмножества от големи блокове с номера. Организациите трябва внимателно да планират своята стратегия за преход към PSTN, като вземат предвид тези логистични съображения, за да избегнат прекъсвания на услугите и да осигурят безпроблемно преминаване към друга мрежа.

Миграция към CCCP в началото спрямо запазване на локална PSTN мрежа

Фигурата Миграция към CCCP в началото спрямо запазване на локална PSTN показва двете опции за миграция към PSTN, обяснени по-горе. Илюстрацията отляво показва сценария, при който всички локални потребители и приложения консумират Cloud-Connected PSTN услуги чрез локална връзка и локален шлюз, свързващ локалната среда с , докато илюстрацията отдясно показва сценария, при който съществуващата локална PSTN мрежа остава на мястото си, а потребителите в Webex Calling използват локална PSTN мрежа чрез връзката Local Gateway между локалната среда и . По време на прехода локациите могат да бъдат превключени чрез Cloud Connected PSTN.

И в двата сценария разговорите между локалната система и потребителя използват връзката Local Gateway. Връзката между локалната и административната среда трябва да бъде проектирана и оразмерена съответно въз основа на очаквания брой едновременни повиквания и необходимата резервираност.

План за набиране

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

Локален план за набиране в

По време на прехода, за да се позволи съвместното съществуване на устройства, регистрирани в 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 низът ще бъде съпоставен или с a +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 набиране на вътрешен номер между местоположения. Тази опция трябва да бъде активирана само ако всички разширения в организацията са уникални. Ако опцията е деактивирана, тогава между местоположенията трябва да се набират важни за предприятието номера (код на управление, код на обект, вътрешен номер) или телефонни номера.

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

Таблицата Пример за номериране на предприятия показва пример за три местоположения, където диапазоните на разширение на две местоположения, NYC и RTP, са идентични. Установяването на схема за номериране на предприятието с междусайтова управляваща цифра 8, последвана от трицифрен код на обекта и четирицифреното разширение, създава неприпокриващ се съкратен междусайтов навик за набиране.

Таблица 2. Пример за номериране на предприятието
Сайт Обхват на удължаване Код на сайта Корпоративен обхват

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

СФО 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

За да се осигури плавен преход, в идеалния случай наборът от навици за набиране за потребителите преди и след прехода трябва да бъде еднакъв. За да се подготви преходът за всяко местоположение, е необходимо да се документират диапазоните на DID и диапазоните на разширения (или съкратените навици за набиране в рамките на обекта). Въз основа на тази информация трябва да се избере междусайтовата управляваща цифра.

Таблицата Диапазони на удължения с фиксирана дължина показва пример за три местоположения и диапазони на удължения с фиксирана дължина. Тъй като е необходимо да се избягват припокриващи се навици за набиране, е важно да се уверите, че за всеки диапазон на разширение първата цифра на диапазона не съвпада с управляващата цифра за съкратено набиране между обекти. Ако например 8 е избрана като управляваща цифра за набиране между обекти, тогава никой диапазон на разширения в който и да е обект не може да започва с 8. Обикновено разширенията на дадено местоположение съвпадат с последните няколко цифри от DID номерата, присвоени на това местоположение. За да се избегнат конфликти, първата цифра на разширението може да бъде променена. Ако например, DIDs в +1 Ако в дадено местоположение се използва диапазон 408 555 8XXX, тогава вместо да се използва 8XXX като диапазон на разширение, може да се използва 7XXX за разширенията в този сайт.

Таблица 3. Диапазони на удължения с фиксирана дължина
Сайт Обхват на удължаване Разширения Код на сайта Корпоративен обхват

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

СФО 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. Преход към седемцифрено набиране

Сайт Разширения Код на сайт Корпоративен обхват Ода на сайта Предприятие ange

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

СФО 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

За внедрявания на телефония, базирани в САЩ, които трябва да предоставят подобрени решения за спешни повиквания, се използва интегрираната в RedSky Horizon Mobility система за маршрутизиране на спешни повиквания. Когато използва RedSky за маршрутизиране на повиквания, администраторът трябва да се регистрира за акаунт чрез Cisco и да конфигурира съответната информация в Calling -> Настройки на услугата, за да активирате тази функция. След като услугата 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 препоръчва да се присвояват лицензи за обаждания, като се използват шаблони за лицензи. Това изисква за всяка група потребители, която изисква уникален набор от лицензи (Пример - Standard срещу Professional), да съществува група със съответните членства в групи. Както е обсъдено в разделите Потребителски групи, потребителските групи могат да бъдат дефинирани ръчно в или синхронизирани от корпоративна директория. Възможна е комбинация от двата подхода.

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

За повече информация вижте Настройване на автоматично присвояване на лицензи в Control Hub и Настройване на шаблони за автоматично присвояване на лицензи за потребители на Webex Calling.

Изисквания за лиценз

Този раздел обхваща само свързани лицензи. Други видове лицензи (пример - регистрация на устройство Webex, съобщения, срещи) не са обхванати. Като част от процеса на проектиране, е необходимо да се определят изискванията за лиценз. Необходимо е да се изчисли броят на лицензите за следните типове лицензи:

Стандартен: брой индивидуални потребители, изискващи стандартни телефонни функции.

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

Работно пространство за обща зона: брой места за споделена употреба или общи зони, изискващи стандартни възможности за разговори.

Съдействие на клиенти: брой агенти и ръководители, изискващи функции за подпомагане на клиенти. Клиентската поддръжка включва професионален лиценз.

Списък с маршрути за повиквания: брой необходими облачни свързани 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 Програмно управление на потребители чрез Webex API Гъвкав; поддържа автоматизация и интеграция Изисква развитие и инфраструктура
Синхронизирана с указател Автоматична синхронизация от 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 Wizard или SCIM приложенията. Ръчното и групово предоставяне на CSV файлове са налични като допълнителни методи, но са по-малко мащабируеми и по-податливи на грешки за големи организации. Гарантирането, че Entra ID е авторитетният източник и че всички потребители съществуват в Entra ID, е от решаващо значение за успешната миграция и последователното потребителско изживяване в различните среди.

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

Проектиране на потребителски групи

След прехвърляне на корпоративния указател от локално към облачно, съберете необходимите потребителски групи, определени от изискванията за лицензиране и шаблони за функции. За всеки групов документ:

Име на групата: уникално име на групата.

Лицензи: лицензи, които ще бъдат присвоени на тази група (ако има такива) и обхват (трябва ли лицензите да бъдат присвоени на съществуващи потребители или само на нови потребители)

Шаблони за настройки: Шаблони за обаждания от приложението Webex и потребителите.

Синхронизиране на директории: Тази група ще бъде ли синхронизирана от корпоративната директория или е локална Webex група, осигурена в Control Hub или чрез API?

Описание: как ще се използва тази група и кои потребители трябва да бъдат членове на нея

Тези данни ще бъдат използвани по-късно по време на фазата на внедряване за създаване на локални групи или групи в корпоративната директория и управление на членството в групи на потребителите.

Еднократна идентификация (SSO)

Cisco препоръчва използването на SSO за удостоверяване на потребителите. Използването на SSO има някои убедителни предимства, включително:

Опростено удостоверяване на потребителя: Потребителите могат да влязат веднъж, използвайки своите корпоративни идентификационни данни (например от Azure ID), за да имат достъп до други интегрирани приложения, елиминирайки нуждата от множество пароли и намалявайки подканите за влизане. Това повишава сигурността, като гарантира, че корпоративните пароли никога не се съхраняват или предават след удостоверяване.

Опростено управление на потребителите: Автоматизира създаването, актуализирането и деактивирането на потребителски акаунти въз основа на промени в корпоративния указател, намалявайки административните разходи и гарантирайки, че само оторизирани потребители имат достъп.

Подобрена сигурност: SSO намалява умората от пароли и риска от нарушения, свързани с пароли, чрез централизиране на удостоверяването чрез доверени доставчици на самоличност (IdP).

Лесна интеграция на многофакторно удостоверяване (MFA): Многофакторната автентичност (MFA) може лесно да се поддържа или чрез решение за управление на достъпа до идентичност (Identity Access Management), като Cisco Duo, или чрез поддръжка на MFA от страна на IdP.

Има няколко опции за внедряване на SSO за услуги:

Единично влизане (SSO), базирано на SAML 2.0: Основният протокол, поддържан за SSO интеграция, позволяващ сигурен обмен на информация за удостоверяване между IdP и доставчика на услуги.

OpenID връзка (OIDC): Поддържа се като алтернативен съвременен протокол за удостоверяване за SSO интеграция.

Идентичност в Webex: Поддържа се и като опция за доставчик на самоличност.

SSO се конфигурира и управлява централизирано чрез , което изисква обмен на метаданни между и избрания IdP.

След конфигурирането, SSO може да бъде тестван преди активиране, за да се гарантира правилната настройка.

Cisco поддържа интеграция с множество тествани и често използвани IdP-ове и системи за управление на идентичността (IAM), включително, но не само:

Cisco Duo

Okta

Услуги за федерация на Microsoft Active Directory (ADFS)

Microsoft Azure

PingFederate

OpenAM

F5 BIG-IP.

Тези IdP отговарят на стандартите SAML 2.0 или OpenID Connect и са валидирани за съвместимост с решенията за сътрудничество на Cisco.

Поддръжка на множество IdP

позволява на организациите да конфигурират SSO с множество IdP, за да се съобразят със сложни ИТ среди, като сливания, придобивания или децентрализирани ИТ отдели, където различните групи използват различни IdP. Поддръжката на множество IdP може да бъде реализирана или с помощта на функцията за множество IdP в, или чрез интеграцията на корпоративна IAM система, като Cisco Duo.

Поддръжката на множество доставчици на идентичност (IdP) на [платформата] адресира няколко ключови случая на употреба, при които организациите изискват гъвкаво и сигурно удостоверяване в различни ИТ среди:

1. Сливания и придобивания

Когато компаниите се сливат или придобиват други, те често имат отделни ИТ инфраструктури и отделни IdP-ове, които не могат да се обединяват. Поддръжката на множество IdP позволява на потребители от двете организации да се удостоверяват и да си сътрудничат сигурно, без да е необходимо незабавно да обединяват системите си за идентичност.

2. Множество независими ИТ отдели

Големите организации или държавните институции могат да имат множество независими ИТ отдели, всеки от които управлява свой собствен IdP. Функцията за множество IdP позволява на тези отдели да поддържат свои собствени системи за удостоверяване, като същевременно осигуряват на потребителите безпроблемен достъп.

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

Организации с различни потребителски групи (напр. служители срещу изпълнители) или множество имейл домейни могат да конфигурират правила за маршрутизиране, за да насочват заявките за удостоверяване към съответния IdP въз основа на членство в домейн или група. Това поддържа диференцирани политики за достъп и контроли за сигурност.

4. Поддръжка на различни протоколи за удостоверяване

Поддържа SAML и OpenID Connect (OIDC) IdP-ове, което позволява на организациите да интегрират различни видове доставчици на идентичност според съществуващата им инфраструктура и изисквания за сигурност.

5. Подобрена сигурност и съответствие

Чрез активиране на множество IdP, организациите могат да внедрят по-силни механизми за удостоверяване, включително многофакторно удостоверяване (MFA) чрез интеграции като Duo, и да наложат последователни политики за сигурност в различни потребителски бази.

6. Опростено потребителско изживяване

Потребителите могат да се удостоверяват, използвайки съществуващите си идентификационни данни от съответните си IdP, осигурявайки унифицирано преживяване за влизане, въпреки основната сложност на множество системи за идентичност.

Въпреки че поддръжката на множество IdP осигурява гъвкавост, тя изисква внимателна координация между екипите по сигурност и идентичност, за да се поддържат последователни политики за сигурност и да се избегнат потенциални уязвимости.

Duo MFA с SSO за

Duo Access Gateway (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, подобрявайки нивото на сигурност.

Самостоятелно записване: Вграденото записване и подканата в Duo подобряват потребителското изживяване по време на настройката на MFA.

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

Cisco препоръчва внедряването на SSO за потребителите. За подобрена сигурност се препоръчва интеграция с Cisco Duo.

Стратегията за Enterprise IAM и SSO трябва да бъде внедрена преди започване на прехода от към .

Функции

разполага с пълен набор от основни функции, които са включени в услугата. Това включва много функции за обаждания от корпоративен клас, които са налични от много години. Може да не видите 100% съответствие между функциите и функциите, но както можете да видите на фигурата по-долу, ключовите функции за повиквания са налични в .

Функции на Webex Calling от корпоративен клас

Освен многото потребителски функции, платформата има и основни системни функции. Те включват функции като автоматични оператори, опашки за повиквания, паркиране на повиквания и др. Можете да видите всички налични основни системни функции в Услуга → Разговори → Функции, както е показано на фигура Основни функции на Webex Разговори.

Основни функции на Webex Calling

Автоматичен секретар

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

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

Автоматичният оператор поддържа следните ключови функции:

Работно време и графици след работно време

График за празници

Опция за набиране на номера, за да насочите клиентите си към мястото, където трябва да отидат

Персонализиране на поздрави

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

Опции за пренасочване на повикването

Анализи и отчети на Control Hub.

За повече информация вижте Управление на автоматични оператори.

Прехвърляне на повикване

Паркирането на повикване дава възможност на потребителите лесно да поставят повикване в режим на задържане, за да може друг потребител лесно да го приеме, когато е на разположение. Това също така освобождава потребителя, който е отговорил на първоначалното повикване, да осъществява или приема други повиквания, докато повикването е паркирано.

Има два вида паркинги за повиквания, предлагани в :

Директно паркиране на повикване - позволява на всеки потребител да паркира повикване към вътрешния номер на друг потребител или към вътрешния номер за паркиране на повикване, както е определено от администратора

Група за паркиране на повиквания - позволява на определена група потребители автоматично да паркират повиквания до наличните дестинации за паркиране, определени за групата. Тези дестинации могат да бъдат вътрешните номера на членовете на групата или вътрешните номера за паркиране на повиквания.

В зависимост от конфигурацията и типа на паркиране, потребителите могат да приемат повиквания, като набират *88+><extension of parked call>, натискане на клавиша на линията, свързан с вътрешния номер за паркиране на повикване, или използване на софтуерен клавиш на техния IP телефон.

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

За повече информация вижте Управление на паркирането на повиквания в Control Hub.

Поемане на повикване

Приемането на повикване позволява на администратора да определи група потребители (членове), които могат да отговарят на повикване към телефона на друг член. Това дава възможност на потребителя да отговаря на повиквания, когато неговите съотборници са заети и не могат да отговорят на входящо повикване.

Потребителите в една група трябва да са на едно и също място.

Потребителите могат да използват или , или стационарния си телефон, за да приемат повикване.

:

Поддържа визуални и аудио известия

Известие за входящо повикване

FAC-базирано (набиране *98) или приемане на обаждане чрез известие

Известия за поемане на повикване за многолинейни повиквания.

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

Известие за входящо повикване

Звукови сигнали и визуално известяване чрез светодиода на слушалката. 6821 поддържа само аудио звънци

Когато избраният тип известие не е няма

Известия за поемане на повикване само за основни линии.

За повече информация вижте Конфигуриране на група за приемане на повиквания.

Опашка на повикванията

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

Призивът на Cisco за интеграция с Microsoft Teams позволява на агентите да имат достъп до повиквания и функции на опашката за повиквания директно от своя клиент на Microsoft Teams.

Опашките за повиквания поддържат следните ключови функции:

Поздрави и съобщения (добре дошли, утеха, шепот и др.)

Задържане на музика

Обратно повикване

Политики за маршрутизиране на опашки (нощно обслужване, празници, пренасочване)

Опашка на агента login/logout

Управление на състоянието на опашката на агентите

или поддръжка на стационарен телефон

Мониториране на обаждания от агент на супервайзор, насочване, вмъкване или поемане на контрол чрез кодове за достъп до функции (FACs)

(достъп на администратор) за:

управление на опашки

Анализ и отчитане на агенти и опашки

Управление на опашки, агенти и супервайзори.

За повече информация вижте Конфигуриране на опашката за повиквания.

има допълнителна функция Customer Assist, която предоставя допълнителни възможности за опашка от повиквания и дава на агентите и ръководителите по-добро потребителско изживяване в . За сравнение на функциите „Опашка за повиквания“ и „Помощ за клиенти“ вижте сравнение на функциите „Опашка за повиквания“ и „Помощ за клиенти“ на Webex Calling.

Група за търсене

Групите за търсене позволяват насочването на входящите повиквания към определена група потребители чрез предварително определен модел на маршрутизиране на повиквания. Това гарантира, че повикванията се приемат от правилната група потребители или се изпращат към гласова поща за последващи действия.

Една голяма разлика между групите за търсене и опашките за повиквания е, че повикванията не се поставят на опашка в групите за търсене, така че ако няма потребители в групата за търсене, които да отговорят на повикването, то ще бъде прекъснато, изпратено към гласова поща или пренасочено към друг номер (потребител или услуга).

За повече информация вижте Управление на групи за търсене в Control Hub.

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

Функцията „Оперативни режими“ позволява на фирмите ефективно да пренасочват повиквания към различни дестинации (потребители, гласова поща, услуги за повиквания, като например опашка за повиквания). Където и кога се пренасочва повикването, се базира на график за времето от деня и деня от седмицата и всеки потребител може да бъде оторизиран да управлява тези режими (графици), за да контролира промените в маршрутизирането на повикванията.

Като пример, повикванията към опашка за повиквания могат да бъдат пренасочени към друга опашка за повиквания с агенти в различна часова зона, за да отговарят на повиквания след работно време, по време на работно време да бъдат пренасочени към местните агенти, а по време на празници да бъдат пренасочени към гласова поща за последващи действия, след като агентите се върнат в офиса.

Упълномощен потребител може да превключва между тези различни сценарии (режими) за пренасочване на повиквания, ако е необходимо да промени къде се пренасочват входящите повиквания за определен период. Тези потребители могат да управляват режимите чрез своите 6800/7800/8800 MPP телефони, 9800 телефони или в Потребителския център на Управление на режими.

За повече информация вижте Маршрутизиране на повиквания въз основа на режими на работа в Webex Calling.

Група за пейджинг

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

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

За повече информация вижте Конфигуриране на група за пейджинг в Control Hub.

Записи

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

Когато се използва като платформа за запис, всички записани разговори се управляват в . Пълноправните администратори с ролята на служител по съответствието могат да възпроизвеждат и изтеглят записите. Без ролята на служител по съответствието, администраторът може само да изтрива записите.

За повече информация относно тази функция и списък със записи от трети страни вижте Управление на записа на разговори за Webex Calling.

Свързване с един номер

Достигането до един номер позволява повиквания към телефонния номер на потребителя да звънят на множество устройства. Това може да включва други настолни телефони, както и мобилни телефони. От тези устройства могат да се осъществяват и разговори, а потребителите могат да прехвърлят и изтеглят разговори между тях.

За повече информация относно тази функция и как администраторът я конфигурира в , вижте Конфигуриране на достъп до един номер (офис навсякъде).

За повече информация относно това как потребителят може да управлява и конфигурира тази функция за себе си в Webex User Hub (портал), вижте Конфигуриране на достъп до един номер (офис навсякъде).

Група за гласова поща

Групите за гласова поща позволяват споделена кутия за гласова поща, която може да бъде присвоена на потребител или функция за пренасочване на повиквания. Някои от причините, поради които може да е необходима група за гласова поща, са:

Гласова поща с общо предназначение за отдел или работна група

Добавяне на опция за гласова поща към автоматичен секретар или група за търсене

За изпращане на препълнени повиквания от опашка за повиквания

Потребители, които се нуждаят само от гласова поща.

За повече информация вижте Управление на споделена гласова поща и кутия за входящи факсове за Webex Calling.

Конзолата за обслужване е посочена на страницата „Функции за повиквания“ в Webex, но е допълнителна функция, за чието използване е необходимо закупуване на лиценз за конзолата за обслужване.

За повече информация вижте Първи стъпки с Attendant Console.

За информация относно всички функции, включително някои допълнителни функции, вижте Функции, налични по тип лиценз за Webex Calling.

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

Таблица 2. Пример за номериране на предприятието
Сайт	Обхват на удължаване	Код на сайта	Корпоративен обхват
Ню Йорк	2XXX	202	8 202 2XXX
СФО	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

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

Таблица 4. Преход към седемцифрено набиране

Сайт	Разширения	Код на сайт	Корпоративен обхват	Ода на сайта	Предприятие ange
Ню Йорк	2XXX	22	8 22 2XXX	822	8 822 2XXX
СФО	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. Опции за осигуряване на потребители за
Метод за осигуряване	Описание	Плюсове	Недостатъци
Ръчно	Create/manage потребителите поотделно в	Лесно за малко потребители; не е необходима инфраструктура	Не е мащабируемо; отнема време за много потребители
Групово (CSV файл)	Import/update потребители групово чрез CSV в	Ефективно за групи; не се изисква кодиране	Ръчна подготовка на CSV; по-малко динамично
Хора и SCIM 2.0 API	Програмно управление на потребители чрез Webex API	Гъвкав; поддържа автоматизация и интеграция	Изисква развитие и инфраструктура
Синхронизирана с указател	Автоматична синхронизация от 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 Calling. Използвайте тази информация, за да конфигурирате защитната стена, прокси сървърите и друга мрежова инфраструктура в съществуващото внедряване, за да активирате мрежовите потоци.

Децентрализираният интернет достъп от всеки клон или обект е препоръчителният подход за услуги за сътрудничество в облака, като например . Като позволява на трафика да излиза локално, този модел:

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

Мащабира се ефективно, когато все повече потребители и сайтове преминават към

Работи безпроблемно със SD-WAN, която може динамично да насочва сесиите към най-близката точка за достъп до облака за оптимална производителност.

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

Освен това, организациите трябва да осигурят адекватна интернет честотна лента на всяко място. Размерът на честотната лента трябва да се определя въз основа на очаквания брой едновременни повиквания, избрания кодек (напр. Opus или G.711), плюс режийни разходи за сигнализация, ретрансмисии и растеж. Това е в съответствие с фазата на подготовка от жизнения цикъл на PPPDIO и установява солидна основа за миграция.

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

Подсекцията за първоначална настройка във фазата на внедряване е от основно значение за създаването на добре структурирана и управляема среда за облачни разговори. Този етап обхваща критични задачи като създаване на организацията, осигуряване и предоставяне на лицензи, както и проверка и заявяване на домейни на вашата компания, за да се гарантира правилно управление на потребителите и сигурност. Освен това, включва предоставяне на шаблони за лицензи за автоматизиране на присвояването на потребителски лицензи, конфигуриране на единично влизане (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 entry ID:

Създайте група с име „група за синхронизация“

Присвоете групата към настройките за осигуряване на Entra ID

Само потребителите в тази група ще бъдат осигурени за .

Винаги тествайте груповата синхронизация в непроизводствена среда, преди да я приложите към цялата организация.

Редовно преглеждайте членството в групата, за да се уверите, че само оторизирани потребители са синхронизирани

За текущо управление, автоматизирайте актуализациите на членството в групата въз основа на бизнес правила или HR системи, ако е възможно.

Референции:

Синхронизирайте потребителите на Entra ID в Control Hub

Настройте приложението Entra ID Wizard в Control Hub

Конектор за директории

Настройване и тестване на единично влизане (SSO)

Единичното влизане (SSO) подобрява сигурността и опростява потребителския достъп, като позволява на потребителите да се удостоверят веднъж с корпоративните си идентификационни данни и да получат безпроблемен достъп до. Поддържа SSO интеграция със SAML 2.0-съвместими IdP, включително Microsoft Entra ID (преди Azure AD), федерални решения на Active Directory (AD) и различни IdP на трети страни.

На този етап проектираната SSO настройка трябва да бъде внедрена и тествана.

Референции:

Интеграция с единичен вход в контролния център

конфигуриране на еднократно влизане за администриране на Webex

Конфигуриране на еднократно влизане с Microsoft Entra ID

Единично влизане в системата (SSO) с множество IdPs

Управление на SSO при интеграция в Control Hub

Закупуване, предоставяне и проверка на лицензи

Като част от първоначалната настройка на , е от съществено значение да се закупят, осигурят и проверят подходящите лицензи, за да се активират и управляват ефективно услугите. Процесът на възлагане на обществени поръчки включва избор на типове лицензи въз основа на потребителските роли и натовареност, като например професионални, стандартни и лицензи за работно пространство. Лицензите се генерират и предоставят чрез софтуерните платформи на 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 Plans, поръчката и пренасянето се инициират от Control Hub веднага щом местоположението бъде създадено, както и в държави, където Cisco Calling Plan е наличен. За повече информация относно плановете на Cisco Calling вижте Първи стъпки с плановете на Cisco.

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

Конфигуриране на местоположения

Преди да добавите потребители и устройства към , трябва да осигурите местоположения за повиквания. За всяко местоположение трябва да се въведе валиден адрес. В САЩ и Канада този адрес се валидира и използва от платформата за изпращане на информация за местоположението по PIDF-LO за спешни повиквания.

Когато конфигурирате местоположения, които използват локална PSTN, трябва да настроите съответно локалните шлюзове. В , за всеки локален шлюз трябва да се създадат trunk и група маршрути, а след това групата маршрути се присвоява като PSTN избор за местоположението. Cisco силно препоръчва винаги да избирате група маршрути като PSTN избор, тъй като този подход ви позволява лесно да добавяте допълнителни канали в бъдеще, поддържайки както мащабируемост, така и резервиране. Cisco също така препоръчва активиране на поддръжка за двойна идентификация и P-Charge-Info на всяка PSTN трънна линия, тъй като това опростява идентифицирането на платимата страна за изходящи директни или пренасочени повиквания. Ако вашият PSTN доставчик използва различен заглавен файл за фактуриране, можете да копирате информацията от заглавния файл P-Charge-Info на локалния шлюз в необходимия заглавен файл за фактуриране.

За местоположения, които използват Cloud Connect for или Cisco Calling Plan като своя PSTN опция, просто изберете съответния PSTN избор за местоположението по време на настройката. Ако местоположението използва Cloud Connect за PSTN или локална PSTN, ще трябва да добавите телефонните номера, които бяха поръчани в предишната стъпка. Номерата могат да бъдат добавени като неактивни, ако не искате да бъдат включени в пренасочването на повиквания веднага; можете да активирате тези номера по-късно, когато бъдат присвоени на потребители или функции.

Важно е винаги да задавате основния номер за всяко местоположение. Основният номер може да бъде присвоен или на потребител, или на функция, като например автоматичен оператор. За да активирате гласова поща на мястото, не забравяйте да зададете пилотния номер на гласовата поща, известен още като номер на гласов портал.

Допълнителните настройки за обаждания до местоположения включват конфигуриране на подробности за спешни повиквания, като например номер за обратно повикване при спешни случаи, опции за известия и подобрени функции за спешни повиквания. Трябва също да прегледате и коригирате настройките за запис, езиковите предпочитания и конфигурациите на устройството, както се изисква за всяко местоположение. Ако вашата организация използва съкратено междусайтово набиране в мрежата със значими за предприятието номера, не забравяйте да конфигурирате уникален код на сайта за местоположението във вътрешните настройки за набиране. Накрая, ако външното набиране изисква цифра за изходящо набиране, не забравяйте да я зададете в настройките за външно набиране. Когато е конфигурирана изходяща цифра за набиране, Cisco препоръчва да се активира прилагането на изходяща цифра за набиране, за да се осигури съгласуваност.

Интеграция с локален контрол на обажданията

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

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

Ако вашето внедряване изисква поддръжка за маршрутизиране на неизвестни разширения, тази функция трябва да бъде активирана на ниво местоположение. Освен това, когато е активирано маршрутизиране на неизвестен вътрешен номер, трябва да посочите максималната дължина на неизвестния вътрешен номер в секцията „Маршрутизиране на повиквания между помещения “ на настройките за услуги за повиквания в . Това гарантира безпроблемно маршрутизиране на повикванията и правилно обработване на сценарии за набиране, базирани на вътрешни номера, във вашата интегрирана среда.

Мигриране на потребители на партиди

Когато мигрирате потребители от към , може да не успеете да преместите всички потребители едновременно. Това може да се дължи на множество причини, включително, но не само, броя на сайтовете или потребителите, колко време отнема преходът на даден сайт and/or група потребители едновременно, ограничени ИТ или сайтови ресурси за поддръжка на прозореца за промяна, продължителност на прозореца за промяна, сложност на промяната и др.

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

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

Мониторинг на други потребители чрез BLF-ове

В един и същ пилотен проект за търсене, опашка за повиквания и т.н.

Споделени редове

Използване на приемане на обаждане

Използване на едни и същи номера за паркиране на повиквания

Интерком

Executive/Admin.

Пример за това би бил потребител, който е част от група за лов, която се прехвърля към . Този потребител ще премине към групата за лов и към всички останали членове на групата за лов. Следователно, след прехода, Hunt Group и нейните членове могат успешно да отговарят на повиквания на новата платформа.

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

Използвайте резултата от инструмента Migration Insights или инструмент на трета страна, който сте използвали във фазата подготовка, за да определите кои потребители и функции трябва да бъдат групирани заедно. Този резултат би трябвало да се използва за разработване на вашия план за миграция и ще ви даде представа как ще групирате потребителите и функциите, които трябва да преминат заедно.

Ключовите стъпки при прехвърлянето на група потребители са:

Идентифициране на потребители за съвместна миграция

Проверете дали всички потребители са в системата

Проверете дали всички TN-и за потребителите съществуват в

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

Уверете се, че шаблоните за лицензиране и настройки за потребителските групи са настроени правилно.

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

В корпоративния указател добавете потребители към групата потребители с активирани обаждания

Инструменти за използване - инструменти за мигриране на потребители и функции and/or инструменти на трети страни

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

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

Работни области

В , работно пространство се отнася до споделено място (като конферентна зала, място за срещи или работно бюро), на което могат да бъдат присвоени устройства, разширения и потребители. За разлика от традиционните телефони на Unifed CM, работните пространства са:

Ориентирано към местоположението: обвързани с физически пространства.

Гъвкаво за устройството: може да има едно или повече устройства (настолни телефони, табла и др.).

След като работните пространства бъдат идентифицирани като част от прехода към , те могат да бъдат добавени в „Устройства“. Всяко работно пространство се нуждае от присвояване на устройство и ако те вече са в Unified CM, те трябва да бъдат нулирани или повторно осигурени за . Функции като гласова поща, пренасочване на повиквания и приемане на повиквания могат да бъдат активирани или деактивирани, а правила могат да се прилагат за видео разговори, паркиране на повиквания и мобилност, както се изисква. Тествайте всяко работно пространство, като осъществявате вътрешни и външни разговори, тествате видео, конференции и функции за мобилност. Накрая, уведомете потребителите за всички приложими процеси за устройства и резервации в работното пространство.

За повече информация относно работните пространства в , вижте Работни пространства.

Устройства за осигуряване

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

Всички поддържани телефони, от които трябва да преминете, ще трябва да бъдат конфигурирани като потребител или работно пространство, а физическият телефон ще трябва да бъде преконфигуриран, за да се регистрира в . Освен това, телефоните от сериите 7800 и 8800 се нуждаят от надстройка на фърмуера си от Enterprise до Multiplatform Phone (MPP) фърмуер. Този процес включва зареждане на преходен фърмуер преди зареждане на MPP фърмуера, необходим за регистрация. Изисква се и съответният миграционен лиценз. Cisco подобри този процес през последните няколко години, за да ви улесни в надграждането на фърмуера на вашите телефони Enterprise до MPP фърмуер. За повече информация относно стъпките за завършване на надстройката на фърмуера вижте Конвертиране на IP телефони от серията Cisco 7800 и 8800 между Enterprise и MPP фърмуер.

В допълнение към стъпките, описани в тази статия, има вграден инструмент, Мигриране на телефона ви към Webex Calling, който можете да използвате, за да мигрирате вашите телефони 7800 и 8800 от Enterprise към MPP фърмуер. Този инструмент ви позволява също да добавяте телефоните и да ги присвоявате на съответните потребители или работни пространства. За повече информация относно използването на инструмента вижте Мигриране на телефона ви.

За телефони от серия 9800, регистрирани с горепосочения фърмуер, изискването за мигриране на фърмуера не се прилага. Тези телефони работят с PhoneOS, която се поддържа както от . За да прехвърлите тези телефони към, ще трябва да ги добавите към Webex Calling, да ги присвоите на потребител или работно пространство и след това да възстановите телефоните до фабричните настройки. Последователност на зареждане на PhoneOS за регистрация фигурата по-долу показва последователността на зареждане на PhoneOS и как телефонът ще се регистрира, след като бъде добавен към , дори ако телефонът все още е настроен на and/or Използват се DHCP опции (пример - 150).

Последователност на зареждане на PhoneOS за регистрация

Поддържа фабрично нулиране на устройства с PhoneOS, за да се позволи Zero-Touch Onboarding към . Администраторите могат дистанционно да възстановят фабричните настройки на телефоните 9800 и 8875 чрез страниците за администриране на CUCM, което елиминира необходимостта от физически достъп до телефоните за свързването им към . Тази функция се поддържа с пакетите с устройства от 9 септември 2025 г.:

CUCM v15 - Unified Communications Manager версия 15

CUCM v14 - Unified Communications Manager версия 14.

За повече информация относно процеса на регистрация за серия 9800 вижте Процес на регистрация.

В допълнение към IP телефоните на Cisco, може да се изисква осигуряване на други устройства, като например аналогови телефонни адаптери (ATA), безжични (Wifi, DECT) телефони, видео устройства, гласови шлюзове и устройства и телефони на^трети страни . Много от тези устройства нямат път за надграждане на фърмуера, както IP телефоните, за да преминат от корпоративен фърмуер към облачен фърмуер. Следователно, ще осигурите всяко от тези устройства в Control Hub. Някои от тях не могат да бъдат прехвърлени и ще трябва да бъдат заменени с еквивалентен модел (напр. ATA 191/192) а други ще изискват ръчно преконфигуриране and/or промени в софтуера.

Гласови шлюзове - За да мигрирате локалния си шлюз, вижте Мигриране на локален шлюз.
За повече информация относно конфигурирането на вашия гласов шлюз VG400, VG410 или VG420 в Control Hub, вижте Локален шлюз

Аналогов телефонен адаптер (ATA) - За да започнете работа с вашите Cisco ATA 191 и 192, вижте Cisco ATA.

Безжичен Wifi телефон - За интегриране на безжични телефони 840 и 860, вижте Интегриране на безжичен телефон Webex.

Безжични DECT телефони - За да започнете работа с новата си серия Cisco IP DECT 6800, вижте Cisco IP DECT.

За да изградите и управлявате цифрова DECT мрежа в Control Hub, вижте Управление на DECT мрежа

За повече информация относно Cisco IP DECT 6800 вижте Ръководство за внедряване

3^{- ти} устройства и телефони - Работете с 3-ти [] доставчици на трети страни 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 за всички местоположения трябва да бъде настроен към доставчика на Cloud Connected PSTN, а входящата и изходящата свързаност трябва да бъдат проверени.

Както е обсъдено в раздела за PSTN на главата за проектиране, клиентите могат също да изберат да преместят своя PSTN достъп към Cloud Connect в началото на прехода, използвайки PSTN trunking за хибридни внедрявания. За повече информация вижте PSTN транкинг за хибридни внедрявания на Webex Calling. В този случай, по време на прехода, достъпът до PSTN е чрез локален шлюз и след преместването на всички потребители към, няма допълнителна стъпка за миграция, свързана с PSTN, освен извеждане от експлоатация и локалните шлюзове.

Оптимизирайте локалната инфраструктура

След като всички потребители са преминали към регистрация в облака и всички крайни точки са преминали към регистрация в облака (или са били изведени от експлоатация), актуализирайте съответната локална инфраструктура, сега когато се използва облачно обаждане. Актуализациите на инфраструктурата включват:

Премахнете локалните SRV записи за контрол на повикванията и съобщенията в DNS системата от локалните DNS сървъри, включително cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги.

Премахнете свързаните с edge DNS SRV записи от публичната DNS система, включително collab_edge._tls.<domain>. Тези SRV записи вече не са необходими за откриване на клиентски услуги за услуги за сътрудничество на периферията.

Актуализирайте всички съответни DHCP обхвати, за да премахнете опция 66 и опция 150 TFTP/boot адреси на сървъри. Тези обхвати вече не са необходими за откриване и изтегляне на конфигурация за контрол на повикванията на крайни точки.

Update/remove подходящи dial-peers в Local Gateway/CUBE които маршрутизират повиквания към и от Unified CM. Тези точки за избиране вече не са необходими за локално маршрутизиране на повиквания.

Изтриване или премахване на всички виртуални машини и виртуални машини на клъстерни възли and/or сървъри. Пренасочвайте изчислителните ресурси и хардуера според нуждите. Тези ресурси вече не са необходими за контрол на повикванията и периферни услуги.

Изтриване или премахване на всички виртуални машини на клъстерни възли and/or сървъри. Пренасочвайте изчислителните ресурси и хардуера според нуждите. Тези ресурси вече не са необходими за гласова поща и услуги за унифицирани съобщения.

Почистване: След мигриране на PSTN достъпа към Cloud Connected PSTN, PSTN транкове, PSTN шлюзове и локален шлюз могат да бъдат деактивирани.

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

DN имената, принадлежащи на мигрирани потребители, трябва да бъдат поставени в скрит дял, за да се избегнат грешки при маршрутизиране на повиквания и да се гарантира, че всички CSS имат приоритетен достъп до облачния път на същите DN имена.

Актуализирайте физическото местоположение за изпращане и мрежовия елемент в Horizon Mobility при настъпване на промени. Често срещани дейности, които изискват актуализации, са:

Подмяна на мрежов комутатор

Подмяна на безжична точка за достъп

Промени в обхвата на DHCP

Физически промени вътре в сградата (ако се реши въпросът cubical/office)

Разширяване или свиване на физическото офис пространство в сграда.

Използвайте анализи и отстраняване на проблеми

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

анализи на качеството на медиите

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

отстраняване на проблеми с качеството на медиите

Отстраняването на неизправности може да се интегрира и с други продукти на Cisco, като например комутатори ThousandEyes и Meraki, за да осигури още по-богато интегрирано изживяване в Control Hub. За повече информация относно използването на Webex Calling анализи и отстраняване на неизправности, вижте Отстраняване на неизправности при повиквания на Webex Calling в Control Hub.

1	Създайте специална група за синхронизация: В корпоративната директория (Microsoft Entra ID или AD) създайте група за защита специално за синхронизиране (например група за синхронизиране).
2	Попълнете групата с целеви потребители: Добавете към тази група само потребителите, които искате да синхронизирате (например тестова група по време на пилотната фаза). Това ви позволява да контролирате строго кой е включен в процеса на синхронизация.
3	Конфигу@@ риране на споразумението за синхронизиране с групово филтриране: Когато настройвате споразумението за синхронизация в предоставянето на Directory Connector или Entra ID, конфигурирайте обхвата да включва само потребители, които са членове на определената група. За Microsoft Entra ID можете да използвате групови задачи в настройките за предоставяне За AD можете да дефинирате LDAP филтър, който да включва само потребители, принадлежащи към зададената група .
4	Разширете групата според нуждите: Докато напредвате към по-широки фази на внедряване, просто добавете допълнителни потребители или групи към групата за синхронизация. Обхватът на синхронизи ране автоматично ще се разшири, за да включва тези потребители, което позволява контролирано и постепенно в недряване. Примерни стъпки за изпълнение: В активната директория: Създайте група за защита, наречена група за синхронизиране. Добавете желаните пилотни потребители към тази група. Настройте конектор за директории с LDAP филтър като: (MemberOf = CN = Webex Sync Group, OU = Groups, DC = вашият домейн, DC = COM). В Microsoft въведете идентификатор: Създайте група, наречена група за синхронизиране Присвояване на групата към настройките за предоставяне на идентификатора в Entra Само потребителите в тази група ще бъдат предоставени. Винаги тествайте груповата синхронизация в непроизводствена среда, преди да кандидатствате за цялата организация Редовно преглеждайте членството в групата, за да сте сигурни, че само оторизираните потребители са За непрекъснато управление автоматизирайте актуализациите на членството в групата въз основа на бизнес правила или системи за човешки ресурси, ако е възможно. Референции: Синхронизиране на потребителите на Entra ID в контролния център Настройване на приложението Entra ID Wizard в контролния център Конектор за директории

Продукт	Описание
Unified CM	Локален контрол на повикванията, предоставящ услуги за регистрация на устройства и маршрутизиране на повиквания
Сиско Expressway-C/E	Крайна инфраструктура, осигуряваща мобилен и отдалечен достъп (MRA) и функционалност „бизнес към бизнес“ (B2B), позволяваща на отдалечени крайни точки да се свързват сигурно отвън организацията. Expressway се разполага по двойки, за да осигури преминаване през защитната стена за външни крайни точки.
Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) и Cisco Telepresence Management Suite (TMS)	Локална инфраструктура за гласови, видео и уеб конференции, осигуряваща многоточкови срещи, управление на срещи и възможности за планиране. [Optional]
Връзка към единица на Cisco	Локална платформа за гласови съобщения, предоставяща възможности за гласова поща и унифицирани съобщения. [Optional]
Cisco Desk, Cisco Room, Cisco Board, Cisco IP телефони и Cisco Jabber	IP-базирани устройства, регистрирани в Unified CM и предоставящи възможности за гласови и видео разговори

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 entry ID: Създайте група с име „група за синхронизация“ Присвоете групата към настройките за осигуряване на Entra ID Само потребителите в тази група ще бъдат осигурени за . Винаги тествайте груповата синхронизация в непроизводствена среда, преди да я приложите към цялата организация. Редовно преглеждайте членството в групата, за да се уверите, че само оторизирани потребители са синхронизирани За текущо управление, автоматизирайте актуализациите на членството в групата въз основа на бизнес правила или HR системи, ако е възможно. Референции: Синхронизирайте потребителите на Entra ID в Control Hub Настройте приложението Entra ID Wizard в Control Hub Конектор за директории

Cisco AI Assistant

Благодарим за обратната връзка.

Ръководство за внедряване

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

Общ преглед

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

Преглед на процеса на PPDIO

Общо описание на PPDIO

Използване на PPDIO за Webex Calling мигра Unified CM ционни проекти

Подгответе

План

Дизайн

Прилагане

Оптимизиране

PPDIO контури за обратна връзка

Миграционен подход

Подгответе

Бизнес и технически изисквания

Защо изискванията за събиране са важни:

Изисквания за бизнеса

Технически изисквания

Мрежова готовност и изисквания

Настройване на UC, свързан с облака

Оценка на текущата среда

Лицензиране

Местоположения/сайтове

Инвентаризация на съществуващи устройства/клиенти

Проверете допустимостта на устройството

Потребители

PSTN свързаност

Характеристики и използване на функциите

Интеграции на Cisco: Unity Connection UCCX UCCE

Запис на обаждания

Интеграции на трети страни

План

План на проекта на високо равнище

Миграционно пътуване - една или две стъпки?

Вариант 1: Миграция на потребителя в една стъпка

Вариант 2: Двустепенна миграция на потребителя

Стъпка 1

Стъпка 2

Дизайн

Избор на регион

Местоположения

PSTN

План за набиране

Локален план за набиране в

план за набиране

Записване

1. Избор на доставчик на запис на разговори

2. Избор на регион

Спешно повикване

Лицензиране

Ръчно възлагане чрез

Шаблони за автоматично възлагане на лицен

Групово възлагане чрез CSV шаблон

Назначаване, базирано на API

Изисквания за лиценз

Осигуряване на потребителя

Потребителски групи

Препоръчителен подход при мигриране от към

Проектиране на потребителски групи

Еднократно влизане (SSO)

Поддръжка на множество IDP

1. Сливания и придобивания

2. Множество независими ИТ отдели

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

4. Поддръжка на различни протоколи за удостоверяване

5. Подобрена сигурност и съответствие

6. Опростено потребителско изживяване

Дуо MFA с SSO за

Характеристики

Автоматичен асистент

Обадете се в парк

Вземане на обаждания

Опашка за обаждания

Хънт Груп

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

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

Записи