Ръководство за внедряване на миграция

В тази статия

Обратна връзка?

Структурираният процес на миграция от локална Cisco Unified CM към облачна система Webex Calling, използващ методологията PPPDIO. Това включва критични дизайнерски съображения като например избор на регион, планове за набиране, аварийни служби и запис на разговори. Процесът също детайли за лицензиране, осигуряване на потребители, SSO и готовност на мрежата, за да се осигури безпроблемна и ефикасен преход.

Въведение

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

Това ръководство е предназначено за екипи или лица с опит в конфигурирането и администрирането на Cisco Unified Communications Manager (Unified CM) и крайни точки на Cisco, включително IP настолни телефони, видео устройства и софтуерни клиенти Jabber. В целия документ има връзки към продуктова и помощна документация, които да ви помогнат.

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

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

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

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

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

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

По време на изпълнението на процеса 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 фази.

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

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

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

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

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

Подготовка

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

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

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

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

Бизнес изисквания

Типичните бизнес изисквания включват:

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

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

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

Фокусирайте се повече върху това, от което се нуждаете, отколкото върху това, което имате.

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

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

PSTN връзка

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

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

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

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

Лошите мрежови условия между локален шлюз и SBC за достъп могат да ограничат производителността на сигналната връзка, което води до още по-нисък лимит на едновременните повиквания. Еднопосочната латентност между локалния шлюз и центъра за данни не трябва да надвишава 100 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 за да прегледате конфигурациите в графичния потребителски интерфейс или в данните за експортиране на конфигурацията.

Таблица 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

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.

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

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

поддържа различни интеграции с трети страни, включително, но не само, SBC за локални шлюзове, IP телефони, интерком телефони, Speaker/Pagers, 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 от препоръчаното пътуване.

Унифицирана карта за преход на високо ниво от 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 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

Благодарим за обратната връзка.

Ръководство за внедряване на миграция

Въведение

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

Общ преглед

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

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

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

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

Подготовка

Планиране

Проектиране

Внедряване

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

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

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

Подготовка

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

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

Бизнес изисквания

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

Готовност и изисквания за мрежата

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

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

Лицензиране

Locations/Sites

Съществуваща инвентаризация devices/clients

Проверете дали устройството отговаря на условията

Потребители

PSTN връзка

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

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

Записване на повикване

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

Планиране

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

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

Опция 1: Мигриране на потребители в една стъпка

Опция 2: Двуетапна миграция на потребителите

Стъпка 1

Стъпка 2

Проектиране

Избор на регион

Местоположения

PSTN

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

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

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

Записване

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

2. Избор на регион

Спешно повикване

Лицензиране

Ръчно задаване чрез

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

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

Задание, базирано на API

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

Обезпечаване на потребители

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

Препоръчителен подход при мигриране от към

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

Еднократна идентификация (SSO)

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

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

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

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

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

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

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

Duo MFA с SSO за

Функции

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

Прехвърляне на повикване

Поемане на повикване

Опашка на повикванията

Група за търсене

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

Група за пейджинг